Why in Android kernel CSPRNG state is saved? 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?
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.