[guardian-dev] Android SecureRandom bug mitigation

[Daniel McCarney]

It seems like Google switched the Android SecureRandom implementation in
versions 4.2+ to use OpenSSL as the backing CSRNG already[1].

It might be worth looking at doing the same for devices running < 4.2. Of
course I haven't seen any information about affected versions RE: the
SecureRandom bitcoin flaw. I'd _expect_ it to only affect devices running older
versions of Android, but without someone more in-the-know confirming it I'm not
sure how reliable that notion is :-)

- Dan

[1]
http://android-developers.blogspot.ca/2013/02/security-enhancements-in-jelly-bean.html

On 08/12, Nathan of Guardian wrote:
> On 08/12/2013 11:16 AM, Nick Parker wrote:
> > An alternative might be to use RAND_bytes from OpenSSL if you are using
> > SecureRandom currently.  You could hook in various entropy sources via
> > calls to RAND_add, and verifying enough entropy has been added to the
> > PRNG via RAND_status.
> We've talked about something like that for awhile - pulling in
> accelerometer, microphone input, camera, etc - as part of a fun way to
> engage the user in entropy.
> 
> I'd just want to make sure we do it *right* of course.
> 
> It is funny to read Google's warning here:
> http://developer.android.com/reference/java/security/SecureRandom.html#SecureRandom(java.security.SecureRandomSpi,
> java.security.Provider)
> <http://developer.android.com/reference/java/security/SecureRandom.html#SecureRandom%28java.security.SecureRandomSpi,%20java.security.Provider%29>
> 
> which in hindsight, may have not been the best advise to follow. :(
> 
> "
> 
> 
>       Seeding |SecureRandom| may be insecure
> 
> A seed is an array of bytes used to bootstrap random number generation.
> To produce cryptographically secure random numbers, both the seed and
> the algorithm must be secure.
> 
> By default, instances of this class will generate an initial seed using
> an internal entropy source, such as |/dev/urandom|. This seed is
> unpredictable and appropriate for secure use.
> 
> Using the |seeded constructor
> <http://developer.android.com/reference/java/security/SecureRandom.html#SecureRandom%28byte[]%29>| or
> calling |setSeed(byte[])
> <http://developer.android.com/reference/java/security/SecureRandom.html#setSeed%28byte[]%29>| may
> completely replace the cryptographically strong default seed causing the
> instance to return a predictable sequence of numbers unfit for secure
> use. Due to variations between implementations it is not recommended to
> use |setSeed| at all."
> 

> _______________________________________________
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/daniel%40binaryparadox.net
> 
> You are subscribed as: daniel at binaryparadox.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20130812/f408051a/attachment.pgp>