Most of this discussion concerns the privacy aspects of having a serial number on a processor chip. But there are a few articles about hardware random number generation technology.
Subject: Pentium III... Date: Thu, 21 Jan 1999 01:37:55 +0100 From: fungus <spam@egg.chips.and.spam.com> Message-ID: <36A676E3.E8D27B14@egg.chips.and.spam.com> Newsgroups: sci.crypt Lines: 13 Intel has announced that the Pentium III will have a built in hardware random number generator, and individual serial number on each chip. http://www.techweb.com/wire/story/TWB19990120S0017 -- <\___/> / O O \ \_____/ FTB.
Subject: Re: Pentium III... Date: Wed, 20 Jan 1999 22:39:30 -0500 From: Brad Aisa <baisa@istar.ca> Message-ID: <36A6A172.8BA38F98@istar.ca> References: <36A676E3.E8D27B14@egg.chips.and.spam.com> Newsgroups: sci.crypt Lines: 14 fungus wrote: > > Intel has announced that the Pentium III will have a built in hardware > random number generator, and individual serial number on each chip. I don't quite understand how a unique serial number in the chip is supposed to be helpful for anything cryptographic. ...and if the chip dies? ...and if you switch between computers? __ Brad Aisa
Subject: Re: Pentium III... Date: Wed, 20 Jan 1999 22:46:41 -0500 From: "Trevor Jackson, III" <fullmoon@aspi.net> Message-ID: <36A6A320.DDDB9C5F@aspi.net> References: <36A6A172.8BA38F98@istar.ca> Newsgroups: sci.crypt Lines: 21 Read the fine print. The purpose is to *identify* the user, not assist him. Brad Aisa wrote: > fungus wrote: > > > > Intel has announced that the Pentium III will have a built in hardware > > random number generator, and individual serial number on each chip. > > I don't quite understand how a unique serial number in the chip is > supposed to be helpful for anything cryptographic. > > ...and if the chip dies? > > ...and if you switch between computers? > > __ > Brad Aisa
Subject: Re: Pentium III... Date: Sat, 23 Jan 1999 18:50:52 GMT From: Daniel James <internet@nospam.demon.co.uk> Message-ID: <VA.00000154.06396550@barney.sonadata> References: <36A6A320.DDDB9C5F@aspi.net> Newsgroups: sci.crypt Lines: 12 In article <36A6A320.DDDB9C5F@aspi.net>, Trevor Jackson, III wrote: > Read the fine print. The purpose is to *identify* the user, not assist him. > The serial number in the chip is to help control the trade in stolen CPUs, which is a big moneyspinner in certain parts of the criminal world. Cheers, Daniel James Daniel at sonadata.demon.co.uk
Subject: Re: Pentium III... Date: 23 Jan 99 22:26:15 GMT From: jsavard@ecn.ab.ca () Message-ID: <36aa4c87.0@ecn.ab.ca> References: <VA.00000154.06396550@barney.sonadata> Newsgroups: sci.crypt Lines: 17 Daniel James (internet@nospam.demon.co.uk) wrote: : The serial number in the chip is to help control the trade in stolen CPUs, : which is a big moneyspinner in certain parts of the criminal world. I hadn't thought of that, but you are correct. Also, as the serial number will identify the type of the chip - and its rated clock speed - that should help combat *fraudulent* overclocking in a way that does not require Intel to design the chips to prevent overclocking by the individual user. However, a serial number accessible to software will be used by some software packages for software piracy prevention: it will not be suitable for most mass-market software, but there are packages to which that sort of thing is applicable. John Savard
Subject: Re: Pentium III... Date: Mon, 25 Jan 1999 17:59:10 GMT From: Darren New <dnew@messagemedia.com> Message-ID: <36ACB1A7.8640A313@messagemedia.com> References: <36aa58fe.19369792@nntp.ix.netcom.com> <VA.00000154.06396550@barney.sonadata> Newsgroups: sci.crypt Lines: 20 > >The serial number in the chip is to help control the trade in stolen CPUs, > >which is a big moneyspinner in certain parts of the criminal world. > > Once again the law-abiding citizen has to pay the price for the > ineptness of law enforcement. I find this amusing, coming from the newsgroup with likely the most vocal opponents to key escrow. :-) Anyway, who would be checking for whether the CPUs are stolen? Will Intel refuse to sell you chips unless you promise to check that every chip you buy is not on the hotlist? And require you to sign same with all the people you redistribute to? If I wind up with a stolen chip in my machine, can it be confiscated as stolen property? Sheesh. -- Darren New / Senior Software Architect / MessageMedia, Inc. San Diego, CA, USA (PST). Cryptokeys on demand. "You could even do it in C++, though that should only be done by folks who think that self-flagellation is for the effete."
Subject: Re: Pentium III... Date: Wed, 27 Jan 1999 08:13:07 GMT From: aquiranx@goliatx.ugr.es (Gurripato (x=nospam)) Message-ID: <36aec9e6.2293499@news.cica.es> References: <36ACB1A7.8640A313@messagemedia.com> Newsgroups: sci.crypt Lines: 17 On Mon, 25 Jan 1999 17:59:10 GMT, Darren New <dnew@messagemedia.com> wrote: >> >The serial number in the chip is to help control the trade in stolen CPUs, >> >which is a big moneyspinner in certain parts of the criminal world. And, naturally, the desire from the FBI,CIA,NSA ...... (your favorite 3-letter agency goes here) to control people´s actions and movements, regardless of whether you belong to the bad guys or not, has NOTHING to do with it. >> Once again the law-abiding citizen has to pay the price for the >> ineptness of law enforcement. I would rather say data-greed. They are far from inept.
Subject: Re: Pentium III... Date: Thu, 28 Jan 1999 10:28:54 GMT From: Daniel James <internet@nospam.demon.co.uk> Message-ID: <VA.0000015c.058b856b@barney.sonadata> References: <36ACB1A7.8640A313@messagemedia.com> Newsgroups: sci.crypt Lines: 15 In article <36ACB1A7.8640A313@messagemedia.com>, Darren New wrote: > Anyway, who would be checking for whether the CPUs are stolen? > The point is that every CPU made will have a unique identifier that cannot be file off, painted over or otherwise rendered illegible without destroying the CPU. This will be useful, for example, when the police find a A.Felon Esq. in posession of a shedful of used CPUs; it will be possible to verify that they were stolen and from whom. Cheers, Daniel James Daniel at sonadata.demon.co.uk
Subject: Re: Pentium III... Date: Thu, 28 Jan 1999 17:31:35 +0100 From: fungus <spam@egg.chips.and.spam.com> Message-ID: <36B090E7.EF5B55AD@egg.chips.and.spam.com> References: <36A676E3.E8D27B14@egg.chips.and.spam.com> Newsgroups: sci.crypt Lines: 23 Daniel James wrote: > > This will be useful, for example, when the > police find a A.Felon Esq. in posession of a shedful of used CPUs; it > will be possible to verify that they were stolen and from whom. > ...except that the numbers will follow no pattern, and Intel won't be keeping records of which chips have which numbers (or so they say). A distributor could, in theory, take every single chip out of the box and record all the serial numbers before he puts them in a truck for transportation. I personally don't think this is very likely.... -- <\___/> / O O \ \_____/ FTB.
Subject: Re: Pentium III... Date: 28 Jan 1999 12:04:16 PST From: bt@templetons.com (Brad Templeton) Message-ID: <78qfs0$c25@journal.concentric.net> References: <36B090E7.EF5B55AD@egg.chips.and.spam.com> Newsgroups: sci.crypt Lines: 34 In article <36B090E7.EF5B55AD@egg.chips.and.spam.com>, fungus <spam@egg.chips.and.spam.com> wrote: > > >Daniel James wrote: >> >> This will be useful, for example, when the >> police find a A.Felon Esq. in posession of a shedful of used CPUs; it >> will be possible to verify that they were stolen and from whom. >> > >...except that the numbers will follow no pattern, and Intel >won't be keeping records of which chips have which numbers >(or so they say). > >A distributor could, in theory, take every single chip out of the >box and record all the serial numbers before he puts them in a truck >for transportation. I personally don't think this is very likely.... They won't record what individual has what serial number, but you can bet they will record what distributors and PC vendors have what serial numbers. They will expect people building PCs to probably run a little program that reads the SN, and checks a database to see if the chip is stolen. Any legit builder of PCs buying chips from a 3rd party may take a random sample and test it before paying. Intel could also put up a web site where customers could check if their chip is stolen, with the provision that if it is, Intel will give them the chip (ie. make it un-stolen) so long as they say who they bought it from. Plus perhaps some other reward. -- Brad Templeton http://www.templetons.com/brad/
Subject: Re: Pentium III... Date: Sun, 24 Jan 1999 18:33:11 GMT From: William Hugh Murray <whmurray@sprynet.com> Message-ID: <36AB6766.E0D9245F@sprynet.com> References: <36a765d4.0@nnrp1.news.uk.psi.net> <36A6A172.8BA38F98@istar.ca> Newsgroups: sci.crypt Lines: 22 No it shouldn't; particularly since Intel provides the user a control over it. Still, it must be a terrible temptation to governments. burt wrote: > > Shouldnt be to dificult to get around the serial number.. > > Brad Aisa wrote in message <36A6A172.8BA38F98@istar.ca>... > >fungus wrote: > >> > >> Intel has announced that the Pentium III will have a built in hardware > >> random number generator, and individual serial number on each chip. > > > >I don't quite understand how a unique serial number in the chip is > >supposed to be helpful for anything cryptographic. > > > >...and if the chip dies? > > > >...and if you switch between computers? > > > >__ > >Brad Aisa
Subject: Re: Pentium III... Date: 21 Jan 99 04:59:39 GMT From: jsavard@ecn.ab.ca () Message-ID: <36a6b43b.0@ecn.ab.ca> References: <36A676E3.E8D27B14@egg.chips.and.spam.com> Newsgroups: sci.crypt Lines: 18 fungus (spam@egg.chips.and.spam.com) wrote: : Intel has announced that the Pentium III will have a built in hardware : random number generator, and individual serial number on each chip. : http://www.techweb.com/wire/story/TWB19990120S0017 Hmm. The serial number on the chip is to assist in copy-protection schemes, creating a market for cryptographic techniques... and a hardware random number generator on the chip will be useful to cryptography programs. So useful, I'm surprised they included such a feature (yes, I know dice aren't export controlled) since they probably have enough headaches getting approval to export their latest and greatest microprocessors. John Savard
Subject: Re: Pentium III... Date: Thu, 21 Jan 1999 01:11:57 -1000 From: ".ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ." <untell@outside.com> Message-ID: <36A70B7D.78BD@outside.com> References: <36a6b43b.0@ecn.ab.ca> Newsgroups: sci.crypt Lines: 37 jsavard@ecn.ab.ca wrote: > > fungus (spam@egg.chips.and.spam.com) wrote: > > : Intel has announced that the Pentium III will have a built in hardware > : random number generator, and individual serial number on each chip. > > : http://www.techweb.com/wire/story/TWB19990120S0017 > > Hmm. The serial number on the chip is to assist in copy-protection > schemes, creating a market for cryptographic techniques... > > and a hardware random number generator on the chip will be useful to > cryptography programs. > > So useful, I'm surprised they included such a feature (yes, I know dice > aren't export controlled) since they probably have enough headaches > getting approval to export their latest and greatest microprocessors. > > John Savard I spoke to Intel's David Aucsmith about this. Last yesr. I informed him that I invented this 13 years ago while I was working at Intel. I invented a random number generator for Intel and I proposed the non-volatile memory scheme for holding chip serial numbers. I invented the "single-poly EPROM cell" for storing ID numbers, etc. using the standard single poly microprocessor wafer process! They said they could not use it because the cells were so big. The n+ diffusion and n-well form one plate of a capacitor, poly 1 forms the other plate, and the floqqting gate. I drew the memory cell, put in on a test mask set, got the wafers, tested the cells, they worked! I wonder if they patented my inventions without notifying me. I might call them soon to collect some royalties. In 1984 I told Larry Palley and Kurt Robinson of Intel Folsom about it. My patent notebook is in the desk of Greg Ledenbach in Folsom California. I have written proof. Name witheld (for now).
Subject: Re: Pentium III... Date: Thu, 21 Jan 1999 08:54:32 -0800 From: David Boreham <dboreham@netscape.com> Message-ID: <36A75BC8.3583A332@netscape.com> References: <36A70B7D.78BD@outside.com> Newsgroups: sci.crypt Lines: 12 > I spoke to Intel's David Aucsmith about this. Last yesr. I informed him > that I invented this 13 years ago while I was working at Intel. I > invented a random number generator for Intel and I proposed the > non-volatile memory scheme for holding chip serial numbers. I invented > the "single-poly EPROM cell" for storing ID numbers, etc. using the Pretty cool. But couldn't they use laser-zapped fuses for the chip ID ? EPROM technology is certainly capable of interesting things, but for the task at hand (configure a unique ID at backend test time), you don't _need_ an EPROM cell.
Subject: Re: Pentium III... Date: Thu, 21 Jan 1999 19:03:56 -1000 From: ".ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ." <old1@wave.com> Message-ID: <36A806BC.23A2@wave.com> References: <36A75BC8.3583A332@netscape.com> Newsgroups: sci.crypt Lines: 57 David Boreham wrote: > > > I spoke to Intel about this last year. I informed them > > that I invented this 13 years ago while I was working at Intel. I > > invented a random number generator for Intel and I proposed the > > non-volatile memory scheme for holding chip serial numbers. I invented > > the "single-poly EPROM cell" for storing ID numbers, etc. using the > Pretty cool. But couldn't they use laser-zapped fuses > for the chip ID ? EPROM technology is certainly capable > of interesting things, but for the task at hand > (configure a unique ID at backend test time), you > don't _need_ an EPROM cell. Laser blown fuses are a possibility. I have not seen the Pentium III chip yet, so the speculations I am making are only based on years of experience at Intel and 12 years out of there. One problem with fuses for cryptographic keys or for security serial numbers is that they are visible under a microscope. A second problem is that they cause reliability problems if extra processing steps are not taken: the laser blast cracks open the top oxide layers and lets contaminations in. That is why I told Intel to use the single poly EPROM cell in 1986 for serial numbers on the 80386. I am glad they finally have taken my advice (or maybe they re-invented the idea). The random number generator I had patented at Intel is probably similar to the one on the Pentium III: several oscillators combine their outputs and that odd waveform is sampled asynchronously. Switched capacitors change the loading on each oscillator with the switches controlled by the random bits that are accumulated in a shift register. The oscillators each have different responses to power supply noise, temperature, capacitance change, noise due to thermally induced voltage irregularities, and small processing irregularities. A heater near one oscillator is switched on and off to produce a thermal history that is different from that of the other oscillators. When the chip comes out, people who evaluate it should look for the single poly EPROM cells that are shaped like ping-pong paddles made of polycrystalline silicon. The handle is the gate of an MOS transistor, the paddle is the capacitor that stores the floating charge. High voltages are applied during wafer sort to this poly capacitor to cause avalanche injection to program the serial numbers through a bond pad that is not connected to the package the customer uses. It will be placed under a metal power bus for added security. The cells also store wafer ID info so that statistical analysis can be done and failure tracking can be done years after retail sales. This would facilitate recalls of chips from bad fab runs. That's my guess. An Un-named Source
Subject: Re: Pentium III... Date: Fri, 22 Jan 1999 19:38:00 GMT From: ritter@io.com (Terry Ritter) Message-ID: <36a8d388.8625558@news.io.com> References: <36A806BC.23A2@wave.com> Newsgroups: sci.crypt Lines: 39 On Thu, 21 Jan 1999 19:03:56 -1000, in <36A806BC.23A2@wave.com>, in sci.crypt ".ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ." <old1@wave.com> wrote: >[...] >The random number generator I had patented at Intel is probably >similar to the one on the Pentium III: several oscillators >combine their outputs and that odd waveform is sampled >asynchronously. Switched capacitors change the loading on each >oscillator with the switches controlled by the random bits that >are accumulated in a shift register. The oscillators each have >different responses to power supply noise, temperature, >capacitance change, noise due to thermally induced voltage >irregularities, and small processing irregularities. A heater >near one oscillator is switched on and off to produce a thermal >history that is different from that of the other oscillators. I think this is generally a bad way to build an on-chip RNG. There are two issues here: Random noise, which, because it is random, need not be protected; and a complex sequence, which, because it is complex, *seems* random. These are two very different things. If we have a machine which only does both, it will be very difficult to know just how much noise we really have. And if there is not much noise there, we have yet another cipher or pseudorandom RNG (admittedly of a special form, with special features, like thermally-delayed bit correlations) which might be attacked. I think it is generally inappropriate to try to hide flaws in the random source. We can still use flawed randomness, we just have to process it. And if we can characterize the flaws, we can get an idea about how much we have to process. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: Pentium III... Date: Thu, 21 Jan 1999 13:18:47 +0100 From: fungus <spam@egg.chips.and.spam.com> Message-ID: <36A71B27.6CE10C77@egg.chips.and.spam.com> References: <36a6b43b.0@ecn.ab.ca> Newsgroups: sci.crypt Lines: 47 jsavard@ecn.ab.ca wrote: > > fungus (spam@egg.chips.and.spam.com) wrote: > > : Intel has announced that the Pentium III will have a built in hardware > : random number generator, and individual serial number on each chip. > > : http://www.techweb.com/wire/story/TWB19990120S0017 > > Hmm. The serial number on the chip is to assist in copy-protection > schemes, creating a market for cryptographic techniques... > Possibly. Most Unix machines have had serial numbers for years now and software is usage is often keyed to the machine. I'm not sure how it will work in the mass market of the PC world though. Any big selling program will probably cause a lot of headaches if people try to key it to the machine. > and a hardware random number generator on the chip will be useful to > cryptography programs. > Maybe not as useful as people will think. It can be used for session keys etc., but I doubt if people will use it for OTP (cue new thread!) due to all the key management problems that involves. The question is whether a hardware number generator provides much benefit over a software generator for session keys. > So useful, I'm surprised they included such a feature (yes, I know dice > aren't export controlled) since they probably have enough headaches > getting approval to export their latest and greatest microprocessors. > Do random number generators fall under export restrictions? I would say "only if they can be seeded and synched with other machines". If this isn't the case then I don't see how they can have problems. I'm sure a company like Intel has thought this through pretty carefully.... -- <\___/> / O O \ \_____/ FTB.
Subject: Re: Pentium III... Date: Thu, 21 Jan 1999 17:00:35 +0100 From: Mok-Kong Shen <mok-kong.shen@stud.uni-muenchen.de> Message-ID: <36A74F23.6BBB7A9C@stud.uni-muenchen.de> References: <36A71B27.6CE10C77@egg.chips.and.spam.com> Newsgroups: sci.crypt Lines: 35 fungus wrote: > > jsavard@ecn.ab.ca wrote: > > > > fungus (spam@egg.chips.and.spam.com) wrote: > > Hmm. The serial number on the chip is to assist in copy-protection > > schemes, creating a market for cryptographic techniques... > > > > Possibly. Most Unix machines have had serial numbers for years now > and software is usage is often keyed to the machine. I'm not sure how > it will work in the mass market of the PC world though. Any big selling > program will probably cause a lot of headaches if people try to key > it to the machine. > > > and a hardware random number generator on the chip will be useful to > > cryptography programs. Licensed software can be downloaded that works only on machines of certain serial numbers. I don't see a difference here between UNIX workstantions and PC. > > Maybe not as useful as people will think. It can be used for session > keys etc., but I doubt if people will use it for OTP (cue new thread!) > due to all the key management problems that involves. The question is > whether a hardware number generator provides much benefit over a software > generator for session keys. Presumably a good session key can be constructed from a combination of the generator output and input from the user. This would eliminate questions concerning the quality of the hardware generator. M. K. Shen
Subject: Re: Pentium III... Date: Thu, 21 Jan 1999 18:18:28 GMT From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Message-ID: <36a76ea8.3406965@news.prosurfr.com> References: <36A71B27.6CE10C77@egg.chips.and.spam.com> Newsgroups: sci.crypt Lines: 48 fungus <spam@egg.chips.and.spam.com> wrote, in part: >Possibly. Most Unix machines have had serial numbers for years now >and software is usage is often keyed to the machine. I'm not sure how >it will work in the mass market of the PC world though. Any big selling >program will probably cause a lot of headaches if people try to key >it to the machine. The serial number may not be used much for copy-protecting mass-market programs, but it will be handy for some programs that are licensed on a lower-volume basis. As a Pentium computer is comparable to the mainframes of yesteryear, some systems with server-type hardware are used for quite impressive applications. (Of course, the big news about the Pentium III seems to be that it includes the long-awaited MMX 2 instruction set.) >Maybe not as useful as people will think. It can be used for session >keys etc., but I doubt if people will use it for OTP (cue new thread!) >due to all the key management problems that involves. The question is >whether a hardware number generator provides much benefit over a software >generator for session keys. >Do random number generators fall under export restrictions? I would >say "only if they can be seeded and synched with other machines". If >this isn't the case then I don't see how they can have problems. I'm >sure a company like Intel has thought this through pretty carefully.... My understanding is that the chip will include hardware to generate true random numbers from electrical noise. This is very helpful to encryption programs, since it allows session keys to be as secure as the public-key method used to transmit them; getting true randomness from keypresses, disk movement, and so on, is cumbersome and depends on the individual user's configuration, and not using truly random numbers creates an additional point of weakness in a cryptographic system. Export restrictions on hardware are generally more stringent than on software, and the Pentium III chip could even provoke the enacting of new restrictions that don't exist at present. (Of course, new chips that push the envelope of performance aren't exportable for a while after introduction in any case.) John Savard http://www.freenet.edmonton.ab.ca/~jsavard/index.html
Subject: Re: Pentium III... Date: Fri, 22 Jan 1999 08:48:54 GMT From: frankrubin@my-dejanews.com Message-ID: <789e1k$bfi$1@nnrp1.dejanews.com> References: <36a6b43b.0@ecn.ab.ca> Newsgroups: sci.crypt Lines: 27 In article <36a6b43b.0@ecn.ab.ca>, jsavard@ecn.ab.ca () wrote: > > Hmm. The serial number on the chip is to assist in copy-protection > schemes, creating a market for cryptographic techniques... > and a hardware random number generator on the chip will be useful to > cryptography programs. > > So useful, I'm surprised they included such a feature (yes, I know dice > aren't export controlled) since they probably have enough headaches > getting approval to export their latest and greatest microprocessors. > > John Savard > John, the random number generators found in hardware and software today are almost always 32-bit generators, meaning they have only 32-bit internal states. This is equivalent to a 32-bit crypto key, which is far too small to make a secure cryptographic system. Nobody will worry about exporting such a chip. If you are looking for something more secure, see my article "One-Time Pad Cryptography" in the Oct. 1996 Cryptologia. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Subject: Re: Pentium III... Date: 22 Jan 1999 13:34:21 GMT From: sax@rmovt.rply.ce.chalmers.se (Stefan Axelsson) Message-ID: <789uot$5ag$1@nyheter.chalmers.se> References: <789e1k$bfi$1@nnrp1.dejanews.com> Newsgroups: sci.crypt Lines: 16 In article <789e1k$bfi$1@nnrp1.dejanews.com>, <frankrubin@my-dejanews.com> wrote: >John, the random number generators found in hardware and software today are >almost always 32-bit generators, meaning they have only 32-bit internal >states. Huh? What *state*? We're (hopefully) not discussing a *pseudo* random device in hardware here. The question of whether it is useful, or any good, still remains to be answered, of course. Stefan, -- Stefan Axelsson Chalmers University of Technology sax@rmovt.rply.ce.chalmers.se Dept. of Computer Engineering (Remove "rmovt.rply" to send mail.)
Subject: Re: Pentium III... Date: Fri, 22 Jan 1999 14:21:13 GMT From: rcktexas@ix.netcom.com (R. Knauer) Message-ID: <36a88936.14838306@nntp.ix.netcom.com> References: <789e1k$bfi$1@nnrp1.dejanews.com> Newsgroups: sci.crypt Lines: 14 On Fri, 22 Jan 1999 08:48:54 GMT, frankrubin@my-dejanews.com wrote: >If you are looking for something more secure, see my article "One-Time Pad >Cryptography" in the Oct. 1996 Cryptologia. Is that posted to the web? If so, could you give us the link. Bob Knauer "It is not the function of our government to keep the citizen from falling into error; it is the function of the citizen to keep the government from falling into error." --Justice Robert H. Jackson
Subject: Re: Pentium III... Date: Fri, 22 Jan 1999 18:15:32 GMT From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Message-ID: <36a8be80.6108402@news.prosurfr.com> References: <789e1k$bfi$1@nnrp1.dejanews.com> Newsgroups: sci.crypt Lines: 31 frankrubin@my-dejanews.com wrote, in part: >John, the random number generators found in hardware and software today are >almost always 32-bit generators, meaning they have only 32-bit internal >states. This is equivalent to a 32-bit crypto key, which is far too small to >make a secure cryptographic system. Nobody will worry about exporting such a >chip. >If you are looking for something more secure, see my article "One-Time Pad >Cryptography" in the Oct. 1996 Cryptologia. I'm sure I've seen the article, even if I don't remember it offhand. Could it be the one where the claim that the one-time-pad is "impractical" is countered? I'm well aware that typical 'random number generators' are mixed congruential - with 32-bit, or even 16-bit, internal states. However, unless I am very much mistaken, the reference to a 'hardware random number generator' on the Pentium III does *not* refer to anything of that type, but to a built-in source of true randomness, by means of electrical noise or the like. It is that which is at the present awkward and expensive to add to a PC, while a PRNG is easy to write in software (and Windows even provides a shared PRNG with a global seed, seeded by the clock at startup, to approximate true random behavior - in a fashion adequate, say, for games, if not for cryptography), and thus it is that which remedies a fundamental omission. John Savard http://www.freenet.edmonton.ab.ca/~jsavard/index.html
Subject: Re: Pentium III... Date: Thu, 21 Jan 1999 19:37:32 GMT From: janb@pmatrix.com Message-ID: <787vlr$3b4$1@nnrp1.dejanews.com> References: <36A676E3.E8D27B14@egg.chips.and.spam.com> Newsgroups: sci.crypt Lines: 30 > Intel has announced that the Pentium III will have a built in hardware > random number generator, and individual serial number on each chip. I can think of cases where having a machine serial number would be somewhat handy. I'm not sure I would build it into the processor though. This tremendously complicates upgrading/replacing your hardware. I think one of the already existing serial number chips (like from Dallas Semi, mabey an iButton) mounted on the motherboard at a well defined address would have been better. Or even much better, some sort of hardware MD5/SHA chip. If the serial number is directly readable, it can be faked. If you can only get the effect the serial number has on some algorithm, like as a MD5 seed, it's a lot harder to forge. You never would let the actual serial number be known in the clear. As for putting a random number generator in the processor, that seems just silly. It's pretty easy to generate extreemly high quality random numbers on a typical PC at rates of 1000 bits/second. This is way more than sufficent for most uses. The primary use for a processor serial number seems like it would be to enforce software licenses. If I read the Microsoft OS license correctly, your NOT allowed to move a copy of the OS from an old machine to a new machine. The OS is licensed to a specific machine, which might be interpreted as a specific processor. - Jan -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Subject: Re: Pentium III... Date: Thu, 21 Jan 1999 20:05:07 GMT From: rcktexas@ix.netcom.com (R. Knauer) Message-ID: <36a78709.23154884@nntp.ix.netcom.com> References: <787vlr$3b4$1@nnrp1.dejanews.com> Newsgroups: sci.crypt Lines: 36 On Thu, 21 Jan 1999 19:37:32 GMT, janb@pmatrix.com wrote: >It's pretty easy to generate extreemly high quality random numbers on a >typical PC at rates of 1000 bits/second. How is that be done such that no one can crack the resulting cipher given sufficient resources? For example, if you have a laptop with sensitive business material on it, and a competitor steals it, he may decide that it is worth 1 million dollars to decipher your files. Can the kind of random number generator you allude to above be adequate to prevent all but the most concerted attacks, like from the NSA? >The primary use for a processor serial number seems like it would be to >enforce software licenses. If I read the Microsoft OS license correctly, your >NOT allowed to move a copy of the OS from an old machine to a new machine. >The OS is licensed to a specific machine, which might be interpreted as a >specific processor. Just great! You buy a computer with an installed OS, the processor dies from infant morality, and now you got a major hassle on your hands. You would think the industry learned its lesson from the old days of closed architectures, key-based S/W, dongle keys, etc. I can just see Ziff Davis refusing to test anything that is Pentium III based. Bob Knauer "A man with his heart in his profession imagines and finds resources where the worthless and lazy despair." --Frederic the Great, in instructions to his Generals
Subject: Re: Pentium III... Date: Fri, 22 Jan 1999 01:15:31 GMT From: janb@pmatrix.com Message-ID: <788jf9$li3$1@nnrp1.dejanews.com> References: <36a78709.23154884@nntp.ix.netcom.com> Newsgroups: sci.crypt Lines: 65 In article <36a78709.23154884@nntp.ix.netcom.com>, rcktexas@ix.netcom.com wrote: > On Thu, 21 Jan 1999 19:37:32 GMT, janb@pmatrix.com wrote: > > >It's pretty easy to generate extreemly high quality random numbers on a > >typical PC at rates of 1000 bits/second. > > How is that be done such that no one can crack the resulting cipher > given sufficient resources? The method of random session key generation has nothing to do with ease of brute force attacks on a specific cryptographic cipher. Cracking a 56-bit DES key will take exactly the same computing effort (22 hours on Distributed.net) no matter what the source of the key. > For example, if you have a laptop with sensitive business material on > it, and a competitor steals it, he may decide that it is worth 1 > million dollars to decipher your files. I agree, long key's are good. None of the enhancements Intel has announced will have any effect on the security of your data. Adding a thumbprint reader or smart card reader or Dallas iButton reader (see http://www.ibutton.com) would. If anything, I think there is danger of a false sense of security. Just because some computer has a Pentium III, with a processor serial number and hardware random number generator doesn't mean it's any more or less secure than a system with say an AMD K6-2 processor. > Can the kind of random number generator you allude to above be > adequate to prevent all but the most concerted attacks, like from the > NSA? Yes, I believe it's possible to generate very high quality random numbers, without thermal noise hardware, like Intel is planning to add to the Pentium III. Random number generators are used for key generation. I have quite a lot of experience in this specific issue. I've written about five generations of cryptographic random number generators for assorted applications on Intel machines. The latest generation I believe makes extreemly high quality random numbers. > >The primary use for a processor serial number seems like it would be to > >enforce software licenses. If I read the Microsoft OS license correctly, your > >NOT allowed to move a copy of the OS from an old machine to a new machine. > >The OS is licensed to a specific machine, which might be interpreted as a > >specific processor. > > Just great! You buy a computer with an installed OS, the processor > dies from infant morality, and now you got a major hassle on your > hands. > > You would think the industry learned its lesson from the old days of > closed architectures, key-based S/W, dongle keys, etc. I can just see > Ziff Davis refusing to test anything that is Pentium III based. At least a dongle would work with your replacement processor. Of cource if your dongle breaks (or you loose it) you may be stuck. I like thumbprint or retina scans more and more every day. Or a smart card, with a duplicate in your safe deposit box (SDB). - Jan -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Subject: Re: Pentium III... Date: Fri, 22 Jan 1999 14:18:11 GMT From: rcktexas@ix.netcom.com (R. Knauer) Message-ID: <36a8840e.13518158@nntp.ix.netcom.com> References: <788jf9$li3$1@nnrp1.dejanews.com> Newsgroups: sci.crypt Lines: 59 On Fri, 22 Jan 1999 01:15:31 GMT, janb@pmatrix.com wrote: >Yes, I believe it's possible to generate very high quality random numbers, >without thermal noise hardware, like Intel is planning to add to the Pentium >III. Random number generators are used for key generation. That very well may be true if you do not require crypto-grade random numbers. >I have quite a lot of experience in this specific issue. I've written about >five generations of cryptographic random number generators for assorted >applications on Intel machines. The latest generation I believe makes >extreemly high quality random numbers. Please elaborate. Also you might want to join the thread on sci.crypt entitled "Metaphysics of Randomness" where we are discussing the fundamentals of crypto-grade random number generation in terms of considerations such as Kolgomorov-Chaitin complexity theory, Godel's Theorem and Turing's Halting Problem, decorrelation schemes for text ciphers, digit expansion generators for irrational numbers and transcendentals and other schemes to generate random numbers. To date no one has come up with a proveably secure method other than a hardware TRNG - although some have claimed their methods are practically secure to a very close level of approximation. The criterion is to produce an OTP cipher system which can withstand a Bayesian attack, yet not require distribution of the pads. >At least a dongle would work with your replacement processor. Of cource if >your dongle breaks (or you loose it) you may be stuck. I cracked a dongle once - it is not all that difficult if you trap the strings it expects and then write a wedge to supply them. >I like thumbprint or >retina scans more and more every day. Or a smart card, with a duplicate in >your safe deposit box (SDB). I guess my problem is that there is no real need for all this. The apparent money lost in pirated software is far less than the money gained when people buy the S/W later, especially when you take into account that the people who pirate S/W can't or won't buy it if they have to until they can afford it. This obsession with sticking one's nose into every nook and cranny of consumer activities is fueled by companies who profit from promoting the technology to do it. Then at a later date it is discovered that the intrusions were worthless, and in many cases even counterproductive, in commercial terms. Bob Knauer "It is not the function of our government to keep the citizen from falling into error; it is the function of the citizen to keep the government from falling into error." --Justice Robert H. Jackson
Subject: Re: Pentium III... Date: Fri, 22 Jan 1999 20:19:47 GMT From: janb@pmatrix.com Message-ID: <78amgn$eu7$1@nnrp1.dejanews.com> References: <36a8840e.13518158@nntp.ix.netcom.com> Newsgroups: sci.crypt Lines: 104 In article <36a8840e.13518158@nntp.ix.netcom.com>, rcktexas@ix.netcom.com wrote: > On Fri, 22 Jan 1999 01:15:31 GMT, janb@pmatrix.com wrote: > > >Yes, I believe it's possible to generate very high quality random numbers, > >without thermal noise hardware, like Intel is planning to add to the Pentium > >III. Random number generators are used for key generation. > > That very well may be true if you do not require crypto-grade random > numbers. > > >I have quite a lot of experience in this specific issue. I've written about > >five generations of cryptographic random number generators for assorted > >applications on Intel machines. The latest generation I believe makes > >extreemly high quality random numbers. > > Please elaborate. Earlier generations were for projects that supplied crypto support on a number of Internet products (like web servers). For interactive apps, collecting bits from mouse position delta's was used. The latest generation was used on some credit card processing software. Three algorithms were available, with randomness analysis done to dynamically select which algorithm to use. Randomness analysis would also flag that the RND seemed broken, possibly halting the application. The three algorithms included: 1) clock skew bit generator Basically spin the processor incrementing a memory location (at like 200 million increments/sec) and then periodically (from a different clock source) interrupt the processor and extract a single bit from the count. Repeat this for as many bits as needed. Production rate as high as 1000 bits/sec can be achieved. Unless the processor code path, cache hits, bus wait states, etc. between each bit sample is identical, the bit will not be predictable. Also the small jitter in the two clock sources will cause the relationship between them to jitter, causing the sample value to vary. Typical clock crystals are I believe +/- 25 ppm. 2) sound card noise collection Collect a bunch of samples from the input (line/mic) of a sound card, and then stir the bits together with a MD5. Production rate is a bit lower and also no guarantee of a sound card. Also requires exclusve device use. Still, for a secure server, requiring a sound card (cheaper is better) is not much of an expense. Most PC already have sounds card now. 3) time variations in physical disk seeks Perform a large number of physical disk seeks and measure processor clock resolution timing using RDTSC (currently about 3 nanosecond resolution). Use the bottom bit as part of random stream (or stir with MD5). Production rate is slow (50-100 bits/sec), and makes your system noisy for a bit. For reseeding a PRNG at periodic intervals this is not an problem. Combined, these methods allow production of very high quality random numbers. Nearly every currently existing PC can do these with no new processor. These assume you retain physical security of the machine, which I think is pretty realistic at the moment of key generation. If course all these methods are meaningless if an intruder is allowed access to modify the software. The same weakness applies to a RNG in a processor. If the processor did the whole private key generation, and kept it stashed in the processor (on eeprom), with interfaces to run the crypto algorithms in the processor (basically a smart card in your Pentium III), then I could see some improved security. I don't believe this is what was announced by Intel though. > To date no one has come up with a proveably secure method other than a > hardware TRNG - although some have claimed their methods are > practically secure to a very close level of approximation. The > criterion is to produce an OTP cipher system which can withstand a > Bayesian attack, yet not require distribution of the pads. Some of the methods I described in essense are hardware RNG's. For example the disk seek timing is influenced by micro air currents inside the drive case and also temperature variations. Things to consider include, is the random number predictable and can it be influenced. PSNR's are totally predictable, if you know the algorithm and and get in sync with the stream (not an easy task). I believe the methods I described above are not very predictable, but without physical security, might be influenced (by the NSA with some very significant effort). Even if they could totally be influenced under lab conditions, this would have no effect on the quality of private keys already generated. My guess is none of the methods, including a Pentium III RND, are guaranteed to pass Tempest security. I could imagine the RFI from the Pentium III RNG might give away clues about it's value, as would the disk drive firmware. I'm not a Tempest hardware or Pentium III designer, so can't say for sure. If I were REALLY serious about security, I'd probably want some sort of RFI protected, physically secure, crypto coprocessor with it's own eeprom storage of my private keys. A $25 crypto iButton fits this description better than some new instructions on a Pentium III. - Jan -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Subject: Re: Pentium III... Date: Sat, 23 Jan 1999 00:15:02 GMT From: ritter@io.com (Terry Ritter) Message-ID: <36a91475.8443843@news.io.com> References: <78amgn$eu7$1@nnrp1.dejanews.com> Newsgroups: sci.crypt Lines: 82 On Fri, 22 Jan 1999 20:19:47 GMT, in <78amgn$eu7$1@nnrp1.dejanews.com>, in sci.crypt janb@pmatrix.com wrote: >[...] >1) clock skew bit generator > >Basically spin the processor incrementing a memory location (at like 200 >million increments/sec) and then periodically (from a different clock source) >interrupt the processor and extract a single bit from the count. Repeat this >for as many bits as needed. Production rate as high as 1000 bits/sec can be >achieved. Unless the processor code path, cache hits, bus wait states, etc. >between each bit sample is identical, the bit will not be predictable. Also >the small jitter in the two clock sources will cause the relationship between >them to jitter, causing the sample value to vary. Typical clock crystals are >I believe +/- 25 ppm. I think this has taken on the status of a crypto "old wives tale," and one might well wonder where it comes from. I have been writing about it for quite some time (see: http://www.io.com/~ritter/RAND/NICORAND.HTM especially http://www.io.com/~ritter/RAND/92062703.HTM and http://www.io.com/~ritter/RAND/92110301.HTM ), and I dispute the idea that this is particularly "random." What it is is "complex," but this is the complexity of digital logic state machines whose structure is known. Computer clock signals are developed from analog crystal oscillators, specifically *because* they are fairly accurate and do not drift much over time. Although crystals do have slightly different frequencies, if we know approximate frequencies, we can develop the precise ratio by looking at the sampled results. Although crystal oscillators do drift over time and temperature, they don't drift very much, and they tend to follow a similar pattern from power-on when they do. One can handwave about "processor code path, cache hits, bus wait states," but the "processor code path" is the program, and it seems quite likely that the program used for random bits once will be used again. So the cache contents will tend to be the same, as will the bus wait states. We are talking about essentially error-free digital systems: There is no reason to expect these things to be "random," just complex. In practice, the major factor which encourages the belief in the "randomness" of such systems is probably memory refresh, which interrupts processing periodically and -- on the surface -- unexpectedly. But by "periodically" we typically mean a crystal-controlled precise period between interrupts. We will know the expected period, as well as the computation consequences when the interrupt is taken, and any deviations from this will just help us to further refine the exact internal state of the hardware. The "jitter" in a crystal oscillator is best modeled as noise in the analog-to-digital conversion -- a bipolar cycle-by-cycle phase difference. The magnitude is tiny and typically normally-distributed, so small values are frequent, but large values are rare. So the probability that this sort of jitter will affect the digital result in any particular cycle is very small. But it *will* show up eventually, and when it does, it will reveal the exact internal state of the oscillator. (That is, that it was close enough to the digital square-wave edge to be affected by the tiny noise variation.) I claim that these sorts of RNG are best understood as fairly-complex PSEUDO-random generators, with only small amounts of uncertainty beyond their internal hardware state. It would be extremely unwise to hope they could oppose a well-equipped and well-financed attack on their sequence. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: Pentium III... Date: Sat, 23 Jan 1999 20:08:45 GMT From: janb@pmatrix.com Message-ID: <78da88$fco$1@nnrp1.dejanews.com> References: <36a91475.8443843@news.io.com> Newsgroups: sci.crypt Lines: 61 In article <36a91475.8443843@news.io.com>, ritter@io.com (Terry Ritter) wrote: > and I dispute the idea that this is particularly "random." What it is > is "complex," but this is the complexity of digital logic state > machines whose structure is known. If the clock skew were the ONLY factor, this might not be such a good choice. I used the title of clock skew because people would recognize the implementation strategy. There are MANY other activities affecting the code execute code, and also may access memory via DMA, causing memory access wait state variations. If you have methods to predict the time, within 3 nanoseconds, of every network packet flowing into a device, there are some folks from Cisco who would want to talk to you. As far as I know, the instant in time that someone in the world clicks a link on a web page, is a random event. These events will influence the code path of the sample time on a web server, causing true randomness. For any computer that has a UI, every keystroke or mouse moment causes code path variations, triggered by true random events. The software generator I mentioned also had three algorithms, to deal with the potential that one (or even two) had a weakness. Stirring a less random soure together with a more random source gives the more random result. Do you also believe disk seeks are highly predicatble? Your also suggesting you can take the output from a cryptographic hash (assuming we hash the data from the original source generator), and exactly predict the patterns of the input, to analyze the patterns originally generated. I've heard of some success in generating MD5 hashes with specific output bits at specific values, but haven't heard of a total breakdown in the integrity of either MD5 or SHA-1. Are you suggesting cryptographic hashes are reversable? That gives a hash, you can calculate the number and value of input bits? I agree that if you put a system in a lab under very controlled conditions, you may be able to predict or influence things better. The software I worked on and I believe software running on most peoples systems will not be under these conditions. The topic of this thread is about the usefulness of a hardware random number generator in a Pentium III. My belief is anybody who is serious about security, will want some external hardware device anyway. So doing security on a PC without extra hardware only applies for 'low' security uses. I believe software generated random numbers are very sufficent for this. Really, I'd love to see some hardware support for security in PC's. I just don't think Intel's latest features improve things much. I don't believe the weakest link is in the quality of random number generators. I think a socket on motherboards for an iButton would be a lot better (and cost very little). For lowest security uses, just a serial number button with costs a buck. If users wanted better security, a crypto iButton could be popped in for a dozen or two bucks. Of course this would work just as well for Intel, AMD, and Cyrix processors, which may not be Intel's goal. - Jan P.S. I really have no connection with Dallas Semi. I just like iButtons more and more when I think about the problems that need solving. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Subject: Re: Pentium III... Date: Sun, 24 Jan 1999 05:08:43 GMT From: ritter@io.com (Terry Ritter) Message-ID: <36aaaad8.5611074@news.io.com> References: <78da88$fco$1@nnrp1.dejanews.com> Newsgroups: sci.crypt Lines: 161 On Sat, 23 Jan 1999 20:08:45 GMT, in <78da88$fco$1@nnrp1.dejanews.com>, in sci.crypt janb@pmatrix.com wrote: >In article <36a91475.8443843@news.io.com>, > ritter@io.com (Terry Ritter) wrote: >> and I dispute the idea that this is particularly "random." What it is >> is "complex," but this is the complexity of digital logic state >> machines whose structure is known. > >If the clock skew were the ONLY factor, this might not be such a good choice. >I used the title of clock skew because people would recognize the >implementation strategy. There are MANY other activities affecting the code >path between each sample. For example, I/O activity causes the processor to >execute code, and also may access memory via DMA, causing memory access wait >state variations. But I/O activity is programmed -- presumably we will be re-using the same program, and can expect similar activity. And DMA activity is also programmed. If we have other tasks running, AND those tasks are actually doing something *while* we take "random" samples, that would be more complex. But if (as we expect) sampling is frequent compared to task-changes, most samples will be related and unaffected within the period of the sampling task, making the supposed increase in complexity largely illusory. >If you have methods to predict the time, within 3 >nanoseconds, of every network packet flowing into a device, there are some >folks from Cisco who would want to talk to you. So, basically, you recommend generating random numbers while actively on line and communicating with a network. That may not be the best approach. If external communications are the key to randomness, we'd sure better hope The Opponent is not monitoring that line (to say nothing of actively *influincing* that timing). Can we be sure? >As far as I know, the instant >in time that someone in the world clicks a link on a web page, is a random >event. For a random person, for one click, yes. But when that person makes repeated clicks, no. >These events will influence the code path of the sample time on a web >server, causing true randomness. Producing cryptographic random values on a web server does not sound like a great idea to me. >For any computer that has a UI, every >keystroke or mouse moment causes code path variations, triggered by true >random events. With respect to keystrokes, every keystroke is first sampled in the keyboard by a scanning process. That scanning process occurs periodically, typically under the control of yet another crystal oscillator. Key strokes are thus quantized in time, which is hardly "random." This problem probably does not apply to a mouse. But for this to work, we have to be using that mouse while we are actively producing random numbers, and our failure to do so will affect the quality of the results. >The software generator I mentioned also had three algorithms, to deal with the >potential that one (or even two) had a weakness. Stirring a less random soure >together with a more random source gives the more random result. It also means that all the discussion and handwaving about the less random source is essentially irrelevant. >Do you also >believe disk seeks are highly predicatble? I do *indeed* believe that disk seeks are highly predictable (which is not to say that they can be predicted to the nanosecond, but that they can be approximated to virtually arbitrary precision). If we know the current rotational angle, and the number of tracks to cross, and the characteristics of the particular drive, seek time is highly predictable. And we know the rotational angle from the last seek and read, and the time elapsed. Typically, disk rotation is yet another crystal-controlled entity. >Your also suggesting you can take the output from a cryptographic hash >(assuming we hash the data from the original source generator), and exactly >predict the patterns of the input, to analyze the patterns originally >generated. I have suggested no such thing. But it was my understanding that you were talking about *real* randomness, as opposed to a hashed or encrypted counter. If we are willing to accept the latter, all we need is a simple polynomial counter and a cryptographic hash or cipher, and we can avoid all this hardware-software-randomness stuff. >I've heard of some success in generating MD5 hashes with specific >output bits at specific values, but haven't heard of a total breakdown in the >integrity of either MD5 or SHA-1. Are you suggesting cryptographic hashes are >reversable? That gives a hash, you can calculate the number and value of input >bits? > >I agree that if you put a system in a lab under very controlled conditions, >you may be able to predict or influence things better. The software I worked >on and I believe software running on most peoples systems will not be under >these conditions. "Belief" is arguably the major problem in cryptography: Most people who propose cryptographic systems *believe* that nobody could crack their complex design. But upon what reality is such belief based? >The topic of this thread is about the usefulness of a hardware random number >generator in a Pentium III. My belief is anybody who is serious about >security, will want some external hardware device anyway. So doing security >on a PC without extra hardware only applies for 'low' security uses. I >believe software generated random numbers are very sufficent for this. "Software generated random numbers" will be sufficent for exactly as long as it takes someone to efficiently solve the system and produce a cracking routine. When cracking is trivial, the result is NO security at all, not even "low" security. And they will not tell you when they succeed. >Really, I'd love to see some hardware support for security in PC's. I just >don't think Intel's latest features improve things much. I don't believe the >weakest link is in the quality of random number generators. I think a socket >on motherboards for an iButton would be a lot better (and cost very little). >For lowest security uses, just a serial number button with costs a buck. If >users wanted better security, a crypto iButton could be popped in for a dozen >or two bucks. Of course this would work just as well for Intel, AMD, and >Cyrix processors, which may not be Intel's goal. This particular discussion was about the recent announcement of a serial number and RNG on the processor chip. But information from Intel last month involves a BIOS storage chip with hardware public-key type operations. The protected BIOS is more likely to be the source of software security than the processor SN. So the other shoe has yet to drop. And the other processor guys may not know what they will do yet. --- Terry Ritter ritter@io.com http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Subject: Re: Pentium III... Date: Mon, 1 Feb 1999 11:09:00 GMT From: sjmz@hplb.hpl.hp.com (Stefek Zaba) Message-ID: <F6H2z0.5p@hplb.hpl.hp.com> References: <36aaaad8.5611074@news.io.com> Newsgroups: sci.crypt Lines: 22 In sci.crypt, Terry Ritter (ritter@io.com) wrote: > Producing cryptographic random values on a web server does not sound > like a great idea to me. A "great" idea it may not be, but - at a plausible guess - well over 90% of "cryptographic random numbers" in fielded use today are being generated on web servers and clients. I make this guesstimate on the grounds that the most widely-deployed crypto protocol on the Net is SSL/TLS, with HTTP as the dominant traffic carried by SSL. The session keys are generated by the client alone (SSLv2), or co-operatively by client and server (SSLv3/TLS). Depending on the platform, the degree of interaction with less predictable external events may be lesser or greater - /dev/random on Linux boxes, crufty combinations of (high-resolution) hard disk seek times and activities of other processes on Windows implementations. It's very rare for fielded e-commerce sites to run RNG hardware at the server end - and even if you do, there's no way for the server to influence the session key under SSLv2 :-( Having an on-chip source of unpredictability to stir into the mix should be a help; it won't be if it's carelessly implemented or carelessly used, though. Stefek
Subject: Re: Pentium III... Date: Fri, 22 Jan 1999 12:17:00 -0600 From: jgfunj@vgrknf.arg (wtshaw) Message-ID: <jgfunj-2201991217000001@dial-244-161.itexas.net> References: <36a78709.23154884@nntp.ix.netcom.com> Newsgroups: sci.crypt Lines: 20 In article <36a78709.23154884@nntp.ix.netcom.com>, rcktexas@ix.netcom.com wrote: > > You would think the industry learned its lesson from the old days of > closed architectures, key-based S/W, dongle keys, etc. I can just see > Ziff Davis refusing to test anything that is Pentium III based. > Sometimes one must think in an obtuse way to see what one should be looking out for. If some vital part of a computer, say the bios in a new package that one just "had to have" also contained the internal battery to sustain it, a serial number could be installed at the same time the battery was purchased. I suppose one could simply add a switch of some sort to go between several such chips. Then, buried deep in the system, a check might be added to verify that a registered bios was installed.... Embedded id's are just another step in an endless series of trumphs and overtrumphs to put security on yours or someone else's terms. -- A much to common philosophy: It's no fun to have power....unless you can abuse it.
Subject: Re: Pentium III... Date: Thu, 21 Jan 1999 23:03:12 +0000 From: Anthony Naggs <amn@ubik.demon.co.uk> Message-ID: <JxTxdyAwI7p2Ewas@ubik.demon.co.uk> References: <787vlr$3b4$1@nnrp1.dejanews.com> Newsgroups: sci.crypt Lines: 15 After much consideration ? decided to share these wise words: > >> Intel has announced that the Pentium III will have a built in hardware >> random number generator, and individual serial number on each chip. > >The primary use for a processor serial number seems like it would be to >enforce software licenses. IMO The primary use for a unique processor serial number is for easy identification of stolen processors, i.e. through software without dismantling suspect PCs & removing heatsink assemblies. -- BAD COMPUTER! That's my registry file you've trashed.
Subject: Re: Pentium III... Date: Sun, 24 Jan 1999 18:27:18 GMT From: William Hugh Murray <whmurray@sprynet.com> Message-ID: <36AB6605.DBB48168@sprynet.com> References: <36A676E3.E8D27B14@egg.chips.and.spam.com> Newsgroups: sci.crypt Lines: 47 This is a multi-part message in MIME format. --------------57A0885E6C73978430B690B7 Anthony Naggs wrote: > > After much consideration ? decided to share these wise words: > > > >> Intel has announced that the Pentium III will have a built in hardware > >> random number generator, and individual serial number on each chip. > > > >The primary use for a processor serial number seems like it would be to > >enforce software licenses. > > IMO The primary use for a unique processor serial number is for easy > identification of stolen processors, i.e. through software without > dismantling suspect PCs & removing heatsink assemblies. How about as a quid quo pro for an export license for the RNG? --------------57A0885E6C73978430B690B7 name="whmurray.vcf" filename="whmurray.vcf" begin:vcard n:Murray;William Hugh tel;fax:800-690-7952 tel;home:203-966-4769 tel;work:203-761-3088 org:Deloitte Touche adr:;;24 East Avenue, Suite 1362;New Canaan;Connecticut;06840; version:2.1 email;internet:whmurray@sprynet.com title:Executive Consultant, Information Security fn:William Hugh Murray end:vcard --------------57A0885E6C73978430B690B7--
Subject: Re: Pentium III... Date: Tue, 26 Jan 1999 11:36:51 GMT From: leadacid.remove-this@remove-this.hotmail.com (Myself) Message-ID: <36ad2ff2.317075143@news.123.net> References: <787vlr$3b4$1@nnrp1.dejanews.com> Newsgroups: sci.crypt Lines: 10 On Thu, 21 Jan 1999 19:37:32 GMT, thermal and electromagnetic action caused janb@pmatrix.com's brain to produce the following pseudorandom thought: >The OS is licensed to a specific machine, which might be interpreted as a >specific processor. And in reply, my brain hashed together this little bit of thoughtsum: What do we do about multiprocessor machines? -Myself-
Subject: Re: Pentium III... Date: Tue, 26 Jan 1999 16:05:24 +0000 From: Marty Levy <rwww60@email.sps.mot.com> Message-ID: <36ADE7C3.1FBF146C@email.sps.mot.com> References: <36ad2ff2.317075143@news.123.net> Newsgroups: sci.crypt Lines: 7 Does anyone know the mechanism Intel plans to use to put the infamous serial numbers on Pentium III chips? I wasn't aware that Pentiums had any non-volitaile memory (other than ROM) on board. The only practical systems I can think of is to use a fuse or laser repair type scheme.
Subject: Re: Pentium III... Date: Wed, 27 Jan 1999 07:09:41 -1000 From: handWave <shaken@stirred.com> Message-ID: <36AF4855.60ED@stirred.com> References: <36ADE7C3.1FBF146C@email.sps.mot.com> Newsgroups: sci.crypt Lines: 22 Marty Levy wrote: > > Does anyone know the mechanism Intel plans to use to put the infamous serial > numbers on Pentium III chips? I wasn't aware that Pentiums had any > non-volitaile memory (other than ROM) on board. The only practical systems I > can think of is to use a fuse or laser repair type scheme. When I worked at Intel I showed them how to make EPROM cells using the ordinary microprocessor wafer fabrication process. In 1986 I drew the "single poly EPROM cell" on the CAD system, had it processed on a test wafer, tested it, and it worked. I told the marketing department about it. I wrote it up in my patent notebook. I told them to use it as a serial number for the 80386, for key storage and for fabrication lot tracking for process analysis. The first generation of EPROM cells during the 1970's also used a single polycrystaline silicon layer. I have not seen the pentoid three, but I expect that it uses this memory cell. It is better than a fuse because it does not explode and crater the top oxides which protect the chip from chemical contamination. Ask Larry Palley at Intel. Or Kurt Robinson at Intel. They know I did these things, and they should send me a royalty check. They know my name, even if sci.crypt does not.
Subject: Re: Pentium III... Date: Thu, 28 Jan 1999 01:54:58 +0100 From: fungus <spam@egg.chips.and.spam.com> Message-ID: <36AFB562.D3E77F17@egg.chips.and.spam.com> References: <36AF4855.60ED@stirred.com> Newsgroups: sci.crypt Lines: 20 handWave wrote: > > In 1986 I drew the > "single poly EPROM cell" on the CAD system, had it processed on a test > wafer, tested it, and it worked. I told the marketing department about > it. I wrote it up in my patent notebook. I told them to use it as a > serial number for the 80386, for key storage and for fabrication lot > tracking for process analysis. > ...so you're personally to blame for all this! -- <\___/> / O O \ \_____/ FTB.
Subject: Re: Pentium III... Date: 27 Jan 1999 09:58:11 -0500 From: Bruce Barnett <see.my.address.below@domain.com> Message-ID: <yek3e4wsqyk.fsf@grymoire.crd.ge.com> References: <787vlr$3b4$1@nnrp1.dejanews.com> Newsgroups: sci.crypt Lines: 11 janb@pmatrix.com writes: > I can think of cases where having a machine serial number would be somewhat > handy. I'm not sure I would build it into the processor though. And what do you do with a 2,4,8 or 64-CPU server? It's the big servers that need it. Dynamic roll-over should be interesting... -- Bruce <barnett at crd. ge. com> (speaking as myself, and not a GE employee)
Subject: Re: Pentium III... Date: Thu, 28 Jan 1999 22:45:03 GMT From: janb@pmatrix.com Message-ID: <78qp9d$2v3$1@nnrp1.dejanews.com> References: <yek3e4wsqyk.fsf@grymoire.crd.ge.com> Newsgroups: sci.crypt Lines: 21 In article <yek3e4wsqyk.fsf@grymoire.crd.ge.com>, Bruce Barnett <see.my.address.below@domain.com> wrote: > janb@pmatrix.com writes: > > > I can think of cases where having a machine serial number would be somewhat > > handy. I'm not sure I would build it into the processor though. > > And what do you do with a 2,4,8 or 64-CPU server? > It's the big servers that need it. > Dynamic roll-over should be interesting... I don't see any difference between 1 or 64 processors, big servers or handheld devices. Pretty much every applications I can think of (except mabey reducing CPU theft) would want a unique identity (serial number) for each system. A system might even be a cluster. My preference would be to have that system identity survive cpu and hardware upgrades/changes. - Jan -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Subject: Re: Pentium III... Date: 03 Feb 1999 10:53:58 -0500 From: Bruce Barnett <see.my.address.below@domain.com> Message-ID: <yekd83rqy95.fsf@grymoire.crd.ge.com> References: <78qp9d$2v3$1@nnrp1.dejanews.com> Newsgroups: sci.crypt Lines: 32 janb@pmatrix.com writes: > I don't see any difference between 1 or 64 processors, big servers or handheld > devices. Pretty much every applications I can think of (except mabey reducing > CPU theft) would want a unique identity (serial number) for each system. A > system might even be a cluster. My preference would be to have that system > identity survive cpu and hardware upgrades/changes. Exactly. But putting the ID on the chip makes this difficult/ impossible. I've talked to field server people that get upset when they have to replace a disk drive, and the security ID changes, and breaks the system. Same will be true in a fortified server. If the one chip that has the master ID fails, and is swapped, the entire system becomes invalid. You have to shut down the server and re-establish identities between every system it has an association with. So - picture a server with 100,000 clients. The clients trust the server. The server fails, and needs a new CPU. The 100,000 clients no longer trust the server. Where is the documents that explain the algorithm in detail? So far it seems to be vaporware. Security documents must be reviewed by peers. Until they do, they are useless. It's even useless to speculate about them. -- Bruce <barnett at crd. ge. com> (speaking as myself, and not a GE employee)
Subject: Re: Pentium III... Date: Fri, 22 Jan 1999 14:21:15 +0000 From: Guy Dawson <guy@crossflight.co.uk> Message-ID: <36A8895B.752DCF1C@crossflight.co.uk> References: <36A676E3.E8D27B14@egg.chips.and.spam.com> Newsgroups: sci.crypt Lines: 22 fungus wrote: > > Intel has announced that the Pentium III will have a built in hardware > random number generator, and individual serial number on each chip. This makes it much easier (well, possible) to determine if a chip is one of a batch of stolen chips. There have been quite a number of raid on truck carrying Intel CPUs. They're currently easy to sell on the black market as they are commodity items that can't be traced. The rated CPU speed can also be recorded against the serial number and this used to determine if a supplier is re-rating CPUs. That is, taking a 333Mhz Celeron and passing it off as a 400MHz one. Guy -- -------------------------------------------------------------------- Guy Dawson I.T. Manager Crossflight Ltd guy@crossflight.co.uk 0973 797819 01753 776104
Subject: Re: Pentium III... Date: Fri, 22 Jan 1999 16:32:53 GMT From: rcktexas@ix.netcom.com (R. Knauer) Message-ID: <36a8a535.22005892@nntp.ix.netcom.com> References: <36A8895B.752DCF1C@crossflight.co.uk> Newsgroups: sci.crypt Lines: 24 On Fri, 22 Jan 1999 14:21:15 +0000, Guy Dawson <guy@crossflight.co.uk> wrote: >This makes it much easier (well, possible) to determine if a chip >is one of a batch of stolen chips. >There have been quite a number of raid on truck carrying Intel CPUs. >They're currently easy to sell on the black market as they are >commodity items that can't be traced. >The rated CPU speed can also be recorded against the serial number >and this used to determine if a supplier is re-rating CPUs. That is, >taking a 333Mhz Celeron and passing it off as a 400MHz one. I guess the next thing is to keep a database on your DNA so you can be followed everywhere you go. <jeez> Bob Knauer "It is not the function of our government to keep the citizen from falling into error; it is the function of the citizen to keep the government from falling into error." --Justice Robert H. Jackson
Subject: Re: Pentium III... Date: Sat, 23 Jan 1999 19:33:07 -0700 From: Robert Yoder <ryoder@tci.com> Message-ID: <36AA8663.5160B4AE@tci.com> References: <36A8895B.752DCF1C@crossflight.co.uk> Newsgroups: sci.crypt Lines: 57 Guy Dawson wrote: > > fungus wrote: > > > > Intel has announced that the Pentium III will have a built in hardware > > random number generator, and individual serial number on each chip. > > This makes it much easier (well, possible) to determine if a chip > is one of a batch of stolen chips. > > There have been quite a number of raid on truck carrying Intel CPUs. > They're currently easy to sell on the black market as they are > commodity items that can't be traced. > > The rated CPU speed can also be recorded against the serial number > and this used to determine if a supplier is re-rating CPUs. That is, > taking a 333Mhz Celeron and passing it off as a 400MHz one. According to: http://www4.tomshardware.com/releases/99q1/990121/cpu-news-01.html "The new identification number is not targeted against processor remarking and Intel is not planning to provide a list where each identification numbers refers to the proper CPU speed. This number is not meant to fight overclocking, it's only meant to improve network security." The official Intel blurb is toward the end of this lengthy example of handwaving: http://www.intel.com/pressroom/archive/speeches/pg012099.htm Do yourself a favor and search the page for the word "serial" and begin reading from there to the end. Being forced to read the whole thing is a violation of the Geneva Convention. Apparently, Intel seriously wants us to believe that having a unique number embedded in your CPU is a giant leap in network security for user authentication. Well since the only thing that goes out on the wire, is what the OS puts on that wire, and the OS is composed of _SOFTWARE_, not _HARDWARE_, I submit that the whole thing has less validity than cold fusion. I suspect that the CPU ID was driven by large commerical software vendors who wanted a way to node-lock their licenses, and Intel is trying cover the whole thing with a sugar-coating and convince the consumers that this is good for us. Robert Yoder -- ryoder@tci.com "Unix: The Solution to the W2K Problem."
Subject: Re: Pentium III... Date: 24 Jan 1999 17:21:56 -0800 From: mskala@ansuz.sooke.bc.ca. (Matthew Skala) Message-ID: <78ggvk$23i$1@ruby.ansuz.sooke.bc.ca> References: <36AA8663.5160B4AE@tci.com> Newsgroups: sci.crypt Lines: 22 In article <36AA8663.5160B4AE@tci.com>, Robert Yoder <ryoder@tci.com> wrote: >I suspect that the CPU ID was driven by large commerical software >vendors who wanted a way to node-lock their licenses, and Intel is >trying cover the whole thing with a sugar-coating and convince the >consumers that this is good for us. It's good for me. I want to build large parallel processors; if each CPU has its own ID number, that may make it easier for then to talk to each other without interferance. I don't really need it, I can get the same functionality in other ways, but it has a small nonzero dollar value. I'm not afraid of it being used to identify me - ethernet cards, PC cases, and hard drives all have serial numbers on them already anyway. The CPU ID is less threatening because nobody's going to be able to read my CPU ID number without first being able to execute programs on my machine. If someone is so stupid as to use my CPU ID (or more properly, what my machine *claims* is its CPU ID) for network security, then I can have some real fun. -- The third girl had an upside-down penguin on Matthew Skala her stomach, so the doctor told her, "I'll Ansuz BBS examine you for free, if you and your (250) 472-3169 boyfriend will debug my Web server." http://www.islandnet.com/~mskala/
Subject: Re: Pentium III... Date: Sun, 24 Jan 1999 19:43:42 -0700 From: Robert Yoder <ryoder@tci.com> Message-ID: <36ABDA5E.7D961BCC@tci.com> References: <78ggvk$23i$1@ruby.ansuz.sooke.bc.ca> Newsgroups: sci.crypt Lines: 70 Matthew Skala wrote: > > In article <36AA8663.5160B4AE@tci.com>, Robert Yoder <ryoder@tci.com> wrote: > >I suspect that the CPU ID was driven by large commerical software > >vendors who wanted a way to node-lock their licenses, and Intel is > >trying cover the whole thing with a sugar-coating and convince the > >consumers that this is good for us. > > It's good for me. I want to build large parallel processors; if each CPU > has its own ID number, that may make it easier for then to talk to each > other without interferance. I don't really need it, I can get the same > functionality in other ways, but it has a small nonzero dollar value. Now I don't have any experience with multi-CPU Intel machines, but I _DO_ have experience with multi-CPU SPARC machines, and in that environment, every CPU has it's own ID based on _WHERE_ it is plugged in, and not on a CPU-specific hard-coded number. e.g. $ psrinfo -v Status of processor 0 as of: 01/24/99 19:27:11 Processor has been on-line since 01/15/99 16:57:08. The sparc processor operates at 248 MHz, and has a sparc floating point processor. Status of processor 1 as of: 01/24/99 19:27:11 Processor has been on-line since 01/15/99 16:57:12. The sparc processor operates at 248 MHz, and has a sparc floating point processor. Status of processor 4 as of: 01/24/99 19:27:11 Processor has been on-line since 01/15/99 16:57:12. The sparc processor operates at 248 MHz, and has a sparc floating point processor. Status of processor 5 as of: 01/24/99 19:27:11 Processor has been on-line since 01/15/99 16:57:12. The sparc processor operates at 248 MHz, and has a sparc floating point processor. $ In this machine, (E6000), board slots 0 and 2 contain CPU/memory boards, and each board hold 2 CPU's. Surely an Intel machine can do something equivalent w/o hard-coding a number into the CPU. > I'm not afraid of it being used to identify me - ethernet cards, PC cases, > and hard drives all have serial numbers on them already anyway. The CPU ID > is less threatening because nobody's going to be able to read my CPU ID > number without first being able to execute programs on my machine. If > someone is so stupid as to use my CPU ID (or more properly, what my > machine *claims* is its CPU ID) for network security, then I can have some > real fun. But in the case of MAC-addresses, we haven't had a huge corporation trying to tell us, (with a straight face), that the MAC address can be used for user authentification. Sun has had a "hostid" embedded in a MB chip for ages which is used for s/w licensing, and HP has had a similar feature for years, but neither of them have ever tried to tell us this could be used for user authentication. (And if you look around the net you can find a s/w program that will circumvent the Sun hostid.) I don't have any _FEAR_ of the CPU-ID "feature"; I just resent having my intelligence insulted by Intel lying to tell us about what it can be used for. And since I don't use third-rate proprietary OS's, I have no worry that my CPU-ID could ever be transmitted w/o my knowing. ry -- ryoder@tci.com "Unix: The Solution to the W2K Problem."
Subject: Re: Pentium III... Date: Mon, 25 Jan 1999 08:55:54 -0700 From: Robert Yoder <ryoder@tci.com> Message-ID: <36AC940A.2DF22C1A@tci.com> References: <36ABDA5E.7D961BCC@tci.com> Newsgroups: sci.crypt Lines: 15 Check this out: http://www.news.com/News/Item/0,4,31354,00.html?st.cn.fd.tkr.ne Two different organizations are organizing a boycott of Intel because the CPU ID is "an invasion of privacy". If Intel hadn't lied to us about the purpose of the CPU ID, there wouldn't even _BE_ a privacy issue! ry -- ryoder@tci.com "Unix: The solution to the W2K Problem."
Terry Ritter, his current address, and his top page.
Last updated: 1999-02-21