SecRandomCopyBytes 有多好?
我主要对 iOS 上的 SecRandomCopyBytes
实现感兴趣,如果它与 OS X 实现不同的话。 (我认为确实如此,因为移动设备比台式计算机拥有越来越多的可用熵源。)
有人知道以下信息:
- SecRandomCopyBytes 从哪里获取熵?
- 它能以什么速率产生好的随机数?
- 如果没有足够的熵,它会阻塞或立即失败吗?
- 是否符合 FIPS 140-2,或者是否已包含在任何其他官方认证中?
该文档不涉及这些要点。
我只能找到道听途说的评论,说它使用了来自收音机、指南针、加速计和其他来源的信息,但没有真正代表苹果的人引用。
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 computer.)
Does anyone have information on:
- Where SecRandomCopyBytes gets entropy from?
- What rate it can generate good random numbers?
- Will it block, or fail immediately if not enough entropy is available?
- 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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
/dev/random 由来自 SecurityServer 的熵提供。 SecurityServer 从内核事件跟踪 (kdebug) 收集熵。该方法在《Mac OS X Internals. A Systems Approach》一书中进行了描述。您可以在线阅读相关内容,例如 http://flylib.com/books/en /3.126.1.73/1/
熵收集的源代码在这里:http://www.opensource.apple.com/source/securityd/securityd-40600/src/entropy.cpp
在 xnu-1504.9.37 中(OS X 的最新版本为写入),内核熵缓冲区被填充在
kernel_debug_internal()
中,仅使用计时信息。这是熵缓冲区写入的唯一位置。/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.根据 iOS 文档,
SecRandomCopyBytes
只是/dev/random
PRNG 的包装器。在大多数 Unix 实现中,该文件是阻塞 PRNG;但是,根据此页面和文档,< OSX/iOS 上的 code>/dev/random 实际上的功能类似于大多数其他 Unix 实现中的/dev/urandom
,因为它永远不会阻塞。由于它不会阻塞,您应该能够通过简单的测试快速确定它生成随机数的速率。
/dev/random
应该尝试从尽可能多的来源获取熵。因此,完全有理由相信 iOS 上它使用无线电和加速计作为熵源;但是,我找不到任何来源,并且 文档仅声明它来自“内核的随机抖动测量”。iPhone 目前正在处理中 已通过 FIPS 140-2 验证。
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.Since it does not block, you should be able to quickly determine the rate it generates random numbers using a simple test.
/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".It appears that the iPhone is currently in the process of being FIPS 140-2 validated.
iOS SDK 明确指出该函数使用
/dev/random
的输出来检索安全随机数据。由于 iOS 是 OSX 的移植版本,而 OSX 本身的核心是 Free-BSD。如果您搜索
/dev/random
和 OSX,您会发现几个帖子,其中存在(我的意思是)有关 OSX 中熵收集的问题: mail-archive.com/cryptography@metzdowd.com/msg00620.html" rel="nofollow">http://www.mail-archive.com/[email protected]/msg00620.html
因此,我预计
/dev/random
的效果并不比 OSX 中的好。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/[email protected]/msg00620.html
Therefore I would expect that
/dev/random
works not better than the one in OSX.