This post was updated on December 16 to make clear that for most of FreeBSD's history, it wasn't possible to use RDRAND and Padlock as the sole source of random numbers fed to the /dev/random engine.
Developers of the FreeBSD operating system will continue preventing users from trusting processors manufactured by Intel and Via Technologies as the sole source of random numbers needed to generate cryptographic keys that can't easily be cracked by government spies and other adversaries.
That decision, which will be effective in the upcoming FreeBSD version 10.0, comes three months after secret documents leaked by former National Security Agency (NSA) subcontractor Edward Snowden said the US spy agency was able to decode vast swaths of the Internet's encrypted traffic. Among other ways, The New York Times, Pro Publica, and The Guardian reported in September, the NSA and its British counterpart defeat encryption technologies by working with chipmakers to insert backdoors, or cryptographic weaknesses, in their products.
The revelations are playing a role in the decision for FreeBSD to continue restricting the use of hardware-based random number generators to seed the data used to ensure cryptographic systems can't be easily broken by adversaries. Specifically, "RDRAND" and "Padlock"—RNGs provided by Intel and Via respectively—will not be the sources FreeBSD uses to directly feed random numbers into the /dev/random engine used to generate random data in Unix-based operating systems. Instead—and has been the case for most of FreeBSD's history—it will be possible to use the pseudo random output of RDRAND and Padlock to seed /dev/random only after it has passed through a separate RNG algorithm known as "Yarrow." Yarrow, in turn, will add further entropy to the data to ensure intentional backdoors, or unpatched weaknesses, in the hardware generators can't be used by adversaries to predict their output.
"For 10, we are going to backtrack and remove RDRAND and Padlock backends and feed them into Yarrow instead of delivering their output directly to /dev/random," FreeBSD developers said in meeting minutes from earlier this year. "It will still be possible to access hardware random number generators, that is, RDRAND, Padlock etc., directly by inline assembly or by using OpenSSL from userland, if required, but we cannot trust them any more."
In separate meeting minutes, developers specifically invoked Snowden's name when discussing the decision.
"Edward Snowdon [sic] -- v. high probability of backdoors in some (HW) RNGs," the notes read, referring to hardware RNGs. Then, alluding to the Dual EC_DRBG RNG forged by the National Institute of Standards and Technology and said to contain an NSA-engineered backdoor, the notes read: "Including elliptic curve generator included in NIST. rdrand in ivbridge not implemented by Intel... Cannot trust HW RNGs to provide good entropy directly. (rdrand implemented in microcode. Intel will add opcode to go directly to HW.) This means partial revert of some work on rdrand and padlock."
The meetings came shortly after a FreeBSD patch a third party submitted in July gave users the ability to use RDRAND and Padlock as direct sources of randomness. The update was committed without proper review and against established policy, and over the next few weeks all or parts of it were removed and recommitted FreeBSD Security Officer Dag-Erling Smørgrav told Ars. The change was finally removed altogether in October. Aside from the brief span earlier this year, no FreeBSD release has ever shipped with the option to feed the bit stream from a hardware pseudo-random number generator directly to /dev/random, Smørgrav said.
Smørgrav went on to say that some corporate users have long expressed a wish that FreeBSD allow them to run raw feeds from RDRAND, because its underlying algorithm is listed as an approved deterministic RNG under the FIPS 140 standard defense contractors and other government workers are required to follow. Using a few lines of code, FreeBSD users can to use RDRAND directly in userland rather than use the kernel to feed it to them directly.
"What it boils down to is that we will not stand in the way of FreeBSD users who want to use these HWRNGs, but neither will we endorse them, and we felt that providing a kernel interface would amount to implicit endorsement of the underlying hardware," Smørgrav wrote in an e-mail.
RNGs are one of the most important ingredients in any secure cryptographic system. They are akin to the dice shakers used in board games that ensure the full range of randomness is contained in each roll. If adversaries can reduce the amount of entropy an RNG produces or devise a way to predict some of its output, they can frequently devise ways to crack the keys needed to decrypt an otherwise unreadable message. A weakness in the /dev/random engine found in Google's Android operating system, for instance, was the root cause of a critical exploit that recently allowed thieves to pilfer bitcoins out of a user's digital wallet. RDRAND is the source of random data provided by Ivy Bridge and later versions of Intel processors. Padlock seeds random data in chips made by Via.
While the FreeBSD developers discussing their distrust cited allegations of backdoors raised in documents leaked by Snowden, the move is a good idea even if those weaknesses never came to light. Adding additional sources of randomness to RDRAND, Padlock, and other RNGs will not reduce their entropy and may make the keys they help generate harder to crack. Relying on multiple sources of randomness is a good practice and possibly could have helped prevent recently discovered crippling weaknesses in Taiwan's secure digital ID system.
reader comments
143