Closed bubundas17 closed 7 months ago
Related Issue: #389
I changed
pub const USE_BATCH_ATTESTATION: bool = false;
to
pub const USE_BATCH_ATTESTATION: bool = true;
then I can use OpenSK to work with google account.
It seems google account can not accept self-attestation which is returned by OpenSK's authenticatorMakeCredential.
Thanks @bubundas17 and @geofli ! From an OpenSK perspective, everything is working as expected. I'll leave this open to track, as it should by default definitely work for a Google login.
Please note that setting USE_BATCH_ATTESTATION
to true
with a self-generated attestation key makes you uniquely identifiable across websites. A workaround would be to generate a new random batch certificate on every registration, but that would just be a more convoluted way to not use attestation.
Yes, I saw the contents, thank you @kaczmarczyck
Usually, the attestation private key is shared between a batch of at least 100,000 security keys of the same model. If you build your own OpenSK, your private key is unique to you. This makes you identifiable across registrations: Two websites could collaborate to track if registrations were attested with the same key material. If you use OpenSK beyond experimentation, please consider carefully if you want to take this privacy risk.
So U2F is left to use batch certificate because it is required by some websites to use U2F
, right?
Now I think Google Account turns to use WebAuthN (CTAP2) instead of U2F, this issue happened.
Now If call WebAuthN from Chrome on Android, the platform/browser sends U2F command. But with Chrome on Windows and macOS, the platform/browser sends CTAP2 commands. Is there a way for RP to choose to send CTAP2 or U2F command through WebAuthN instead of platform/browser controls that?
If it is not privacy friendly to use an unique attestation private key. Is it safe to use the crypto_data folder shared by FeitianTech? And is it safe to use a private key which is being shared in a public repository?
https://github.com/FeitianTech/OpenSK/releases
I got this release link on Feitian's OpenSK GUI setup guide. https://feitiantech.github.io/OpenSK_USB/feitianguiway/
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.
The certificate and private key shared here https://github.com/FeitianTech/OpenSK/releases are different with the materials inside OpenSK hardwares sold publicly. https://github.com/FeitianTech/OpenSK/releases was just regenerated to show how to use the GUI firmware update tool.
Some off topic questions: Will it be possible to backup and restore the storage partition without a j-Link and restore it later?
AFAIK, it is impossible to do that unless you use a J-Link.
@bubundas17 Can you tell me more about your use case? It has traditionally been considered a feature that secrets can not leave your security key. I believe there may be good reasons to want such a feature, and I'm curious about your ideas!
@kaczmarczyck As it is already possible to dump the persistent storage via a j-Tag, Security concerns should not be a factor in not implementing it because someone with the right tools can do it anyway.
I thought it might be helpful. Because, while tinkering with the firmware (e.g., changing from one version to another or tweaking customization parameters.), at some point, we might need to clear the storage (As it happened multiple times with me) and lose the persistent contents, so we might want to keep a backup of the device in a working state .
Users should have the choice whether they want to lock down access to JTAG or not. You can configure OpenSK to be locked down for improved security. I'm not saying that this closes all attack vectors for a local attacker, but arguably security key users have advantages from inaccessible private key storage.
I'd suggest that you don't tinker with the device that holds your actual important secret. I do see the benefit of backing up your security key, but how to do that correctly and securely is a hard question. There is no standardized solution to this problem so far. Of course, since OpenSK is open source, you could add that functionality for yourself. :)
I am already using a Yubico Key for daily use. If I consider adding this feature and create a PR, will you guys accept it?
If you use a vendor specific command (like we did for our configure.py
script) 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).
@geofli
Setting
const USE_BATCH_ATTESTATION: bool = true;
Has another side effect.
Yubico's WebAuthn demo, is no longer accepting the key.
https://demo.yubico.com/webauthn-technical/registration
It says,
Attestation certificate must use version 3!
Tested with Stable and Develop branches. same behavior.
I opened a new issue #455 to track that. Seems like an independent problem!
@bubundas17 , yes, the automatically generated certificate is not compliant with https://www.w3.org/TR/webauthn-1/#packed-attestation-cert-requirements , so Yubico demo server rejects it.
I just changed const USE_BATCH_ATTESTATION: bool = true
to try to check that Google server does not accept self-attestation. If you want to really change OpenSK to have batch attestation, there is still some work to do.
The work mentioned by @geofli is tracked under #457. We are looking into the problem of supporting none attestation. Looks like OpenSK is working as intended, but I will keep this issue open to track our behavior for Google logins.
same
Even I changed const USE_BATCH_ATTESTATION: bool = true
After compiling with USE_BATCH_ATTESTATION
set to true
, did you also configure OpenSK to set a certificate?
./tools/configure.py \
--certificate=crypto_data/opensk_cert.pem \
--private-key=crypto_data/opensk.key
And if so, can you tell me what website you used, plus all steps I need to reproduce?
ok just i editing USE_BATCH_ATTESTATION = true in mod file: and flashing. After flashing I trying add phisic key to google account: and after enter the pin and clicked button on phisic key, Windows are still please me enter the pin. I can do this indefinitely. loop { enter_the_pin(); click_phisic_button(); }
I forgot that I install with stable branch.
It works for me, but I see you use Windows, and you don't seem to pass the Windows dialog. Is your problem Google specific, and all other websites work?
yep
not working on windows 10 and 11
I can't reproduce. On both stable
and develop
, the following steps work on Windows 10:
I don't have an update on registering on Google without batch attestation.
Login with Google works now, tested with the develop
branch, no batch attestation and Chrome 120.0.
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.