Re: SSL and Malicious Hardware/Software
On Mon, Apr 28, 2008 at 03:12:31PM -0700, Ryan Phillips wrote: What are people's opinions on corporations using this tactic? I can't think of a great way of alerting the user, but I would expect a pretty reasonable level of privacy while using an SSL connection at work. Expectations of privacy at work vary by jurisdiction and industry. In the US, and say in the financial services industry, any such expectations are groundless (IANAL). -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - 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 cryptography@metzdowd.com 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)
[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 cryptography@metzdowd.com 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)
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: 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: 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 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: Designing and implementing malicious hardware
There are high assurance systems that exist that do eactly this. There are two different implementations of the security unit processing the same data. The outputs are compared by a seperate high assurance and validated module that enters into an alarm mode should the outputs differ. However, these are generally costly affairs, you need to pay two implementation teams etc, therefore remain the luxury of only the most critical systems. For hardware, this would mean running multiple chips in parallel checking each others states/outputs. Architectures like that have been built for reliability (e.g., Stratus), but generally they assume identical processors. Whether you can actually build such a thing with deliberately different processors is an open question. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Shor's algorithm in danger?
Hi, I saw the the email concerning Shor's algorithm to me. I want to respond to it, before the meme that Shor's algorithm has been discredited takes root. In one sentence, my position on Shor's algorithm: * There are very good reasons to take a Missouri show me attitude toward Shor's algorithm, but this paper probably does not change the arguments, and a variety of people much smarter than me have analyzed the algorithm in more detail and are pretty convinced it's going to work with acceptable scaling. A one-sentence summary of the paper: * Quantum error correction doesn't work. In order to believe that Shor doesn't work, you have to believe that either the algorithm fundamentally doesn't scale, or that quantum error correction doesn't work. Or, conclude that the paper is in error for some reason. I think it's likely that the authors have inferred too much from a relatively limited set of experiments. Essentially, what they have done is a simple simulation of an imperfect inverter and extrapolated from that to the performance of a complete system. If someone handed you an unrefereed tech report that said, Transistors are noisy, so a microprocessor can't work, would you believe it? Today, of course not, but even forty years ago your first response would probably have been to seek out the opinion of an expert, or wait for the paper to be refereed before bothering with it. With quantum computers, we don't yet have a working, large-scale machine, but would you prefer to believe a set of papers already vetted by smart people, or an unrefereed one? I don't mean to disparage the authors; I know neither of them personally, but the second author, at least, has done good work. But this paper, I think, is questionable. In summary, the paper in question (arXiv:0804.3076) would have broad implications for the ability of quantum computers to maintain state accurately enough to provide real-world acceleration over classical computers. It's a very legitimate concern, which gets raised occasionally by very smart people, and usually ends in a stalemate with the preponderance of quantum information people on the side of don't worry, QEC works. But it's not yet clear that this paper really pushes the argument forward in either direction. The paper is also not yet refereed, and it will be interesting to see how it changes as a result of any referee's comments. The authors may turn out to be right. More power to them in attempting to prove it; right or wrong, these arguments are often illuminating. Meantime, for all but a handful of people, we now return you to your regularly scheduled programming. I put a longer post, with references, on my blog at http://rdvlivefromtokyo.blogspot.com/2008/04/shors-algorithm-in-danger.html In the hopes that someone finds this useful, --Rod -- Rodney Van Meter Assistant Professor of Environment and Information Studies Keio University, Shonan Fujisawa Campus, Japan http://web.sfc.keio.ac.jp/~rdv/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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: SSL and Malicious Hardware/Software
On Mon, 28 Apr 2008, Ryan Phillips wrote: | Matt's blog post [1] gets to the heart of the matter of what we can | trust. | | I may have missed the discussion, but I ran across Netronome's 'SSL | Inspector' appliance [2] today and with the recent discussion on this | list regarding malicious hardware, I find this appliance appalling. It's not the first. Blue Coat, a company that's been building various Web optimization/filtering appliances for 12 years, does the same thing. I'm sure there are others. | Basically a corporation can inject a SSL Trusted CA key in the | keystore within their corporate operating system image and have this | device generate a new server certificate to every SSL enabled website, | signed by the Trusted CA, and handed to the client. The client does a | validation check and trusts the generated certificate, since the CA is | trusted. A very nice man-in-the-middle and would trick most casual | computer users. | | I'm guessing these bogus certificates can be forged to look like the | real thing, but only differ by the fingerprint and root CA that was | used to sign it. | | What are people's opinions on corporations using this tactic? I can't | think of a great way of alerting the user, but I would expect a pretty | reasonable level of privacy while using an SSL connection at work. I'm very uncomfortable with the whole business. Corporations will of course tell you it's their equipment and is there for business purposes, and you have no expectation of privacy while using it. I can understand the issues they face: Between various regulatory laws that impinge on the white-hot topic of data leakage and issues of workplace discrimination arising out of questionable sites, they are under a great deal of pressure to control what goes over their networks. But if monitoring everything is the stance they have to take, I would rather that they simply block encrypted connections entirely. As this stuff gets rolled out, there *will* be legal issues. On the one hand, the whole industry is telling you HTTPS to a secure web site - see that green bar in your browser? - is secure and private. On the other, your employer is doing a man-in-the-middle attack and, without your knowing it, reading your discussions with your doctor. Or maybe gaining access to your credit card accounts - and who knows who in the IT department might be able to sneak a peak. Careful companies will target these appliances at particular sites. They'll want to be able to prove that they aren't watching you order your medications on line, lest they run into ADA problems, for example. It's going to be very interesting to see how this all plays out. We've got two major trends crashing headlong into each other. One is toward tighter and tighter control over what goes on on a company's machines and networks, some of it forced by regulation, some of it because we can. The other is the growing technological workarounds. If I don't like the rules on my company's network, I can buy over-the-air broadband service and use it from my desk. It's still too expensive for most people today, but the price will come down rapidly. Corporate IT will try to close up machines to make that harder and harder to do, but at the same time there's a growing push for IT to get out of the business of buying, financing, and maintaining rapidly depreciating laptops. Better to give employees a stipend and let them buy what they want - and carry the risks. -- Jerry | Regards, | Ryan | | [1] http://www.crypto.com/blog/hardware_security/ | [2] http://www.netronome.com/web/guest/products/ssl_appliance - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL and Malicious Hardware/Software
On Mon, Apr 28, 2008 at 10:03:38PM -0400, Victor Duchovni wrote: On Mon, Apr 28, 2008 at 03:12:31PM -0700, Ryan Phillips wrote: What are people's opinions on corporations using this tactic? I can't think of a great way of alerting the user, but I would expect a pretty reasonable level of privacy while using an SSL connection at work. Expectations of privacy at work vary by jurisdiction and industry. In the US, and say in the financial services industry, any such expectations are groundless (IANAL). Most places I have worked (all in the US) explicitly required consent to more or less arbitrary amounts of monitoring as a condition of employment. -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Declassified NSA publications
On Fri, Apr 25, 2008 at 12:22 AM, Steven M. Bellovin [EMAIL PROTECTED] wrote: http://www.nsa.gov/public/crypt_spectrum.cfm I know this is silly but I could not resist to comment on some NSA redacts: http://www.literatecode.com/2008/04/29/nsaredact/ Ilya - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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: Doubts about efficiency of Shor's factoring algorithm in quantum computers
I can't say I entirely followed this paper, but I'm pretty sure that the paper neglects to take into account the fact that you can move to more aggressive error correction as the computer scales up. e.g. rather than just having each logical qbit encoded as 7 physical qbits, you could have each logical qbit encoded as 7 sub-logical qbits which are in turn represented by 7 logical qbits. From the simulation graph he gives, he can get an error rate of 10^-9 per operation in his logical qbits even with a rate of 10^-5 per operation on the physical qbits. I see no reason why a similar improvement wouldn't be possible with another round of encoding, or merely a more agressive code that can correct for multiple physical q-bit errors. Aside from that, I'm frankly not too impressed with the paper -- the author confuses 256-bit RSA with 256-bit ECC for example. Quantum computing is still quite a ways off, if nothing else for dumb economic reasons, but this paper doesn't really do much to convince me that it isn't a real possibility that we need to be worried about in the long term. On Mon, Apr 28, 2008 at 5:57 PM, Perry E. Metzger [EMAIL PROTECTED] wrote: Charles McElwain [EMAIL PROTECTED] writes: Follow-ups on this line of research will be interesting for the evaluation of any impact of quantum computers on cryptography, and even generally, since the decoherence behavior would tend to make quantum computers approximate improving classical computers. Very interesting indeed. I'd be curious about the opinions of people who know the field well. My QM and quantum computing knowledge aren't quite up to the task of analyzing the paper. From the Physics pre-print server arXiv, quantum physics section: http://arxiv.org/abs/0804.3076 Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
