Configuration Integrity
Version History
| Release | Modification |
|---|---|
| 7.1.3 | SSR Configuration Integrity added. |
SSR Configuration Integrity addresses security requirements for protecting sensitive data stored on SSR devices when they are at rest - when a system is powered off for extended periods, physically stolen, or have their storage media removed and analyzed offline by malicious actors seeking to extract sensitive information or compromise network security.
SSR devices are frequently deployed in environments where physical security cannot be guaranteed, ranging from remote branch offices and retail locations to temporary installations and field deployments. In these environments, configuration files, private keys, and operational data stored on the device require protection from unauthorized access.
Modern compliance requirements and regulatory frameworks mandate encryption-at-rest for sensitive data, particularly in the financial services, healthcare, and government sectors. High-security customers require robust protection against data exfiltration to maintain their security posture and meet regulatory obligations. These requirements have evolved beyond simple access controls to demand cryptographic protection of stored credentials, configuration data, and private key material that could be exploited to compromise broader network infrastructure.
SSR Configuration Integrity protects authentication credentials, keys and certificates, network topology information, and other pieces of sensitive SSR configuration from unauthorized access when the system is powered off.
Furthermore, Configuration Integrity prevents network and SSR operations from executing when the system is determined to be in a compromised state. These protected secrets cannot be exfiltrated even if the bad actor has physical access to the drive, preventing attackers from impersonating network nodes or intercepting encrypted communications. Most importantly, it meets compliance requirements for encryption-at-rest without impacting runtime performance, allowing organizations to satisfy regulatory mandates while maintaining the high-performance networking capabilities that SSR devices are designed to provide.
Configuration Integrity does not address any runtime access-policy or permissions concerns. Proper file and directory permissions are still required, as well as proper login and authentication controls. Configuration Integrity augments the existing SSR security functionality to provide encryption-at-rest guarantees.
Configuration Integrity is enabled automatically on new installations of and upgrades to SSR 7.1.3 on platforms (hardware or VM) with TPM 2.0.
After installing / upgrading to SSR 7.1.3, downgrading to an earlier version of SSR software where Configuration Integrity (CI) is not available is NOT supported.
Rollback to the previously installed version of software is supported.
How It Works
Configuration Integrity utilizes a hybrid approach combining TPM2 hardware security with Linux native filesystem encryption, administered by the userspace tool fscrypt. fscrypt utilizes an AES-256 key generated and protected by the TPM to perform encryption and decryption operations. Once the encrypted directories are unlocked, they operate as a normal directory; the encryption is transparent to the user.
Major Components
The following are the major components of Configuration Integrity.
TPM 2.0 Hardware Security Module
The TPM is the trust anchor of the system. It creates and unseals the Filesystem Encryption Key (FEK), and is the only component of the system that can perform this task. If the storage of the SSR is somehow separated from the TPM, the FEK can no longer be unsealed, and the filesystem cannot be unlocked, ensuring that sensitive data remains protected.
All SSR TPMs are provisioned with an RSA-2048 key, which is used to perform the encryption and decryption of the FEK.
Configuration Integrity encryption is enabled automatically on platforms (hardware or VM) with TPM 2.0. Platforms without TPM 2.0 will remain unencrypted.
Filesystem Encryption Key (FEK)
The FEK is a 256-bit random number generated by the TPM. Once it has been generated, it is encrypted by the TPM using RSA-2048 before being written to disk. At no time will the unencrypted FEK be written on disk. Any time it is decrypted, it is stored in memory only.
fscrypt
fscrypt is a userspace interface to the Kernel-level filesystem and encryption stacks. It operates on a per-directory basis, leveraging either a PAM module, a passphrase, or a 256-bit raw key to unlock and decrypt the directory. The SSR uses only the raw key mode.
fscrypt requires that no target directory exist as a repository for decrypted files. Because technology allows the recovery of deleted files from a directory, the process of migrating files to an existing encrypted directory leaves traces of the unencrypted versions on disk resulting in a potential security risk.
All sensitive files will be written to the encrypted directory from their inception onward, ensuring that there is no security risk. fscrypt configured in raw_key mode uses AES-256-XTS encryption for file contents and AES-256-CBC-CTS encryption for filenames.
Configuration Integrity Systemd Service
The Integrity Handler is the systemd service responsible for Configuration Integrity on the system. If it detects that a system has not been configured for Configuration Integrity, it will perform a series of checks to see if it can support the feature. If the system can support the feature, it will onboard the system into Configuration Integrity.
Once a system is onboarded, the Integrity Handler is responsible for unlocking the encrypted directories so they can be transparently used by the system. It does so with the following sequence:
- Locate encrypted FEK on disk.
- Unseal FEK with the TPM.
- Pass unencrypted FEK to fscrypt.
- fscrypt uses the FEK to automatically unlock the necessary encrypted directories.
If any of these steps fail, it is interpreted as an integrity event. Network activities are blocked. An emergency log is generated and broadcast to all consoles on the system that the system integrity is compromised and it must be reprovisioned. The SSR will repeatedly try to start the integrity service to unlock the encrypted directories and fail, each time writing the emergency log.
Broadcast message from systemd-journald@TESTsystem1 (Mon 2025-12-01 17:15:20 UTC):
integrity-handler: Integrity event detected. A clean installation is required.
Recovery steps require physical access to the device to reimage the system with a fresh ISO.
Troubleshooting
Use the information below to investigate issues and understand the Configuration Integrity feature.
Logging
Logging is handled through existing system components rather than a dedicated log category. During initial system provisioning, all Configuration Integrity initialization is logged as part of the standard provisioning process. On subsequent boots, the systemd service that is responsible for unlocking encrypted directories logs all unlock operations and service status information through the systemd journal. Use journalctl -u integrity-handler for visibility into the operational state of the encryption system during the boot sequence.
Key operational messages include TPM provisioning status and error conditions, filesystem encryption capability detection results, and detailed logging of FEK generation, storage, and retrieval operations. The system also logs all directory encryption and decryption operations along with integrity violation events that may trigger protective responses.
Compromised System
In the event your system has been compromised, the device must be reprovisioned with a clean install from a bootable USB. If that is not viable, contact your sales team or Juniper technical support to begin the RMA process.