SecureRandom setSeed method fails on MacOS

Question

Running macOS High Sierra 10.13.5 and Java 1.8.0u171.

I have something like the following code:

SecureRandom random = SecureRandom.getInstance("NativePRNGNonBlocking");
random.setSeed(bla byte array);

I encounter the following exception whenever this is run, I have redacted some of the stack trace that contains some sensitive bits:

java.security.ProviderException: setSeed() failed
    at sun.security.provider.NativePRNG$RandomIO.implSetSeed(NativePRNG.java:472)
    at sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:331)
    at sun.security.provider.NativePRNG$NonBlocking.engineSetSeed(NativePRNG.java:312)
    at java.security.SecureRandom.setSeed(SecureRandom.java:427)
--redacted--
Caused by: java.io.IOException: Operation not permitted
    at java.io.FileOutputStream.writeBytes(Native Method)
    at java.io.FileOutputStream.write(FileOutputStream.java:313)
    at sun.security.provider.NativePRNG$RandomIO.implSetSeed(NativePRNG.java:470)
    at sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:331)
    at sun.security.provider.NativePRNG$NonBlocking.engineSetSeed(NativePRNG.java:312)
    at java.security.SecureRandom.setSeed(SecureRandom.java:427)
--redacted--

It appears that it is trying to write something, but I don't know what, or where. There is code in the area that mentions /dev/random, so I figured I would check the perms of that, but I don't know what to make of that either.

x@y:~ $ ls -ld /dev/null
crw-rw-rw-  1 root  wheel    3,   2 Jun 11 15:25 /dev/null
x@y:~ $ ls -ld /dev/urandom
crw-rw-rw-  1 root  wheel   14,   1 Jun 11 15:02 /dev/urandom
x@y:~ $ ls -ld /dev/random
crw-rw-rw-  1 root  wheel   14,   0 Jun  7 08:15 /dev/random

Any ideas what the issue is, and what I can do to remedy it?

EDIT: I found that it appears that NativePRNGNonBlocking appears to try and access /dev/urandom which OSX apparently doesn't allow writing to. Is there a way I can enable writing to it, or another method of avoiding this while still maintaining non-blocking behavior?

Do you still see the problem if you use `SecureRandom.getInstance("SHA1PRNG", "SUN")`? Assuming MacOS is used only for non-critical development work. — neurite, Jun 11 '18 at 23:03
Doesn't appear that I experience any issues with that. As a remediation step, I have altered the code to set it to that algorithm if the os.name contains "Mac Os". A less than desirable solution, considering our linux systems would still use NativePRNGNonBlocking. — ryanlutgen, Jun 13 '18 at 18:29
It's perhaps better to differentiate on development versus production environment. Because I am not sure `os.name` is reliable enough. What if it gets hacked? — neurite, Jun 13 '18 at 20:06
Yea that is probably the approach I will be taking, now that I know what the culprit is. I am not sure how to enable write access to urandom, so the better approach would be to just add an environment check there (we already have environments), to select the algorithm, rather than asking everyone on Mac to add write access to urandom (assuming its possible). Thanks for the info. — ryanlutgen, Jun 13 '18 at 20:11

User8461 · Answer 1 · 2018-06-11T23:21:11.393

2

The standard seed should already be provide enough entropy.

SecureRandom setSeed method fails on MacOS

2 Answers2