How it works

This section contains information on some TPM operating principles (administration password, list of certificates with private keys that can be protected, symmetric keys and their derivation mechanism, and PCR registers).

TPM administration password

A TPM administration password has to be set during its initialization. In this technical note, it is referred to as "TPM password".

You will be asked to provide this password for certain maintenance operations, when modifying the BIOS, after certain software updates, or after the SNS firewall boot partition is changed.

With regard to the TPM password:

  • It must comply with the password policy set on the SNS firewall,
  • On SNS in 4.8.7 and higher versions, we recommend generating it randomly with a length of at least 64 characters. Due to a restriction on SNS 4.3 LTSB versions, its length must not exceed 32 characters.
  • It must be kept in a secure and protected location.

IMPORTANT
If you misplace the TPM password, you will not be able to reinitialize it, and Stormshield is not in a position to recover the password. This scenario is described in the Troubleshooting section.

List of certificates with private keys that can be protected by the TPM

TPM protection applies to some certificates, depending on the SNS version installed.

Certificates used in the following cases with a private key that can be protected by the TPM Compatible SNS versions
4.3 LTSB 4.8.7 and upwards

IPsec VPN

SSL VPN -
SSL/TLS decryption
(web administration interface and captive portal)
-
Communications with the SMC server -
Sending of logs to a syslog server -
Internal LDAP -

Symmetric key - Operating principle and derivation mechanism

A symmetric key is set during the initialization of the TPM and stored on the TPM. When the private key of a certificate is protected by the TPM, the key will be encrypted with a symmetric key. Only the symmetric key will enable the encryption and decryption of a certificate's private key.

Firewalls have their own TPMs in high availability clusters. Two symmetric keys are therefore generated:

  • A first symmetric key stored on the active firewall's TPM,
  • A second symmetric key stored on the passive firewall's TPM.

To ensure service continuity when an SNS firewall cluster switches, the symmetric key that is stored on the active firewall has to be identical to the key that is stored on the passive firewall.

To achieve this, a symmetric key derivation mechanism (called derivekey) is used to generate the same symmetric key from the TPM password when the TPM on both firewalls in the cluster is initialized. As such, during a switch, each SNS firewall is able to decrypt the private keys. On versions 4.8.7 and higher, this mechanism is automatically used when the TPM is initialized from the SNS firewall web administration interface, regardless of whether it is a member of a high availability cluster.

PCR registers - Symmetric key protection and system status measurement

The symmetric key is sealed in the TPM, and access to it is strictly protected through a feature that reliably measures the status of the system, known as PCRs (platform configuration registers).

The TPM is sealed by the PCRs based on a series of hashes. Their value is defined by a set of measures taken when the SNS firewall is starting up: BIOS version and options, launched UEFI binaries, partition table, operating system, connected hardware modules (such as network modules and USB devices), etc.

If PCR hash values change, access to the TPM module may be denied. When this occurs, the symmetric key can no longer be recovered, and the protected private keys can no longer be decrypted. After ensuring that the changes are legitimate, reseal the TPM to refresh the hash values of the trusted RCPs, and restore access to the TPM. This procedure is described in the Sealing the TPM section.

NOTE
As of version 4.8.7, the TPM sealing policy no longer takes into account the PCR hash linked to the SNS firewall startup sequence. This hash used to be modified after a version update that contained changes to the SNS firewall startup sequence. Do note that the integrity of the UEFI binaries in this boot sequence is monitored by the Secure Boot feature.

Cases requiring the TPM to be resealed

The following cases require the TPM to be resealed:

  • If the TPM sealing policy was modified after a version update. Information is provided in the SNS release notes for this case.
  • If a BIOS option has been modified, for example if the SNS firewall's Secure Boot feature has been enabled or disabled.
  • If a physical maintenance operation has been conducted, for example if a USB device was plugged in or unplugged, or if a network module has been changed.
  • If the boot partition was modified and the SNS firewall was started on it.

    NOTE
    If the partition was selected in console mode during the interactive selection when the SNS firewall was started up, the TPM needs to be resealed after a second reboot.