Skip to main content
tiCrypt 2.17.11

Architecture

A tiCrypt deployment is a set of hosts separated by two boundaries. The authorization boundary marks where tiCrypt's control begins. The external firewall marks what is reachable from the outside world. Almost every design decision follows from where a component sits relative to those two lines.

Select any component below to see what it does, which ports it uses, and where it is documented, or trace a path from the list on the left to follow a whole operation from end to end.

  • a person, not a server
  • listens on a port
  • one-way path inward
  • runs on its host
authorization boundaryexternal firewallFrontend interfaceOther peopleExternal MFAData ingresstiAudit servertiCrypt backend serverCompute nodesDistributed file systemtiCrypt usersUser workstation443 · 6000-6100External Data BrokersAudit and ComplianceBrokersExternal MFAticrypt-sftpSFTP 2022ticrypt-mailboxHTTPS 443tiAudit25000Audit web interfaceHTTPS 443REST frontend443 ext · 443 intProxy6000-6100Virtual machinesAuthenticationFile managerBatchLoggingStatisticsNotificationsMaintenanceVM host 1SSH 22Secure VM22 · 6000-6254VM host 2VM host 3VM host 4VM host 5Slurm host 1Batch job VMSlurm host 2Slurm host 3Slurm host 4Slurm host 5Distributed filesystem

How to read it​

Nothing inside the boundary is directly reachable. A user never connects to a VM; they connect to the proxy, which forwards to it. An external data broker never connects to the backend; they reach an ingress service, which has a one-way path inward and no route to anything else.

Encryption happens at the edges, not in the middle. Files are encrypted on the user's own machine before they leave it, and data arriving through ingress is encrypted with the recipient's public key on arrival. Everything between those points, the distributed file system included, handles ciphertext. An administrator with filesystem access sees encrypted bytes.

The two channels out of a workstation do different jobs. REST API traffic on 443 carries metadata, file chunks, and management operations. Tunneled application traffic on 6000-6100 carries interactive sessions: remote desktop, terminals, and forwarded applications.

Data ingress​

Getting data in from someone who has no tiCrypt account is a distinct problem from using tiCrypt, and it is solved by two services that live outside the external firewall:

  • ticrypt-sftp accepts transfers from a standard SFTP client on port 2022. It serves both administrator-provisioned accounts and user-created Inboxes.
  • ticrypt-mailbox accepts uploads through a web form reached from a link, for senders who will not configure an SFTP client.

Both need a network path to the REST frontend and nothing else. Neither can reach the internal network, the distributed file system, or a compute node. That is what makes it safe to expose them.

Sizing a deployment​

The diagram draws five VM hosts and five Slurm hosts. Real counts vary with the workload; the shape does not:

  • VM hosts carry interactive secure VMs. Each needs virtualization extensions in BIOS and a path to the distributed file system.
  • Slurm hosts run batch jobs. Each runs ticrypt-host-controller, which starts a secure VM per job.

A single-server evaluation deployment collapses all of this onto one machine. Production separates the backend, the compute hosts, and storage. See the Pre-Installation Checklist for the hardware and network requirements behind each.

  • Network: the VLANs and bridges these hosts sit on, and why the backend is the only way in or out.
  • Components: every package in the tiCrypt repository, what it does, and how to install it.
  • Install Guide: the Ansible deployment process.
  • REST API: the interface every client uses to reach the backend.