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 <core-libs-dev-bounces at openjdk.java.net> on behalf of Gustavo Romero <gromero at linux.vnet.ibm.com>
> Sent: Wednesday, June 20, 2018 2:59:47 AM
> To: core-libs-dev; security-dev
> Cc: vladimir.kozlov at oracle.com; 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
>