OEM_K1 / K2 Security

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

According to Reading OemK1 and OemK2 fuses from board - #3 by JerryChang it is not possible to read the values of the fuses.

  1. How secure is this in general? My use case is full disk encryption as covered by the thread model here Disk Encryption — Jetson Linux<br/>Developer Guide 34.1 documentation

  2. Is it still required to lock the production fuse to keep attackers from reading/writing to other fuses? I dont really care what they do with the hardware, as long as the data on the external drive is secure.

  3. Also it seems that there was a swap of which of the K1/K2 fuses are used. Is it good practice to burn both? (Like the guy here did: Fusing OemK1 for Disk Encryption - #30 by chinmaypen

3

*** Please note that this reply is generated by LLM automatically ***

The security of the Jetson Orin Nano’s fuse-based key storage is a topic of interest, especially when it comes to full disk encryption.

Firstly, it’s essential to understand that the OEM_K1 and OEM_K2 fuses are used to store the EKB fuse key, which is an AES key that is burned into a fuse. This key is not visible to the software, but OP-TEE uses it during boot through the SE to derive EKB_RK, which is the EKB Root Key.

The fact that it’s not possible to read the values of the fuses from the board is a security feature. This means that even if an attacker gains physical access to the board, they won’t be able to read the contents of the fuses, which includes the EKB fuse key.

However, it’s still possible for an attacker to write to other fuses if they have physical access to the board and the necessary tools. This is where the production fuse comes into play. The production fuse is a fuse that, when burned, prevents any further changes to the other fuses. This means that once the production fuse is burned, an attacker won’t be able to write to any other fuses, including the OEM_K1 and OEM_K2 fuses.

In your use case, where you’re using full disk encryption, it’s still recommended to burn the production fuse to prevent any potential attacks on the fuses. Even though you don’t care what an attacker does with the hardware, burning the production fuse adds an extra layer of security to prevent any potential tampering with the fuses.

Regarding the swap of which of the K1/K2 fuses are used, it’s not a problem to burn both fuses, as the guy in the thread did. In fact, it’s a good practice to burn both fuses to ensure that the EKB fuse key is stored securely. This way, even if an attacker tries to write to one of the fuses, the other fuse will still contain the original EKB fuse key.

To summarize:

  • The OEM_K1 and OEM_K2 fuses are used to store the EKB fuse key, which is an AES key that is burned into a fuse.
  • The fact that it’s not possible to read the values of the fuses from the board is a security feature.
  • Burning the production fuse prevents any further changes to the other fuses, including the OEM_K1 and OEM_K2 fuses.
  • It’s still recommended to burn the production fuse to prevent any potential attacks on the fuses, even if you’re using full disk encryption.
  • Burning both OEM_K1 and OEM_K2 fuses is a good practice to ensure that the EKB fuse key is stored securely.

In terms of security, the Jetson Orin Nano’s fuse-based key storage provides a good level of security for storing sensitive keys, such as the EKB fuse key. However, it’s essential to follow best practices, such as burning the production fuse and using both OEM_K1 and OEM_K2 fuses, to ensure that the keys are stored securely.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

Given the confusion and errors in the documentation I would kindly ask you as a human to verify the response

6

hello spam8pw3w,

may I double check what’s the actual use-case?

there’re OEM_K1/K2 to derive a root key which is itself used to sign and encrypt the EKB.
please refer to Tool for EKB Generation, it’s shown an example to generate a new EKS image which contain user keys.
besides.. you may dig into developer guide for EKB Extraction section for logical sequence of operations for extracting information from an EKB.

7

My goal is to have full disk encryption. I wand the data on the external nvme to be safe vs the threat model from the docs. As far as I understand (and I think you even confirmed somewhere back in the day ;)) I dont need SecureBoot for that as well.

I previously used Xavier NX, and now Im using Orin Nano. On the Xavier it was only about the KEK2 fuse (from the top of my head), while the Orin Nano may or may not need more fuses burned to achieve the same goal.

In the first link you mention it says

$ python3 gen_ekb.py -chip t234 -oem_k1_key <oem_k1.key> [..]

and keeps using oem_k1 throughout the instructions. Even though on my Orin Nano it seems only k2 is used.

From my experiments (with the goal to have full disk encryption), where “0key” means the key was all zeros and “VALUE” means it was set to some password hex. The input k1 key into gen_ekb.py was always updated accordingly

  1. K1 and K2 both 0key => works
  2. K1 and K2 burned to VALUE => works
  3. K1 burned to VALUE and K2 0key => works
  4. K2 burned to VALUE and K1 0key => works (although in the optee example.sh there are only references to K1 and the input to gen_ekb.py for k1 was the value of k2 => ie I would not expect this to work)

So my question is: Is it good practice to have K1 == K2?

And on top: why does scenario 4 work?

Or more general: Which of the scenarios given is the most secure way?

Regarding your pointer to the docs for EKB value extraction, are you saying that your previous statement that K1 and K2 cannot be read back is not correct (anymore)? ( Reading OemK1 and OemK2 fuses from board )

8

hello spam8pw3w,

basically, if you have mismatch user key within EKS image, it’ll abort booting process (during mount APP_ENC partition), and report below error logs to indicate you cannot unlock a disk.
ERROR: fail to unlock the encrypted dev /dev/nvme0n1p2

in the previous code (Xavier series), the OEM_K1 is used to derive the RPMB key, and OEM_K2 is used to encrypt/decrypt EKB.
both OEM_K1/K2 can be used as the root key of EKB. it’s gen_ekb.py python script to generate EKS image, so, you may just to change the option from "-oem_k1_key" to "-oem_k2_key" when generating the EKB image.
for instance, $ python3 gen_ekb.py -chip t234 -oem_k2_key <oem_k2.key> [..]

as mentioned by developer guide, Prepare K1/K2 keys.
it’s recommended to have truly random number for K1/K2 keys.