What happened to password manager that was under development that unlocks with Spark 2

Support
1

Hi,

I had been lurking the forum for a long time. I am still genuinely curious how can Spark 2 be useful for password manager or unlock a data vault etc. I forget who, but some company was working, partnering with Vivokey to develop a password manager and I am curious what happened?

Thanks!
-MJ

2

There are issues with key management. Basically you could use the auth API to generate a jwt but it requires online access to the auth API, and the password manager would have to trust the time and date of the machine it’s running on to compare the exp claim of the jwt.

That’s the first hurdle. The next one is data protection via encryption. One assumes the password manager database would be encrypted and therefore need decryption to access. Since the jwt is just clear text data with a signature, using some part of it as a symmetric decryption key is not advisable. Therefore you would then need a decryption password or phrase separate from the jwt which makes the whole thing moot.

There may be a way to do this but I don’t know a good way. Feel free to open discussion here because if something can be sorted out we could explore it for sure.

1 Like
3

Does it need to use the API in this scenario?

I’m not super familiar with the Spark 2 but as I understand it the API generates a random challenge string which is sent to the S2, which then replies with a chunk of data that is based on encrypting the challenge string with them embedded AES key. So for any given challenge the response is static, and couldn’t practically be determined without access to the S2.

If the goal is simply to have the S2 provide key material for decrypting a password manager, couldn’t you generate a challenge string and store it with the encrypted file? When you want to unlock it, you send the challenge to the S2, it will reply with the same response every time, and that response is your key to the encrypted database.

4

It’s not static as this would pose a serious problem for entropy… the chip appends random data to the challenge and encrypts it, sending back new different data each time for the same exact challenge.

5

aah, yeah, that makes sense.

Maybe a new API endpoint where you can submit a valid JWT and a block of data, and it gives you back the data encrypted with the associated AES key (or even run through some other sort of derivation function unrelated to the embedded key)?

6

I don’t have experience with the Spark 2, but what you describe is exactly what the HMAC-SHA1 applet for the Apex and FlexSecure does to act as a 2FA device for KeePassXC and KeePass2Android.

1 Like