Opinion: Cracking OS X for Intel doesn't say a lot at this stage; Apple may have the last word.
As was to be expected once the software got out of the lab, OS X for Intel has been hacked to make it run on generic Intel platforms, not just the Apple-approved Developer Transition Kit machines.
This is, at this stage, less of an event than it appears at first blush.
Getting around the TPM (Trusted Platform Module)
one of the requirements of enabling OS X to run on a generic platform basically just involves programming the system code to ignore any calls to the TPM.
While this will allow OS X to boot, disabling the TPM also disables its functionality.
The TPM at the motherboard level is just a chip that responds in a determined way to certain program calls. The DTK uses Infineon hardware (the obsolete SLD 9630 TT 1.1, which will most likely be replaced in production machines by the SLB 9635) to perform the functions.
TPM chips contain a random number generator, a small amount of scratchpad memory, and an implementation of both the RSA encryption and SHA1 hashing algorithms.
The random number generator is used to create key pairs, with the public key exported and the private key stored within the chip. Signatures are calculated by the TPM itself, so the private key is never revealed to anyone.
Apples switch to Intel raises peripheral issues. Click here to read more.
There are boot-time functions in the TPM that provide the ability to store in PCR (Platform Configuration Registers) the hashes of configuration information throughout the boot sequence.
Once booted, data (such as symmetric keys for encrypted files) can be saved in a PCR. The saved data can only be modified if the PCR has the same value as at the time of saving. So, if a virus has somehow modified the operating system, the PCR value will not match, and the change operation will fail.
TPMs are designed to repel external attack, not owner-instituted (local) attacks. The chips are not designed to be resistant to hardware attacks like power analysis, RF analysis or timing analysis. They are designed to protect a locally generated private key (as well as the manufacturer-supplied "endorsement key") by detecting a change in the environment around the chip. Thats it.
The TPM does not control program execution or block execution based on signature, revocation lists or any "approved" lists. While application software can perform all of the just-mentioned blockade functions, its not the TPM that does it; its the software.
And so, heres where disabling the TPM bites back. If you want to run OS X/Intel software in the future, running on a hacked operating system will (as I said before) lose the TPM functionality, and the original software will not run since it will check for TPM.
To get a functioning application, youll have to disassemble and crack the TPM calls. Every one of them. And that is a lot of work.
Read more here about whats involved in porting Mac OS X to Intel hardware.
Not that it cant be done by motivated individuals. Back in the Bad Old Days, lots of Mac software was "copy-protected" and cracked. The high-end software went to USB dongles and the like for authentication while most other software vendors just gave up. But its still a lot of work, and with the DMCA
you can now be tossed into the hoosegow for doing it.
I think Apple still has some techno-tricks up its sleeve about running its software on Intel hardware. Dont assume that just because people could crack things at this point that they will be able to do so when the real software comes out. I think it may well be that Apple put the first version of the OS out just to see what people would do with it, and thus know what to defend against. Thats what Id do, anyway.
Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog.