Authentication with ECC/OTP custom APDU

[rrottmann]

As an alternative to using VERIFY(CHV1) to unlock the token, a challenge / response scheme should be established.
This would also be the preferred method to authenticate/unlock the token via a script.

1. Alice generates ECC keypair on token and receives the public ECC key. (operation requires CHV3 authentication)
2. Bob generates ECC keypair on another token
3. Alice uploads Bobs ECC public key to an OTP slot on the token
4. Bob uploads Alices ECC public key to an OTP slot
5. Alice generates a nonce on the token. Nonce gets stored and printed
6. Bob uses token that has Alices ECC public key stored to derive a shared secret on token
7. Bob uploads the nonce and receives a HMAC calculated using the derived shared secret on token
8. Alice calculates derived shared secret on token using Bobs ECC public key and calculates HMAC(stored_nonce)
9. Alice compares self-calculated HMAC with uploaded HMAC from Bob. If they match, token gets authenticated
10. Alices token generates and stores a new nonce regardless of successful authentication

• Ideally, other ECC keypairs (e.g. generated using Python cryptgraphy library or openssl) can be used as well to generate a compatible public key that gets used to derive a shared secret
• The HMAC function using derived secrets from an uploaded ECC public key should be available to the user as this can be standalone useful
• This scheme allows a usecase where the security officer initializes the key using CHV3 and does not handout CHV1 but only onet-time codes
• The unlock using the onetime code should not be useable to change CHV1
• gpg operations should work without further authentication once the token is unlocked