Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Ultra-low-cost True Randomness

Posted by CmdrTaco on Mon Sep 10, 2007 10:04 AM
from the and-a-damn-fine-hack dept.
Cryptocrat writes "Today I blogged about a new method for secure random sequence generation that is based on physical properties of hardware, but requires only hardware found on most computer systems: from standard PCs to RFID tags." Basically he's powercycling memory and looking at the default state of the bits, which surprisingly (to me anyway) is able to both to fingerprint systems, as well as generate a true random number. There also is a PDF Paper on the subject if you're interested in the concept.
+ -
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by eldavojohn (898314) * <my/.username@@@gmail.com> on Monday September 10 2007, @10:07AM (#20539003) Homepage Journal
    A slightly more expensive but somehow even more random method is to seed the generator against the words and phrases that come out of the mouth of South Carolina's Miss Teen USA [youtube.com].

    But in all seriousness, I wonder how this compares to the Mersenne Twister [wikipedia.org] (Java implementation [gmu.edu] & PDF [hiroshima-u.ac.jp])that I use at home? I am almost sure this new proposed method is more efficient and faster, when will there be (I know, I'm lazy) a universal implementation of it? :)

    Also, this may be a stupid question, but I wonder how one measures the 'randomness' of a generator? Is there a unit that represents randomness? I mean, it would be seemingly impossible to do it using observation of the output so I guess all you can do is discuss how dependent it is on particular prior events and what they are, theoretically. Can you really say that this is 'more random' than another one because you have to know so much more before hand about the particular machine & its fingerprint in order to predict its generated number?
    • by BadAnalogyGuy (945258) <BadAnalogyGuy@gmail.com> on Monday September 10 2007, @10:13AM (#20539091)
      Randomness is definable.

      Why, take a look at this Wikipedia link [wikipedia.org]. You can never tell whether it represents the truth or some crackpot's claim to it or just some troll's malicious vandalism.

      Voila! Randomness!
      • Re: (Score:3, Insightful)

        by Mc1brew (1135437)
        That link brought me to the conclusion that randomness doesn't exist as much as I thought. It uses the example of rolling dice, random right? Not really... Just too many variables to consider over the given amount of time. *Density of dice *Placement of dice in hand *Distance of hand from table *Number of dice *Potential values of dice *Density of table *etc..... By the time you write down all the variables a value has been generated. Just because you didn't have enough time to evaluate the scenario, doe
    • I think the easiest way to measure "randomness" is to (whilst keeping the environment the same) generate a massive number of "random" numbers, and check the number of occurrences of values to their expected number of occurrences. Probability would dictate that a true random number generator would return values to within a tiny margin of what would be expected. The "unit" would probably be "standard deviations" (ie, the bad random number generator has a bias for $SOME_VALUE of 2 standard deviations)
      • Re: (Score:2, Insightful)

        123456789123456789123456789123456789123456789

        That's how to test uniformity, but not randomness.

      • Re: (Score:3, Insightful)

        by Matje (183300)
        it is a lot more tricky than that. Test your method against the following string:

        12345678901234567890

        See? The distribution of digits doesn't tell you a whole lot about the randomness of a stream.

        A nice way to define randomness is using Kolmogorov Complexity. A random number then is a number that cannot be represented by a program (in some code language) that is shorter than the random number itself. In other words: if the smallest program that outputs number X is the program "print X" then X is considered a
            • For instance, in the 123456789012345678901234567890 sequence example, any self-respecting compressor such as Zip would create something like "1234567890 times 3", which is pretty close to the shortest program which generates the sequence.

              perl -e 'print 1..9,0..9,0..9,0'
      • I think you'd also need some means of defining the randomness of distribution in your sequence. For instance, 01010101010101010101010101010101 doesn't look very random.
    • Re: (Score:3, Informative)

      by NetCow (117556)
      Mersenne Twister is not a random number generator, it's a pseudo-random number generator.

      Randomness is measured as entropy. See here for details: http://mathworld.wolfram.com/Entropy.html [wolfram.com]
    • The Mersenne Twister is a pseudo-random number generator. For many uses, this is preferable to a true random number generator as it is easily repeatable. (One can also repeat the results of a true random number generator by storing the output, but depending on how many random numbers you're generating, this might be space intensive.)

      That said, although this might be "true" randomness, what kind of randomness it is? Uniform over a range? Gaussian? Weibull? Most likely, none of the above if it can be used for fingerprinting systems. (No, I did not RTFA.)

      • Fingerprinting (Score:3, Informative)

        by jgoemat (565882)

        Most likely, none of the above if it can be used for fingerprinting systems. (No, I did not RTFA.)

        Basically some bits are more likely to be 0, some are more likely to be 1 and some are apparently random. Many cycles are done to identify which bits fall into which category. The ones more likely to be 0 or 1 are used to determine the fingerprint. The ones that appear to be totally random are used to generate random data.

    • Re: (Score:3, Insightful)

      by solafide (845228)
      Randomness is measured statistically using multiple tests: see Knuth, Art of Computer Programming Volume 2, Chapter 3 for a thorough discussion of common statistical randomness tests, or here [fourmilab.ch] for a practical testing tool.

      I don't expect this to be statistically random: they claim it's based on thermal noise. But the startup temperature of a computer does not have that much entropy, so the thermal noise isn't reliable. Just because something's garbage doesn't mean it's statistically random.

      • Thermal noise random number generators do not depend on temperature (unless cooled to liquid nitrogen temperatures). Normal room temperature provides quite enough random fluctuations for good generators.
    • by sholden (12227)
      You can do some stats on the output, for example: http://citeseer.ist.psu.edu/maurer92universal.html [psu.edu]

    • Re: (Score:2, Informative)

      Well, the theory goes something like this: the more wide and varied the seeds you feed to a random number generator, the more truly random your results. Many programs use a timestamp from the system clock as a seed, or even a timestamp as seed to put through the random number generator to get another random number that is used as a seed, etc. ad finitum. Of course, the system clock has only so much granularity, so based on that granularity there are a finite number of seeds for each 24 hour period. If yo
    • Also, this may be a stupid question, but I wonder how one measures the 'randomness' of a generator? Is there a unit that represents randomness? I mean, it would be seemingly impossible to do it using observation of the output so I guess all you can do is discuss how dependent it is on particular prior events and what they are, theoretically. Can you really say that this is 'more random' than another one because you have to know so much more before hand about the particular machine & its fingerprint in o

    • Re: (Score:2, Interesting)

      by kevmatic (1133523)
      Yeah, it can be measured. There is no unit, though, as its a measure of entropy. So things are more or less random than something else. I imagine randomness studying program assign numbers to it. a random number is just a number; '1' might be randomly selected out of 1 through 6, but its still just 1. But random number sets are considered random if, for every number, the chances of a the number after it being, say 4, are 1 in 10. So if you have a random set and come across a 1, the probability the next nu
      • Re: (Score:3, Interesting)

        by ThosLives (686517)

        There is no unit, though, as its a measure of entropy.

        Eh, well, the unit of entropy is actually "energy per temperature"*, so there are physical units associated with it. Of course, that's physical entropy, and I don't know that it's the same as "information entropy." If they're different, then I blame the folks that overload technical words.

        That said, I always thought "random" simply meant "the next outcome is not predictable based on all previous measurements." Therefore the measure of "random" would b

        • Re: (Score:3, Interesting)

          by sdedeo (683762)
          Entropy is fascinating. It's proportional to the logarithm of the number of microstates, but until the advent of quantum mechanics, there was not good way to number the microstates of a given physical system. Once you have the uncertainty principle, you can divide the phase space up into little chunks of volume (Planck's constant)^(dimensions) and count it that way.

          Another way to put it is that before the advent of quantum mechanics, every measurement of entropy was only meaningful in a relative, differe
    • Also, this may be a stupid question, but I wonder how one measures the 'randomness' of a generator?

      Read James Gleick's Chaos.

      There is a method in that book that describes how they extracted attractors from a stream of data. Here's how it works.

      A team of researchers had a bathtub with a dripping faucet. They tuned the dripping until the drips fell at random intervals. Nothing rhythmic about it. As the drop broke away from the faucet, it was setting up a vibration in the remaining water that would

  • Oblig. XKCD (Score:5, Funny)

    by IcedTeaisgood (1148451) on Monday September 10 2007, @10:15AM (#20539133)
  • OK, do we in this world have a problem with not sufficient randomness in our keys or something?
  • Is pretty low cost to get some randomness. Some friends like jug wine though. Although I'm extremely cheap, so I just go for 100 proof stuff. $12.00 and you can get a whole bottle of randomness.
  • The contents of a power-cycled DRAM cell are highly correlated to whatever was stored in it before power was lost. Geez, think about how a DRAM works... it's a capacitor (aka an integrator)! That's the last place I'd ever look for randomness.
    • Yeah, but the headline of the PDF says: "Initial SRAM state..."
    • by AmIAnAi (975049) *
      TFA talks about SRAM, rather than DRAM. So there's no capacitor involved for data storage - each cell is a transistor-based state machine.
  • by G4from128k (686170) on Monday September 10 2007, @10:25AM (#20539281)
    I wouldn't assume that these fingerprints are as unique or pattern-less as one might hope (a fact discussed in the pdf). All of the RAM chips from a given wafer or given mask may share tendencies toward some patterns of the probability of a 0 or 1. These patterns may appear as correlations between rows and columns of a given chip. Location on the wafer (in the context of nonuniformities of exposure to fab chemicals) might also systematically affect the aggregate probabilities of 0 or 1 or the repeatability of the fingerprint. The quality of these fingerprints to be consistent or random might change from run to run and from manufacturer to manufacturer. Finally, I'd bet that the probabilities vary systematically with temperature -- e.g., the probability of a 1 increases for all bits as the chip's temperature increases.

    This is a very interesting phenomenon, but a lot more data is needed to show that it provides consistent behavior.
  • Will vary with the length of time the computer has been off. There is a suprising amount of non-volatileness in DRAM. I liked Alan Touring's suggestion that all computers come equiped with a small radioactive source and detector. The random breakdown and emission of the source is an almost ideal random number generator. It wouldn't take a source any bigger than we now have in a smoke detector.
  • Pick a question. Then keep asking that question to a politician. You should get truly randomized results. If you doubt me, just take a politician with an opposite stance, and repeat the process. The answers will not be polar opposites.
    And consequently no information could be extracted that scenerio -- wow, I think I just proved that you can't transmit information across a quantum entanglement..
  • by nweaver (113078) on Monday September 10 2007, @10:29AM (#20539357) Homepage
    the true RNG properties rely on the fact that:

    a: Many of the bits are sorta random, but physically random. So very biased coins, but true randomness.

    b: With the right reduction function, you can turn a LOT (eg, 512 Kb) of cruddy random data to a small amount (128b-512b) of very high quality, well distributed random.

    And the fingerprinting relies on the fact that:

    a: Many other of the bits are physically random, but VERY VERY biased. So map where those are and record them and it is a very good fingerprint. And since it is all silicon process randomness going into that, it is pretty much a physically unclonable function.

    Kevin Fu has some SMART grad students.
    • Re: (Score:3, Funny)

      by Dirtside (91468)

      Kevin Fu has some SMART grad students.

      I wonder how often they go around saying to people, "Whoa. I know Kevin Fu."
  • by gillbates (106458) on Monday September 10 2007, @10:33AM (#20539421) Homepage Journal

    As an embedded engineer, I've encountered numerous cases where power cycling RAM did not alter the contents.

    In fact, I've seen systems boot and run even after the power was cut for several seconds. Some types of SRAM and SDRAM have the ability to retain an (imperfect) memory image even at very low voltage levels. Sure, it's not guaranteed to be accurate by the manufacturer, but RAM "images" are a pretty well known phenomenon. In some cases, the contents of memory can be reconstructed even after the computer has been powered off and removed to a forensic laboratory.

    This is not random at all. In fact, it's more likely to produce an easily exploitable RNG than anything else; I would not be at all surprised if the standard UNIX random number generator provided better security.

    • by tlhIngan (30335) <(slashdot) (at) (worf.net)> on Monday September 10 2007, @11:54AM (#20540781)

      As an embedded engineer, I've encountered numerous cases where power cycling RAM did not alter the contents.

      In fact, I've seen systems boot and run even after the power was cut for several seconds. Some types of SRAM and SDRAM have the ability to retain an (imperfect) memory image even at very low voltage levels. Sure, it's not guaranteed to be accurate by the manufacturer, but RAM "images" are a pretty well known phenomenon. In some cases, the contents of memory can be reconstructed even after the computer has been powered off and removed to a forensic laboratory.

      This is not random at all. In fact, it's more likely to produce an easily exploitable RNG than anything else; I would not be at all surprised if the standard UNIX random number generator provided better security.


      I've had this bite me, and exploited it.

      It bit me when booting into Windows CE - you'd power cycle the thing, and the OS would boot with the old RAM disk you had - we'd gotten to the point where we'd have the bootloader wipe the kernel memory so the data structures were all corrupted by the time the OS was trying to decide between mounting the RAM disk (object store) and starting fresh. It turns out that the longer an image is unchanged in RAM, the more likely the cells woudl be biased such that if you cycle the power on them, they're more likely to lean towards the way they were before power was cut.

      The time I exploited it, I didn't have any way of logging. Logging to serial port caused issues (timing-sensitive code), so I logged to memory (and no, I had no filesystem running, so I couldn't log to file). My trick was to simply log to a circular RAM buffer. When it crashed, I would just power cycle and dump the RAM buffer. Even though the data was fresh, it was enough to make out what my debug message was trying to say (almost always perfect). This was readable after a brief power cycle, and was still readable after turning power off for nearly a minute. The characters got corrupted, but since it was regular ASCII, you could still make out the words.
    • by nickovs (115935) on Monday September 10 2007, @12:16PM (#20541137)
      There are a couple of things to note here. Firstly, SDRAM and SRAM behave very differently. Synchronous dynamic RAM can retain charge in the capacitors for quite some time after being powered down and there is very little one can do about it, but the paper discusses static RAM. With static RAM there is a difference between being "powered off" and having the Vcc rail clamped to ground. Active clamping of the power line is much more effective at clearing the RAM than even just disconnecting it from the power supply, for reasons which become obvious when you look at a classic six transistor CMOS RAM circuit [wikipedia.org]. Without clamping, bias will remain for exactly the same reason that SRAM doesn't consume much power; current only flows when the data changes.

      As for it being a good RNG; the state of RAM on power-up is probably a lousy "random number generator", but the statistics in the paper suggest it is a fairly good "source of randomness". There's a big difference between bias and unpredictability (think about dice with '1' on five of the sides and '0' on the remaining side). You wouldn't want to use the state without putting it through a compression function first, but it's a much better seed than using clock() [berkeley.edu]!
  • by operagost (62405) on Monday September 10 2007, @10:43AM (#20539605) Homepage Journal
    You can never be sure [random.org].
  • by Quila (201335) on Monday September 10 2007, @10:43AM (#20539615)
    Learn How To Use Capital Letters At The Beginning Of Sentences!
  • by fubob (7626) on Monday September 10 2007, @10:44AM (#20539633) Homepage
    We were surprised to suddenly get attention to this paper, but apparently Slashdot readers are watching the security seminar at UMass Amhest.

    Anyhow, we will be answering questions in this thread. So if you have any questions, post them here and Dan Holcomb will get back to you as soon as he can.

    Cheers,
    -Kevin Fu
  • by rpp3po (641313) on Monday September 10 2007, @10:55AM (#20539883)
    The original paper is much better than CmdrTaco's quick conclusions.
    The described method is ONLY for SRAM (statical RAM), no DRAM, no SDRAM. You can find this on RFID chips and in a CPU'S cache, not in RAM. As there is no way to access a CPU's cache uninitialized, I can't see why this should be useful.
    If you have to modify a CPU first, to allow access to it's unitialized caches (think about all the unwanted implications), it's much cheaper to just give it a thermal diode and register to poll (as most modern CPU's already have).
    After all the described method is just another way of collecting thermal noise. As RFID's are custom designs most of the time, also there it would be cheaper to just use a thermal diode.
    The only application for this would be if you had to develop strong crypto for legacy RFID chips.
    Slashdot stories get worse by the day.
  • HotBits (Score:3, Informative)

    by The -e**(i*pi) (1150927) on Monday September 10 2007, @01:36PM (#20542457)
    The only way I know of generating truly random numbers (not psudorandom) is hot bits which works on the principle of single radioactive atoms decaying after a perfectly random, in every sense of the word, time. http://www.fourmilab.ch/hotbits/ [fourmilab.ch]
  • by ironring (598705) on Monday September 10 2007, @03:01PM (#20543831)
    This is a bit of old news. I have already authored and been granted several patents in this area.
    6,906,962 Method for defining the initial state of static random access memory
    6,828,561 Apparatus and method for detecting alpha particles
    6,738,294 Electronic fingerprinting of semiconductor integrated circuits
    I have several other ideas for application of this technology and would be happy to discuss if someone is interested.
    Paul
    • by BadAnalogyGuy (945258) <BadAnalogyGuy@gmail.com> on Monday September 10 2007, @10:10AM (#20539047)
      23423483837223429723432891023478343589435892

      You would expect that, you fucking pervert.
        • Re:Four (Score:5, Informative)

          by ukatoton (999756) on Monday September 10 2007, @10:47AM (#20539693)
          RTFA
          There are 3 states the bits can fall into:

          1. initially (almost) always 0
          2. initially 0 or 1 with somewhat even probability
          3. initially (almost) always 1

          Using the bits that fall into category 2 to generate the number will result in a random number, as these are known to change randomly

          since it is now known which bits will change with each power cycle, those bits can be used as a source of true randomness


          Bits falling into the other two states are ignored for the random function and are used for the identification function.
          • Re:Four (Score:4, Informative)

            by ajs (35943) <ajs@noSpAm.ajs.com> on Monday September 10 2007, @01:53PM (#20542751) Homepage Journal
            I'm not entirely clear on why this is more interesting than just using timing like most of the rest of the world does. Perl has, for example, long used a setjmp/longjmp-based timing test for its Math::TrulyRandom [cpan.org] package by Matt Blaze and Don Mitchell of AT&T and of course most modern Unix-like systems implement /dev/random and /dev/urandom again based on timing. RFC1750 [ietf.org] has given useful directions on how to generate random numbers on generic hardware for well over a decade. I recall first reading this RFC, not long after it came out. It really changed my understanding of random numbers on computer hardware.

            This just doesn't seem all that newsworthy, though it's cool enough as yet another random number generation technique, I suppose.
            • Re: (Score:3, Informative)

              by psmears (629712)

              If I have a die that is weighted to land on 5 or 6 almost every time, it's not random.

              It is random, it just isn't fair.

              What's more, you can use it to generate fair, random 0s and 1s: throw it twice, and if you get 5-6, that's a 0; if you get 6-5, that's a 1. If you get two of the same number (5-5/6-6), repeat from the start. Assuming the throws are independent (i.e. it has no memory), and the probabilities of 5&6 are both greater than zero, you'll get a 0 or 1 with equal probability.

              The article plays a similar trick, but it uses a hash function to even out the probabilities...

    • I think I know the answer, but I've RTFA, so it doesn't count.
    • by Goaway (82658)
      Because the output of the method is not a truly random number. It is a number with some amount of randomness and some amount of regularity. To fingerprint, you look for the regularity, and to make random numbers, you refine the randomness through some kind of hash function.
    • Re: (Score:3, Informative)

      by Stripe7 (571267)
      Read the article, there are 3 states for bits of RAM at power up. 1. Always 0 2. 50/50 flipping between 0 and 1 3. Always 1 For fingerprint use 1 and 3 and mask out the flipping bits, for Randomness mask out the consistent bits.