3
$\begingroup$

I am reading about the security internals of Android. In the book Android Security Internals, in chapter on Cryptographic Providers, there is a para stating:

On Android, CSPRNG implementations are seeded by reading seed bytes from the standard Linux /dev/urandom device file, which is an inter- face to the kernel CSPRNG. As the kernel CSPRNG itself may be in a fairly predictable state right after starting, Android periodically saves the state (which is 4096 bytes as of Android 4.4) of the kernel CSPRNG to the /data/system/entropy.dat file. The contents of that file are written back to /dev/urandom on boot in order to carry over the previous CSPRNG state. This is performed by the EntropyMixer system service.

Can someone help me to understand why is it important to save the state of kernel CSPRNG and load it on boot? If we not save the state, is it insecure? Isn't this saving the state making it predictable. Also, why the kernel CSPRNG will be in a predictable state after starting?

$\endgroup$
2
$\begingroup$

If we not save the state, is it insecure?

Yes, for an answer read on:

Isn't this saving the state making it predictable.

Yes. If an attacker manages to get access to the /data/system/entropy.dat file shortly after the kernel has loaded, he will have good knowledge of the internal CSPRNG state, could predict the random data and do nasty things.

On the other hand, if an attacker already has that high access rights to the machine predicting the CSPRNG is the least of your problems. He could just as well fool applications by providing it's own /dev/urandom device that generates pseudo random data. In that case he has perfect knowledge.

In case that the attacker does not have access rights to access the entropy file it is safe.

Also, why the kernel CSPRNG will be in a predictable state after starting?

In an embedded device like an android phone, there aren't many things that generate entropy data. There is for example no hard-drive that you can use as an entropy source by measuring seek and access times. Right after start-up there are also few (if any) network connections that you could use as an entropy source.

Entropy gets collected much quicker as soon as the machine gets operated by a human. You can pull data from input devices etc.

This is by the way not only true for embedded devices such as an android phone but for servers that run without operator interaction as well. So you'll see the same thing done on linux servers as well.

$\endgroup$
1
  • $\begingroup$ "In an embedded device like an android phone, there aren't many things that generate entropy data." This comment is clearly not true. An smartphone has many more sources of entropy than a standard desktop, laptop or server. GPS, imaging sensors, gyroscopes for orientation, and lots of user interaction. $\endgroup$ – rmalayter Jun 26 '15 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.