PSP Encryption Key

[Sirwhizz]

Long time reader first time poster. I haven't seen this on this forum yet, so, I found this at another forum. I thought a conversation here might be good.

EdwardFMA at psp-linux.org found it

While exploring the 1.0 Firmware Dump i came across these Public keys

\flash0\data\cert\Class1_PCA_G3_v2.cer
QUOTE
VeriSign Trust Network
© 1998 VeriSign, Inc. - For authorized use only
Class 1 Public Primary Certification Authority - G2
VeriSign, Inc.
US

RSA(2048 bit)

30 81 89 02 81 81 00 aa d0 ba be 16 2d b8 83 d4 ca d2 0f bc 76 31 ca 94 d8 1d 93 8c 56 02 bc d9 6f 1a 6f 52 36 6e 75 56 0a 55 d3 df 43 87 21 11 65 8a 7e 8f bd 21 de 6b 32 3f 1b 84 34 95 05 9d 41 35 eb 92 eb 96 dd aa 59 3f 01 53 6d 99 4f ed e5 e2 2a 5a 90 c1 b9 c4 a6 15 cf c8 45 eb a6 5d 8e 9c 3e f0 64 24 76 a5 cd ab 1a 6f b6 d8 7b 51 61 6e a6 7f 87 c8 e2 b7 e5 34 dc 41 88 ea 09 40 be 73 92 3d 6b e7 75 02 03 01 00 01


\flash0\data\cert\Class1_PCA_G3v2.cer
QUOTE
VeriSign Class 1 Public Primary Certification Authority - G3
© 1999 VeriSign, Inc. - For authorized use only
VeriSign Trust Network
VeriSign, Inc.
US

RSA(2048 bit)
30 82 01 0a 02 82 01 01 00 dd 84 d4 b9 b4 f9 a7 d8 f3 04 78 9c de 3d dc 6c 13 16 d9 7a dd 24 51 66 c0 c7 26 59 0d ac 06 08 c2 94 d1 33 1f f0 83 35 1f 6e 1b c8 de aa 6e 15 4e 54 27 ef c4 6d 1a ec 0b e3 0e f0 44 a5 57 c7 40 58 1e a3 47 1f 71 ec 60 f6 6d 94 c8 18 39 ed fe 42 18 56 df e4 4c 49 10 78 4e 01 76 35 63 12 36 dd 66 bc 01 04 36 a3 55 68 d5 a2 36 09 ac ab 21 26 54 06 ad 3f ca 14 e0 ac ca ad 06 1d 95 e2 f8 9d f1 e0 60 ff c2 7f 75 2b 4c cc da fe 87 99 21 ea ba fe 3e 54 d7 d2 59 78 db 3c 6e cf a0 13 00 1a b8 27 a1 e4 be 67 96 ca a0 c5 b3 9c dd c9 75 9e eb 30 9a 5f a3 cd d9 ae 78 19 3f 23 e9 5c db 29 bd ad 55 c8 1b 54 8c 63 f6 e8 a6 ea c7 37 12 5c a3 29 1e 02 d9 db 1f 3b b4 d7 0f 56 47 81 15 04 4a af 83 27 d1 c5 58 88 c1 dd f6 aa a7 a3 18 da 68 aa 6d 11 51 e1 bf 65 6b 9f 96 76 d1 3d 02


\flash0\data\cert\Class1_PCA_ss_v4.cer
QUOTE
Class 1 Public Primary Certification Authority
VeriSign, Inc.
US

RSA(1024 bit)
30 81 89 02 81 81 00 e5 19 bf 6d a3 56 61 2d 99 48 71 f6 67 de b9 8d eb b7 9e 86 80 0a 91 0e fa 38 25 af 46 88 82 e5 73 a8 a0 9b 24 5d 0d 1f cc 65 6e 0c b0 d0 56 84 18 87 9a 06 9b 10 a1 73 df b4 58 39 6b 6e c1 f6 15 d5 a8 a8 3f aa 12 06 8d 31 ac 7f b0 34 d7 8f 34 67 88 09 cd 14 11 e2 4e 45 56 69 1f 78 02 80 da dc 47 91 29 bb 36 c9 63 5c c5 e0 d7 2d 87 7b a1 b7 32 b0 7b 30 ba


There are much more Certificate's in 1.0 Firmware if you would like me to post them just say. Now about these public keys they can be reverse engineered to make a private key.

I hope it is helpful.

[Drakonite]

You really need to go read up on public key encryption...

[Sirwhizz]

You really need to go read up on public key encryption...

I have been doing that. I just thought since no one has talked about it here especially since someone has found the keys that it might be useful information on this forum.

[Drakonite]

They are public keys, and some members of these forums have had them for quite a while, not that it matters.

The whole purpose of public key encryption is so that you can give out a public key and it doesn't comprimise the private key.

Having the public key really does not help towards a private key at all. You don't even know exactly what these keys are for.

[Sirwhizz]

I know you cannot get a private key out of a public key. Sony has the private key and the only way to get that if it is leaked or some good hacking is done.

Like I said I didn't know if anyone have seen them before. I just thought some people might of wanted to look at them.

Just something that might get people to talk about or think about

[mrbrown]

Certificates aren't really that interesting since the ~PSP file format isn't signed using these certificates. Chances are they are used by the SSL library.

[Sirwhizz]

Thanks for the insight. I kinda figured that out. I know Sony is smart, but they might have goofed up somewhere. We just have to find it. They did screw up on the 1.0 firmware by letting it run unsigned code and made updates fast. I wish I knew what minor change is between 1.5 and 1.51. I have a lot of programming behind me. I used to do encryption programming as a hobby, because I knew one day it might come in handy for when I got a real job which I have now.

[Marco_N]

What would be nice is to find the encryption key for the v1.00 firmware, that way it can be broken open and disassembled (if you're in a country where reverse-engineering is legal).

The PSP uses two things:
- digital signatures -> public/private key pair
- encryption (128 bit AES)

Since the digital signature private key is out of the question for now, has anybody tried to "do what a PSP does" when it boots up and tried to decrypt firmware .prx files?

[mrbrown]

Since the digital signature private key is out of the question for now, has anybody tried to "do what a PSP does" when it boots up and tried to decrypt firmware .prx files?

Yes. ~PSP files are decrypted using hardware, the key(s?) is never in the clear.

It's also unknown (and unlikely) if the PSP hardware can be used to encrypt ~PSP files.

[steddy]

Given that encryption is done using symetric keys and its pretty stupid to rely upon a single key for all files, isn't it likely that the key is stored in the file that is encrypted but is hidden via public / private key crypto.

I will be looking at my kernel dump tonight to try and work some of this out. From your postings its obvious you have some knowledge of how this works already :)

Steddy

[Sirwhizz]

What would be nice is to find the encryption key for the v1.00 firmware, that way it can be broken open and disassembled (if you're in a country where reverse-engineering is legal).

The PSP uses two things:
- digital signatures -> public/private key pair
- encryption (128 bit AES)

Since the digital signature private key is out of the question for now, has anybody tried to "do what a PSP does" when it boots up and tried to decrypt firmware .prx files?

The keys above are from the 1.0 firmware. Here is the link to the other forum

http://www.psp-linux.org/forums/index.php?showtopic=434

I do think Drakonite is right on

They are public keys, and some members of these forums have had them for quite a while, not that it matters.

The whole purpose of public key encryption is so that you can give out a public key and it doesn't comprimise the private key.

Having the public key really does not help towards a private key at all. You don't even know exactly what these keys are for.

I think the encryption on the PSP is hardware too, because software would be to slow and would create a lag in playing a fast game, but I might be wrong.

[mrbrown]

Given that encryption is done using symetric keys and its pretty stupid to rely upon a single key for all files, isn't it likely that the key is stored in the file that is encrypted but is hidden via public / private key crypto.

No. Consider that the PSP hardware already has at least one key that is used to decrypt any content keys (keys used over portions of the ~PSP file). Sony only has to sign the content key with the private key at Sony, and the PSP hardware decrypts that content key in hardware and uses it to decrypt the rest of the file.

Now I've looked at the code, and there isn't much to gain as a huge part of it is done in hardware. I could be wrong about the methods used, but this is how MagicGate worked on the PS2 - content keys signed by an inaccessible hardware key. They also used ICVs over each "block" in the file, which is why I alluded to checksums in a previous thread.

You should check out the book on cryptography, Bruce Schneier's Applied Cryptography. It will open up a whole host of other secure transmission methods to you besides public key encryption :).

[steddy]

No. Consider that the PSP hardware already has at least one key that is used to decrypt any content keys (keys used over portions of the ~PSP file). Sony only has to sign the content key with the private key at Sony, and the PSP hardware decrypts that content key in hardware and uses it to decrypt the rest of the file.

Aren't we saying the same things but using different terminology? A signature doesn't encrypt anything it just proves that its authentic. I think by this you mean the session key stored in the file (content key) is encrypted by the Sony private key. Since signing is a process whereby a hash is encrypted by the private key, you are calling this a signature.

This is the same as I am stating if thats what you mean. Each file is encrypted with a random session key, and the key is then encrypted by the Sony private key and stored in the file. The public key which is in ROM (not on the Flash0: device) decrypts the session key then uses it to decrypt the file.

You should check out the book on cryptography, Bruce Schneier's Applied Cryptography. It will open up a whole host of other secure transmission methods to you besides public key encryption :)

I am very familiar withs Bruces work and think its a fanastic explanation of crypto. Anybody that hasn't read it should. They should also sign up to his free crypto newsletter. He wrote a follow-up called 'Secrets and Lies' which is a public apology for the first book. It explains that even though crypto can be perfect, the people and processes around a system always mean it can never be 100% secure.

Thanks for the info on the ICV's, useful stuff. OK, onto Winhex and Ps2dis I go :)

[mrbrown]

If it helps you then take what I said to mean that the content key (which is not a session key) is encrypted with the hardware key, which is never in the clear. Which means that the content key is also never in the clear.

You are still on about public key encryption. I'm talking about a single key being used in the transimission stream, encrypted with a key that is not in the transmission stream.

[steddy]

Ok. Two things then. First, is the content key different for all files and is it a symmetric key? If the answer to both of those is yes, then its a session key (ie the session represents that one instance of the file).

Second, s the Hardware key symmetric? Does Sony encrypt the content key with the same key as the PSP decrypts it with? If the answer is no then its a public / private key pair. If the answer is yes then it would be VERY useful to discover what that key is, even if its in hardware. With its knowledge we could encrypt and sign our own binaries (in my view unlikely).

On a side note, do you know how this is addressed in hardware? Is it via the COP functions and if so do you know which ones?

Steddy

[nanoscopic]

Maybe the keys are not useful to encrypt or sign data... but aren't they useful for decrypting the encrypted 1.5 update?

[Marco_N]

I think I have to agree with mrbrown that it's more like a content key than a session key; a session key is usually created at random for the purpose of setting up a secure channel and then through some key exchange mechanism both sides agree on it. It's obvious that a UMD can't generate keys at random, so "the key" or keys are always fixed which would make it more into a content key like on DVD-Audio. A disc key can be used to unlock file keys, etc.

Let's assume that the key that's in UMD_DATA.BIN (offset 0x0B) is the media key. What if the specialized hardware in the PSP takes this media key and does a decrypt round or rounds on it with the 'hidden' public key. This is the "real" media key. With the "real" media key it unlocks the 0xPSP files. This "real" media key can be hidden on a little bit of RAM that's on the hardware and be valid as long as the UMD is in the drive.

It makes sense that this hardware is accessible by the UMD controller, but it also works from Memory Stick (i.e. Updater) and from internal ROM (Firmware). Perhaps there's some secure computing mode that all i/o is passing through this hardware.

Because of the nature of this board, I think we better leave the UMD alone and concentrate on the Memory Stick. On the Updater there is no xxx_DATA.BIN, so there would be no media key. Perhaps the key is hidden in the PSAR file?

[gsa]

Hi,

I would say there is no such thing as a "UMD media key" particular to each disk - encrypted system PRX files present in more than one UMD do not vary from one UMD to another (e.g. if they are encrypted, they are encrypted using the same key.)

My guess is that each "~PSP" file contains the key which has been used to encrypt it, probably encrypted with the hardware protected key before being put there.

The alternative is for the file to be encrypted directly using the hardware protected key, thus no key stored in the file - but much less security.

gsa

[mrbrown]

My guess is that each "~PSP" file contains the key which has been used to encrypt it, probably encrypted with the hardware protected key before being put there.

Bingo! Thanks for putting it in clearer words than I could :).

[steddy]

Bingo! Thanks for putting it in clearer words than I could :).

Good, and thats what I am saying too. Only I am saying that the hardware key is a Public key and the one it was encrypted with is a Private key. If that wasn't the case we could encrypt our own executables to run on a 1.5.

Steddy

[gsa]

Hi,

If that wasn't the case we could encrypt our own executables to run on a 1.5

That would be the case if we had access to the key used to encrypt the executables, that is:

* If asymmetric encryption (AE) is used, it is at the manufacturer secret signing/encrypting lab :)

* If symmetric encryption (SE) is used, the decryption process occurs inside the hardware and the only way to get the key from there seems to be to peel the chip

Only I am saying that the hardware key is a Public key and the one it was encrypted with is a Private key

I agree that AE is used, as it provides higher protection to the manufacturer, but I can not guess which part of the key pair is stored in the hardware - not that it matters:

* If SE is used, a compromise of the hardware key is fatal

* If AE is used, then the key stored in-hardware is used to decrypt whatever it is fed (signature or encrypted blob). A compromise of the hardware key is non-fatal, as you still need the key used to encrypt the data - and you can not derive one from the other. A successful attack would require modifying the in-hardware key, probably by replacing/simulating the chip altogether.

Given the facts I go with AE - it seems that the chip stripper was not such a good investment after all :P

So, to sum it up, my guess at the PSP encryption process is:

Kh = AE-key stored in hardware
Ks = AE-key stored at the manufacturer (Kh counterpart)
Kc = SE-key randomly generated for each file

Encryption process at the manufacturer:

1. Generate Kc and SE-Encrypt BOOT.BIN with it
2. AE-Encrypt Kc using Ks
3. Maybe use a HMAC with Kc for integrity verification
4. Stuff everything into EBOOT.BIN

Decryption process at the PSP:

1. Extract Kc by AE-Decrypting with Kh
2. Decrypt the file using Kc
3. Maybe verify integrity by using the HMAC with Kc
4. Run :)

Please feel free to prove me wrong, as it is I believe the best bet is to try to find out how the PSP1.0 ran plain ELFs (the fix in 1.5 is software based, it can probably be reversed) or find out how to reflash a 1.0 firmware.

All references to hardware-based encryption are based on the findings of other people in here, I do not have a 1.0 kernel to even start looking at it... (sigh)

gsa

[steddy]

I agree with everything you said GSA, thats exactly how I think it all works too.

With regard to 1.0 PSPs, I think the hardware decryption will be handed by a COP type coprocessor. If thats the case the 1.0 PSP simply didn't require the executable to be encrypted so it didn't pass it by the decryption circuit.

Since not all files are encrypted (e.g. images) its not a automatic hardware decode of any file that loads from anywhere. Its much more likely the LoadModule function checks for a ~PSP header and if it finds one then uses the COP functions to decrypt the key and then decrypts the rest of the file.

I think this is something that can be turned off on a 1.5 if the appropriate place in the kernel bootblock is found, but it would require us to be able to run unsigned code on a 1.5 to do it.

Steddy

[Mangus]

well, i kinda doubt this will help much due to the fact it is common sense but:

ok normally decryption works like this |Encrypted FIle|/|Key(Public and Private)| = |Decrypted File|

which in the form of a simple algebraic formula is z/y1(y2)=x

well just like in algebra when you have two variables and need the other(s) you flip the formula around:

z/x=y1(y2)

see z is encrypted, x is decrypted and the y's are the different keys needed (i'm not so sure how the whole y thing would work out to look in true terms but this helps to illustrate my point anyway.)

basically if we could create a program that would take two files one encrypted by sony and the other unencrypted (possibly obtained through a ram memory dump) and we use a decyption method that will does the decyption backwards (is made to start with decrypted file and figure out pattern of encryption till a key(s) is found).

Just a thought, but seeing as reversing the decryption process this way could be highly improbable, this might never happen.

[ripnet]

i belive it involves factorzing the product of 2 large primes - thats why its impossible (read very difficult / time consuming) to reverse it... Its very easy to multiply 2 primes to make a large number Z but to find out which 2 primes multiply together to make Z involves a brute force search, and the encrpytion is designed such that such a search would take an impossibly long time using todays computers. I think we would be much better off trying to 'lift' the bootstrap and descryption code from the PSP (maybe by directly reading the flash rom). Also the encrpytion used (aes?) is known not to be suspectable to plaintext attack. George

[Krevnik]

RSA is pretty strong, and the key sizes used are pretty ugly (2048-bit used to be considered military grade back in the mid-90s, and RSA hasn't gotten too much weaker in the long-term).

However, many key generators have weaknesses, and pose to be a problem at times. While this isn't common anymore, there used to be quite a few sloppy generators that would try to find two primes close to each other to get as close to the desired bit-length as possible. *Whoops*... Do a /really/ fast square-root estimation and start counting backwards in your brute-force search and you would find an answer pretty quick.

RSA's biggest flaw is that you don't need anything but the public key to attempt a crack. No data, nothing... you will know the answer is correct the moment you factor n. Unfortunately... 1024-bits is still a very large search space, and prime generators aren't very fast yet.

[ripnet]

Just out of interest, I would like to see something along the lines of "If we can factorize 2349874395782349652395239523652352376578234653245273465 we have cracked it"... i think it would be clearer with real numbers than in terms of 64 bits...

I dont think we are even certain of the alogrithm used on PSP yet, let alone a t the stage where we have reversed the boot loader to find out the maths it applys to check the digital sig...
George

[MindWall]

just some info that may help:

Encryption - 128bit AES
AES info: http://www.quadibloc.com/crypto/co040401.htm
(description of AES including possible attack, thanx for link-update Lex)

RSA Security Solutions Adopted for PSP™:

"RSA Security Inc. (NASDAQ: RSAS) announced today that it has licensed RSA BSAFE® Secure Sockets Layer (SSL) and public key infrastructure (PKI) products to Sony Computer Entertainment Inc. (SCEI), to provide a secure interactive environment for software title developers and publishers creating game titles for its new PSPTM (PlayStation® Portable) handheld entertainment system. "

http://www.rsasecurity.com/press_releas ... oc_id=5648

basic structure:
http://www.rsasecurity.com/products/bsa ... S_0503.pdf

More detailed BSAFE Cert-C Micro Edition:
https://eval.rsasecurity.com.au/downloa ... index.html

Internet-Drafts (public documents made availabe from RSA itself, now expired as specifications, but not tottaly useless to us)
BSAFE (1999):
http://quimby.gnus.org/internet-drafts/ ... afe-00.txt
TestCases:
http://quimby.gnus.org/internet-drafts/ ... est-00.txt

http://pc.watch.impress.co.jp/docs/2004 ... gai_3a.gif

[Lex]

Working AES-Encryption Link (see MindWalls post, 1up):
http://www.quadibloc.com/crypto/co040401.htm

[AuDioFreaK39]

on the diagram listed above...is there a way to make the psp not go through the AES Encryption process, and go directly to everything else?

[spikesp]

That's easy, just take an eraser and remove the wire between AES Crypto and IO bus.