OpenSK: Not working with google?
I am using the stable branch without any modifications.
I have successfully built and flashed it to an nrf52840 Dongle.
after flashing
I have ran
./tools/configure.py --certificate=crypto_data/opensk_cert.pem --private-key=crypto_data/opensk.key
and the certificate seems to be installed.
and the OpenSK device seems to be working on https://demo.yubico.com/playground
but when I tried using it with a google account, it is failing to add.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 29 (11 by maintainers)
If you use a vendor specific command (like we did for our
configure.pyscript) to dump the storage, this should at least come with the step of validating the user’s PIN to succeed. Maybe the command should also take an ECC public key as a parameter to protect the storage so that OpenSK can encrypt it properly before sending it over USB.Injecting the storage into another key has some side effects though as it creates a clone of an existing key. Not sure right now how to deal with this in a good way.
At the moment the only idea that comes to my mind would be that OpenSK creates internally a unique encryption key, derived from hardware constants that survive even a chip erase and that is guaranteed to be unique per chip. This encryption key could be used to seal the storage before dumping it and used again to decrypt it for injection, ensuring that the storage is still bound to the OpenSK device. As the encryption key is unique per chip it guarantees such a command can’t be abused to create clones. CryptoCell has such key baked in but we only partially support CC310 for the bootloader (SHA256 module, not encryption).
I opened a new issue #455 to track that. Seems like an independent problem!
The browser controls whether U2F or CTAP2, and it’s also your privacy advocate. The browser doesn’t directly forward the received responses from your security key, but filters necessary information. For example, when you reproduce this issue with a recent Chrome, it would ask at some point whether you want to allow sending information to identify your security key model. If you skip, Chrome strips this information. Basically, you choose your anonymity set: Everyone in your batch, from a website point of view, could be you. Same for no attestation. You share identity with everyone who decides not to use attestation. This should in theory be the largest anomymity set, but I don’t have data on that.
This answers the question around safety of sharing the private key. If your attestation private key is known, everyone can pretend to be a Feitian OpenSK. You could e.g. use it for your own security key software implementation. This is good for privacy, but has one downside: A cautious website has to assume that everyone who says they are an OpenSK are actually a software implementation. So if a website really only wants to accept hardware authenticators, they have to reject OpenSK.
So yes, it’s safe to use Feitian’s
crypto_data. Nobody can steal your own private key material through that.