Re: CPRNGs are still an issue.
Charles Jackson wrote: I probably should not be commenting, not being a real device guy. But, variations in temperature and time could be expected to change SSD timing. Temperature changes will probably change the power supply voltages and shift some of the thresholds in the devices. Oscillators will drift with changes in temperature and voltage. Battery voltages tend to go down over time and up with temperature. In addition, in some systems the clock frequency is purposely swept over something like a 0.1% range in order to smooth out the RF emissions from the device. (This can give a 20 or 30 dB reduction in peak emissions at a given frequency. There is, of course, no change in total emissions.) Combine all of these factors, and one can envision the SSD cycles taking varying numbers of system clock ticks and consequently the low order bits of a counter driven by a system clock would be random. However, one would have to test this kind of entropy source carefully and would have to keep track of any changes in the manufacturing processes for both the SSD and the processor chip. Is there anyone out there who knows about device timing that can say more? As a chip wonk, without addressing SSD operational timing directly how much a clock can change is dependent on the accuracy over a period of time sufficient to be off by one or more clocks, implying long counter chain timing - slow entropy accumulation at best. Worse still, the error value when compared to an outside clock source would tend to be at a fixed rate, although you see minor variations based on temperature and voltage. The same things that make power analysis a valid attack also influence temperature and voltage. I'd expect you could manipulate second order effects by how the system is operated. Other than effects on frequency, temperature and voltage affect switching thresholds which can cause variability in delay in particular when crossing clock domains. These threshold delays can be strongly correlated. Dithered clocks are intended to only fool spectrum analyzers measuring peak power and are not based on entropy or second order effects. A PLL feedback pattern is typically masked by applying the output of a counter and look up table or combinatoric circuit. There is no disparity generated long term in clock high and low bauds, the counter makes the dithering periodic. Think short PRNG cyclically applying clock edge offsets and hitting all the positive and negative offsets equally. The two don't strike me as sufficient to construct an adequate ergodic system. Using a HDD as an 'entropy' source is based on operating an ergodic system where the preceding state is not readily predictable. The variability is based in part on sectors and cylinders, angular velocity, disk position and head position. All that variability can collapse in an SSD. Trying to rely on remaining secondary effects for loss of predictability could be countered by eliminating or reducing them. We design systems to not be readily influenced by secondary effects in the first place. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Wed, Dec 17, 2008 at 03:02:54PM -0500, Perry E. Metzger wrote: The longer I'm in this field, the more the phrase use with extreme caution seems to mean don't use to me. More and more, I think that if you don't have a really good way to test and get assurance about a component of your security architecture, you should leave that component out. But do beware of becoming something of a luddite w.r.t. entropy sources. If you can mix seeds into your entropy pool without destroying the entropy of your pool (and we agree that you can) while adding some of any entropy in your seeds (and we agree that you can), then why not? Yes, I saw your other message. Testing entropy pools and sources is hard if you want real entropy. One way to test the pool and its mixing function is to add and use a hook for supplying test vectors instead of real entropy for each source. But to test the operational system, if it has real entropy sources, is harder. So you might as well add in a fixed, manufacture-time seed + time/counter-based salting, as you suggested. And you'll still want to test the result, but you can only apply statistical analysis to the outputs to decide if they're random-*looking*. Having no entropy sources is not a good option for systems where the threat model requires good entropy sources (e.g., if you want PFS to prevent compromise of an end-point from compromising pre-compromise communications). IMO it's not wise to trivially reject an all of the above approach to entropy gathering. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Tue, 16 Dec 2008, mhey...@gmail.com wrote: On Thu, Dec 11, 2008 at 8:42 PM, Damien Miller d...@mindrot.org wrote: On Thu, 11 Dec 2008, James A. Donald wrote: If one uses a higher resolution counter - sub microsecond - and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true random. Until someone runs your software on a SSD instead of a HDD. Oops. Before we give up on using drive timings, does anyone have evidence to verify this assertion? The reviews I have seen using tools like HD Tune and HD Tach seem to show timing noise reading and writing SSDs. I don't know where the noise comes from - it is probably not turbulence grin/ - but it may be random enough that a long series of tests, say for a second or so (don't forget, these drives are fast), could provide a nice pool of unguessable bits. I think you have it quite backwards - in the absence of good evidence that transaction timings on SSDs are dependent on some physically unpredictable process (air turbulence, shot noise, etc.) then they should not be considered suitable for cryptographic use, no matter how random looking they are. -d - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Dec 16, 2008, at 12:10 PM, Simon Josefsson wrote: ...I agree with your recommendation to write an AES key to devices at manufacturing time. However it always comes with costs, including: 1) The cost of improving the manufacture process sufficiently well to make it unlikely that compromised AES keys are set in the factory. 2) The cost of individualizing each device. Each of these costs can be high enough that alternative approaches can be cost-effective. (*) My impression is that the cost and risks in 1) are often under-estimated, to the point where they can become a relatively cheap attack vector. /Simon (*) In case anyone doubts how the YubiKey works, which I'm affiliated with, we took the costs in 1) and 2). But they are large costs. We considered to require users to go through an initial configuration step to set the AES key themselves. However, the usability cost in that is probably higher than 1) and 2). Configuration at installation seems to be worth considering. It's a matter of making that as easy as possible. Asking users for the AES key is not easy - people aren't good at generating, or even entering, random 128-bit strings. However, you might be able to get them to push a reset button - or even connect and disconnect the device - a number of times and use the timing as a source of entropy. For something like a network interface, it might be reasonable to assume that an attacker is unlikely to be present at exactly the time of initial configuration, so simply pulling bits off the wire/out of the air during initialization isn't unreasonable. In general, given the assumption that it's easier to keep the initialization environment reasonably secure than it is the general fielded environment, and that you can afford much more time during initial configuration than is likely during normal operation, all kinds of things that are marginal if used operationally may be workable for initial configuration. (Also, of course, operational use may be unattended, but in most cases you can assume that initial configuration is attended.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Dec 16, 2008, at 4:22 PM, Charles Jackson wrote: I probably should not be commenting, not being a real device guy. But, variations in temperature and time could be expected to change SSD timing. Temperature changes will probably change the power supply voltages and shift some of the thresholds in the devices. Oscillators will drift with changes in temperature and voltage. Battery voltages tend to go down over time and up with temperature. In addition, in some systems the clock frequency is purposely swept over something like a 0.1% range in order to smooth out the RF emissions from the device. (This can give a 20 or 30 dB reduction in peak emissions at a given frequency. There is, of course, no change in total emissions.) Combine all of these factors, and one can envision the SSD cycles taking varying numbers of system clock ticks and consequently the low order bits of a counter driven by a system clock would be random. However, one would have to test this kind of entropy source carefully and would have to keep track of any changes in the manufacturing processes for both the SSD and the processor chip. Is there anyone out there who knows about device timing that can say more? I'm not a device guy either, but I've had reason to learn a bit more about SSD's than is widely understood. SSD's are complicated devices. Deep down, the characteristics of the underlying storage are very, very different from those of a disk. Layers of sophisticated hardware/firmware intervene to make a solid- state memory look like a disk. To take a very simple example: The smallest unit you can read from/write to solid state memory is several times the size of a disk block. So to allow software to continue to read and write individual disk blocks, you have to do a layer of buffering and blocking/deblocking. A much more obscure one is that the throughput of the memory is maximum when you are doing either all reads or all writes; anywhere in between slows it down. So higher- performance SSD's play games with what is essentially double buffering: Do all reads against a segment of memory, while sending writes to a separate copy as well as a look-aside buffer to satisfy reads to data that was recently written. Switch the roles of the two segments at some point. Put all this together and the performance visible even at the OS driver level will certainly show all kinds of variation. However, just because there's variation doesn't mean there's entropy to be had! You'd need to have a sufficiently detailed model of the inner workings of the SSD to be confident that the variations aren't predictable. However, you're not likely to get that: Getting good performance out of SSD's is a black art. The techniques are highly proprietary right now, because they are what make an SSD competitive. Further, of course, anything you did learn would likely apply to one manufacturing run of one model - just about anything could change at any time. So ... use with extreme caution. Estimate conservatively. Mix any apparent entropy you get with other sources. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Jerry Leichter leich...@lrw.com writes: SSD's are complicated devices. Complexity makes it hard to understand the security characteristics of relying on the timing of the devices. So ... use with extreme caution. Estimate conservatively. Mix any apparent entropy you get with other sources. The longer I'm in this field, the more the phrase use with extreme caution seems to mean don't use to me. More and more, I think that if you don't have a really good way to test and get assurance about a component of your security architecture, you should leave that component out. That's one reason I recommended just use AES in counter mode as the best way to generate random numbers in a low cost embedded context -- it is easy to get assurance simply by running AES validation tests, and you confine your risk to one easily examined part of the process, the key generator in the factory. I'm reminded of Tony Hoare's old saw about systems: There are two ways of constructing a software design: One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Wed, 17 Dec 2008 13:02:58 -0500 Jerry Leichter leich...@lrw.com wrote: On Dec 16, 2008, at 4:22 PM, Charles Jackson wrote: I probably should not be commenting, not being a real device guy. But, variations in temperature and time could be expected to change SSD timing. Temperature changes will probably change the power supply voltages and shift some of the thresholds in the devices. Oscillators will drift with changes in temperature and voltage. Battery voltages tend to go down over time and up with temperature. In addition, in some systems the clock frequency is purposely swept over something like a 0.1% range in order to smooth out the RF emissions from the device. (This can give a 20 or 30 dB reduction in peak emissions at a given frequency. There is, of course, no change in total emissions.) Combine all of these factors, and one can envision the SSD cycles taking varying numbers of system clock ticks and consequently the low order bits of a counter driven by a system clock would be random. However, one would have to test this kind of entropy source carefully and would have to keep track of any changes in the manufacturing processes for both the SSD and the processor chip. Is there anyone out there who knows about device timing that can say more? I'm not a device guy either, but I've had reason to learn a bit more about SSD's than is widely understood. SSD's are complicated devices. Deep down, the characteristics of the underlying storage are very, very different from those of a disk. Layers of sophisticated hardware/firmware intervene to make a solid- state memory look like a disk. To take a very simple example: The smallest unit you can read from/write to solid state memory is several times the size of a disk block. So to allow software to continue to read and write individual disk blocks, you have to do a layer of buffering and blocking/deblocking. A much more obscure one is that the throughput of the memory is maximum when you are doing either all reads or all writes; anywhere in between slows it down. So higher- performance SSD's play games with what is essentially double buffering: Do all reads against a segment of memory, while sending writes to a separate copy as well as a look-aside buffer to satisfy reads to data that was recently written. Switch the roles of the two segments at some point. But what is the *physical basis* for the randomness? http://www.springerlink.com/content/gkbmm9nuy07kerww/ (full text at http://world.std.com/~dtd/random/forward.pdf) explains why hard drive timings are considered random; are their comparable phenomena for SSDs? (Of course -- that's a '94 paper; hard drive technology has changed a lot. Would they still get the same results?) --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Bill Frantz fra...@pwpconsult.com writes: I find myself in this situation with a design I'm working on. I have an ARM chip, where each chip has two unique numbers burned into the chip for a total of 160 bits. I don't think I can really depend on these numbers being secret, since the chip designers thought they would be useful for DRM. It certainly will do no harm to hash them into the pool, and give them a zero entropy weight. The ARM family are particularly problematic for entropy gathering because anything that'd help you is (a) locked away so it can't be accessed and (b) not easily ascertainable at runtime. For the x86 equivalent you just do a CPUID (and you can in turn check whether the architecture supports that before you use it if you're on an old-enough system) and from there can execute further instructions to determine hardware capabilities and read/use them via MSRs as required. For the ARM the equivalent is a CP15 read (and then further accesses to the ARM equivalent of x86 MSRs), e.g.: asm volatile ( mrc p15, 0, r0, c0, c0, 0\n\t str r0, %0\n : =m(processorID) : : cc, r0); but this is only accessible in supervisor mode so for any normal app it's an instant illegal instruction fault. Furthermore, even in supervisor mode there's no way to bootstrap your way up as you can for x86 and tap the amazing store of hard-to-predict information that most ARM cores make available because each ARM implementation adds its own oddball registers and the only way to know whether they're present and usable is if you know in advance which specific core and stepping you're working with. In other words you can't get there from here and even if you could you wouldn't know what to do when you got there. So everything you need is there, you just can't use it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: CPRNGs are still an issue.
-Michael Heyman Wrote: Before we give up on using drive timings [as an entropy source], does anyone have evidence to verify this assertion [that SSD drives will have much less variation in read/write timing]? The reviews I have seen using tools like HD Tune and HD Tach seem to show timing noise reading and writing SSDs. I don't know where the noise comes from - it is probably not turbulence grin/ - but it may be random enough that a long series of tests, say for a second or so (don't forget, these drives are fast), could provide a nice pool of unguessable bits. == I probably should not be commenting, not being a real device guy. But, variations in temperature and time could be expected to change SSD timing. Temperature changes will probably change the power supply voltages and shift some of the thresholds in the devices. Oscillators will drift with changes in temperature and voltage. Battery voltages tend to go down over time and up with temperature. In addition, in some systems the clock frequency is purposely swept over something like a 0.1% range in order to smooth out the RF emissions from the device. (This can give a 20 or 30 dB reduction in peak emissions at a given frequency. There is, of course, no change in total emissions.) Combine all of these factors, and one can envision the SSD cycles taking varying numbers of system clock ticks and consequently the low order bits of a counter driven by a system clock would be random. However, one would have to test this kind of entropy source carefully and would have to keep track of any changes in the manufacturing processes for both the SSD and the processor chip. Is there anyone out there who knows about device timing that can say more? Chuck Jackson - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
=?ISO-8859-1?Q?Joachim_Str=F6mbergson?= joac...@strombergson.com writes: Damien Miller wrote: Until someone runs your software on a SSD instead of a HDD. Oops. That is a very good observation. I would bet loads of GM stocks that very few people realise that moving from 0ld sk00l HDD to SSD would affect their entropy sources. This is only going to be a problem if your RNG is... well, to be blunt, stupid enough to rely entirely on HDD timings as an entropy source. I would hope that any well-designed entropy polling system would use as many sources as possible for the simple reason that otherwise a single failure can destroy the security of your entire system. In other words an entropy polling mechanism should see the change from HDD to SSD as nothing more than a small glitch for its fault-tolerant front-end to accomodate and continue as before. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Dec 15, 2008, at 2:28 PM, Joachim Strömbergson wrote: ...One could probably do a similar comparison to the increasingly popular idea of building virtual LANs to connect your virtualized server running on the same physical host. Ethernet frame reception time variance as well as other real physical events should take a hit when moving into the virtualization domain. After all, replacing physical stuff with SW is the whole point of virtualization. Does anybody know what VMware, Parallels etc do to support entropy for sources like this, or is it basically a forgotten/skipped/ignored feature? They don't seem to be doing very much yet - and the problems are very real. All sorts of algorithms assume that an instance of a running OS has some unique features associated with it, and at the least (a) those will be fairly stable over time; (b) there will never be two instances at the same time. In different contexts and uses, virtualization breaks both of these. The virtual image captures everything there is to say about the running OS and all its processes. Nothing stops you from running multiple copies at once. Nothing stops you from saving an image, so replaying the same machine state repeatedly. Conversely, if something in the underlying hardware is made available to provide uniqueness of some kind, the ability to stop the VM and move it elsewhere - typically between almost any two instructions - means that you can't rely on this uniqueness except in very constrained ways. People move to virtualization with the idea that a virtual machine is just like a physical machine, only more flexible. Well - it's either just like, or it's more flexible! It can't be both. In fact, more flexible is what sells virtualization, and the effects can be very subtle and far-reaching. We don't really understand them. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Aloha! Damien Miller wrote: On Thu, 11 Dec 2008, James A. Donald wrote: If one uses a higher resolution counter - sub microsecond - and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true random. Until someone runs your software on a SSD instead of a HDD. Oops. That is a very good observation. I would bet loads of GM stocks that very few people realise that moving from 0ld sk00l HDD to SSD would affect their entropy sources. Does anybode have any idea if this has been discussed among OS Dev groups? One could probably do a similar comparison to the increasingly popular idea of building virtual LANs to connect your virtualized server running on the same physical host. Ethernet frame reception time variance as well as other real physical events should take a hit when moving into the virtualization domain. After all, replacing physical stuff with SW is the whole point of virtualization. Does anybody know what VMware, Parallels etc do to support entropy for sources like this, or is it basically a forgotten/skipped/ignored feature? -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. Kryptoblog - IT-säkerhet på svenska http://www.strombergson.com/kryptoblog - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Damien Miller wrote: On Thu, 11 Dec 2008, James A. Donald wrote: If one uses a higher resolution counter - sub microsecond - and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true random. Until someone runs your software on a SSD instead of a HDD. Oops. How would software that attempted to measure the entropy of the incoming seek times behave when an SSD replaced an HDD? Would the reduction in measured entropy be proportional to the reduction in entropy from the attacker's point of view? -- __ \/ o\ Paul Crowley /\__/ www.ciphergoth.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Bill Frantz fra...@pwpconsult.com wrote: Short of building special random number generation hardware, does anyone have any suggestions for additional sources? Any unused input device with noise can be used. Examples: Soundcard: http://www.av8n.com/turbid/ Camera: http://www.lavarnd.org/ If anything in the system changes a lot, like processes starting and stopping or files opening closing, periodically hashing the tables that describe that state is useful. Is your threat model one-sided? e.g. for a home router, attacks from the Internet side might be more of a worry than attacks from the LAN. In that case, things like packet timing on the LAN side are unknown to the feared attacker. Also, if you are doing NAT, the port numbers on the LAN side since those are not sent outside. If the device does any crypto, mixing ciphertext into the pool is nowhere near ideal since you would not be encrypting unless some enemy might get the text and using things an an enemy can get is exactly what you do not want here. However, it is cheap and random-looking, and the volume is proportional to the amount of crypto done, so it might help in some cases. -- Sandy Harris, Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Dec 15, 2008, at 2:09 PM, Perry E. Metzger wrote: Bill Frantz fra...@pwpconsult.com writes: I find myself in this situation with a design I'm working on. I have an ARM chip, where each chip has two unique numbers burned into the chip for a total of 160 bits. I don't think I can really depend on these numbers being secret, since the chip designers thought they would be useful for DRM. It certainly will do no harm to hash them into the pool, and give them a zero entropy weight. The system will be built with SSD instead of HDD, so Damien's comment hits close to home. I hope to be able to use timing of external devices, the system communicates with a number of these, along with a microsecond counter to gather entropy from clock skew between the internal clock and the clocks in those devices. Unfortunately the system doesn't normally have a user, so UI timings will be few and far between. Short of building special random number generation hardware, does anyone have any suggestions for additional sources? Given the usual threat model for a device like this, I'd just store an AES key at the factory and use it in counter mode (or something very similar) as your PRNG. Agree in general. Just one point: One big issue might be that if you can't store the counter across device resets, you will need a new layer of indirection -- the obvious one is to generate a new AES key at boot, perhaps by CBCing the real time clock with the permanent AES key and use the new key in counter mode for that session. This strikes me as additional complication for little purpose. Keep the same AES key - in fact, it might even be useful to either store the generated key schedules or even to generate open code for the particular device-specific key. Take the real time clock's value for the upper 64 bits of a the input to AES, and use a counter starting at 0 for the lower 64 bits. As long as the precision of the RTC is sufficient that you can never have two boots with the same value, you're fine. (If you actually have a bigger RTC values you can throw away low-order bits.) Given that we *are* assuming an SSD, of course, you could presumably store values across boots - though there are advantages to the RTC, since it avoids having to have special cases for things like the initialization of the stored value and recovery if the SSD is replaced. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Perry E. Metzger wrote: [Snip admirably straightforward threat and requirements analysis] Yes, you can attempt to gather randomness at run time, but there are endless ways to screw that up -- can you *really* tell if your random numbers are random enough? -- and in a cheap device with low manufacturing tolerances, can you really rely on how consistent things like clock skew will be? Given the previous discussion on combining entropy, it shouldn't hurt, as long as it's testable during manufacture. Lets contrast that with AES in counter mode with a really good factory installed key. It is trivial to validate that your code works correctly (and do please do that!) It is straightforward to build a device to generate a stream of good AES key at the factory, and you need only make sure that one piece of hardware is working correctly, rather than all the cheap pieces of hardware you're churning out. Ah, here's the rub. I like this testing requirement. The recent FreeBSD Security Advisory was merely a simple failure of initialization -- yet wasn't caught for the longest time, because it wasn't readily testable. One big issue might be that if you can't store the counter across device resets, you will need a new layer of indirection -- the obvious one is to generate a new AES key at boot, perhaps by CBCing the real time clock with the permanent AES key and use the new key in counter mode for that session. As long as the testing procedure validates the key and key+RTC separately. This does necessitate an extra manufacturing step in which the device gets individualized, but you're setting the default password to a per-device string and having that taped to the top of the box anyway, right? If you're not, most of the boxes will be vulnerable anyway and there's no point... Recently, I was pleasantly surprised that the ATT U-verse box had this! Unlike the ATT 2wire boxes we were installing just this summer. If we could only get Linksys, et alia on board - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Thu, Dec 11, 2008 at 8:42 PM, Damien Miller d...@mindrot.org wrote: On Thu, 11 Dec 2008, James A. Donald wrote: If one uses a higher resolution counter - sub microsecond - and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true random. Until someone runs your software on a SSD instead of a HDD. Oops. Before we give up on using drive timings, does anyone have evidence to verify this assertion? The reviews I have seen using tools like HD Tune and HD Tach seem to show timing noise reading and writing SSDs. I don't know where the noise comes from - it is probably not turbulence grin/ - but it may be random enough that a long series of tests, say for a second or so (don't forget, these drives are fast), could provide a nice pool of unguessable bits. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Perry E. Metzger pe...@piermont.com writes: This does necessitate an extra manufacturing step in which the device gets individualized, but you're setting the default password to a per-device string and having that taped to the top of the box anyway, right? If you're not, most of the boxes will be vulnerable anyway and there's no point... Not quite, you can optimize that. Some software (e.g., OpenWRT) forces users to access the device via (local) ethernet before wireless is enabled. This enables security aware people to configure wireless security, and avoid a period of insecure wireless network. Incidentally, this approach also enables devices to collect entropy from the user session. That could be useful when generating SSH private keys. (Although I believe, unfortunately, OpenWRT generates the SSH key directly after the first boot. It seems unclear what kind of entropy it can hope to have at that point?) I agree with your recommendation to write an AES key to devices at manufacturing time. However it always comes with costs, including: 1) The cost of improving the manufacture process sufficiently well to make it unlikely that compromised AES keys are set in the factory. 2) The cost of individualizing each device. Each of these costs can be high enough that alternative approaches can be cost-effective. (*) My impression is that the cost and risks in 1) are often under-estimated, to the point where they can become a relatively cheap attack vector. /Simon (*) In case anyone doubts how the YubiKey works, which I'm affiliated with, we took the costs in 1) and 2). But they are large costs. We considered to require users to go through an initial configuration step to set the AES key themselves. However, the usability cost in that is probably higher than 1) and 2). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
d...@mindrot.org (Damien Miller) on Friday, December 12, 2008 wrote: On Thu, 11 Dec 2008, James A. Donald wrote: If one uses a higher resolution counter - sub microsecond - and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true random. Until someone runs your software on a SSD instead of a HDD. Oops. I find myself in this situation with a design I'm working on. I have an ARM chip, where each chip has two unique numbers burned into the chip for a total of 160 bits. I don't think I can really depend on these numbers being secret, since the chip designers thought they would be useful for DRM. It certainly will do no harm to hash them into the pool, and give them a zero entropy weight. The system will be built with SSD instead of HDD, so Damien's comment hits close to home. I hope to be able to use timing of external devices, the system communicates with a number of these, along with a microsecond counter to gather entropy from clock skew between the internal clock and the clocks in those devices. Unfortunately the system doesn't normally have a user, so UI timings will be few and far between. Short of building special random number generation hardware, does anyone have any suggestions for additional sources? Cheers - Bill --- Bill Frantz| Barack Hussein Obama, President of the United States. 408-356-8506 | Now we can return to being a partner with the rest of www.periwinkle.com | the world. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Bill Frantz fra...@pwpconsult.com writes: I find myself in this situation with a design I'm working on. I have an ARM chip, where each chip has two unique numbers burned into the chip for a total of 160 bits. I don't think I can really depend on these numbers being secret, since the chip designers thought they would be useful for DRM. It certainly will do no harm to hash them into the pool, and give them a zero entropy weight. The system will be built with SSD instead of HDD, so Damien's comment hits close to home. I hope to be able to use timing of external devices, the system communicates with a number of these, along with a microsecond counter to gather entropy from clock skew between the internal clock and the clocks in those devices. Unfortunately the system doesn't normally have a user, so UI timings will be few and far between. Short of building special random number generation hardware, does anyone have any suggestions for additional sources? Given the usual threat model for a device like this, I'd just store an AES key at the factory and use it in counter mode (or something very similar) as your PRNG. The rest of this message is justification for this design choice under a very specific threat model -- it might not be a good idea under a different threat model. I'm imagining that this is a device like a router, wireless base station, or similar, where you have (for most users) a fairly modest level of physical access based threat, and a very strong remote exploitation threat. (I presume if this wasn't a fairly inexpensive mass produced item, adding a hardware RNG wouldn't be a big deal. If this is an ATM or other expensive high risk device, why aren't you spending the money?) So reiterating, our threat model is largely remote attack -- if someone gets prolonged physical access to the device, they can read out the key, but with that much access they can also alter the firmware so who cares. Physical access means everything is lost anyway. Some remote attackers might gain complete control of the device and be able to read the key, but again, in such cases everything is likely lost anyway, because they could also alter the firmware. I also presume that for the device in question, the quality of the RNGs is important (or you wouldn't be thinking hard about it). So, why not go for the simplest, easiest and strongest source we know about, a block cipher in counter mode with a strong key? Yes, you can attempt to gather randomness at run time, but there are endless ways to screw that up -- can you *really* tell if your random numbers are random enough? -- and in a cheap device with low manufacturing tolerances, can you really rely on how consistent things like clock skew will be? Lets contrast that with AES in counter mode with a really good factory installed key. It is trivial to validate that your code works correctly (and do please do that!) It is straightforward to build a device to generate a stream of good AES key at the factory, and you need only make sure that one piece of hardware is working correctly, rather than all the cheap pieces of hardware you're churning out. One big issue might be that if you can't store the counter across device resets, you will need a new layer of indirection -- the obvious one is to generate a new AES key at boot, perhaps by CBCing the real time clock with the permanent AES key and use the new key in counter mode for that session. Again, here are the possible issues from the point of view of this threat model: 1) If someone remotely takes control of the device (via some sort of OS bug or the like), you're lost anyway, so a complicated algorithm using local randomness won't help. 2) If someone takes control of the device through physical access, you're lost anyway, see #1. 3) If neither 1 or 2 happen, a factory loaded key gives you, for practical purposes, an ideal CPRNG. It is low cost, as strong as AES itself, and easily validated. This does necessitate an extra manufacturing step in which the device gets individualized, but you're setting the default password to a per-device string and having that taped to the top of the box anyway, right? If you're not, most of the boxes will be vulnerable anyway and there's no point... Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Thu, 11 Dec 2008, James A. Donald wrote: If one uses a higher resolution counter - sub microsecond - and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true random. Until someone runs your software on a SSD instead of a HDD. Oops. -d - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Jack Lloyd wrote: I think the situation is even worse outside of the major projects (the OS kernels crypto implementations and the main crypto libraries). I think outside of those, nobody is even really looking. For instance - This afternoon I took a look at a C++ library called JUCE which offers (among a pile of other things) RSA and Blowfish. However it turns out that all of the RSA keys are generated with an LCRNG (lrand48, basically) seeded with the time in milliseconds. http://www.randombit.net/bitbashing/security/juce_rng_vulnerability.html If one uses a higher resolution counter - sub microsecond - and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true random. In Crypto Kong I added entropy at various times during program initialization from the 64 bit performance counter. Unfortunately the 64 bit performance counter is not guaranteed to be present, so I also obtained entropy from a wide variety of other sources - including the dreaded millisecond counter that has caused so many security holes. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On 1227894567 seconds since the Beginning of the UNIX epoch Perry E. Metzger wrote: As it turns out, cryptographic pseudorandom number generators continue to be a good place to look for security vulnerabilities -- see the enclosed FreeBSD security advisory. The more things change, the more they stay the same... They failed to also mention that GBDE uses arc4random(9) to generate the keys which is uses to write data. So, any data written in the first five minutes after a boot may also be weakly keyed. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
