## August 3, 2005

### The Forces of Darkness

There’s a firestorm raging through the blogosphere.

It really is diagnostic of which part of the blogosphere you inhabit, whether you think the subject of the firestorm is

1. the President’s endorsement of Intelligent Design,
2. the Strings 2005 discussion panel’s vote on the Anthropic Principle,
3. or Apple’s incorporation of DRM into the MacOSX/Intel Kernel.

According to the folks from OSx86, who’ve been playing around with the Developer Preview Release,

• We’ve discovered that Rosetta uses TCPA/TPM DRM. Some parts of the GUI like ATSServer are still not native to x86 - meaning that Rosetta is required by the GUI, which in turn requires TPM. See the forum topic here.
• After much careful analysis of the files from the new Intel-based Macs, it would appear that SSE3 enabled processors are required to run the GUI. We are still testing this theory, though - nothing has been proven conclusively. Check out this forum thread for evidence and discussion.

Smart people, like Cory Doctorow, are up in arms, but I don’t really understand how this can succeed in the long run1.

The MacOSX Kernel is Open-Source. TPM support is provided by a kernel extension (called TPMACPI.kext, I gather). Doubtless, when the next version of MacOSX/Darwin is released, this particular kernel extension will not be Open-Source (unlike the ones which allow Darwin to boot on generic hardware. But who cares? The API provided by this kernel extension will be easy enough to figure out, even assuming that Apple does not save you the trouble by documenting it for use by 3rd party developers. And once you know the API, writing a dummy kernel extension to mimic it on generic x86 hardware will be easy. Oh wait … you mean people are already working on that?

Maybe I’ve missed some essential point2, but I wouldn’t be surprised if a drop-in dummy .kext, installable by end-users, is available by the time Apple starts shipping x86 Macs.

#### Update:

As is clear from the comments below, it’s probably not that hard, after all, for Apple to cripple the GUI on generic x86 hardware, regardless of whether the Kernel and the core OS continue to run. TPM does allow individual Applications, themselves, to authenticate the hardware. That’s all that’s required to prevent some crucial part of the GUI from running on unapproved hardware configurations. ☹

1 To be clear, Doctorow’s complaints are about the evils of TC generally. In that regard, he’s surely correct. I’m talking only about the ability to boot MacOSX on generic Intel hardware.

2 A DMCA lawsuit by Apple would be one possibility I’ve neglected.

Posted by distler at August 3, 2005 3:56 AM

TrackBack URL for this Entry:   http://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/622

### Re: The Forces of Darkness

I don’t know anything about the technical details but doesn’t DRM hardware come with secret keys on chip? In that case, any non open but essential software could check if the other side of the api knows about some private key. And that bit you cannot reverse engineer or fake.

Posted by: Robert on August 3, 2005 4:12 AM | Permalink | Reply to this

### Who checks?

Well, my crude understanding is that it’s this Kernel module that does the checking, rather than the User-level applications which query it.

The requisite decryption keys have to be held somewhere, and it’s “better” to hold them in one place (the Kernel module), than in multiple User-level applications. But the flip-side, clearly, is that an “attacker” just needs to replace the Kernel module to circumvent the DRM.

Posted by: Jacques Distler on August 3, 2005 4:30 AM | Permalink | PGP Sig | Reply to this

### Re: Who checks?

Oddly enough, I just translated an article about “trusted computing.” TPM uses public-key crypto implemented in hardware (in fact, I think it’s implemented through both the CPU and an external chip that stores a hardwired key). Software may be required to include a signature in order to run at all, or to run with certain privileges. The keys would not be in the kext, although I can imagine the kext implementing a separate layer of crypto to keep the hardware crypto at a remove.

I don’t know all the ins and outs, but it seemed pretty clear that there are smart people working on this, and they really don’t want you to break free.

### Re: Who checks?

Yeah, reading some more about this, it becomes clear that, if the authentication of the hardware is implemented in the Application (Rosetta) itself, rather than in the Kernel (through a .kext), then replacing the Kernel extension doesn’t help you.

If the goal was to totally disable MacOSX on generic x86 hardware, they’d want to authenticate the hardware in the Kernel. But, if the goal is just to cripple it, all they’d need to do is have one crucial piece of software at the Application-level authenticate the hardware, and refuse to run if the desired hardware configuration is not present.

Posted by: Jacques Distler on August 3, 2005 12:02 PM | Permalink | PGP Sig | Reply to this

### Basic question

As I am not too familiar with the MacOSX market, could someone explain something to me. What exactly is the TPM supposed to prevent? Is it supposed to prevent MacOSX from being installed on an generic Intel based machine or to prevent an alternative OS from being installed on a machine designed for MacOSX?

Posted by: Srijith on August 3, 2005 11:46 AM | Permalink | PGP Sig | Reply to this

### Re: Basic question

Is it supposed to prevent MacOSX from being installed on an generic Intel based machine or to prevent an alternative OS from being installed on a machine designed for MacOSX?

The former. More precisely, it’s supposed to prevent MacOSX from running on generic x86 hardware. Darwin, the core OS, which is open-source, runs and will continue to run on generic x86 hardware. But the GUI will presumably only run on Apple-branded PCs.

Posted by: Jacques Distler on August 3, 2005 12:07 PM | Permalink | PGP Sig | Reply to this

### Rambling…

Disclaimer: Thinking while I am typing…

The simplest way they could do this is to encrypt something secret (maybe the whole binary of Rosetta) with the public part of a non-migratable “storage key”. But then this decrypted secret will have to be shared with the application via non-secure memory. This allows anyone to dump the memory and analyse it to death.

Or, the application could use a challenge response method, asking the processor to decrypt a random value passed to it, encrypted with its public key and check if the response is correct. But then within the application binary, somewhere a comparison will have to be performed. A modification of the binary (crack as they call it) could subvert this process. Unless, it is not possible to edit the binary of Rosetta. This can be done by “sealing” a secret that Rosetta needs to operate using the hash connected to Rosetta binary as the PCR lock. But the question arises - how do you get this secret in the machine in the first instance? Does MacOSX ship with the OS already installed? If yes, this secret could be initialised when installing, when the system is still in “safe” hands. But what kind of secret will that be? It can’t be a static thing nor common to all Rosetta copies since if it is so, it can be observed on running the application on normal machine, dumped, analysed and then copied to ‘abnormal’ machines. But then that can be defeated by using TPM signing key, asking the TPM to sign the secret when it is decrypted and given to the application. To prevent replay attack, the secret will still not be static though.

Hm.. maybe they can pull it off and/or I am rambling :)

Posted by: Srijith on August 3, 2005 2:48 PM | Permalink | PGP Sig | Reply to this

### Re: The Forces of Darkness

BTW, all this might just be rumours.

Posted by: Srijith on August 4, 2005 1:43 AM | Permalink | PGP Sig | Reply to this

Post a New Comment