tiCrypt Security Architecture

ticrypt-security-model

ticrypt ~#

A fully compromised tiCrypt server produces no data breach.

Every file, drive, and communication channel is encrypted with keys that never exist on the server. A breached server yields ciphertext -- computationally indistinguishable from random noise without the user-controlled keys needed to read it. This is not a secondary defense layer. It is the architecture.

tiCrypt is built on a principle we call zero-knowledge infrastructure: the server operates on data it cannot read, manages keys it cannot use, and authenticates users without ever learning their credentials. Traditional security mechanisms -- perimeter defenses, network segmentation, access control lists -- assume the server is trustworthy. When that assumption fails, the data is exposed. tiCrypt eliminates the assumption entirely.

Threat Status: Critical

• Server breach exposes all data in plaintext
• Rogue admin can read, copy, or exfiltrate any file
• Stolen backup = complete data breach
• Database dump contains readable records
• Encryption keys stored alongside data on server
• Security depends on perimeter integrity

Threat Status: Neutralized

• Server breach exposes only ciphertext
• Admins are cryptographically excluded from data
• Stolen backup = encrypted blobs, no keys
• Database contains RSA-wrapped key material only
• Decryption keys exist only on user endpoints
• Security is intrinsic to the data itself

Security Principles

tiCrypt is built on three foundational principles: data confinement through encryption, public-key cryptography, and end-to-end encryption. Every security feature in the platform derives from the combination of these principles.

Data Confinement Through Encryption

Traditional data confinement relies on access control lists (ACLs). The problem with ACLs is that administrators control them, and attackers who compromise an administrator account inherit that same power. This is the root cause behind privilege-escalation breaches (CWE-269: Improper Privilege Management).

tiCrypt enforces data confinement cryptographically -- the foundation of its zero-knowledge infrastructure. Each file is encrypted at creation with a unique, randomly generated AES-256 key (FIPS 197). That key is then encrypted with the public keys of authorized users and stored on the server. Encryption occurs on the client before data leaves the application; decryption occurs only on the recipient's client. This architecture satisfies CMMC Level 2 practices SC.L2-3.13.16 (protecting CUI at rest) and SC.L2-3.13.8 (protecting CUI in transit).

File sharing involves no server-side decryption. The entire key-transfer process executes in the file owner's client application:

1. The encrypted file key is retrieved from the server.
2. The owner decrypts the key using their private key.
3. The key is re-encrypted with the recipient's public key.
4. The re-encrypted key is deposited on the server.

The private key never leaves the owner's client. Only public keys are available to other parties.

Public-Key Cryptography

Public-key cryptography uses a key pair: a public key known to everyone, and a private key known only to its owner. Data encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. This asymmetry enables both secure data exchange and digital signatures without requiring pre-shared secrets.

tiCrypt uses RSA-2048 key pairs to wrap per-file AES-256 keys and to produce digital signatures. All RSA operations are performed by the FIPS-validated cryptographic module operating in FIPS mode (the OpenSSL 3.1.2 FIPS provider, CMVP certificate #4985); tiCrypt implements no cryptography of its own, so key-encapsulation and signature operations run only in the module’s approved modes. RSA-2048 provides 112 bits of security strength, approved for government use under FIPS 186-5 (Digital Signature Standard) and validated per FIPS 140-3 (Security Requirements for Cryptographic Modules). Key management follows the guidelines in NIST SP 800-57 Part 1, Rev. 5 (Recommendation for Key Management), which approves 112-bit security strength through 2030.

Each user generates a key pair at account creation. This single key pair powers all of tiCrypt's core security functions:

• Authentication: The user decrypts their private key using their password, signs a server-issued nonce (challenge-response protocol), and the server verifies the signature against the stored public key. No password is ever sent to or stored by the server. This satisfies CMMC Level 2 practices IA.L2-3.5.2 (authenticate identities), IA.L2-3.5.4 (replay-resistant authentication), and IA.L2-3.5.10 (cryptographically-protected passwords).
• File Sharing: Files are shared by encrypting the per-file AES-256 key with the recipient's RSA-2048 public key. No passwords or shared secrets need to change hands.
• Certificates: Digitally signed instructions (using the owner's RSA private key) authorize other users to perform operations on the owner's behalf, providing non-repudiation.

Technical Deep Dive: RSA-2048 Key Generation and Operations

RSA key pairs are constructed from two secret large primes $p$ and $q$, each approximately 1024 bits. The public modulus is their product:

$n = p \cdot q$

Euler's totient of $n$ is:

$\phi(n) = (p - 1)(q - 1)$

A public exponent $e$ is chosen such that $1 < e < \phi(n)$ and $\gcd(e,\, \phi(n)) = 1$. tiCrypt uses the standard value $e = 65537$ ($= 2^{16} + 1$), which is a Fermat prime that makes modular exponentiation efficient while maintaining security. The private exponent $d$ is the modular multiplicative inverse of $e$:

$d \equiv e^{-1} \pmod{\phi(n)}, \qquad \text{i.e.,} \quad e \cdot d \equiv 1 \pmod{\phi(n)}$

The public key is the pair $(n,\, e)$. The private key is $d$, kept secret along with $p$, $q$, and $\phi(n)$.

Encryption and Decryption

To encrypt a plaintext message $m$ where $0 \le m < n$:

$c \equiv m^e \pmod{n}$

To decrypt ciphertext $c$:

$m \equiv c^d \pmod{n}$

Correctness follows from Euler's theorem. Since $ed \equiv 1 \pmod{\phi(n)}$, there exists an integer $k$ such that $ed = 1 + k\phi(n)$. Then:

$c^d \equiv (m^e)^d \equiv m^{ed} \equiv m^{1 + k\phi(n)} \equiv m \cdot (m^{\phi(n)})^k \equiv m \cdot 1^k \equiv m \pmod{n}$

Digital Signatures and Authentication

Signing reverses the operation: the signer applies their private key to a hash of the message. tiCrypt uses SHA-256 as the hash function $H$:

$\sigma \equiv H(m)^d \pmod{n}$

Any party with the signer's public key can verify the signature:

$H(m) \stackrel{?}{\equiv} \sigma^e \pmod{n}$

In tiCrypt's authentication protocol, the server issues a random nonce $r$. The user computes $\sigma \equiv H(r)^d \pmod{n}$ and returns $\sigma$. The server checks $\sigma^e \equiv H(r) \pmod{n}$ against the stored public key. The private key $d$ is never transmitted; only the signature is.

Security: The Integer Factorization Problem

The security of RSA rests on the hardness of recovering $p$ and $q$ from $n$. The best known classical algorithm for this is the General Number Field Sieve (GNFS), which runs in sub-exponential time:

$T_{\text{GNFS}} = \exp\!\left(\left(\tfrac{64}{9}\right)^{1/3} (\ln n)^{1/3} (\ln \ln n)^{2/3}\right)$

For a 2048-bit modulus, this evaluates to roughly $10^{23}$ basic operations, far exceeding the capacity of any foreseeable classical computing system. Even a cluster of $10^{15}$ machines each performing $10^{15}$ operations per second would require $\approx 10^7$ years to factor a single RSA-2048 modulus.

Computation Result

10⁷ years

The time required to factor a single RSA-2048 key, even with a hypothetical cluster of 10¹⁵ machines each performing 10¹⁵ operations per second.

Quantum Computing Considerations

A sufficiently large quantum computer running Shor's algorithm could factor RSA-2048 in polynomial time, rendering the integer factorization problem tractable. AES-256 faces a lesser quantum threat: Grover's algorithm halves the effective key length to 128 bits, which remains computationally infeasible. tiCrypt's architecture is designed for cryptographic agility. Because all encryption is performed in the client application through the OpenSSL FIPS module, the cryptographic primitives can be upgraded to NIST post-quantum standards (ML-KEM for key encapsulation, ML-DSA for digital signatures) without changes to the server infrastructure, the storage layer, or the zero-knowledge security model. The server never interprets cryptographic material; it stores and forwards opaque ciphertext regardless of the underlying algorithm. For a detailed analysis of the quantum threat timeline and tiCrypt's migration path, see Separating Threat from Hype with Quantum Computing.

End-to-End Encryption

End-to-end encryption means data is encrypted as early as possible and decrypted as late as possible, only by the intended recipient and only at the moment of use. No intermediate party, including system administrators and the tiCrypt backend, can access the data in transit or at rest.

This is strictly stronger than encryption-in-transit (TLS), which allows anyone with access to the server's private key to decrypt traffic. Even if tiCrypt's TLS certificate were compromised, end-to-end encryption would keep the data secure independently, eliminating the entire class of man-in-the-middle attacks (CWE-300) against data confidentiality.

Encryption occurs on the client side with keys controlled exclusively by the user. If a file is accessed or shared multiple times, it is decrypted each time from the ciphertext. No unencrypted copies persist in intermediate storage, satisfying CMMC Level 2 practice SC.L2-3.13.16 (protecting CUI at rest).

All data in tiCrypt is encrypted at a uniform level: AES-256 (FIPS 197), providing 256 bits of symmetric security strength per NIST SP 800-131A, Rev. 2. There are no tiers of security. Since the performance difference between AES-128 and AES-256 is minor (roughly 20% on modern hardware with AES-NI instruction support), there is no practical reason to accept weaker protection for any resource. The net result of these three principles is that every resource is encrypted with a unique key before it leaves the user's device, and the server never holds a key capable of decrypting anything.

Technical Deep Dive: AES-256 Block Cipher Construction

AES (Advanced Encryption Standard) is a substitution-permutation network (SPN) block cipher standardized by NIST in FIPS 197. It operates on a fixed 128-bit (16-byte) block of data arranged as a $4 \times 4$ byte matrix called the state. AES-256 uses a 256-bit key and applies 14 rounds of transformation. All arithmetic is performed in the finite field $\mathbb{F}_{2^8} = \mathbb{F}_2[x]\,/\,(x^8 + x^4 + x^3 + x + 1)$, where each byte represents a degree-7 polynomial over $\mathbb{F}_2$.

State Representation

The 16 input bytes are loaded into the state matrix $S$ as columns, giving elements $s_{r,c}$ for row $r \in \{0,1,2,3\}$ and column $c \in \{0,1,2,3\}$. Each element is a byte, an element of $\mathbb{F}_{2^8}$.

Round Structure

Each round (except the last) applies four operations in sequence:

1. SubBytes: Non-linear substitution

Each byte $b$ in the state is replaced by a value from the AES S-box. The S-box is constructed from two steps in $\mathbb{F}_{2^8}$:

• Compute the multiplicative inverse: $b \mapsto b^{-1}$ (with $0^{-1} = 0$ by convention)
• Apply the affine transformation over $\mathbb{F}_2^8$:

$S(b) = A \cdot b^{-1} \oplus \texttt{0x63}$

where $A$ is the fixed $8 \times 8$ binary circulant matrix defined in the AES specification. The non-linearity of the modular inversion step is what makes the cipher resistant to algebraic and linear attacks.

2. ShiftRows: Inter-column diffusion

Row $r$ of the state is cyclically shifted left by $r$ byte positions:

$s_{r,c} \leftarrow s_{r,\,(c + r) \bmod 4}$

Row 0 is unchanged; rows 1, 2, and 3 shift left by 1, 2, and 3 positions respectively. This ensures that after two rounds, every column of the state contains bytes that originated from all four columns of the input.

3. MixColumns: Linear mixing within columns

Each column $[s_{0,c},\, s_{1,c},\, s_{2,c},\, s_{3,c}]^T$ is multiplied by a fixed $4 \times 4$ MDS matrix over $\mathbb{F}_{2^8}$:

$\begin{pmatrix} s'_{0,c} \\ s'_{1,c} \\ s'_{2,c} \\ s'_{3,c} \end{pmatrix} = \begin{pmatrix} 02 & 03 & 01 & 01 \\ 01 & 02 & 03 & 01 \\ 01 & 01 & 02 & 03 \\ 03 & 01 & 01 & 02 \end{pmatrix} \begin{pmatrix} s_{0,c} \\ s_{1,c} \\ s_{2,c} \\ s_{3,c} \end{pmatrix}$

Coefficients are elements of $\mathbb{F}_{2^8}$: $\texttt{02}$ denotes multiplication by $x$ (a left shift with conditional XOR of $\texttt{0x1B}$), and $\texttt{03}$ denotes multiplication by $x + 1$. This matrix is an MDS (Maximum Distance Separable) matrix, which guarantees that any non-zero difference in a column input produces differences in all four output bytes (the strict avalanche criterion). Combined with ShiftRows, after just two rounds every output byte depends on every input byte.

4. AddRoundKey: Key injection

Each byte of the state is XORed with the corresponding byte of the round key $K^{(r)}$ derived from the key schedule:

$s_{r,c} \leftarrow s_{r,c} \oplus k^{(r)}_{r,c}$

The final round applies SubBytes, ShiftRows, and AddRoundKey only; MixColumns is omitted to make encryption and decryption structurally symmetric.

Key Schedule

The 256-bit master key is expanded into 15 round keys (one for the initial key addition plus one per round) using the Rijndael key schedule. The schedule generates successive 32-bit words by applying SubBytes, a byte rotation, and XOR with round constants $\text{Rcon}[i] = x^{i-1} \in \mathbb{F}_{2^8}$. For AES-256, an additional SubBytes application is inserted every other word to prevent the symmetry that could arise from the larger key size.

Security

AES-256 provides a key space of $2^{256} \approx 1.16 \times 10^{77}$ possible keys. At $10^{18}$ guesses per second (well beyond any present hardware), exhaustive search would require approximately $3.67 \times 10^{50}$ years. The best published cryptanalytic attack (biclique, 2011) achieves a complexity of $2^{254.4}$, an entirely negligible practical improvement. The SPN construction provably bounds the probability that any non-trivial differential or linear trail through four rounds is at most $2^{-128}$, giving AES its formal resistance to both differential and linear cryptanalysis.

Key Space

2²⁵⁶

Possible AES-256 keys -- more than the number of atoms in the observable universe. At 10¹⁸ guesses per second, exhaustive search would take 3.67 × 10⁵⁰ years.

Combined Security Model

Each file in tiCrypt is protected under a hybrid encryption scheme: AES-256 encrypts the file data using a randomly generated per-file symmetric key, while RSA-2048 encrypts that key under each authorized user's public key. This hybrid approach, recommended by NIST SP 800-175B, Rev. 1 (Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms), combines the performance of symmetric encryption with the key-distribution advantages of asymmetric cryptography.

An attacker must break at least one of two independent hardness problems: the integer factorization problem to recover the file key from its RSA-encrypted form, or the AES block cipher to recover plaintext without the key. No known attack achieves either at the key lengths tiCrypt uses. Because the two problems are mathematically independent, progress against one provides no leverage against the other.

Zero-Knowledge Demonstration

What you see

Patient: Sarah Chen, DOB: 04/12/1983, MRN: 7284931

Decrypted on your device with your private key

What the server sees

d3cf579be97da9159afae66e1dc19454 eb475d89cc345000e65624b439ad3b3f 4be743d78f4bce86871390b0ea3a9cbc 7175c86845296e665840736787837f73 9a9adf03e509cfe3aba76434ac34dc7c cd614e96a58953973d7174c465a995f1 78c077bbe9f70513212f3d4b59677583

AES-256 ciphertext. No keys on server. No decryption possible.

Attack Scenarios and Mitigations

Zero-knowledge infrastructure produces the same outcome regardless of how the system is compromised. The following scenarios demonstrate this property.

Breach Simulation // Select Attack Vector

Attack Vector

Server Breach

An attacker gains root access to the tiCrypt backend server, including the database.

[EXECUTE]

Attack Vector

Rogue Administrator

A system administrator with full infrastructure access decides to exfiltrate data.

[EXECUTE]

Attack Vector

Stolen Backup

Backup tapes or storage snapshots are stolen or fall into the wrong hands.

[EXECUTE]

Attack Vector

Zero-Day Exploit

An unpatched vulnerability gives an attacker persistent access to the backend.

[EXECUTE]

Server Misconfiguration

Threat

A misconfigured or improperly rebooted server can disable authentication, leaving the system open to unauthorized access (CWE-306: Missing Authentication for Critical Function).

Mitigation

In tiCrypt, a fully disabled authentication server still exposes nothing useful. All accessible data is encrypted with keys held only by individual users' clients. No server misconfiguration, regardless of severity, allows tiCrypt to leak unencrypted data.

Insider Threats

Threat

Administrators with broad data access can exfiltrate information before detection (CWE-269: Improper Privilege Management). Traditional audit logs are too slow and voluminous to serve as an effective deterrent.

Mitigation

tiCrypt cryptographically isolates administrators from user data; no administrator privilege level grants access to plaintext. All legitimate access flows through the tiCrypt system and is captured in the tamper-evident audit log. Audit log analysis can surface irregularities within minutes. Rogue administrator activity is structurally visible in a way it is not in traditional systems. This directly addresses CMMC Level 2 practices AC.L2-3.1.5 (least privilege) and AU.L2-3.3.1 (system-level auditing).

Authentication Attacks

Threat

If an attacker can forge authentication certificates or substitute public keys, they can impersonate users and access shared files (CWE-290: Authentication Bypass by Spoofing).

Mitigation

tiCrypt's chain of trust and crowd security (detailed in the next section) make key substitution detectable. Public key fingerprints (SHA-256 hashes) are stored client-side, outside server control. Any attempt to swap a key is caught by any client that has previously interacted with that user. The trust chain can be independently validated by any user without relying on the server, providing defense against both external attackers and compromised infrastructure.

Zero-Day Exploits

Threat

Zero-day exploits in backend servers (operating system, database, web server) can give attackers access to stored data. High-value data stores make such attacks financially motivated.

Mitigation

tiCrypt's end-to-end encryption renders backend access useless for data exfiltration. Decryption keys are never present on the server. A full server compromise (including root access) makes the system temporarily unavailable, not insecure. Encrypted data remains protected regardless of how long an attacker maintains control of the backend, reducing the impact of any zero-day from data breach to denial of service.

Advanced Security Features

Public Key Signing and Chain of Trust

Public-key cryptography introduces one notable vulnerability: an attacker with server access could substitute a user's public key with one they control, then intercept future file shares encrypted to the fraudulent key (a variant of man-in-the-middle attack, CWE-300).

tiCrypt mitigates this through a hierarchical chain of digital signatures:

• A site key, signed by a hardwired Tera Insights private key, bootstraps the trust root of the entire deployment.
• The site key signs the first super-administrator key; that key signs subsequent administrator keys; and so on, forming a signature chain analogous to X.509 certificate hierarchies.
• Every new user account is approved by an administrator, whose private key signs the new account's public key, cryptographically binding it to the chain of trust.
• Any user can independently verify the full chain of signatures on the client side, without trusting the server.

An attacker cannot inject a fraudulent key without controlling an administrator's private key.

Crowd Security

To further protect key integrity, tiCrypt's frontend locally stores SHA-256 fingerprints (per FIPS 180-4) of every public key it has previously interacted with. When a file is shared with a user, the frontend fetches the user's public key and compares it against the stored fingerprint. Any discrepancy triggers an immediate alert.

This fingerprint data is stored client-side, outside the server's reach. Even with a fully compromised server, an attacker cannot swap keys without detection by any client that has previously interacted with the target user. This mechanism provides a form of key-pinning that does not rely on any centralized certificate authority or server-side trust store.

Secure JavaScript Delivery

Since tiCrypt's frontend is delivered as a standalone desktop application built on Wails, a natural attack vector is injecting malicious code to exfiltrate private keys (CWE-506: Embedded Malicious Code; CWE-829: Inclusion of Functionality from Untrusted Control Sphere). tiCrypt addresses this through three layers of defense:

1. Dependency isolation. All dependencies are bundled into the tiCrypt frontend at build time. No external JavaScript, CSS, or HTML resources are referenced at runtime. Compromised third-party CDNs or supply-chain attacks against open-source packages cannot affect a packaged tiCrypt deployment.
2. Code signing. The frontend bundle is delivered as a digitally signed ZIP archive, with signing keys controlled by two senior Tera Insights executives under dual-control procedures.
3. Local delivery via tiCrypt Connect. tiCrypt Connect serves the frontend locally, automatically verifies and applies updates on new releases, and authenticates all VM traffic, locking sessions if unauthenticated connections are detected.

Key Escrow

Loss of a private key means permanent loss of data access. tiCrypt's key escrow mechanism enables recovery without creating a single point of failure, satisfying the key recovery provisions of NIST SP 800-57 Part 1, Rev. 5.

Recovery requires a minimum of three escrow key holders, each holding an escrow key pair signed by the site key and usable only for escrow operations. The recovery process works as follows:

1. A random AES-256 key share is generated for each escrow key holder and encrypted with that holder's escrow public key (RSA-2048).
2. The user's private key is encrypted with a composite key derived from all individual shares, then stored on the server.

No individual escrow key holder can recover the user's private key alone. All shares must be combined by a designated recovery party. If any single share is missing, recovery is cryptographically impossible. This multi-party escrow design enforces separation of duties (CMMC Level 2 practice AC.L2-3.1.4) and prevents any single administrator from unilaterally accessing user keys. Across the full set of advanced security features, the common thread is that key substitution, malicious code injection, and key loss are all addressed through mechanisms that do not require trusting the server.

Secure Virtual Machines

tiCrypt extends its zero-knowledge infrastructure into the compute layer through encrypted virtual machines (VMs) with a fundamentally different access model from conventional cloud infrastructure.

Access Model

VMs cannot be accessed through console connections, direct SSH logins, or standard remote access tools, all of which could be exploited by a compromised administrator. The only access path is through a secure, mutually authenticated channel within tiCrypt:

1. When a VM starts, it receives the owner's public key.
2. The user and VM perform mutual authentication using their respective RSA-2048 key pairs.
3. A symmetric session key is negotiated via Diffie-Hellman key exchange and used for all subsequent communication, providing forward secrecy for the session.

The result is a double-encrypted channel: data is encrypted with the Diffie-Hellman session key at the application layer and transmitted over an encrypted WebSocket (TLS) transport. The backend is involved only in the initial handshake and never participates in ongoing communication between the user and their VM.

Encrypted Drives

VMs use encrypted drives whose AES-256 keys are generated and managed identically to Vault file keys. The encrypted user-VM channel transmits drive keys at startup; even system administrators with root access to the hypervisor host cannot access drive contents.

Data Store Access

VMs access the main data store through secure sub-sessions, with file keys passed through the encrypted user-VM channel.

Secure Tunnels

tiCrypt Connect establishes a TLS 1.2+ tunnel using FIPS-approved cipher suites (e.g., TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) between the user's computer and the VM, with exclusively public-key authentication and ephemeral session keys providing forward secrecy. No commands can be run on the remote machine through this protocol. It is more restrictive than SSH by design, limiting the tunnel to data transport only.

Outbound Access

VMs have strictly limited outbound network access. Only the tiCrypt backend and explicitly allowlisted licensing servers are reachable. This prevents both accidental and intentional data exfiltration, satisfying CMMC Level 2 practice SC.L2-3.13.6 (network communication denial by default). Even a hijacked VM can only route data through the audited tiCrypt Vault.

Boot Images

VM boot images are immutable and reset automatically on each boot, eliminating persistent malware, rootkits, and other forms of internal compromise. This ensures that each VM session starts from a known-good state. Taken together, VMs operate inside a cryptographic boundary that excludes the hypervisor host, the backend, and the network infrastructure from the session entirely.

Combining tiCrypt with Traditional Defenses

tiCrypt's encryption-first architecture is designed to complement, not replace, traditional security measures. Defense in depth requires that an attacker must defeat both layers to achieve a data breach.

Multi-Factor Authentication

tiCrypt's primary authentication mechanism, private-key signing, is strong on its own. However, a stolen private key used from an unfamiliar machine represents a real risk. MFA addresses this as an independent, additional layer, satisfying CMMC Level 2 practices IA.L2-3.5.3 (multi-factor authentication) and IA.L2-3.5.4 (replay-resistant authentication).

Rather than integrating MFA into the backend (which would create a single point of failure), tiCrypt treats MFA providers as external, independent proof-providers. When a key is used from a machine that has been inactive for a configured period or has never been used by that user, tiCrypt's authentication protocol requires MFA verification before granting access. A stolen key used from an unrecognized machine triggers this check and the request is denied. For a deeper analysis of this design, see Why tiCrypt Uses MFA: But Never Trusts It.

Perimeter and Server Defense

tiCrypt's deployment minimizes the server-side attack surface by design:

• Regular user accounts are not required on the hosting server, eliminating most local privilege-escalation vectors at the source.
• Only two network entry points are required: SSH (port 22) for administrative management and HTTPS (port 443) for the tiCrypt interface. All other ports should be blocked at the host firewall, consistent with CMMC Level 2 practice SC.L2-3.13.6 (deny by default).
• SSH public-key authentication should be enforced for all administrative access, disabling password-based login entirely and rendering brute-force and credential-stuffing attacks ineffective.
• All existing security tools, including firewalls, intrusion detection/prevention systems (IDS/IPS), and host-based auditing, are fully compatible with tiCrypt and provide meaningful additional layers of defense.

Auditing and Compliance

tiCrypt is built to meet NIST SP 800-171r2 and CMMC Level 2 compliance requirements, with particular strength in the AU (Audit and Accountability), SC (System and Communications Protection), and IA (Identification and Authentication) control families. Its audit engine is designed for high-throughput log analysis, making large-scale deployments practical without sacrificing query performance. For a compliance-focused walkthrough of the nine AU practices and SIEM integration, see Satisfying CMMC Level 2 Audit and Accountability Controls. For the audit schema and forensic investigation capabilities, see Usage Reporting and Forensics in tiCrypt Audit.

Secure Audit Logs

Log entries are cryptographically chained using SHA-256 hashing (FIPS 180-4), forming an append-only, tamper-evident structure similar to a hash chain. Any modification to a log entry, including insertion, deletion, or alteration, produces a hash conflict detectable upon audit. Administrators and attackers alike cannot alter the log history without leaving forensic evidence. The audit system is deployed independently from the tiCrypt backend, ensuring that neither administrators nor attackers can alter the record without detection. This satisfies CMMC Level 2 practices AU.L2-3.3.8 (protect audit information), AU.L2-3.3.1 (system-level auditing), and AU.L2-3.3.4 (alert on audit process failure).

Audited Events

tiCrypt tracks over 110 distinct event types across six categories at millisecond precision with UTC timestamps, satisfying AU.L2-3.3.1 (system-level auditing) and AU.L2-3.3.2 (user accountability). Tracked event categories include:

Category	Events
Sessions & Authentication	Certificate requests, challenges, lookups, and deletions
File System	Directory creation, deletion, renaming, and modification
Virtual Machines	Creation, deletion, and proxy registration
Virtual Drives	Attachment, detachment, creation, deletion, and key operations
Files	Creation, deletion, key operations, and chunk-level read/write events
Access Control	Group and user permission creation, deletion, and modification

Infrastructure and Scalability

System Architecture

tiCrypt's backend is composed of ten loosely coupled microservices, each with its own MongoDB database and configuration. Services communicate exclusively over TCP and maintain no shared state. This architecture enforces the principle of least privilege at the service level: a failure or compromise of one service does not grant access to the data or keys held by any other, satisfying CMMC Level 2 practice SC.L2-3.13.2 (architectural design). For a visual walkthrough of how requests flow through these components, see tiCrypt Functional Architecture. For deployment sizing and hardware requirements, see Understanding tiCrypt Infrastructure.

Service	Role
ticrypt-rest	HTTPS entry point for all client requests; reverse-proxied behind Nginx
ticrypt-auth	Authentication, authorization, and global coordination across all services
ticrypt-file-manager	File and directory management
ticrypt-storage	Encrypted chunk storage
ticrypt-vm	Virtual machine lifecycle and Slurm batch integration
ticrypt-proxy	Secure tunnel mediation between users and VMs
ticrypt-logger	Tamper-resistant, append-only audit log
ticrypt-stats	Statistical data collection
ticrypt-notifications	User and system notifications
ticrypt-maintenance	Background maintenance tasks

All client requests enter through ticrypt-rest and are authenticated and authorized by ticrypt-auth before any service acts on them. No service is reachable directly from outside the backend network boundary.

Audit System Isolation

tiCrypt Audit is a dedicated, separately deployed system for log processing, alerting, and ad hoc queries. The backend pushes log data to Audit over a one-way TCP connection on port 25000. There is no return path; Audit cannot issue commands to or query the backend. This unidirectional architecture means security and compliance teams can be granted full access to Audit without receiving any access to the tiCrypt backend, its data, or its user keys. The audit record cannot be altered by anyone with access to the tiCrypt backend; doing so would produce a detectable hash conflict in the cryptographically chained log. This separation satisfies CMMC Level 2 practice AU.L2-3.3.8 (protect audit information and audit logging tools).

Data Ingress Boundary

The data ingress services, ticrypt-sftp and ticrypt-mailbox, are intentionally deployed outside the secure infrastructure perimeter in a DMZ-like configuration. External collaborators can deposit data into the enclave without being granted any access to the backend, the Vault, or user accounts. Files deposited through either channel are encrypted on arrival using the recipient's RSA-2048 public key. The ingress services require only a one-way network path to ticrypt-rest; the backend has no network path back to them. This unidirectional design limits the blast radius of a compromised ingress service.

VM Network Isolation

VMs do not accept direct inbound connections. All ports are blocked at the host firewall and internally within the VM except port 22, which does not run SSH; it is controlled exclusively by the VM controller (ticrypt-vmc) for encrypted tunnel traffic. All VM communication is mediated by ticrypt-proxy over mutually authenticated WebSocket connections with Diffie-Hellman key negotiation. No component between the user and the VM, including ticrypt-proxy itself, can read the session traffic after the initial handshake completes. For a detailed breakdown, see How tiCrypt Isolates Virtual Machines at the Network Level.

Outbound traffic from VMs is fully blocked by default (deny-all policy). The only permitted exception is access to licensing servers configured explicitly through ticrypt-allowedlist, which requires SuperAdmin authorization and operates by manipulating iptables firewall rules and DNS replies on the backend host, not within the VM itself. The VM has no ability to modify its own network policy.

Storage

Vault Storage

Vault file content is divided into 8 MB chunks, each encrypted independently using the file's unique AES-256 key with a per-chunk initialization vector (IV). Each chunk is stored as 8 MB + 64 bytes on disk; the extra 64 bytes hold the IV used for AES-CBC encryption of that chunk. Chunks are numbered from zero and stored in a directory structure keyed to the file ID, accessible only to the tiCrypt backend process, not to VM hosts or any other service.

All metadata, including file properties, directory entries, access control information, and per-file encrypted decryption keys, is stored in MongoDB, physically separated from the chunk data. An attacker with access to the raw chunk files has no path to plaintext without the per-file decryption keys, which only authorized users can recover via their RSA private keys.

A practical consequence of this design is that 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. tiCrypt places no requirement on the underlying filesystem for Vault storage, but access to the storage directory should be restricted to the tiCrypt backend service account following the principle of least privilege (CMMC Level 2 practice AC.L2-3.1.1). For practical guidance on partitioning shared storage while maintaining compliance, see Carving Out a CUI Enclave on Your Existing Filesystem. For the theoretical basis of ciphertext co-residency, see Cryptographic Isolation for CUI on Shared Storage.

Encrypted VM Drives

VM encrypted drives are stored as files in a distributed filesystem accessible to all Libvirt host servers, organized into disk pools (separate pools for disk images, encrypted drives, and ISOs). A newly created drive is intentionally left blank and unformatted. Formatting is deferred until the drive's first attachment to a tiCrypt VM for a critical security reason: the AES-256 encryption key is generated and held exclusively by the user and the VM controller, not by the infrastructure. The tiCrypt backend, Libvirt, and the underlying VM host are all excluded from access to this key.

On Windows, the drive is formatted as NTFS and BitLocker full-volume encryption (AES-256) is enabled immediately, before the drive is made available to the user. All subsequent writes, including filesystem metadata, are encrypted. An external tool inspecting the backing file can determine the drive is NTFS-formatted but can read no content beyond what was written before BitLocker activation, which is minimal.

On Linux, 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, including filesystem structure, metadata, and file content, is encrypted at the block level. An external tool inspecting the backing file can only determine which disk blocks have been written; it cannot derive any information about their content or the filesystem type.

Non-Secure Storage: ISOs and NFS

ISOs are attached as read-only CD-ROM devices and are always safe to mount in a tiCrypt VM. They are useful for distributing software packages and public datasets without introducing a writable external channel.

NFS shares require careful handling. An NFS share mounted read-write inside a secure VM creates a direct data exfiltration path that bypasses tiCrypt's encryption and audit controls entirely, rendering the deployment non-compliant with CMMC Level 2 media protection practice MP.L2-3.8.6 (protect CUI on media). All NFS shares mounted in tiCrypt VMs must be exported read-only.

The NFS server itself must also reside within the tiCrypt security boundary. An NFS server outside the controlled infrastructure extends the authorization boundary to a system that may not meet tiCrypt's security requirements. The recommended approach is to run a local NFS server inside the boundary and replicate data into it from external sources, so VMs access only the controlled copy. For details on how tiCrypt interacts with the underlying filesystem, see Interplay between the Filesystem and tiCrypt. Across every data path in the system, from storage to ingress to VM communication, data is encrypted before it leaves the user's control, and the infrastructure handles ciphertext exclusively.

Data Migration

tiCrypt supports several secure methods for importing data. For a full walkthrough of each method, see Getting Data Into the Enclave.

• Browser upload: Direct upload of files into the user's Vault via the tiCrypt web interface. Files are encrypted client-side before transmission.
• SFTP / Inbox credentials: External parties can send files directly to a user's Vault. Files are encrypted using the recipient's RSA-2048 public key on arrival, so only the intended user can decrypt them. The SFTP/Inbox server can be hosted separately from the tiCrypt backend, outside the security perimeter.
• VM SFTP via tiCrypt Connect: With tiCrypt Connect running, users can generate ephemeral SFTP credentials to transfer data directly into a VM through the encrypted tunnel. Proxy connections are managed by the application.
• External Drive Builder: The Drive Builder tool allows users to create and encrypt virtual drives externally, sign them with their private key for integrity verification, and copy them into the tiCrypt drive pool.
• External cloud services: Dropbox, Google Cloud, and OneDrive integrations allow one-way, secure data transfer into a user's Vault.

All import methods maintain end-to-end encryption throughout the transfer process, ensuring data is never exposed in plaintext on any intermediate system.

Conclusion

The prevailing model of data security assumes that if the perimeter is strong enough, the data inside is safe. tiCrypt rejects this assumption entirely. Perimeters can be breached. Administrators can be compromised. Authentication servers can be spoofed. The question is not whether an attacker can reach the server, but what they find when they do.

A fully compromised tiCrypt server produces no data breach.

That is the defining guarantee of zero-knowledge infrastructure. By grounding every security property in user-controlled, end-to-end encryption (AES-256, FIPS 197) and RSA-2048 public-key cryptography (FIPS 186-5), tiCrypt ensures that a breach of the server is a breach of infrastructure, not a breach of data. Decryption keys never reside on the server. Passwords are never transmitted or stored. Administrators are cryptographically isolated from user data. Every file, drive, and communication channel is independently encrypted, and access to one reveals nothing about any other.

Layered on top of this cryptographic foundation are the mechanisms that address sophisticated, targeted attacks: a hierarchical chain of trust that makes key substitution detectable, crowd security that catches irregularities client-side, MFA integration that treats identity providers as independent proof-providers rather than trusted insiders, and tamper-evident audit logs that surface rogue activity within minutes.

The result is a system where the attack surface is dramatically reduced, the value of a successful breach is radically diminished, and the security guarantee rests on the mathematical hardness of integer factorization and AES key recovery. These are the only mechanisms that insider threats, zero-day exploits, and compromised infrastructure alike cannot quietly bypass.

tiCrypt is not a harder wall. It is zero-knowledge infrastructure: a fundamentally different architecture where the server never holds the keys to decrypt the data it stores.

Appendix: CMMC Level 2 Compliance Mapping

The following table maps key CMMC Level 2 practices (per NIST SP 800-171r2) to the specific tiCrypt architectural features that satisfy them. Controls listed here are directly addressed by the platform; organizational controls (Personnel Security, Physical Protection, and others) require institution-specific implementation. For a control-by-control analysis of where the platform's responsibility ends and organizational controls begin, see The Shared Responsibility Gap in Cloud Research Enclaves.

Control	Requirement	How tiCrypt Satisfies It
SC.L2-3.13.16	CUI Protection at Rest	Every file and drive encrypted with a unique AES-256 key; decryption keys exist only on user endpoints. Infrastructure never possesses plaintext or decryption keys.
SC.L2-3.13.8	Transmission Encryption	Data encrypted client-side before transmission (end-to-end); TLS 1.2+ with FIPS-approved cipher suites for transport.
SC.L2-3.13.11	FIPS-Validated Cryptography	All cryptographic operations use the OpenSSL 3.1.2 FIPS 140-3 module: AES-256 (FIPS 197), RSA-2048 (FIPS 186-5), SHA-256 (FIPS 180-4).
SC.L2-3.13.2	Security Architecture	Three-layer architecture (physical infrastructure, tiCrypt security layer, work layer in encrypted VMs), each with independent security controls and isolated microservices.
SC.L2-3.13.6	Default-Deny Network Policy	All traffic denied by default. Only ports 22 and 443 permitted inbound; VMs have deny-all outbound policy with explicit allowlist exceptions requiring SuperAdmin authorization.
SC.L2-3.13.10	Cryptographic Key Management	Client-side RSA-2048 key pair generation at account creation. Multi-person escrow recovery requires a minimum of three key holders; no single holder can recover a key alone.
SC.L2-3.13.4	Unauthorized Transfer Prevention	VMs logically isolated with encrypted drives and no cross-project network paths. Data export requires explicit authorization from project members.
IA.L2-3.5.2	Identity Authentication	Challenge-response protocol: server issues random nonce, user signs with RSA private key, server verifies against stored public key. No password transmitted or stored on server.
IA.L2-3.5.3	Multifactor Authentication	MFA integrated as independent proof-provider (Duo, Shibboleth). MFA certificate verified alongside digital signature; both must pass for session establishment.
IA.L2-3.5.4	Replay-Resistant Authentication	Server-issued nonces are cryptographically random and non-reusable, preventing replay of previous authentication events.
IA.L2-3.5.7	Password Complexity	Enforced for the password protecting the user's RSA private key. The server stores no information that enables offline brute-force attacks against this password.
IA.L2-3.5.10	Cryptographic Password Protection	Authentication uses public-key cryptography; no passwords transmitted to the server. Password used only to decrypt the user's private key on the client.
AU.L2-3.3.1	Audit Log Creation & Retention	110+ event types tracked at millisecond precision (UTC, NTP-synchronized). SHA-256 hash chain provides tamper-evident, append-only integrity.
AU.L2-3.3.2	User Action Traceability	Every file access, key request, sharing action, and VM operation logged with authenticated user identity, session ID, source IP, and success/failure status.
AU.L2-3.3.4	Audit Processing Failure Alerts	Fail-safe design: all backend services stop if the logging service fails. Capacity alerts at configurable thresholds; key manager stops at 90% utilization.
AU.L2-3.3.8	Audit Information Protection	SHA-256 hash chaining detects any record modification. One-way TCP push to isolated audit system on port 25000; no return path from audit to backend.
AC.L2-3.1.1	Authorized Access Only	Accounts created in deactivated state; administrator must activate and assign team and permission profile. All access routed through encrypted tiCrypt channels.
AC.L2-3.1.3	CUI Flow Enforcement	All data encrypted with per-resource AES-256 keys controlled by the data owner's RSA key pair. System administrators cryptographically excluded from user data.
AC.L2-3.1.4	Separation of Duties	Multiple administrator levels (Sub-Admin, Admin, Super Admin, infrastructure root) with distinct privileges. Cryptographic separation ensures no admin level grants plaintext access.
AC.L2-3.1.5	Least Privilege	Granular permission profiles restrict users to minimum necessary access. Data owners control cryptographic access through PKI key sharing.
MP.L2-3.8.1	Media Protection	FIPS 140-3 AES-256 encryption on all stored data. Physical possession of storage media yields only encrypted data; decryption requires the data owner's RSA private key.
MP.L2-3.8.3	Media Sanitization	Cryptographic erasure: destroying the per-resource AES-256 key renders ciphertext permanently unrecoverable. No disk-level sanitization required.
MP.L2-3.8.9	Backup CUI Protection	All backup data is end-to-end encrypted. Backup systems see only encrypted blobs; decryption requires the data owner's RSA private key.