My guess? The suits at Sony, being as incompetent now as they always have been, still haven't realized the seriousness of their situation.<p>I'd love to be privy to the email exchanges that must be going on there between their engineers and management...<p>Alternatively they do have a solution, and it's something to the effect of "nuke it from orbit"/"if we can't have it, <i>nobody</i> can". They already tried to take that approach with OtherOS, so this should get entertaining if that's the case.
Here's the problem (picture supplied by first result after googling for ps3 nand motherboard):<p><a href="http://s200.photobucket.com/albums/aa138/ejsid/infectus%20ps3/?action=view&current=DSC01329.jpg" rel="nofollow">http://s200.photobucket.com/albums/aa138/ejsid/infectus%20ps...</a><p>The keys are <i>hard-coded</i> in hardware and the content in question lives on a TSOP NAND device on the motherboard. No matter what Sony does, they can't prevent you from flashing your own code, signed with the old keys, to that onboard NAND. Whether you de-solder it and socket it, or use some other sort of hardware device, Sony is screwed for old hardware.
If I can resurrect my PS3 and run *nix natively on it with graphics and full blown access to the co-processors I'd buy a second one for gaming.<p>The main problem is the memory limitations of 256MB+256MB but with careful configuration it can be just OK.<p>I wouldn't be surprised if this ends up making the PS3 ubiquitous leaving all the other consoles behind. Even in spite of the poor higher management coming from old media (the ones pissing off traditional developers, forcing Blu-Ray and that insane rootkit.)<p><a href="http://en.wikipedia.org/wiki/Howard_Stringer" rel="nofollow">http://en.wikipedia.org/wiki/Howard_Stringer</a><p><a href="http://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootkit_scandal" rel="nofollow">http://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootki...</a>
Let's say they update the hardware to include a new public key. They now have the issue that existing signatures don't verify properly. You can mitigate this by having a list of existing valid signatures which can use the old key, but that can't be the best way. Can anyone come up with another?
<i>"We will fix the issues through network updates, but because this is a security issue, we are not able to provide you with any more details,” [Sony] said.</i><p>Wrong on two counts. First, Sony can't really "fix" the problem, merely patch over the current situation until their "fix" is compromised. At best they can hold freedom off for a little while longer.<p>Second, there is no security through obscurity, and failing to explain exactly how they will "fix" the compromised hardware is vainglorious. If a fix does exist, it will be so resistant to exploit that an explanation won't change anything.<p>It's conceivable for them to have an impervious fix (without conceiving of the fix itself), however experience has shown that the strongest schemes are the ones that have been exposed to the most eyeballs.
They can simply check the date it was signed:
if (dateSigned() < 1293775200) {
// Verify with old PubKey
} else {
// Use new PubKey
}
What is the big deal here?