tiCrypt has no hardware vendor lock-in. It runs on commodity x86_64 servers, standard networking, and whatever storage you already have. But "hardware agnostic" does not mean "no requirements."
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.
tiCrypt delegates VM storage to libvirt storage pools, but not every pool type can create volumes on demand. This article explains which pool types support dynamic provisioning and how encrypted data drives map onto network block-device backends like Ceph RBD and iSCSI.
tiCrypt is composed of several distinct components that communicate over tightly controlled channels. This article walks through the functional architecture of a tiCrypt deployment, explaining how requests flow from the user's workstation through the backend and into secure compute nodes. For infrastructure planning and deployment sizing, see Understanding tiCrypt Infrastructure.
The "traditional" LibVirt networking is based on Linux bridges. This architecture is simple yet effective for providing networking connectivity to VMs. If the VMs run on a single server, this architecture is sufficient. However, if the VMs run on multiple servers, the Linux bridge architecture becomes more complex and less efficient. Specifically, in the case of tiCrypt, it creates the following issues:
nat, route, and open) setups. This makes it difficult to deal with custom firewall rules on hosts and backend.Planning a tiCrypt deployment starts with understanding the infrastructure that powers it. This guide walks through the core components, how they connect, and the deployment architectures available, from a lightweight demo system to a full-scale production environment with batch processing. For a detailed walkthrough of how traffic flows between these components, see tiCrypt Functional Architecture.
Note: This guide covers infrastructure planning and setup. The tiCrypt installation and software deployment process is covered separately.
The tiCrypt Vault offers a file system-like facility that allows files and directories to be created and used. All the metadata, such as file properties, directory entries, access information, and decryption keys, are stored in the MongoDB database used by the tiCrypt-file storage service.
In tiCrypt Vault, the file content is broken into 8MB chunks, each encrypted independently using the file key. The size of such chunks is 8MB+64Bytes on disk (unless they are the last, incomplete chunk). The extra 64Bytes contain the IV (initialization vector for AES encryption). For each file, the chunks are numbered from 0 onwards. The chunks are stored in a directory structure based on the file ID, visible only to the tiCrypt backend (preferably not to the VM hosts). The storage location can be configured in the configuration file of the tiCrypt-storage service.
tiCrypt is not opinionated on the file system or integration with other systems for this storage, but for compliance reasons, it is recommended that the access is restricted to only the tiCrypt backend.
Without the decryption keys that only users can recover, the content of the chunk files is entirely indecipherable. It is safe to back up these files using any method (including non-encrypted backup, cloud, etc). The strong encryption, coupled with the unavailability of the key to even administrators, ensures that this content can be replicated outside the secure environment from a compliance point of view.