Re: defending against evil in all layers of hardware and software
On Tue, 29 Apr 2008, Ivan Krsti?~G wrote: > On Apr 28, 2008, at 12:58 PM, John Denker wrote: > > Of course we should insist on an open-source boot ROM code: > > The boot ROM should check the pgp signature of each PCI card's > > BIOS code before letting it get control. And then it should > > check the pgp signature of the operating system before booting > > it. I don't know of any machine that actually does this > > > The OLPC XO-1 laptop has an open-source bootloader (Open Firmware) which > checks the operating system signature before passing control to it. If the bootloader is running on malicious hardware I don't think that test can be trusted. :( -- Jonathan Thornburg (remove -animal to reply) <[EMAIL PROTECTED]> School of Mathematics, U of Southampton, England "C++ is to programming as sex is to reproduction. Better ways might technically exist but they're not nearly as much fun." -- Nikolai Irgens
Re: defending against evil in all layers of hardware and software
Stephan Neuhaus <[EMAIL PROTECTED]> writes: > On Apr 28, 2008, at 23:56, Perry E. Metzger wrote: > >> If you have a rotten apple engineer, he will be able to hide what he's >> trying to do and make it look completely legit. If he's really good, >> it may not be possible to catch what he's done EVEN IN PRINCIPLE. > > Fred Cohen proved in 1984 in his "Computer Viruses, Theory and > Experiments"[1] that "Program P is a virus" is undecidable. He needn't have bothered. All non-trivial properties of programs are undecidable. Rice's Theorem, you know. Such a proof is one line -- you need merely assert that "X is a virus" is a non-trivial property (that is, a property that is only true of some programs). Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: defending against evil in all layers of hardware and software
On Apr 28, 2008, at 12:58 PM, John Denker wrote: Of course we should insist on an open-source boot ROM code: The boot ROM should check the pgp signature of each PCI card's BIOS code before letting it get control. And then it should check the pgp signature of the operating system before booting it. I don't know of any machine that actually does this The OLPC XO-1 laptop has an open-source bootloader (Open Firmware) which checks the operating system signature before passing control to it. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: defending against evil in all layers of hardware and software
On Apr 28, 2008, at 2:56 PM, Perry E. Metzger wrote: I'm pretty sure we can defend against this sort of thing a lot of the time (by no means all) if it is done by quite ordinary criminals. If it is done by really good people, I have very serious doubts. I think you just described all of security. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: defending against evil in all layers of hardware and software
On Apr 28, 2008, at 23:56, Perry E. Metzger wrote: If you have a rotten apple engineer, he will be able to hide what he's trying to do and make it look completely legit. If he's really good, it may not be possible to catch what he's done EVEN IN PRINCIPLE. Fred Cohen proved in 1984 in his "Computer Viruses, Theory and Experiments"[1] that "Program P is a virus" is undecidable. I assume that this result can be applied to hardware in the form that "Chip C contains malicious gates" is also undecidable. (Caveat: Cohen seems to make the fundamental assumption that there is no fundamental distinction between code and data, something that need not necessarily hold everywhere inside a computer chip.) Fun, Stephan [1] See for example http://vx.netlux.org/lib/afc01.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Just update the microcode (was: Re: defending against evil in all layers of hardware and software)
The "signature" in the microcode update has not the same meaning as within crypto. For intel chips it has 31bits and basically contains a revision number. The requirements for the BIOS for checking microcode updates are in short: check the crc and ensure that older revisions cant replace new ones by comparing the "signature". I did not try myself, but I think one can probably update anything if you just hexedit the update header. Afaik these chips do not own any crypto-related functionallity or storage capability (except precise timing and rand maybe) and they are not tamper-proof. Thats why TPM was invented :-) l8er, Sebastian On Mon, Apr 28, 2008 at 06:16:12PM -0400, John Ioannidis wrote: > Intel and AMD processors can have new microcode loaded to them, and this > is usually done by the BIOS. Presumably there is some asymmetric crypto > involved with the processor doing the signature validation. > > A major power that makes a good fraction of the world's laptops and > desktops (and hence controls the circuitry and the BIOS, even if they do > not control the chip manufacturing process) would be in a good place to > introduce problems that way, no? > > /ji > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- ~~ ~~ perl self.pl ~~ $_='print"\$_=\47$_\47;eval"';eval ~~ [EMAIL PROTECTED] - SuSE Security Team ~~ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Just update the microcode (was: Re: defending against evil in all layers of hardware and software)
[EMAIL PROTECTED] wrote: No need to be a major power. Linux patches x86 code, as does Windows. I ran across a project several years ago that modified the microcode for some i/o x86 assembly instructions. Here's a good link explaining it all. What the OS or the BIOS loads is files that come from Intel. There is some verification involved, as the processor won't just accept random bytes. You'll need a fair amount of money, as well as intelligence expertise, to get hold of the signing keys, not to mention the documentation for how to write microcode in the first place. I assume that's one of Intel's (and AMD's) closest-guarded secrets. http://en.wikipedia.org/wiki/Microcode "It must be true, I read it on the Internet" :) All this hw/sw flexibility makes designing a good security system a real challenge. You need a reference monitor somewhere in it that you can truly trust. - Alex That we agree on! /ji - Original Message - From: "John Ioannidis" <[EMAIL PROTECTED]> To: Cryptography Subject: Just update the microcode (was: Re: defending against evil in all layers of hardware and software) Date: Mon, 28 Apr 2008 18:16:12 -0400 Intel and AMD processors can have new microcode loaded to them, and this is usually done by the BIOS. Presumably there is some asymmetric crypto involved with the processor doing the signature validation. A major power that makes a good fraction of the world's laptops and desktops (and hence controls the circuitry and the BIOS, even if they do not control the chip manufacturing process) would be in a good place to introduce problems that way, no? /ji - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Just update the microcode (was: Re: defending against evil in all layers of hardware and software)
No need to be a major power. Linux patches x86 code, as does Windows. I ran across a project several years ago that modified the microcode for some i/o x86 assembly instructions. Here's a good link explaining it all. http://en.wikipedia.org/wiki/Microcode All this hw/sw flexibility makes designing a good security system a real challenge. You need a reference monitor somewhere in it that you can truly trust. - Alex > - Original Message - > From: "John Ioannidis" <[EMAIL PROTECTED]> > To: Cryptography > Subject: Just update the microcode (was: Re: defending against > evil in all layers of hardware and software) > Date: Mon, 28 Apr 2008 18:16:12 -0400 > > > Intel and AMD processors can have new microcode loaded to them, and > this is usually done by the BIOS. Presumably there is some > asymmetric crypto involved with the processor doing the signature > validation. > > A major power that makes a good fraction of the world's laptops and > desktops (and hence controls the circuitry and the BIOS, even if > they do not control the chip manufacturing process) would be in a > good place to introduce problems that way, no? > > /ji > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Just update the microcode (was: Re: defending against evil in all layers of hardware and software)
Intel and AMD processors can have new microcode loaded to them, and this is usually done by the BIOS. Presumably there is some asymmetric crypto involved with the processor doing the signature validation. A major power that makes a good fraction of the world's laptops and desktops (and hence controls the circuitry and the BIOS, even if they do not control the chip manufacturing process) would be in a good place to introduce problems that way, no? /ji - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: defending against evil in all layers of hardware and software
John Denker <[EMAIL PROTECTED]> writes: > This is an important discussion > > The threats are real, and we need to defend against them. I'm not sure how to feasibly defend against such things. It would seem to require complete control over the entire design and supply chain, which involves so many thousands of people who could be bribed that I have serious doubts that it can be done perfectly. > This should not be an occasion for idly wringing our hands, nor > sticking our head in the sand, nor looking under the lamp-post > where the looking is easy. We need to look at all of this stuff. > And we can. We are not defenseless. I'll believe that when I see feasible defenses. So far as I can tell, if you can't trust the hardware supplier, you're meat. I don't think it is possible even in principle to validate the hardware after the fact. Even if you could apply formal methods successfully, it isn't even obvious how you would specify the property of the system that you're trying to prove. "Never does anything bad" is kind of nebulous if you're doing proofs. > As in all security, we need not aim for absolute security. An > often-useful approach is to do things that raise the cost to > the attacker out of proportion to the cost to the defender. Well, this sort of thing is already not that interesting to an ordinary spammer or phisher -- they have no trouble making loads of money without engaging in such stuff. If you're talking about what a national government might pay to get such a back door in hardware, though, I think that it is probably worth billions to such an entity. After all, a decent bomber these days costs a billion dollars, and clearly this is a lot more potent. Given that, I don't see what would work in practice. If a major power wanted to turn a couple of engineers at the right place in the design or supply chain, the amount of money needed is far below the amount in play. > For software, for firmware, and to some extent even for silicon > masks, SCM (source code management) systems, if used wisely, can > help a lot. If you have a rotten apple engineer, he will be able to hide what he's trying to do and make it look completely legit. If he's really good, it may not be possible to catch what he's done EVEN IN PRINCIPLE. All an SCM can do is tell you who put the bad stuff in much after the fact if you ever catch it at all. That's not exactly "defense". It is at best "post mortem". > Of course we should insist on an open-source boot ROM code: > http://www.coreboot.org/Welcome_to_coreboot Won't help. A bad apple can probably manage a sufficiently subtle flaw that it won't be noticed by widespread code inspection. See Jerry's earlier posting on the subject. > Another line of defense involves closing the loop. For example, > one could in principle find Ken's trojan by disassembling the > compiler and looking for code that doesn't seem to "belong". Only if the bad guy doesn't anticipate that you might do that. I'm pretty sure we can defend against this sort of thing a lot of the time (by no means all) if it is done by quite ordinary criminals. If it is done by really good people, I have very serious doubts. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
defending against evil in all layers of hardware and software
This is an important discussion The threats are real, and we need to defend against them. We need to consider the _whole_ problem, top to bottom. The layers that could be subverted include, at a minimum: -- The cpu chip itself (which set off the current flurry of interest). -- The boot rom. -- The BIOS code that lives on practically every card plugged into the PCI bus. -- Board-level stuff like memory controllers and I/O bridges. -- The operating system. -- Compilers, as Uncle Ken pointed out. http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf -- Your "secure" application. -- Users. As a particular example where PCs that we might wish to be secure are known to be under attack, consider electronic voting machines. In most cases there's a PC in there, running Windows CE. Some application software was provided by people with felony fraud convictions. Means, motive, and opportunity are all present. There is ample evidence that "problems" have occurred. These are not confined to the Florida fiasco in 2000. An example from 2004 is the voting machine in Franklin County, Ohio that recorded 4,258 votes for Bush when only 638 voters showed up. http://www.truthout.org/Conyersreport.pdf This should not be an occasion for idly wringing our hands, nor sticking our head in the sand, nor looking under the lamp-post where the looking is easy. We need to look at all of this stuff. And we can. We are not defenseless. As in all security, we need not aim for absolute security. An often-useful approach is to do things that raise the cost to the attacker out of proportion to the cost to the defender. For software, for firmware, and to some extent even for silicon masks, SCM (source code management) systems, if used wisely, can help a lot. Consider for example a policy every delta to the software to be submitted by one person and tested by another before being committed to the main branch of the project. Both the submitter and the tester would digitally sign the delta. This creates a long-tailed liability for anybody who tries to sneak in a trojan This is AFAIK the simplest defense against high-grade attacks such as Ken's, which leave no long-term trace in the source code (because the trojan is self-replicating). The point is that there is a long-term trace in the SCM logs. We can make the logs effectively permanent and immutable. Of course we should insist on an open-source boot ROM code: http://www.coreboot.org/Welcome_to_coreboot The boot ROM should check the pgp signature of each PCI card's BIOS code before letting it get control. And then it should check the pgp signature of the operating system before booting it. I don't know of any machine that actually does this, but it all seems perfectly doable. Another line of defense involves closing the loop. For example, one could in principle find Ken's trojan by disassembling the compiler and looking for code that doesn't seem to "belong". I have personally disassembled a couple of operating systems (although this was back when operating systems were smaller than they are now). We can similarly close the loop on chips. As others have pointed out, silicon has no secrets. A cost-effective way to check for trojans would be to buy more voting machines than necessary, and choose /at random/ a few of them to be torn down for testing. (This has obvious analogies to sampling methods used in many crypto algorithms.) For starters, we grind open the CPU chips and check that they are all the same. That's much easier than checking the detailed functionality of each one. And we check that the CPUs in the voting machines are the same as CPUs from another source, perhaps WAL*MART, on the theory that the attacker finds it harder to subvert all of WAL*MART than to subvert just a truckload of voting machines. Checksumming the boot ROM in the torn-down machine is easy. I emphasize that we should *not* rely on asking a running machine to checksum its own ROMs, because it is just too easy to subvert the program that calculates the checksum. To defend against this, we tear down multiple machines, and give one randomly selected ROM to the Democratic pollwatchers, one to the Republican pollwatchers, et cetera. This way nobody needs to trusty anybody else; each guy is responsible for making sure _his_ checksummer is OK. All of this works hand-in-glove with old-fashioned procedural security and physical security. As the saying goes, if you don't have physical security, you don't have security. But the converse is true, too: Placing armed guards around a vault full of voting machines doesn't make the machines any less buggy than they were when they went into the vault. That's why we need a balanced approach that gets all the layers to work together. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMA
