Default SecureRandom issue in BCFIPS and latest JDK15

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Default SecureRandom issue in BCFIPS and latest JDK15

Ioannis Kakavas
Hi there folks,

Simply attempting to get an instance of SecureRandom is failing in recent JDK15ea ( build 29 ) when BouncyCastleFipsProvider is the preferred security provider


minimal reproduction

```
import java.security.SecureRandom;
import java.security.Security;

public class TestSecureRandomBug {

    public static void main(String[] args){
        assert Security.getProviders()[0].getName().equals("BCFIPS");
        SecureRandom random = new SecureRandom();
    }
}
```

fails with

```
Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294)
        at java.base/java.security.SecureRandom.<init>(SecureRandom.java:219)
        at TestSecureRandomBug.main(TestSecureRandomBug.java:8)
Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.Provider$Service.newInstance(Provider.java:1857)
        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290)
        ... 2 more
```

this works fine with the same security properties and policy (happy to share if useful) for JDK 14 and lower as well as earlier ea builds of JDK15


This looks like it was introduced by the changes made in https://bugs.openjdk.java.net/browse/JDK-8246613. This change is being backported to previous Java versions so I expect the impact to be larger than simply > JDK15.

I didn't have time to look into more detail for the cause yet, but I thought it's worth bringing up in case someone else comes across this


Best Regards
Ioannis

Reply | Threaded
Open this post in threaded view
|

Re: Default SecureRandom issue in BCFIPS and latest JDK15

Eckenfels. Bernd
Hello Ioannis,

Are you planning to report this to security-dev OpenJDK mailing list? I think default Random provider selection was recent discussion topic there.

This seems to be a clear OpenJDK issue, Maybe Rory knows if a open source project already gave EA feedback on this?

Gruss
Bernd
--
http://www.seeburger.com
From: Ioannis Kakavas <[hidden email]>
Sent: Saturday, June 27, 2020 8:18:56 AM
To: [hidden email]
Subject: [dev-crypto] Default SecureRandom issue in BCFIPS and latest JDK15
 
Hi there folks,

Simply attempting to get an instance of SecureRandom is failing in recent JDK15ea ( build 29 ) when BouncyCastleFipsProvider is the preferred security provider


minimal reproduction

```
import java.security.SecureRandom;
import java.security.Security;

public class TestSecureRandomBug {

    public static void main(String[] args){
        assert Security.getProviders()[0].getName().equals("BCFIPS");
        SecureRandom random = new SecureRandom();
    }
}
```

fails with

```
Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294)
        at java.base/java.security.SecureRandom.<init>(SecureRandom.java:219)
        at TestSecureRandomBug.main(TestSecureRandomBug.java:8)
Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.Provider$Service.newInstance(Provider.java:1857)
        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290)
        ... 2 more
```

this works fine with the same security properties and policy (happy to share if useful) for JDK 14 and lower as well as earlier ea builds of JDK15


This looks like it was introduced by the changes made in https://bugs.openjdk.java.net/browse/JDK-8246613. This change is being backported to previous Java versions so I expect the impact to be larger than simply > JDK15.

I didn't have time to look into more detail for the cause yet, but I thought it's worth bringing up in case someone else comes across this


Best Regards
Ioannis






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, 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
|

Re: Default SecureRandom issue in BCFIPS and latest JDK15

Ioannis Kakavas
Hi Bernd,

Thanks for the suggestion. The fact that this manifests only with the bouncycastle fips provider ( both 1.0.1 and 1.0.2 ) and not bouncycastle 1.65 or the SUN one for that matter, lead me to think this is bcfips related and I started the discussion here first.

I'll check security-dev and see if someone has reported this already. if not I'll send an email there, but it may have to wait for Monday morning my time.

Regards,
Ioannis


Sent from ProtonMail mobile



-------- Original Message --------
On Jun 27, 2020, 09:37, Eckenfels. Bernd < [hidden email]> wrote:

Hello Ioannis,

Are you planning to report this to security-dev OpenJDK mailing list? I think default Random provider selection was recent discussion topic there.

This seems to be a clear OpenJDK issue, Maybe Rory knows if a open source project already gave EA feedback on this?

Gruss
Bernd
--
http://www.seeburger.com
From: Ioannis Kakavas <[hidden email]>
Sent: Saturday, June 27, 2020 8:18:56 AM
To: [hidden email]
Subject: [dev-crypto] Default SecureRandom issue in BCFIPS and latest JDK15
 
Hi there folks,

Simply attempting to get an instance of SecureRandom is failing in recent JDK15ea ( build 29 ) when BouncyCastleFipsProvider is the preferred security provider


minimal reproduction

```
import java.security.SecureRandom;
import java.security.Security;

public class TestSecureRandomBug {

    public static void main(String[] args){
        assert Security.getProviders()[0].getName().equals("BCFIPS");
        SecureRandom random = new SecureRandom();
    }
}
```

fails with

```
Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294)
        at java.base/java.security.SecureRandom.<init>(SecureRandom.java:219)
        at TestSecureRandomBug.main(TestSecureRandomBug.java:8)
Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.Provider$Service.newInstance(Provider.java:1857)
        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290)
        ... 2 more
```

this works fine with the same security properties and policy (happy to share if useful) for JDK 14 and lower as well as earlier ea builds of JDK15


This looks like it was introduced by the changes made in https://bugs.openjdk.java.net/browse/JDK-8246613. This change is being backported to previous Java versions so I expect the impact to be larger than simply > JDK15.

I didn't have time to look into more detail for the cause yet, but I thought it's worth bringing up in case someone else comes across this


Best Regards
Ioannis






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, 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
|

Re: Default SecureRandom issue in BCFIPS and latest JDK15

David Hook-3

Firstly, thanks for flagging this now.

I've had a look at this, I think I can say what's happening, just not sure why.

The BCFIPS provider overrides getService() and getServices() and also populates the legacy map so that it has the "feel" of regular BC. It has it's own extension of Provider.Service which it uses for creating services. For some reason the Java 15 provider class is trying to create the BCFIPS DRBG using the java.security.Provider.Service.newInstance() method, not the BC one. This is why BC (which is a legacy style provider) works okay, but BCFIPS (which makes use of the features that were introduced in Java 5) fails. The list of SecureRandom implementations is built up in two places, one related to putService() and the other related to the legacy behavior.

The two universes seem to run into each other though and the weird thing is it seems I would only be able to stop the error by overriding getDefaultSecureRandomService() which I can't actually do (it's package protected, and should probably stay that way). Even if I call putService with the BC SecureRandom service on BCFIPS provider construction it appears the Java 15 Provider class overwrites the Service object with a legacy one and then the error occurs again.

The new scheme for dealing with "new SecureRandom()" is a fundamentally good idea, since Java 11 replaced the LinkedHashMap() in ensureLegacyParsed() method with a ConcurrentHashMap() one all previous guarantees about DRBG order went out the door and "new SecureRandom()"'s constant calling of getServices() has been an irritation for people for quite a while.

I think if they replace the code around line 1419:

        if (prngServices != null && !prngServices.isEmpty()) {

            return prngServices.iterator().next();

        }

with:

        if (prngServices != null && !prngServices.isEmpty()) {

            Service rng = prngServices.iterator().next();
            // ensure services on providers defining there own Service class are resolved.
            return getService(rng.getType(), rng.getAlgorithm());
        }

The BCFIPS provider (and any other one extending Service) will then work properly. I wouldn't suggest anything "deeper" than this as the code for meshing the legacy world with the Java 5 world does seem fragile, any change that was "cleverer" is likely to just cause other side affects.

Thanks,

David

On 27/6/20 6:38 pm, Ioannis Kakavas wrote:
Hi Bernd,

Thanks for the suggestion. The fact that this manifests only with the bouncycastle fips provider ( both 1.0.1 and 1.0.2 ) and not bouncycastle 1.65 or the SUN one for that matter, lead me to think this is bcfips related and I started the discussion here first.

I'll check security-dev and see if someone has reported this already. if not I'll send an email there, but it may have to wait for Monday morning my time.

Regards,
Ioannis


Sent from ProtonMail mobile



-------- Original Message --------
On Jun 27, 2020, 09:37, Eckenfels. Bernd < [hidden email]> wrote:

Hello Ioannis,

Are you planning to report this to security-dev OpenJDK mailing list? I think default Random provider selection was recent discussion topic there.

This seems to be a clear OpenJDK issue, Maybe Rory knows if a open source project already gave EA feedback on this?

Gruss
Bernd
--
http://www.seeburger.com
From: Ioannis Kakavas [hidden email]
Sent: Saturday, June 27, 2020 8:18:56 AM
To: [hidden email]
Subject: [dev-crypto] Default SecureRandom issue in BCFIPS and latest JDK15
 
Hi there folks,

Simply attempting to get an instance of SecureRandom is failing in recent JDK15ea ( build 29 ) when BouncyCastleFipsProvider is the preferred security provider


minimal reproduction

```
import java.security.SecureRandom;
import java.security.Security;

public class TestSecureRandomBug {

    public static void main(String[] args){
        assert Security.getProviders()[0].getName().equals("BCFIPS");
        SecureRandom random = new SecureRandom();
    }
}
```

fails with

```
Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294)
        at java.base/java.security.SecureRandom.<init>(SecureRandom.java:219)
        at TestSecureRandomBug.main(TestSecureRandomBug.java:8)
Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.Provider$Service.newInstance(Provider.java:1857)
        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290)
        ... 2 more
```

this works fine with the same security properties and policy (happy to share if useful) for JDK 14 and lower as well as earlier ea builds of JDK15


This looks like it was introduced by the changes made in https://bugs.openjdk.java.net/browse/JDK-8246613. This change is being backported to previous Java versions so I expect the impact to be larger than simply > JDK15.

I didn't have time to look into more detail for the cause yet, but I thought it's worth bringing up in case someone else comes across this


Best Regards
Ioannis






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, 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
|

Re: Default SecureRandom issue in BCFIPS and latest JDK15

Ioannis Kakavas
Thanks David,

I'll take it to the security-dev list to let the openjdk folks know. Given that this has the potential to break any provider that extends Service, I believe this has to be addressed.

I'll point them to the discussion here for a possible solution.

Ioannis



-------- Original Message --------
On Jun 28, 2020, 05:45, David Hook < [hidden email]> wrote:


Firstly, thanks for flagging this now.

I've had a look at this, I think I can say what's happening, just not sure why.

The BCFIPS provider overrides getService() and getServices() and also populates the legacy map so that it has the "feel" of regular BC. It has it's own extension of Provider.Service which it uses for creating services. For some reason the Java 15 provider class is trying to create the BCFIPS DRBG using the java.security.Provider.Service.newInstance() method, not the BC one. This is why BC (which is a legacy style provider) works okay, but BCFIPS (which makes use of the features that were introduced in Java 5) fails. The list of SecureRandom implementations is built up in two places, one related to putService() and the other related to the legacy behavior.

The two universes seem to run into each other though and the weird thing is it seems I would only be able to stop the error by overriding getDefaultSecureRandomService() which I can't actually do (it's package protected, and should probably stay that way). Even if I call putService with the BC SecureRandom service on BCFIPS provider construction it appears the Java 15 Provider class overwrites the Service object with a legacy one and then the error occurs again.

The new scheme for dealing with "new SecureRandom()" is a fundamentally good idea, since Java 11 replaced the LinkedHashMap() in ensureLegacyParsed() method with a ConcurrentHashMap() one all previous guarantees about DRBG order went out the door and "new SecureRandom()"'s constant calling of getServices() has been an irritation for people for quite a while.

I think if they replace the code around line 1419:

        if (prngServices != null && !prngServices.isEmpty()) {

            return prngServices.iterator().next();

        }

with:

        if (prngServices != null && !prngServices.isEmpty()) {

            Service rng = prngServices.iterator().next();
            // ensure services on providers defining there own Service class are resolved.
            return getService(rng.getType(), rng.getAlgorithm());
        }

The BCFIPS provider (and any other one extending Service) will then work properly. I wouldn't suggest anything "deeper" than this as the code for meshing the legacy world with the Java 5 world does seem fragile, any change that was "cleverer" is likely to just cause other side affects.

Thanks,

David

On 27/6/20 6:38 pm, Ioannis Kakavas wrote:
Hi Bernd,

Thanks for the suggestion. The fact that this manifests only with the bouncycastle fips provider ( both 1.0.1 and 1.0.2 ) and not bouncycastle 1.65 or the SUN one for that matter, lead me to think this is bcfips related and I started the discussion here first.

I'll check security-dev and see if someone has reported this already. if not I'll send an email there, but it may have to wait for Monday morning my time.

Regards,
Ioannis


Sent from ProtonMail mobile



-------- Original Message --------
On Jun 27, 2020, 09:37, Eckenfels. Bernd < [hidden email]> wrote:

Hello Ioannis,

Are you planning to report this to security-dev OpenJDK mailing list? I think default Random provider selection was recent discussion topic there.

This seems to be a clear OpenJDK issue, Maybe Rory knows if a open source project already gave EA feedback on this?

Gruss
Bernd
--
http://www.seeburger.com
From: Ioannis Kakavas [hidden email]
Sent: Saturday, June 27, 2020 8:18:56 AM
To: [hidden email]
Subject: [dev-crypto] Default SecureRandom issue in BCFIPS and latest JDK15
 
Hi there folks,

Simply attempting to get an instance of SecureRandom is failing in recent JDK15ea ( build 29 ) when BouncyCastleFipsProvider is the preferred security provider


minimal reproduction

```
import java.security.SecureRandom;
import java.security.Security;

public class TestSecureRandomBug {

    public static void main(String[] args){
        assert Security.getProviders()[0].getName().equals("BCFIPS");
        SecureRandom random = new SecureRandom();
    }
}
```

fails with

```
Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294)
        at java.base/java.security.SecureRandom.<init>(SecureRandom.java:219)
        at TestSecureRandomBug.main(TestSecureRandomBug.java:8)
Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.Provider$Service.newInstance(Provider.java:1857)
        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290)
        ... 2 more
```

this works fine with the same security properties and policy (happy to share if useful) for JDK 14 and lower as well as earlier ea builds of JDK15


This looks like it was introduced by the changes made in https://bugs.openjdk.java.net/browse/JDK-8246613. This change is being backported to previous Java versions so I expect the impact to be larger than simply > JDK15.

I didn't have time to look into more detail for the cause yet, but I thought it's worth bringing up in case someone else comes across this


Best Regards
Ioannis






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, 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
|

Re: Default SecureRandom issue in BCFIPS and latest JDK15

Ioannis Kakavas


//Ioannis



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, June 28, 2020 1:47 PM, Ioannis Kakavas <[hidden email]> wrote:

Thanks David,

I'll take it to the security-dev list to let the openjdk folks know. Given that this has the potential to break any provider that extends Service, I believe this has to be addressed.

I'll point them to the discussion here for a possible solution.

Ioannis



-------- Original Message --------
On Jun 28, 2020, 05:45, David Hook < [hidden email]> wrote:


Firstly, thanks for flagging this now.

I've had a look at this, I think I can say what's happening, just not sure why.

The BCFIPS provider overrides getService() and getServices() and also populates the legacy map so that it has the "feel" of regular BC. It has it's own extension of Provider.Service which it uses for creating services. For some reason the Java 15 provider class is trying to create the BCFIPS DRBG using the java.security.Provider.Service.newInstance() method, not the BC one. This is why BC (which is a legacy style provider) works okay, but BCFIPS (which makes use of the features that were introduced in Java 5) fails. The list of SecureRandom implementations is built up in two places, one related to putService() and the other related to the legacy behavior.

The two universes seem to run into each other though and the weird thing is it seems I would only be able to stop the error by overriding getDefaultSecureRandomService() which I can't actually do (it's package protected, and should probably stay that way). Even if I call putService with the BC SecureRandom service on BCFIPS provider construction it appears the Java 15 Provider class overwrites the Service object with a legacy one and then the error occurs again.

The new scheme for dealing with "new SecureRandom()" is a fundamentally good idea, since Java 11 replaced the LinkedHashMap() in ensureLegacyParsed() method with a ConcurrentHashMap() one all previous guarantees about DRBG order went out the door and "new SecureRandom()"'s constant calling of getServices() has been an irritation for people for quite a while.

I think if they replace the code around line 1419:

        if (prngServices != null && !prngServices.isEmpty()) {

            return prngServices.iterator().next();

        }

with:

        if (prngServices != null && !prngServices.isEmpty()) {

            Service rng = prngServices.iterator().next();
            // ensure services on providers defining there own Service class are resolved.
            return getService(rng.getType(), rng.getAlgorithm());
        }

The BCFIPS provider (and any other one extending Service) will then work properly. I wouldn't suggest anything "deeper" than this as the code for meshing the legacy world with the Java 5 world does seem fragile, any change that was "cleverer" is likely to just cause other side affects.

Thanks,

David

On 27/6/20 6:38 pm, Ioannis Kakavas wrote:
Hi Bernd,

Thanks for the suggestion. The fact that this manifests only with the bouncycastle fips provider ( both 1.0.1 and 1.0.2 ) and not bouncycastle 1.65 or the SUN one for that matter, lead me to think this is bcfips related and I started the discussion here first.

I'll check security-dev and see if someone has reported this already. if not I'll send an email there, but it may have to wait for Monday morning my time.

Regards,
Ioannis


Sent from ProtonMail mobile



-------- Original Message --------
On Jun 27, 2020, 09:37, Eckenfels. Bernd < [hidden email]> wrote:

Hello Ioannis,

Are you planning to report this to security-dev OpenJDK mailing list? I think default Random provider selection was recent discussion topic there.

This seems to be a clear OpenJDK issue, Maybe Rory knows if a open source project already gave EA feedback on this?

Gruss
Bernd
--
From: Ioannis Kakavas [hidden email]
Sent: Saturday, June 27, 2020 8:18:56 AM
To: [hidden email]
Subject: [dev-crypto] Default SecureRandom issue in BCFIPS and latest JDK15
 
Hi there folks,

Simply attempting to get an instance of SecureRandom is failing in recent JDK15ea ( build 29 ) when BouncyCastleFipsProvider is the preferred security provider


minimal reproduction

```
import java.security.SecureRandom;
import java.security.Security;

public class TestSecureRandomBug {

    public static void main(String[] args){
        assert Security.getProviders()[0].getName().equals("BCFIPS");
        SecureRandom random = new SecureRandom();
    }
}
```

fails with

```
Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294)
        at java.base/java.security.SecureRandom.<init>(SecureRandom.java:219)
        at TestSecureRandomBug.main(TestSecureRandomBug.java:8)
Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.Provider$Service.newInstance(Provider.java:1857)
        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290)
        ... 2 more
```

this works fine with the same security properties and policy (happy to share if useful) for JDK 14 and lower as well as earlier ea builds of JDK15


This looks like it was introduced by the changes made in https://bugs.openjdk.java.net/browse/JDK-8246613. This change is being backported to previous Java versions so I expect the impact to be larger than simply > JDK15.

I didn't have time to look into more detail for the cause yet, but I thought it's worth bringing up in case someone else comes across this


Best Regards
Ioannis






 
 
 


SEEBURGER AG
 
Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:
 
Axel Haas, Michael Kleeberg, Axel Otto, 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
|

Re: Default SecureRandom issue in BCFIPS and latest JDK15

David Hook-3

Thanks, I'll keep an eye on it.

Regards,

David

On 30/6/20 7:01 am, Ioannis Kakavas wrote:


//Ioannis



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, June 28, 2020 1:47 PM, Ioannis Kakavas [hidden email] wrote:

Thanks David,

I'll take it to the security-dev list to let the openjdk folks know. Given that this has the potential to break any provider that extends Service, I believe this has to be addressed.

I'll point them to the discussion here for a possible solution.

Ioannis



-------- Original Message --------
On Jun 28, 2020, 05:45, David Hook < [hidden email]> wrote:


Firstly, thanks for flagging this now.

I've had a look at this, I think I can say what's happening, just not sure why.

The BCFIPS provider overrides getService() and getServices() and also populates the legacy map so that it has the "feel" of regular BC. It has it's own extension of Provider.Service which it uses for creating services. For some reason the Java 15 provider class is trying to create the BCFIPS DRBG using the java.security.Provider.Service.newInstance() method, not the BC one. This is why BC (which is a legacy style provider) works okay, but BCFIPS (which makes use of the features that were introduced in Java 5) fails. The list of SecureRandom implementations is built up in two places, one related to putService() and the other related to the legacy behavior.

The two universes seem to run into each other though and the weird thing is it seems I would only be able to stop the error by overriding getDefaultSecureRandomService() which I can't actually do (it's package protected, and should probably stay that way). Even if I call putService with the BC SecureRandom service on BCFIPS provider construction it appears the Java 15 Provider class overwrites the Service object with a legacy one and then the error occurs again.

The new scheme for dealing with "new SecureRandom()" is a fundamentally good idea, since Java 11 replaced the LinkedHashMap() in ensureLegacyParsed() method with a ConcurrentHashMap() one all previous guarantees about DRBG order went out the door and "new SecureRandom()"'s constant calling of getServices() has been an irritation for people for quite a while.

I think if they replace the code around line 1419:

        if (prngServices != null && !prngServices.isEmpty()) {

            return prngServices.iterator().next();

        }

with:

        if (prngServices != null && !prngServices.isEmpty()) {

            Service rng = prngServices.iterator().next();
            // ensure services on providers defining there own Service class are resolved.
            return getService(rng.getType(), rng.getAlgorithm());
        }

The BCFIPS provider (and any other one extending Service) will then work properly. I wouldn't suggest anything "deeper" than this as the code for meshing the legacy world with the Java 5 world does seem fragile, any change that was "cleverer" is likely to just cause other side affects.

Thanks,

David

On 27/6/20 6:38 pm, Ioannis Kakavas wrote:
Hi Bernd,

Thanks for the suggestion. The fact that this manifests only with the bouncycastle fips provider ( both 1.0.1 and 1.0.2 ) and not bouncycastle 1.65 or the SUN one for that matter, lead me to think this is bcfips related and I started the discussion here first.

I'll check security-dev and see if someone has reported this already. if not I'll send an email there, but it may have to wait for Monday morning my time.

Regards,
Ioannis


Sent from ProtonMail mobile



-------- Original Message --------
On Jun 27, 2020, 09:37, Eckenfels. Bernd < [hidden email]> wrote:

Hello Ioannis,

Are you planning to report this to security-dev OpenJDK mailing list? I think default Random provider selection was recent discussion topic there.

This seems to be a clear OpenJDK issue, Maybe Rory knows if a open source project already gave EA feedback on this?

Gruss
Bernd
--
From: Ioannis Kakavas [hidden email]
Sent: Saturday, June 27, 2020 8:18:56 AM
To: [hidden email]
Subject: [dev-crypto] Default SecureRandom issue in BCFIPS and latest JDK15
 
Hi there folks,

Simply attempting to get an instance of SecureRandom is failing in recent JDK15ea ( build 29 ) when BouncyCastleFipsProvider is the preferred security provider


minimal reproduction

```
import java.security.SecureRandom;
import java.security.Security;

public class TestSecureRandomBug {

    public static void main(String[] args){
        assert Security.getProviders()[0].getName().equals("BCFIPS");
        SecureRandom random = new SecureRandom();
    }
}
```

fails with

```
Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294)
        at java.base/java.security.SecureRandom.<init>(SecureRandom.java:219)
        at TestSecureRandomBug.main(TestSecureRandomBug.java:8)
Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom
  attributes: {ImplementedIn=Software}

        at java.base/java.security.Provider$Service.newInstance(Provider.java:1857)
        at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290)
        ... 2 more
```

this works fine with the same security properties and policy (happy to share if useful) for JDK 14 and lower as well as earlier ea builds of JDK15


This looks like it was introduced by the changes made in https://bugs.openjdk.java.net/browse/JDK-8246613. This change is being backported to previous Java versions so I expect the impact to be larger than simply > JDK15.

I didn't have time to look into more detail for the cause yet, but I thought it's worth bringing up in case someone else comes across this


Best Regards
Ioannis






 
 
 


SEEBURGER AG
 
Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:
 
Axel Haas, Michael Kleeberg, Axel Otto, 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.