Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Encryption BSD

FreeBSD Developers Will Not Trust Chip-Based Encryption 178

Posted by Soulskill from the fool-me-once,-shame-on-you dept.
New submitter srobert writes "An article at Ars Technica explains how, following stories of NSA leaks, FreeBSD developers will not rely solely on Intel's or Via's chip-based random number generators for /dev/random values. The values will first be seeded through another randomization algorithm known as 'Yarrow.' The changes are effective with the upcoming FreeBSD 10.0 (for which the first of three planned release candidates became available last week)."
This discussion has been archived. No new comments can be posted.

FreeBSD Developers Will Not Trust Chip-Based Encryption More

FreeBSD Developers Will Not Trust Chip-Based Encryption

Comments Filter:

  • Very Smart Move (Score:5, Insightful)

    by Anonymous Coward on Wednesday December 11, 2013 @05:09PM (#45663917)

    They have every reason NOT to trust the chips. Trust, but verify is always the correct way.

    • Re: (Score:3, Interesting)

      by Billly Gates ( 198444 )

      You know 6 months ago such a comment would be modded -1 and this story would have the foot icon for humor.

      My have things changed. Microsoft was not that bad DRM monster we feared 12 years ago. First it turned out to be Apple in which we cheered them 10 years ago here on /.

      But both companies fail far in comparison to the US government and this is something I would not have imagined in my wildest nightmares.

      • Re: (Score:3)

        by lgw ( 121541 )

        The RNG threat is particularly bad, because it looks like only one person would need to be in the know to sabotage the RNG on silicon, and it would bypass any review process, and it would be very hard to detect by observation of the RNG (assuming it still had, say, 32 bits of entropy).

        • it looks like only one person would need to be in the know to sabotage the RNG on silicon

          Technically, you can't even access the hardware RDRNG, you have to access it through a black box hash function unit that is specified as "trust us". If something were to be sabotaged, that would be the place to do it. If I were designing a susceptible RNG, I'd allow it to change its behavior based on an obscure set of inputs, so most of the time it worked correctly.

      • This work has been ongoing for about a year, since long before the NSA stuff came out. The consensus has been for a while that some hardware random number generators give very good entropy, but some are very poor and it's difficult to tell without querying them a few million times and plotting the distribution which one you have. Add to that, some of them appear to be influenced by the temperature, and as Stephen Murdoch's attack on Tor showed influencing the temperature of someone else's server is not al

        • The CPU based RNGs - aren't they based on factors other than temperature, such as ambient noise?
          • It depends on the implementation. As I recall, the Intel ones are basically just a pair of flipflops in an unstable configuration for each bit. They're intended to be something that toggles between 0 and 1 at some frequency that you can't easily determine (and which isn't the same for each bit). However, as they're digital circuits, they do respond to heat. Hopefully, they don't respond in a way that makes the readings more predictable, but it would take a lot of analysis to be sure of that.
            • Yeah, I describe how it could be done in the thread below 'Is there any way to gain trust in a chip?' Also, if a chip has multiple asynchronous clocks & PLLs, that's another way of introducing randomness in the results.

    • Re: (Score:2)

      by mlts ( 1038732 ) *

      Trust but verify is important, but chips are incredibly hard to know if a random source is truly random, as opposed to, say the output of a clock AES encrypted, so that it appears random.

      Best thing to do is have the chip be part of the RNG, but not the only part, so another random source will provide enough unpredictability to keep thing secure.

    • Re: (Score:2, Informative)

      by smash ( 1351 )

      Ah, but Linus has called such claims nonsense [theregister.co.uk].

      FreeBSD for me, thanks.

      • Re:Very Smart Move (Score:5, Informative)

        by Anonymous Coward on Wednesday December 11, 2013 @09:45PM (#45666793)

        I take it you didn't even actually read what he said, then.

        Linus Torvalds responds:

        Where do I start a petition to raise the IQ and kernel knowledge of people?

        Guys, go read drivers/char/random.c. Then, learn about cryptography. Finally, come back here and admit to the world that you were wrong.

        Short answer: we actually know what we are doing. You don't.

        Long answer: we use rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if rdrand were to be back-doored by the NSA, our use of rdrand actually improves the quality of the random numbers you get from /dev/random.

        Really short answer: you're ignorant.

        TL;DR: Linux was NOT trusting chips and doing a variant of what FreeBSD plans to do now since quite a bit before.

        • Re: (Score:2)

          by DES ( 13846 ) *

          TL;DR: Linux was NOT trusting chips and doing a variant of what FreeBSD plans to do now since quite a bit before.

          You mean “a variant of what FreeBSD has been doing since 2003”

      • Re: (Score:2)

        by zdzichu ( 100333 )

        Linus is reasonable guy. He's sometimes wrong, but can be convinced with technical arguments. The "don't-trust-RDRAND" change was included in Linux a year and a half ago: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9 [kernel.org]

      • Ah, but Linus has called such claims nonsense [theregister.co.uk].

        FreeBSD for me, thanks.

        No he did not call the claims nonsense, what he said was that the kernel did not do this anyway so before starting a stupid petition not to do something you should actually check what the kernel does.

        It sounds like all FreeBSD are doing is copying the approach that Linux already used in that they are using the random values thrown out by the chip as a source of entropy to combine with several other sources of entropy in generating a true random number. I am surprised that FreeBSD did not do this already to

      • Tell us - what happens when you mix a stream of zeros into your entropy pool?

    • Re: (Score:3, Insightful)

      by celle ( 906675 )

      "Trust, but verify"

              If you feel you have to verify then you don't trust them. It was bullshit when Reagan said it and it still is.

      • It was bullshit when Reagan said it and it still is.

        Reagan's mind was imprinted into the NSA's most powerful computer, where it feverishly works to complete World Domination for Bonzo.

    • From the above summary

      FreeBSD developers will not rely solely on Intel's or Via's chip-based random number generators for /dev/random values

      In other words, Intel or Via's RNG will still be used, but won't be the ONLY basis on which they are generated. It will be that PLUS Yarrow

    • It's not so much "very smart move" as "why weren't they doing this in the first place"? I've worked on various crypto projects and I don't think any of them ever relied on a single source of entropy, unfiltered. For those systems using RDRAND the way it's supposed to be used (to feed a hash or crypt-based generator, alongside other sources), this "news" story should really read "FreeBSD developers finally do what everyone else has been doing for years".

  • Wise (Score:1)

    by Anonymous Coward

    It's always wise to get entropy from as many places as you can; in light of the NSA revelations, it's time relying on just one becomes something people don't even consider anymore.

    Is OpenBSD, the 'security first' BSD, ahead of, or behind the curve with this?

    • Re:Wise (Score:5, Funny)

      by Minwee ( 522556 ) <dcr@neverwhen.org> on Wednesday December 11, 2013 @05:21PM (#45664021) Homepage
      Every time an OpenBSD system needs a random number, instead of trusting any hardware device, it phones home and asks Theo to provide one.

    • You mean just like Linux has for quite some time?

      After all, these hardware random sources feed the entropy pool, however are certainly not its only source.
      Hell, applications can even contribute to the pool as they wish, and that is not considered an issue no matter how non-random their contribution is.

      FreeBSD and its reliance on the Yarrow approach is much more 'sensitive' to its PRNG source(s), so its about time they caught up..

      http://en.wikipedia.org/wiki//dev/random

      Then again, random numbers tend to be t

      • Re: (Score:3)

        by Thud457 ( 234763 )

        random numbers tend to be treated almost as a religious argument rather than a technical one.

        Hail Eris!

  • what's that going to accomplish? (Score:1)

    by Anonymous Coward

    if the idea is not to trust the hardware implementation then why use it alongside "Yarrow" in the first place? This just seems like the glorious Foundation using recent news about the NASA as a self-promotion tactic and even to a layman it's a poor one. "Trust FreeBSD, we still use rdrand et. al., but we filter it through some vague algorithm called Yarrow that makes it safe!"

    You'll forgive me for not being entirely convinced, particularly when even the latest release of 10 still refuses to boot and instal

    • Re: what's that going to accomplish? (Score:5, Informative)

      by Anonymous Coward on Wednesday December 11, 2013 @05:24PM (#45664045)

      https://www.schneier.com/yarrow-qa.html

      your ignorance is unjustifiable

    • Re:what's that going to accomplish? (Score:5, Insightful)

      by houstonbofh ( 602064 ) on Wednesday December 11, 2013 @05:24PM (#45664049)
      Because true random in software is computationally expensive. Adding a layer of obfuscation on top of the untrusted hardware gives you a better random cheaply, and avoids potential back-doors in the hardware generator.

      • Not to mention insecure too.

        There are only so many milliseconds on the clock to use on the seed. Even if you use the mic statistically silence or a clicking sound will be heard for 90% of the users so that makes that seed bad too. Network? At home there is little traffic and even at work there are the same patterns from Cisco and HP for 80% of the packets.

        SGI had some interesting encryption methods that dealt with quantam mechanics on their servers and workstations. Man I miss them.

        • Re: (Score:2)

          by mlts ( 1038732 ) *

          I've wondered about using a very high speed flip-flops, or on a simpler thing, a SR latch with both inputs on, and sampling the output. I remember some cryptographically secure RNGs doing this in lieu of a radium-painted chip.

          • Re: (Score:2)

            by CoderJoe ( 97563 ) *

            This article [ieee.org] talks about Intel's design, which is based on two inverters in a ring. Both inverters are forced to the same state and then left to settle into one state or the other based on thermal noise. There's a bit more to it, but that is the basis.

        • Re: (Score:2)

          by LoRdTAW ( 99712 )

          I am not a cryptologist or crypto expert but what about the seed methods using a video camera looking at a lava lamp? I have also heard of pointing it out a busy window as the randomness of traffic, people, animals, tree movement etc. is quite random. Is it too slow or not random enough? What about a camera looking at a busy highway? I did a bit of googling and only found that the lavarand site is long gone but it was started by SGI back in the 90's. Another article described a cmos camera with the lens cap

      • Because true random in software is computationally expensive.

        True, if by "computationally expensive" you mean "we have to run this until the hardware breaks and starts executing our software non-deterministically".

        Otherwise, true randomness in software is simply infeasible, because chip engineers deliberately design the hardware to eliminate non-determinism.

        • Because true random in software is computationally expensive.

          True, if by "computationally expensive" you mean "we have to run this until the hardware breaks and starts executing our software non-deterministically".

          Otherwise, true randomness in software is simply infeasible, because chip engineers deliberately design the hardware to eliminate non-determinism.

          Yep. Just keep calculating until you find the dodgy bit of ram. :) (Not supported with ECC memory)

    • Yarrow is hardly vague. [schneier.com]

  • Makes sense ... (Score:5, Insightful)

    by MacTO ( 1161105 ) on Wednesday December 11, 2013 @05:20PM (#45664011)

    One of the features of open source software is that the code, thus the algorithms, can be examined by a third party. In the case of chips, this is very difficult to do. Most people are stuck trusting that the designer implemented the algorithm they said they did, and that they implemented it properly (the former implying no malice and the latter implying competence). That is particularly true for something like random number generators, which are intended to be non-deterministic as far as the software is concerned so any testing the implementation can only be done statistically. Very few people have the ability to examine the physical design of the chip to check the actual implementation.

  • Is there any way to gain trust in a chip? (Score:5, Interesting)

    by Jeremi ( 14640 ) on Wednesday December 11, 2013 @05:21PM (#45664019) Homepage

    Just out of curiosity: Given a "black box" implementation of a random number generator, is it possible to test its output sufficiently to gain some faith in its proper randomness?

    Seeing as such a piece of hardware need not (and hopefully would not) have any inputs, only an output, it's hard to imagine how someone might hide (and later trigger) a back-door mechanism that could change its behavior post-testing. (But I'm sure there is some way to do it that I'm not thinking of ;))

    • There are. But an even better option is probably to roll out your own.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      Black box? No. Even if testing proved it was absolutely random for the first N numbers, there is no way to be certain that N+1 is not the first of a string of non-random numbers.

      But it's not necessary to make it a black box. Physical systems take well known phenomena and use them to to generate random numbers. http://en.wikipedia.org/wiki/Random_number_generation#Physical_methods Done this way, you can make a "transparent box" that performs great and is trustworthy.

    • Re: (Score:2)

      by OzPeter ( 195038 )

      Just out of curiosity: Given a "black box" implementation of any device, is it possible to test its output sufficiently to gain some faith in its proper operation?

      Why do you stop at randomness? You are trusting a lot more hardware than just that when you use a computer.

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      Ok, I'll take a shot, here's two of them for you:

      1: Chip outputs the digits of pi starting at some crazy number of decimal places out that only the NSA has had enough hours on the supercomputer to find. Your chip now puts out data that you cannot distinguish from random, but that the NSA can perfectly predict. They go to their giant database of all of your internet traffic ever, and can now read whatever they would like, as all of your keys are now utterly, hopelessly broken.

      2: Chip internally stores the

      • 2: Chip internally stores the last n random numbers that it has output. Later, the NSA can confiscate your computer, subject the chip to some undocumented state that causes it to barf up its secrets, and again all your keys are now utterly, hopelessly broken.

        More likely its just going to get the random numbers generated for a video game.

        • If you're using /dev/random (or the Windows equivalent) instead of /dev/urandom for that, you're an idiot and probably have lots of open bugs related to your game hanging.

    • Re: (Score:2, Insightful)

      by SuperKendall ( 25149 )

      The output can be completely random, but it doesn't matter if someone else has a mechanism to reproduce exactly the same random stream. Or the ability to toggle on the semi-random mode...

      • AFAIK the term "random" refers to "non-deterministic"; that is, if you know you have a box here which you know will provide the same output as the box over there, neither one is "random".

    • Re: (Score:3)

      by AHuxley ( 892839 )
      Re 'output sufficiently to gain some faith in its proper randomness".
      Back when cypher machines where unique physical devices sold to gov for embassy use the US and UK had two options:
      Set their own device standard with Tempest to leak the plain text. Such a unit would pass all "proper" crypto testing as it was a real crypto unit. The plain text was leaking out as entered or printed and could be collected.
      The great aspect was "trust" form the end user and the message was "safe" for sending.
      The other opt

    • Just out of curiosity: Given a "black box" implementation of a random number generator, is it possible to test its output sufficiently to gain some faith in its proper randomness?

      Yes and No. One can statistically analyze output of the (pseudo) RNG and compare it to pure randomness, like atmospheric noise. However, you can't be sure there is no message in the stream. For example: Strong crypto produces enciphered data that looks exactly like pure randomness. It's one way we test for cryptographic strength. Indeed, BSD will now pipe RNG output through Yarrow (a pRNG based on hash functions) to produce randomness. Considering that knowing the initial state of a PRNG reveals its

    • Just out of curiosity: Given a "black box" implementation of a random number generator, is it possible to test its output sufficiently to gain some faith in its proper randomness?

      Short answer: No.

      Long answer: There is "statistical randomness" and "cryptographical randomness". "Statistical randomness" tells you whether a random number generator can be used reasonably to simulate random physical phenomena. "Cryptographical randomness" means that it is impossible to predict the next random number if you know the mechanism that produces the random numbers, and the previous sequence of random numbers. Statistical randomness can be tested. For example, if you calculate three random num

      • Just out of curiosity: Given a "black box" implementation of a random number generator, is it possible to test its output sufficiently to gain some faith in its proper randomness?

        gnasher719 gave a nice answer, and I just want to add more. For statistical purposes, a true and fair RNG printing a string of zeroes and ones would at the very least print a normal number [wikipedia.org], and to test for that, one would have to count the frequencies of substrings of every length, in every base, which of course can be done, but may get expensive if one wants a lot of confidence [wikipedia.org].

        What gnasher719 calls cryptographical randomness cannot be tested in practice, but in theory, one can run the countable set [wikipedia.org] of al

    • Re: (Score:3)

      by ras ( 84108 )

      Given a "black box" implementation of a random number generator, is it possible to test its output sufficiently to gain some faith in its proper randomness?

      The answer is an outright no.

      The thing that crypto depends on isn't that a stream of random numbers appears to be random. It is that the next number is utterly unpredictable. No one, not even the person who generated it, will know what it will be. This means if it is used as a key to protected some data, no one can predict what that key will be.

      One of

    • I have no doubt that the hardware-based random number generators works in the exact fashion that their manufacturers have specified. Given the amount of scrutiny that is presently being placed upon them I am certain that any sort of pattern in the entropy under normal operation would have been discovered by now.

      However, this does not preclude the existence of a backdoor which alters normal operation. Setup certain registers in a particular fashion, call an undocumented instruction, and boom, the random numb

    • At its most basic level, couldn't an RNG be implemented in hardware by putting in a JK flip flop w/ both inputs set to '1', so that a race condition develops? Put in enough bits, separate the flip flops some, and the outputs of some won't necessarily influence that of the others. Or even if they do, the probability will be... random!

      Do that w/ enough bits - say 512 - and you got a perfect RNG in the hardware. Some of the inputs could be near VDD, some near VSS and others far from either, and you'd ha

  • We have known for some time it is not impossible to hardcode a backdoor into a chip. I thought we already decided a while back that we cannot trust chip protection, in the past it was china chips but with the information given by snowden it only makes sense not to trust a chip from intel

  • nine nine nine... (Score:5, Funny)

    by jakedata ( 585566 ) on Wednesday December 11, 2013 @05:31PM (#45664125)

    http://dilbert.com/strips/comic/2001-10-25/ [dilbert.com]

    That's the problem with randomness, you can never be sure.

  • FYI, Linux did this 18 months ago (Score:5, Informative)

    by swillden ( 191260 ) <shawn-ds@willden.org> on Wednesday December 11, 2013 @05:51PM (#45664333) Journal

    One of the first things Ted Ts'o did when he took back maintainership of /dev/random in Linux was to stop depending solely on the hardware RNG.

    https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J?e

  • TRNG using discrete components? (Score:5, Interesting)

    by QuasiSteve ( 2042606 ) on Wednesday December 11, 2013 @06:22PM (#45664711)

    Given that it's stated that you can't trust a chip's encryption routines, which at the basis means that you don't trust its random number generator, and given that 'a chip' extends down from the latest Intel to a relatively lowly PIC, is anybody aware of an actually available TRNG (true/hardware random number generator) built out of discrete components?

    Comments to a Bruce Schneier post titled "Surreptitiously Tampering with Computer Chips" [schneier.com] once suggested this would be the only way to 1. be certain* of no tampering and 2. have reasonably sufficient output bandwidth to be used in practical applications.

    However, I haven't seen any actual implementation. My Google-fu may be failing me, though.

    * Barring some pretty sweet shenanigans like those pulled by Henryk Gasperowicz; [Spoiler video](https://www.youtube.com/watch?v=-KMLmpC7-Ls). I can't see manufacturers including any crypto-defeatery bits into a basic transistor thinking that it just might possibly be used in an actual crypto application, and eat the cost somehow.

  • It strikes me as concession packaged up as stand-offishness. But it still reads like concession. If you don't trust the chip, don't use the chip. Why all the song and dance just to say "well we're still relying on the chip, by the way" at the end? Can anybody say "sugar coat"? I would take them to task over it, if I had some kind of bargaining power of my own. I would say, "if you claim you don't trust the chip, then either you don't utilize the chip, at all, or I in turn don't trust your routines."

    • Trust in a random number generator is not a binary thing. All of the current hardware RNG implementations produce some entropy. The question is how much entropy you trust them to produce. If it gives 256 bits of entropy, then you can just use it as your random number source and be done with it. One that produces 16 bits of entropy is very useful as one (but not the sole) source to an algorithm like Yarrow of Fortuna, but would be a disaster if you used it as the random number generator without such an a

      • Re: (Score:2)

        by eyenot ( 102141 )

        It just seems so, so stupid to me that in the search for real encryption, we have to rely on pseudo-randomness, so then the entire point of contention comes down to a matter of how much "pseudo" we're willing to accept. My theory is that as science goes deeper into math and logic, we're going to result in consecutively more "reliable" PRNG but those will always be dismissed by later science, and will always raise the point of contention. It's not worth getting worked up over, and it's certainly never worth

  • FreeBSD has been using Yarrow for 10+ years, and no FreeBSD release has ever shipped with the option to feed the stream from a HWRNG directly to /dev/random. The only news here is that we have a new framework in the kernel for plugging hardware pseudo-random number generators into Yarrow, and an explicit policy (issued in my capacity as FreeBSD Security Officer) to not expose HWPRNGs directly to userland. There was some pressure from corporate users who want the raw feed for compliance reasons, but they wer

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close