Jetson TX2/Xavier (L4T R32.7.3) Trusty hwkey-agent / EKS provisioning questions

Robotics & Edge Computing Jetson Systems Jetson TX2
,
1

Jetson TX2/Xavier (L4T R32.7.3) Trusty hwkey-agent / EKS provisioning questions

Hello,

We’re developing a product on Jetson TX2 and Jetson Xavier (T194) running Jetson Linux / L4T R32.7.3 (JetPack 4.6.3). Our goal is to use the Trusty hwkey-agent Trusted Application together with the Linux hwkey-app client to seal/unseal sensitive data (e.g., LUKS key material) using hardware-derived keys.

We tested on two systems with the same software stack:

  • Development machine: hwkey-app succeeds

  • Production machine with burned fuses: hwkey-app fails

On the production machine we see the following error when running hwkey-app:

/hwkey-app -e -i plain.bin -o sealed.bin -t
tipc_connect: can't connect to tipc service "hwkey-agent.srv.crypto-srv" (err=107)

Questions:

  1. In L4T R32.7.3, does the NVIDIA-provided prebuilt Trusty TOS include the hwkey-agent TA and support deriving keys from hardware fuses / SE keyslots as required by hwkey-app?

  2. If we provision the EKS partition with an EKB (eks.img) generated with our OEM key material, will the prebuilt TOS automatically detect and use it at boot for hwkey-agent / hwkey-app operations, or is a TOS rebuild/configuration change required? For a production-fused machine, is it the expected workflow:

    • generate eks.img with NVIDIA’s gen_ekb.py using the correct KEK2/OEM key inputs (matching what is burned on the module), and

    • flash eks.img into the EKS partition,
      and then hwkey-app should succeed?
      If not, what additional steps are required (TOS rebuild options, required configs, signing, etc.)?

Environment:

  • L4T Version: R32.7.3

  • JetPack: 4.6.3

  • Platform: Tegra T194 (Xavier) and Jetson TX2

Thanks,
Shabnam

2

Hello,

Thanks for visiting the NVIDIA Developer Forums.
To ensure better visibility and support, I’ve moved your post to the Jetson category where it’s more appropriate

Cheers,
Tom

5

hello shabnam.ab,

you may enable Disk Encryption, it encrypts a whole disk or partition to protect the data.

the boot partition (“APP”) remains in an unencrypted format, so the bootloader can still load kernel and device tree blob; the root partition (“APP_ENC”) would be encrypted.
the user_key is specified in EKB (i.e. eks.img)
CA sample, hwkey-agent/CA_sample/tool/gen_ekb/example.sh to generate eks.img, the sym.key is the user_key. Trusty retrieves user_key from eks.img, and loads the key into keyslot_14 for decryption, when you perform image flashing, please use --use_key options to specify the user_key.

please see-also Topic 258603 for reference.