I’ll try to explain what I think the spark 2 uses to authenticate you.
Just as a note, I did about a week of research on the spark 2 but decided to go for a NExT.
I’m no crypto expert, but this AES based security model cought my attention, how does it work?
The only thing I can imagine is that the challenge your implant has to solve is to decrypt and reencrypt a passphrase.
Decrypt with one and encrypt with another key.
That mitigates the risk that someone scans and copies your tag, because it will always be another passphrase/challenge.
My concern is, that this now places the trust on vivokeys servers. (But that’s already the case with openid, so don’t worry.)
Can someone confirm this theory?
I’m waiting for the Apex and hope I can use it to authenticate myself by signing a challenge with my private key (asymetric encryption).
You basically have it right. It’s a preshared key model (vs public/private key).
The server and tag provide a series of challenge/response transactions, all combined with some randomness (to thwart replay attacks) and the server just makes sure what comes back after decryption is what was sent before encryption. Overly simplified, but accurate none the less.
I’ll let someone else chime in but I’m 99% sure the Apex will be able to run an applet that does public key encryption.
You’re right, the Spark is only configured to handle symmetric key encryption, and currently the keys are retained by VivoKey. This is not intended to limit the capabilities of power users, it’s more targeted at enabling amateur users.
I’m not a javacard developer, but I know the Apex line will allow assymetric key encryption methods. One that is already implemented is OAuth2, which is what is used for the existing OpenID Connect plugin. There are a few others already developed and many more being fleshed out by the community. The Flex Beta participants did a great job brainstorming and developing some frameworks all the way back to 2018, until a critical manufacturing defect was discovered for our use case. The new line of chips does not appear to have that issue, so javacard development continues.
To be specific, a challenge is created on the server and passed through app to chip over NFC. The chip adds a random nonce to the data and encrypts it all with the requested key. The encrypted data is returned to the server for decryption using the key. The data is decrypted, the nonce thrown out, and the resulting data compared with the original challenge. If they match, the chip is considered authenticated, meaning we believe we talked to the actual chip not an emulator or malicious actor.
To further clarify… the key in this scenario means which key number… the Spark and Spark 2 both have 3 separate AES keys inside… we can request the challenge be encrypted using key 0, 1, or 2.