Per Console Keys

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

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.

adrianc about hardware crypto

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).

More about efuses in general:

• Tonti_SSIRI_eFuse_V2.pdf
• reference

Source: gitbrew#otheros

Keys

per_console_root_key_0

• bootldr and metldr are decrypted with this key. See also Boot Order.
• Might it be obtained with per_console_root_key_1 ? It need more looked into. It might be the case, based on the behavior of the other derivatives known to be obtained through AES.

per_console_root_key_1 (EID_root_key)

• Derived from per_console_key_0
• Stored inside metldr
• Copied to sector 0 by metldr
• Cleared by isoldr
• Used to decrypt part of the EID
• Used to derive further keys
• Can be obtained with a modified isoldr that dumps it

Obtaining It

Launch the patched isoldr with your preferred method, let it be Option 1, or Option 2...

Option 1 - Dumper Kernel Module

• Modify glevand's spp_verifier_direct to dump the mbox to wherever_you_want.
• http://pastebin.com/uTBbnC9B <- needs to be edited further

insmod ./spp_verifier_direct.ko
cat metldr > /proc/spp_verifier_direct/metldr
cat dump_eid_root_key.self > /proc/spp_verifier_direct/isoldr
echo 1 > /proc/spp_verifier_direct/run
cat /proc/spp_verifier_direct/debug
hd /ls.bin | less

Option 2 - Dumper Payload

• http://pastebin.com/YwDKqgTj

*DO NOT CREATE AN MFW USING THIS IT WOULD BRICK

• Patched isoldr to dump it: http://www.wupload.com/file/1153650416/dump_eid_root_key.self <- dead link

• This can be loaded as the payload stage2 in the payload marcan used to load linux.
  • http://marcansoft.com/blog/2010/10/asbestos-running-linux-as-gameos/
  • http://git.marcansoft.com/?p=asbestos.git

• This can also be loaded as with lv2patcher and payloader3.
  • payloader3.git <- ?dead link ?

Comments

• What these SELFs do is dump the PS3 ISOLATED SPU LS through mbox, so you only need a way to catch this data with PPU code in lv2 environment aka a dongle payload or linux kernel.
• This has been tested and proven to work on 3.55 MFW.
• In the dump the remaining dump is the metldr clear code. metldr clears itself and all the registers then jumps to isoldr.
• Overwritting that code lets you dump your key + metldr.

per_console_root_key_2 (EID0_key)

Obtaining It

Using the reversed code

• This key can be obtained through AES from eid_root_key.
• The algorithm is located in isoldr.
• EID0_key can be gotten through a program such as openssl, using the following command (once installed):

openssl aes-256-cbc -e -in eid0_key_seed -out eid0_enc_seed -nosalt -K (isoldr key) -iv (isoldr RIV) -p -nopad

See Seeds.

Using anergistics (advanced users)

EID0 can be decrypted by setting EID0_key in anergistics and fireing aim_spu_module.self:

• Load aim_spu_module.self + EID0 + EID0_key in anergistics -> decrypted EID0.
• This code decrypts EID0 on PC.
• The prerequisites are:
  • Dump EID0 from your PS3.
  • Dump EID0_key from your PS3 and put it in the code above where the key (eid_mkey?) is needed.
  • Load all of them in anergistic.

Using similar steps, you can provide eid_root_key and obtain EID0_key:

• EID0_key can be obtained with eid_root_key directly by letting isoldr apply the algorithm in anergistic.
• It needs modifing anergistic to feed isoldr with eid_root_key.
• Patched aim_spu_module to dump EID0_Key:

*DO NOT CREATE AN MFW USING THIS IT WOULD BRICK

• • http://dl.dropbox.com/u/35197530/aim.self <- dead link

per_console_root_key_n

These are further derivations of the per_console_key_1 (EID_root_key).

See ps3_decrypt_tools by naehrwert, zecoxao and al..

cVTRM

SRK (Secret or Syscon Root Key - root hash secret (hsec)) (derivation from per console key?) is stored in Syscon along with SRH (Secret or Syscon Root Hash). SRK is used as HMAC hash to authenticate cVTRM data from flash. SRH is a hash of cVTRM data. SRH is computed at runtime and compared with SRH from Syscon.

You can fetch SRH with VTRM or SCM utilities from glevand's ps3-vuart-tools (you need to add the function to the tools to do so) or from GameOS directly if you do some patches at hypervisor level.

cVTRM uses SysCon Isolated Module to do all the cryptographic operations. It uses AES-CBC-128 to encrypt data. It seems like key is fetched from encrypted key table in Syscon (related to EID1?). Also this key can be computed using AES-XTS-128. IV contains all zeroes. Data and tweak keys for XTS are computed from eid_root_key using seeds from SysCon Isolated Module.

Here is an example of decrypted cVTRM blocks:

1B68B7B67048454E863ECA0665EFB086  1B68B7B67048454E863ECA0665EFB08670F3EADB (Drive Revocation List Hash)
70F3EADB96791F41F9A76F4D895DD582  96791F41F9A76F4D895DD5820DB108EC03D19250 (Content Revocation List Hash)
0DB108EC03D192500000000000000000
00000000000000000000000000000000

00000001000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000

087E91AEFFB8E66A0000000000000000  6AE6B8FFAE917E08 (PSN) Account ID
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000

00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000

• DEAD LINK Here's a link with the added functions. Please test it and report if it works :)