Clarify guidelines for appropriate RNGs

[praetorian-peter-mueller]

Bottom Line

I recommend that we add language to MASTG-TEST-0016 to provide guidance to Android security engineers using languages other than Java. I propose that when java.security.SecureRandom is not available due to the choice of language, the language in MASTG-TEST-0016 should require that a "cryptographically secure pseudorandom number generator" should be used instead.

Details

The Static Analysis section in MASTG-TEST-0016 asks testers to look for custom or known-insecure random number generators. The present language provides an example of an insecure RNG in java.util.Random, and instead suggests the use of java.security.SecureRandom with the default constructor. This is very helpful information when the app in question is developed in Java.

Some Android apps are not written in Java (e.g., Dart), and in cases like these, it may be helpful for testers to have some other concise criteria for a "sufficiently secure" RNG.

I believe the right answer here is for developers to consult the standard library documentation (or equivalent) for their programming language and/or their operating system's developer documentation and identify the package, library, or device that exposes the kernel's cryptographically secure pseudorandom number generator (kernel-based CSPRNG). This should be the default choice for RNGs being used for security-sensitive purposes unless there is a compelling reason to the contrary.

Most modern programming languages and operating systems recommend a specific choice of CSPRNG in their documentation, and including the specific wording "cryptographically secure pseudorandom number generator" in MASTG-TEST-0016 will help the reader understand what to search for in their documentation.

Conclusion

MASTG-TEST-0016 should be updated to recommend the use of a "cryptographically secure pseudorandom number generator" when java.security.SecureRandom is not available due to the choice of language.