[Freeipa-devel] DNSSEC key wrapping: cryptographer needed

Tue Jun 24 14:30:54 UTC 2014

----- Original Message -----
> Hello list,
> 
> I'm working on key wrapping mechanism described in thread "LDAP schema for
> DNSSEC keys" [0] and I'm really puzzled from the maze of crypto here. I would
> really appreciate any suggestions or comments on this.
> 
> - I have difficulties to pick and use proper wrapping mechanisms and their
> configuration/usage patterns.
> 
> - Rick van Rein from OpenDNSSEC-user list noted that we are defeating purpose
> of PKCS#11 by exporting raw keys from HSM. I can see his point and we should
> be able to do all crypto operations inside SoftHSM.
> 
> I have asked him to describe his doubts on freeipa-devel list - stay tuned.
> 
> 
> We need to wrap
> ===============
> - asymmetric key (zone key)   with symmetric key  (master key)
> - symmetric key  (master key) with asymmetric key (replica key)
> 
> LDAP schema prescribes some storage formats but my question is about crypto
> algorithms (and padding!) used for key wrapping.

It is important to get these details right indeed, we must be able to change
crypto algorithms if needed in the future, so algorithm agility must be part
of the story.

> Asymmetric keys
> ===============
> According to schema [1] wrapped asymmetric (i.e. private) key must be stored
> in 'ipaPrivateKey' attribute as DER-encoded EncryptedPrivateKeyInfo structure
> according to RFC 5958 [2].
> 
> It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData part
> of EncryptedPrivateKeyInfo structure so we only have to add algorithm
> identifier, DER-encode the whole thing, and we could be done.

Right.

> I'm not sure where should I stick IV or what happens if default (fixed) IV
> value is left in place...?

We cannot use a fixed IV unless the wrapping algorithm uses an obfuscator within
the data, otherwise you open yourself up for attacks. I expect the IV (if needed)
to be provided by the SoftHSM itself ? If not something sounds broken.

If the IV is fixed for some reason we culd provide the data with a secret confounder
in the first block, but then we would not respect the standard in the first place.

I will try to take a look at RFC 5958 once I am back at home tomorrow.

> Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with
> AES according to RFC 3394 (no padding) or RFC 5649 (with padding).
> 
> RFC 3394 works only on blocks of 64 bits, which is not our case because
> EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get
> proper padding etc.

We could also define how we generate padding ourselves if RFC 3394 is easier,
although of course using RFC 5649 wuld be preferable rather than massaging the data
ourselves.

> And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but
> OpenSSL doesn't support RFC 5649! The patch with this functionality was
> submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state
> "new" and there was no reply to the e-mail in the original thread [4].
> 
> What do we do?
> - Convince OpenSSL to review and accept the patch?

If we are using a standard this is not as important, we can make our own
implementation and then work with the OpenSSL community to get a proper implementation
in. Does NSS implements it btw ?

> - Hack it around #0: Use something else as key wrapping method? Other
> wrapping
> methods would require SoftHSM modification because SoftHSM supports only AES
> mechanisms now.
> - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a
> downstream
> patch in SoftHSM? Do we have enough expertise to implement it correctly?
> - Hack it around #2: Implement raw key extraction from SoftHSM and do key
> wrapping somehow somewhere? (Please nooooooo.)

No, let's use standards where they exist, it is ok to make our own implementation until
upstream libraries finally get a good one, but let's avoid completely custom stuff.

> Symmetric keys
> ==============
> should be stored in 'ipaSecretKey' attribute but detailed storage format
> definition is missing from schema [1] right now.
> 
> Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with
> asymmetric key as *wrapping* key so we need to add this functionality.
> 
> The first question is:
> What algorithm and padding scheme should we use?

We need algorithm agility here too, so I would use some generic envelope mechanism
defined for encrypting data with asymetric keys and use it. If it is a good mechanism
it will allow to use multiple algorithms and key sizes etc..

> Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]? That would be relatively
> easy to implement to SoftHSM because it is already there, just not handled in
> C_WrapKey (so we need to add appropriate 'glue' there).

I would not use something that ties us to RSA keys, it is probably highly desirable to
use EC keys too as an alternative.

> Another question is storage format of the wrapped key.
> PKCS#11 2.40d2 [7] contains this comment about "PKCS #1 RSA OAEP" algorithm:
> "For wrapping, the “input” to the encryption operation is the value of the
> CKA_VALUE attribute of the key that is wrapped; similarly for unwrapping. The
> mechanism does not wrap the key type or any other information about the key,
> except the key length; the application must convey these separately."
> 
> AFAIK it means that it wraps raw secret key and nothing else. If I'm not
> wrong
> we should be able to take resulting blob and stick it into OneSymmetricKey
> structure from RFC 6031 [5]. Honza, is it correct assumption/idea?

As long as we have a place to stick in what standard as used so we can change it if
needs be then I do not have a strong preference.

> I would really appreciate any suggestions or comments on this.
> 
> Thank you for your time.
> 
> [0] https://www.redhat.com/archives/freeipa-devel/2014-April/msg00565.html
> [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2
> [2] http://tools.ietf.org/html/rfc5958#section-3
> [3] http://rt.openssl.org/Ticket/Display.html?id=2204
> [4] http://marc.info/?l=openssl-dev&m=126953517430167&w=2
> [5] https://tools.ietf.org/html/rfc6031#section-2
> [6] https://www.openssl.org/docs/crypto/RSA_public_encrypt.html
> [7]
> http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/csprd02/pkcs11-curr-v2.40-csprd02.html#_Toc387327841