Some RNGs (including some versions of Linux /dev/random) have an interface that exposes the estimated amount of entropy in the secret state of the RNG.
If an adversary gains access to this interface, then there is a small risk that sensitive information leaks to the adversary, because the entropy estimate may be derived from and correlated to sensitive information. Just to be clear, I do not see this to be a serious risk. It would be difficult to exploit. Yet I do not see enough benefit in this interface to support taking this risk. This issue has probably been discussed elsewhere, maybe with different conclusions from, and better reasoning than, mine. If so, then a reply could just point to those discussions. --- More detail sketched out below: The entropy in the RNG must necessarily be derived from secret sources. In many systems, the secret sources include things like keyboard input timings, which can be further classified as sensitive sources. The estimated entropy is also derived in some way from these secret sensitive sources. This derivation of the estimated entropy is not generally a cryptographically strong one-way function. Furthermore, the timing information might be leaked even if estimation is somehow one-way. Therefore, the interfaces leaks information about the sensitive sources. For a concrete example, the interface might leak information about the keyboard timings, which might in turn leak information about the values of the key inputs (if, say, there is a correlation between the values and timings, which might be the case, if say the difference key-down and key-up times vary significantly between different keyboard inputs). I don't see much value of providing this estimated-entropy interface at all. Arguably, system administrators might find it useful to know whether the system is in a secure state (perhaps to diagnose some kind of problem). Obviously, this interface does not escalate a system administrator's already high privileges. But providing this interface to non-privileged processes risks exposure of sensitive information to unauthorized processes. A simple way to reduce this risk would be to deny access to non-privileged users, disallowing them to see the run-time entropy estimate. A more severe recommendation (Barak and Halevi, http://ia.cr/2005/029) is to not keep a run-time estimate of entropy. But some security goals do need live entropy, which might suggest using some limited run-time entropy estimation. For example, NIST SP 800-90* standards have a notion of prediction resistance (which is similar of Linux /dev/random's blocking interface). In this mode, the RNG waits until it deems it has enough, presumably fresh entropy. The ostensible purpose is to recover from past temporary state-exposures. The NIST approach is gather to fresh entropy from a live noise source. If this noise source has its entropy assessed only at design time, not at run-time, then Barak and Halevi's recommendation (of no run-time entropy estimation), can be followed. The NIST standards might, however, have some mild health test checks of entropy source, which only aim to detect severe failure, making them only mildly incompatible with the Barak-Halevi approach. If I understand correctly, the recent /dev/random approaches are to decrease the estimate entropy on an ongoing basis (such as during calls /dev/random), to ensure the current pool is deemed to be fresh entropy. The freshness so obtained might have a purpose similar to NIST's security goal of prediction resistance (recovery from temporary state-compromise). Unfortunately, this step of decreasing the entropy estimate increases the risk of the interface. For example, if the entropy is in a near full state, then /dev/random might cease to increase its entropy estimate. In this full state, the leak is reduced or stopped, because the entropy estimate does not change as often. To circumvent this obstacle, the adversary can draw down the entropy estimate by calling /dev/random, thereby cause the RNG to decrease its entropy estimate. In so doing, the adversary can change the RNG state from non-leaky back to leaky. (The issue of calls to /dev/random being abused for another purpose to cause a denial of service has already been largely mitigated by changes in the /dev/random system.) The entropy estimate interface exposes more information than the blocking behavior of something like /dev/random, in that the entropy estimate numbers contain more information than the single bit of blocked/non-blocked state, and further the entropy estimate changes more frequently than the blocking state. But even the blocking behavior of /dev/random has the potential to leak a miniscule information, such as the timing information. For example, a malicious non-privileged process might call /dev/random very frequently until it blocks. Whether another user, say the system administrator, on the system types sensitive keyboard input into another process, /dev/random may unblock. The malicious process can then gather some timing information about the keyboard inputs. I see this as a much smaller risk, which is arguably worth the benefit of the prediction resistance properties of /dev/random. Again, the reason it is smaller risk is that blocking state changes much less frequently than the entropy estimate. Monitoring changes in the entropy estimate can therefore much more precise timing information. Best regards, Dan Brown [BlackBerry]<http://www.blackberry.com/> --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________ dsfjdssdfsd mailing list dsfjdssdfsd@ietf.org https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
