Add mechanism for serializing private keys

[sosthene-nitrokey]

Summay

Add an secrecy field to StorageAttributes. When set to Public this allows calling wrapkey and serialize_key on a private key or a shared secret.

Motivation

Currently private keys cannot be serialized. This is generally a good thing as it avoids misuse, however there are cases where it is a limitation. The one I encountered was the serialization of the result of a Diffie-Hellman for an OpenPGP card implementation, which requires returning the output of a Diffie-Hellman to the host.

It would we useful to have a general mechanism to allow serialization of private keys, which is off by default.

Drawbacks

This is a breaking API change for StorageAttributes because the fields are public (they should probably be private or #[non_exhaustive]).

Inspirations

extractable from the Web Crypto APIs

Unresolved questions

What to do with a "secret" public key? If the default for StorageAttributes is to be Secret, obtaining the public key with derive_key would lead to a "secret" public key.

Alternatives

Add an agree_public method to CryptoClient that returns the result of the diffie-hellman as a byte array.

While this would fix the immediate need for an OpenPGP implementation, I believe it would be a bit redundant with the agree method and less flexible.

[sosthene-nitrokey]

Edited to add "Unresolved questions".

[sosthene-nitrokey]

Ok, I've begun working on an implementation. I think it's better to call it "extractable" instead of "secrecy".

The issue I'm encounter is for the serialization of asymmetric keys. The "Secrecy" (public or private) modifies the path of the key, so the client can't try to load the key and then look at whether it's a public or a private key. This seems redundant with the SENSITIVE flag that is stored with the key (but is never read).

[sosthene-nitrokey]

There's also no suitable Mechanism for serializing a symmetric secret

[nickray]

A not on terminology: Secrecy is secret or public, I try to avoid using "private" as a third terminology.

Fundamentally, /pub can be imported/exported freely, while /sec can only be unwrapped/wrapped (and by default, should not be extractable at all).

But generally, the terminology is based on an attempted simplification of flags set in PKCS#11 for private keys: https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/os/pkcs11-base-v3.0-os.html#_Toc29976581.

We should probably have a session to discuss the long-term plan.

[sosthene-nitrokey]

Draft implementation is at #39

[nickray]

Thanks for looking into this. Web Crypto as inspiration is good :)

Two things that are important:

• extractability should be set at creation and not changeable after
• import/export should always be unwrap/wrap operations, i.e. encrypted with some AEAD

For symm, I think serializing as raw bytes makes the most sense?

For the wrapping key, if it's for another hw key, ideally we can use the agreement identity key of that device (together with its certificate).

[daringer]

Are you sure there should be no way of exporting any private key in any situation? It might become necessary at one point. If the default is to disallow it I think it's fine.

I would also vote for "no way to export any private key" (w/o wrapping) ... E.g. this is also the case for the SE050 and overall a good default, as even for a misbehaving device this reduces chances to leak a private key.

[sosthene-nitrokey]

Ok, in that case I'm not sure my approach is that useful and the agree_public approach would be simpler. If we follow the approach of the SE050 of only exporting private keys wrapped with a static key not manipulated by the user, we need a separate mechanism to export the results of agree anyway.

[nickray]

I don't think agree_public makes sense, basically it's "we have a security mechanism in place for agree, but you can bypass it by just calling a different function".

One loophole we might try is:

• keep the diff between shared secret (SS) + symmetric key (SK) on a type level, where agree outputs a shared secret
• store both in /sec
• have both be non-extractable by default
• exceptionally allow extractable shared secrets to be exported (vs. wrapped)

I think in PIV they also only do agreement on the card and then pull the shared secret.
Does PGP at have some kind of transport layer security? I.e. encrypt at the transport layer if not at the API layer?

[nickray]

BTW, to avoid confusion, I see that by extractable above (and in WebCrypto) you mean "export the key" (unencrypted). On the other hand, WebCrypto lets you wrapKey any sensitive material.

In my own world view, there is secret and public data. You can always import/export public data. You can by default not wrap secret data; setting extractable allows this. But you'd never export secrets (unencrypted) even if they're extractable.

IOW, extractable means:

• can export (WebCrypto)
• can wrap (PKCS11)

not extractable means:

• can wrap (WebCrypto)
• can't do anything (PKCS11)

[sosthene-nitrokey]

exceptionally allow extractable shared secrets to be exported (vs. wrapped)

What do you mean by that? serialize_key on a kind::Shared with extractable set to true would work ?

[sosthene-nitrokey]

Does PGP at have some kind of transport layer security? I.e. encrypt at the transport layer if not at the API layer?

I has but only for management operations, not for cryptographic operation. I wouldn't make much sense for standard use anyway since the keys is plugged directly into the host it's communicating with.

[sosthene-nitrokey]

The SharedSecret case was fixed by #39

Other types of privates keys will not be exportable.