How good is SecRandomCopyBytes?

I'm principally interested in the implementation of SecRandomCopyBytes on iOS, if it differs from the OS X implementation. (I would presume that it does, since a mobile device has more and more readily available sources of entropy than a desktop compute开发者_运维百科r.)

Does anyone have information on:

1. Where SecRandomCopyBytes gets entropy from?
2. What rate it can generate good random numbers?
3. Will it block, or fail immediately if not enough entropy is available?
4. Is it FIPS 140-2 compliant, or has it been included in any other official certification?

The documentation does not cover these points.

I've only been able to find hear-say comments that it uses information from radios, the compass, accelerometers and other sources, but no quotes from people actually representing Apple.

/dev/random is fed by entropy from the SecurityServer. SecurityServer collecting entropy from the kernel event tracking (kdebug). The method is described in the book "Mac OS X Internals. A Systems Approach". You can read about it online for example at http://flylib.com/books/en/3.126.1.73/1/

the source code for the entropy collecting is here: http://www.opensource.apple.com/source/securityd/securityd-40600/src/entropy.cpp

In xnu-1504.9.37 (latest version for OS X as of writing), the kernel entropy buffer is filled in kernel_debug_internal(), using only timing information. This is the only place that the entropy buffer is written to.

if (entropy_flag && (kdebug_enable & KDEBUG_ENABLE_ENTROPY)) {
    if (kd_entropy_indx < kd_entropy_count) {
        kd_entropy_buffer [ kd_entropy_indx] = mach_absolute_time();
        kd_entropy_indx++;
    }

    if (kd_entropy_indx == kd_entropy_count) {
        /*
         * Disable entropy collection
         */
        kdebug_enable &= ~KDEBUG_ENABLE_ENTROPY;
        kdebug_slowcheck &= ~SLOW_ENTROPY;
    }
}

1. According to the iOS documentation, SecRandomCopyBytes is just a wrapper for the /dev/random PRNG. On most implementations of Unix, this file is a blocking PRNG; however, according to this page and the documentation, /dev/random on OSX/iOS actually functions like /dev/urandom in most other Unix implementations in that it does not ever block.

2. Since it does not block, you should be able to quickly determine the rate it generates random numbers using a simple test.

3. /dev/random is supposed to try to get entropy from as many sources as possible. Thus, it is entirely reasonable to believe that on iOS it uses the radio and accelerometer as sources of entropy; however, I cannot find any sources for this, and the documentation only states that it comes from "the random jitter measurements of the kernel".

4. It appears that the iPhone is currently in the process of being FIPS 140-2 validated.

The iOS SDK clearly states that this function uses the output of /dev/random for retrieving the secure random data. As iOS is a ported version of OSX which itself is in it's core a Free-BSD.

If you seach for /dev/random and OSX you find several posts that there was (and my be is) a problem regarding the entropy collection in OSX:

http://www.mail-archive.com/cryptography@metzdowd.com/msg00620.html

Therefore I would expect that /dev/random works not better than the one in OSX.