Re: Dell to Add Security Chip to PCs
-- On 3 Feb 2005 at 22:25, Anonymous wrote: > Now, my personal perspective on this is that this is no real > threat. It allows people who choose to use the capability to > issue reasonably credible and convincing statements about > their software configuration. Basically it allows people to > tell the truth about their software in a convincing way. > Anyone who is threatened by the ability of other people to > tell the truth should take a hard look at his own ethical > standards. Honesty is no threat to the world! > > The only people endangered by this capability are those who > want to be able to lie. They want to agree to contracts and > user agreements that, for example, require them to observe > DRM restrictions and copyright laws, but then they want the > power to go back on their word, to dishonor their commitment, > and to lie about their promises. An honest man is not > affected by Trusted Computing; it would not change his > behavior in any way, because he would be as bound by his word > as by the TC software restrictions. The ability to convincingly tell the truth is a very handy one between people who are roughly equal. It is a potentially disastrous one if one party can do violence with impunity to the one with the ability to convincingly tell the truth. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 6B7i0tiB4vUHqQnAP6nXT2z+B+zLB8624+K6+ENU 47fFHg6cY0KInzxMe/l+L2c7LqmPZyrwOSZepYIR3 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dell to Add Security Chip to PCs
Dan Kaminsky wrote: TCPA eliminates external checks and balances, such as antivirus. As the user, I'm not trusted to audit operations within a TCPA-established sandbox. Antivirus is essentially a user system auditing tool, and TCPA-based systems have these big black boxes AV isn't allowed to analyze. Actually, as the owner of the Trusted Platform Module (TPM), you have complete control over the use of your TPM. This means you can prevent applications from using certain functions of the TPM, including creating and using keys. In addition, the TCG specifications may in fact enhance the AV experience by allowing AV programs to ensure audit log integrity using the Platform Configuration Registers (PCR's, 20-byte registers that store chained SHA-1 hashes) in conjunction with a stored measurement log. These PCR's may then be exported in a signed log (signed by the TPM endorsement key), ensuring that a rogue application has not tampered with the results of the AV scan. Imagine a sandbox that parses input code signed to an API-derivable public key. Imagine an exploit encrypted to that. Can AV decrypt the payload and prevent execution? No, of course not. Only the TCPA sandbox can. But since AV can't get inside of the TCPA sandbox, whatever content is "protected" in there is quite conspicuously unprotected. The TCPA (now TCG) does not define a sandbox in which Windows/*nix applications execute. It simply defines the TPM and the software that is responsible for ferrying messages back and forth from the TPM in the appropriate format (TSS - TCG Software Stack). You may be confusing the work of the TCG with work being done by both Microsoft (NGSCB/Palladium) and Intel (LaGrande). While MS may use the TPM to bootstrap an OS capable of executing sandboxed applications, this is not the result of work done by the TCG, which is a consortium of many companies (including MS, Intel, HP, IBM, Sun, AMD, etc.) with varying goals. So, in your example above, once the exploit code is decrypted, it is *outside* the TPM, and thus subject to all normal system inspection software. So yes, the AV program could in fact prevent execution of an exploit encrypted to a key contained within the TPM trust boundary*. However, a LaGrande/NGSCB system may be subject to the attack you describe. *I say boundary because the TPM does not in fact store public/private keypairs internally. Rather it encrypts all keypairs using the Storage Root Key (SRK) - a 2048-bit RSA keypair - and then exports the key for storage on the local storage device (most commonly the hard disk). Another noteworthy aspect of all TPM devices on the market today (version 1.1 of the TCG specifications) is that they do NOT perform symmetric encryption, only asymmetric encryption and hashing (RSA and SHA-1, respectively, as required by the standard). Regards, Mike - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is 3DES Broken?
John Kelsey wrote:
From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
No, I meant CBC -- there's a birthday paradox attack to watch out for.
Yep. In fact, there's a birthday paradox problem for all the standard chaining modes at around 2^{n/2}.
For CBC and CFB, this ends up leaking information about the XOR of a couple plaintext blocks at a time; for OFB and counter mode, it ends up making the keystream distinguishable from random. Also, most of the security proofs for block cipher constructions (like the secure CBC-MAC schemes) limit the number of blocks to some constant factor times 2^{n/2}.
It seems that the block size of an algorithm then
is a severe limiting factor. Is there anyway to
expand the effective block size of an (old 8byte)
algorithm, in a manner akin to the TDES trick,
and get an updated 16byte composite that neuters
the birthday trick?
Hypothetically, by say having 2 keys and running
2 machines in parallel to generate a 2x blocksize.
(I'm just thinking of this as a sort of mental challenge,
although over on the OpenPGP group we were toying
with the idea of adding GOST, but faced the difficulty
of its apparent age/weakness.)
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dell to Add Security Chip to PCs
Trei, Peter wrote: It could easily be leveraged to make motherboards which will only run 'authorized' OSs, and OSs which will run only 'authorized' software. And you, the owner of the computer, will NOT neccesarily be the authority which gets to decide what OS and software the machine can run. If you 'take ownership' as you put it, the internal keys and certs change, and all of a sudden you might not have a bootable computer anymore. Goodbye Linux. Goodbye Freeware. Goodbye independent software development. It would be a very sad world if this comes to pass. Yes it would, many governments are turning to Linux and other freeware. Many huge companies make heavy use of Linux and and freeware, suddenly losing this would have a massive effect on their bottom line and possibly enough to impact the economy as a whole. Independent software developers are a significant part of the economy as well, and most politicians do not want to associate themselves with the concept of "hurting small business". Universities and other educational institutions will fight anything that resembles what you have described tooth and nail. To think that this kind of technology would be mandated by a government is laughable. Nor do I believe there will be any conspiracy on the part of ISPs to require to in order to get on the Internet. As it stands now most people are running 5+ year old computer and windows 98/me, I doubt this is going to change much because for most people, this does what they want (minus all the security vulnerabilities, but with NAT appliances those are not even that big a deal). There is no customer demand for this technology to be mandated, there is no reason why an ISP or vendor would want to piss off significant percentages of their clients in this way. The software world is becoming MORE open. Firefox and Openoffice are becoming legitimate in the eyes of government and businesses, Linux is huge these days, and the open source development method is being talked about in business mags, board rooms, and universities everywhere. The government was not able to get the Clipper chip passed and that was backed with the horror stories of rampant pedophilia, terrorism, and organized crime. Do you honestly believe they will be able to destroy open source, linux, independent software development, and the like with just the fear of movie piracy, mp3 sharing, and such? Do you really think they are willing to piss off large sections of the voting population, the tech segment of the economy, universities, small businesses, and the rest of the world just because the MPAA and RIAA don't like customers owning devices they do not control? It is entirely possibly that a machine like you described will be built, I wish them luck because they will need it. It is attempted quite often and yet history shows us that there is really no widespread demand for iOpeners, WebTV, and their ilk. I don't see customers demanding this, therefor there will probably not be much of a supply. Either way, there is currently a HUGE market for general use PCs that the end user controls, so I imagine there will always be companies willing to supply them. My primary fear regarding TCPA is the remote attestation component. I can easily picture Microsoft deciding that they do not like Samba and decide to make it so that Windows boxes simply cannot communicate with it for domain, filesystem, or authentication purposes. All they need do is require that the piece on the other end be signed by Microsoft. Heck they could render http agent spoofing useless if they decide to make it so that only IE could connect to ISS. Again though, doing so would piss off a great many of their customers, some of who are slowly jumping ship to other solutions anyway. -- Mark Allen Earnest Lead Systems Programmer Emerging Technologies The Pennsylvania State University smime.p7s Description: S/MIME Cryptographic Signature
Re: Is 3DES Broken?
At 09:55 2005-02-03 -0500, John Kelsey wrote:
>From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
>Sent: Feb 2, 2005 1:39 PM
>To: bear <[EMAIL PROTECTED]>
>Cc: Aram Perez <[EMAIL PROTECTED]>, Cryptography
>Subject: Re: Is 3DES Broken?
...
>>I think you meant ECB mode?
>No, I meant CBC -- there's a birthday paradox attack to watch out for.
Yep. In fact, there's a birthday paradox problem for all the standard
chaining modes at around 2^{n/2}.
For CBC and CFB, this ends up leaking information about the XOR of a
couple plaintext blocks at a time; for OFB and counter mode, it ends up
making the keystream distinguishable from random. Also, most of the
security proofs for block cipher constructions (like the secure CBC-MAC
schemes) limit the number of blocks to some constant factor times 2^{n/2}.
I'm surprised that no-one has said that ECB mode is "unsafe at any speed".
Greg.
Greg RoseINTERNET: [EMAIL PROTECTED]
Qualcomm Incorporated VOICE: +1-858-651-5733 FAX: +1-858-651-5766
5775 Morehouse Drivehttp://people.qualcomm.com/ggr/
San Diego, CA 92121 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dell to Add Security Chip to PCs
In message <[EMAIL PROTECTED]>, Dan Kaminsky writes: > >>>Uh, you *really* have no idea how much the black hat community is >>>looking forward to TCPA. For example, Office is going to have core >>>components running inside a protected environment totally immune to >>>antivirus. >>> >>> >> >>How? TCPA is only a cryptographic device, and some BIOS code, nothing >>else. Does the coming of TCPA chips eliminate the bugs, buffer overflows, >>stack overflows, or any other way to execute arbitrary code? If yes, isn't >>that a wonderful thing? Obviously it doesn't (eliminate bugs and so on). >> >> >> >TCPA eliminates external checks and balances, such as antivirus. As the >user, I'm not trusted to audit operations within a TCPA-established >sandbox. Antivirus is essentially a user system auditing tool, and >TCPA-based systems have these big black boxes AV isn't allowed to analyze. > >Imagine a sandbox that parses input code signed to an API-derivable >public key. Imagine an exploit encrypted to that. Can AV decrypt the >payload and prevent execution? No, of course not. Only the TCPA >sandbox can. But since AV can't get inside of the TCPA sandbox, >whatever content is "protected" in there is quite conspicuously unprotected. > >It's a little like having a serial killer in San Quentin. You feel >really safe until you realize...uh, he's your cellmate. > >I don't know how clear I can say this, your threat model is broken, and >the bad guys can't stop laughing about it. > I have no idea whether or not the bad guys are laughing about it, but if they are, I agree with them -- I'm very afriad that this chip will make matters worse, not better. With one exception -- preventing the theft of very sensitive user-owned private keys -- I don't think that the TCPA chip is solving the right problems. *Maybe* it will solve the problems of a future operating system architecture; on today's systems, it doesn't help, and probably makes matters worse. TCPA is a way to raise the walls between programs executing in different protection spaces. So far, so good. Now -- tell me the last time you saw an OS flaw that directly exploited flaws in conventional memory protection or process isolation? They're *very* rare. The problems we see are code bugs and architectural failures. A buffer overflow in a Web browser still compromises the browser; if the now-evil browser is capable of writing files, registry entries, etc., the user's machine is still capable of being turned into a spam engine, etc. Sure, in some new OS there might be restrictions on what such an application can do, but you can implement those restrictions with today's hardware. Again, the problem is in the OS architecture, not in the limitations of its hardware isolation. I can certainly imagine an operating system that does a much better job of isolating processes. (In fact, I've worked on such things; if you're interested, see my papers on sub-operating systems and separate IP addresses per process group.) But I don't see that TCPA chips add much over today's memory management architectures. Furthermore, as Dan points out, it may make things worse -- the safety of the OS depends on the userland/kernel interface, which in turn is heavily dependent on the complexity of the privileged kernel modules. If you put too much complex code in your kernel -- and from the talks I've heard this is exactly what Microsoft is planning -- it's not going to help the situation at all. Indeed, as Dan points out, it may make matters worse. Microsoft's current secure coding initiative is a good idea, and from what I've seen they're doing a good job of it. In 5 years, I wouldn't be at all surprised if the rate of simple bugs -- the buffer overflows, format string errors, race conditions, etc. -- was much lower in Windows and Office than in competing open source products. (I would add that this gain has come at a *very* high monetary cost -- training, code reviews, etc., aren't cheap.) The remaining danger -- and it's a big one -- is the architecture flaws, where ease of use and functionality often lead to danger. Getting this right -- getting it easy to use *and* secure -- is the real challenge. Nor are competing products immune; the drive to make KDE and Gnome (and for that matter MacOS X) as easy to use (well, easier to use) than Windows is likely to lead to the same downward security sprial. I'm ranting, and this is going off-topic. My bottom line: does this chip solve real problems that aren't solvable with today's technology? Other than protecting keys -- and, of course, DRM -- I'm very far from convinced of it. "The fault, dear Brutus, is not in our stars but in ourselves." --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [E
Re: Dell to Add Security Chip to PCs
The best that can happen with TCPA is pretty good - it could stop a lot of viruses and malware, for one thing. No, it can't. That's the point; it's not like the code running inside the sandbox becomes magically exploitproof...it just becomes totally opaque to any external auditor. A black hat takes an exploit, encrypts it to the public key exported by the TCPA-compliant environment (think about a worm that encrypts itself to each cached public key) and sends the newly unauditable structure out. Sure, the worm can only manipulate data inside the sandbox, but when the whole *idea* is to put everything valuable inside these safe sandboxes, that's not exactly comforting. --Dan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dell to Add Security Chip to PCs
Erwann ABALEA wrote: > I've read your objections. Maybe I wasn't clear. What's wrong in installing a cryptographic device by default on PC motherboards? I work for a PKI 'vendor', and for me, software private keys is a nonsense. How will you convice "Mr Smith" (or Mme Michu) to buy an expensive CC EAL4+ evaluated token, install the drivers, and solve the inevitable conflicts that will occur, simply to store his private key? You first have to be good to convice him to justify the extra depense. If a standard secure hardware cryptographic device is installed by default on PCs, it's OK! You could obviously say that Mr Smith won't be able to move his certificates from machine A to machine B, but more than 98% of the time, Mr Smith doesn't need to do that. Installing a TCPA chip is not a bad idea. It is as 'trustable' as any other cryptographic device, internal or external. What is bad is accepting to buy a software that you won't be able to use if you decide to claim your ownership... Palladium is bad, TCPA is not bad. Don't confuse the two. the cost of EAL evaluation typically has already been amortized across large number of chips in the smartcard market. the manufactoring costs of such a chip is pretty proportional to the chip size ... and the thing that drives chip size tends to be the amount of eeprom memory. in tcpa track at intel developer's forum a couple years ago ... i gave a talk and claimed that i had designed and significantly cost reduced such a chip by throwing out all features that weren't absolutely necessary for security. I also mentioned that two years after i had finished such a design ... that tcpa was starting to converge to something similar. the head of tcpa in the audience quiped that i didn't have a committee of 200 helping me with the design. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Using TCPA
On Feb 4, 2005, at 6:58 AM, Eric Murray wrote: So a question for the TCPA proponents (or opponents): how would I do that using TCPA? check out enforcer.sourceforge.net We also had a paper at ACSAC 2004 with some of the apps we've built on it. Two things we've built that haven't made it yet to the sourceforge site: - an SELinux version - an OpenSSL engine --Sean Sean W. Smith [EMAIL PROTECTED] www.cs.dartmouth.edu/~sws/ Hanover, NH USA (Where the Appalachian Trail crosses the VT-NH border) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dell to Add Security Chip to PCs
Peter Gutmann wrote: Neither. Currently they've typically been smart-card cores glued to the MB and accessed via I2C/SMB. and chips that typically have had eal4+ or eal5+ evaluations. hot topic in 2000, 2001 ... at the intel developer's forums and rsa conferences - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
