3 ms·

The vendors here are proposing a platform synchronization method such that these are both backed up as well as shared across devices within a particular platfor

by dwaite 5y ago

The vendors here are proposing a platform synchronization method such that these are both backed up as well as shared across devices within a particular platform account. There likely is a hardware key that supports export and import of keys (even if that winds up being a fork of say the Solo key firmware). However, as an end-user one doesn't want to accidentally forget to export keys for a while, nor do they want to worry about how to properly secure a backup. So, you likely would want additional infrastructure such as vendor software which would do this for you on a schedule. There are interesting models which could work here, such as a factory-paired 'set' of keys being sold in the same package, where only the second key (the one you kept in your fire safe) has the necessary keys to decrypt and load such a backup. The question is whether a security manufacturer would be interested in this, as the presence of such a mechanism may prevent them from getting certain security certifications and being able to sell/be used in certain markets and scenarios.

blep_ 5y ago
FIDO, at least, doesn't store per-site keys on the device. You only have to back up and restore the master key, which doesn't change and so doesn't need to be scheduled.
- dwaite 5y ago
  When generating non-resident/non-discoverable credentials, many authenticators will use a source of randomness, an internal secret and possibly the name of the requesting origin to generate a private key, and export either a seed value or a wrapped version of that key in a 'credential handle' during registration. You have to pass that handle back to authenticate someone, which the authenticator will process and check to see if they were the one that issued it. Such credentials are only usable for secondary factors, because you need to know what list of registered handles to pass to the authenticator, which means you will typically need to know who the requesting party is. Web Authentication and CTAP 2.x added the notion of discoverable credentials, which do not require such handles and as such are usable as a primary factor for authentication. A site can simply ask into the void "do you have any credentials for example.com" and potentially get back an answer. These necessarily require state. Several of the platforms do not want to deal with the security ramifications of exporting wrapped keys, and simply generate and store keys even in the traditional U2F case. This is actually why the terminology was changed from 'resident' to 'discoverable' in WebAuthn L2 and CTAP 2.1 - a non-discoverable credential has the old behavior where you have to supply the handle to get back a response, but there's no guarantee that credential won't be resident in some state store of the authenticator.

by dwaite 5y ago

blep_ 5y ago

FIDO, at least, doesn't store per-site keys on the device. You only have to back up and restore the master key, which doesn't change and so doesn't need to be scheduled.

dwaite 5y ago
When generating non-resident/non-discoverable credentials, many authenticators will use a source of randomness, an internal secret and possibly the name of the requesting origin to generate a private key, and export either a seed value or a wrapped version of that key in a 'credential handle' during registration. You have to pass that handle back to authenticate someone, which the authenticator will process and check to see if they were the one that issued it. Such credentials are only usable for secondary factors, because you need to know what list of registered handles to pass to the authenticator, which means you will typically need to know who the requesting party is. Web Authentication and CTAP 2.x added the notion of discoverable credentials, which do not require such handles and as such are usable as a primary factor for authentication. A site can simply ask into the void "do you have any credentials for example.com" and potentially get back an answer. These necessarily require state. Several of the platforms do not want to deal with the security ramifications of exporting wrapped keys, and simply generate and store keys even in the traditional U2F case. This is actually why the terminology was changed from 'resident' to 'discoverable' in WebAuthn L2 and CTAP 2.1 - a non-discoverable credential has the old behavior where you have to supply the handle to get back a response, but there's no guarantee that credential won't be resident in some state store of the authenticator.