Technological discussion on PS3 security and crack.*

[Nesh]

The hardware keys are system specific. The only way Sony can issue a new metldr is if they recorded the hardware key for each PS3 produced, and can somehow sign and distribute the new machine specific metldrs. It would only be possible to do this over PSN and would make future on disk firmware updates virtually impossible due to the space needed to put every single possible metldr varient on a disk.

I am not sure if I am getting this correctly. So the problem here are the individual hardware keys for each hardware. Right?

Can they make a reversed solution?

Is there any other kind of specific "id" ascosciated with each original game that wont take as much space? Probably some software related parameter for each title.
If yes, can some form of "list" of these "id's" be included in a newer firmware that will exclude any other software (such as homebrew or pirated copy) that doesnt match it while use new keys for future games? Can a firmware "update" or "alter" the keys for each machine automatically?

The problem here would be how to secure the firmware of course from hackers so they wouldnt mess with it and create a custom version of it. I think I just answered my own question.

Its impossible

So how on earth can they do it? Is the PS3 doomed to malicious hacking? GeoHotz claims that there is a solution?

 

[tia86]

except if the hypervisor is ineffective and they are able to peek at memory they shouldnt (which they demonstrated). been talked about lots how you can just shutdown the isolated SPU after decrypting/validating and do whatever you want with the data.

Ok, but you cannot peek the memory inside SPE into Security vault mode.
You can run the update process (which contain new loaders & software keys) into Security Vault and do all I/O with external memory (RAM, HDD, Flash memory).
You can peek the I/O data, but is encrypted with the new keys.
Insted of using the isolated SPE only for crypt/decrypt, you use it for all update process.
This is valid if Cell keys are still unknown and nobody can run own code into Security Vault mode.

@Coloruless: somebody say that are system-specifi, somebody no.
But if the key to go into Security Vault mode is system-specific, then every ps3 manufactered need ad-hoc metldr. You cant execute (at the factory) a pre-defined code and then say to Cell "encrypt this with your hardware key and store it, this is metldr" because this process require to go into Security Vault mode.

 

[-tkf-]

Except we already would have any new key sony would use. It is pointless. You cannot keep secrets when you have to shout them in the commons to communicate.

Screw the secrets, Sony is back to security through being obscure. New games require FW 3.6. FW 3.6 makes it harder (not impossible, i got that part) to run homebrew or whatever. And most important it makes it way harder to run copies of FW 3.6 games.

 

[Npl]

Ok, but you cannot peek the memory inside SPE into Security vault mode.
You can run the update process (which contain new loaders & software keys) into Security Vault and do all I/O with external memory (RAM, HDD, Flash memory).
You can peek the I/O data, but is encrypted with the new keys.
Insted of using the isolated SPE only for crypt/decrypt, you use it for all update process.
This is valid if Cell keys are still unknown and nobody can run own code into Security Vault mode.

Ideally updating would be an totally isolated process, but you are still talking about the theory or idea behind the security which is far from what Sony actually managed to implement.
Its so broken that you dont have to get into the isolated SPU but just instruct it to decode into readable memory.
Even if Sony could do a perfect FW 3.6, the issue is that it still needs to be run on the broken firmware for updating, hence the whole firmware can be decrypted and disassembled and every new key can be extracted for it. So then you`d end up with a perfect security and its still useless because the new keys still are out in the open.

@Coloruless: somebody say that are system-specifi, somebody no.
But if the key to go into Security Vault mode is system-specific, then every ps3 manufactered need ad-hoc metldr. You cant execute (at the factory) a pre-defined code and then say to Cell "encrypt this with your hardware key and store it, this is metldr" because this process require to go into Security Vault mode.

every thing system specific is in flash.

 

[tia86]

Its so broken that you dont have to get into the isolated SPU but just instruct it to decode into readable memory.

The question is: if you pass data to the isolated SPU (the 'Oracle') and istruct it to decrypt, what keys are used for decrypting? Metldr keys or Cell hardware key?
If this isolated SPU use Metldr keys, you can encrypt the firmware update with Cell key.

 

[Squilliam]

I was just thinking about something, is there anything they can do with that disabled SPU in future hardware revisions in order to restore security?

 

[Npl]

The question is: if you pass data to the isolated SPU (the 'Oracle') and istruct it to decrypt, what keys are used for decrypting? Metldr keys or Cell hardware key?
If this isolated SPU use Metldr keys, you can encrypt the firmware update with Cell key.

Cell key is only used for the first loader (bootloader).

SPU kicks into isolated mode, decrypts + checks its code (metldr + keys) from flash via Cell masterkey + code (then the cell masterkey is never used again) and purges every leftovers. Unlike with firmware updates (are too big for 256K LS and need to be written out to flash) the decoded data stays on the SPU and is then used as code (chaining of crypto modules) - so you have a hard time getting the Cell masterkey.

So I bet whats available and used for signing are only keys further down the chain

 

[bomlat]

Or you could just wait till someone lifted the keys from the new firmware and signed a servicetool, or signed a CFW with the new keys (or if you fancy this branded an old OFW as a newer one).

The basic of the encryption:you can do the things only one way by the public key,and two way by the private.(actually this is the way which used nearly everywhere,example in you https communication)
So,in the future firmware they will broadcast the new public key,and they will keep the private in safety ( ) ,so you will have to get AGAIN the private key of the sony,or you have to de-solder the NAND and re-program it,or to insert a modchip (which is an ASIC ship usually)


So no,you can not make a new signature for the new service tool,because you will not have it !!!!

The ps3 doesn't have the private key of the sony- it's been simply a very big mistake, to make it this predictable.

And the plaintext firmware is not a so big business itself:we have that for the WII,for the PSP,for the xbox360,however it will not make any system less secure.(the flaws will make it less secure)

Now everyone have the opportunity to make his ps3 hacked,and usable as a multimedia device,or off-line gaming station - and that's it.Or you can use it on-line ,until the Sony will ban it.
This opportunity will be closed with the next firmware update.After that you will need a hardware modchip to run cfw

 

[bomlat]

So then you`d end up with a perfect security and its still useless because the new keys still are out in the open.

Like the xbox360?
the keys in the fw are interesting only if you want to play new games or use the psn.
Otherwise they will not make the system less secure (even with them you will not be able to signature anything)

 

[tia86]

Cell key is only used for the first loader (bootloader).

So I bet whats available and used for signing are only keys further down the chain

Ok, so there's the theorical chance for Sony to rebuild the trust chain, without open to world the new keys. If Cell Masterkey is not compromised and it's system-independent.

 

[makattack]

Like the xbox360?
the keys in the fw are interesting only if you want to play new games or use the psn.
Otherwise they will not make the system less secure (even with them you will not be able to signature anything)

No, on the XBox, you cannot burn a DVD with Halo Reach and run it on an unmodded console.

On the PS3 now, anyone can burn a BDR with God of War 3 and run it on ANY unmodified PS3.

 

[bomlat]

No one recognise that the new firmware will contain only the new public key?
There is no way to get the private key from the public (if there is a properly implemented ecliptic or rsa scheme)
Many guys claiming things,which if possible then we don't have today working internet banking, https,secure communication!!!!

The sony have to release with the new firmware the new public keys:after that the only way to hack the system will be the hardware modification.

 

[bomlat]

No, on the XBox, you cannot burn a DVD with Halo Reach and run it on an unmodded console.

On the PS3 now, anyone can burn a BDR with God of War 3 and run it on ANY unmodified PS3.

You can:but until the sony will restrict the usage of the compromised key to the pressed BR discs.

I don't know ho the ps3 secure elf working,but in the case of the xb360 there is a descriptor header for each executable,with the signatured hash and the status bits.
The status bit can define the condition,when the xb360 can execute the code:it can be from original disc,copied disc or from hdd.
So,from the future update the only accepted status bit will be the "PRESSED_BR" if the signature created by the compromised key.

Simply common sense.

 

[ban25]

No one recognise that the new firmware will contain only the new public key?
There is no way to get the private key from the public (if there is a properly implemented ecliptic or rsa scheme)
Many guys claiming things,which if possible then we don't have today working internet banking, https,secure communication!!!!

The sony have to release with the new firmware the new public keys:after that the only way to hack the system will be the hardware modification.

You need to consider it as a fork. From this point forward, hackers can fork the firmware and patch in whatever functionality they desire while also maintaining compatibility with Sony's changes (i.e. a new public key for future games).

 

[bomlat]

You need to consider it as a fork. From this point forward, hackers can fork the firmware and patch in whatever functionality they desire while also maintaining compatibility with Sony's changes (i.e. a new public key for future games).

Actual, it is more accurate like this : the hackers can update the compromised and not ofw updated machines with parts from the new firmware.
However,it will be next to impossible to tell which part doing what,and from the perspective of the Sony the target will be that to blacklist as mush compromised machine as possible.
(the hackers can read the fimrware of the MS,but actualy not so easy to tell how the jtag/dvd flash detecting part working,and each time many modded console fall out from the line)
There is a reason why I have two dash 6717 xbox360 in the storeroom ( rrod both of them,but I can re-flow them for enough time to be able to get the keyvault from them,and that worth more than 40 pounds)

It will be impossible to close out the hardware hack from the current ps3s,but it will be soldering / hardware programming ,and not simply a usb memory stick insertion.

 

[I.S.T.]

PSP, at least when I was still on the scene required exploiting either the hardware, software, or OS in order to inject code to initiate the hack. Hardware revisions could combat some of that. Firmware revisions can patch the OS. Games that rely on code introduced with future firmware revisions which remove exploits in the OS made that level of firmware required.

None of that is required on the PS3. You don't have to glitch anything. You don't need a buffer overflow. You don't need to modify hardware. You don't need anything.

PS3 hackers have what PSP hackers didn't have. The keys that Sony uses to sign everything and anything.

It's analygous to the PSP being a house where you have a key that lets you in and you have windows, ventilation ducts, chimneys, basement, and houseowners. The hackers don't have the key to get in. But they can break in through the window, or the chimney, or the ventilation ducts, or maybe even convince the houseowners they are here to repair something.

With the PS3, you may have a similar situation but bars over the windows, grating in chimneys, homeowners that can't be fooled etc. Only now, the hackers have the key to the front door so all that beefed up security doesn't mean squat. And the kicker to the whole thing? You can't change the lock without the hackers knowing what the new key is.

Regards,
SB

The PSP master keys have also been leaked. Right now, there are only a few signed things, but I imagine the number will grow in the future.

 

[aaronspink]

The basic of the encryption:you can do the things only one way by the public key,and two way by the private.(actually this is the way which used nearly everywhere,example in you https communication)

You REALLY REALLY REALLY don't understand how encryption is used do you? Here's a hint. The only think you use PubPriv encryption for is EXCHANGE of a key. You do not encrypt data with a pubpriv crypto system. You encrypt the data with the symmetric key you exchange via the pubpriv key exchange.

 

[aaronspink]

Actual, it is more accurate like this : the hackers can update the compromised and not ofw updated machines with parts from the new firmware.
However,it will be next to impossible to tell which part doing what,and from the perspective of the Sony the target will be that to blacklist as mush compromised machine as possible.
(the hackers can read the fimrware of the MS,but actualy not so easy to tell how the jtag/dvd flash detecting part working,and each time many modded console fall out from the line)
There is a reason why I have two dash 6717 xbox360 in the storeroom ( rrod both of them,but I can re-flow them for enough time to be able to get the keyvault from them,and that worth more than 40 pounds)

It will be impossible to close out the hardware hack from the current ps3s,but it will be soldering / hardware programming ,and not simply a usb memory stick insertion.

Someone here needs to read up on the history of satellite TV firmware...

 

[Toaddio]

Someone here needs to read up on the history of satellite TV firmware...

Someone around here needs to read up on the multiquote feature of the forums.

 

[makattack]

You REALLY REALLY REALLY don't understand how encryption is used do you? Here's a hint. The only think you use PubPriv encryption for is EXCHANGE of a key. You do not encrypt data with a pubpriv crypto system. You encrypt the data with the symmetric key you exchange via the pubpriv key exchange.

Practically, you're correct... but technically, there's nothing keeping you from using public key cryptography as you would a symmetric cryptographic algorithm (secret key algo) -- it's just computationally more expensive.

For that reason, SSL is setup so that the asymmetric algorithm is used to securely pass the session/secret key between two parties. The session/secret key is what's used to provide data security by encrypting/decrypting the actual data payload.

If you want a really secure, but computationally expensive secure channel. You could combine a digital signature key pair with a data encryption key pair -- both can be the same or even different asymmetric algorithms. This way, you not only have data security, but also have some reasonable assurance that the parties you're communicating with are who they say they are. Of course, your digital signature key-pair does need some trusted authorizing body to provide assurance.

How this would work could look as follows:

Harry met Sally, and both decide to securely communicate with their own Digital Signature Algorithm and some Public Key Cryptography algorithm that both agree to (HnSCrypto).

Harry generates 2 pairs of public/private key-pairs. One for his Digital Signature needs, another for data encryption.
Sally generates 2 pairs of public/private key-pairs. Again, one for signing, and one for data encryption/decryption.

Harry publishes both of his public keys to Sally in a manner Sally trusts
Sally publishes both of her public keys to Harry in a manner Harry trusts

Harry writes a love letter, to Sally, signs it with his signing private key (their DSA involves generating a hash of the entire message, and sending that hash value with the private signing key to the HnSCrypto algorithm)
Harry then uses the same HnSCrypto algorithm with his other private key to encrypt both the cleartext message and the messages signature. This result, he sends to Sally.

Sally uses the Harrys messaging public key to decrypt the message received using the HnSCrypto algorithm.
Sarlly then uses Harrys signing public key to verify the digital signature by decrypting the signature, regenerating the hash over the cleartext message, and comparing it.

Sally now can read the cleartext message Harry sent, and knows it really came from him.

Another variant of the above use-case would have Harry and Sally using the other persons public key to encrypt the signed data.

I haven't read through all the above posts -- but I did see something glaringly wrong... but didn't have the time to point it out when I saw it... someone said something about an asymmetric key-pair where (I'll paraphrase): the public component only "works in one direction" and the private component works "both ways"

That really just doesn't make any sense... but it's easy to see why someone who doesn't fully understand cryptographic algorithms can get confused.

With asymmetric cryptography, most people refer to the key-pairs as the "public" and "private" components -- unfortunately, some people still refer to the "private" key as a "secret" key.

The term "secret key encryption" is synonymous with symmetric encryption -- used to describe all algorithms where the same key is used to both encrypt and decrypt data.

Unfortunately, calling the private key used in asymmetric encryption (also known as Public Key Cryptography) the same as the secret key in symmetric algorithms is only valid if you consider that both keys are comprised of bits. That's really the only relationship.

The private key component of an asymmetric key-pair is mathematically related to the public key. They are invalid without each other. That's the security of it. In a secure implementation, it would be very computationally expensive to be able to determine one key if you have the other key. Likewise, if you have data encoded with either the public or the private key, it should be computationally impractical to try and derive the other key. Unfortunately, that is not the case with the PS3.

Hence, this is now used as a "how not to implement a digital signature algorithm" use-case.

BTW, I used to work in the world of cryptographic computing, and it's guys like this: http://www.gamefaqs.com/boards/960187-/57175136 who made it so much fun. Incidentally, this is one reason I really admire and like the work the failover folks did. For a crypto-geek, it's... just cool.

If you perform a google search for "ps3 cryptanalysis" you'll get other relevant links and more technical information than if you search "ps3 hack"

Again, I find it interesting that the PS3 is mentioned, ignobly in this wiki entry for a "Timeline of cryptography" : http://en.wikipedia.org/wiki/Timeline_of_cryptography

2010 - The master key for High-bandwidth Digital Content Protection (HDCP) and the private signing key for the Sony PlayStation 3 game console are recovered and published using separate cryptoanalytic attacks. PGP Corp. is acquired by Symantec.