Hey,
sorry, but I believe you have misunderstood the actual issue. Which I do not
blame you, since the matter disclosure was handled pretty badly (the fact that
the actual vulnerability details were published much later than the "Android
isn't secure" campaign makes me think there was some marketing force at work).
Anyway, the details:
The issue stemmed from the bad design of Java Cryptography API (JCA) which is a
standard Java API for work with cryptographic primitives. The API however is
badly designed - it does not guarantee a good same implementation of underlying
primitve. So for example, SecureRandom (the PRNG) may have different underlying
implementations depending on platform and device.
This is a very known pitfall - there have been numerous cases of bad Java JVM
PRNGs being defaulted in some implementations (e.g. Windows Sun JVM) and in
alot of cases the PRNG wasn't seeded at creation. Which means that the user of
SecureRandom must manually seed the PRNG to ensure correct function.
This was the exact issue here on Android as well - in some cases/devices the
SecureRandom would use a Java PRNG implementation (instead of better, more
secure, /dev/urandom backed implementation usually used on Linux systems) which
was not seeded at all. Since authors also didn't seed the generators
themselves, they were utterly worthless.
This is also the exact same issue that slipped past Debian a few years ago
which compromised all their OpenSSH keys - the PRNG wasn't properly seeded due
to oversight in code.
So what BitCoin app developers should have known is to either:
1.) Enforce usage of /dev/urandom PRNG from Linux kernel (which is also
official Google recommendation)
2.) Manually seed PRNG after instatiation
Since they didn't do any of that, the app was compromised. Also note: this is
NOT a Dalvik issue. If an app uses OpenSSL PRNG without properly seeding it it
will also work incorrectly.
Most of this mess comes down to the fact that cryptograpy APIs (at least JCA
and OpenSSL) are badly designed and documented and don't stress enough the
proper initialization procedures for cryptographic primitives. OpenSSL
documentation is especially bad in that aspect and causes developers to quickly
fall into one of many pits of secure algorithm implementation.
So TL;DR: Android PRNG isn't buggy per se, users of it have to be avare of
problems with API design and mitigate them. Also, even the desktop versions of
libs are problematic in this aspect so blaming this issue on Android is
misleading and could push people into false sense of security.
As for Intel/AMD PRNGs - for now I havent seen OSes rely on those to generate
proper sequences. The preliminary tests show that the distribution looks "ok".
Fully relying on them without additional entropy sources would be a pretty dumb
idea though.
Regards,
--
Jernej Virag
@jernejv
On August 30, 2013 at 19:38:04 , Dmitriy Nikandrov
(dmitriy.nikand...@gmail.com) wrote:
Hi all,
have you heard of last issue with theft of coins from bitcoin wallet installed
on Android?
It is caused by dalvik's buggy pseudorandom number generator (PRNG) component -
the generated numbers can be the same - this ruins security of all user apps
relying on that PRNG.
And what is more interesting - there is rumors that Intel & AMD may also
intentionally "tune" their CPU's PRNG to provide really not so random numbers -
in favor of different gov organisations, making tools like PGP meaningless.
Did anybody study this?
It is important to check Intel's and AMD's PRNG realization, to check if they
are doing what they should.
Regards,
Dmitriy
_______________________________________________
Replicant mailing list
Replicant@osuosl.org
https://lists.osuosl.org/mailman/listinfo/replicant
