[Freeipa-devel] DNSSEC key wrapping: cryptographer needed

[Simo Sorce]

On Tue, 2014-06-24 at 20:30 +0200, Petr Spacek wrote:
> On 24.6.2014 15:45, Tomas Mraz wrote:
> >> >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].
> > I am sorry, but this does not make much sense to me. Iff the SoftHSM's
> > C_WrapKey is really safe wrapping method for backing up and/or
> > replicating HSM's it must provide wrapped key in such format that the IV
> > is pregenerated as part of the Wrap operation and stored in the final
> > blob of wrapped key. Unfortunately I do not know much of SoftHSM.
> SoftHSM is "just" PKCS#11 interface implementation so SoftHSM can't do 
> something against PKCS#11 standard.
> 
> In this case the standard says that user has to provide IV explicitly and the 
> C_WrapKey should fall-back to standardized default if IV was not given by user.

Sounds completely bogus, but in this case we'll have to either provide a
random IV ourselves (and then store it alongside or provide data with a
confounder at the start implementing padding on our own.

> See section "6.13.3 AES Key Wrap" in "PKCS #11 Mechanisms v2.30: Cryptoki – 
> Draft 7" on
> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf
> 
> >
> >> >What do we do?
> >> >- Convince OpenSSL to review and accept the patch?
> > I would say the patch is not too useful as is - there are multiple
> > problems with it such as it is not using proper high level interfaces
> > for the AES encryption, etc.
> Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different from 
> the 2010-version. I didn't notice it.
> 
> Would you review the patch if we re-write it against current OpenSSL git head?
> 


-- 
Simo Sorce * Red Hat, Inc * New York