PS3 Cell Processor Security Architecture

hoyhoy writes "IBM Developerworks is discussing the PS3 Cell Processor Security Architecture today on Developerworks. It details the hardware level security for isolating processes that exists in the Cell processor's architecture." From the article: "The architecture's main strength is its ability to allow an application to protect itself using the hardware security features instead of the conventional method of solely relying on the operating system or other supervisory software for protection. Therefore, if the operating system is compromised by an attack, the hardware security features can still protect the application and its valuable data. As an analogy, consider the protection the supervisory software provides as the castle's moat and the Cell BE security hardware features as the locked safe inside the castle."

Comments

Intel equivalent

[IamTheRealMike]

For comparison, the Intel equivalent to this technique (allowing processes to shield themselves even from the kernel) is called LaGrande Technology.

I'm not really a fan of this sort of design - it seems to duplicate the purpose of the existing kernel/userspace security architecture, but I can appreciate the pickle we're in with de-facto standard kernels that allow anything to be loaded into them. Windows Vista 64 bit requires all kernel drivers to be signed: correctly so, in my opinion, but this doesn't help the huge 32 bit userbase today.

Re:Intel equivalent

[flooey]

...but I can appreciate the pickle we're in with de-facto standard kernels that allow anything to be loaded into them.

I think it's more that the "pickle" is that the kernels are software, which is inherantly malleable. This type of security architecture isn't designed to protect the user from outside attackers, though it helps with that as a bonus. It's designed to protect the device from the legitimate user doing something the manufacturer doesn't intend (such as, for instance, decrypting movies or games and then saving them to a hard drive or running non-standard operating systems).

Re:Intel equivalent

[IamTheRealMike]

The fact that software is malleable is a two-sided coin: most people who end up with their machine modified in the ways this technique helps deal with are the victims of malware and viruses.

Regardless of what you believe it was designed for, the only things that actually matter are what it actually does. It's like saying that asymmetric crypto was designed so the military could hide secrets from civilians. Sure they use it for that, does that mean cryptography is bad? No.

Likewise, look at it from the perspective of the average gamer. This technology could easily be used to shield games from cheats with far greater effectiveness than now. You only have to play Counter Strike for half an hour to see how destructive cheaters can be - even if everybody is totally legit it won't be long until somebody is accusing somebody else of wallhacking. A game service that suffers trace levels of cheating would be enjoyed more by everybody, despite the software being less malleable as a result.

Uhh....whaaat?

[HaloZero]

Ok, so, I get it. The PS3 will have a processor that has an instruction set dedicated to protected the threads of a program from infiltration by something that has already compromised the operating system. The obvious advantage is the protection of the data stored in those threads at a time of either pre or post processing.

That sounds like a great technology. Truly. If used for the right purposes.

WHY are you implementing it on a GAME CONSOLE? (I'm also a little scared of the wording '...allow an application to protect itself... - we're writing sentience into these things, now, too? Might cause some ethical issues with first-person shooters..)

I'd love that sort of protection on a kiosk machine, something we'd send to a trade show, or even the laptops employed by our sales force. But the PS3? Nothing mission-critical is going to happen on the PS3. Nothing. Wait, wait.. I think I figured it out...

Digital Rights Management. Gotcha, gotcha. Thanks, Sony. It's nice to know that the PS3 will have an anti-modchip on it from the getgo.

Re:DRM

[IamTheRealMike]

Yes, it can make slightly more effective DRM because an application no longer needs to trust the operating system. But this isn't a black and white issue (realistically, outside of Slashdot groupthink, DRM is never black and white).

For instance, consider this:

• It can make more effective DRM, but it can also make more effective encryption. How do you know your operating system is secure, really? Root kits are not at all uncommon even on desktop machines these days. Have you seen how easy it is to dump form data from Safari before it's encrypted? It's not quite as easy for IE or Firefox because they're written in C++ rather than Objective-C, but it's still possible.

  Personally I wouldn't trust my CC number to an unknown Windows machine these days. SSL/TLS wire security just isn't secure anymore when it's so easy to intercept the data before it's ever encrypted.

• Afraid the government is spying on you? What was that NSAKEY symbol in the Windows crypto libraries anyway? It'd be a LOT harder to put Big Brother style tech into a CPU than an operating system simply because the CPU has much less information to work with. So crypto programs can shield themselves from possibly malicious software in another way.

• DRM exists, a lot of digital media is protected using it, and unless piracy suddenly becomes as unacceptable as murder or somebody invents a new kind of economic system to replace copyright it'll probably be around for a long time to come. Simply saying "we won't accept that" won't cut it with a lot of people, some geeks included (who do you think designs all this DRM anyway? magic programming pixies?).

  Consider - hardware process protection would theoretically allow for Linux-compatible DRM. Right now Windows Media DRM uses the "secure audio path" to try and prevent people using malicious audio drivers to trivially dump the decrypted audio out of the player. Linux has no equivalent, fundamentally cannot, however these kind of hardware features could allow it to get such a thing without breaking the GPL (because the operating system can be GPLd and therefore "untrusted" but the player would not have to trust it to work...)

• Anyway, like most technologies, it cuts both ways. It has uses you'll disagree with and others you will want. Just deal with it.

Concise summary

[DeadCatX2]

1) The Cell supports a Secure Processing Vault. This is basically hardware-based memory protection; since the OS is software, and software can be compromised, so can the OS. The hardware can't be compromised so easily, so you load up a SPE with some code and data, and then it engages its own memory protection, preventing anyone from reading/writing its memory until it's done, by which time it deletes the important information. So you can't peek at the decrypted results, because they're encrypted when they're loaded, and the decrypted results are deleted when it's done doing its work (which work gets re-encrypted before it leaves the SPE). There's a small communication channel left open, and it's the SPE's duty to protect it.

2) It also has a Runtime Secure Boot. This involves using a cryptographically signed BIOS. This verifies that the BIOS is trusted. From here, any time control is handed over to another program, it first must be cryptographically verified. This prevents unauthorized or compromised code from executing.

3) Once you've securely booted and your SPE is in isolation mode, protected from the eyes of other threads, you have access to The Root Key. The Root Key is stored in hardware, can't be accessed by software, and is used to decrypt other keys. These other keys are then used to do encryption in an individual SPE.

So, we make a key, stick it in some flip flops that you can't read, isolate an SPE to provide memory protection, and then authenticate each and every piece of code from the BIOS through to the currently executing thread. Everything going in is encrypted, isolated when the work is being done, and gets re-encrypted before leaving to the next module, all using encrypted keys. Pretty thick stuff.