[Freeipa-devel] DNSSEC key wrapping: cryptographer needed

[Jan Cholasta]

On 23.6.2014 14:57, Petr Spacek wrote:
> 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.
>
>
> 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.
>
> I'm not sure where should I stick IV or what happens if default (fixed)
> IV value is left in place...?
>
>
> 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.
>
> 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].

Does this mean SoftHSM does not support RFC 5649?

>
> What do we do?
> - Convince OpenSSL to review and accept the patch?
> - 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.)
>
>
> Symmetric keys
> ==============
> should be stored in 'ipaSecretKey' attribute but detailed storage format
> definition is missing from schema [1] right now.

I thought we already agreed on using raw encrypted blob.

>
> 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?

I guess PKCS#1 RSA or PKCS#1 RSA OAEP.

>
> 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).
>
> 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?

What is the benefit of using OneSymmetricKey here? There is no wrapping 
algorithm identifier as in EncryptedPrivateKeyInfo and the whole thing 
looks very PSKC-specific.

>
>
> 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
>
>


-- 
Jan Cholasta