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

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.

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.

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.

The only thing I’m not a fan of is that encryption key is created by 3rd party.

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).

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)

Vihor:

Speaking of security, who programmed the original encryption key? Is it stored somewhere on Vivokey servers? Do I get to know the key?

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.

fraggersparks:

the Ntag “poisons” the output with a counter.

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.