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
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
