If you need an easy way to view and manage discoverable credentials on your NFC passkey token, you can use our app! You can also change your PIN using the app as well.
For anyone who wants to avoid Google Play, you can side-load the debug APK (while you still can);
VivoKey_Passkey_Manager.apk (39.2 MB)
7 Likes
Even if you donât have the Google Play Store and Google Play Services on your phone, you can use the Aurora Store to download and install the apps from Google Play.
5 Likes
Do you know if this will persist after the shift to no sideloading?
Depends. If you run it on a stock locked-down phone, probably not since it just calls out to the package installer for you, essentially the same as when you tap an apk to open it. Its magic is really the API connection to Google Play.
On a free Android like LineageOS where these signature enforcements are optional, or any rooted stock Android, you can still install the apk normally. Should that also fail, you can use Aurora Services (similar to the FDroid privileged extension) as a privileged system component to handle the installations for you, or just root the phone and have Aurora use root commands via Magisk to force installation.
That said, it is still unclear to me when and how rigid these signature enforcements will arrive.
3 Likes
Awesome. Tested it on my P71 test card with FlexSecure FIDO2 and my Apex. No issues.
Any plans to support managing or deleting non-passkey FIDO 2 credentials? For instance, I have my Apex as a 2FA for an AWS account (which I presume holds a private key), but its not a discoverable credential/passkey, and no PIN is required.
3 Likes
FIDO2 knows two types of keys:
-
Discoverable credentials (previously known as resident keys): These keys store actual key material and metadata on the hardware chip. These are the keys you can actually view and manage in the storage of your chip. These keys also power single-factor / Passkey logins, as the relying party can determine who is trying to log in because the chip allows for credential metadata discovery.
-
Server-side credentials (also known as non-discoverable credentials): These keys are cryptographically derived from a fixed secret inside the chip. The entire key materials and metadata is encrypted in the key handle, which is stored, managed, and supplied for authentication by the relying party, i.e. the server you are authenticating with. No storage is used for these keys on the chip. These types of keys can only be used for second-factor logins as the relying party already has to know who is trying to log in to send the correct key handle. This modality is also how U2F (FIDO1) works exclusively.
4 Likes
Updated today to v1.0.2 to direct users to set PIN for any token without one sec. Operating without a PIN set can work for certain passkey registrations, but it makes the reality of using your token awkward.. so we just donât attempt to list any credentials without first setting a PIN.
2 Likes
Thanks! I was under the impression that some amount of information was being stored on the FIDO device for non-discoverable credentials. Since even the older FIDO credentials were discussed in terms of public and private keys, I just assumed that a private key was being generated and stored each time a site enrolled the device as a 2nd factor.
This excerpt from A Tour of WebAuthn says:
Nearly all U2F security keys are designed in a manner that avoids the need to actually store the private keys, thus they can generate an unlimited number of credentials with only a constant amount of onboard storage. The exact details are private to the security key but go something like this:
Either at the factory or on first use, the security key will generate and store a random symmetric key. Weâll call this the âroot secretâ. Then, when the security key is asked to generate a public and private key, it chooses a random seed value and encrypts it with the root secret. Next, it authenticates the encrypted seed, along with the hash of the relying party ID and any other pertinent values, using an algorithm like HMAC.
Together, the encrypted seed and the HMAC form the credential ID. Then the security key generates a public key and private key from the seed, discards the private key, and returns the credential ID and public key to the computer.
When asked to do a sign operation, the security key splits the credential ID into an encrypted seed and an HMAC value. It checks whether the HMAC is correct for the relying party ID hash and the encrypted seed. If not, then either this credential ID came from a different security key or the relying party ID is incorrect. In either case, it returns an error.
But, if the HMAC is correct, it decrypts the seed using its root secret and can then derive the same private key as it did before. Then it performs the
signoperation with that private key and returns the resulting signature.At no point did the security key need to store anything other than the root secret, and there is only a single root secret for all credentials, so the storage requirements are constant. The state necessary for a credential is kept in the credential ID, and that is stored on the server.
Is this basically the process that the FIDO2 applet is doing when generating non-discoverable credentials? That a new public/private key pair is in fact being generated for each RP, but that the private key is discarded and recreated each time the device signs a request?
CTAP2/FIDO2 supports both discoverable (resident) credentials (ârk = 1â) username-less authentication flow, and non-discoverable (non-resident) credentials (ârk = 0â) where the RP must supply âallowCredentialsâ. Both are âpasswordlessâ but only resident keys can basically supply the entire authentication credential, while non-resident credentials must supply specific account data (stored on the RP server) to the token, hence the need to supply a username to the RP so they can look up the account blob that needs to be sent to the token.
With non-resident (non-discoverable) credentials, FIDO2 security keys are designed to be stateless per credential;
- At registration, the authenticator returns an opaque credentialId (a âkey handleâ). That blob typically contains the private key (or a seed to derive it) wrapped/encrypted with a device-unique secret, plus metadata (e.g., RP ID hash, policy flags) and a MAC for integrity.
- At authentication, the RP sends that same credentialId back to the FIDO2 token using âallowCredentialsâ. The authenticator unwraps/derives the key using its device secret.
Registration: The token makes a key pair. It sends the public key and a device-encrypted handle (credentialId) back through the browser to the RP. The RP stores public key + credentialId for your account.
Authentication: The RP sends that credentialId and a challenge to the token. The token opens the handle, rebuilds the private key in RAM, confirms itâs for this site, gets your touch/PIN if needed, signs the challenge, returns the signature, and forgets the private key. Nothing stored.
5 Likes
Pushed v1.1.0 release to improve PIN and NFC error handling and messaging. In review now.
3 Likes