Skip to main content

Carving Out a CUI Enclave on Your Existing Filesystem

· 13 min read
Thomas Samant
Thomas Samant
Senior Partner

Organizations operating research clusters, HPC environments, and open compute infrastructure already maintain filesystems measured in petabytes. When CMMC Level 2 compliance enters the picture, organizations often assume CUI requires physically dedicated storage: a separate appliance, separate drives, a hard boundary between the regulated enclave and everything else. That assumption is expensive and, under tiCrypt's architecture, unnecessary.

tiCrypt's client-side encryption reduces the storage layer to a ciphertext-only medium. The filesystem never holds keys or plaintext. Because the storage layer cannot read what it stores, CUI can share physical media with non-CUI workloads without compromising confidentiality. You can carve out a partition, directory, or namespace on your existing shared filesystem, point tiCrypt at it, and maintain full CMMC L2 compliance without purchasing dedicated hardware. This article explains how to do it, what the storage layer actually holds, and which CMMC controls make this acceptable.

For the theoretical foundation behind cryptographic isolation on shared media, see Cryptographic Isolation for CUI on Shared Storage. For details on how tiCrypt interacts with the underlying filesystem, see Interplay between the filesystem and tiCrypt.

Why Shared Storage Is Acceptable​

CMMC Level 2 requires that the confidentiality of CUI be protected. It does not require that CUI reside on physically dedicated hardware. Physical isolation is one way to satisfy the confidentiality requirement. Cryptography is another.

The natural objection: "CUI is on the same physical disk as non-CUI data." Under tiCrypt's architecture, this is irrelevant. tiCrypt encrypts every resource on the client with a unique AES-256 key before it reaches the storage layer. The storage layer receives and persists ciphertext only. Decryption keys never exist on the server, in the storage system, or in any administrator's possession. An attacker, a co-tenant, or a storage administrator with full disk access sees only ciphertext: computationally indistinguishable from random data without the keys.

This is not a workaround. It is the architecture functioning as designed. The tiCrypt Security Whitepaper states it directly:

Vault chunks can be backed up using any method, including unencrypted backups or cloud storage, without creating a compliance risk. The encryption is inherent to the data, not dependent on the storage medium.

The same property that makes unencrypted backups safe makes shared storage safe: the data is self-protecting regardless of where it resides.

caution

Shared storage is acceptable because tiCrypt's encryption is client-side, with user-controlled keys. Server-side encryption with provider-managed keys does not provide the same guarantee. If the storage platform or an administrator controls the keys, co-residency remains a confidentiality risk regardless of the encryption algorithm. The distinction is who holds the keys, not whether encryption is present.

What tiCrypt Actually Stores on Disk​

The compliance argument depends on what the filesystem actually holds. tiCrypt persists three categories of data. None contains plaintext CUI.

Vault chunks​

Vault file content is split into 8 MB chunks. Each chunk is encrypted independently with the file's unique AES-256 key in CBC mode, using a per-chunk initialization vector (IV). Each chunk occupies 8 MB + 64 bytes on disk; the extra 64 bytes store the IV. The last chunk may be smaller. Chunks are numbered from zero and stored in a directory structure keyed to the file ID.

Without the per-file decryption key, recoverable only by authorized users through their RSA-2048 private keys, every chunk is indistinguishable from random data.

Encrypted VM drives​

Encrypted VM drives are stored as files (raw or QCOW2 format) on a distributed filesystem accessible to all libvirt host servers. Each drive's encryption key is generated and held exclusively by the user and the VM controller. The tiCrypt backend, libvirt, and the underlying VM host have no access to the key.

On Linux VMs, LUKS (Linux Unified Key Setup) encryption with AES-256 is applied at the block layer beneath the filesystem (typically EXT4). All data written to the drive (filesystem structure, metadata, and file content) is encrypted. An external observer can determine which disk blocks have been written but cannot derive their content.

On Windows VMs, the drive is formatted as NTFS and BitLocker full-volume encryption (AES-256) is activated before the user accesses it. All subsequent writes are encrypted.

In both cases, FIPS mode is enabled at the operating system level within the VM. All cryptographic operations (LUKS, BitLocker, and tiCrypt's own OpenSSL calls) use FIPS-validated implementations. The backing files on the shared filesystem contain only ciphertext.

MongoDB metadata​

All metadata (file properties, directory entries, access control records, and per-file encrypted decryption keys) resides in MongoDB, physically separate from chunk and drive data. The per-file decryption keys in MongoDB are wrapped with each authorized user's RSA-2048 public key. An attacker with full access to MongoDB cannot recover plaintext without the corresponding RSA-2048 private keys.

What is NOT on the storage layer​

Private keys never leave the client. No plaintext CUI exists on disk at any point. No session keys, unwrapped file keys, or password hashes reside in the storage layer. The storage layer is a passive container for ciphertext.

Partitioning Your Filesystem for tiCrypt​

tiCrypt requires storage for three categories of data: Vault chunks, encrypted VM drives, and VM boot images. Each can occupy a separate partition, directory, or namespace on the storage appliance. The only requirement is that the tiCrypt backend service account has read/write access and no other account does.

Directory structure​

A typical shared-filesystem layout for a tiCrypt deployment:

/shared-storage/
├── ticrypt-vault/              # Vault chunk storage
│   └── <file-id>/              # One directory per file
│       ├── 0                   # Chunk 0 (8 MB + 64 bytes)
│       ├── 1                   # Chunk 1
│       └── ...
├── ticrypt-vm-drives/          # Encrypted VM drive pool
│   ├── drive-001.qcow2
│   ├── drive-002.raw
│   └── ...
├── ticrypt-vm-images/          # VM boot images (non-encrypted)
│   ├── ubuntu-22.04.qcow2
│   └── windows-server-2022.qcow2
└── ticrypt-bricks/             # VM brick images
    └── ...

The ticrypt-storage service reads and writes the Vault chunk directory (ticrypt-vault/), configured in its service configuration file. The VM-related directories correspond to libvirt storage pools, configured through tiCrypt's libvirt integration. For details on pool types and their capabilities, see tiCrypt and libvirt Storage Pools.

Coexistence with non-tiCrypt workloads​

The rest of the shared filesystem continues hosting non-CUI workloads: research data, application binaries, and any other content your organization stores. The tiCrypt directories contain only ciphertext, so their presence on the same physical media as non-CUI data creates no confidentiality exposure. The CMMC assessment boundary includes the storage appliance (see Scoping below), but the encryption architecture satisfies the controls, not hardware isolation.

Cryptographic Erase: Sanitization Without Destroying Shared Media​

Data sanitization is one of the strongest arguments for shared storage with tiCrypt. CMMC L2 practice MP.L2-3.8.3 (NIST SP 800-171r2 requirement 3.8.3) requires that media containing CUI be sanitized before disposal or reuse. On dedicated hardware, this typically means physical destruction of drives. On shared storage, physical destruction is not feasible; the same media holds other tenants' active data.

Per-resource encryption eliminates the problem. Each Vault file and each encrypted VM drive has its own independently generated AES-256 key. When a resource is deleted, tiCrypt destroys its key. Once the key is destroyed:

  • The ciphertext remaining on disk is computationally indistinguishable from random noise
  • No method exists to recover the plaintext from the remaining ciphertext
  • No disk-level sanitization (overwrite, degauss, physical destruction) is required
  • The storage space can be immediately reused by any workload

This is cryptographic erase. Destroying the key sanitizes the data. Because every resource has its own key, destroying one key sanitizes one resource without affecting any other data on the same media. The shared filesystem continues operating normally, and the freed space is available for reuse.

CMMC L2 Control Mapping for Joint Storage Deployments​

The following controls are directly relevant when tiCrypt shares a filesystem with other workloads. For each control, the table specifies how the joint deployment satisfies the requirement.

System and Communications Protection (SC)​

PracticeRequirementHow the Joint Deployment Satisfies It
SC.L2-3.13.16Protect confidentiality of CUI at restEvery resource is encrypted with a unique AES-256 key on the client before reaching storage. The shared filesystem holds ciphertext only. Because encryption is per-resource, confidentiality does not depend on storage-layer isolation.
SC.L2-3.13.11Employ FIPS-validated cryptographytiCrypt uses the OpenSSL 3.1.2 FIPS-validated module for all cryptographic operations and implements no custom cryptography. The validated module covers AES-256 (FIPS 197) and RSA-2048 (FIPS 186-5) at the key lengths in use. Within secure VMs and SLURM HPC environments, FIPS mode is enabled at the operating system level.
SC.L2-3.13.8Protect CUI in transitData is encrypted client-side before transmission, and TLS protects the client-to-backend connection. The backend-to-storage connection carries ciphertext only.
SC.L2-3.13.1Monitor and protect boundary communicationsThe enclave boundary is defined at the application layer (tiCrypt backend), not at the storage layer. All data crossing the boundary to storage is ciphertext; the shared filesystem sits outside the plaintext trust boundary.
SC.L2-3.13.2Architectural design for securityClient-side encryption, key isolation from all server components, and user-controlled PKI form the architectural basis. The storage layer is explicitly untrusted by design.

Media Protection (MP)​

PracticeRequirementHow the Joint Deployment Satisfies It
MP.L2-3.8.3Sanitize media before reuse or disposalCryptographic erase: destroying the per-resource AES-256 key renders the ciphertext unrecoverable. No disk-level sanitization required. Shared media can be reused without physical destruction.
MP.L2-3.8.6Protect CUI on media during transportIf the shared filesystem is replicated, backed up, or physically transported, the CUI portion is ciphertext. No plaintext exists outside the client endpoint.
MP.L2-3.8.9Protect confidentiality of backup CUISnapshots, replicas, and backups of the shared filesystem contain only ciphertext for the tiCrypt partition. Key material resides separately in MongoDB as RSA-2048-wrapped blobs. Backups of the storage layer alone cannot produce plaintext.

Access Control (AC)​

PracticeRequirementHow the Joint Deployment Satisfies It
AC.L2-3.1.1Limit system access to authorized usersStorage access is restricted to the tiCrypt service account via filesystem permissions. Data owners govern cryptographic access through PKI key sharing.
AC.L2-3.1.2Limit access to permitted transactions and functionsThe storage service account holds only read, write, and delete permissions on chunk/drive files. No execute permission, no access to directories outside the tiCrypt partition.
AC.L2-3.1.3Control CUI flow per approved authorizationsCUI flows only through tiCrypt's encrypted channels. The storage layer is a passive recipient of ciphertext. Data owners explicitly control who receives wrapped keys.
AC.L2-3.1.5Employ least privilegeThe tiCrypt directories are restricted to the minimum set of service accounts. Storage administrators can access the ciphertext but cannot decrypt it.

Audit and Accountability (AU)​

PracticeRequirementHow the Joint Deployment Satisfies It
AU.L2-3.3.1Create and retain system audit logstiCrypt logs all file operations, key operations, and access events at the application layer. The storage layer's native audit logging, if available, provides a complementary record of filesystem-level access.
AU.L2-3.3.2Ensure individual accountabilityEvery tiCrypt operation is tied to an authenticated session with cryptographic identity. Storage-layer access logs show the tiCrypt service account, which correlates to application-layer audit records for per-user attribution.

Scoping the Shared Storage Appliance​

When a shared filesystem holds CUI, even encrypted CUI, it enters the CMMC assessment scope. Encryption does not remove the appliance from scope. It changes which controls the appliance must satisfy independently and how easily it satisfies them.

The shared storage appliance is best classified as a Security Protection Asset (SPA) under CMMC Level 2 scoping guidance. It provides a security-relevant function (durable, available storage of encrypted CUI) but has no access to keys or plaintext. A conservative assessor may classify it as a CUI Asset, which brings the full control set to bear. Under tiCrypt's architecture, the appliance satisfies the applicable controls under either classification. The classification affects documentation volume, not feasibility.

Document the cryptographic scoping rationale explicitly in your SSP. The assessment team should evaluate a deliberate architectural decision, not an undocumented one.

caution

Do not attempt to argue the storage appliance out of scope. The stronger position is to scope it in and demonstrate that every applicable control is satisfied by the encryption architecture. An assessor who sees a ciphertext-only storage layer inside the boundary has nothing to challenge. An assessor who sees you trying to exclude it has a finding.

What Your SSP Must Document​

For a joint storage deployment, your System Security Plan should include the following:

  1. Cryptographic scoping rationale. State that the shared storage holds only ciphertext, that data owners hold keys exclusively on client endpoints, and that the encryption architecture provides confidentiality. Reference the specific SC and MP controls listed above.

  2. Data flow diagram. Show where plaintext exists (client endpoint and secure-compute VM memory only) and where ciphertext resides (shared filesystem, MongoDB, backups, replicas). The diagram must show that the storage layer sits outside the plaintext boundary.

  3. Partition and permission documentation. Document the directory structure, filesystem permissions, and service account assignments for the tiCrypt storage directories. Show that least privilege is enforced.

  4. Sanitization procedure. Document cryptographic erase as the sanitization method for MP.L2-3.8.3. Describe the key destruction process, including escrowed and backed-up key copies.

  5. Shared responsibility boundary. Identify which controls tiCrypt satisfies (encryption, key management, application-level audit) and which the organization must satisfy independently (physical security, filesystem-level access control, infrastructure monitoring, backup procedures).

  6. Asset classification. State the CMMC asset classification for the shared storage appliance (Security Protection Asset or CUI Asset) and justify the classification based on the appliance's relationship to CUI.

Dedicated storage for CUI is not a CMMC requirement. Confidentiality is. tiCrypt's client-side encryption satisfies that requirement at the cryptographic layer, making the storage medium irrelevant to the security of the data it holds.

Further Reading​