Skip to main content

Security Principles and Compliance: tiCrypt

Executive Summary​

Traditional security mechanisms including perimeter defenses, backend network security, and access control management have proven insufficient against modern threats. The continuous stream of high-profile data breaches makes this clear: when a backend server or admin account is compromised, these mechanisms offer little protection.

tiCrypt takes a fundamentally different approach. Rather than relying on server-side defenses, tiCrypt builds security around strong, user-controlled encryption. Because decryption keys are never stored on the server, a server breach cannot produce a data breach. In tiCrypt, a compromised admin account does not mean compromised data.

Security Principles​

tiCrypt is built on three foundational principles: data confinement through encryption, public-key cryptography, and end-to-end encryption. All security features in the platform derive 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 admin account inherit that same power.

tiCrypt enforces data confinement cryptographically. Each file is encrypted at creation with a unique, independently generated AES-256 key. That key is then encrypted with the public keys of authorized users and stored on the server. End-to-end encryption is performed before data reaches the server; decryption happens only at the destination.

File sharing never touches the server's logic directly. Instead, the process happens entirely in the file owner's browser:

  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 side. 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 private key, and vice versa. This asymmetry enables both secure data exchange and digital signatures without requiring shared secrets.

tiCrypt uses RSA-2048 key pairs, the standard recommended by NIST FIPS 140-2 for government use. It is estimated that deriving a private key from an RSA-2048 public key would require half a million computers running for 13 billion years.

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 challenge, and the server verifies the signature against the stored public key. No password is ever sent to or stored by the server.
  • File Sharing: Files are shared by encrypting a resource key with the recipient's public key. No passwords or secrets need to change hands.
  • Certificates: Digitally signed instructions authorize other users to perform operations on the owner's behalf.

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 just before 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, which allows anyone with access to the right server certificates to decrypt traffic. Even if tiCrypt's SSL certificate were compromised, end-to-end encryption would keep the data secure independently.

Encryption occurs on the client side with keys controlled by the user. If a file is accessed or shared multiple times, it is decrypted each time from scratch. No unencrypted copies persist in intermediate storage.

All data in tiCrypt is encrypted to the same level: AES-256. There are no tiers of security. Since the performance difference between AES-128 and AES-256 is minor (roughly 20%), there is no practical reason to accept weaker protection for any resource.

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 that fake key.

tiCrypt mitigates this through a chain of digital signatures:

  • A site key, signed by a hardwired Tera Insights private key, bootstraps the security of the entire deployment.
  • The site key signs the first super-admin key; that key signs subsequent admin keys; and so on.
  • Every new user account is approved by an administrator, whose private key signs the new account's public key, cryptographically linking 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 fake key without controlling an administrator key.

Crowd Security​

To further protect key integrity, tiCrypt's frontend locally stores SHA-256 fingerprints 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 is immediately flagged.

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.

Secure JavaScript Delivery​

Since tiCrypt's frontend runs in the browser, a natural attack vector is injecting malicious JavaScript to steal private keys. tiCrypt addresses this in three ways:

  1. All dependencies are bundled into the tiCrypt frontend. No external JavaScript, CSS, or HTML resources are referenced. Compromised third-party libraries cannot affect a packaged tiCrypt deployment.
  2. The frontend bundle is delivered as a digitally signed ZIP archive, with signing keys controlled by two senior Tera Insights executives.
  3. tiCrypt Connect serves the frontend locally, automatically updates it on new releases, and works alongside the frontend to authenticate all VM traffic, locking sessions if unauthenticated connections are detected.

Key Escrow​

Loss of a private key means loss of data access. tiCrypt's key escrow mechanism enables recovery without creating a single point of failure.

Recovery requires a minimum of three escrow keys, each signed by the site key and usable only for escrow activities. The recovery process works as follows:

  1. A random AES-256 key is generated for each escrow key and encrypted with the corresponding escrow public key.
  2. The combination of these AES-256 keys encrypts the user's private key, which is then stored on the server.

No individual escrow key holder can recover the user's private key alone. All parts must be combined by a designated party. If any part is missing, recovery is impossible.

Secure Virtual Machines​

tiCrypt provides secure computation environments through encrypted virtual machines (VMs) with a fundamentally different access model than 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 admin. The only access path is through a secure, user-authenticated channel within tiCrypt:

  1. When a VM starts, it receives the owner's public key.
  2. The user and VM co-authenticate using their respective public and private keys.
  3. A symmetric session key is negotiated via Diffie-Hellman and used for all subsequent communication.

The result is a double-encrypted channel: data is encrypted with the session key (rest encryption) and transmitted over an encrypted WebSocket (transport encryption). 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 keys are generated and managed identically to file keys. The user-VM channel transmits drive keys at startup; even system administrators 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 FIPS-180 compliant TLS tunnel between the user's computer and the VM using exclusively public-key authentication and temporary private keys. No commands can be run on the remote machine through this protocol. It is more restrictive than SSH by design.

Outbound access: VMs have strictly limited internet access. Only the tiCrypt backend and licensing servers are reachable. This prevents both accidental and intentional data exfiltration. Even a hijacked VM can only route data through the audited tiCrypt vault.

Boot images are immutable and reset automatically on each boot, eliminating persistent internal risk.

Combining tiCrypt with Traditional Defenses​

tiCrypt's encryption-first architecture is designed to complement, not replace, traditional security measures. An attacker must defeat both to achieve a 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.

Rather than integrating MFA into the backend (which would create a single point of failure), tiCrypt treats MFA providers as external proof-providers. When a key is used from a machine inactive for a set period or never previously used by that user, tiCrypt's authentication protocol requires MFA to independently verify the request. A stolen key used from a new machine will trigger this check and be denied.

Perimeter and Server Defense​

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

  • Regular user accounts are not required on the hosting server, eliminating most server-side vulnerabilities at the source.
  • Only two entry points are needed: SSH for admin management and HTTPS for the tiCrypt interface. All other ports should be blocked.
  • Strong SSH public-key authentication can be deployed for all administrative access, rendering password-based vulnerabilities ineffective.
  • All existing security tools including firewalls, intrusion detection, and system auditing are fully compatible with tiCrypt and add meaningful additional layers.

Threat Model and Solutions​

Server Misconfiguration​

Problem: A misconfigured or improperly rebooted server can disable authentication, leaving the system open.

Solution: In tiCrypt, a fully disabled authentication server still exposes nothing useful. The accessible data is encrypted with keys held only by individual users. No scenario allows tiCrypt to leak unencrypted data, present or future.

Insider Threats​

Problem: Admins with broad data access can exfiltrate information before detection. Traditional audit logs are too slow and voluminous to serve as an effective deterrent.

Solution: tiCrypt cryptographically isolates administrators from user data. All legitimate access flows through the tiCrypt system and is captured in the audit log. Log mining can surface irregularities within minutes. Rogue admin activity is structurally visible in a way it is not in traditional systems.

Authentication Attacks​

Problem: If an attacker can forge authentication certificates or substitute public keys, they can impersonate users and access shared files.

Solution: tiCrypt's chain of trust and crowd security make key substitution detectable. Public key fingerprints are stored client-side, outside server control. Any attempt to swap a key will be 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.

Zero-Day Exploits​

Problem: If zero-day exploits are discovered in backend servers, attackers can access stored data. High-value data stores make such attacks financially motivated.

Solution: tiCrypt's end-to-end encryption renders backend access useless. Decryption keys are never present on the server. A full server compromise makes the system temporarily unavailable, not insecure. Encrypted data remains protected regardless of how long an attacker controls the backend.

Auditing and Compliance​

tiCrypt is built to meet NIST and CMMC compliance requirements. Its audit engine can process hundreds of millions of entries per second, making large-scale log analysis practical.

Secure Audit Logs​

Log entries are chained using SHA-256 hashing, similar in principle to a blockchain. Any modification to a log entry produces a hash conflict detectable on audit. Administrators and attackers alike cannot alter the log history without leaving forensic evidence.

Audited Events​

tiCrypt tracks 30+ event types at millisecond precision, including:

  • Session and certificate requests, challenges, lookups, and deletions
  • Directory entry creation, deletion, renaming, and modification
  • Virtual machine creation, deletion, and proxy registration
  • Virtual drive attachment, detachment, creation, deletion, and key operations
  • File creation, deletion, key operations, and chunk-level read/write events
  • Group and user permission creation, deletion, and modification

Infrastructure and Scalability​

System Architecture​

tiCrypt runs as a set of independent services: AUTH, FILE MANAGER, and VM, each with its own configuration files under /etc/ticrypt. Services operate independently; a failure in one does not cascade to others. All user requests pass through the REST service, which delegates to the relevant service after AUTH validation.

tiCrypt is designed for isolation with strictly controlled entry points, a distributed file system connecting the main server to VM hosts, and no dependency on special security appliances. It can be deployed on existing hardware clusters as a private cloud, or on AWS BareMetal infrastructure.

Storage​

tiCrypt Vault: Files are divided into 8MB chunks, each encrypted with a unique key. Metadata, directory entries, access information, and decryption keys are stored in MongoDB. Without decryption keys, chunk files are indecipherable.

Encrypted Drives: Libvirt manages VM disk images and encrypted drives. New drives are left unformatted until first attachment to a VM, ensuring encryption keys are generated and controlled by the user rather than the infrastructure. On Windows, BitLocker provides full-volume encryption. On Linux, LUKS provides full-disk encryption via a block layer beneath the filesystem (typically EXT4).

Licensing​

tiCrypt is offered under a single deployment license covering the entire institution. No per-seat renegotiation or additional fees apply as the system scales.

System Requirements​

Software: RedHat Enterprise, CentOS, Rocky, or Springdale; distributed filesystem tuned to system workflows; Java JRE 8+; Libvirt and QEMU on all VM servers; SSH on all VM servers.

Network: 1 Gbit/s external (10 Gbit/s preferred); 10 Gbit/s internal or Infiniband (Infiniband preferred); TLS for the REST interface and static assets; a range of 10 to 100 ports open for SSH proxying on the public-facing server; a firewall in front of the public server.

System Bootstrapping​

The entire security deployment is anchored to a site key signed by a Tera Insights private key, verifiable against a public key hardwired into both the frontend and backend. The bootstrapping sequence is:

  1. Generate the site key and submit it to Tera Insights for countersigning.
  2. Add escrow groups to enable redundant key recovery.
  3. Add escrow users to enable individual key recovery.
  4. Create at least one (preferably two) super-admin accounts to coordinate activation and role assignment.

Data Migration​

tiCrypt supports several secure methods for importing data:

  • Browser upload: Direct upload of smaller files into the user's Vault via the tiCrypt web interface.
  • SFTP / Inbox credentials: External parties can send files directly to a user's Vault. Files are encrypted using the recipient's public key on arrival, so only the intended user can decrypt them. The SFTP/Inbox server can be hosted separately from the tiCrypt backend.
  • VM SFTP via tiCrypt Connect: With tiCrypt Connect running, users can generate SFTP credentials to transfer data directly into a VM. 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 public key, 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.

Conclusion​

The prevailing model of data security assumes that if the walls are strong enough, the data inside is safe. tiCrypt rejects this assumption. Walls can be breached. Admins 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.

tiCrypt's answer is: nothing usable. By grounding every security guarantee in user-controlled, end-to-end encryption and RSA-2048 public-key cryptography, tiCrypt ensures that a breach of the server is a breach of infrastructure and 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 foundation are the mechanisms that address sophisticated, targeted attacks: a 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 make rogue activity visible within minutes.

The result is a system where the attack surface is radically reduced, the value of a successful breach is radically diminished, and the burden of proof falls entirely on cryptography. It is the one mechanism that neither insider threats, zero-day exploits, nor compromised infrastructure can quietly bypass.

tiCrypt is not a harder wall. It is a fundamentally different approach to what security means.