Cell's security architecture: IBM's prize and Sony's Achilles heel

[cliffbo]

IBM has released the most detailed document to date describing the security architecture of the Cell Broadband Engine that powers Sony's forthcoming Playstation 3. The design is impressive because it represents the first mass-market processor architecture designed from the ground up with security as a major consideration. Cell is not invulnerable to attack, however, and its greatest strength may yet turn out to be the PS3's Achilles heel as a secure content delivery vehicle.

In a nutshell, Cell's designers decided to anchor application software security substantially and directly in hardware. Normally, applications rely on another piece of software—the operating system, or some kind of virtual machine hypervisor—to ensure their integrity by shielding them from attacks by other malicious applications. Of course, the fundamental problem with using software to protect software is that the protecting layer can itself be compromised. An attacker can take control of the OS and/or hypervisor, and have his way with the system and all of the code and data in memory and storage.

Cell aims to prevent attacks by having the hardware itself protect each individual application from other applications, and even from the OS. Any of Cell's eight synergistic processing elements (SPEs) can be booted, on-the-fly, in secure mode, so that the code and data stored in each SPE's local store is walled off from the rest of the system. This partitioning is enforced in various ways by Cell's hardware, with the end result being that the integrity of the code running on a secure SPE can be verified by the SPE; i.e. the SPE can check a thread at load-time and periodically during runtime to see if its code has been modified either in memory or in storage. Verified code can then be trusted to handle sensitive data, like digital media content.

Cell uses three primary security mechanisms and one auxiliary one to ensure code and data integrity at the hardware level. Here's a very brief rundown of these mechanisms; for more information check the paper linked above:

Secure processing vault (SPV): An SPV is essentially an SPE running in secure mode. When in secure mode, the SPE's local store cannot be read from or written to by any other agent on the Cell's internal element interconnect bus (EIB). Only the SPE to which the local store is attached can access it. This means that encrypted data can be moved from main memory or storage into the secure local store, where the SPE can safely decrypt it out of sight of the rest of the system.
Runtime secure boot: It does no good to create an SPV and move encrypted data into it if the code that's running on the secured SPE has been tampered with. Cell's runtime secure boot feature allows the SPE hardware to check periodically to ensure that the application it's running hasn't been modified. IBM is vague on exactly how this works, other than stating that it involves a hardware key and a cryptographic algorithm.
Hardware root of secrecy: This feature is the heart of Cell's approach to software security. Cell stores a root key in hardware, and when an SPE boots in secure mode it must access that key in order to unseal the set of keys that it will use to decrypt the code and data that will go into its LS. Only an SPE running in secure mode with code that has been verified via runtime secure boot may ever access the root key.
Hardware random number generator (RNG): Cell's hardware RNG can be used for a variety of cryptographic functions, and it will work in conjunction with the three previously described features. The paper suggests that it will be mainly used to timestamp messages so that replay attacks can be prevented.
The PS3's Achilles heel
A thorough and accurate evaluation of Cell's security mechanisms would be out of my league, even if it were possible given the information provided in the new paper (which it isn't). Nonetheless, I can draw a few significant conclusions from the general and somewhat spotty description provided by IBM.

First, IBM starts out the paper with an acknowledgment that Cell's security architecture is designed to thwart only software-based attacks. It's a truism in the infosec world that once an attacker has on-site, physical access to the hardware it's game over, so Cell sensibly doesn't even try to tackle that one. This being the case, I have one, hyphenated word for Sony headquarters: "mod-chip."

Because of Cell's high level of integration, where the bulk of the security architecture is on a single die, I'm not sure at the moment how mod-chipping will work on the PS3. However, it's a near certainty that someone will figure out how to compromise the box with a hardware modification of some sort. When a successful hardware-based attack is formulated, then Sony and IBM can't just release a patch that fixes the problem, and therein lies the weakness of hardware-based security.

The PS3's security architecture is a fixed quantity (= sitting duck), from the general layout and functioning of its various components all the way down to the hardware-stored root key. That single master root key, and the fixed, non-patchable nature of a hardware-based security scheme, means that thousands of very smart, warranty-voiding attackers will have all the time in the world to divine the PS3's innermost secrets. And when just one of those folks has an "aha!" moment and hits on the perfect attack, a forum post somewhere will clue in the rest of the planet. That attack will then work every time, on every PS3, and no OS upgrade or patch will solve the problem.

At that point, it's going to be up to law enforcement to check the spread of the damaging information and to prevent the sale of hardware designed to compromise the PS3.

Conclusions
While Cell BE may turn out to be a great product for corporate uses where security is paramount and physical access to the hardware can be restricted, it's just not going to save Sony's digital bacon. This isn't just because of the aforementioned problems inherent in a hardware-based security scheme where the box's owner is also a potential attacker, but because no amount of security will provide the kind of ultimate protection from so-called "piracy" that Sony wants.

If the PS3 were the only vehicle in the world for consuming Sony's and the *AA's digital content, then a perfectly secure, hacker-proof console design would ensure that none of that content leaks out onto the Internet in unsecured form. We all know, however, that this isn't the case. Sony will never see enough market penetration with the PS3 to profitably release PS3-only nongaming content. The company, like other content providers, will always have to deal with a multi-format, multi-platform world.

Thus the same songs, images, and movies that we'll see on the PS3 will also be made available on a wide variety of platforms with varying levels of security. All it takes is for one of those content delivery mechanisms to be compromised by someone with access to an Internet connection, and the cat is out of the bag. So in spite of Sony's best efforts with Blu-Ray and the PS3, consumers will always have the option of getting the same content for free off the Internet if Sony tries to price PS3 content too high or if they impose draconian usage restrictions.



http://arstechnica.com/news.ars/post/20060427-6694.html

[venomv]

So the PS3 isn't hack-proof? There is no such thing anyway, give hackers time and they can crack anything.

[xbdestroya]

Wasn't the actual IBM document referenced here by Ars posted by Cpi a couple of days ago in another thread? I believe it was, though I forget which thread.

Anyway Hannibal is way too dismissive of PS3's security considerations. Even if eventually the console does get cracked, it's going to be a rough rough slog for the people trying to do it.

EDIT: here (http://forums.e-mpire.com/showpost.php?p=1069999&postcount=76)

[Garfunkel]

it is better than nothing

[casualkiss]

Wasn't the reason PS3 became region free is to deny the only legitimate excuse someone could have to mod a PS3 (import software). I have a feeling Sony is planning a more legal approach to combating piracy this time.

[LiquidEagle]

Not to mention the heavier inclusion of online this time around -- XBox modders were SOL if they wanted to play on XBL, right? Same should go for this, and I never thought of it that way, Casual -- there really is no excuse for modding if all the games are region-free.

[nwo504]

there still is that "Backup" arguement

[venomv]

Could you be more specific?

[Zer0-Sum]

Hi all, first post, coming out of lurker mode....

Lets all admit that Arstechnica and even Slashdot are HUGE Sony haters. Everytime I go to those sites they have very little good to say about Sony for any reason, especially on the posting boards. Sure hannible paid lip service to Cell and PS3, but so far he has a lot of bad things to say about a system that has not even come out yet! So lame....

I read the aticle and I dont know what hannibles real point is other than they hate Sonys out look on Secutirty and protecting their IP. And modding a console is pointless if all the games are region free, unless you are just stealing games.

[gablar16]

It seems like a pretty impressive system to me. This hardware level security should make a very secure chip in other applications and even in the PS3. But cracking the PS3 architecture it's certainly not an easy task, that I imagine, employs some very expensive equipment and man hours.

I can see the worth of selling modchips now. There is a legal justification for it and a huge market of american and european gamers trying to play japanese only games. But PS3 is region free, so the only need for the modchip would be to play pirated games which is illegal. How fast can modding really spread if they are selling illegal products? How long would it take for sony to order a mod chip and report them to the local police departmentof the shipping address? ( Of course, Sony will provide a "small donation" to keep the boys in blue happy:salute:;-] )

I think that by the time modding a PS3 becomes a economically significant problem, We would be well into PS4 generation anyways. The PS3 it's not about being secure 100% of the time. Its about being profitable for the longest possible time.

[xbdestroya]

Venom, Nwo54 is saying there's still theoretically the legal argument that chips should be sold to allow the playing of 'backups.' Granted I don't know how far those arguments get in court.

@Deadboyz: Welcome to the forum!

[gablar16]

Venom, Nwo54 is saying there's still theoretically the legal argument that chips should be sold to allow the playing of 'backups.' Granted I don't know how far those arguments get in court.

@Deadboyz: Welcome to the forum!

True, the backup argument should hold up and the selling of modchips will continue over the internet. If not it will be a sad day for technology.

[overclocked]

Wasn't the actual IBM document referenced here by Ars posted by Cpi a couple of days ago in another thread? I believe it was, though I forget which thread.

Anyway Hannibal is way too dismissive of PS3's security considerations. Even if eventually the console does get cracked, it's going to be a rough rough slog for the people trying to do it.

EDIT: here (http://forums.e-mpire.com/showpost.php?p=1069999&postcount=76)

I thought Hannibal was *strangely* hard against Sony for something that seems to be a a security implemention more for the Server-style IBM kind of buisness.

He has got some anger for IBM cause they didnt live up to his hopes about the Mac. Maybe time to go and get some therapy... :shrug:

[section]

Cell BE security architecture paper here http://www-128.ibm.com/developerworks/power/library/pa-cellsecurity/

First, IBM starts out the paper with an acknowledgment that Cell's security architecture is designed to thwart only software-based attacks.

I don't know which paper Arstechnica writer must have read but it's not the same I did where it clearly says Although, the Cell BE processor does have defenses against physical attacks, the architecture's main focus is software-based attacks.

Cell BE's Hardware Root of Secrecy is a hardware based key, the paper doesn't say if it's changeable but I really doubt if it will ever be cracked with any type of modchip because it would effectively mean opening up Cell processor and coupling the modchip into some of it's innards.

This Runtime Secure Boot -security is very interesting, it can be implemented on a thread level so if developer wants to he/she can force checking of every thread the running application spawns, probably against newly created keypairs, so it's also very robust. I don't wonder anymore why PS3 OS needs an SPE to itself because seemingly the running application code encoding/decoding is done on an OS level.

[cybergrue]

Wasn't the reason PS3 became region free is to deny the only legitimate excuse someone could have to mod a PS3 (import software). I have a feeling Sony is planning a more legal approach to combating piracy this time.

Actually, it grosly simplified inventory and production, which lowers cost. Instead of making x number of copies of a game, one for each regon, you only have to make one version. I am assuming the translation costs would be much smaller then the cost to press annother version of the disk. Right now, game in North America have to support 3 languages (English, French and Spanish). Add two more languages (German and Italian), and you have most (but not all) of Western Europe covered as well. With the PS2, a seperate disk was required because of the differences in TV standards, but this shouldn't be an issue with the PS3.

Also, nich games with a limited appeal in other regons, such as some of the Japanese games in NA, and some of the NA games in Japan can be marketed there because the publisher doesn't have to press a minimum number of disks, and can make the avaliable through alternative distribution arangements, such as on-line instead of in gaming stores.

[venomv]

Venom, Nwo54 is saying there's still theoretically the legal argument that chips should be sold to allow the playing of 'backups.' Granted I don't know how far those arguments get in court.

@Deadboyz: Welcome to the forum!

Ahh, ok, I see.

I don't know what I think about that, there are people who don't want to do anything illegal with them, but most seem to.

@cybergure That is all true, but I think the main reason is probably because of fighting mod-chips in court.

[RavenFox]

Why would IBM post this? Its like the news at times giving away information ...just boggles the mind.

[cybergrue]

I read the aticle and I dont know what hannibles real point is other than they hate Sonys out look on Secutirty and protecting their IP. And modding a console is pointless if all the games are region free, unless you are just stealing games.
Hanabel has had derived the Cell for almost as long as there has been any data avaliable about it. I remember in late 2004 when some guy collected all the scraps of information known about the Cell, and combined into a paper and posted it to his web site. The data was pretty good, however some of the guys observations and conclusions were a bit off. I was taking a Masters level course in Operating system design at the time, so I found a few thing in the paper that although were not wrong, I woud not have stated in the same manner as the author did. This paper was widely linked to from many technical and gaming sites across the Internet, and finally Hanabel read it.

Anyways, Hanabels article ripped the paper to shreads with things like this:
Paper: "The Cell's SPU's don't have a cashe." <- True, the SPU doesn't have a L1 cashe using a strict and well known definition of the word cashe as used in describing microprocessors.
HANABEL "THE SPU's do have a cashe, it called the local store." <- This statement is only true if you do not use the strict definition of cashe.

And so on though the entire article. Anyways, its my opinion that Hanabel dosn't understand the Cell's architecture or the design decisions that lead to it, and instead of trying to understand it, he derives it instead.

[iceman2654]

Do you happen to have a link to Hanabel's article?

[xbdestroya]

Guys ok, I'm seeing Hannibal's name spelled differently everytime it's written here. Hannibal - that's the way. ;)

Anyway yeah I remember the original article, it was flying around everywhere at the end of 2004 (that's when it was, yeah?) Unfortunately I can't find it at the moment via Google, but I want to say Blackmoor was the author or something, yeah? Anyway Hannibal tore the guy up - and to be fair honestly it wasn't that great a piece, really a bunch of hype - but Hannibal went overboard. It was to the extent where the guy actually made a follow-up article to address Hannibal and some of his points.

[solidus]

You mean Blachford?
If so, Here's (http://www.blachford.info/computer/Cell/Cell0_v2.html) the link!

But regarding this article, I didn't know it was written by Hannibal after reading it, mainly because of the aricle's quality.
I don't see why software security in the form of firmware, or patches, couldn't work with the hardware's security architecture.

[xbdestroya]

Blachford!!! Yeah that's the one - thanks Solidus! :thumbl:

[Crossbar]

.... Anyways, its my opinion that Hanabel dosn't understand the Cell's architecture or the design decisions that lead to it, and instead of trying to understand it, he derives it instead.
I agree that Hannibal seems to lack deeper understanding of Cell and in some cases spread misinformation. I think he deserved his reputation from writing stuff other guys told him, when he´s writing stuff based on his own knowledge the techical level is pretty shallow.

For Example, Hannibal continues to claim that the SPEs lacks branch prediction and hence are inherently ineffiecient in branch intensive code, when infact the SPEs supports software guided branch prediction which can be extremely efficient and provides the benefit of giving 100% predictable execution time every time you run a piece of code, compared to hw prediction which is based on statistics.
I wonder if this branch prediction missunderstanding was what some MS guy told him, because his article on Xenon was very comprehensive, while the Cell article was shitty.

[cpiasminc]

For Example, Hannibal continues to claim that the SPEs lacks branch prediction and hence are inherently ineffiecient in branch intensive code
Usually, when people say that a CPU has a branch predictor, that means a hardware layout for it. There's nothing wrong with saying that the SPEs don't have a branch predictor because they really don't. And how efficient it is on branchy blocks is up in the air and is pretty much a case-by-case thing. If you have some huge computational operation that is loaded with branches, that will run pretty good as long as your branch hints are good. If you're talking about a plain old state machine which is near-zero computational load and 90% branches, that's not going to work out so well, and no amount of branch hints will help you.

when infact the SPEs supports software guided branch prediction which can be extremely efficient and provides the benefit of giving 100% predictable execution time every time you run a piece of code, compared to hw prediction which is based on statistics.
It won't invariably give you 100% correct prediction rate every single time. Nothing can ever do that. There might be specific SPE programs that do that well, but longitudinal averages -- no way. And most hardware branch prediction units will give you longitudinal prediction averages over 90%. Some, like the P4's are extremely verbose simply because the cost of a misprediction is so high.

I wonder if this branch prediction missunderstanding was what some MS guy told him, because his article on Xenon was very comprehensive, while the Cell article was shitty.
Not surprising considering XeCPU is out in the open while PS3 is still in a cave.

[section]

Not surprising considering XeCPU is out in the open while PS3 is still in a cave.
But nobody can't deny that there seems to be amazingly large amount of those who won't find anything good about anything Sony does, is it home appliances or gaming consoles. For many it doesn't seem to matter if IBM or Toshiba have collaborated their ideas and hardware, it's Sony that is the devil in whatever it touches.

And that's what ticks me off. Many supposedly trustworthy hardware sites have already chosen sides and therefore they seem to push their agenda although they usually don't know about the hardware facts more than your average Joe Sixpack via the published documents.

And that won't make such "technological forums" trustworthy at all. But sad thing is that such "factual" tech info spreads at these interweb times like fire in the bushes of Australia.

[xbdestroya]

There's always a sort of underrcurrent going against whoever the top player in a market is; for all the support that Microsoft enjoys vs Sony in the console market among the US gaming media, you'll see that Microsoft has no such fan base in the world of operating systems.

I wouldn't worry about the journalism in the tech industry as a whole - beyond the bias there *is* fact, and even when a site writes a biased piece on something, as long as you can filter out the slant and walk away with the 'facts' as it were, then it will have served a purpose.

[Arnaud_M]

If you have some huge computational operation that is loaded with branches, that will run pretty good as long as your branch hints are good. If you're talking about a plain old state machine which is near-zero computational load and 90% branches, that's not going to work out so well, and no amount of branch hints will help you.

Actually, I was thinking about this, and I have a question: why do you think branch hinting will be useless with finite states machines ? I am very familiar with FSM, but not with branch hinting, but I guess it works by the developper giving hints to the compiler about the most probable next state of the FSM (maybe given some current valuation of a set of variables ?) ? If so, do you think it is useless because you consider most FSM as too "random" for the hints to be really useful, or because the amount of CPU (SPE in this case) work needed to take the hint into account will overshadow any possible gain ?

Arnaud

[cpiasminc]

I think in general as an FSM starts proliferating in branching factor, probability of taking a given branch tends towards more and more Gaussian distributions -- of course, this is taking out local-scope factors that play into it, but often times in games, large decision trees that are computatationally light depend on data that is outside of local scope. Since the hints kind of depend on rough computation results (like you said), there is the "randomness" factor, but the less branching factor you have, the more skewed it becomes.

Even more than the "randomness", is just the tedium. People will overlook it quite easily because it is so much more important with an FSM to make sure it actually works without getting screwy.

It's not so much that branch hinting will be *useless*, it's just that it won't be that massive in its impact as it would with say, branches to prevent errors from propagating in a collision test... mainly because those are the kinds of things that have much earlier warning signs (much earlier meaning double-digit clock cycles). A branch hint is lot like a prefetch -- you're trying to beat out the potential misprediction in the same way a prefetch tries to beat out the potential cache miss.

[Crossbar]

LOL I thought that would get you going. :)
Usually, when people say that a CPU has a branch predictor, that means a hardware layout for it. There's nothing wrong with saying that the SPEs don't have a branch predictor because they really don't. It's not "traditional" branch prediction, but saying SPEs are lousy performers because they are paying a penalty at each branch is utterly wrong because they don't. Some branch predictions will easily be inserted by the compiler some needs to be insterted by the programmer, if you are writing in assembler you'll have full control. The only issue is that the branch prediction needs to be supplied 11 stages before the actual branch, if you have branchy code with little calculations this may be a problem, but there are special instructions for conditional assignments and some other tricks to help avoid those cases to some degree.
And how efficient it is on branchy blocks is up in the air and is pretty much a case-by-case thing. If you have some huge computational operation that is loaded with branches, that will run pretty good as long as your branch hints are good. If you're talking about a plain old state machine which is near-zero computational load and 90% branches, that's not going to work out so well, and no amount of branch hints will help you.A plain old state machine is usually a case switch in my world, and the SPE prediction works well in the switch, depending on how much is done in the case statement I may not get the required 11 stages in the actual case statement before the break instruction, but depending on how critical the code is I may find some useful work to be done there to avoid empty cycles.
Personally I try to implement statemachines through table lookups as far as possible, huge switch statements are not very elegant and usually bad performers on any architecture.
It won't invariably give you 100% correct prediction rate every single time. Nothing can ever do that. There might be specific SPE programs that do that well, but longitudinal averages -- no way. And most hardware branch prediction units will give you longitudinal prediction averages over 90%. Some, like the P4's are extremely verbose simply because the cost of a misprediction is so high.Actually I did not write it gives 100% correct prediction rate, but in theory you could actually implement it on the Cell, but it will probably not be worth implementing it. What I wrote was that it gives you 100% predictable execution times each time you are running a piece of code as you are not depending on the execution history of that piece of code. Oppose to the case of "traditional" hw prediction where you can expect a "random" behaviour of the branch prediction. (not really random, but you don't know how updated the branch prediction is at any given time, and every time you break away from the pattern you pay a penalty)
On a side note, another feature of the SPE which contribute to a very predictable execution is the lack of an associative cache which is another big contributor of random bad performance when a cache miss occurs. As long as you are able to feed the SPE with a steady flow of data through buffered DMA transfer it will perform as a dream. I think the comparison with VU-units on steroids is quite accurate. :)

Not surprising considering XeCPU is out in the open while PS3 is still in a cave.Not really, you can download an emulator for Cell from IBM, there is plenty of free documentation and active public discussion fora for cell and has been for the past 6-8 months.

[cpiasminc]

Some branch predictions will easily be inserted by the compiler some needs to be insterted by the programmer, if you are writing in assembler you'll have full control.
That's fine for people like me, but assembler is such a lost art, and I'm of a dying breed.

A plain old state machine is usually a case switch in my world, and the SPE prediction works well in the switch, depending on how much is done in the case statement I may not get the required 11 stages in the actual case statement before the break instruction, but depending on how critical the code is I may find some useful work to be done there to avoid empty cycles.
I'm used to state machine decision trees going down at least 4 or 5 levels... not quite so simple as a switch. Some I've worked with go down around 13 levels or so.*

* Note that these would be decision trees which are computationally light. Most computationally heavy things with branches don't go more than 1 level, and quite a few would probably be faster and easier to deal with simply by not dealing with the branch and doing a conditional move. At least on XeCPU and SPEs... Not so true on PCs.

Not really, you can download an emulator for Cell from IBM, there is plenty of free documentation and active public discussion fora for cell and has been for the past 6-8 months.
That's useless and too time-consuming for the scope of an article. Especially for a guy who admits that a deep architectural analysis would be out of his depth. The biggest weapon XeCPU has as far as getting information out is the fact that people feel more free to let stuff slip to their journalist friends now that the console is out. Not so true with Cell. It's really going to be the people who are pounding away on it all the time who would be the most meaningful and informative sources. Hannibal has his sources and those are going to be the ones he counts on.

[Crossbar]

That's fine for people like me, but assembler is such a lost art, and I'm of a dying breed.Fair enough, but there are actually a couple of intrinsic function who does the job in most cases, but to use them efficiently you need some assembler level knowledge. And for full control assembler is the way to go. I don't think you'll be out of job for a while if you enjoy assembler.:thumbl:
Personally I only resort to assembler for hw control reasons now a days. The performance issues we have are usually solved by loop unrolling and inline functions and some intrinsics, I find it hard to beat modern compilers most of the times.

I'm used to state machine decision trees going down at least 4 or 5 levels... not quite so simple as a switch. Some I've worked with go down around 13 levels or so.*

* Note that these would be decision trees which are computationally light. Most computationally heavy things with branches don't go more than 1 level, and quite a few would probably be faster and easier to deal with simply by not dealing with the branch and doing a conditional move. At least on XeCPU and SPEs... Not so true on PCs.
I actually think that the SPE has some very powerful bit vector instructions (including massive paralell conditional assignments) that could be used to calculate some transition conditions very efficiently. I think they will be used in a lot of very clever ways together with some new algorithms for AI etc. within a year or two.

... Hannibal has his sources and those are going to be the ones he counts on.Second that, and in the fields where he does not have sources the quality will suffer.

[Zer0-Sum]

This discussion got WAY beyond me about six posts back or so..... :p

[frosty]

LOL, programmer talk. At least you know that you can believe what these guys say about these systems because they know what they are talking about a lot more than most of us...

[venomv]

That's not the problem, it doesn't matter if I can believe them if I can no clue what they are saying, lol. Even though in this case I could pretty much follow them.