Add injection and derivation support #8
Conversation
|
@sosthene-nitrokey Any clue how to resolve this one? |
You need to add your backend to the dispatch impl in the |
| type HmacSha256P256 = Hmac<sha2::Sha256>; | ||
|
|
||
| let key_id = request.key; | ||
| let key = keystore.load_key(key::Secrecy::Secret, None, &key_id)?; |
There was a problem hiding this comment.
Please verify that the key kind is a Symmetric key.
There was a problem hiding this comment.
Done, but had to revert. Will check this again later.
| pub fn inject_any_key( | ||
| keystore: &mut impl Keystore, | ||
| request: &request::InjectAnyKey, | ||
| ) -> Result<reply::InjectAnyKey, Error> { | ||
| let key_id = keystore.store_key( | ||
| request.location, | ||
| key::Secrecy::Secret, | ||
| request.kind, | ||
| &request.raw_key, | ||
| )?; | ||
|
|
||
| Ok(reply::InjectAnyKey { key: Some(key_id) }) | ||
| } |
There was a problem hiding this comment.
What does this syscall bring compared to the existing unsafe_inject_key syscall?
There was a problem hiding this comment.
I forgot to check opcard's implementation in this regard. There are no advantages of using this extension over Trussed's currently AFAIK. In the future supporting other kinds like curve25519 could be handy.
| let derived_key: [u8; 32] = mac | ||
| .finalize() | ||
| .into_bytes() | ||
| .try_into() | ||
| .map_err(|_| Error::InternalError)?; | ||
| let key_id = keystore.store_key( | ||
| request.location, | ||
| key::Secrecy::Secret, | ||
| key::Kind::P256, // TODO use mechanism/kind from the request | ||
| &derived_key, | ||
| )?; | ||
| Ok(reply::DeriveFromHash { key: Some(key_id) }) |
There was a problem hiding this comment.
Are you sure that this necessarily creates a key that is valid?
The key generation is a bit more complex than just using random bytes. This is the procedure we currently use in trussed: https://docs.rs/p256-cortex-m4/0.1.0-alpha.6/src/p256_cortex_m4/cortex_m4.rs.html#81-93.
Especially, the private key has to be within the
There was a problem hiding this comment.
That's a correct observation - there are no checks for key validation as of now. I was thinking about adding the same checks like done in the linked implementation, but I am gravitating now more towards using curve25519 instead, and remove the p256 support for derivation, unless proved to be safe to use in this way.
I've just noticed there is no ticket for that - to be done soon.
Connected: trussed-dev/trussed#44 (comment)
There was a problem hiding this comment.
For EdDSA this will work but for X25519 (ECDH) there is the same issue, except the constraints on the scalar are even worse.
There was a problem hiding this comment.
One solution could be to simply use the result of the hash to seed a ChaCha8Rng and use it to generate the key. We would need it to commit to having the key generation algorithm be stable so that the same RNG always gives the same key.
These are the features required by Nitrokey Webcrypt.
This fixes the "large size difference in enum" warning
To avoid accidental use of other secret material
This reverts commit fdc90f3. This is required to make Nitrokey Webcrypt working at the moment, but should be removed in the future.
|
Replaced by Nitrokey/nitrokey-websmartcard-rust#16 |
Add injection and derivation support needed for Nitrokey Webcrypt
Note: the current implementation of HMAC to P256 key derivation is not safe and should not be used in production