Re: [openssl-users] Certificate verification fails with latest commits (ECDSA)
Summary of thread so far: The latest security update enforces that any inherently unsigned BIGNUM must be encoded as a non- negative DER INTEGER (which has a leading 0 byte if the most significant bit of the first byte would otherwise be set). It is a well known historic bug that some other ASN.1 libraries incorrectly treat the DER/BER INTEGER type as unsigned when encoding and decoding inherently unsigned numbers, and that such libraries will thus accept the correct encoding (leading 0 byte) as a non-canonical BER encoding (and thankfully forget to normalize it to the wrong form), while producing an incorrect encoding without the leading 0 byte. Historically, OpenSSL (and probably some other ASN.1 libraries too) have intentionally tolerated this specific incorrect encoding, but the new security update now consistently rejects it. Would it reintroduce the related security issue to explicitly tolerate the alternative encoding, perhaps by allowing the EC code to accept negative numbers as their unsigned encoding equivalents, while preserving the signed form when round-tripping BER to BN to DER. (This of cause would still fail if the most significant 9 bits were all 1, e.g. 0xFF8, but that would still be 256 times rarer). I am assuming without checking, that i2d_ASN1_INTEGER already handles negative values. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Certificate verification fails with latest commits (ECDSA)
On Tue, Feb 03, 2015, jan.w...@ptb.de wrote:
This check fails for some of our certificates and the reason is that
openssl adds a padding byte for BIGNUMs in crypto/asn1/x_bignum.c if the
MSB is set. Our encoding does not contain these padding bytes and,
consequently, the re-encoded version of our certificate signature is two
bytes longer than before which results in an error.
RFC3279 defines
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
I've looked up the DER encoding rules for INTEGER here
http://www.itu.int/rec/T-REC-X.690-200811-I
and I can't find any evidence that this padding byte is mandatory. See
below for the relevant paragraph.
The MSB is effectively a sign bit but the explanation in the standard isn't
very clear. If you take your example of GTS001.pem and do:
openssl asn1parse -in GTS001.pem -strparse 367 -out sig.der
It will parse out the Ecdsa-Sig-Value field and you get:
0:d=0 hl=2 l= 52 cons: SEQUENCE
2:d=1 hl=2 l= 24 prim: INTEGER
:-0739E1C1762E2E3E1D4480425633EA0BB669CE784DC3ACCB
28:d=1 hl=2 l= 24 prim: INTEGER
:-332658917A3B05831D91176C0512CF91C617819E1A7CF14B
Note the two - signs.
Just to show it isn't just OpenSSL: if you use dumpasn1 on the output (sig.der)
you get:
0 52: SEQUENCE {
2 24: INTEGER
: F8 C6 1E 3E 89 D1 D1 C1 E2 BB 7F BD A9 CC 15 F4
: 49 96 31 87 B2 3C 53 35
: Error: Integer has a negative value.
28 24: INTEGER
: CC D9 A7 6E 85 C4 FA 7C E2 6E E8 93 FA ED 30 6E
: 39 E8 7E 61 E5 83 0E B5
: Error: Integer has a negative value.
: }
From your quote:
The value of the
two's complement binary number is obtained by
summing the numerical values assigned to each bit for those bits which are
set to one, excluding bit 8 of the first octet, and then
reducing this value by the numerical value assigned to bit 8 of the first
octet if that bit is set to one.
What this is saying is that if the MSB is one you subtract that value from
the result.
For example 0x80 without the MSB represents '0' the MSB represents 0x80 and
you subtract that resulting in -0x80. That's why you need the 0 padding byte
prepended if the MSB is one.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Certificate verification fails with latest commits (ECDSA)
Hi,
we have noticed that with the latest Debian wheezy-security update of the
libssl1.0.0 package sudenly the verification of some of our ECDSA-signed
certificates failed.
I've looked into this and I've traced it down to the following patch
https://github.com/openssl/openssl/commit/684400ce192dac51df3d3e92b61830a6ef90be3e
which introduces a new statement to check the length of the DER-coded
signature in ecs_vrf.c:
- if (d2i_ECDSA_SIG(s, sigbuf, sig_len) == NULL) goto err;
+ if (d2i_ECDSA_SIG(s, p, sig_len) == NULL) goto err;
+ /* Ensure signature uses DER and doesn't have trailing garbage */
+ derlen = i2d_ECDSA_SIG(s, der);
+ if (derlen != sig_len || memcmp(sigbuf, der, derlen))
+ goto err;
This check fails for some of our certificates and the reason is that
openssl adds a padding byte for BIGNUMs in crypto/asn1/x_bignum.c if the
MSB is set. Our encoding does not contain these padding bytes and,
consequently, the re-encoded version of our certificate signature is two
bytes longer than before which results in an error.
RFC3279 defines
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
I've looked up the DER encoding rules for INTEGER here
http://www.itu.int/rec/T-REC-X.690-200811-I
and I can't find any evidence that this padding byte is mandatory. See
below for the relevant paragraph.
So my question is: Would you agree that this is an openssl bug or is the
padding byte indeed mandatory and we have to adapt the encoding of our
certificates?
I am attaching one of the certificates for which the verification fails
along with the root ca's certificate.
Cheers,
Jan
X.690 INTEGER:
8.3 Encoding of an integer value
8.3.1 The encoding of an integer value shall be primitive. The contents
octets shall consist of one or more octets.
8.3.2 If the contents octets of an integer value encoding consist of more
than one octet, then the bits of the first
octet and bit 8 of the second octet:
a) shall not all be ones; and
b) shall not all be zero.
NOTE ? These rules ensure that an integer value is always encoded in the
smallest possible number of octets.
8.3.3 The contents octets shall be a two's complement binary number equal
to the integer value, and consisting of
bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second
octet, followed by bits 8 to 1 of each octet in turn up to
and including the last octet of the contents octets.
NOTE ? The value of a two's complement binary number is derived by
numbering the bits in the contents octets, starting with bit
1 of the last octet as bit zero and ending the numbering with bit 8 of the
first octet. Each bit is assigned a numerical value of 2N,
where N is its position in the above numbering sequence. The value of the
two's complement binary number is obtained by
summing the numerical values assigned to each bit for those bits which are
set to one, excluding bit 8 of the first octet, and then
reducing this value by the numerical value assigned to bit 8 of the first
octet if that bit is set to one.
Jan Weil
Physikalisch-Technische Bundesanstalt
Arbeitsgruppe 8.52 Datenkommunikation und -sicherheit
Abbestr. 2 - 12
10587 Berlin
Telefon: (+49 30) 34 81 - 77 64
Fax: (+49 30) 34 81 - 69 77 64
Email: jan.w...@ptb.de
GTS001.pem
Description: Binary data
OSM_ROOT.pem
Description: Binary data
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Certificate verification fails with latest commits (ECDSA)
On Tue, Feb 03, 2015, jan.w...@ptb.de wrote:
This check fails for some of our certificates and the reason is that
openssl adds a padding byte for BIGNUMs in crypto/asn1/x_bignum.c if the
MSB is set. Our encoding does not contain these padding bytes and,
consequently, the re-encoded version of our certificate signature is two
bytes longer than before which results in an error.
RFC3279 defines
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
I've looked up the DER encoding rules for INTEGER here
http://www.itu.int/rec/T-REC-X.690-200811-I
and I can't find any evidence that this padding byte is mandatory. See
below for the relevant paragraph.
The MSB is effectively a sign bit but the explanation in the standard isn't
very clear. If you take your example of GTS001.pem and do:
openssl asn1parse -in GTS001.pem -strparse 367 -out sig.der
It will parse out the Ecdsa-Sig-Value field and you get:
0:d=0 hl=2 l= 52 cons: SEQUENCE
2:d=1 hl=2 l= 24 prim: INTEGER
:-0739E1C1762E2E3E1D4480425633EA0BB669CE784DC3ACCB
28:d=1 hl=2 l= 24 prim: INTEGER
:-332658917A3B05831D91176C0512CF91C617819E1A7CF14B
Note the two - signs.
Just to show it isn't just OpenSSL: if you use dumpasn1 on the output (sig.der)
you get:
0 52: SEQUENCE {
2 24: INTEGER
: F8 C6 1E 3E 89 D1 D1 C1 E2 BB 7F BD A9 CC 15 F4
: 49 96 31 87 B2 3C 53 35
: Error: Integer has a negative value.
28 24: INTEGER
: CC D9 A7 6E 85 C4 FA 7C E2 6E E8 93 FA ED 30 6E
: 39 E8 7E 61 E5 83 0E B5
: Error: Integer has a negative value.
: }
From your quote:
The value of the
two's complement binary number is obtained by
summing the numerical values assigned to each bit for those bits which are
set to one, excluding bit 8 of the first octet, and then
reducing this value by the numerical value assigned to bit 8 of the first
octet if that bit is set to one.
What this is saying is that if the MSB is one you subtract that value from
the result.
For example 0x80 without the MSB represents '0' the MSB represents 0x80 and
you subtract that resulting in -0x80. That's why you need the 0 padding byte
prepended if the MSB is one.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Certificate verification fails with latest commits (ECDSA)
Hi Steve, thanks a lot for your quick response and for the clarification. Von: Dr. Stephen Henson st...@openssl.org The MSB is effectively a sign bit but the explanation in the standard isn't very clear. If you take your example of GTS001.pem and do: openssl asn1parse -in GTS001.pem -strparse 367 -out sig.der It will parse out the Ecdsa-Sig-Value field and you get: 0:d=0 hl=2 l= 52 cons: SEQUENCE 2:d=1 hl=2 l= 24 prim: INTEGER :-0739E1C1762E2E3E1D4480425633EA0BB669CE784DC3ACCB 28:d=1 hl=2 l= 24 prim: INTEGER :-332658917A3B05831D91176C0512CF91C617819E1A7CF14B Note the two - signs. [...] What this is saying is that if the MSB is one you subtract that value from the result. For example 0x80 without the MSB represents '0' the MSB represents 0x80 and you subtract that resulting in -0x80. Well, yes, that's how two's complement works. That's why you need the 0 padding byte prepended if the MSB is one. The actual problem is that I have totally ignored the mathematics of ECs and it only occured to me when I read your reply that the values of r and s, as far as i understand now, can never be negative. Not so good news for our certificates... Thanks again! Jan Jan Weil Physikalisch-Technische Bundesanstalt Arbeitsgruppe 8.52 Datenkommunikation und -sicherheit Abbestr. 2 - 12 10587 Berlin Telefon: (+49 30) 34 81 - 77 64 Fax: (+49 30) 34 81 - 69 77 64 Email: jan.w...@ptb.de ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
