Bonjour,
Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser
<s...@pdflib.com<mailto:s...@pdflib.com>> a écrit :
Hi,
I'm trying to decrypt a DER-encoded CMS object (created by Adobe Acrobat) with
OpenSSL 1.0.2d:
$ openssl cms -decrypt -in recipient.bin -inform DER -inkey atssecp521r1.key
-recip atssecp521r1.pem
Error reading S/MIME message
140735227593552:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
tag:tasn_dec.c:1198:
140735227593552:error:0D06C03A:asn1 encoding
routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:762:
140735227593552:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:tasn_dec.c:694:Field=version, Type=CMS_KeyAgreeRecipientInfo
140735227593552:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:685:
140735227593552:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested
asn1 error:tasn_dec.c:336:Field=d.kari, Type=CMS_RecipientInfo
140735227593552:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:tasn_dec.c:666:Field=recipientInfos, Type=CMS_EnvelopedData
140735227593552:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:
140735227593552:error:0D08403A:asn1 encoding
routines:ASN1_TEMPLATE_EX_D2I:nested asn1
error:tasn_dec.c:557:Field=d.envelopedData, Type=CMS_ContentInfo
The full dumpasn1 output of the file "recipient.bin" is below at the end of the
message. Is this a correct CMS object?
If I compare this to the structure of a CMS object that was generated by
OpenSSL itself, there's a difference in the structure of the RecipientInfos
object. If I understand it correctly, this is the start of the RecipientInfos
object (starting at line 6 of the dumpasn1 output):
SET {
[1] {
SEQUENCE {
INTEGER 3
…
This is the expression of an EXPLICIT tag.
I can match this to the following rules in RFC 5652:
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo }
KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys }
See RFC5652 section 12.1.
These data types are defined in a module with IMPLICIT TAGS (it was changed
between PKCS#7v1.5 and RFC2630), so kari, kekri, pwri, and ori elements are
associated to an IMPLICIT tag.
Additional definition to read the dump.
OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
If I dump a CMS object that was created with OpenSSL's CMS tool with the same
certificate as the problematic one, the structure of the RecipientInfos object
looks like this:
SET {
[1] {
INTEGER 3
…
So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present here.
This is the correct behavior of an IMPLICIT tag.
Another issue in the Acrobat-generated CMS object is the top-level CMSVersion
in the EnvelopedData object being 0. I believe this is wrong and should be 2,
but apparently OpenSSL doesn't care.
Full output of dumpasn1 for "recipient.bin" file:
SEQUENCE {
OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
[0] {
SEQUENCE {
INTEGER 0
SET {
[1] {
SEQUENCE {
This is wrong, the SEQUENCE is to be hidden by the [1] tag.
INTEGER 3
[0] {
The [0] introduces the originator element, of type OriginatorIdentifierOrKey,
it’s EXPLICIT.
[1] {
SEQUENCE {
Also wrong, the [1] here should be IMPLICIT and hide the SEQUENCE tag of the
OriginatorPublicKey structure.
SEQUENCE {
OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
}
BIT STRING
04 01 91 BE 01 63 00 79 C2 D2 95 0F 9D 03 A4 34
5A 9C 2F 98 4A 13 D4 59 C6 EA 6C 4B 6D 7D 2B DC
1C 08 16 86 EF F0 C2 3D AE A4 AF A3 7C 7E 15 80
55 18 06 2C E9 09 19 3A 3A 78 DD 93 F1 33 B1 1E
9A 76 7C 01 1E 8B B6 B0 FE 5E BA FD 04 EE F3 84
3D 47 61 22 D2 A3 AC 1C D4 B8 66 57 94 B1 74 83
B1 4E 7F 2F 64 7F 4F 64 40 6A 1D 02 38 5F FE DF
93 7B 14 6D 5A BF 75 AC 77 CB 47 2B 16 F0 9D C7
[ Another 5 bytes skipped ]
}
}
}
I haven’t checked the rest.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
