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.


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



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

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

    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          
    $ head -c 16 eks.img > eks_ecb.img                       
    $ hexdump eks_ecb.img                                    
    0000000 0400 0000 564e 4b45 5042 0000 0000 0000           
    $ 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:

    Any help would be appreciated.

    Best regards,

    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,

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


    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.


    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,


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