Tegrasign HSM Key Database

Robotics & Edge Computing Jetson Systems Jetson Orin NX
1

I’m currently investigating implementing HSM support for tegrasign_v3.py and I’ve run into an issue that seems problematic. There is the concept of a ‘Key Database’ which seems to allow tegrasign to add new keys to the HSM. These keys are identified by a key ID and allow tegrasign to lookup the key rather than run the KDF again. Unfortunately, the “_DK_” key id keys (e.g. SBK_MB1BCT_DK_1ed3171350735702d909464dedfcdc35) are using a randomly generated label buffer to create the ID based on the contents of the kdf .yaml file where the ‘RANDOM’ field is set to “ IV SALT2 DERSTR “. Due to this setting, you end up creating a new key entry every time you need to sign and encrypt new images. This will cause the HSM to fill up with these keys.

I can prevent this behavior by modifying tegraflash_impl_t234.py so that the ‘RANDOM’ field does not specify ‘DERSTR’, but I’m wondering if that will cause unwanted side-effects. Does this label really need to be randomly generated?

2

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

The issue you’re facing is related to the Key Database in the HSM (Hardware Security Module) used by tegrasignv3.py. The Key Database allows tegrasign to store and manage keys, which are identified by a key ID. This key ID is generated based on the contents of the KDF (Key Derivation Function) YAML file.

In your case, the DK key ID keys (e.g., SBKMB1BCTDK1ed3171350735702d909464dedfcdc35) are using a randomly generated label buffer to create the ID. This is because the RANDOM field in the KDF YAML file is set to “IV SALT2 DERSTR”. As a result, a new key entry is created every time you need to sign and encrypt new images, which can cause the HSM to fill up with these keys.

Modifying tegraflashimplt234.py to remove the DERSTR specification from the RANDOM field might prevent this behavior. However, it’s essential to understand the implications of this change.

The DERSTR specification is likely used to ensure that the label buffer is randomly generated and unique for each key derivation operation. This randomness is crucial for the security of the key derivation process.

If you remove the DERSTR specification, the label buffer might not be randomly generated, which could lead to the following potential issues:

  1. Key collisions: Without a randomly generated label buffer, there’s a higher chance of key collisions, where two different key derivation operations produce the same key ID.
  2. Predictable key IDs: If the label buffer is not randomly generated, an attacker might be able to predict the key ID, which could compromise the security of the key derivation process.
  3. Incompatibility with HSM: The HSM might expect a randomly generated label buffer for key derivation operations. If the label buffer is not randomly generated, the HSM might not function correctly or might reject the key derivation requests.

Before making any changes, consider the following:

  1. Consult the HSM documentation: Check the HSM documentation to see if it provides any guidance on the label buffer generation for key derivation operations.
  2. Evaluate the security implications: Assess the potential security risks associated with removing the DERSTR specification from the RANDOM field.
  3. Test the modified implementation: Thoroughly test the modified tegraflashimplt234.py implementation to ensure that it works correctly and doesn’t introduce any security vulnerabilities.

In summary, while modifying tegraflashimplt234.py might prevent the HSM from filling up with keys, it’s crucial to carefully evaluate the potential security implications and test the modified implementation to ensure that it doesn’t compromise the security of the key derivation process.

As an alternative, you could consider implementing a key caching mechanism in tegrasignv3.py to store and reuse previously generated keys, rather than generating a new key for each signing and encryption operation. This approach would avoid the need to modify the KDF YAML file and minimize the risk of introducing security vulnerabilities.

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

7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.