Strict Public Key checking leads to broken certificates

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Strict Public Key checking leads to broken certificates

Eckenfels. Bernd
Hello,

With BC 1.56 additional verification for RSA public key components have been added. This is similar to the stricter DER parsing introduced by Oracle in 8u121 JCE (CVE-2016-5546).

We encounter a larger number of certificates with problems. Redundant leading zeros are unfortunately common amongst self signed certificates and there is even a commercial German CA (Datev) who produced broken RSA keys.

Are there any plans to make this optional/configurable?

I am not completely sure about Oracles reverting change either, because for 8u141 (and 8u131b31 as well as Java 9 and 10) it is claimed that the stricter test is only done for signatures however they verify the self signed signatures on the carts perfectly fine). https://bugs.openjdk.java.net/browse/JDK-8175251


Gruss
Bernd
--
http://www.seeburger.com








SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strict Public Key checking leads to broken certificates

David Hook-3

I guess the first thing to point out is that this is not a BER/DER issue. The rule now being enforced for INTEGER and ENUMERATED is stated in ISO/IEC 8825-1:2003 (E), Section 8.3, specifically 8.3.2 which says

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.

There is a version of the standard available at:

https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

Section 8 is about BER. There is only one correct way to encode an INTEGER or ENUMERATED, the comments in JDK-8175251 are, put politely, a fantasy.

So please pass that on.

The second thing, it's starting to sound like we may have to make this configurable (I'd hope this would be temporary, but I am starting to have my doubts). CVE-2016-5546, while it touches on this issue (as I said, there is only one way of encoding an INTEGER even in BER), isn't actually the reason for this change, although it affects the DER encoding of INTEGER/ENUMERATED as people that do not understand how to encode INTEGER/ENUMERATED correctly in general, do not generally encode them properly in DER either. The real issue is that broken encodings have been used to break both signature mechanisms and signed data in the past, while nothing specific has come up related to exploiting incorrect encodings of integers primitives (at least that I am aware of), it seems obvious now that it is only a matter of time before someone finds a way.

Anyway, if we are going to add a org.bouncycastle.asn1.allow_unsafe_integer property, I'd like to at least limit the amount of damage it can do further down the track by placing some restriction on just how broken an encoding we are willing to accept if the property is set to true.

Would you be able to email me (off list) a representative sample of the problem certificates?

My impression to date, where I have run into this myself, is that generally the extra bytes are  added on to bring the primitive's value encoding to a 32 bit boundary. Assuming that is the case we may be able to deal with this by allowing for up to 3/4 extra bytes in the encoding if the  allow_unsafe_integer property has been set to true. Anything more than that we can probably assume is because of someone being up to mischief.

If anyone has any further questions, please let me know.

Regards,

David

On 28/06/17 01:45, Eckenfels. Bernd wrote:
Hello,

With BC 1.56 additional verification for RSA public key components have been added. This is similar to the stricter DER parsing introduced by Oracle in 8u121 JCE (CVE-2016-5546).

We encounter a larger number of certificates with problems. Redundant leading zeros are unfortunately common amongst self signed certificates and there is even a commercial German CA (Datev) who produced broken RSA keys.

Are there any plans to make this optional/configurable?

I am not completely sure about Oracles reverting change either, because for 8u141 (and 8u131b31 as well as Java 9 and 10) it is claimed that the stricter test is only done for signatures however they verify the self signed signatures on the carts perfectly fine). https://bugs.openjdk.java.net/browse/JDK-8175251


Gruss
Bernd
--
http://www.seeburger.com








SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Strict Public Key checking leads to broken certificates

Eckenfels. Bernd
Hello and thanks David,

I sent the samples off-list, all of them have only one additional 0byte, but it could be indeed also 32bit for the public exponent (00010001). I am still checking other customer reports but I think allowing a single byte would be enough.

Maybe it should be different for parsing/reading/instantiation and actual verification. Because for example when offering a tool which alerts about format problems it would be nice to use a ASN.1 parser in lenient mode.

BTW all cents I have seen calculate the certification on the broken bytes, none of them use a normalized form but transfer redundant bytes.

Instead of a system property (or in addition to it)  I think an own algorithm type for a lenient CertificateFactory.getInstance("X.509unsafe","BC") could also help (however I am not sure where parsing decisions are done without the instance).

Gruss
Bernd
--
http://www.seeburger.com
________________________________________
From: David Hook [[hidden email]]
Sent: Tuesday, June 27, 2017 21:44
To: Eckenfels. Bernd; [hidden email]
Subject: Re: [dev-crypto] Strict Public Key checking leads to broken certificates

I guess the first thing to point out is that this is not a BER/DER issue. The rule now being enforced for INTEGER and ENUMERATED is stated in ISO/IEC 8825-1:2003 (E), Section 8.3, specifically 8.3.2 which says

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.

There is a version of the standard available at:

https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

Section 8 is about BER. There is only one correct way to encode an INTEGER or ENUMERATED, the comments in JDK-8175251 are, put politely, a fantasy.

So please pass that on.

The second thing, it's starting to sound like we may have to make this configurable (I'd hope this would be temporary, but I am starting to have my doubts). CVE-2016-5546, while it touches on this issue (as I said, there is only one way of encoding an INTEGER even in BER), isn't actually the reason for this change, although it affects the DER encoding of INTEGER/ENUMERATED as people that do not understand how to encode INTEGER/ENUMERATED correctly in general, do not generally encode them properly in DER either. The real issue is that broken encodings have been used to break both signature mechanisms and signed data in the past, while nothing specific has come up related to exploiting incorrect encodings of integers primitives (at least that I am aware of), it seems obvious now that it is only a matter of time before someone finds a way.

Anyway, if we are going to add a org.bouncycastle.asn1.allow_unsafe_integer property, I'd like to at least limit the amount of damage it can do further down the track by placing some restriction on just how broken an encoding we are willing to accept if the property is set to true.

Would you be able to email me (off list) a representative sample of the problem certificates?

My impression to date, where I have run into this myself, is that generally the extra bytes are  added on to bring the primitive's value encoding to a 32 bit boundary. Assuming that is the case we may be able to deal with this by allowing for up to 3/4 extra bytes in the encoding if the  allow_unsafe_integer property has been set to true. Anything more than that we can probably assume is because of someone being up to mischief.

If anyone has any further questions, please let me know.

Regards,

David

On 28/06/17 01:45, Eckenfels. Bernd wrote:

Hello,

With BC 1.56 additional verification for RSA public key components have been added. This is similar to the stricter DER parsing introduced by Oracle in 8u121 JCE (CVE-2016-5546).

We encounter a larger number of certificates with problems. Redundant leading zeros are unfortunately common amongst self signed certificates and there is even a commercial German CA (Datev) who produced broken RSA keys.

Are there any plans to make this optional/configurable?

I am not completely sure about Oracles reverting change either, because for 8u141 (and 8u131b31 as well as Java 9 and 10) it is claimed that the stricter test is only done for signatures however they verify the self signed signatures on the carts perfectly fine). https://bugs.openjdk.java.net/browse/JDK-8175251


Gruss
Bernd
--
http://www.seeburger.com








SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]<mailto:[hidden email]>               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.












SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Strict Public Key checking leads to broken certificates

Eckenfels. Bernd
Hello,

Just BTW there is a fix for this in IBM JDKs 8.0.4.5 (introduced by 8.0.4.1 which is on u121 level) which allows to use -Dcom.ibm.security.EnforceStrictDER=false as documented in IV94326 (and yes they also speak about DER) https://www.ibm.com/developerworks/java/jdk/fixes/8/index.html#SR4FP5

--
http://www.seeburger.com
________________________________________
From: Eckenfels. Bernd [[hidden email]]
Sent: Tuesday, June 27, 2017 23:21
To: [hidden email]
Subject: RE: [dev-crypto] Strict Public Key checking leads to broken certificates

Hello and thanks David,

I sent the samples off-list, all of them have only one additional 0byte, but it could be indeed also 32bit for the public exponent (00010001). I am still checking other customer reports but I think allowing a single byte would be enough.

Maybe it should be different for parsing/reading/instantiation and actual verification. Because for example when offering a tool which alerts about format problems it would be nice to use a ASN.1 parser in lenient mode.

BTW all cents I have seen calculate the certification on the broken bytes, none of them use a normalized form but transfer redundant bytes.

Instead of a system property (or in addition to it)  I think an own algorithm type for a lenient CertificateFactory.getInstance("X.509unsafe","BC") could also help (however I am not sure where parsing decisions are done without the instance).

Gruss
Bernd
--
http://www.seeburger.com
________________________________________
From: David Hook [[hidden email]]
Sent: Tuesday, June 27, 2017 21:44
To: Eckenfels. Bernd; [hidden email]
Subject: Re: [dev-crypto] Strict Public Key checking leads to broken certificates

I guess the first thing to point out is that this is not a BER/DER issue. The rule now being enforced for INTEGER and ENUMERATED is stated in ISO/IEC 8825-1:2003 (E), Section 8.3, specifically 8.3.2 which says

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.

There is a version of the standard available at:

https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

Section 8 is about BER. There is only one correct way to encode an INTEGER or ENUMERATED, the comments in JDK-8175251 are, put politely, a fantasy.

So please pass that on.

The second thing, it's starting to sound like we may have to make this configurable (I'd hope this would be temporary, but I am starting to have my doubts). CVE-2016-5546, while it touches on this issue (as I said, there is only one way of encoding an INTEGER even in BER), isn't actually the reason for this change, although it affects the DER encoding of INTEGER/ENUMERATED as people that do not understand how to encode INTEGER/ENUMERATED correctly in general, do not generally encode them properly in DER either. The real issue is that broken encodings have been used to break both signature mechanisms and signed data in the past, while nothing specific has come up related to exploiting incorrect encodings of integers primitives (at least that I am aware of), it seems obvious now that it is only a matter of time before someone finds a way.

Anyway, if we are going to add a org.bouncycastle.asn1.allow_unsafe_integer property, I'd like to at least limit the amount of damage it can do further down the track by placing some restriction on just how broken an encoding we are willing to accept if the property is set to true.

Would you be able to email me (off list) a representative sample of the problem certificates?

My impression to date, where I have run into this myself, is that generally the extra bytes are  added on to bring the primitive's value encoding to a 32 bit boundary. Assuming that is the case we may be able to deal with this by allowing for up to 3/4 extra bytes in the encoding if the  allow_unsafe_integer property has been set to true. Anything more than that we can probably assume is because of someone being up to mischief.

If anyone has any further questions, please let me know.

Regards,

David

On 28/06/17 01:45, Eckenfels. Bernd wrote:

Hello,

With BC 1.56 additional verification for RSA public key components have been added. This is similar to the stricter DER parsing introduced by Oracle in 8u121 JCE (CVE-2016-5546).

We encounter a larger number of certificates with problems. Redundant leading zeros are unfortunately common amongst self signed certificates and there is even a commercial German CA (Datev) who produced broken RSA keys.

Are there any plans to make this optional/configurable?

I am not completely sure about Oracles reverting change either, because for 8u141 (and 8u131b31 as well as Java 9 and 10) it is claimed that the stricter test is only done for signatures however they verify the self signed signatures on the carts perfectly fine). https://bugs.openjdk.java.net/browse/JDK-8175251


Gruss
Bernd
--
http://www.seeburger.com








SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]<mailto:[hidden email]>               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.












SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.








SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strict Public Key checking leads to broken certificates

David Hook-3
I don't know if I would really describe it as a fix...

At any rate, we have added the
org.bouncycastle.asn1.allow_unsafe_integer property to the current beta.
I think it will deal with the current set of incorrect encodings - a
single extra sign byte, and also ones where the sign extension has been
extended to make up a 32 bit word. If the property is set to true the
ASN.1 parser will loosen the validation rules applied to INTEGER or
ENUMERATED types.

It's now up on https://www.bouncycastle.org/betas version 158b08 or later.

Regards,

David

On 28/06/17 08:02, Eckenfels. Bernd wrote:

> Hello,
>
> Just BTW there is a fix for this in IBM JDKs 8.0.4.5 (introduced by 8.0.4.1 which is on u121 level) which allows to use -Dcom.ibm.security.EnforceStrictDER=false as documented in IV94326 (and yes they also speak about DER) https://www.ibm.com/developerworks/java/jdk/fixes/8/index.html#SR4FP5
>
> --
> http://www.seeburger.com
> ________________________________________
> From: Eckenfels. Bernd [[hidden email]]
> Sent: Tuesday, June 27, 2017 23:21
> To: [hidden email]
> Subject: RE: [dev-crypto] Strict Public Key checking leads to broken certificates
>
> Hello and thanks David,
>
> I sent the samples off-list, all of them have only one additional 0byte, but it could be indeed also 32bit for the public exponent (00010001). I am still checking other customer reports but I think allowing a single byte would be enough.
>
> Maybe it should be different for parsing/reading/instantiation and actual verification. Because for example when offering a tool which alerts about format problems it would be nice to use a ASN.1 parser in lenient mode.
>
> BTW all cents I have seen calculate the certification on the broken bytes, none of them use a normalized form but transfer redundant bytes.
>
> Instead of a system property (or in addition to it)  I think an own algorithm type for a lenient CertificateFactory.getInstance("X.509unsafe","BC") could also help (however I am not sure where parsing decisions are done without the instance).
>
> Gruss
> Bernd
> --
> http://www.seeburger.com
> ________________________________________
> From: David Hook [[hidden email]]
> Sent: Tuesday, June 27, 2017 21:44
> To: Eckenfels. Bernd; [hidden email]
> Subject: Re: [dev-crypto] Strict Public Key checking leads to broken certificates
>
> I guess the first thing to point out is that this is not a BER/DER issue. The rule now being enforced for INTEGER and ENUMERATED is stated in ISO/IEC 8825-1:2003 (E), Section 8.3, specifically 8.3.2 which says
>
> 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.
>
> There is a version of the standard available at:
>
> https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
>
> Section 8 is about BER. There is only one correct way to encode an INTEGER or ENUMERATED, the comments in JDK-8175251 are, put politely, a fantasy.
>
> So please pass that on.
>
> The second thing, it's starting to sound like we may have to make this configurable (I'd hope this would be temporary, but I am starting to have my doubts). CVE-2016-5546, while it touches on this issue (as I said, there is only one way of encoding an INTEGER even in BER), isn't actually the reason for this change, although it affects the DER encoding of INTEGER/ENUMERATED as people that do not understand how to encode INTEGER/ENUMERATED correctly in general, do not generally encode them properly in DER either. The real issue is that broken encodings have been used to break both signature mechanisms and signed data in the past, while nothing specific has come up related to exploiting incorrect encodings of integers primitives (at least that I am aware of), it seems obvious now that it is only a matter of time before someone finds a way.
>
> Anyway, if we are going to add a org.bouncycastle.asn1.allow_unsafe_integer property, I'd like to at least limit the amount of damage it can do further down the track by placing some restriction on just how broken an encoding we are willing to accept if the property is set to true.
>
> Would you be able to email me (off list) a representative sample of the problem certificates?
>
> My impression to date, where I have run into this myself, is that generally the extra bytes are  added on to bring the primitive's value encoding to a 32 bit boundary. Assuming that is the case we may be able to deal with this by allowing for up to 3/4 extra bytes in the encoding if the  allow_unsafe_integer property has been set to true. Anything more than that we can probably assume is because of someone being up to mischief.
>
> If anyone has any further questions, please let me know.
>
> Regards,
>
> David
>
> On 28/06/17 01:45, Eckenfels. Bernd wrote:
>
> Hello,
>
> With BC 1.56 additional verification for RSA public key components have been added. This is similar to the stricter DER parsing introduced by Oracle in 8u121 JCE (CVE-2016-5546).
>
> We encounter a larger number of certificates with problems. Redundant leading zeros are unfortunately common amongst self signed certificates and there is even a commercial German CA (Datev) who produced broken RSA keys.
>
> Are there any plans to make this optional/configurable?
>
> I am not completely sure about Oracles reverting change either, because for 8u141 (and 8u131b31 as well as Java 9 and 10) it is claimed that the stricter test is only done for signatures however they verify the self signed signatures on the carts perfectly fine). https://bugs.openjdk.java.net/browse/JDK-8175251
>
>
> Gruss
> Bernd
> --
> http://www.seeburger.com
>
>
>
>
>
>
>
>
> SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
> Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
> Edisonstr. 1
> D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
> Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
> Fax: 07252 / 96 - 2222
> Internet: http://www.seeburger.de               Registergericht/Commercial Register:
> e-mail: [hidden email]<mailto:[hidden email]>               HRB 240708 Mannheim
>
>
> Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.
>
>
> This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.
>
>
>
>
>
>
>
>
>
>
>
>
> SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
> Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
> Edisonstr. 1
> D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
> Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
> Fax: 07252 / 96 - 2222
> Internet: http://www.seeburger.de               Registergericht/Commercial Register:
> e-mail: [hidden email]               HRB 240708 Mannheim
>
>
> Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.
>
>
> This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.
>
>
>
>
>
>
>
>
> SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
> Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
> Edisonstr. 1
> D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
> Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
> Fax: 07252 / 96 - 2222
> Internet: http://www.seeburger.de               Registergericht/Commercial Register:
> e-mail: [hidden email]               HRB 240708 Mannheim
>
>
> Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.
>
>
> This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.
>
>
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Strict Public Key checking leads to broken certificates

Eckenfels. Bernd
Hello David,

we can confirm that the Beta 08 with the system property allows us to use the broken certificates again. Thanks a lot for the fast reply. Could you push your pending changes so we can verify that the upgrade 1.57>1.58 is otherwise fine with us.

Gruss
Bernd

-----Original Message-----
From: David Hook [mailto:[hidden email]]
Sent: Wednesday, June 28, 2017 8:31 AM
To: Eckenfels. Bernd; [hidden email]
Subject: Re: [dev-crypto] Strict Public Key checking leads to broken certificates

I don't know if I would really describe it as a fix...

At any rate, we have added the
org.bouncycastle.asn1.allow_unsafe_integer property to the current beta.
I think it will deal with the current set of incorrect encodings - a
single extra sign byte, and also ones where the sign extension has been
extended to make up a 32 bit word. If the property is set to true the
ASN.1 parser will loosen the validation rules applied to INTEGER or
ENUMERATED types.

It's now up on https://www.bouncycastle.org/betas version 158b08 or later.

Regards,

David








SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strict Public Key checking leads to broken certificates

Andreas Schildbach
In reply to this post by David Hook-3
On 06/27/2017 09:44 PM, David Hook wrote:

> Would you be able to email me (off list) a representative sample of the
> problem certificates?

Here is another example:

0xffda47bfc776bcd269da4832626ac332adfca6dd835e8ecd83cd1ebe7d709b0e

It's a Bitcoin ECDSA signature that is contained in the (public) unit
tests and in the Bitcoin blockchain for all eternity.

https://github.com/bitcoin/bitcoin/blob/master/src/test/data/tx_valid.json#L47
https://blockexplorer.com/tx/406b2b06bcd34d3c8733e6b79f7a394c8a431fbf4ff5ac705c93f4076bb77602


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strict Public Key checking leads to broken certificates

Andreas Schildbach
In reply to this post by David Hook-3
Thanks for adding the system property. However, I wonder how I can
enable this property per thread or per call? The reason is that some
Bitcoin signatures need that check, and some don't.

More info: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki


On 06/28/2017 08:31 AM, David Hook wrote:

> I don't know if I would really describe it as a fix...
>
> At any rate, we have added the
> org.bouncycastle.asn1.allow_unsafe_integer property to the current beta.
> I think it will deal with the current set of incorrect encodings - a
> single extra sign byte, and also ones where the sign extension has been
> extended to make up a 32 bit word. If the property is set to true the
> ASN.1 parser will loosen the validation rules applied to INTEGER or
> ENUMERATED types.
>
> It's now up on https://www.bouncycastle.org/betas version 158b08 or later.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strict Public Key checking leads to broken certificates

David Hook-3

There might be a way of adding this as thread local somewhere.

We'll have to think about this one. I'll have to get back to you on this one.

Regards,

David

On 01/07/17 07:24, Andreas Schildbach wrote:
Thanks for adding the system property. However, I wonder how I can
enable this property per thread or per call? The reason is that some
Bitcoin signatures need that check, and some don't.

More info: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki


On 06/28/2017 08:31 AM, David Hook wrote:
I don't know if I would really describe it as a fix...

At any rate, we have added the
org.bouncycastle.asn1.allow_unsafe_integer property to the current beta.
I think it will deal with the current set of incorrect encodings - a
single extra sign byte, and also ones where the sign extension has been
extended to make up a 32 bit word. If the property is set to true the 
ASN.1 parser will loosen the validation rules applied to INTEGER or
ENUMERATED types.

It's now up on https://www.bouncycastle.org/betas version 158b08 or later.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strict Public Key checking leads to broken certificates

Eckenfels. Bernd

Hello,

 

one option ist to turn off the strict checking with the system property and inspect the encoded bytes yourself, so you can decide what you want to accept or not.

 

David, the Oracle CPU on July 18th (8u141) will solve the problem for the SunJCE provider. Do you think it would be possible to get a release by then (as in our case we need fixes from both parties)?

 

(But having a thread context configuration sometime feels to me better than a system property, but then maybe the setting needs to be able to differentiate between normal signature and signatures for certificate chain checkin and signing?)

 

Gruss

Bernd

 

 

From: David Hook [mailto:[hidden email]]
Sent: Friday, June 30, 2017 11:37 PM
To: [hidden email]
Subject: Re: [dev-crypto] Re: Strict Public Key checking leads to broken certificates

 

 

There might be a way of adding this as thread local somewhere.
 
We'll have to think about this one. I'll have to get back to you on this one.
 
Regards,
 
David


On 01/07/17 07:24, Andreas Schildbach wrote:

Thanks for adding the system property. However, I wonder how I can
enable this property per thread or per call? The reason is that some
Bitcoin signatures need that check, and some don't.
 
More info: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
 
 
On 06/28/2017 08:31 AM, David Hook wrote:
I don't know if I would really describe it as a fix...
 
At any rate, we have added the
org.bouncycastle.asn1.allow_unsafe_integer property to the current beta.
I think it will deal with the current set of incorrect encodings - a
single extra sign byte, and also ones where the sign extension has been
extended to make up a 32 bit word. If the property is set to true the 
ASN.1 parser will loosen the validation rules applied to INTEGER or
ENUMERATED types.
 
It's now up on https://www.bouncycastle.org/betas version 158b08 or later.
 
 
 

 






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1  
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0 Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: [hidden email] HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strict Public Key checking leads to broken certificates

Andreas Schildbach
In reply to this post by David Hook-3
Thanks David!

The more I think about this, the more I'm convinced this setting should
be thread- or call-level only. That is, if this check is security
relevant at all (which I don't know, I'm only assuming).

By setting the system property, you disable the check for all purposes
of the library. This can have unexpected side effects, like running code
from a library (which perhaps uses BC as well) with reduced security.


On 06/30/2017 11:36 PM, David Hook wrote:

>
> There might be a way of adding this as thread local somewhere.
>
> We'll have to think about this one. I'll have to get back to you on this one.
>
> Regards,
>
> David
>
>
> On 01/07/17 07:24, Andreas Schildbach wrote:
>> Thanks for adding the system property. However, I wonder how I can
>> enable this property per thread or per call? The reason is that some
>> Bitcoin signatures need that check, and some don't.
>>
>> More info: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
>>
>>
>> On 06/28/2017 08:31 AM, David Hook wrote:
>>> I don't know if I would really describe it as a fix...
>>>
>>> At any rate, we have added the
>>> org.bouncycastle.asn1.allow_unsafe_integer property to the current beta.
>>> I think it will deal with the current set of incorrect encodings - a
>>> single extra sign byte, and also ones where the sign extension has been
>>> extended to make up a 32 bit word. If the property is set to true the
>>> ASN.1 parser will loosen the validation rules applied to INTEGER or
>>> ENUMERATED types.
>>>
>>> It's now up on https://www.bouncycastle.org/betas version 158b08 or later.
>>
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strict Public Key checking leads to broken certificates

Andreas Schildbach
In reply to this post by Eckenfels. Bernd
On 07/03/2017 12:57 PM, Eckenfels. Bernd wrote:

> oneoption ist to turn off the strict checking with the system property
> and inspect the encoded bytes yourself, so you can decide what you want
> to accept or not.

Note this only works if its your own code. But others users of the
library are affected too, if they are running in the same VM.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strict Public Key checking leads to broken certificates

David Hook-3
In reply to this post by Andreas Schildbach

We're looking into making it thread local as well.

Just to clarify we're not aware of anyone deliberately exploiting this
at the moment, and even our current definition of "reduced security" is
still a lot tighter than it was before. That said, the past few years
have seen attacks based on exploiting ASN.1 parsing errors and, more
relevantly, parsers ignoring actual errors. Finding things which can be
tweaked without changing appearances is also the first step in trying to
associate fake data with a real signature. Anything which can be done to
close of these avenues of mischief now is good thing.

We are not in the land of be "rigorous with what you produce, graceful
about what you will accept" anymore, like the days of the pre-spam
Internet, I am afraid those days are well gone now.

Regards,

David

On 03/07/17 21:34, Andreas Schildbach wrote:

> Thanks David!
>
> The more I think about this, the more I'm convinced this setting should
> be thread- or call-level only. That is, if this check is security
> relevant at all (which I don't know, I'm only assuming).
>
> By setting the system property, you disable the check for all purposes
> of the library. This can have unexpected side effects, like running code
> from a library (which perhaps uses BC as well) with reduced security.
>
>
> On 06/30/2017 11:36 PM, David Hook wrote:
>> There might be a way of adding this as thread local somewhere.
>>
>> We'll have to think about this one. I'll have to get back to you on this one.
>>
>> Regards,
>>
>> David
>>
>>
>> On 01/07/17 07:24, Andreas Schildbach wrote:
>>> Thanks for adding the system property. However, I wonder how I can
>>> enable this property per thread or per call? The reason is that some
>>> Bitcoin signatures need that check, and some don't.
>>>
>>> More info: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
>>>
>>>
>>> On 06/28/2017 08:31 AM, David Hook wrote:
>>>> I don't know if I would really describe it as a fix...
>>>>
>>>> At any rate, we have added the
>>>> org.bouncycastle.asn1.allow_unsafe_integer property to the current beta.
>>>> I think it will deal with the current set of incorrect encodings - a
>>>> single extra sign byte, and also ones where the sign extension has been
>>>> extended to make up a 32 bit word. If the property is set to true the
>>>> ASN.1 parser will loosen the validation rules applied to INTEGER or
>>>> ENUMERATED types.
>>>>
>>>> It's now up on https://www.bouncycastle.org/betas version 158b08 or later.
>
>
>



Loading...