Technological discussion on PS3 security and crack.*

[draconian]

http://www.ibm.com/developerworks/power/library/pa-cellsecurity/

The runtime secure boot can protect the certificate revocation list (think of this as the list of bad guys) from modification (a particular bad guy might be removed from the list, for example). The hardware root of secrecy can ensure that the private key is not exposed by an attacker. (If the private key is obtained, all communication addressed to the private key owner will be exposed to the attacker). The hardware random number generator protects against replay attacks (see Resources) by marking the current communication with a time stamp. A replay attack is where an adversary takes an old communication message and sends it again through the unsecured communication channel. Because the authentication protocol will verify that the message is authentic, a robust time stamping feature is the only way for the communication partners to realize that there is a man-in-the-middle attack happening.

So, it seems the cell does have hardware random number generator. But isn't used for encryption?

Maybe the hardware random number generator is only used for the firmware code (hypervisor).

and the hypervisor(that sony wrote) itself encrypts/decrypts SELFS with it's own seperate key that does not have random number in it.

 

[Colourless]

The signing tool using by Sony probably used something like the Standard C Library rand() function which produces the same numbers each time its run, unless you set the seed value and even then its still not suitable for cryptography use. Then again someone might have just generated a single random number thinking thats all that was needed to be done and hard coded it in the signing tool or stored it in a reused data file with the private key

If something like that is the case, and the same tool is used to sign games, for production, then the digital signatures there will most likely have the same problem too.

 

[BadTB25]

Looks like geohot has released a firmware package decrypter. Things are moving fast on the PS3 Scene.

http://psgroove.com/content.php?586-Geohot-Releases-dePKG-Firmware-Package-Decrypter

 

[whome0]

From what i gather the Game keys haven´t been cracked yet, but unless Sony actually used random keys on those... it shouldn´t take long.
But they can sign their own firmwares, making it easy to run anything that isn´t crypted to begin with, and the decryption of games is already in place. So that leaves us with a wide open console.

Making own signed custom firmware package and run any programs (better media center client, .mkv support, .srt/.sub support, etc...) yes, but games use many of the SDK interface services (psn network, friends lists, whatnot helper methods, ...). It might take time to implement all this in a custom FW, unless they can crack and transparently reuse libraries from the official firmware.

 

[draconian]

Watching the Chaos comm., everyone has to now surely agree that Sony's firmware team is not only made up of a bunch of mediocre programmers, but also really really bad ones. After 4 years, they still can't get cross voice chat and their OS foot print is still like 40-50 megs.

For those that haven't watched the Chaos Comm. youtube videos, Sony has to encrypt / generate signatures for all their packaged firmware components. In the process of generating a signature via ECDSA method, they have to use their private key and a random K (a non predictable value, non recurring value), but the problem is they (Sony) are using the same value K over and over again in signing their packages.

As described in
http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/

if the encrypter uses some predictable / recurring K, then via simple algebra, an exploiter will have
one equation (a signed binary) where the 2 unknowns are a random K and the private key
2nd equation (a signed binary) where the 2 unknowns are a random K and the private key

and everyone knows, when you have 2 unknowns and 2 equations, you can solve the equation.
So, this is how they got the keys to sign the packages. But this appears to be for things signed at level 2 (gameOS). They specifically said that they don't have level 1 or level 0 keys (yet).

[another thought is, why even use asymmetric encryption where a public key, random k, private key is needed? Would'nt it be smarter for a console maker to use a symmetric one where there is no random k and simple secret cipher / decipher]

Now this is where things are hazy for me,
since they now assert that they can make asbestOS.pup(custom firmware),

I'm guessing they can get level 1 or level 0 keys using the same method? Or maybe they don't need level 0 or level 1 keys? Since Level 2 is where gameOS resides and that is good enough? But if that's the case, Sony can block this exploit buy updating the hypervisor (level 0 / 1) and check via whitelisting of official sony binaries).

If sony's faulty ECDSA implementation is stored and run from the run time boot authentication, then sony is doomed. Otherwise, if the faulty implementation is run via code from the pup itself, then sony can recover.

 

[betan]

Symmetric decryption is easier and faster but reveals the private key to the decryptor.
So it's convenient to encrypt a random symmetric key with asymmetric encryption, and encrypt the large secret with this random key.

 

[JPT]

Watching the Chaos comm., everyone has to now surely agree that Sony's firmware team is not only made up of a bunch of mediocre programmers, but also really really bad ones. After 4 years, they still can't get cross voice chat and their OS foot print is still like 40-50 megs.

Just a dumb question, how do you know that they "can't get cross voice chat" ?

 

[-tkf-]

Watching the Chaos comm., everyone has to now surely agree that Sony's firmware team is not only made up of a bunch of mediocre programmers, but also really really bad ones.

What the... you read the source code you know the conditions under which the firmware was created under? You have no idea how the random number ended up not being random. The chance it was on purpose is pretty slim. To me it shows signs of a development under extremely high pressure and development tools that wasn't ready.

 

[BRiT]

Just a dumb question, how do you know that they "can't get cross voice chat" ?

Is it available yet? No. I think that was his thinking in the process. Of course there could be silly business reasons to not make it available.

 

[Elan Tedronai]

Ability to sign anything. You know what that means?
Say goodbye to online gaming and safe transactions on PSN. Say goodbye to browsing over the net without worrying about viruses.

Playstation 3 is completely fucked

 

[BadTB25]

Ability to sign anything. You know what that means?
Say goodbye to online gaming and safe transactions on PSN. Say goodbye to browsing over the net without worrying about viruses.

Playstation 3 is completely fucked

How would browsing over the net via PS3 get you viruses now when it wouldn't get you them before?

Moot point for me though since I do not use my PS3 to browse the net.

 

[Xenus]

I'd guess signed code injection but I really doubt there would be that much of a problem with viruses, The bigger issue would be a custom firmware type race like they have on the PSP. Though if they properly did their new game keys and encryption which is a big if they might be protected form pirating as long as they update the keys often enough to stay one step ahead.

 

[JPT]

Is it available yet? No. I think that was his thinking in the process. Of course there could be silly business reasons to not make it available.

Its just that its a serious leap going from its not there to people are incompetent. Especially without knowing what kind of limitations etc that has been put in place by external circumstances etc.

 

[makattack]

[another thought is, why even use asymmetric encryption where a public key, random k, private key is needed? Would'nt it be smarter for a console maker to use a symmetric one where there is no random k and simple secret cipher / decipher]

The reason for an asymmetric (public key cipher) algorithm: it is how you can most easily and securely implement a digital signature protocol. In fact, ECDSA stands for EC (Elliptic Curve) DSA (Digital Signature Algorithm).

It allows you to sign your code (or whatever data you are signing) with your private key. With the public key widely distributed (amongst all the consoles -- in firmware/OS), you don't have to store the private key material (the secret key) in an inherently insecure/widely distributed system.

Anyone with the public key can validate the digital signature.

Although it's a high-level summary, this wiki entry is decent for describing the specifics:
http://en.wikipedia.org/wiki/Elliptic_Curve_DSA

This actually, when properly implemented, is much more secure than a secret key algorithm.

Additionally, don't confuse this with data encryption. Typically, you use a Public Key algorithm to securely transmit secret keys for secure session based encryption (e.g. SSL).

When you have a situation where the secret key is compromised, the only solution is to rekey. Generate a new secret/public key pair. Of course, this means you'll need to redistribute the new public key -- but all old software/data signed by the old key will be invalid. That is, unless you have the capability to store multiple keys, and you specifically allow the old key to be used...

That is Sony's best alternative. Update the system to support multiple keys. Generate a new key pair. All old software will be insecure, but still work (and copy/mod-able). New software will be secure. Of course, if they can't securely sign the new firmware with this new key pair, they are still S.O.L. as people will still be able to overwrite the firmware and install any self-signed code using the old keypair.

 

[Commenter]

If this hack is as big as some are suggesting, and it will lead to wide scale piracy, I guess the ramifications will be quite big.

Do you think this might force Sony to change their strategy, and start trying to follow Nintendo's model of making profit on hardware/peripherals, such as focusing on selling move peripherals?

 

[Npl]

....Of course, if they can't securely sign the new firmware with this new key pair, they are still S.O.L. as people will still be able to overwrite the firmware and install any self-signed code using the old keypair.

Thats no "if"... current firmwares cant know the not-yet-existing new keys.

They are pretty screwed in that regard - supposedly they get new firmwares which arent breached they could only use a whitelist including hashes of each and every official signed software to effectively counter it.

The biggest issue is if you can somehow decrypt the new firmwares, mod them to accept the old key without fuss and then sign it with the old key - this would install to every existing console that hasnt been updated past 3.55 atleast. Similar to the game of CFWs that was played on the PSP.

Supposedly the updating mechanism should be seperated enough so that you cant read the decrypted data.. but my confidence that Sony somehow couldve gotten this right is vanishing. If thats the case then you`d always be able to downgrade and use modded/custom firmwares, but atleast new firmwares from Sony would be safe from beeing modded.

 

[Colourless]

I could be completely wrong, but I can't see how Sony will stop people taking new firmwares, modding them, then resigning them with the private key and package it together with the old loaders.

 

[Npl]

I could be completely wrong, but I can't see how Sony will stop people taking new firmwares, modding them, then resigning them with the private key and package it together with the old loaders.

updating should run below everything else, restoring the chain-of-trust. means the keys/code to decrypt would be in the new firmware package protected by a a lower cryptographic layer (never leaving the SPU and not broken), and could simply be swapped out in newer firmware.
Thats how I understood the security features of Cell when I red through them, I dont know how its done by Sony.

eg. a Firmware package should look like:
[cryptro LV1] protected by cryptro LV0
[modules] protected by cryptro LV1

so trying to install a new Firmware might pass a simple signature check, stops XMB and starts the updater but then fails the thorough check.

 

[BRiT]

NPL, I was under the impression that they had hacked the lowest level of security crypto used. If that's true, then there is nothing Sony can readily do.

 

[draconian]

Just a dumb question, how do you know that they "can't get cross voice chat" ?

technically, I'm sure they can do the cross game voice chat part, but I think the external limitations are the memory issues. They need reorganize or rewrite their OS to have a smaller memory footprint. And ultimately, this is a technical issue.

What the... you read the source code you know the conditions under which the firmware was created under? You have no idea how the random number ended up not being random. The chance it was on purpose is pretty slim. To me it shows signs of a development under extremely high pressure and development tools that wasn't ready.

No, i think it was on purpose. I can easily imagine the guy reading/implementing the ECDSA docs and translating the word "random" into Japanese and understanding it to be simply a non-obvious value (i.e. 2343293846563306710445) instead of non-recurring / non predictable / non-repeatable value. Then again, this guy is probably not on the firmware team is on the app signing package team.

Its just that its a serious leap going from its not there to people are incompetent. Especially without knowing what kind of limitations etc that has been put in place by external circumstances etc.

Fair enough. But I don't think the lack of voicechat is due to patents/3rd party issues (i.e. EA threats)

The reason for an asymmetric (public key cipher) algorithm: it is how you can most easily and securely implement a digital signature protocol. In fact, ECDSA stands for EC (Elliptic Curve) DSA (Digital Signature Algorithm).

It allows you to sign your code (or whatever data you are signing) with your private key. With the public key widely distributed (amongst all the consoles -- in firmware/OS), you don't have to store the private key material (the secret key) in an inherently insecure/widely distributed system.

This doesn't make much sense to me. Either way, a key is stored on the machine. With a public key, they might not be able to sign code for execution on the ps3, but they could certainly decrypt it and see the code itself (for running on emulators. well, ok ps3 apps don't have to worry about this, but psn apps might)

NPL, I was under the impression that they had hacked the lowest level of security crypto used. If that's true, then there is nothing Sony can readily do.

well, no one really knows how the security works. The hackers are claiming that they can make a *.pup file. If the decrypter/encrypter code is from Sony's updateable pup itself, then sony can recover via whitelisting of old binaries and using new keys for new binaries. If the code for the encrypter is not updateable, and actually inside the CELL itself (like the on die boot rom), then sony is screwed. I think it is the former and not the latter. But who knows whats going on in the firmware team's mind.