Overview of encryption drivers

In the past, adding an HSM could only be done after product installation. Now, during a new installation, you can set up a hardware (HSM) encryption key that allows data encryption without requiring a separate software encryption key.

If you Enable Hardware Encryption, then you can opt out of enabling a separate software encryption key. In that scenario, software encryption is used for key generation only.

The software key is Trust Protection Foundation’s default encryption key. It is an AES-256 key that is stored in the Windows registry.

The Null encryption driver actually provides no encryption key at all. It gives users the option of selecting no encryption for objects, such as certificates, that do not need to be secured.

For more information on the default encryption drivers, see Managing the default software encryption key and Managing the null key.

If you want to use AES keys stored on a SafeNet Luna SA or Entrust nShield device, or if you want to store code signing keys on those devices, you must first configure the device connection via the Trust Protection Foundation Configuration Console then create a Hardware Encryption Driver object . For information on configuring an HSM device connection and a Hardware Encryption Driver, see Using HSM-protected encryption keys.

After you configure the device connection and create the Hardware Encryption Driver, you can select the driver’s corresponding encryption keys to define your system’s default encryption key settings as well as individual Certificate and Credential object encryption keys.

Encryption keys are critical to Trust Protection Foundation’s functionality. Consequently, during startup, Trust Protection Foundation loads every encryption driver and validates its associated encryption keys. If Trust Protection Foundation is unable to load an encryption driver or validate any one of the encryption keys, it logs an error to the local Windows system event log and shuts down. You can still run Trust Protection Foundation Configuration Console with reduced functionality so that you can correct the problem; however, the Palo Alto Networks Trust Protection Foundation service itself, will not load until the problem is corrected.

To provide some level of redundancy and system failover, Trust Protection Foundation can use the same encryption key from different Encryption Drivers as long as the Encryption key name and password are the same. Moreover, if multiple copies of the same key exist on the HSM device, you can select a copy of the original key as long as it has the same fingerprint as the original.

However, once you initialize a key, you cannot change the encryption key itself. If a configured encryption key is not available or is not valid when Trust Protection Foundation attempts to write encrypted data to the Secret Store, Trust Protection Foundation logs an error to the local Windows system event log, notifies the user at the administration console, and shuts down.