But... where is the key used with AES?

[jason]

AES obviously requires an encryption/decryption key, we know that this key is stored on the PSP itself, question is: Where? It's a symetrical encryption, therefore the SAME key is used for encryption and decryption, if only we could find the key, wherever it is, we could encode binaries (assuming there's no other protection to them)

[fwaggle]

what if (hypothetically) the key is random between software, and the key itself is encrypted as part of the software using a public/private key setup? it's my grossly under-educated opinion that it's pretty unlikely to have only "one layer to the onion" so to speak.

if you don't understand what i've just said, it could be because i'm half asleep, so i'll try again. the software is encrypted using a random AES key. the key is then encrypted using sony's private key, so that only people with the PSP's public key can decrypt it. they decrypt the AES key, and feed that to the AES-on-a-chip everyone's talking about.

snatching the key off the hardware of the psp is going to be pretty difficult given the fact that we can't even get our own userland program running yet, much less one that has unrestricted access to all the memory.

i dunno, just my silly 2 cents this evening. i'm half expecting this thread to be locked soon, because it sounds suspiciously like another one of those "oh my god why has no one thought of... ...yet" threads.

[jason]

what if (hypothetically) the key is random between software, and the key itself is encrypted as part of the software using a public/private key setup? it's my grossly under-educated opinion that it's pretty unlikely to have only "one layer to the onion" so to speak.

if you don't understand what i've just said, it could be because i'm half asleep, so i'll try again. the software is encrypted using a random AES key. the key is then encrypted using sony's private key, so that only people with the PSP's public key can decrypt it. they decrypt the AES key, and feed that to the AES-on-a-chip everyone's talking about.

snatching the key off the hardware of the psp is going to be pretty difficult given the fact that we can't even get our own userland program running yet, much less one that has unrestricted access to all the memory.

i dunno, just my silly 2 cents this evening. i'm half expecting this thread to be locked soon, because it sounds suspiciously like another one of those "oh my god why has no one thought of... ...yet" threads.

This is a possibility, and pretty much what the SSH protocol does, but it's unlikely that the secret key is in the SDK, so this would mean that Sony has to encrypt each and every PSP or PSAR, it's a big job, perhaps they have grant developers access to a shell server to encrypt their own binaries? If this is the case, congrats Sony, good work on the security of the PSP.

[mc]

This is a possibility, and pretty much what the SSH protocol does, but it's unlikely that the secret key is in the SDK, so this would mean that Sony has to encrypt each and every PSP or PSAR, it's a big job, perhaps they have grant developers access to a shell server to encrypt their own binaries? If this is the case, congrats Sony, good work on the security of the PSP.

It has been said that all official releases are sent to Sony for final QA tests, at which point they also encrypt the binaries. Compared to the QA verification, the actual encryption operation is next to no work at all.

[jason]

This is a possibility, and pretty much what the SSH protocol does, but it's unlikely that the secret key is in the SDK, so this would mean that Sony has to encrypt each and every PSP or PSAR, it's a big job, perhaps they have grant developers access to a shell server to encrypt their own binaries? If this is the case, congrats Sony, good work on the security of the PSP.

It has been said that all official releases are sent to Sony for final QA tests, at which point they also encrypt the binaries. Compared to the QA verification, the actual encryption operation is next to no work at all.

Therefore I would imagine that Sony is also testing the pre-games for buffer overflows etc. In this case, how come they didn't catch the Wipeout browser thing? Therefore, it's probably ok to conclude that owning the Sony SDK or Codewarrior (aka DevKit) is absolutely useless since Sony wouldn't encrypt our binaries anyway.

[Neil Stevens]

The "wipeout browser thing" is not a failure of the software. It's not a "buffer overflow" to hijack one's DNS. They couldn't do anything about that.

[jason]

The "wipeout browser thing" is not a failure of the software. It's not a "buffer overflow" to hijack one's DNS. They couldn't do anything about that.

What I mean is that they could just have told Wipeout's developers: "hey guys, this is lame, it's obvious that someone will setup a fake DNS server to redirect requests to one's httpd server."

[pixel]

What I mean is that they could just have told Wipeout's developers: "hey guys, this is lame, it's obvious that someone will setup a fake DNS server to redirect requests to one's httpd server."

And what could they have done about that ?

It's physically impossible to avoid such thing to happen.

And nevertheless, it's really not a harmful "hole" (I wouldn't call that a hole anyway)

[jason]

What I mean is that they could just have told Wipeout's developers: "hey guys, this is lame, it's obvious that someone will setup a fake DNS server to redirect requests to one's httpd server."

And what could they have done about that ?

It's physically impossible to avoid such thing to happen.

And nevertheless, it's really not a harmful "hole" (I wouldn't call that a hole anyway)

In any case, let's go back to the subject, if AES is encapsulated in a public key encryption scheme and each application uses a different AES encryption key, then the Codewarrior devkit is USELESS, as USELESS as the Sony SDK, they can simply just put it on a torrent, wouldn't matter since nobody but Sony owns the secret key, and I doubt they would be encrypting your linux kernels or whatever for that matter. Honestly, this is really smart of them, even if the SDK leaks, it's completely useless (not really useless if the PSP gets modded one day, but that's another matter, Sony learnt from their PS1 and PS2 mistakes, I doubt a mod is just going to show up before a long time, but once again this is out of topic and rather not interesting, but I wanted to make the point.)

It's very likely that Sony uses a public key encryption, especially since the RSA patent expired, so forget about your dreams of recompiling linux or whatever mame emulator with a leaked SDK, this ain't gonna happen buddy, the secret key is out of reach. Kudos to Sony for the "Security" of the PSP.

[Neil Stevens]

There really isn't any way around the DNS thing, unless you want to have no internet features at all. Hard-coding IP addresses is a pretty silly alternative, and even then one could use routing tricks to hack that, too!

[pixel]

It's very likely that Sony uses a public key encryption, especially since the RSA patent expired, so forget about your dreams of recompiling linux or whatever mame emulator with a leaked SDK, this ain't gonna happen buddy, the secret key is out of reach. Kudos to Sony for the "Security" of the PSP.

Well, don't forget the DS is known to crypt the roms the same way, and look at the current state of the "dsdev" by now.. ;)

[jason]

It's very likely that Sony uses a public key encryption, especially since the RSA patent expired, so forget about your dreams of recompiling linux or whatever mame emulator with a leaked SDK, this ain't gonna happen buddy, the secret key is out of reach. Kudos to Sony for the "Security" of the PSP.

Well, don't forget the DS is known to crypt the roms the same way, and look at the current state of the "dsdev" by now.. ;)

I sincerely hope that Sony will release Linux/PSP or NetBSD/PSP as they did for the PS2 or something similar as Yarose for the PS1, what should we do to push them this way?

[morbo]

Well, your best bet is to understand your quest. Sincerest good luck here. Its a 90nm device. Just all the best luck really. How is your budget?

http://www.chipworks.com Search for this overview:

Sony CXD2962GG Processor with Embedded DRAM Chiptease Analysis (CTR-0501-001)


Manufacturer: Sony
Part Number: CXD2962GG
Device Type: Microcontroller


What's Inside This Report:

60 nm gate length logic transistors, low-k dielectrics confirms the part to be made using Sony's 90 nm process. The part includes embedded DRAM using trench capacitors.

* table of metal dimensions
* SEM images of logic transistor
* minmum pitch metal 1
* general image
* package and die photos


Who Should Buy This Report:

* Manufacturers of 90 nm mobile devices


Report / Device Description

The CXD2962GG is a 90 nm technology node CMOS processor that incorporates embedded DRAM. It was removed from a Sony Portable PlayStation (PSP).

[fwaggle]

What I mean is that they could just have told Wipeout's developers: "hey guys, this is lame, it's obvious that someone will setup a fake DNS server to redirect requests to one's httpd server."

And what could they have done about that ?

It's physically impossible to avoid such thing to happen.

And nevertheless, it's really not a harmful "hole" (I wouldn't call that a hole anyway)

actually what they could have done is included public keys for the SCEA servers inside the wipeout browser code, then use https and "bob's your uncle" - no more spoofed scea websites.

the simple answer to the "hey guys, this is lame" thing is it was overlooked. it happens, even with strict quality assesment.

sorry for the late reply ;)

fwaggle

[biohazd]

---Too many 'if's...---
If it turns out that developers can directly distribute code (i.e. expansions for existing games) to the consumer, without needing sony to encrypt data for them, then the most likely scheme is to use AES, encrypt the key using RSA and tag it somewhere in the binary.

If this is indeed the case, then it's reasonable to assume that developers will have a 'public key' (and i mean public for licensed dev's) with which to encrypt the AES key and the PSP will have the 'Private Key' for decryption. We can assume that this would be pretty secure because pulling the Private key from the firmware (if it is stored within firmware...) would itself require the Private key in the first place to decrypt said firmware update. Remember, i don't think sony would go to much trouble simply to stop people from encrypting their own code. Rather the system is in place to protect the licensed code from being decrypted, thus protecting the developer's intelectual property.

If this turns out to be the case, then a full SDK may provide the Public key used to encrypt the data, enabling someone to create valid encrypted code while still protecting the developer's intelectual property.

---An alternative---
On the other hand, if it turns out that all code passes through sony's 'inner circle' then they could easily do without RSA entirely and simply use a set AES key that is both used for encrypting the data at sony HQ and hard-wired into the crypto hardware on the PSP, negating the need to include the AES key in an obfuscated form along with the encrypted data.

[Shine]

---Too many 'if's...---
We can assume that this would be pretty secure because pulling the Private key from the firmware (if it is stored within firmware...) would itself require the Private key in the first place to decrypt said firmware update.

I don't understand this. If a developer could crypt their own programs for running on normal PSPs, then the firmware is executed and perhaps could be read. But as noted in other threads, there are special developer PSPs, which can execute only unencrypted programs and if you want to distribute a program, Sony has to encrypt it and this is done with a private key at Sony, I think. It would be pretty secure from Sony to assume that someone can decrypt the firmware, reverse engineer all chips and getting the public key from the firmware or the hardware. But even with all this information there is still no way to encrypt own programs, so it doesn't matter if you decrypt everything, you can't use this intellectual property without a way to execute it on normal PSPs.

[Naibas]

---Too many 'if's...---
If it turns out that developers can directly distribute code (i.e. expansions for existing games) to the consumer, without needing sony to encrypt data for them, then the most likely scheme is to use AES, encrypt the key using RSA and tag it somewhere in the binary.

When you say "expansions for existing games", I think you are thinking too much like these are PC games. It seems highly unlikely that any PSP game would download and run R4000 binaries, mostly because that's just too much work. You'd either have to a) get an executable that runs off the memory stick (encrypted by Sony, no doubt, which would only happen after another long, painful run through the QA hoops), or b) write a loader that runs while your game boots up, and have it find new executable code on the mem card and then dynamically load it in place of the old code. That is also a lot of work.

It seems much, much, much more likely that the developers simply read external data files (off the mem stick, of course). These files would most likely be a custom binary format, capable of storing whatever they need (images, audio, video, scripting languages, shaders, whatever). They already have to do this anyways to load up the content that ships with the game off the disc, so all the tools are probably already in place.

Then it's easy to author content later on, and possibly even provide authoring tools to the end user. Because it's raw data, it can be in any format that makes them happy, and doesn't have to conform to the Sony hardware executable encryption. I bet that developers don't ever see the encryption process, that it's something that happens on the consumer PSP before their code even runs. I bet they don't code for it and they don't think about it, and that Sony encrypts the files, and the hardware just verifies and decrypts, and then the original executable lands in memory and is run.

Of course, most of this is speculation, but it's educated speculation, and makes the most sense, given how these things have worked in the past and how developers operate.

[lmx]

raw read and rite is tomemory card is dissallowed by sony, all save data passes through encryption. So even if a developer wanted to read raw, tis not possible. might as well use crayons to get data into psp memory. all keys in hardware, no referene to them in software I would imagine to be safe

[fwaggle]

Then it's easy to author content later on, and possibly even provide authoring tools to the end user. Because it's raw data, it can be in any format that makes them happy, and doesn't have to conform to the Sony hardware executable encryption.

raw read and rite is tomemory card is dissallowed by sony, all save data passes through encryption.

i think Naibus is referring to the data after it's come out of the savegame API.

[fireether]

raw read and rite is tomemory card is dissallowed by sony, all save data passes through encryption. So even if a developer wanted to read raw, tis not possible. might as well use crayons to get data into psp memory. all keys in hardware, no referene to them in software I would imagine to be safe

Is there hard proof of this?

I dont agree because if you look at the PSP, you will see there is a MP3 player, picture viewer, among other applications. Yes, those were coded by sony, but..

Its easier to use the same API for everything, instead of having two different API's. While sony could have done some tricks to do raw read/writes (tricks not allowed or shown to developers) - or even disabled the part of the API that allows raw read/writes.. I think that most likely they told the developers to stick to the encryption, but the developers will also have the option to do raw read/writes.

I could be wrong, but in my thinking - in order to keep the PSP flexible to future potentional applications, its easier to allow raw read/writes.

One example is GPS software. If a developer makes the GPS software, they may want to do raw read/writes for some purposes.. I.e. allow extra maps to be downloaded and stored on the memory card.

Again, I dont have any proof for or against. But would like to know if there is any.

[lmx]

So even if a developer wanted to read raw, tis not possible.

I take that ludricrous statement back. developees can probably dump data on the stick. it would probably fail trc, but I guess homebrewers would get fed up of the trc process pretty quick.

[BlackDayz]

Tony Hawk's pro skater allows you to use a jpg to put on a skater's face. If they don't allow the data to be read raw, couldn't the AES key be reverse engineered by using the jpg as a control file to figure out the AES key? That's if data needed to be imported using the AES API.

[Neila]

BlackDays, where does the game take the image from?
the Photo directory?

[Vyrus001]

i wonder if that would do any good though, because if the image is crypted to be used in the game then why would it save the crypted image some where on the memory card or in the game save? would the encrypted vers of the image not just be deleated on game exit ?

[neonenergy]

Tony Hawk's pro skater allows you to use a jpg to put on a skater's face. If they don't allow the data to be read raw, couldn't the AES key be reverse engineered by using the jpg as a control file to figure out the AES key? That's if data needed to be imported using the AES API.

First we have to read that temporary data on the memory, which once we have, gives us about ten bajillion years to find the real encryption. Also i dont believe that the jpeg has to be encrypted for in game use, it could be accessed directly via some api function.

[BlackDayz]

Yeah, in THUG2 remix you just drop a 128x128 jpg with 8-bit color in the photo directory. The reason I brought this up was just a possible source file for comparison to possibly figure out the AES key, or at least get a better understanding of it. Th real question (in my mind) is where would you look for it? Ack! Anywho.

[EdZ]

I severly doubt the unencrypted jpeg would be encrypted just so it can be stored in memory. Msot likely it would just be shunted straight from the Memory Stick to the PSP's memory, then displayed. No encryption needed.

[Neila]

then probably encrypted saved with a whole bunch of other data... which will render the attempt useless
so it's a no-go

[Krevnik]

Well, there are two weaknesses to this:

1) If they use RSA at some point, the public key is vulnerable and can be attacked through generation of prime numbers and attempting to find the factors. This is somewhat slow, but possible, although getting your hands on a public key is needed... The thing is, RSA works through having the public key actually CONTAIN the secrets (two large primes), just multiplied together to form a huge value.

2) If they use AES exclusively, then because of size/etc, an attack is actually more difficult. HOWEVER! There is still a huge weakness through the v1.00 firmware which allows us to run code. Now, if we could trigger the PSP to encrypt some KNOWN data out as a save file such as an arbitrarily long unique string (HINT, HINT! *COUGH COUGH*), you can attack AES by knowing both the encrypted and unencrypted forms. The process and both data forms would then be known, and you could derive the key that way through some work.

This is not an insurmountable task... and with the Hello World app out, we might have a chance, especially if AES-128 is all that is used (likely since Sony does the encryption themselves).

Edit: You know what, nevermind... I was blowing hot air on the AES stuff, as there is too much dynamic movement of data to accurately use a plaintext attack on AES itself to reveal the key. Best we can do is effectively reduce the number of rounds in the cipher to reduce the search space a little. Seems the best solution is to get a leak or extract the key. However, because someone has managed to rip apart these suckers, have they noticed an FPGA which might be doing the encryption?