Cryptographic Isolation for CUI on Shared Storage
How tiCrypt's client-side encryption, key isolation, and PKI enable a shared file system to host a CUI enclave.
The Case Against Physical Isolation
Organizations establishing a Controlled Unclassified Information (CUI) enclave for CMMC Level 2 routinely assume that the storage layer must be physically dedicated: separate appliances, separate media, and a hard boundary between the regulated environment and everything else. For research institutions and HPC centers, this assumption is often the single most expensive component of the compliance effort.
CMMC Level 2 does not mandate physical isolation of CUI at rest. It mandates that the confidentiality of CUI be protected. Physical isolation is one method of satisfying that requirement. Cryptography is another, and under tiCrypt's architecture it produces a more auditable result.
The consequence is significant: a CUI enclave can reside on a partition of existing shared storage, or on a shared appliance serving multiple environments, and remain fully compliant, because the security of the data does not depend on the hardware.
How Cryptography Replaces Physical Separation
Isolation is provided by client-side encryption and key isolation, not by partitioning. A shared file system can host a CUI enclave when the storage layer never holds keys or plaintext; it receives and stores only ciphertext. Under these conditions, physical co-residency (other tenants' data on the same media) does not disclose CUI, because nothing on the media is readable by any party without the keys.
Partitioning and cryptographic erase are supporting mechanisms that strengthen the architecture. They are not the control of record. Isolation is established by encryption, applied at the client, before data reaches shared media.
The architecture, not the hardware, determines compliance. A NAS with logical separation but no client-side encryption would fail the confidentiality requirements -- and the gap typically surfaces only at assessment.
The Controls That Matter: At-Rest and In-Transit
Three NIST 800-171 / CMMC requirements carry the at-rest and in-transit argument:
| Requirement | What It Requires | What tiCrypt Does |
|---|---|---|
| SC.L2-3.13.16 | Protect the confidentiality of CUI at rest | Encryption satisfies this control at the data layer, regardless of the hardware on which the ciphertext resides |
| SC.L2-3.13.11 | Employ FIPS-validated cryptography to protect CUI confidentiality | The cryptographic module carries a current CMVP validation covering the operations in use: data-at-rest encryption and key wrapping within a defined cryptographic boundary |
| SC.L2-3.13.8 | Use cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission | CUI is encrypted on the client before transmission, and the connection is protected with TLS, providing two independent layers of encryption in transit |
SC.L2-3.13.11 is the foundational requirement. Two conditions must hold: the module must carry a current CMVP validation, and encryption must be controlled by the data owner -- not the platform, storage layer, or an administrator. Server-side encryption with provider-managed keys is not sufficient, even when FIPS-validated, because confidentiality depends on key material only the data owner possesses. tiCrypt meets both conditions by design: validated cryptography, with private keys that never leave the client.
Three Pillars: Client-Side Encryption, Key Isolation, and PKI
tiCrypt's cryptographic isolation rests on three components:
Client-side encryption. Every resource -- files, encrypted virtual drives, and other protected objects -- is encrypted at the endpoint with its own unique AES-256 key before it crosses the wire to storage. The shared file system receives and persists ciphertext only. No plaintext is ever written to shared media.
Key isolation. The storage layer has no access to keys. Key material resides in a separate key-management plane that the storage appliance cannot reach. Because the appliance cannot decrypt what it holds, physical co-residency with other tenants is not a confidentiality exposure.
PKI. Per-user and per-group keys, key wrapping, and controlled key recovery are administered through a public-key infrastructure that is an integral part of the security architecture. The location of private keys, the administration of the certificate authority, and the governance of key recovery are architectural properties of the system, documented in the SSP.
Why the Data Owner Controls Everything
The critical distinction between this architecture and server-side encryption is who holds the keys. In tiCrypt, the keys are held by the data owner, not by the platform, the administrator, or the storage layer.
Each user generates a key pair at account creation. The private key is encrypted with the user's password on the client and never leaves the user's possession; no copy exists on the server. Every resource is encrypted with a unique AES-256 key at creation, and that resource key is then wrapped (encrypted) with the public key of each authorized user.
Sharing a resource never decrypts it on the server. The owner's client unwraps the resource key with their private key, re-wraps it with the recipient's public key, and deposits the wrapped key on the server. The recipient's client unwraps it with their own private key. At no point does the server, the storage layer, or any administrator see the resource key or the plaintext.
The consequences for a CUI environment:
- Administrators cannot read data. They manage the platform but never possess decryption keys. A compromised administrator account does not constitute a data breach.
- The storage layer cannot read data. It holds ciphertext and wrapped key blobs; without the corresponding private key, neither is useful.
- Access is explicit, not implicit. A user can decrypt a resource only if the owner (or an authorized party) has wrapped the resource key for that user. There is no master key and no server-side override.
- Revocation is immediate. Removing a user's wrapped key blob removes that user's ability to decrypt any data not already copied out.
This is what makes shared storage viable for CUI: the confidentiality guarantee does not depend on who can reach the storage hardware. It depends entirely on who holds the private keys, and that is always the data owner.
The same architecture also protects integrity. Digital signatures on encrypted data and key operations make tampering detectable, satisfying SC.L2-3.13.12 and SC.L2-3.13.13.
For a full description of tiCrypt's cryptographic architecture, see the Security Whitepaper.
In the SSP, this design is substantiated with a data-flow diagram showing where plaintext exists (client endpoint and secure-compute memory only) and where ciphertext exists (shared storage, replication targets, snapshots, and backups).
Logical Partitioning: The Second Layer
Partitioning the shared file system -- through a dedicated tenant, view, or namespace with role-based access control -- provides a second, independent layer of separation. It is sound practice, but it is not the layer that satisfies the confidentiality requirement.
The relevant Access Control requirements:
| Requirement | What It Governs |
|---|---|
| AC.L2-3.1.1 | Limit system access to authorized users |
| AC.L2-3.1.2 | Limit access to permitted functions |
| AC.L2-3.1.3 | Control the flow of CUI in accordance with approved authorizations |
| AC.L2-3.1.5 | Least privilege |
| AC.L2-3.1.7 | Prevent non-privileged users from executing privileged functions |
AC.L2-3.1.1 through 3.1.3 are satisfied by the tenancy and RBAC boundary on the storage platform. AC.L2-3.1.5 and 3.1.7 are enforced at both the storage layer (administrator role separation) and the cryptographic layer (administrators cannot decrypt data regardless of their platform privileges).
Cryptography provides the primary isolation; partitioning provides defense in depth.
Cryptographic Erase: Sanitization Without Destroying Drives
Cryptographic erase addresses the most difficult problem in shared-media CUI hosting: sanitization and reuse. MP.L2-3.8.3 requires that media containing CUI be sanitized or destroyed before disposal or release for reuse. On dedicated infrastructure, sanitization frequently means physical destruction of drives. On a shared file system, physical destruction is not feasible, because the same media holds other tenants' active data.
Per-resource encryption resolves this. Each resource -- whether a Vault file or an encrypted virtual drive -- has its own independently generated AES-256 key. When a resource is deleted, the system destroys that key, which was the sole means of decrypting it. Once the key is destroyed:
- The ciphertext remaining on disk is computationally indistinguishable from random noise
- No method exists to reconstruct the original content
- No disk-level sanitization (overwrite, degauss, destruction) is required
This is cryptographic erase: destroying the key sanitizes the data. Because every resource has its own independently generated key, destroying one key sanitizes one resource without affecting any other data on the same media. Shared media can be re-provisioned across tenants, or decommissioned, without physical destruction.
Cryptographic erase is only as strong as the encryption it relies on. Data must be encrypted before it is written, the cryptography must be CMVP-validated, and every copy of the key -- including escrowed and backup copies -- must be verifiably destroyed. tiCrypt's deletion procedure maps explicitly to MP.L2-3.8.3 as a documented, repeatable process.
Bringing the Storage Appliance into Scope
When the shared file system holds CUI, including encrypted CUI, it enters the CMMC assessment scope. Encryption does not change the classification of the information: CUI that has been encrypted is still CUI. What changes is whether the storage layer is capable of disclosing it, and under this architecture the answer is no.
The practical question is which asset category applies under the CMMC Level 2 scoping guidance. Because the appliance has no access to keys or plaintext and provides a security-relevant function (durable, available storage of protected CUI), treating it as a Security Protection Asset is a defensible position and a reasonable basis for control scoping. A conservative assessor may still classify it as a CUI Asset, which brings the full control set to bear on the appliance. The architecture satisfies the applicable controls under either classification, so the determination affects documentation rather than feasibility.
In either case, the decisive step is the same: the SSP documents the cryptographic scoping rationale explicitly, so the assessment team evaluates a deliberate design decision rather than an undocumented one.
Do not claim that ciphertext-only storage is out of scope entirely. Some practitioners argue this by analogy to encrypted cloud-at-rest cases, but the DoD scoping guidance does not clearly support it and the determination is an assessor judgment call. The stronger position: scope the appliance in and let the cryptography carry the controls.
Control Mapping
The tables below map tiCrypt's cryptographic isolation to the relevant NIST 800-171 / CMMC Level 2 requirements, organized by control family.
System and Communications Protection
| Requirement | What It Requires | What tiCrypt Does |
|---|---|---|
| SC.L2-3.13.16 | Protect confidentiality of CUI at rest | Each resource (file, encrypted drive) is encrypted with a unique AES-256 key on the client before reaching storage. Shared media holds ciphertext only. |
| SC.L2-3.13.11 | FIPS-validated cryptography for CUI confidentiality | A CMVP-validated module covers all encryption and key-wrapping operations. User-controlled PKI ensures private keys never leave the client. |
| SC.L2-3.13.8 | Protect CUI in transit | Data is encrypted client-side before transmission and carried over TLS. The storage layer receives ciphertext over an encrypted channel. |
| SC.L2-3.13.1 | Monitor and protect boundary communications | A defined enclave boundary separates the encrypted CUI environment from the shared storage layer. All data crossing the boundary is ciphertext. |
| SC.L2-3.13.2 | Employ security-effective architectural designs | Separation by cryptography: client-side encryption, key isolation from storage, and user-driven PKI form the architectural basis. |
| SC.L2-3.13.12 | Protect CUI integrity | Digital signatures on encrypted data and key operations detect tampering. Modifications to ciphertext or key blobs are identifiable. |
| SC.L2-3.13.13 | FIPS-validated cryptography for CUI integrity | The same CMVP-validated module covers integrity operations (signatures, key verification). |
Media Protection
| Requirement | What It Requires | What tiCrypt Does |
|---|---|---|
| MP.L2-3.8.3 | Sanitize media before reuse or disposal | Cryptographic erase: destruction of the per-resource key renders the ciphertext unrecoverable. No disk-level sanitization is required. |
| MP.L2-3.8.6 | Protect CUI during media transport | Media in transport (drives, tapes, replication) carries ciphertext only. No plaintext exists outside the client endpoint. |
| MP.L2-3.8.9 | Protect CUI backups | Snapshots, replicas, and backup targets contain only ciphertext. Key material is never stored with the backup data. |
Access Control
| Requirement | What It Requires | What tiCrypt Does |
|---|---|---|
| AC.L2-3.1.1 | Limit system access to authorized users | Storage tenancy and namespace separation. Encryption-key sharing is controlled by the data owner via PKI. |
| AC.L2-3.1.2 | Limit access to permitted functions | RBAC on the storage platform. Resource-level access is enforced cryptographically; only users holding a wrapped key blob can decrypt. |
| AC.L2-3.1.3 | Control CUI flow per approved authorizations | The data owner explicitly shares resource keys with authorized recipients. No implicit access, no administrative override. |
| AC.L2-3.1.5 | Least privilege | The storage management plane is restricted to authorized administrators. Administrators cannot decrypt data. |
| AC.L2-3.1.7 | Restrict privileged functions | Administrative access to storage is role-separated from data access. Privilege on the platform does not grant privilege over CUI. |
Audit and Accountability
| Requirement | What It Requires | What tiCrypt Does |
|---|---|---|
| AU.L2-3.3.1 | Create audit logs | All storage management actions and encryption-platform access events are logged. |
| AU.L2-3.3.2 | Trace actions to individual users | Logs attribute every file operation, key share, and administrative action to an authenticated identity. |
| AU.L2-3.3.7 | Time synchronization | Storage and encryption platforms use synchronized time sources (NTP). |
| AU.L2-3.3.8 | Protect audit data | Audit logs are integrity-protected and stored independently from the data they describe. |
Identification and Authentication
| Requirement | What It Requires | What tiCrypt Does |
|---|---|---|
| IA.L2-3.5.2 | Authenticate users and devices | PKI-based authentication using digital signatures. No passwords are stored on the server. |
| IA.L2-3.5.3 | MFA for privileged and network access | Multi-factor authentication is enforced on administrative access to the storage and encryption platforms. |
Configuration Management and Physical Protection
| Requirement | What It Requires | What tiCrypt Does |
|---|---|---|
| CM.L2-3.4.1 | Establish baseline configurations | The storage appliance runs a documented, version-controlled baseline configuration. |
| CM.L2-3.4.2 | Enforce security configuration settings | Configuration is enforced through automation. Deviations from baseline are detected and remediated. |
| PE.L2-3.10.1 | Limit physical access | The storage appliance remains physically protected within the assessment boundary (data center, locked facility). Cryptographic isolation replaces dedicated hardware, not physical security. |
Security That Does Not Depend on the Hardware
Every guarantee in this architecture is enforced by cryptography rather than by trust in infrastructure or personnel. Plaintext exists only at the client endpoint and in secure-compute memory. Keys exist only with the data owner. The storage layer, regardless of who operates it or what else it hosts, holds nothing it can read, nothing an administrator can disclose, and nothing a physical breach of the appliance can expose.
Shared storage is therefore not a compromise under tiCrypt. Confidentiality is enforced by the encryption, access is enforced by possession of keys, and sanitization is enforced by key destruction. Physical isolation is one method of protecting CUI. Cryptographic isolation achieves the same protection on shared media, with stronger auditability and without dedicated hardware.