Talk:Per Console Keys

From PS3 Developer wiki
Jump to: navigation, search

naehrwert's blogposts[edit]

Individual Infos - December 24, 2011[edit]

One of the PS3′s console specific cryptography works as follows:

At factory time there is a console specific key generated, probably from a private constant value and a console specific seed. Maybe that’s the key used for encrypting bootldr and metldr. Fact is, that metldr stores another console specific keyset (key/iv) to LS offset 0×00000. That keyset is probably calculated from the first one. At factory time the isolated root keyset (how I call it) is used to encrypt the console’s “Individual Infos”, like eEID. But not the whole eEID is encrypted the same way, special seeds are used to calculate key/iv pairs for the different sections. And not even that is true for every eEID section, because for e.g. EID0 another step is needed to generate the final section key(set). Each of the isolated modules using such an “Individual Info” has a special section that isoldr uses to generate the derived key(set)s. But the generation works in a way, that the section data is encrypted with aes-cbc using the isolated root keyset, so it is not possible to calculate the isolated root keyset back from the derived key(set)s, because aes shouldn’t allow a known plaintext attack. So far I can decrypt some of EID0′s sections, EID1, EID2 and EID4. EID5 encryption should be similar to EID0′s but I lack the generation keys for that one.

Source: http://nwert.wordpress.com/2011/12/24/individual-infos/

eEID Cryptography - July 11, 2012[edit]

When metldr is encrypted at factory, a special keyset is set in the binary before encryption. Later when an isolated loader is loaded by metldr, it will copy the keyset to LS offset 0x00000. It consists of eid_root_key and eid_root_iv. To not having to use the same key for all eEID parts, several subkeys are generated from special data called individual information seed. These seeds are stored in the metadata header of isolated modules loaded by isoldr. When isoldr will load a module, it will call a subroutine that encrypts each seed chunk (0x40 bytes) using eid_root_key and eid_root_iv. Then the so-called individual infos are passed in registers r7 to r22 (= 0x100 bytes in total) to the loaded module where they are used further. Usually isolated modules have a seed section of 0x100 bytes but all of them (except sb_iso_spu_module) have all zeroes but the first 0x40 bytes chunk. You can, for example, find the recently published EID0 seed in the metadata section of aim_spu_module. Appliance info manager is used to get e.g. the target ID or the PSID from EID0. This explains why the seed can also be found in isoldr directly, since that one is checking EID0 too.

As you can probably think, a fair amount of reversing time and knowledge has gone into finding this, so stop calling us *swearwords* for not releasing information that could potentially lead to more piracy, because we think that this would do more harm to the “scene” than just keeping some information in private (for now). Also I can only encourage everyone that thinks about us this way or is greedy demanding for developers/reverse engineers to release their stuff, to fire up isoldr in IDA or disassemble it with objdump and try to reverse all this from start to end. We’ll see, who is able to pull this through on his own…

Source: http://nwert.wordpress.com/2012/07/11/eeid-cryptography/

Kaz very kind explanation[edit]

EID crypto is very complicated, it is done so on purpose. first of all EID0 isn't decrypted with one key, and one 
algorithm alone. it is decrypted in several parts which use different algos and keys. the keys are all derivations 
of a per console key (per_console_key_1)which is stored inside metldr and copied by it to sector 0 and never 
leaves isolation. that same key is a derivation of the per console key (per_console_key_0) used to encrypt metldr
 and the bl in the first place as well.

isoldr clears that key from sector 0 before jumping to the isolated module. but before doing so it encrypts it 
with another keyset and stores it in a buffer so that the isolated module can use the new crafted key. since the
operation is AES, if you know that keyset you can decrypt the crafted key and get the eid root key without pwning
a loader or metldr through an isolated module. that is not like you really need it because you can already use the
crafted key to decrypt some of eid0, but not all of it. and the crafted key also uses the first elf section to be 
built as in your isolated module will have a small section which only contains a key. and that key is used as another
layer by isoldr to encrypt the buffer with it. so basically you have 2 encryption layers over the root key. the final 
key then decrypts a specific part of the EID.

eid crypto is actually done smart. that is because most of it originally comes from the cell bootrom, as in they 
reuse the same algo used for metldr binaries and bl in the eid crypto, including some of the keys and the steps. 
and you cannot decrypt all of the eid sections unless you gathered every single keys and steps. and there are a 
lot then you still have to figure out wtf it is you decrypted because eid is actually full of keys.

adrianc about hwcrypto[edit]

...
and i now know exactly how the hw crypto works
i have confirmed the existence of efuses
and the OTP (bootrom) is real aka the prebootldr
thats where you'll find the root key
bootrom is not encrypted, you just cant see it (the CBE itself returns zeroes when you try to read it)
and the efuses hold the root key, which is 48bits

@ Cell BE die, located in persistent storage

ibm docs state "A unique 48-bit customer ID can be defined by the customer." (in efuses)

more about efuses in general: http://paris.utdallas.edu/ssiri08/Tonti_SSIRI_eFuse_V2.pdf reference