Thank will for you additions Will. Certainly TPM has not too much to do with DRM, but partially it can provide a 'tamper proof device' functionality to store keys like a smart card. So it can be a good starting point for any technology which needs some cryptographic protection from the beginning.
The conspiration theory I pictured maybe be a little far fetched, but many years ago there were big lobbies and work behind it. As we can see today, fortunately it didn't get implemented. Csaba ________________________________________ From: [email protected] [[email protected]] On Behalf Of Will Drewry [[email protected]] Sent: Monday, June 18, 2012 11:35 AM To: [email protected] Subject: Re: [nlug] UEFI On Mon, Jun 18, 2012 at 9:30 AM, Toth, Csaba <[email protected]> wrote: > And one of the goals of UEFI is to prevent the some malicious code to infect > the early booting process (or at least make it harder). > Although the MBR (Master Boot Record) and other boot sector viruses reminds > me the DOS era, but it's still not impossible to write one. Firmware viruses (and mbr viruses) are not /that/ uncommon. There was a recent one that's sole purpose was to inject spammy ads into a user's desktop! (What overkill :) I'll try to find the link. > On the other hand, I don't think that in real life it can prevent the a smart > virus. > Warning: *conspiration theory* > It will try to make the Palladium project to succeed. I don't know if that was palladium's intent or not, but I think that project is long gone. If you're actually interested in what has happened (rather than a project that didn't happen :) with content protection on Win+Intel, then check out, checkout PAVP and HDCP playback. > As you know DRM is technically impossible: the movie/audio players will > always have the cryptographic keys and algorithms in them how to decode a > video/audio stream. So one only has to reverse engineer them to pirate music. > That's why Microsoft tries to create a protected environment within Windows > (they originally wanted to release it with Vista), which someone cannot look > at. The DRM crypto keys would be kept there, so the video/audio pirates > wouldn't be able to reverse engineer. But the whole protected environment > could be circumvented if the whole thing is not controlled from the beginning > of the boot process. In theory, Intel's TXT could have been used to create a memory-curtaining hypervisor for doing this stuff after boot, but I don't think it got used that way. > The TPM chip (trusted platform module) is now present in every modern > motherboard, the last piece is the UEFI. Then the protected environment can > become true. The TPM doesn't really do much here. ARM platforms and other embedded systems have had their own "secure boot" without TPMs. Just look at ARM TrustZone and how it is used on mobile devices today. TPMs are good for data/code measurement, runtime access controlled NVRAM, limited forms of measurement state attestation, and key wrapping. While code measurement and binding key matter to the measured state (in a PCR) provide a means to implement secure boot paths, they are really a side issue. Chrome devices having been doing a secure boot (Verified Boot) without relying on the TPM for anything but storing versioning information in NVRAM to prevent a remote rollback attack against an image. They also all come with the ability to be run in "developer mode", relying on proof of physical presence, which allows the user to install software that is, or can be made, compatible with the firmware on the device (on the newest devices the coreboot+uboot code can be found here -- git.chromium.org). > (Note: > Protected environment won't prevent malwares from spreading or make you > computer more secure. It makes your computer more secure _from_you_ for RIAA > and MPAA. Same with "trusted platform module". It's not a chip you can trust, > but a chip what MPAA and RIAA can trust which can keep you away from some > parts of your own computer. > Well, MS didn't have the courage to get this thing out, MPAA and RIAA has the > pressure on them though I guess. Probably lots of people would give a finger > and migrate to Linux or other OS). FUD alert :) The TPM chip has very little to do with any sort of DRM scheme, At most, they can be used for VERY slow hardware-protected key storage (like protecting your disk encryption key!) and/or machine state attestation. At most, any attestation is of code on disk, not run-time execution, so it doesn't say much about the runtime machine state w.r.t vulnerabilities/exploits. >From a security perspective, a secure boot flow let's you know that the code being loaded in from backing store has been integrity checked. It's up to the OS maintainer (vendor, end user, whatever) to ensure that the code uses good run-time defensive strategies: regular updates, software fault isolation, minimized attack surface, etc. The combination yields a system that, during boot, is only exposed to anything that persists on the device and isn't authenticated. It's a pretty nice property to have in hardware. That said, I have not reviewed the UEFI secure boot work, so I don't know if they have achieved a robust secure boot implementation, much less be pairing with operating systems environments that provide the other pieces of the security puzzle. cheers, will > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of > Tilghman Lesher [[email protected]] > Sent: Sunday, June 17, 2012 12:22 PM > To: [email protected] > Subject: Re: [nlug] UEFI > > On Sun, Jun 17, 2012 at 9:51 AM, Chris McQuistion > <[email protected]> wrote: >> This trusted loader thing can be disabled in any UEFI BIOS, though (read >> that article for more information.) Anyone comfortable going into their >> BIOS won't have to "crack" anything. They can just turn it off. Those >> people not comfortable with going into their BIOS can use Red Hat's loader. > > Correction: it can be disabled on any computer that uses an x86_64 > processor. Considering how quickly devices are moving to ARM (where > it cannot be disabled), I suspect this is a moot point. You *have* to > go through their schema if you want Linux to work on the next > generation of devices. > > -Tilghman > > -- > You received this message because you are subscribed to the Google Groups > "NLUG" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nlug-talk?hl=en > > > -- > You received this message because you are subscribed to the Google Groups > "NLUG" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nlug-talk?hl=en -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en
