How it works

This section lists the certificates with private keys that can be protected by the TPM, and provides explanations on the TPM administration password, symmetric key and its derivation mechanism, PCRs, and the importance of having access to the TPM.

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.

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.37 LTSB and higher 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 section Troubleshooting".

Symmetric keys

Introduction

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.

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

Symmetric key derivation mechanism

A symmetric key derivation mechanism (called derivekey) is used to generate the symmetric key from the TPM password when the TPM on an SNS firewall is initialized.

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. When the TPM on both firewalls in the cluster is initialized, the derivation mechanism is automatically used, making it possible to generate the same symmetric key from the TPM password. As such, during a switch, each SNS firewall is able to decrypt the private keys.

This mechanism is also useful in an SNS firewall exchange (RMA) to restore configuration backups that contain protected private keys. Since only the symmetric key can be used to encrypt and decrypt protected private keys, the symmetric key that is stored on the new firewall must be identical to the one that was stored on the returned firewall.

Platform configuration registers

Introduction

The TPM is sealed by the PCRs based on a series of hashes. These hashes are determined by a set of unfalsifiable measures that are taken when the SNS firewall starts up, e.g., BIOS version and options, partition table, launched EFI binaries, operating system, connected hardware modules, etc.

Among these PCRs, PCR 4 measures all launched EFI binaries, and is frequently the only register that changes when the SNS firewall is updated (when the update applies changes to the SNS firewall’s startup sequence).

NOTE
As of SNS version 4.8.7, the hash from PCR 4, which is linked to the SNS firewall boot sequence, is no longer taken into account in the TPM sealing policy. The Secure Boot feature now monitors the integrity of the UEFI binaries in this boot sequence.

PCR hash values and access to the TPM

If PCR hash values change, access to the TPM module may be denied.

• On SNS versions 4.3.37 LTSB and higher versions of 4.3 LTSB (with the former sealing policy including PCR 4): access to the TPM is denied if at least one of the values among PCR 0 to 7 changes.
• On SNS in 4.8.7 and higher versions (with the new sealing policy excluding PCR 4): access to the TPM will be denied if at least one of the values among PCR 0 to 3 or 5 to 7 changes.

If access to the TPM module is denied, the symmetric key can no longer be recovered, and protected private keys can no longer be decrypted without entering the TPM password.

To restore access to the TPM, ensure in advance that the change is legitimate. You must then reseal the TPM to update the value of PCR hashes. This procedure is described in the Sealing the TPM section.

IMPORTANT
If access to the TPM is denied, SNS firewall features that use certificates with protected private keys (VPN, those managed by an SMC server, etc.) will no longer function until access to the TPM is restored. Such blockages may occur, usually after an SNS firewall has been updated. This scenario is described in the section Appendix: points to note when updating SNS firewalls on which the TPM has been initialized.

Cases requiring the TPM to be resealed

The following cases require the TPM to be resealed:

• Secure Boot has been enabled or disabled on the SNS firewall.
• The SNS firewall boot partition has been changed. Do note, however, that 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.
• A USB device was plugged in or unplugged from the SNS firewall, meaning that a change has been made to the table of partitions that are available when the SNS firewall starts up.
• The TPM sealing policy was modified after a version update. When such a change occurs, it is announced in the SNS Version release notes.

NOTE
While this list is not exhaustive, it covers the most frequently encountered cases that require the TPM to be resealed. Other cases may also require the TPM to be resealed, such as certain hardware module changes, or modifications to certain BIOS options.