Intel Patches Flaws In Trusted Execution Tech

An anonymous reader writes "Joanna Rutkowska's company Invisible Things Lab has issued the results of their research into flaws in Intel's Trusted Execution Technology (TXT), whose function is to provide a mechanism for safe loading of system software and to protect sensitive files. ITL describes how flaws in TXT can be used to compromise the integrity of a software loaded via an Intel TXT-based loader in a generic way, fully circumventing any protection TXT is supposed to provide. The attack exploits an implementation error in the so-called SINIT Authenticated Code modules and that could potentially allow a malicious attacker to elevate their privileges. Intel has released a patch for the affected chipsets, which include the Q35, GM45, PM45 Express, Q45, and Q43 Express." Here are ITL's press release (PDF) and Intel's advisory.

Comments

First Word macro viruses, then PDF, and now...

[Anonymous Coward]

oh my gawd! Now I can't even use plain TXT documents!! oh wait... nevermind...

Re:First Word macro viruses, then PDF, and now...

[clarkkent09]

And why is Intel releasing patches to Infiniti car models?

Re:First Word macro viruses, then PDF, and now...

[Anonymous Coward]

And why is Intel releasing patches to Infiniti car models?

Because Microsoft won't.

Re:woot!

[davecrusoe]

now only if I could change it to say something more erudite...

TPMs and related tech

[girlintraining]

It was true fifty years ago, and it's still true today: If I have access to the hardware, you're screwed. And thus far, there have been precious few non-trivial applications that have been unexploitable remotely at some point. Systems are amazingly complex and full of flaws because almost all modern software was built with security as an after-thought. The only difference these days between a "secure" system and an insecure one is that the secure system hasn't had its flaws discovered yet.

Re:TPMs and related tech

[ameline]

> If I have access to the hardware, you're screwed

Or more precisely; If Joanna has access to the hardware they are screwed. :-)

Finding and exploiting these flaws is not a widely held skill. Unfortunately for the ones (futilely)* attempting to secure these things, all it takes is for *one* smart and enterprising person to crack it, and then the jig is up.

* And given that it is inevitable for the hardware to get into the hands of Joanna and other likewise bright and curious people, it *is* both a futile and sisyphean effort.

Re:TPMs and related tech

[pclminion]

It was true fifty years ago, and it's still true today: If I have access to the hardware, you're screwed.

Hardware safety is like thread safety. It originates at the lowest levels and percolates upward. In thread safety, the lowest levels are primitives like interlocked exchange. On top of this, we build spin-locks. On top of those we build critical sections. Etc. Hardware can be made secure by making it tamper-resistant. Cryptographic ICs can be rigged to self-destruct when somebody opens the package. Given a secure cryptographic chip, hardware security can be assembled on top of it. I'm not willing to go out on a limb and say that we have TRULY secure cryptographic chips, but if and when we do, we can built unconditionally secure hardware on top of them just like we build thread safety out of interlocked exchanges.

Re:TPMs and related tech

[clarkkent09]

Or more precisely; If Joanna has access to the hardware they are screwed. :-)

Hey, be nice, she's a lady.

Re:TPMs and related tech

[MichaelSmith]

It was true fifty years ago, and it's still true today: If I have access to the hardware, you're screwed.

But will that still be the case when computers consist of isolated atoms embedded in a diamond lattice? The equipment required for hacking will certainly be different.

Re:TPMs and related tech

[slimjim8094]

Exactly. It's the same problem as with DRM and audio/video - your software can kick ass, but all it takes is one person to break it and everybody has a copy.

Re:TPMs and related tech

[jamesh]

It's funny isn't it... It took 10 years for someone to read the boot rom of the Super Game Boy (and similar time for the Game Boy?), but the XBox was hacked in a similar fashion much faster.

I think if it takes 10 years for someone to break it then it could be deemed secure... the trouble with that is that it's only true retrospectively :)

Re:TPMs and related tech

[techno-vampire]

Systems are amazingly complex and full of flaws because almost all modern software was built with security as an after-thought.

Please note that Unix was designed from the ground up to be secure, and there've been exploits, root kits and vulnerabilities in it over the years. Not many, compared to some other systems, but enough to show that making a secure system and keeping it that way is a non-trivial exercise.

Re:TPMs and related tech

[Anonymous Coward]

Systems are amazingly complex and full of flaws because almost all modern software was built with security as an after-thought.

Please note that Unix was designed from the ground up to be secure,

No it wasn't - it was built to be open, used by mutually-trusting users.

You're thinking of Multics.

Re:TPMs and related tech

[BikeHelmet]

Cryptographic ICs can be rigged to self-destruct when somebody opens the package. Given a secure cryptographic chip, hardware security can be assembled on top of it. I'm not willing

Cost? :P

That might just be a factor in security being tacked on as an afterthought. Since people are incredibly shortsighted about everything, the cost here and now is what matters.

So if eating healthy might keep me alive 40 years longer... screw it, cheeseburger! I'll die happy at 65!

And if I have a chance to reduce pollution created at a power plant, so people have reduced medical costs and no environmental cleanup is needed later... screw it, money! $$$

And if face the possibility of getting a girl pregnant because I have no condom... screw it (her), sex!

Yeah, people are stupid shortsighted fools. =P It's in our nature. We're never going to have totally secure platforms. Just secure *enough*.

Re:TPMs and related tech

[pclminion]

Cost? :P

True -- at first glance there are serious challenges to building a hardware security primitive. But if a cheap device was ever created, it would be a very, very bad day. Control over all the hardware would be in the hands of the key-holders alone...

Re:TPMs and related tech

[Anonymous Coward]

And let's not forget - TXT was designed by Intel for DRM. It is Intel's implementation of Trusted Computing and is designed SPECIFICALLY for DRM purposes.

Remember: Modern security, at least as implemented by Microsoft and Intel, is not about security for you. It's about the designer's security and control.

Re:TPMs and related tech

[Anonymous Coward]

NT was designed from the ground up to be secure

Just Microsoft botched the implemementation of that

Re:TPMs and related tech

[peragrin]

The tools change yes, but you will still have inputs and outputs. as long as you have those hacks are still possible. just a lot smaller.

Re:TPMs and related tech

[Anonymous Coward]

No physical access is needed for this attack to work. RTFA.

Re:TPMs and related tech

[Rich0]

The only way I can see hardware security reaching true theoretical unbreakability is if we get to the level where the uncertainty principle prevents observing the hardware in action, but I'm not sure if it will be feasible to have the hardware even run reliably under those conditions.

You can certainly make the hardware hard to crack, but ultimately it is physical in nature and it can be taken apart physically. It is almost impossible to make it theoretically secure, although in practice you can do pretty well.

Re:TPMs and related tech

[dpilot]

The issue isn't to build perfectly secure hardware/software, it's to build *sufficiently* secure hardware/software. There really are self-destructing crypto-chips, but those are usually installed in critical hardware where the data involved is sufficiently concentrated and/or valuable that it's worth spending the extra money to protect.

Let's take a simple testcase... Assume that you want to use crypto-stuff to theft-proof your laptop by turning it into a brick for anyone who doesn't have the secret password/token. In bygone days, that might have been the BIOS password, but it's really simple to remove the battery, etc. That's a simple, cheap way to work around the protection. Many systems have a hard drive password, so let's pretend that it's secure. So the "cost" to steal one of those is a new 2.5" hard drive. Now as the protection becomes more sophisticated, presumably the cost to work around it rises as well. At some point, you're better off buying a new laptop, instead of breaking the protection on a stolen one.

Similarly with the value of the data. Most of my data is only valuable to me, not to anyone else. So for the most part, it's not worth much to someone else to crack my data protection. It's worth investing some money/resource to protect my data, but why would anyone bother working really hard to get at it? On the other hand, the previously mentioned mainframe may well have hundreds of thousands of credit card or account numbers, or it may have account numbers for lines of credit worh millions of dollars, etc. It's worth much more to crack the mainframe than it is my piddly system.

So while we may talk about how anything can be broken with physical access, most of the time, especially for Slashdotter's systems, it's just not worth the effort. What we can get off the shelf, TPM or TXT, etc, is probably good enough, probably even overkill.

Re:TPMs and related tech

[Proteus Child]

Hardware can be made secure by making it tamper-resistant. Cryptographic ICs can be rigged to self-destruct when somebody opens the package.

Sometimes you don't even need to expose the silicon to mess with the guts of a chip. You can still connect to the pins or solder pads of an IC and monitor signals passively, or introduce overvoltage/undervoltage/weird signal patterns from outside.

Re:TPMs and related tech

[pclminion]

So while we may talk about how anything can be broken with physical access, most of the time, especially for Slashdotter's systems, it's just not worth the effort. What we can get off the shelf, TPM or TXT, etc, is probably good enough, probably even overkill.

What you're missing is the other application of truly secure hardware -- absolutely, totally, brutally locked down DRM mechanisms. To massive IP companies, it's probably worth it to pour a few hundred million into figuring out how to cheaply build a truly hardware-secure platform. Once they have that, only the analog hole remains. Eventually, when people stop manufacturing analog devices, even that will disappear, and the only people who will have control over media will be the rights-holders and the few hobbyist who are capable of building their own analog devices.

Re:TPMs and related tech

[dpilot]

Hopefully it'll never come to that. Don't forget, every DRM doodad added to software and hardware hurts their respective makers. Part of the giant black eye that Microsoft took over Vista was because of the reliability implications of all of that "trusted path" and "degradation" garbage. Stuff that doesn't do spit to increase the value of the hardware or software to the customer, and it boosts the costs to the developer/manufacturer without any extra revenue, it just placates the MafiAA. So at this point we're pitting entertainment mega-corporations against hardware and software mega-corporations. At one point it's just possible that they could have gotten away with this, but by now enough people have been downloading and streaming without onerous DRM, and enough high-profile prosecutions have taken place, that there will be a general realization that encroaching DRM is just a power grab, not an "enabling factor."

Maybe they're sheeple, but take away their YouTube and enough of them can trample you.

Re:TPMs and related tech

[Simetrical]

The only way I can see hardware security reaching true theoretical unbreakability is if we get to the level where the uncertainty principle prevents observing the hardware in action, but I'm not sure if it will be feasible to have the hardware even run reliably under those conditions.

Well, this idea is pretty much the basis for quantum cryptography: if anyone observes the transmission, it gets corrupted. So it's evidently possible for some things.

Re:TPMs and related tech

[Rich0]

Absolutely, and I had this in mind. However, right now quantum cryptography only protects the transmission, not the end-nodes. You'd need a computer where every byte of data in transit, in processing, or in memory associated with the authentication mechanism is protected all the time.

Even that won't really protect you completely since you can do a MITM at any time. The processing circuitry presumably needs to read the data to do work on it. So, you can remove the existing circuitry and replace it with circuitry that copies the data as it works on it. To defeat that the circuitry needs to be able to operate on the data without being able to read it - for some operations this is probably possible, but I doubt you'll be able to pull it off. You'd need a ton of error correction code to handle the loss rate when individual components can't retransmit on error and you're transmitting and operating on single particles or photons.

Chipset patch?

[Christopher_Wood]

Do I have to weld it on or something?

Re:Chipset patch?

[DigiShaman]

Yes. Below is a video tutorial on how to do it.

http://www.youtube.com/watch?v=wJpukz5sn_U

Fix?

[Anonymous Coward]

Oh, this is great, text files now. *sigh* So what can be done to fix this vulnerability. To be honest I have no idea what my chipset is. Am I screwing myself if I apply the supplied patch to unsupported hardware or...?

Re:Fix?

[JackieBrown]

No. You'll be fine and should go for it :)

You can always press undo later...

Re:Fix?

[Anonymous Coward]

Ah! You bricked my computer! Undo didn't work!!!

Re:WTF are you doing?

[girlintraining]

By the way, I don't live under the fridge, you insensitive dyke! X_X

True dat. I am insensitive when it comes to the special needs population of slashdot...

Readme.TXT

[marciot]

User: Oh, look, someone sent me a text file
User: *double-click*
Computer: Launching trusted executable...
Trojan: Got ya, sucker.

Seriously Intel, TXT? What were you thinking?

Re:Readme.TXT

[mirix]

Yeah really. Some dude in his Intel office:
"Hey Jim, you know what computing needs? more ambiguous acronyms. That would be just grand."

Re:Readme.TXT

[Darkness404]

Exactly. And people wonder how viruses spread so fast... Really, OSes need to check the file type and then auto-assign a unique file extension for file browsers, at least on those easily exploitable (Windows and perhaps OS X). So even though the file may be called song.mp3 , but the actual file type is an .exe, it would be called song.exe in the file browser. Things with multiple extensions would also be changed in the browser for example song.mp3.txt that is really a .exe file would be called songmp3.exe in the browser. Now, the same file would be referenced as song.mp3.txt everywhere else as to not break compatibility with other programs, but in the file browser it would be called songmp3.exe. This could help reduce the amount of trojans and other files that are like cute_cat.jpg.exe that people -still- click on thinking its just a picture.

Re:Readme.TXT

[Anonymous Coward]

What about not executing what isent set +x.. and save by default new file as -x.
Oh that right, it already the case except on flawed OS.

Re:Readme.TXT

[Darkness404]

Well, we can't expect Windows to ever implement anything better than half-baked security now can we? ;)

Re:Readme.TXT

[spathi-wa]

I don't agree that this will solve anything. People who are likely to double click on cute_cat.jpg.exe are just as likely to not know the difference between song.mp3.exe and songmp3.exe.

"it says mp3 right there in the file name"

Re:Readme.TXT

[Tycho]

The classic MacOS had a feature similar to this, but it was abandoned by MacOS X. One type of metadata present for each file in the classic MacOS had a four character creator code and another four character file type code. The FourCC codes used currently in audio and video files were originally derived from this system. At any rate, unless the file type was "APPL" or "CNTL" it wasn't going to execute from the Finder unless the file type code was changed, a nontrivial, but not an impossible task for a user aiming to do something stupid. "APPL" and "CNTL" were obviously not file types assigned to files by any web browser by default unless the browser decoded the .hqx or .bin file automatically and determined the resultant file was an application. Executables in the Classic MacOS needed to be encoded specially due to the unusual structure of executable files. Files had two forks, a resource fork and data fork and each fork had critical parts that were needed for an executable to run as well as being separate, distinct structures in the filesystem. A file downloaded from the internet would be stored entirely as a data file with all of the data in the data fork and without any data in the resource fork and thus impossible to execute on its own without some sort of rearrangement by another application. Granted the file could still have a trojan, and while a file freshly downloaded off the internet with a .mp3 extension could be double clicked the file would be opened by iTunes. Assuming or course that the filetype codes were set by the browser automatically after detecting the file extension, but iTunes would puke on the file after realizing it was not mp3 audio. An enterprising idiot could still decode the same trojan into an application with StuffIt even if the file contained a .mp3 extension to the file name and run it, but you really would have to work hard to be that stupid.

Currently however, one operation that might be useful that could be performed by a browser or a real-time scanner would be to check the contents and structure of the file to make sure it at least appears to match the a file of the same extension that matters to the OS and throw up a warning if the file is bad. Finding and alerting the user when the string "This program cannot be run in DOS mode" in a file in Windows or when the signature of an ELF or Mach-O binary appears unexpectedly in a file, might help. The problem I see is that while there are some techniques that could be implemented from the classic MacOS to improve the security of downloaded files, the changes would require reworking of the ABI (Application Binary Interface) among many other changes to both Windows and Linux to be workable. The compatibility issues that would crop up due to any major changes would be no fun either.

Re:Readme.TXT

[zaft]

Duh, people at Intel don't have offices, you clod.

Re:Readme.TXT

[Anonymous Coward]

The proliferation of this thing you call 'file extensions' is itself part of the problem.

MIME-Types could be part of the answer (notable MSIE ignores MIME-Types in favor of the magic three letters at the end)

For an thorough explanation as to why the entire concept of file extensions was and still is a absolutely horrid, see the link below.

It was written in 2001, but is still fully applicable. It is a bit long, so save the URL when you have some time to read.

http://arstechnica.com/apple/reviews/2001/08/metadata.ars

Re:Readme.TXT

[Antique Geekmeister]

And oh, dear me, that resource/fork mess was unstable. They inevitably fell out of sync during hardware issues or during software problems, and completely ruined MacOS filesystems and components. Re-implementing that mess would be like bringing back punch cards. Sure, they have some advantages in stability, but the mostly useless overhead of handling them is unacceptable.

Re:Readme.TXT

[Anonymous Coward]

Windows does support file permissions, in fact, it has more permissions then UNIX (Read/Write/Execute/Browse-Folder/Create-File/Append-File/Delete-File/Delete-Folder/etc). Unfortunately, the tools suck more.

Setting/Disabling the X flag in *nix is pretty straightforward programmatically. On Windows, even the UI requires wading through 5 GUI panels just to get the complete permission list for changing them as a user.

VB Program for Windows
Equivalent C Function for *nix (ok, you could just use umask instead before writing the file as well)

Re:Readme.TXT

[Anonymous Coward]

Except that is one of the number one reasons - no kidding - some friends of mine never took up on linux and/or find it boring.

You can't send them executables/scripts/etc. which are easy to use.

You didn't solve a problem, just moved it from the realm of security to the realm of usability.

Re:Readme.TXT

[Tycho]

Actually, the most common problem with standard HFS drives had nothing to do with file forks. There was no backup of the structures necessary for the integrity of the filesystem in standard HFS. With the not at all uncommon hard lock ups and reboots in MacOS 7.5* to 8.1 one structure is bound to get corrupted, especially if the caching policy for the write cache on the hard drive is set to write-back.

At any rate, the type of problems present in standard HFS are no longer a factor, backup superblocks and backup records are written to the filesystem on recent computers. Filesystem corruption is even less of a problem with journaled filesystems also now in use. The version of HFS+ filesystem used in MacOS X is far more reliable than a standard HFS filesystem on the classic MacOS.

* System 7.1.2 never happened, it was a bad dream, just like 7.5.2 and 7.5.3 Revision 2. Then again, System 7.5.4 was pulled within minutes of release upon discovery of a nasty filesystem corruption bug.

Re:WTF are you doing?

[Darkness404]

And once again... an XKCD reference comes in handy. http://xkcd.com/322/

None of the above

[hwyhobo]

What, you mean a woman is actually doing something useful involving computers? She must be fat, old, ugly, or all three.

None of the above: http://invisiblethings.org/about.html - she is young and rather attractive.

Re:None of the above

[CxDoo]

She is young and rather attractive, however there are some questions raised.

Re:None of the above

[Trinn]

Err...why does any of that matter? I fail to see the issue here, she's a very smart and quite attractive woman.

Re:None of the above

[CxDoo]

It doesn't matter.
I found it interesting the first time I stumbled upon it, so I reposted it here, is all.

The best execution tech is lethal injection

[Anonymous Coward]

Of all the execution technologies lethal injection has proven to be the most reliable. If Microsoft designed an execution technology, it would be the electric chair. If the product doesn't kill you outright, it will leave your hair on end and badly burned.

So all in all

[Errol backfiring]

The technology is even less trusted than it already was by end users.

Not Trusting The User

[Anonymous Coward]

TXT is not about trusting you the user, its about not trusting you. You cannot be trusted not to copy that DVD or BluRay, so Intel and the media companies are arranging to take over your computer. With TXT installed you will not be allowed to do certain operations, and there will be no way around it even with administrator privileges. TXT is about taking away control of your computer and giving it to the big corporations. Only signed software can be installed, so there will be no way around the DRM. The trusted path from media to screen will be enforced by the hardware, and it will refuse to run if anything has been tampered with.

There is no reason why a user would ever want to have TXT installed on their machine, that cannot already be done with public key based security. The primary difference between traditional public key certificates and TXT, is that in TXT you are not trusted to have access to your own private certificate.

Re:Not Trusting The User

[Nursie]

I had been wondering about that. It seemed to me that it describes a system in which you don't have control of your system and couldn't poke around in the process to find out what it was doing.

I'll stick with the broken version, thanks.

Re:Not Trusting The User

[eallanjr]

TXT doesn't HAVE to be about DRM and selling your computer's soul to the big corporations. TrouSerS is a FOSS implementation of the trusted software stack. There are legitimate uses for trusted computing aside from DRM enforcement.

But I agree that there is probably is very little need for a typical user to be running TXT on their machine; I definitely don't trust MS/MPAA/etc not to abuse the technology

Re:Not Trusting The User

[Anonymous Coward]

All those things you are talking about can be done with traditional public-key systems. Remember the difference with TXT is that your key is sealed away inside the TPM module, and you can not get access to it. Destroy the TPM module and all your keys are lost.

You are not trusted to manage your own private key. There is no reason for this apart from the obvious and explicit - you are not trusted.

Re:Not Trusting The User

[dpilot]

Let's leave the MafiAA out of this for a moment. Sometimes it seems to me that most users really can't be trusted with their computers.

Click this link!!!
Open thie attachment!!!

The littany goes on and on, and no matter how many times they're warned, they still click that link and open that attachment.

For that matter, none of us fully trusts ourselves, in all circumstances. After all, we all say, "Never do normal operations as root, only use root as necessary." That's been considered the first line of security on Unix/Linux, and the first flaw pointed out in the normal operating model of Windows. Look at separation of root priviledge as a way of minimizing those times doubleplusgood diligence is required. Of course we should always be diligent, but there are more sensitive times.

TXT/TPM can be a tool for the owner to protect us from the unknown. We all fear (rightfully, I fear) that TXT/TPM will really be a tool for corporations who clearly distrust their customers.

Re:Not Trusting The User

[IamTheRealMike]

You're talking garbage and have no idea what TXT is or how it works.

Re:Not Trusting The User

[Anonymous Coward]

But you dont need to take control of the root certificate away to do that...

Re:Not Trusting The User

[thePowerOfGrayskull]

The problem is that it's not a fundamentally bad idea. Just like you want people to be able to verify the places they're connecting to in a reliable fashion, ensuring that only trusted software can run is on the surface a very good idea -- for example this behavior on the blackberry platform is (IMO) a good part of the reason why you don't hear of much malware for Blackberry. Without access to the Blackberry-specific components, you're very limited in the damage you can do. And without a signed key from RIM, you can't get access to those components as a developer.

The problem is in the ways in which it will be abused, chief among them being as you described.

Re:Not Trusting The User

[Anonymous Coward]

Care to point out exactly where you think the description above is wrong, because it sounds to me like you have no idea what TXT is or how it works.

Re:Not Trusting The User

[dpilot]

I missed that line. Is it true that TXT doesn't let you control your own root cert?

I have a Thinkpad. I keep the TPM stuff in my kernel config, and I've built Trousers. Actually doing something with it has been on my ToDo list for years now. Nor have I tried Trusted Grub.

Re:Not Trusting The User

[dpilot]

My impression is that with TPM and TrouSerS, *I* can put the master key into the TPM, assuming nobody else has gotten there, first.

Come to think of it, you've just described a new LiveCD. This would be a LiveCD that should be the very first thing you boot in your new PC, especially before you boot the supplied (probably Windows) OS. Boot the LiveCD, plug in a USB flash memory, and it will set up the TPM/TXT for you, putting the necessary root cert stuff on the flash memory for your later use.

Given the nature of manufacturing, I would expect standard TPM/TXT setup to be a first-boot type of operation, probably with some sort of activation tie-in. The real question comes when first-boot finds a non-virgin TPM/TXT. Would it refuse to activate, or would it activate and refuse to enable MafiAA extensions, etc?

Re:Not Trusting The User

[Anonymous Coward]

See: http://www.h-online.com/open/features/Linux-and-the-Trusted-Platform-Module-TPM-746611.html

The main objection of the open source community to TPM chips is that they are capable of generating public/private key pairs where the private key is contained within the TPM and is not even known to the computer owner. It is also possible, during manufacture, to inject private keys into a TPM that will be known to a third party, i.e. a computer manufacturer or major copyright holder, but again, not known to the computer owner. Potentially this leads to manufacturers and content providers being able to limit what the computer owner can and can't do with their PC. The Free Software Foundation refers to this kind of restriction of the computer owner and user's rights as "Tivoisation".

The most recent GNU General Public License (GPLv3) specifically states that GPLv3 licensed software is forbidden from running on platforms which require a private signing key, unless the key is freely available to the computer owner; this specifically excludes hardware that uses a TPM. This has been suggested as one of the reasons why, at present, the Linux kernel is sticking with GPLv2.

Re:Not Trusting The User

[PingPongBoy]

Only signed software can be installed, so there will be no way around the DRM.

Can the computer industry really go along with this? There are bajillions of software packages that have never been signed.

Re:Not Trusting The User

[dpilot]

The wording is "are capable of", and it emphasizes the importance to me of siezing control of your own TPM. Elsewhere on this thread I suggested the creation of a LiveCD that would (first!) access the TPM, giving the owner the private key on a USB flash device. It would be of utmost importance to boot this disk FIRST, before ever booting the preinstalled OS.

I seriously doubt that manufacturing cost constraints would permit injecting private keys - I would expect such injection to take place upon first boot, probably bundled in with the activation process. On that line, I don't know what would happen if Windows first boot found a non-virgin TPM. Would it fail to activate, would it activate but fail to enable MafiAA extensions, or would it just bluescreen?

Re:Not Trusting The User

[makomk]

Nope. All TPMs are shipped with a key already in them, though you can load your own key in addition to the shipped one.

Re:Not Trusting The User

[Anonymous Coward]

This is because if they didn't, then the system would not boot after the new motherboard was installed, when coupled with a TPM compliant CPU (Some Xeon PIIIs, P4 Northwood and -all- later Intel CPUs). OEMs conveniently (most of them anyhow), take care of this issue for you at the factory, and then disable TPM in BIOS after the first test boot. Lenovo does this with their IdeaCentre line of machines, certainly.

My system is TPM-enabled (IdeaCentre K230), but it came shipped with TPM disabled in the BIOS. I do have CPU-DEP enabled though.

What is going to be a bitch, is when they no longer include the option to disable TPM via BIOS or ELF. They haven't been able to yet, because not enough software supports it, and there are too many hardware bugs still being found, as per the article. Once they iron out the hardware bugs, the software will soon follow, because programmers will have no choice if they want their stuff to run on new hardware.

Basically Joanna just gave them free bug testing, so they can perfect something that is detrimental to the general public. She should have kept this type of information quiet.

Re:Not Trusting The User

[dpilot]

Where does that key come from? Is it unique for every TPM, like a network card MAC?

Never mind, a few moments with google... It looks like the "Endorsement key" is chip-unique, in 2 parts, and you can only get the public part, and ask the TPM to sign/encrypt with the private part. It's not at all clear to me that ANYONE knows the private part. In particular, if the TPM has its key manufactured in, it would be a royal pain in the neck to manage the data, correlating private and public keys. (Where "royal" means "expensive", in this case.) As far as I can tell, the private key is used only to sign or encrypt other stuff, so the public key can verify that that particular chip was used.

Again, the key action here becomes "tpm takeownership" or its Windows/OSX equivalent.

I still maintain that a LiveCD with support to do a "tpm takownership" would be a great thing to have, and to use prior to booting ANYTHING else on a new PC. Once I've done a takeownership, nobody else can unless I do a "tpm transferownership".

I don't think that the built-in key is sinister. It looks to me as if the worst that could happen if someone got it is that they could snoop something you've used the TPM to encrypt. Presumably they could grab YOUR private key and do a "tpm transferownership" to themselves. Certainly bad, but hardly unobtrusive. In a way similar to removing the battery to reset the BIOS password - tamper-evident.

Hmmmm, now that I think about it, they could tranferownership to themselves, do nefarious things, then transferownership back to you. I guess then I'd fall back to the "what's so valuable about this laptop to go to all of that effort?" argument.

Re:Not Trusting The User

[makomk]

It looks like the "Endorsement key" is chip-unique, in 2 parts, and you can only get the public part, and ask the TPM to sign/encrypt with the private part. It's not at all clear to me that ANYONE knows the private part.

Nope, no-one should know the private part; in fact, according to some information, it's generated on-chip and never leaves the TPM. The whole point is that the endorsement key can be used to verify that the TPM is in fact a genuine one, and not a piece of software emulating a TPM. In turn, the TPM can then verify that your computer is running an authorized operating system (remote attestation).

This is a less-than-ideal approach if you - as an end-user - just want to verify a particular TPM you control signed something. Having the TPM generate the key on first use would be much better, both from a security and a privacy perspective.

BIOS Updates?

[CloneRanger]

/me wonders when we can expect updated BIOS from Asus and others?

Re:BIOS Updates?

[PincushionMan]

Easy, Ship it back to your vendor or reseller. You'll get your system back in a couple of weeks. What? Too long? You have two choices then, 1) Buy a temporary desktop or a laptop (yay free market at work! [/sarcasm]), or 2) buy new BIOS chip to plug in, from your vendor (of course). The chip will have an updated TPM/TXT signature on it. I'm sure that's what Hollywood would want you to do. Don't expect the chip to be cheap or anything though. On second thought, scratch that. Hard drive manufacturers don't let you update the firmware, you have to send the whole drive in (just try to find a firmware update on Seagate's site), and there's no guarantee that you'll get the same drive back. Perhaps they'll start leasing instead of selling computers, then?

It's a security issue

[Anonymous Coward]

You don't know who Joanna Rutkovska is, nor do many others who discuss their security problems with her on a day to day basis.

She is smart and much of what she says about the technicalities has to be taken on faith by many of those who pay attention to what she says.

Does it matter what gender or sexual orientation she has? In my opinion no.

But it does matter who she is and where she has come from. Her past - and anyone else's in the security industry - needs to be verifiable, and Joanna's isn't. It's as though she emerged into the world fully formed and knowledgeable just a few short years ago.

Ignore the bigots, but don't get hung up on accusations of sexism or prejudice. Wanting to know where a person has come from is a perfectly reasonable aspiration and the emotional issues of gender and sexuality are ideal tools to suppress questions.

Hasn't anything you read about social engineering these past ten years penetrated your thick skull? :-)

Re:It's a security issue

[Proteus Child]

...and how many people in the security community started out in the hacker community and took great pains to conceal their real names back then? More to the point, how many people in the security community go to great lengths to dissociate their all-grown-up-now professional lives from their days in the hacker scene because it would call unfavorable attention upon their employers, plus put certain of their expensive certifications in jeopardy?

Some people spend years hacking around in their basements and don't feel a need to tell anyone about their work. Others "suddenly appear" because they finally feel like publishing something, the work they publish is brilliant, and thus they gain respect for it.

so how will asimov's laws be implemented?

[airdrummer]

won't the 3 laws of robotics require impregnable systems? even, especially, to users?

Intel Patches Flaws In Trusted Execution Tech

[Anonymous Coward]

Good, I trust it doesn't work at all now. Send the code to Texas.

Upgrade...

[ghostis]

Sounds like Intel needs to move to the Systematic Hardware Integrated Trust standard...

It's Funny Until ...

[not_hylas( )]

It's Funny Until ...

Subversionhack:

http://subversionhack.livejournal.com/

https://tagmeme.com/subhack/a/index.html

http://slashdot.org/comments.pl?sid=1135787&cid=26950187