facebook rss twitter

Sony lets slip its PlayStation 3 Master Key - oops!

by Alistair Lowe on 25 October 2012, 17:52

Tags: Sony Computers Entertainment Europe (NYSE:SNE)

Quick Link: HEXUS.net/qabocj

Add to My Vault: x

This wouldn't be the first time Sony has leaked important security keys, common to every PlayStation 3 console, however, this is the first time the console's LV0 decryption keys have been let loose in the wild.

So what makes the LV0 keys so special? These are the core security keys of the console, used to decrypt new firmware updates. With these keys in-hand, makers of custom firmwares (CFW) can easily decrypt any future firmware updates released by Sony, remaining a step ahead of the update game; likewise, modifying firmwares and preventing them from talking back to Sony HQ also becomes a much easier task.

Up until now, Sony's PlayStation 3 has been the most secure of the mass-market home consoles, with initial hacks late to arrive and updates to the console's firmware stopping any further progress in its tracks. So where has Sony gone wrong and what can the firm do to resolve the issue?

Perhaps the most obvious mistake was to allow keys to leak in the first place, which were extracted through a flaw in the console's hypervisor. Another is that the firm will have had the opportunity to provide a unique key for each console, however likely opted out of this to decrease the complexity of the firmware update system.

Sony PlayStation 3

Going forward, Sony likely has three routes, the first would be to frequently release confusing firmware updates to keep hackers at bay long-enough to push-out the next firmware update with new security. The second would be a more proactive approach, where the firm delivers an update that will at-last generate new unique keys for consoles, preventing the use of any universal custom firmware, though, this is assuming that the LV0 key can be locked-out as an override. The third, long-term approach, would be to ship all new PlayStation 3 consoles from now-on with new master keys.

The group that released the new CFW with LV0 master keys calls itself "The Three Musketeers". It claims that it only released the keys now, in the knowledge that a Chinese group also planned to release the keys, however, for a profit.

Perhaps Sony and the industry in general can be thankful that this leak has happened less than a year before the expected launch of the PlayStation 4.

HEXUS Forums :: 7 Comments

Login with Forum Account

Don't have an account? Register today!
Posted by YenRug - Thu 25 Oct 2012 11:49
I think there's been a bit of a mix-up in this story, which is a couple of days later than even Eurogamer covered it. The leak of the Lv 0 keys was from “The Three Musketeers” hacker group, they had managed to extract the key from the PS3 and had sat on the information; someone in their circle then leaked it to some other groups, with a Chinese team deciding to exploit it and start selling regular updates based on this information. When they learned of this, “The Three Musketeers” made the information public to stop the financial exploitation.
Posted by Kushan - Thu 25 Oct 2012 12:04
The story is waaay off in terms of correctness.
Every PS3 does, in fact, have a “unique key” inside its first stage bootloader (bootldr). This is unique for every PS3. The next stage in the boot process is lvl0, which will then go on to load everything else. The “lvl0” key leaked here is what bootldr uses to verify lvl0 before loading it.
The problem for Sony is that bootldr cannot be changed, it is part of the PS3's CPU and permanently set in hardware. Since all Firmware updates have to be read by all PS3's, they are now permanently decryptable so future CFWs aren't going to be an issue for existing consoles. It means that people can create a hacked lvl0 and sign it so that bootldr will load it.

Now the catch for CFW users is that if you're on a later firmware, you have no easy way to install a CFW - you can use hardware to replace the lvl0 with a hacked one, but later PS3 models already use a different mechanism (late slim models and all super slim) so this won't work. Instead, a different exploit will have to be found to allow you to replace the bootloader chain.

In any case, it's bad news for Sony and akin to the PSP days whereby once you've installed CFW you're good forever but when you update you'll have to downgrade or hope for an exploit. In any case, the vast vast majority of PS3's can be downgraded with hardware.
Posted by Scribe - Thu 25 Oct 2012 17:23
OK guys, I'm going to have to clarify what the intent of the article was here and I'm going to admit right away that I'm not in with the CFW scene on the PS3, however I made some reasonable assumptions based on knowledge of embedded systems.

- Each PlayStation has a unique id (of course), however, it clearly doesn't have a unique LV0 encryption key or one that utilises the console's unique id, else the leak of a handful of LV0 keys wouldn't be a big issue.

- Typically the keys used by first-stage bootloaders (which are typically nothing more than decrypting bootstraps) are OTP (One Time Programmable) when chips are first flashed in the factory. Sony missed its chance to program these unique keys at this point (not talking about the bootloader's own encryption here).

- Firmware updates do NOT have to be understood by all PlayStations if the keys were unique, Sony could have reasonably encrypted images as they left servers based on a lookup and the console's unique id.

- With this same logic, Sony could now deliver a new firmware that implemented this concept in a later-stage of bootloader, preventing hacks that mimic a firmware update or that could be easily mass-deployed. This would limit LV0 hacks to those who are directly willing to reprogram/replace the PS3's internal flash or to when a new exploit is found.

This seems to line-up with what you're saying doesn't it Kushan?
Posted by Kushan - Thu 25 Oct 2012 19:36
Hi Scribe,

Most of what you're saying is fairly correct, however you're (and don't take this the wrong way) way wrong when it comes to the Firmware Updates not being Unique. The problem is that not all PS3s have network connectivity (Last I checked, which was some time ago, it was about 2/3 of PS3's had been online at least once - which means a good 1/3 stay permanently offline. For the sake of argument, let's say it's half that - 1/6 - that's still at least 10million PS3's) and the updates get pushed out with the games themselves, which may require a certain FW version to work. There'd be absolutely no way to include a FW update for every PS3 in existence on a BD-ROM. Even for the PS3's that do have network connectivity, they don't always have great speeds or a lot of bandwidth to spare. Each PS3 update is nearly 200Mb in size, which today for many is quite a bit, let alone back in 2006. That's also why Sony doesn't always “force” people to update. Oh and it does have a “patch” system whereby incremental patches are released rather than full OS's but this was only actually implemented in versions above 3.4 (possibly another oversight from Sony).
In any case, a unique FW update for every console wasn't really plausible back in 2006 and is still somewhat unlikely today, at least for systems as widely distributed as the PS3.

However, the PS3 does actually have a bunch of unique per-console keys (not just console ID's). It's my understanding (I'm a little bit hazy on this myself) that the bootldr is encrypted on a per-console basis so there's no way to easily decrypt it. Bootldr then decrypts lvl0, however this was using a static encryption key - this is the key we're talking about here (Shared amongst all PS3's). However, it was secure because bootldr was secure. What you're saying is that lvl0 should have been encrypted on a per-console basis and that would have possibly helped, but as it's updatable and with the above issues, it would mean that the console would have to store the encryption key as well as the decryption key - I'm guessing Sony seen that as too much of a risk (evidently someone's managed to exploit at least one bootldr to get the key so the result would have been the same anyway, I suspect - just not as easily done).
Posted by Agent - Thu 25 Oct 2012 21:42
The first-stage bootloader is in ROM and has a per-console key which is effectively in tamper-resistant silicon. The second-stage bootloader (bootldr) is encrypted with the per-console key, but is not upgradable and is the same for all consoles (other than the encryption wrapper around it). This second-stage bootloader verifies lv0. Sony signed lv0 using the same broken process that they used for everything else, which leaks their private key. This means that the lv0 private key was doomed from the start, ever since we demonstrated the screwup at the Chaos Communication Congress two years ago.

However, because lv0 is also encrypted, including its signature block, we need that decryption key (which is part of bootldr) before we can decrypt the signature and apply the algorithm to derive the private key. We did this for several later-stage loaders by using an exploit to dump them, and Geohot did it for metldr (the “second root” in the PS3′s bizarre boot process) using a different exploit (we replicated this, although our exploit might be different). At the time, this was enough to break the security of all released firmware to date, since everything that mattered was rooted in metldr (which is bootldr’s brother and is also decrypted by the per-console key). However, Sony took a last ditch effort after that hack and wrapped everything after metldr into lv0, effectively using the only security they had left (bootldr and lv0) to attempt to re-secure their platform.

Bootldr suffers from the same exploit as metldr, so it was also doomed. However, because bootldr is designed to run from a cold boot, it cannot be loaded into a “sandboxed” SPU like metldr can from the comfort of OS-mode code execution (which we had via the USB lv2 exploit), so the exploit is harder to pull off because you don’t have control over the rest of the software. For the exploit that we knew about, it would’ve required hardware assistance to repeatedly reboot the PS3 and some kind of flash emulator to set up the exploit with varying parameters each boot, and it probably would’ve taken several hours or days of automated attempts to hit the right combination (basically the exploit would work by executing random garbage as code, and hoping that it jumps to somewhere within a segment that we control – the probabilities are high enough that it would work out within a reasonable timeframe). We never bothered to do this after the whole lawsuit episode.

That's a fail0verflow dev.

SEE NEWER »