This page aims to document the security related aspects of the FIDO2 implementation on Solo. This is to make it easier for public review and comments.
Solo aims to achieve 256 bit (32 byte) security with its FIDO2 implementation, even in light of physical side channels.
When Solo is first programmed, it will be "uninitialized," meaning it won't have any secret material, until the first time it boots, then it will leverage the TRNG to generate all necessary material. This only happens once.
A master secret,
M, is generated at initialization. This is only used for
all key generation and derivation in FIDO2. Solo uses a key wrapping method
for FIDO2 operation.
NOTE: The masked implementation of AES is planned, but not yet implemented. Currently it is normal AES.
When you register a service with a FIDO2 or U2F authenticator, the authenticator must generate a new keypair unique to that service. This keypair could be stored on the authenticator to be used in subsequent authentications, but now a certain amount of memory needs to be allocated for this. On embedded devices, there isn't much memory to spare and users will allows frustratingly hit the limit of this memory.
The answer to this problem is to do key wrapping. The authenticator just
M and uses
M and the TRNG to generate new keys and derive previous
keys on the fly. A random number,
R, is generated, and is placed in the
KEYID parameter. The service stores
KEYID after registering a
key and will issue it back to the authenticator for subsequent authentications.
In essence, the following happens at registration.
R, calculate private key,
- Derive public key,
Rto service. (
- Service stores
Now on authenication.
- Service issues authentication request with
- * Authenticator generates
- Proceed normally as if
Kwas loaded from storage memory.
Planned, but not yet implemented.
M consists of 64 bytes, split into equal parts
In theory, we should only need 32 bytes to achieve 256 security, but we also
plan to have side channel security hence the added bytes.
Our HMAC currently is a two step process. First, just generate a normal
tmp = SHA256_HMAC(M1, R)
We could proceed using
tmp as our secret key,
K. But our
implementation isn't side channel resistant and we won't bother trying to add
side channel resistance. So we add an additional stage that is side channel
K = aes256_masked(M2, tmp)
We add a masked AES encryption to provide side channel resistance. Masked AES
is well studied and relatively easy to implement. An adversary may be able to
M1 via SCA but not
* There are other details I leave out. There's also an authentication tag
KEYID parameter to ensure this is a key generated by the Solo