[openssl-users] Unable to decrypt CMS object encrypted with EC prime256v1 certificate

[Dr. Stephen Henson]

On Wed, Jul 06, 2016, Stephan M?hlstrasser wrote:

> Am 06.07.16 um 05:15 schrieb Dr. Stephen Henson:
> >...
> >>Is the CMS object broken, or is this a problem in OpenSSL?
> >>
> >
> >Well the OpenSSL version does interop OK with the Bouncy Castle version of
> >ECDH and CMS. I've checked through your test message and the problem is that
> >the AES unwrapping algorithm checks fail meaning it can't proceed any further.
> >That could be down to a CMS problem, an ECDH issue or a problem with the wrap
> >algorithm either in the version you are testing or OpenSSL.
> >
> >Is it possible to get any debugging information from the other version you are
> >using: for example the content encryption key it is expecting or the ECDH
> >shared secret?
> 
> I don't know whether that is possible, I will check.
> 
> >Have you tried generating an message with OpenSSL and decrypting it with the
> >other version?
> 
> Yes, the other version cannot decrypt the CMS object generated by
> OpenSSL. I did some tests with Bouncy Castle, and it also cannot
> decrypt the CMS object.
> 
> What might be interesting is that on the other hand Windows
> CryptoAPI is able to decrypt the CMS object (tested on Windows 10).
> 

Just to clarify: you're saying that neither this third party version nor
BouncyCastler can decrypt the OpenSSL generated CMS objects?

> While doing research on this, we found one thing that looks
> suspicious in the CMS objects generated by OpenSSL 1.0.2. When
> dumping the CMS object with dumpasn1, the key wrap algorithm is
> encoded as follows:
> 
> SEQUENCE {
>  OBJECT IDENTIFIER '1 3 132 1 11 3'
>  SEQUENCE {
>    OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
>    NULL
>    }
>  }
> 
> Note the NULL parameter in the aes256-wrap algorithm identifier.
> Compare that to RFC 3565, "2.3.2.  AES CEK Wrap Process":
> 
> https://tools.ietf.org/html/rfc3565#section-2.3.2
> 
> "In all cases the parameters field MUST be absent."
> 
> Does this refer to the parameters field of the AlgorithmIdentifier
> of the AES key wrap algorithm? Then it would be incorrect to include
> the NULL here.
> 

I'll check. That looks like a bug as the code should be excluding the NULL.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org