Rewind key slot to 0, when num_issued exceeds 15.

[scateu]

Rewind key slot to 0, when num_issued exceeds 15. So that the oldest key can be wiped with the other 14 keys remained.

Note: When the '16th' key is being issued, it will blink first and fail, and then the counter will rewind to 0. The next enroll will be successful, and saved at slot 0.

[scateu]

Not sure if it is a good idea yet. Any comment is welcomed. 😃

[ad-m]

I think it's too dangerous for keys 👿 Maybe some shortcuts on button to confirmation? By mistake somebody can miss blinks and fails to upload key.

[scateu]

Yeah, I have the same feeling... However, since enroll(register) process is not so frequently, and the rewind process will give a failure as an additional prompt, I think it's relatively safe for user.

For example:

The detail process of enrolling the 16th key:

1. Browser: Register
2. U2F Zero: Red light
3. User press the button
4. Browser: Fail
5. U2F Zero: Blink red light
6. U2F Zero: rewind the key pointer to 0 (do nothing to keys)
7. Browser: Register (again)
8. U2F Zero: Red light
9. User press the button
10. Browser: Success
11. U2F Zero: Saved at slot 0

[jeffmilstea]

I also think it's too dangerous, and feel this is something best performed from the command line. Perhaps adding per-slot deletions to client.py would be a better approach?

[conorpp]

I think it would be too easy for a user to mistakenly overwrite a needed key pair. Also it requires the user to keep track of the order of the registrations. The identities of the key pairs can't be given as there can't be unique identifiers.

I'm currently looking into using a key wrapping method to remove the short key limit.

[scateu]

Key wrapping is used in yubikey now. But is it a waste of the other 14 key slots?

Plus, I think key wrapping is some kind of downgrading the security level of u2f keys? Since it share the same master key.

[conorpp]

Yes most of the key slots will go unused in the key wrapping method. It could potentially have a lower security level if the master key is not handled correctly. But in the current HW design I believe it can work fine.

The master secret can be 32 bytes of random numbers that are generated using the HW RNG. It is always stored on the crypto chip and used internally to compute a HMAC with the public key handle and AppID. This digest can then be used as a private key and can be recalculated on the fly.

Master secret is 256 bit so it has same security level of old/current keys. Master secret is still isolated on the crypto chip like the old/current keys.