[shellcromancer]

Fantastic research by NinjaLab. One of the most interesting parts to me from Yubico's advisory is that the Webauthn protocols attestation [1] is also defeated by this local cloning. Could the protocol have been better designed to resist this local cloning attack?

> An attacker could exploit this issue to create a fraudulent YubiKey using the recovered attestation key. This would produce a valid FIDO attestation statement during the make credential resulting in a bypass of an organization’s authenticator model preference controls for affected YubiKey versions.

1. https://www.w3.org/TR/webauthn-2/#attestation

[sitharus]

> Could the protocol have been better designed to resist this local cloning attack?

I don't see how, the attacker is cloning the secrets used to sign the request, if they have those secrets there's no way of distinguishing the clone from the original device. The whole security model of secure elements is preventing the keys from being extracted, if you can do that there's no more security than saving the key to a file on your computer.

Of course to get the key they need to physically open the device, so unless someone actually takes your key it's more secure than saving them on you computer.

[magicalhippo]

The login service could send not just the request, but also N random bits for the next session.

These would be stored by the device and combined with the next sessions' request data before signing. The login site does it's own combining before checking the signature.

This way any clone usage would be obvious. If the attacker uses the clone before you, your key wouldn't work for that site anymore. The site could even warn you if it keeps track of previous values.

Likewise it limits the timeframe the attacker can use the clone.

I guess even just 16 bits of data should make it quite resistant to guessing by the attacker.

This requires some non-volatile storage to keep the "future bits", but at 16 bits you can do quite a few logins before having to do a single page erase.

Then again, not my field so perhaps there's something I'm missing.

[jtvjan]

Perhaps some kind of rolling key system could've been used? If the key was rewritten on each successful login, either the attacker would have to use their cloned key immediately (alerting the user), or have their cloned key become useless the moment the user logs in again. This would only work with discoverable credentials, and would increase wear on the device's flash storage.

[Scaevolus]

Even with extraction possible, it's much harder to get the keys from this device than a file on a computer.

Security isn't just the binary of "possible" vs "impossible". It's about *how expensive" that possibility is.

[lxgr]

Not really, unfortunately, given that attestation practically always depends on some piece of secure hardware being able to guard an issuer-certified secret with which it can authenticate itself to a relying party and thereby bootstrap trust into any derived/stored secrets.

If that attestation secret is extractable in any way, nothing prevents an attacker from creating a fake authenticator able to create fraudulent attestations, despite not behaving like an authentic one (i.e. in that it allows extracting stored credentials).

You could theoretically try to mitigate the impact of a single leaked attestation secret by using something like e.g. indirect attestation and authenticator-unique attestation keys (rather than attestation keys shared by hundreds of thousands of authenticators, which is what Yubikey does), but it would be a probabilistic mitigation at best.