控制SecureRandom API的配置文件位于$JAVA_HOME/jre/lib/security/java.security。比如我们可以配置该文件里的securerandom.source属性来指定SecureRandom中使用的seed的来源。比如使用设备相关的源，可以这样设置：
securerandom.source=file:/dev/urandom securerandom.source=file:/dev/random
关于SecureRandom具体技术细节，可参看文后参考链接2。
现在重点看下SecureRandomSpi抽象类，文件见链接3。该抽象类为SecureRandom类定义了功能接口,里面有三个抽象方法engineSetSeed,engineGenerateSeed,and engineNextBytes。如果Service Provider希望实现加密强度较高的伪随机数生成器，就必须实现这三个方法。
然而Apache Harmony 6.0M3及其之前版本的SecureRandom实现中engineNextBytes函数存在安全漏洞。
Apache Harmony 是2005年以Apache License发布的一个开源的java核心库。虽然2011年以后已宣布停产，但是这个项目作为Google Android platform的一部分继续被开发维护。
Apache Harmony's SecureRandom实现算法如下：
Android里的PRNG使用SHA-1哈希算法、由操作系统提供的设备相关的种子来产生伪随机序列。随机数是通过三部分(即seed+counter+ padding)反复哈希求和计算产生的。算法如下图
其中计数器counter从0开始，算法每运行一次自增一。counter和padding部分都可以称为buffer。Padding遵守SHA-1的填充格式：最后的8 byte存放要hash的值的长度len，剩下的部分由一个1，后面跟0的格式进行填充。最后返回Hash后的结果，也就是生成的伪随机序列。
当使用无参构造函数创建一个SecureRandom实例，并且在随后也不使用setSeed()进行初始化时,插入一个起始值后，代码不能正确的调整偏移量(byte offset,这个offset是指向state buffer的指针)。这导致本该附加在种子后面的计数器(8 byte)和padding(起始4 byte)覆盖了种子的起始12 byte。熵的剩下8 byte(20 byte的种子中未被覆盖部分),使得PRNG加密应用无效。
小编推荐阅读
