RFC: Add new JCA provider to support hardware RNGs

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

RFC: Add new JCA provider to support hardware RNGs

Gustavo Romero
Sorry for resending it. I missed a few MLs.

--

Hi,

Please, could I get comments on the following change?

Since it's related to security, I would be glad if security
experts could also comment on that.

webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/

It introduces a way to get benefits from hardware instructions in userspace
that can delivery a random number and so be used to speed up and avoid
blocking in some SecureRandom methods, notably generateSeed() and
nextBytes(), without loosing the random number quality. Particularly on
Power, the new POWER9 CPUs introduced a hardware instruction called 'darn'
that can be used for that purpose.

The main idea is to add a new JCA provider called "HWTRNG" (if no better
name is suggested), adding new helper methods that can then be intrinsified
and that will be used  by generateSeed() and nextBytes(). In that sense,
this change also adds the proper mechanisms in the Interpreter,
C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other
platforms) to intrinsify these helper methods that will be used in the end
by generateSeed() and nextBytes() methods. The added helpers are:

    byte[] getRandomSequence0(int)
    byte[] getRandomSequence1(byte[])
    long validRandomLong(void)
    long randomLong(void)

The helpers also take care of checking if the returned random number is
valid and attempt 10 times (as recommended by ISA) get a valid random
number before falling back to a software alternative (HWTRNG is based
mostly on JCA provider NativePRNG and so the fall back mechanism will use
the exactly same methods found in NativePRNG and hence behave similarly.
Nonetheless, in my experience such a hardware failures (which are the main
cause of a returned invalid random number) are quite rare: in my tests I
was never able to exhaust the HW RNG and force it to generate an invalid
random number).

The user, besides having to specify explicitly the use of a non-default
provider (HWTRNG), will have to unlock the VM experimental options to
effectively use the hardware RNG as an unique random source by passing
options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics".

On Power, for the Interpreter and C1 Compiler, besides avoiding the
blocking effect of a low entropy on /dev/random, I was able to get about
126 Mbps (3x higher than the version without 'darn') on generaSeed() and
nextBytes(). The maximum theoretical value on a POWER9 machine is usually
128 Mbps.

I'll address the details about the file headers (Copyright, dates, authors,
versions, etc) after I get some feedback about this change.


Thanks in advance.

Best regards,
Gustavo

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add new JCA provider to support hardware RNGs

Gustavo Romero
Hi Bernd,

Thanks for your comments.

On 06/20/2018 05:05 PM, Bernd Eckenfels wrote:
> Just a FYI under Linux when you read from urandom the Linux kernel will always XOR with random bytes generated with x64 rdrand instruction (arch_get_random_lomg() - if supported). Since it is a XOR it does not have to trust the quality of this black box hardware implementation.

Yes, I know to some extent how the use of rdrand on Intel by Linux
generated debates in the past.


> I would not implement a generator which does not have its own software whitening. (And most likely there is no need for one different than urandom on Linux). If you do implement whitening I would use a DRBG construction and no longer use a (low state) SHA1PRNG.

My main concern to use 'darn' on Power was to get some additional speed and
throughput on obtaining true random numbers (or on cases where /dev/random
- which blocks - was preferred to /dev/urandom). That concern seems valid
specially when the code is not JITed yet by the C2 compiler (so for
Interpreted and C1 Compiler). Anyway, the idea to have a separated provider
and that the use of the intrinsic is by no means enabled by default is to
let the user to decide if he/she wants to use that kind of generator. I
think OpenSSL disabled by default the use of rdrand similarly but let the
user to enable it if desired?

The idea of DRBG looks valid. I took SHA1PRNG as a fallback. But if DRBG
would be used for whitening that would need a seed from /dev/urandom?
(I'm trying to think the impact on performance here).


Best regards,
Gustavo

> Gruss
> Bernd
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: core-libs-dev <[hidden email]> on behalf of Gustavo Romero <[hidden email]>
> Sent: Wednesday, June 20, 2018 2:59:47 AM
> To: core-libs-dev; security-dev
> Cc: [hidden email]; Doerr, Martin
> Subject: RFC: Add new JCA provider to support hardware RNGs
>
> Hi,
>
> Please, could I get comments on the following change?
>
> Since it's related to security, I would be glad if security
> experts could also comment on that.
>
> webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/
>
> It introduces a way to get benefits from hardware instructions in userspace
> that can delivery a random number and so be used to speed up and avoid
> blocking in some SecureRandom methods, notably generateSeed() and
> nextBytes(), without loosing the random number quality. Particularly on
> Power, the new POWER9 CPUs introduced a hardware instruction called 'darn'
> that can be used for that purpose.
>
> The main idea is to add a new JCA provider called "HWTRNG" (if no better
> name is suggested), adding new helper methods that can then be intrinsified
> and that will be used  by generateSeed() and nextBytes(). In that sense,
> this change also adds the proper mechanisms in the Interpreter,
> C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other
> platforms) to intrinsify these helper methods that will be used in the end
> by generateSeed() and nextBytes() methods. The added helpers are:
>
>     byte[] getRandomSequence0(int)
>     byte[] getRandomSequence1(byte[])
>     long validRandomLong(void)
>     long randomLong(void)
>
> The helpers also take care of checking if the returned random number is
> valid and attempt 10 times (as recommended by ISA) get a valid random
> number before falling back to a software alternative (HWTRNG is based
> mostly on JCA provider NativePRNG and so the fall back mechanism will use
> the exactly same methods found in NativePRNG and hence behave similarly.
> Nonetheless, in my experience such a hardware failures (which are the main
> cause of a returned invalid random number) are quite rare: in my tests I
> was never able to exhaust the HW RNG and force it to generate an invalid
> random number).
>
> The user, besides having to specify explicitly the use of a non-default
> provider (HWTRNG), will have to unlock the VM experimental options to
> effectively use the hardware RNG as an unique random source by passing
> options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics".
>
> On Power, for the Interpreter and C1 Compiler, besides avoiding the
> blocking effect of a low entropy on /dev/random, I was able to get about
> 126 Mbps (3x higher than the version without 'darn') on generaSeed() and
> nextBytes(). The maximum theoretical value on a POWER9 machine is usually
> 128 Mbps.
>
> I'll address the details about the file headers (Copyright, dates, authors,
> versions, etc) after I get some feedback about this change.
>
>
> Thanks in advance.
>
> Best regards,
> Gustavo
>