Hey I like to contribute! 
This community seems awesome anyway.
2 Likes
When you get into the Vivokey forum,There is mention of IFTTT in a thread Thread you might want to browse.
.
Here is the link for your future reference
https://members.vivokey.com/t/what-should-we-do-next/18/41
This is where the IFTTT mention starts
https://members.vivokey.com/t/what-should-we-do-next/18/41?u=pilgrimsmaster
2 Likes
Thanks for the links. Will be useful.
1 Like
Feel free to clone the repo and run localy to test the Auth and IFTTT.
P.S. I did this “blindly” without having the Spark to test yet. So, there could be minor errors, but the OpenID flow is there and IFTTT is working even on localhost (regardless of CORS).
Cheers
3 Likes
One question, thou. Is development with a implanted chip risky? Can I brick it?
I saw Amal was using a test card in the vivocoin demo. Wonder if it’s for a reason.
Referring to Spark 2 specifically.
You always want to test things out on a test card before deploying to an implant. I forget what the exact chip in the Spark 2 is, but you should be able to purchase test cards for it. @fraggersparks would know.
If you want to do development for the upcoming APEX line, you’ll need Javacards like these
1 Like
Unfortunately, looks like these cards for Spark 2 are not to be found on Digiwell, where I made my initial purchase. Dang it, now I have to get them from somewhere else and w8 with the dev all over again. 
It depends on the chip. With something like the Spark where you can’t actually write to the chip, bricking it would take intentionally plopping it on an NFCKill device or a similar level of full on dumb.
With writable chips there’s some risk of writing garbage to the chip putting it in a weird state, but as far as I know this is rarely permanent, but will usually require a Proxmark and some know how to fix. The only chips that I’m aware of being able to fully brick through normal operation are the old VivoKey Flex One Beta units and the FlexM1 Gen2.
1 Like
Yea, makes sense. I know it’s unwritable, so the only thing I’m expecting to potentially fail are my API requests 
Can’t wait to test the IFTTT Webhooks as soon as my Spark arrives.
If any of you feel like living on the edge you can go test it locally and tell me if it works for you.
1 Like
They are NTAG 413s iirc.
1 Like
Yep your right,
2 Likes
Nice features for NTAG413!
Speaking of security, who programmed the original encryption key? Is it stored somewhere on Vivokey servers? Do I get to know the key?
I would assume VivoKey programmed them and has a database of the keys since that’s required to make the OpenID stuff work.
Donno if they’d give you your key though since giving keys to anyone sounds like a dangerous and slippery slope, but worth asking probably.
1 Like
Hi all,
Spark devices are exclusively a VivoKey product. Test cards can be obtained by contacting @amal - you can’t buy a Ntag in the correct specs as it still needs symmetric key generation and registration in our backend.
3 Likes
Hi @fraggersparks thank you for the info! I hope @amal has some spare test cards around. I would mainly like use it to authenticate with different services I develop on my own backend like IFTTT sample app (I shared my repo link above). Just some stuff I would like to access or do securely on daily basis.
The only thing I’m not a fan of is that encryption key is created by 3rd party. I come from a crypto community and not having keys in your possession kinda defeats the purpose of cryptography. If there should be one point of failure, it should be the user, not the company. I wouldn’t like my key leaking anytime, anywhere. It is a big responsibility. I own NanoLedger which is also a tamperless crypto device, but the keys are blank on purchase, and get generated on first run. I know this is impossible without a some micro processor, but I imagine it’s good idea to bounce arguments around.
1 Like
This is not considered an issue on our end as these keys are not for end users. They are used purely for challenge encryption and are useless for actual cryptography - the Ntag “poisons” the output with a counter.
Your use case for cryptography much better aligns with the Apex, which does exactly as you’ve specified. Generates keys that are unexportable (and has the option for asymmetric keys).
3 Likes
This makes much more sense now regarding “crypto” function of the chip. I guess it’s good news after all. As long as my server is well secured, there should be no issues.
1 Like
Not the Spark 1 or Spark 2, those are locked down and unbrickable.
Demo cards are for easier development, particularly for devs who don’t have or want implants but might be working to integrate some service. We will make them available on Dangerous Things for cheap. They will have some limitations coming down the pipe, but for now they are just like any other Spark 1 card (the cards have ISO15693 ICODE DNA chips like the Spark 1)
We program the keys during manufacture and keep the keys stored on our side. This is for authenticating the chip with challenge/response to the VivoKey platform.
It’s a random nonce actually, not a counter value… at least not the TAM1 challenge response. The SUN feature of the Spark 2 contains a CMAC signature that does use a counter value… but it’s technically less secure from an attack surface standpoint than TAM1, so we are only supporting it with a grain of salt at this point.
2 Likes
I just recently built something that does this from an Arduino.
Scan your implant. When a specific UID is detected, it sends an HTTP Request to an IFTTT webhook and triggers an applet.
You could easily just skip the whole Arduino aspect of it and use the Vivokey app to set the URL that is opened when your implant is scanned to the URL of the webhook.
The URL structure used by an IFTTT webhook is:
http://www.maker.ifttt.com/{WEBHOOK_EVENT_NAME}/with/key/{YOUR_WEBHOOK_SERVICE_KEY}
1 Like