Fuses usage after ODM Production mode activated

Hi Jerry,

I’m trying to understand the usage of the keys (SSK, KEK0,…, KEK2) after ODM production mode is activated.

I’m using also EKB (Encrypted Keyblob) that I generated (please see the traces below). Unfortunately, I didn’t succeed to have it working.

I’m using the same Trusted application (keystore-demo) with the same fixed vector.

0x8623D63FAFE4775AC381024B4FB3EFA6

My key encryption key (KEK 2) that I burned in my target is:

0x30220131113002130210303100233232

Traces:

1.Define a format for the EKB content and generate the EKB content’s plaintext.

$ cat secret_message.txt
secret message!!

2.Generate a 128-bit symmetric key EKB_RK.

$ cat my_kek2.key
0x30220131113002130210303100233232

3.Burn the EKB_RK key into the device’s KEK2 fuse.

  • the script odmfuse.sh is used to burn this in the fuses.
  • 4.The default FV is:

    $ cat fixed_vector.txt
    0x8623D63FAFE4775AC381024B4FB3EFA6
    

    5.Compute EKB_EK using AES ECB encryption according to the formula:

    EKB_EK = AES-128-ECB(FV, EKB_RK)

    6.Encrypt the EKB content plaintext with EKB_EK, using the desired crypto algorithm to obtain the EKB content ciphertext.

    In my case I’m using openssl command line.

    $ openssl enc -aes-128-ecb -e -in secret_message.txt -out secret_message_ciphered.txt -K 30220131113002130210303100233232 -iv 8623D63FAFE4775AC381024B4FB3EFA6
    

    7.Append the EKB header to the EKB content ciphertext as described in the section Encrypted Keyblob Format. The resulting file is a fully generated EKB binary.

    $ hexdump secret_message_ciphered.txt                    
    0000000 eb72 c7bf a140 78a3 823e e667 7c92 b07a          
    0000010 c759 8774 72c2 3634 ee76 8cb1 fec4 dcbe          
    0000020                                                  
    $ head -c 16 eks.img > eks_ecb.img                       
    $ hexdump eks_ecb.img                                    
    0000000 0400 0000 564e 4b45 5042 0000 0000 0000           
    0000010                                                   
    $ tail -c 1024 secret_message_ciphered.txt >> eks_ecb.img
    $ dd if=/dev/zero of=eks_tmp.img bs=1 count=992          
    #                                                        
    # Padding with 0 until have 1024 bytes as size for EKB   
    # Content Ciphertext                                     
    $ tail -c 992 eks_tmp.img >> eks_ecb.img
    

    8.Flash the EKB binary to the device’s EKS partition.


    Serial traces:

    [0000.673] I> TOS boot-params @ 0x85000000
    [0000.677] I> TOS params prepared
    [0000.680] I> Loading EKS ...
    [0000.682] I> A/B: bin_type (15) slot 0
    [0000.686] I> Loading partition eks at 0x8590f800
    [0000.690] I> Reading two headers - addr:0x8590f800 blocks:1
    [0000.696] I> Addr: 0x8590f800, start-block: 58757128, num_blocks: 1
    [0000.704] I> Binary(15) of size 1040 is loaded @ 0x8590f800
    [0000.710] I> EKB detected (length: 0x400) @ 0x8590f800
    [0000.715] I> Copied encrypted keys
    [0000.719] I> boot profiler @ 0x275844000
    [0000.722] I> boot profiler for TOS @ 0x275844000
    [0000.727] I> Unhalting SCE
    [0000.730] I> Primary Memory Start:80000000 Size:70000000
    [0000.735] I> Extended Memory Start:f0110000 Size:1856f0000
    [0000.742] I> MB2(TBoot-BPMP) done
    
    NOTICE:  BL31: v1.3(release):bf7419b-dirty
    NOTICE:  BL31: Built : 10:34:52, Feb 18 2020
    keystore-demo: 141: Hello world from keystore-demo app
    keystore-demo: 209: main: EKB contents do not match expected value
    exit called, thread 0xffffffffea852800, name trusty_app_0_7d18fc60-e9fc-11e8
    

    Is that the correct way to generate the EKB ?

    How we can use the SSK with the EKB to do storage encryption ?

    I tried to respect the steps mentioned in the link:
    https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3231/Tegra%20Linux%20Driver%20Package%20Development%20Guide/trusty.html#wwpID0E0PC0HA

    Any help would be appreciated.

    Best regards,
    Ilies

    The keystore-demo app doesn’t actually expect the data to be encrypted with AES - see lines 182-211 in app/keystore-demo/keystore-demo.c in the sources. It just XORs the 16-byte ciphertext with the ekb_ek.

    It takes additional code to turn the demo into something usable. I have an implementation at https://github.com/madisongh/keystore, which I’ve been using for partition encryption, that’s a bit more complete.

    1 Like

    Hi Madisox,

    Thank you for your response.

    The keystore-demo application use only one key (KEK2) for the moment.

    Could we use the SSK instead of KEK2 for example?

    I think no because we have to use the SSK for the EKB generation. The SSK is generated by the BOOTROM then store in the SE key slot.

    Could you please confirm that ?

    Is there any way to use the keys (SSK, KEK0, KEK1, …) for other security applications ? if yes, the usage of the EKB is mandatory for that ?

    Best regards,
    Ilies

    By SSK, do you mean the SBK? No, I don’t believe so. None of this is very well documented, but it wouldn’t make sense to have the SBK accessible to anything but the boot ROM, since it’s a symmetric encryption key.

    Not for us ordinary mortals. The only thing NVIDIA documents is the use of KEK2, so I would stick with using that, and in the documented manner.

    Please take a look in the following video (slide 12 and 13):

    https://www.brainshark.com/nvidia/Jetson_Security_SecureBoot?dm=5&pause=1&nrs=1&nodesktopflash=1

    SSK: Secure Storage Key.

    I wish use this key to do secure storage (SSD encryption).

    OK, got it. Unfortunately, that presentation only provides some hints, and the public documentation doesn’t mention the SSK at all. It is mentioned in some header files in the trusty and cboot source code, but I’d be careful about trying to use it without some guidance from NVIDIA.

    You could adapt the KEK2-based keystore TA to provide the passphrase for unlocking a self-encrypting SSD, though.

    madisox,

    SSK is coming from SBK, KEK2 and an ID and can be used for secure storage protection key. We are providing a sample to show how it’s used in our next R32.4 release. The sample is demonstrating how to use SSK derived key to protect secrets.

    Hi Chijen,

    Do you mean JetPack 4.4 release ?

    I’m looking forward to use this version of JetPack.

    Thank you very much

    Best regards,

    Ilies

    Thanks for sharing, this is a massive time saver :)