Kirk

The PSP KIRK Crypto Engine is a security hardware device that is embedded into the TACHYON main IC chip. It is a bus master and can DMA to/from main DDR RAM memory, operating independantly of the CPU. It is interfaced via memory mapped registers at base of 0xBDE00000 (SPOCK Crypto Engine on the other hand is mapped to 0xBDF00000). It is capable of performing AES encryption, decryption, SHA1 Hash, pseudo random number generation, and signature generation and verifications (ECDSA) and CMAC.

All (or almost all) the static keys used by the engine (plus the private key for Kirk command 1) have been found through the PS3 hacks or glitching and can be found on the Keys page.

Invocation

All of the Kirk commands can be used using the function sceUtilsBufferCopyWithRange, which takes five arguments:

• the output buffer (if there is one, NULL otherwise)
• the output buffer size (if there is one, 0 otherwise)
• the input buffer (if there is one, NULL otherwise)
• the input buffer size (if there is one, 0 otherwise)
• the index of the command (as detailed below).

Elliptic curves

The PSP uses ECDSA for public-key cryptography. Elliptic curves are known for being fast and only requiring small keys, contrary to other public-key cryptography algorithms. They are still considered to be very secure, even for the 160-bit curves used by the PSP, unless a mistake is made when using them.

These curves have been designed by Sony only for the console. They are not vulnerable to any known attack.

Both use the usual Weierstrass form.

Elliptic curve for Kirk command 1

This curve is used for the ECDSA verification of Kirk command 1.

p = 0xFFFFFFFFFFFFFFFF0001B5C617F290EAE1DBAD8F
G = (0x2259ACEE15489CB096A882F0AE1CF9FD8EE5F8FA, 0x604358456D0A1CB2908DE90F27D75C82BEC108C0)
n = 0xFFFFFFFFFFFFFFFF00000001FFFFFFFFFFFFFFFF
a = -3
b = 0x65D1488C0359E234ADC95BD3908014BD91A525F9

The public key is hardcoded, and is equal to: (0xED9CE58234E61A53C685D64D51D0236BC3B5D4B9, 0x049DF1A075C0E04FB344858B61B79B69A63D2C39).

Elliptic curve for the other commands

This curved is used for Kirk commands 0xC, 0xD, 0x10, 0x11, and likely 0x12.

p = 0xFFFFFFFFFFFFFFFEFFFFB5AE3C523E63944F2127
G = (0x128EC4256487FD8FDF64E2437BC0A1F6D5AFDE2C, 0x5958557EB1DB001260425524DBC379D5AC5F4ADF)
n = 0xFFFFFFFFFFFFFFFF00000001FFFFFFFFFFFFFFFF
a = -3
b = 0xA68BEDC33418029C1D3CE33B9A321FCCBB9E0F0B

The public key is variable. For the latest Pre-IPL version which add an additional ECDSA verification of the XOR of the block hashes, the public key is (0xBC660611A70BD7F2D140A48215C096D11D2D4112, 0xF0E9379AC4E0D387C542D091349DD15169DD5A87).

Code sample

Below is an example of how to manipulate these curves using the ecpy python library.

import ecpy.curves

psp_curve_cmd1 = {
    'name':      "psp_curve_cmd1",
    'type':      "weierstrass",
    'size':      160,
    'field':     0xFFFFFFFFFFFFFFFF00000001FFFFFFFFFFFFFFFF,
    'generator': (0x2259ACEE15489CB096A882F0AE1CF9FD8EE5F8FA, 0x604358456D0A1CB2908DE90F27D75C82BEC108C0),
    'order':     0xFFFFFFFFFFFFFFFF0001B5C617F290EAE1DBAD8F,
    'cofactor':  1,
    'a':         -3,
    'b':         0x65D1488C0359E234ADC95BD3908014BD91A525F9,
}

psp_curve_cmd17 = {
    'name':      "psp_curve_cmd17",
    'type':      "weierstrass",
    'size':      160,
    'field':     0xFFFFFFFFFFFFFFFF00000001FFFFFFFFFFFFFFFF,
    'generator': (0x128EC4256487FD8FDF64E2437BC0A1F6D5AFDE2C, 0x5958557EB1DB001260425524DBC379D5AC5F4ADF),
    'order':     0xFFFFFFFFFFFFFFFEFFFFB5AE3C523E63944F2127,
    'cofactor':  1,
    'a':         -3,
    'b':         0xA68BEDC33418029C1D3CE33B9A321FCCBB9E0F0B,
}

crv1 = ecpy.curves.WeierstrassCurve(psp_curve_cmd1)
crv17 = ecpy.curves.WeierstrassCurve(psp_curve_cmd17)

pt1 = ecpy.curves.Point(0xED9CE58234E61A53C685D64D51D0236BC3B5D4B9, 0x049DF1A075C0E04FB344858B61B79B69A63D2C39, crv1)
pt17 = ecpy.curves.Point(0xbc660611a70bd7f2d140a48215c096d11d2d4112, 0xf0e9379ac4e0d387c542d091349dd15169dd5a87, crv17)

# verify the Kirk command 1 ECDSA private key
crv1_g = ecpy.curves.Point(0x2259ACEE15489CB096A882F0AE1CF9FD8EE5F8FA, 0x604358456D0A1CB2908DE90F27D75C82BEC108C0, crv1)
assert(crv1.mul_point(crv1.generator, 0xF392E26490B80FD889F2D9722C1F34D7274F983D) == pt1)

Slotted Keys

The KIRK ROM can access different keys which are slotted in what might be some kind of secure enclave. There are slots for both AES and ECDSA keys.

AES slotted keys

Id	Content
0	KIRK command 0 (Kbooti from Devkit) decryption key
1	KIRK command 0 (Kbooti from Devkit) CMAC key
2	KIRK command 1 (IPL) decryption key
3	KIRK command 2 (DRM) decryption key
4~131	KIRK commands 4/7 decryption keys (128 possible ones)

ECDSA slotted keys

Note: public keys take two slots (for both coordinates), and private keys take only one.

Id	Content
0/1	KIRK command 1 (IPL) public key (used to verify valid IPLs)
2/3	KIRK command 2 (DRM) public key (used to verify data passed to KIRK command 2)
4	KIRK command 3 (DRM) private key (used by command 2 to sign data for command 3)
5/6	KIRK command 3 (DRM) public key (used by command 3 to verify data coming from command 2)

Individual Seed

Some Kirk commands like commands 16 and 18 use individual (per-console) seeds. The base per-console seed is the Fuse ID (6 bytes), which is transformed into a 0x40 bytes buffer. The first 0x10 bytes of the buffer is the AES CBC MAC key used by Kirk command 18 whilst the second 0x10 bytes are the AES CBC key used by Kirk command 16.

typedef struct ScePspIndividualSeed { // size is 0x40
    SceUInt8 aes128cbc_mac_key[0x10]; // used by Kirk command 18
    SceUInt8 aes128cbc_key[0x10]; // used by Kirk command 16
    SceUInt8 derivation_key[0x10]; // used to derive the 2 other keys
    SceUInt8 fuse_id[8]; // endianness to precise
    SceUInt32 padding; // usually set to zero
    SceUInt32 hash; // the hash algorithm is in flashData.prx
} ScePspIndividualSeed;

To generate the individual seed of a PSP, provided the Fuse ID (0xBC100090 and 0xBC100094 hardware registers), execute the following code.

void gen_psp_individual_seed() {   
  int i, k;
  ScePspIndividualSeed seed;
  u8 subkey_1[0x10], subkey_2[0x10];
  rijndael_ctx aes_ctx;
  u8 fuseid[8];
  
  // Byte-reverse the Fuse ID
  u32 g_fuse90 = *(u32 *)0xBC100090;
  u32 g_fuse94 = *(u32 *)0xBC100094;
  fuseid[7] = g_fuse90 &0xFF;
  fuseid[6] = (g_fuse90>>8) &0xFF;
  fuseid[5] = (g_fuse90>>16) &0xFF;
  fuseid[4] = (g_fuse90>>24) &0xFF;
  fuseid[3] = g_fuse94 &0xFF;
  fuseid[2] = (g_fuse94>>8) &0xFF;
  fuseid[1] = (g_fuse94>>16) &0xFF;
  fuseid[0] = (g_fuse94>>24) &0xFF;
 
  rijndael_set_key(&aes_ctx, ids_master_key, 128); // set ids_master_key as AES key
  
  for (i = 0; i < 0x10; i++) // initialize the subkeys using the Fuse ID
    subkey_2[i] = subkey_1[i] = fuseid[i % 8];

  for (i = 0; i < 3; i++) { // AES encrypt, then decrypt, then encrypt, then decrypt, each subkey
    rijndael_encrypt(&aes_ctx, subkey_1, subkey_1);
    rijndael_decrypt(&aes_ctx, subkey_2, subkey_2);
  }

  rijndael_set_key(&aes_ctx, subkey_1, 128); // set subkey_1 as AES key

  for (i = 0; i < 3; i++) { // encrypt three times each one of the three first blocks
    for (k = 0; k < 3; k++)
      rijndael_encrypt(&aes_ctx, subkey_2, subkey_2);
    memcpy(&seed[i * 0x10], subkey_2, 0x10);
  }

  rijndael_set_key(&aes_ctx, seed.derivation_key, 128); // set the derivation key as AES key

  for (i = 0; i < 2; i++) { // encrypt twice the seeds to get the final keys
    rijndael_encrypt(&aes_ctx, seed.aes128cbc_mac_key, seed.aes128cbc_mac_key);
    rijndael_encrypt(&aes_ctx, seed.aes128cbc_key, seed.aes128cbc_key);
  }
}

Commands

On PSP there are 19 Kirk commands. On PSVita, there are these 19 commands plus some new commands to support bigger keys (192 bits for example). See F00D commands.

Kirk commands are called with the same 5 arguments (outbuf, outbuf_size, inbuf, inbuf_size, service_number (which is the command ID)). Depending on the service number used, the expectations of the inbuf or outbuf vary and are detailed below.

Table

Command ID	Name	Short description	Input size	Output size	Used in	Uses perconsole key fuse based algo?	Uses slot key? (if yes, specify)
0	KIRK_CMD_DECRYPT_BOOTROM	Decryption of the psp devkit kbooti bootrom (no inverse)	encrypted kbooti size	decrypted kbooti bootrom size	tachsm.o	No	Slot0_AES_1_CMAC
1	KIRK_CMD_DECRYPT_PRIVATE	Super-Duper decryption (no inverse)	buf_size+0x90	buf_size	memlmd, mesg_led, bootrom	No	Slot2_AES_CMAC
2	KIRK_CMD_DNAS_ENCRYPT	Encrypt Operation for DNAS (inverse of command 3)	buf_size+0x90	buf_size	mesg_led	Yes	Slot3_AES
3	KIRK_CMD_DNAS_DECRYPT	Decrypt Operation for DNAS (inverse of command 2)	buf_size+0x90	buf_size	mesg_led	Yes	No
4	KIRK_CMD_ENCRYPT_STATIC	Encrypt Operation (inverse of command 7) (key=static)	buf_size+0x14	buf_size+0x14	chnnlsv, memab, openpsid	No	Slot4<->0x83_AES
5	KIRK_CMD_ENCRYPT_PERCONSOLE	Encrypt Operation (inverse of command 8) (key=per-console)	buf_size+0x14	buf_size+0x14	openpsid, chnnlsv, psheet since PSP FW 2.81 for PGD, ?openpsid for IDPS Certificates?	Yes	No
6	KIRK_CMD_ENCRYPT_USER	Encrypt Operation (inverse of command 9) (key=user-defined)	buf_size+0x24	buf_size+0x34	power, inside a kl4e blob, IPL (stage 2)	Yes	No
7	KIRK_CMD_DECRYPT_STATIC	Decrypt Operation (inverse of command 4) (key=static)	buf_size+0x14	buf_size+0x14	memlmd, mesg_led,chnnlsv, memab, openpsid, bootrom	No	Slot4<->0x83_AES
8	KIRK_CMD_DECRYPT_PERCONSOLE	Decrypt Operation (inverse of command 5) (key=per-console)	buf_size+0x14	buf_size+0x14	memlmd, chnnlsv, psheet since PSP FW 2.81 for PGD	Yes	No
9	KIRK_CMD_DECRYPT_USER	Decrypt Operation (inverse of command 6) (key=user-defined)	buf_size+0x34 (header + key)	buf_size	power, inside a kl4e blob, IPL (stage 2)	Yes	No
10 (0xA)	KIRK_CMD_PRIV_SIGVRY	Private Signature Verify (checks for private SCE sig)	buf_size+0x90	0		Yes	No
11 (0xB)	KIRK_CMD_HASH	SHA1 Hash	buf_size >= 0x14	0x14	memlmd, mesg_led, memab, chkreg, openpsid, bootrom	No	No
12 (0xC)	KIRK_CMD_ECDSA_GENKEY	ECDSA Generate Private/Public Key Pair	0	0x3C	memab, openpsid	No	No
13 (0xD)	KIRK_CMD_ECDSA_MUL	ECDSA Multiply Point	0x3C	0x3C	memab, openpsid	No	No
14 (0xE)	KIRK_CMD_PRNGEN	Pseudo Random Number Generation	0	0x14	mesg_led, chnnlsv, memab, semawm, openpsid	No	No
15 (0xF)	KIRK_CMD_INIT_FUSE_SEEDS	Initializes Kirk Fuse Seeds.	0	0	IPL	Yes	No
16 (0x10)	KIRK_CMD_SIGGEN	ECDSA Signature Generation	0x34	0x28	memab, openpsid	Yes	No
17 (0x11)	KIRK_CMD_SIGVRY	Signature Verification (checks for generated signatures)	0x64	0	memab, memlmd, mesg_led, openpsid	No	No
18 (0x12)	KIRK_CMD_CERTVRY	Certificate Verification (IDStorage Certificates CMAC)	0xB8	0	openpsid, memab, chkreg	Yes	No

Command 1: decryption and authentication

Overview

This function is used to both decrypt and verify the signature of the IPL blocks.

There are two versions of this service: AES CMAC Verification, and ECDSA Verification. They use the header section of the input buffer slightly differently.

In both cases, the total header length is 0x90. The first 0x60 bytes depend on the version. The last 0x30 bytes are the same in both cases:

Metadata Header Structure (Length 0x30):

Address	Size	Description
0x60	4	Set to 1
0x64	4	0 indicates AES CMAC version, 1 indicates ECDSA version
0x68	4	0
0x6C	4	0 for retail version and 0xFFFFFFFF for dev versions
0x70	4	Length of decrypted data
0x74	4	Length of the padding after the header and before the real data
0x78	8	0

AES CMAC Version

Key Header Structure (Length 0x60):

Address	Size	Description
0x00	16	Decryption key, encrypted with the Kirk command 1 AES master key
0x10	16	CMAC key, encrypted with the Kirk command 1 AES master key
0x20	16	Header hash (CMAC)
0x30	16	Data hash (CMAC)
0x40	32	0

Decryption process

The first 0x20 bytes of the Key Header are decrypted with the Kirk command 1 Stored AES Key. This was allegedly discovered by Datel by decapping the chip and reversing engineering the algorithms and keys. This was also recovered through the failure in PS3 cryptography by decrypting the isolated module in the PSP emulator on the PS3.

The first block is the AES Key used for decrypting the main data. The second block is used to decrypt the next two blocks (0x20 bytes at offset 0x20). These represent the Metadata Header CMAC and the Data CMAC. They are checked against the AES CMAC of the metadata header section and the AES CMAC of the whole data, from the metadata header section to the end of the data (including padding in-between).

ECDSA Version

Key Header Structure (Length 0x60):

Address	Size	Description
0x00	0x10	Decryption key, encrypted with the Kirk command 1 AES master key
0x10	0x14	Header ECDSA signature r
0x24	0x14	Header ECDSA signature s
0x38	0x14	Data ECDSA signature r
0x4C	0x14	Data ECDSA signature s

Decryption process

The ECDSA version is slightly different. Only the first block (0x10 bytes) is decrypted with the Kirk command 1 AES Key. It is used to decrypt the main data section just as in the AES CMAC version. Rather than a CMAC, the Metadata header is checked by SHA1 hashing its 0x30 bytes and checking the signature components through a ECDSA Verify call. The encrypted Data section is also checked via SHA1 of the entire data through a ECDSA Verify call.

The ECDSA curve parameters are indicated above.

Commands 2 & 3: DRM encrypt & decrypt

These commands are mostly unknown. The header is the same as Kirk command 1, with the mode set to 2 or 3.

In command 2, the input data passed to Kirk is first checked (presumably CMAC), then decrypted, and re-encrypted with the console unique private key. Having that common key would allow legit creation of DRM BB install packages.

Command 3 is the decryption counterpart of command 2.

Commands 4~9: AES encrypt & decrypt

All these commands do AES128-CBC encryption/decryption with an IV equal to 0. - Commands 4 (encryption) and 7 (decryption) use a one of the 128 keys stored in the Kirk chip and available on the Keys page, index being given by the keyseed field (which must be between 0x00 and 0x7F) - Commands 5 (encryption) and 8 (decryption) use an unknown per-console key (it is unknown if it is derived from other data, or just stored as-is on the chip) - Commands 6 (encryption) and 9 (decryption) use a key derived from the keyseed using an unknown key derivation function

In all cases, data is prefixed with a 0x14-byte long header:

Address	Size	Description
0x00	4	Mode: must be 4 for encryption, 5 for decryption
0x04	8	Unknown (0?)
0x0C	4	Keyseed
0x10	4	Size of the following data

Command 10: AES CMAC verification

Used to verify IdStorage IDPS certificates.

This seems to be the AES CMAC verification of Kirk command 1, and takes the same header as Command 1, the only difference is that no decryption is performed.

See command 1 information for details.

It could also possibly verify CMACs for commands 2 and 3, but that is unknown.

Command 11: SHA1

This command computes the SHA1 of the input. The input must be prefixed with a 4-byte header giving the length of the buffer. Output is 0x14-byte long.

Command 12: ECDSA key pair generation

This command generates a random private key and computes the associated public key. See above for the parameters of the elliptic curve.

This returns the following into the keypair buffer, of size 0x3C (each value is 0x14 bytes long):

• 0x00 - randomly generated private key
• 0x14 - Public Key point x value
• 0x28 - Public Key point y value

Command 13: ECDSA point multiplication

This command multiplies an elliptic curve point by a scalar. See above for the parameters of the elliptic curve.

Input (size 0x3c):

• 0x00 - scalar k
• 0x14 - point x value P.x
• 0x28 - point y value P.y

Output (size 0x28):

• 0x00 - point x value (kP).x
• 0x14 - point y value (kP).y

The result is a new point(x and y are each 0x14 bytes long).

Command 14: PRNG

This function takes no input and generates random data of the given size (depending on the specified size of the output buffer).

Command 15: Init Fuse Seeds

This function takes no input and no output.

Kirk initialization of Fuse Seeds.

Command 16: ECDSA signature generation

This command generates an ECDSA signature of a SHA1 hash (0x14 buffer) using an encrypted private key.

Input is:

• 0x00: 0x20-byte long encrypted buffer containing the private key
• 0x20: the message hash.

The output is a 0x28-byte long signature (r and s, both 0x14-byte long).

The private key buffer is encrypted with a device-specific encryption using the FuseID.

Here is the code of the decryption, thanks to Davee & Proxima. g_fuse90 and g_fuse94 are the two words composing the FuseID (present at the 0xBC100090 and 0xBC100094 hardware registers).

Output is 0x20-byte long, but the last 0xC bytes are ignored (and possibly always equal to zero) for the private key.

void decrypt_kirk16_private(u8 *dA_out, u8 *dA_enc)
{   
  int i, k;
  kirk16_data keydata;
  u8 subkey_1[0x10], subkey_2[0x10];
  rijndael_ctx aes_ctx;
  
  keydata.fuseid[7] = g_fuse90 &0xFF;
  keydata.fuseid[6] = (g_fuse90>>8) &0xFF;
  keydata.fuseid[5] = (g_fuse90>>16) &0xFF;
  keydata.fuseid[4] = (g_fuse90>>24) &0xFF;
  keydata.fuseid[3] = g_fuse94 &0xFF;
  keydata.fuseid[2] = (g_fuse94>>8) &0xFF;
  keydata.fuseid[1] = (g_fuse94>>16) &0xFF;
  keydata.fuseid[0] = (g_fuse94>>24) &0xFF;
 
  /* set encryption key */
  rijndael_set_key(&aes_ctx, kirk16_key, 128);
  
  /* set the subkeys */
  for (i = 0; i < 0x10; i++)
  {
    /* set to the fuseid */
    subkey_2[i] = subkey_1[i] = keydata.fuseid[i % 8];
  } 

  /* do aes crypto */
  for (i = 0; i < 3; i++)
  {
    /* encrypt + decrypt */
    rijndael_encrypt(&aes_ctx, subkey_1, subkey_1);
    rijndael_decrypt(&aes_ctx, subkey_2, subkey_2);
  }

  /* set new key */
  rijndael_set_key(&aes_ctx, subkey_1, 128);

  /* now lets make the key mesh */
  for (i = 0; i < 3; i++)
  {
    /* do encryption in group of 3 */
    for (k = 0; k < 3; k++)
    {
      /* crypto */
      rijndael_encrypt(&aes_ctx, subkey_2, subkey_2);
    }

    /* copy to out block */
    memcpy(&keydata.mesh[i * 0x10], subkey_2, 0x10);
  }

  /* set the key to the mesh */
  rijndael_set_key(&aes_ctx, &keydata.mesh[0x20], 128);

  /* do the encryption routines for the aes key */
  for (i = 0; i < 2; i++)
  {
    /* encrypt the data */
    rijndael_encrypt(&aes_ctx, &keydata.mesh[0x10], &keydata.mesh[0x10]);
  }

  /* set the key to that mesh shit */
  rijndael_set_key(&aes_ctx, &keydata.mesh[0x10], 128);

  /* cbc decrypt the dA */
  AES_cbc_decrypt((AES_ctx *)&aes_ctx, dA_enc, dA_out, 0x20);
}

Command 17: ECDSA signature verification

This command verifies an ECDSA signature using the ECDSA curve described above.

It takes no output, and takes as an input:

• 0x00: public key
• 0x28: signed message hash
• 0x3C: signature r
• 0x50: signature s

The result of the operation is given by the return value (0 on success, 5 on failure to verify the signature).

Command 18: verify certificate

This command has most likely no output header.

It takes as an input a 0xB8-long buffer:

• 0x00: certificate data (either ConsoleID or OpenPSID)
• 0x10: certificate public key (x and y)
• 0x38: ECDSA signature (r and s)
• 0x60: ECDSA public key used for the signature
• 0x88: certificate encrypted private key (padded)
• 0xA8: AES-CMAC hash of the rest of the header.

Details are on PS Vita wiki. See also DespertarDelCementerio and CEX2DEX programs source codes.

Error codes

    0×00: Success
    0×01: Kirk not enabled
    0×02: Invalid mode
    0×03: Invalid header digest
    0×04: Invalid data digest
    0×05: Invalid signature
    0x0C: isInCriticalSection violation
    0x0D: Invalid operation (out of 1-18 range)
    0x0E: Invalid seed/code (cipher operations)
    0x0F: Invalid ?header size? (cipher operations)
    0×10: Invalid data size (equals 0) (sign/cipher operations)

Code Samples

• [1]

• [2]

• [3]

• [4]

Open problems

• The private key corresponding to the latest version PRE-IPL public key is unknown.
• Commands 2, 3, 5, 6, 8, and 9 are mostly unknown and need testing/documentation.