ASP 130 R7.x Encrypted architecture overview

Last Updated : Oct 30, 2026 |
Prolog information
Metadata
Keywords:

FIPS 140-3 Compliance

To achieve strict STIG and FIPS 140-3 compliance, starting with ASP 130 R7.0, the solution adopts a full-disk encryption architecture featuring:
  • Block-Level Encryption: Implements RHEL Linux Unified Key Setup (LUKS2) (dm-crypt) at the physical volume layer, providing transparent data encryption at the block level rather than targeting individual files or partitions.
  • Comprehensive Data-at-Rest Protection: Secures all required system partitions simultaneously by protecting the underlying physical volume, covering root, system logs, application data (libvirt), and swap partitions.
  • Enforced FIPS Mode: ASP 130 R7.x software installation is conducted strictly in FIPS mode and sets the system-wide cryptographic policy to mandate FIPS-approved algorithms (such as AES-XTS) for all encryption.

TPM Binding

TPM 2.0 binding is leveraged to securely seal and automatically release encryption keys based on platform integrity. The LUKS framework supports multiple key slots, enabling key management and secure recovery operations.
  • TPM-Bound Key: Primary unlock mechanism using Clevis TPM2 binding for automated system startup.
    • Clevis is used for managing LUKS passphrases, keys and related components.
  • Recovery Passphrase: A secondary passphrase is maintained to allow manual unlocking in the event of TPM failure or hardware replacement.
    • Passphrase input will be required to support the HDD disk import feature in the event of server failure/replacement.
  • Key Rotation: Additional key slots can be added or rotated without requiring re-encryption of the underlying data, supporting operational security policies and periodic credential updates.
Figure: High-level flow architecture of full disk encryption with TPM binding

Data-at-Rest protection and media security

By encrypting all sensitive partitions, including swap space, this architecture protects against unauthorized data access in scenarios involving physical disk removal, decommissioning, or loss of hardware.
Because all data is stored in encrypted form using LUKS2, any data remnants on the physical media remain cryptographically protected, mitigating the risk of data exposure outside of a trusted system state.
Note:
The /boot and /boot/efi partitions remain unencrypted as they must be accessible to system firmware and the bootloader during early boot; disk decryption via LUKS occurs later in the boot process once the Linux kernel and initramfs are loaded.
Figure: High-level storage layout of encrypted vs unencrypted physical disk
LSBLK Example output before encrypting
[root@asp130-r660xs-20841 ~]# lsblk
NAME                             MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                                8:0    0  3.3T  0 disk
├─sda1                             8:1    0  600M  0 part  /boot/efi
├─sda2                             8:2    0    1G  0 part  /boot
├─sda3                             8:3    0    6G  0 part  [SWAP]
└─sda4                             8:4    0  3.3T  0 part
  ├─vg_system-lv_root            253:0    0   10G  0 lvm   /
  ├─vg_system-lv_libvirt         253:1    0  3.2T  0 lvm   /var/lib/libvirt
  ├─vg_system-lv_guestinfo       253:2    0   52M  0 lvm   /opt/avaya/asp/guestinfo
  ├─vg_system-lv_audit           253:3    0    5G  0 lvm   /var/log/audit
  ├─vg_system-lv_log             253:4    0   15G  0 lvm   /var/log
  ├─vg_system-lv_var             253:5    0    6G  0 lvm   /var
  ├─vg_system-lv_vartmp          253:6    0    4G  0 lvm   /var/tmp
  ├─vg_system-lv_tmp             253:7    0    3G  0 lvm   /tmp
  └─vg_system-lv_home            253:8    0    3G  0 lvm   /home
 
LSBLK Example output after encrypting
Note:
The output below displays the two LUKS encrypted devices located under the /dev/sda3 and /dev/sda4 partitions, respectively.
[root@asp130-r660xs-20841 ~]# lsblk
NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sda                                             8:0    0  2.2T  0 disk
├─sda1                                          8:1    0  600M  0 part  /boot/efi
├─sda2                                          8:2    0    1G  0 part  /boot
├─sda3                                          8:3    0    6G  0 part
│ └─luks-e1223307-4ee7-4120-97c6-f79e02f5264b 253:0    0    6G  0 crypt [SWAP]
└─sda4                                          8:4    0  2.2T  0 part
  └─luks-4392d57c-360c-4129-8385-1254effaff95 253:1    0  2.2T  0 crypt
    ├─vg_system-lv_root                       253:2    0   10G  0 lvm   /
    ├─vg_system-lv_libvirt                    253:3    0  2.1T  0 lvm   /var/lib/libvirt
    ├─vg_system-lv_guestinfo                  253:4    0   52M  0 lvm   /opt/avaya/asp/guestinfo
    ├─vg_system-lv_audit                      253:5    0    5G  0 lvm   /var/log/audit
    ├─vg_system-lv_log                        253:6    0   15G  0 lvm   /var/log
    ├─vg_system-lv_var                        253:7    0    6G  0 lvm   /var
    ├─vg_system-lv_vartmp                     253:8    0    4G  0 lvm   /var/tmp
    ├─vg_system-lv_tmp                        253:9    0    3G  0 lvm   /tmp
    └─vg_system-lv_home                       253:10   0    3G  0 lvm   /home
 
Note:
If viewing the server console connected via monitor, a LUKS passphrase prompt will temporarily appear during startup. No action is required; the system will automatically unlock after a few seconds.
During initial OS provisioning, the first-boot configuration script enforces a mandatory LUKS passphrase change.