One additional note, to avoid surprise when you read the code. (Mostly
aimed at Rob, but others might have opinions.)
The initial implementation does not pull the wrapped key out of the
keystore and ship it directly to the caller. Instead, it calls
hal_ks_fetch (which unwraps the key), then it fetches the MKM KEK and
re-wraps the key. On import, it doesn't write the wrapped key directly
into the keystore, but it unwraps the key with the MKM KEK, and calls
hal_rpc_pkey_load, which re-wraps the key before storing it.
While this is inefficient, it means not having to modify the keystore
code (fewer little-used, little-tested code paths), and it isolates the
changes to rpc_pkey.c. Also, on import, we have to determine the key
type (by unwrapping and checking the ASN.1 wrapper), 1) because we need
it for the slot structure and the key block header structure, and 2)
because importing a hashsig key requires rebuilding the hash tree.
It would be possible to export the whole keystore block (or the key
block header + der), but if we ever change the keystore implementation,
it could invalidate not only the keys currently in flash, but any keys
in external storage. Maybe not a big deal? Also, it would expose the key
metadata (key block header) in plaintext. Bigger deal or no big deal?
As it is now, a "raw" exported key has the exact same structure (ASN.1
wrapper) as a "normal" exported key, except that it doesn't come with an
encrypted wrapping key. We could also get that by pulling just the der
from the key block, but we'd still need to unwrap the key on import, for
reasons above.
paul
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
