strongSwan - Bug #3589
scepclient invalid encoding of signedAttrs
09.10.2020 15:39 - Marc Garvey

ステータス:

Closed

開始日:

優先度:

Normal

期日:担当者:

Tobias Brunner

予定工数:

0.00時間カテゴリ:

scepclient

対象バージョン:5.9.1

Affected version:

5.8.2

Resolution:

Fixed

説明
Hello,
I tried to use the scepclient command for a scep server project and I found a problem.
The scepclient does not encode the signedAttr of the pkcs#7 container in the correct way.
Because of this invalid encoding, some librarys will fail during the signature check of the message. (In my case bouncycastle)
The signed attributes are defined as a ASN.1 Set
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute[[https://tools.ietf.org/html/rfc5652#section-5.3]]
It also defines for the signature verification
When the field is present, however, the result is the message
digest of the complete DER encoding of the SignedAttrs value
contained in the signedAttrs field. Since the SignedAttrs value,
when present, must contain the content-type and the message-digest
attributes, those values are indirectly included in the result. The
content-type attribute MUST NOT be included in a countersignature
unsigned attribute as defined in Section 11.4. A separate encodingof the signedAttrs field is performed for message digest calculation.
The IMPLICIT [0] tag in the signedAttrs is not used for the DER
encoding, rather an EXPLICIT SET OF tag is used. That is, the DER
encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0]tag, MUST be included in the message digest calculation along withthe length and content octets of the SignedAttributes value.
[[https://tools.ietf.org/html/rfc5652#section-5.4]]
This means that the signed attributes must be encoded as DER structure
The ASN.1 specifikation for an DER Set ist like thisDER encoding. Constructed. Contents octets are the same as for the BER encoding, except that there is an order, namely ascending
lexicographic order of BER encoding[[http://luca.ntop.org/Teaching/Appunti/asn1.html]] 5.15
This is the Dump ASN.1 of the scepclient message (only the part of the signed Attr)

1386
1389
1391
1403
1405

197:
32:
10:
18:
16:

[0]

::
1423
1425

48:
10:14.10.2024{SEQUENCE {OBJECT IDENTIFIER senderNonce (2 16 840 1 113733 1 9 5)SET {OCTET STRING 93 FE A2 E7 AC 57 2B C3 79 DB DE B0}}
SEQUENCE {OBJECT IDENTIFIER transID (2 16 840 1 113733 1 9 7)

1/3

D6

60

1437
1439

34:
32:

SET

:
:
1473
1475
1487
1489

18:
10:
4:
2:
:
:

1493
1495
1506
1508

35:
9:
22:
20:
:
:
:
:

1530
1532
1543
1545

28:
9:
15:
13:
::

1560
1562
1573
1575

24:
9:
11:
9:
:
:
:

{
PrintableString 'C910E32E652D9BB47DEA2236CF16B89D'}}
SEQUENCE {OBJECT IDENTIFIER messageType (2 16 840 1 113733 1 9 2)
SET {PrintableString '19'}}
SEQUENCE {OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 9 4)
SET {OCTET STRING
CA 8A 5D E1 E1 04 6A 44 5B B2 D5 10 34 EE
19 3B 1E F8}}SEQUENCE {OBJECT IDENTIFIER signingTime (1 2 840 113549 1 9 5)
SET {UTCTime 08/10/2020 10:53:49 GMT}}SEQUENCE {OBJECT IDENTIFIER contentType (1 2 840 113549 1 9 3)
SET {OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)}}}

79

DD

3B

1E

This is a dump of the Bouncycastle encoding of the same message which will be used by BC to verify the signature.

0351719232536
3849
51
6264

79
81
93
95

113
115
126
128

150

197: SET {18:SEQUENCE {10:OBJECT IDENTIFIER messageType (2 16 840 1 113733 1 9 2)
4:
SET {
2:
PrintableString '19':}:}
24:
SEQUENCE {9:
OBJECT IDENTIFIER contentType (1 2 840 113549 1 9 3)
11:
SET {
9:
OBJECT IDENTIFIER data (1 2 840 113549 1 7 1):}:}
28:
SEQUENCE {9:
OBJECT IDENTIFIER signingTime (1 2 840 113549 1 9 5)
15:
SET {
13:
UTCTime 08/10/2020 10:53:49 GMT:}:}
32:
SEQUENCE {10:OBJECT IDENTIFIER senderNonce (2 16 840 1 113733 1 9 5)
18:
SET {
16:
OCTET STRING 93 FE A2 E7 AC 57 2B C3 79 DB DE B0 D6 60 57 E7:}:}35:SEQUENCE {9:
OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 9 4)
22:
SET {
20:
OCTET STRING CA 8A 5D E1 E1 04 6A 44 5B B2 D5 10 34 EE 79 DD 19:}:}48:
SEQUENCE {14.10.2024

2/3152
164
166

10:
34:
32:
:::

OBJECT IDENTIFIER transID (2 16 840 1 113733 1 9
SET {PrintableString 'C910E32E652D9BB47DEA2236CF16B89D'}}}7)

You will see that the ordering is different thats why the digest inside the signature is different.
I know exactly that is never a good idea to reencode a ASN.1 message because something like this could happen during thesignature verification, but nevertheless the scep client should encode the message correctly.
Best regardsMarc履歴#1 - 09.10.2020 18:09 - Tobias Brunner- トラッカー を Issue から Bug に変更- カテゴリ を scepclient にセット
- ステータス を New から Feedback に変更- 担当者 を Tobias Brunner にセット
- 対象バージョン を 5.9.1 にセット

I tried to use the scepclient command for a scep server project and I found a problem.
The scepclient does not encode the signedAttr of the pkcs#7 container in the correct way.

Just because I feel I need to mention it, did you read the note on scepclient? But considering that, I wonder why nobody ever noticed this during thelast 15 years. I guess some parsers/servers just accept the SET in any order and use it as it was received when verifying the signature (i.e. without
re-encoding).
DER encoding. Constructed. Contents octets are the same as for the BER encoding, except that there is an order, namely ascending
lexicographic order of BER encoding

ASN.1 is really idiotic sometimes. Let's define SET OF as "an unordered collection of zero or more occurrences of a given type", but then, just for thefun of it, let's order the items when encoding for no apparent reason.
But yeah, that was clearly incorrect. Luckily it seems to be the only place where we encode a SET OF with more than one element. I pushed a fix tothe 3589-pkcs7-attr branch. Let me know if that works for you.
#2 - 12.10.2020 10:34 - Marc Garvey
Hello, yes I have read this notice and I would not open a ticket for a missing feature.
anyways thanks for this fast response. I will check this branch.
#3 - 27.10.2020 11:28 - Tobias Brunner- ステータス を Feedback から Closed に変更- Resolution を Fixed にセット

14.10.2024

3/3