[cryptography] Android SecureRandom poor entropy

ianG iang at iang.org
Wed Aug 28 07:19:15 EDT 2013


On 25/08/13 23:45 PM, Marco Pozzato wrote:
> Hi all,
>
> I'm CTO at PrivateWave, developing solutions for secure telephony.
>
> Recently, android SecureRandom PRNG proved to be seriously flawed
> (http://android-developers.blogspot.it/2013/08/some-securerandom-thoughts.html)
> because, by default, it is not properly initialized with "good" entropy.
>
> The weakness is very critical, because initial state is practically
> affected only by process ID: when an application starts with the same
> PID, it generates the very same sequence of pseudo-random numbers.

Ouch!

> Many bitcoin applications suffered this issue and some bucks has been lost.
>
> Are you aware of some lists of flawed applications, not only related to
> bitcoin, but also in other cryptography and security domain?


In some pre-release sense, my app was effected in that I'd done the work 
to replace dependency on SecureRandom by centralising the source of it 
into one file, but I hadn't actually given it a new SR as yet.  A timely 
reminder, as we're about to require it.

(An earlier bug was the BigInteger failure in 2.2 Android, which caused 
certain public key operations to fail.  That was much more debilitating 
because it wasn't easy to isolate, until I found the comments from 
Bitcoin developers that hinted at the actual bug.)

> Our product, PrivateGSM, is not affected and I want to express here my
> thanks to Philip Zimmermann, who I had the pleasure and the honor to
> work with some years ago, when we was advisor in PrivateWave's
> scientific board and we jointly worked on the first mobile ZRTP client
> and designed a bitstream variant of ZRTP protocol, so called ZRTP/S.
>
> He insisted a lot on initializing PRNG with good entropy, such as noise
> from microphone, not trusting OS. Now I can fully and better appreciate
> that hint: thanks Phil.


Absolutely.  Phil cares.

> I'd like to share with you the results of some tests we run on android
> devices to assert the weakness of SecureRandom, without proper
> initialization.
>
> Flawed: after a few hundreds runs, PIDs start duplicating and the very
> same sequence is generated:


Hmm... that's not even a rainbow table, more like fifty shades of grey...


>   * Android Simulator 4.2
>   * Galaxy Nexus 4.3
>   * Samsung Galaxy S4 4.2.2
>   * HTC One X 4.1.1
>   * Motorola Razr 4.1.2
>
>
> Apparently not flawed: despite PIDs duplicates, random does not repeats.
>
>   * Samsung Galaxy Note II 4.1.2
>   * Samsung Galaxy S3 4.1.2
>   * Samsung Galaxy SII 4.1.2
>   * Motorola Defy Cyanogen 10.1


So, it's all over the map.  A problem with Android development is that 
bugs of this nature don't typically ever get fixed, we have to wait 
until the entire stock of phones is rolled over.


> Then, we decided to continue our tests to assert the quality of
> SecureRandom: DieHard test proved a good quality of sequence generated
> with SecureRandom...
>
> ...as long as you you start in the right way :-)



Thanks for the report, it provides some valuable clarification.

iang


More information about the cryptography mailing list