Editing Per Console Keys

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
= Explanation =
== naehrwert's blogposts - Individual Infos - December 24, 2011 ==
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/
== naehrwert's blogposts - eEID Cryptography - July 11, 2012 ==
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 their own…
Source: http://nwert.wordpress.com/2012/07/11/eeid-cryptography/
== Kaz about per-console keys derivation ==
<pre>
EID crypto is very complicated, it is done so on purpose by SCE.
First of all, EID0 is not decrypted with one key, and one algorithm alone. It is decrypted in several parts which use different algorithms and keys. The keys are all derivations of a per-console key (eid_root_key / per_console_key_1) which is stored inside metldr and copied by it to sector 0 and never
leaves isolation. per_console_key_1 is itself a derivation of per_console_key_0 which is used to encrypt metldr and the bootloader in the first place.
isoldr clears eid_root_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
operations are symmetric 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. It is not like you really need eid_root_key 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 eid_root_key. The final
key then decrypts a specific section of the EID0.
EID crypto is actually done smartly. That is because most of it originally comes from the CELL bootROM, as in it
reuses the same algorithms used for metldr binaries and bootloader in the EID crypto, including some of the keys and steps.
You cannot decrypt all of the EID sections unless you gathered every single keys and steps. There are a lot then you still have to figure out wtf you decrypted because EID is actually full of keys.
</pre>
== adrianc about hardware crypto ==
<pre>
I now know exactly how the hardware crypto works. I have confirmed the existence of eFuses and the OTP (bootrom) is real, aka the pre-bootldr. That is where you will find the most primary root key.
BootROM is not encrypted. You just can't see it (the CBE itself returns zeroes when you try to read it).
The eFuses hold the root key, which is 48bits, at Cell BE die, located in persistent storage.
IBM documents state "A unique 48-bit customer ID can be defined by the customer." (ie. in eFuses).
</pre>
More about efuses in general:
* [http://paris.utdallas.edu/ssiri08/Tonti_SSIRI_eFuse_V2.pdf Tonti_SSIRI_eFuse_V2.pdf]
* [https://www.psdevwiki.com/ps3/File:wdB8mFS.png reference]
Source: gitbrew#otheros
= Keys =
== per_console_root_key_0 ==
== per_console_root_key_0 ==


Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)

Templates used on this page:

Retrieved from "http://www.psdevwiki.com/ps3/Per_Console_Keys"