Technological discussion on PS3 security and crack.*

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.

You are correct that technically you could use an asym crypto algorithm to do bulk data encryption but it would be very very computationally expensive. There are good reasons why no one does that in practice.

Then there are issues that asym crypto is generally only designed and tested for relatively short messages. I'm not aware of anyone who has done in depth analysis of the asym crypto used for large scale bulk data transmission.
 
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?
No, as in many PS3 that disabled SPU is disabled on account of it being broken. ;) (The deliberately deactivated SPE in otherwise healthy 1:8 Cells is done to achieve parity with broken 1:7 Cells that were used for cost purposes due to yields.)
 
No, as in many PS3 that disabled SPU is disabled on account of it being broken. ;) (The deliberately deactivated SPE in otherwise healthy 1:8 Cells is done to achieve parity with broken 1:7 Cells that were used for cost purposes due to yields.)

Im talking about say a future hardware revision where they reactivate the SPE. Surely the yields are at a point where if they were to reactivate the SPE they could branch off a new line of PS3s from that point which were immune to the previous hack? Since it is something unavailable to the current line of PS3s which are hackable it would give them a point of differentiation and perhaps make it unreplicateable for all present PS3s on the market which have that SPE disabled?
 
In terms of future hardware, an available SPE wouldn't be any more use than the current reserved SPE - it has no greater protection than any other SPE. A future hardware revision would patch the problem by fixing the whole security key issue. That's likely to be implemented at some point, but it can't fix the current userbase. I guess in theory they could use an 8th SPE and dedicate it to encryption for using some very high cost methods, but that's not really the issue. If the implementation of the elliptic curve encryption hadn't been cocked up, we wouldn't have this mess, so creating extra complex security would be adding complexity for no real gain at this point.
 
You are correct that technically you could use an asym crypto algorithm to do bulk data encryption but it would be very very computationally expensive. There are good reasons why no one does that in practice.

Then there are issues that asym crypto is generally only designed and tested for relatively short messages. I'm not aware of anyone who has done in depth analysis of the asym crypto used for large scale bulk data transmission.

Yes, it's computationally expensive, as I already said -- and you quoted. That is the basis of asymmetric key algorithms. A secure public key algorithm is one, which is based on the difficulty of solving certain mathematical problems. Problems such as factoring *large* primes, or finding a discrete logarithm of a random elliptic curve given a known base point.

Your statement that asymmetric key ciphers are "only designed and tested for relatively short messages" isn't accurate.

I think maybe you want to say that one-time pad ciphers are still the most secure way to maintain secrecy, if properly implemented, and used with a secure key exchange method.

Asymmetric key cryptographic algorithms are not specifically designed and tested for short messages. They're designed so that it would be computationally expensive to attack.

It really is a fascinating area of computer science, if you're really interested. The wiki entries on cryptanalysis, one-time pads, and public-key cryptography are very good to get an overview.
 
Last edited by a moderator:
Your statement that asymmetric key ciphers are "only designed and tested for relatively short messages" isn't accurate.

by designed, I'm talking about the actual engineering around it. The general assumption is that you aren't sending gigabytes of data with an asym cypher. This has generally restricted the type of analysis used which is somewhat important considering all the cracks/etc against various cyphers generally rely not on brute force but reducing algorithmic complexity. Given large scale data and in this case realistically large known plaintext, the question becomes, are there any additional algorithmic faults that can be exploited?
 
Someone here needs to read up on the history of satellite TV firmware...

In the case of the sat,you need the PRIVATE key to get access to the content:with it you can decrypt it without paying any money.
Here not the content the interesting,but the control above the software.
And that can be granted with a public key.
 
I think no one get the real problem of the Sony,and the seriousness of this hack.

1.The biggest issue currently not the ability to run not signed code: with the private key in the wilderness the only one thing that anyone need to fake itself as the Sony update site-from that point of time he will be able to make a ps3 zombie army,or just simply kill all of them.
Instantly making a big financial liability.

2.the embedded "private" key is not important:the encrypted ,not readable firmware is just a not necessary feature,not a needed one.
The main thing is :the sony consoles can accept only that firmware,which have the signature of the new sony private key (a new,not compromised one)
If this fulfilled then the damage controlled .

Until that point anything can happen,after that only the fraction of the consoles will be a problem.

3.The ps3 protection is not similar to the BR AACS protection.I think many mixing up the two.
The AACS is a drm,the ps3 is a hardware chain of trust.
In the AACS the protected item is the decrypting private key-in the ps3 the confidence in the hardware of the end user.
So,the Sony just want to avoid to make hardware which can run not trusted software,the AACS want to allow only to the authorised users the content access.

Due to this,if the AACS compromised then they have to re-distribute the decrypting keys- if the ps3 they have to re-distribute the new signature checking public keys.
 
If the PSP is anything to go from, then real homebrew for the PS3 might be close.

PSP homebrew that runs on all firmwares have been released, everything from Doom to crazy homebuild games are released.. download and put them on a stick, and run them.
 
If the PSP is anything to go from, then real homebrew for the PS3 might be close.

PSP homebrew that runs on all firmwares have been released, everything from Doom to crazy homebuild games are released.. download and put them on a stick, and run them.

All firmwares? You mean even non custom fw?
 
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.

Why virtually impossible? You don't need to put an entire new metldr for every ps3.
You can encrypt the new firmware with a new AES key. Store this AES key with a small loader that run in Secure Vault, and encrypt this loader+AES key with the cell hardware key.
So, the only part that is system-specific is this small loader and AES key, you could fit into 128bytes of data. When the loader is decrypted and loaded into Secure vault, it fetch a block of the new firmware, decrypt with AES key and then begin the updating process.
Since is 128bytes only, you can store all possible variations only in 5GB of data. Even GT5 use only 15GB of BD-25GB, you have enought space.
 
Why virtually impossible? You don't need to put an entire new metldr for every ps3.
You can encrypt the new firmware with a new AES key. Store this AES key with a small loader that run in Secure Vault, and encrypt this loader+AES key with the cell hardware key.
So, the only part that is system-specific is this small loader and AES key, you could fit into 128bytes of data. When the loader is decrypted and loaded into Secure vault, it fetch a block of the new firmware, decrypt with AES key and then begin the updating process.
Since is 128bytes only, you can store all possible variations only in 5GB of data. Even GT5 use only 15GB of BD-25GB, you have enought space.

Btw, if they can't use AES because it's not supported in hardware, they can implement RC4 in the small loader. It's so simple that you can implement it with a few istructions (http://en.wikipedia.org/wiki/RC4_(cipher)). Then with RC4 decrypt the crypto library and AES keys and then, with AES, the firmware
 
Why virtually impossible? You don't need to put an entire new metldr for every ps3.
You can encrypt the new firmware with a new AES key. Store this AES key with a small loader that run in Secure Vault, and encrypt this loader+AES key with the cell hardware key.
So, the only part that is system-specific is this small loader and AES key, you could fit into 128bytes of data. When the loader is decrypted and loaded into Secure vault, it fetch a block of the new firmware, decrypt with AES key and then begin the updating process.
Since is 128bytes only, you can store all possible variations only in 5GB of data. Even GT5 use only 15GB of BD-25GB, you have enought space.

Not make too much sense.
The currently hacked machines will stay hacked .
And it need only one CPU key to be able to capture the firmware (de-cap a cpu and see the code under a SEM)
Even if this method possible.
 
Can the PS3 BR read the BCA area of the discs?
From the other side,is the BCA part of the BR specification?

Oh,after a quick search:
http://www.museumstuff.com/learn/topics/Burst_Cutting_Area
On Blu-Ray Discs a Pre-recorded Media Serial Number PMSN can be stored in the BCA.
There is a sony pattent here :
http://www.faqs.org/patents/app/20090022044

So,IF the PS3 reader can read out the BCA,then they can make serial numbers for all discs,that they make (for the new ones mainly),and it making the life easy if they want to ban console which can play copy.

Interesting.And actually it make easy to connect permanently the games to the user-if they want to go on this road. (or they can define a few month block for re-sale in the case of the network games)


Even the AACS spec contain the BCA for BD
http://www.aacsla.com/specifications/AACS_Spec_CBHD_Prerecorded_0.90_20081007.pdf
It mention only the video discs,but by a high margin they will able to read it with the PS3
The question is that can they read it with the PS3 from the br drive?

It can contain 14 bytes of free data,or 20 bytes if they can use the whole are freely.
Not a GUID,but could be enough.
 
I went to the local pirated games guy to chk out on the scene and he says he's got these new USB dongles which keep you on 3.41 but fools the system into believing its 3.55 and, so, let you play online too ! Thats new to me!

Whats this new thingy ?
 
I went to the local pirated games guy to chk out on the scene and he says he's got these new USB dongles which keep you on 3.41 but fools the system into believing its 3.55 and, so, let you play online too ! Thats new to me!

Whats this new thingy ?

:oops:
 
Back
Top