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

[Stephan Mühlstrasser]

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

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.

-- 
Stephan