i.MX6 encrypted boot DEK blob

[noorahmadshinwa]

Hi!

I am experimenting with encrypted boot on an i.MX6 board, and I noticed something strange when generating a DEK_BLOB from my signed u-boot.

Whenever I generate a BLOB using the same dek.bin file, the resulting blob is different. I mean generating the blob with the same dek.bin on the exact same chip.

I would expect a chip with the same DEK and the same OCOTP to always generate the same BLOB.

Is this normal?

Also I am using a 192-bit key and getting an 80 byte (0x50) size BLOB. Is that correct?

[Yuri]

@noorahmadshinwa 

Hello,

  let me look at log regarding DEK_BLOB command.

(The output will look something like this:
=> dek_blob 0x17870000 0x17871000 192
Generating DEK blob using key at
0x17870000
28 EB 58 03 ED 70 00 23 A9 58 AA 8F E8 10 52 27 4B 3F E7 0E C3 4F CF D5
DEK Blob is available at 0x17871000
810050416655180072B5556654639EDAA98B68FE931376301F207140110C7EC5BD898
62DF05218BECA18FEE72281667D235765B19E1FCB7DDD7FA2D9E1E145CA4D1EFCCDA3
929B6BE7C40240757FB7AD)

Regards,
Yuri.,

[noorahmadshinwa]

Hello Yuri.

Here is what i mean:

=> fatload mmc 0:1 0x17870000 dek.bin
24 bytes read in 12 ms (2 KiB/s)

=> md.b 17870000 24
17870000: 2f 1c bd 49 6c b1 68 84 25 f4 28 c7 2d 13 eb 1b    /..Il.h.%.(.-...
17870010: 34 17 a8 39 d5 8a b4 f3 91 12 66 4e b1 72 2e 4f    4..9......fN.r.O
17870020: b1 72 66 4e

=> dek_blob 0x17870000 0x17871000 192
SEC0: RNG instantiated

Encapsulating provided DEK to form blob
DEK Blob
8100504166551800476A60777DE2F3635A3ED7224FA9CF5ACE6FDF0FBF0A575B5572815CF228C3F0E96A944E405DCC1049451BFA07946904C903B1D00E03BC76378C97D4B62AB04E1BFDE6EC141FF881

=> dek_blob 0x17870000 0x17871000 192
SEC0: RNG instantiated

Encapsulating provided DEK to form blob
DEK Blob
810050416655180022B53663ED7F19F8A161D40EB8446525135DEEB18FCA2D76D2F62C8487C94330F668B7D3DC6CAAF23BAA66AB38D254FFB6F09554AC48621B231B11023EB6C04920C8D856210112DD

=> md.b 17870000 24
17870000: 2f 1c bd 49 6c b1 68 84 25 f4 28 c7 2d 13 eb 1b    /..Il.h.%.(.-...
17870010: 34 17 a8 39 d5 8a b4 f3 91 12 66 4e b1 72 2e 4f    4..9......fN.r.O
17870020: b1 72 66 4e                                        .rfN

Notice the first call and the second call to dek_blob yield different results (if you look at the second line of bytes). even though the input dek bytes are the same.

EDIT: I realise that my md.b calls use hex 24 as the length and display some extra bytes. but you can still see that the dek has not changed.

Thank you.

-Noor

[Yuri · Accepted solution]

@noorahmadshinwa 
Hello,

   regarding the BLOB approach - "Each time the blob protocol is used to protect data, a randomly generated key
is used to encrypt the data. The random key is itself encrypted, using a key encryption and is then stored along
with the encrypted data. The encryption key is derived from the chip's master secret key so the encryption key
can be recreated when the chip powers up again." So, each time new randomly generated key is used.

Regards,
Yuri.