tiCrypt System Security Plan
This System Security Plan documents the security controls that the tiCrypt platform provides directly. It is a product-level reference: every control below is satisfied by tiCrypt itself, independent of any specific deployment. Controls that depend on the operating organization, such as physical protection, personnel security, and facility contingency, are intentionally excluded and identified in the scope statement. This is a product-level shared-responsibility document: a deploying organization incorporates it by reference into its own System Security Plan, which adds the authorization boundary, system inventory, network diagrams, and organization-defined parameters.
Purpose and Scope
tiCrypt is built on zero-knowledge infrastructure: data is encrypted with keys that never exist on the server, so a fully compromised server yields only ciphertext. Because security is enforced cryptographically rather than by trusting the infrastructure, tiCrypt satisfies a large share of the technical control families in NIST SP 800-171 Revision 3 and CMMC 2.0 Level 2 on its own.
This plan states, control by control, how the platform meets each requirement. It follows the shared-responsibility model: the controls documented here are the platform's contribution to a deployment's overall compliance posture. The deploying organization remains responsible for the organizational and physical controls listed on the right.
Provided by tiCrypt
- Access Control (AC)
- Audit and Accountability (AU)
- Identification and Authentication (IA)
- System and Communications Protection (SC)
- Configuration Management (CM, platform mechanisms)
- System and Information Integrity (SI, platform mechanisms)
- Media Protection (MP, cryptographic)
- Supply chain and backup integrity (SR / CP / SA, cryptographic)
Organizational Responsibility (Out of Scope)
- Physical and Environmental Protection (PE)
- Personnel Security (PS)
- Awareness and Training (AT)
- Facility and hardware Maintenance (MA)
- Contingency site and continuity operations (CP, non-cryptographic)
- Security Assessment and Authorization process (CA)
- Risk Assessment program (RA)
- Acquisition and procurement process (SA, non-product)
How to read this plan. Each control card lists its NIST SP 800-171 Revision 3 requirement identifier and its CMMC 2.0 Level 2 practice, followed by the requirement and how tiCrypt implements it. CMMC 2.0 Level 2 is defined against NIST SP 800-171, so the two usually align; where a requirement exists in Revision 3 but not in CMMC 2.0 (or the reverse), the other column reads None. CMMC 2.0 Level 2 assessments are currently conducted against NIST SP 800-171 Revision 2, reflected in the CMMC practice identifiers; the Revision 3 identifiers are provided as a forward-looking reference. A control mapped to None in both columns denotes a tiCrypt capability that exceeds the CMMC Level 2 and 800-171 baselines. A control marked Provided · Config Required is delivered by the platform but must be enabled or operated by the deploying organization.
Access Control (AC)
Family · ACtiCrypt enforces access control cryptographically: every file, drive, and communication channel is encrypted client-side with keys that never exist on the server, so access is granted only by re-encrypting resource keys to an authorized user's RSA public key. Team, Project, Group, and Permission Profile constructs layer organizational policy on top of this cryptographic foundation, and administrators at every tier are cryptographically excluded from user data.
Requirement. Define, create, enable, modify, disable, and remove system accounts in accordance with organizational policy.
tiCrypt Implementation. Each tiCrypt account is bound to an RSA-2048 key pair generated at account creation; the private key is encrypted with the user password and never leaves the client, so an account cannot be used without possession of its key material. A user must belong to a Team to be active, which gives the deploying organization a single enforcement point for enabling and disabling accounts and for applying resource quotas. User and Permission Profiles assign each account a role with granular permissions, and administrator tiers (Sub-Admin, Admin, Super-Admin) manage accounts without any cryptographic access to user data. The deploying organization defines its Teams, Projects, and Permission Profiles and operates the account lifecycle.
Requirement. Enforce approved authorizations for logical access to information and system resources.
tiCrypt Implementation. Access enforcement in tiCrypt is cryptographic rather than purely policy based: every file and drive is encrypted with an AES-256 key, and a user can read a resource only if that key has been re-encrypted to the user's RSA public key. The server holds only ciphertext and cannot decrypt or grant access on its own; a fully compromised server yields only ciphertext. Project tags additionally gate access so that only certified active members of a project can reach tagged resources, and Permission Profiles restrict which operations each role may perform.
Requirement. Enforce discretionary access control where the owner of an object may grant or limit access to it.
tiCrypt Implementation. Resource owners exercise discretionary control directly through key management: to share a file or drive, the owner's client re-encrypts the resource's AES key to the recipient's RSA public key. The server never decrypts and cannot extend access on behalf of an owner, so the set of users able to read a resource is exactly the set the owner has cryptographically granted. Groups provide a structured mechanism for owners to share with collaborators, and access remains bounded by project certification and permission profiles.
Requirement. Control the flow of information within the system and between interconnected systems in accordance with approved authorizations.
tiCrypt Implementation. All information flows through managed, encrypted tunnels established by the tiCrypt Connect client; only ports 22 and 443 are permitted inbound and all other traffic is denied by default. Split tunneling is prevented, and external systems cannot connect directly to the platform. Within the platform, project tags confine data to certified active project members, and data export from a project requires explicit authorization, so information cannot leave a project boundary without an approved flow decision.
Requirement. Identify and separate the duties of individuals to reduce the risk of malevolent activity without collusion.
tiCrypt Implementation. tiCrypt provides tiered administrative roles (Sub-Admin, Admin, Super-Admin) plus infrastructure root, and all administrative tiers are cryptographically excluded from user data, structurally separating system administration from data access. User and Permission Profiles let the organization assign each individual a role with only the granular permissions that role requires, so operational duties can be divided across distinct profiles. The deploying organization defines the profile assignments that implement its specific separation-of-duties policy.
Requirement. Employ the principle of least privilege, allowing only authorized accesses necessary to accomplish assigned tasks.
tiCrypt Implementation. Every account operates under a User or Permission Profile that combines a role with granular permissions, so each user holds only the specific operations the organization assigns. Data access is further minimized cryptographically: a user can decrypt only resources whose AES keys have been re-encrypted to that user's public key, and even Super-Admins and infrastructure root cannot read user data. Project certification restricts tagged resources to certified active members. The deploying organization defines the permission profiles that reflect its least-privilege policy.
Requirement. Prevent non-privileged users from executing privileged functions and log the execution of privileged functions.
tiCrypt Implementation. Permission Profiles restrict privileged functions to the administrative tiers that hold the corresponding permissions, so non-privileged users cannot invoke them. tiCrypt then logs every privileged function executed by any administrative tier, and because all data access requires a key request, those requests are logged alongside administrative activity. Administrators remain cryptographically excluded from user data, so privileged functions are limited to management operations and the audit trail covers that complete set.
Requirement. Limit consecutive invalid logon attempts and take a defined action when the limit is exceeded.
tiCrypt Implementation. A tiCrypt logon requires decrypting the user's password-protected private key on the client; after a configurable number of consecutive failed decryption attempts, five by default, the account is locked and an administrator must intervene. Because authentication is challenge-response, no password is transmitted to or stored by the server. The salt and initialization vector needed to decrypt the private key are released by the server only after a successful connection, so an attacker who copies the encrypted key file offline cannot mount an unbounded offline guessing attack against it. The deploying organization sets the attempt limit and lockout action to match its policy.
Requirement. Prevent access to the system by initiating a session lock after a period of inactivity, concealing previously visible information, and retaining the lock until the user re-authenticates.
tiCrypt Implementation. Idle tiCrypt sessions lock automatically after a configurable interval, with a default of 15 minutes. On lock, the session obscures the screen so previously visible information is concealed, and the session remains locked until the user re-authenticates. The deploying organization may adjust the idle interval to match its policy.
Requirement. Automatically terminate a user session after defined conditions or trigger events.
tiCrypt Implementation. tiCrypt distinguishes locking from termination. Command sessions such as terminal and SSH connections are automatically terminated after a defined period of inactivity, closing the connection rather than suspending it. Interactive graphical sessions lock at the idle threshold and require full re-authentication through the challenge-response protocol; the underlying tunnel is torn down when the session closes or the re-authentication window lapses. The deploying organization configures the inactivity thresholds that trigger termination. Terminated sessions hold no reusable credentials because no password or private key is ever stored on the server.
Requirement. Establish usage restrictions and configuration requirements for remote access, and authorize each type of remote access prior to allowing such connections.
tiCrypt Implementation. All remote access to the platform flows through a single authorized path: the tiCrypt Connect client over managed, encrypted tunnels. Every remote session is authenticated by the challenge-response protocol, in which the server issues a random nonce and the client signs it with the user's private key. When the deployment enables multi-factor authentication, a signed certificate from an external MFA provider is verified alongside the challenge before the session is authorized. External systems cannot connect directly to the platform, so no unauthorized remote access type exists.
Requirement. Implement cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.
tiCrypt Implementation. Remote sessions run inside encrypted tunnels managed by the tiCrypt Connect client, using AES-256 (FIPS 197), RSA-2048 (FIPS 186-5), and SHA-256 (FIPS 180-4) provided by a FIPS 140-3 validated cryptographic module. Data remains encrypted end to end because all encryption and decryption occurs client-side; the server never holds the keys, so a compromised transport or server exposes only ciphertext. This protects both the confidentiality and the integrity of every remote access session.
Requirement. Route remote accesses through authorized and managed network access control points.
tiCrypt Implementation. The tiCrypt Connect client is the sole managed access control point for the platform: all remote access is routed through its managed, encrypted tunnels. Only ports 22 and 443 are permitted inbound, all other traffic is denied by default, and split tunneling is prevented so a connected client cannot bridge the platform to another network. External systems cannot connect directly to the platform through any other path.
Requirement. Establish terms and conditions for the use of, and verify controls on, external systems that access the system or process organizational information.
tiCrypt Implementation. External systems cannot connect directly to the platform; the only supported access path is the tiCrypt Connect client over managed, encrypted tunnels with split tunneling prevented. Information cannot move to an external system implicitly because data export from a project requires explicit authorization, giving the organization a controlled decision point for every outbound transfer. The deploying organization defines and operates the authorization policy governing which exports are permitted.
Requirement. Enable authorized users to determine whether access authorizations assigned to a sharing partner match the information's access restrictions, and employ mechanisms to assist users in making sharing decisions.
tiCrypt Implementation. Sharing in tiCrypt is an explicit, user-driven cryptographic act: the owner's client re-encrypts the resource's AES key to the intended recipient's RSA public key, so no share can occur accidentally or be created by the server. Groups give users a managed structure for collaborative sharing, while project tags ensure shared resources remain reachable only by certified active project members regardless of key grants. Every key request is logged, providing an auditable record of sharing activity.
Audit and Accountability (AU)
Family · AUtiCrypt generates hash-chained, tamper-evident audit records for more than 110 event types, including every cryptographic key request, and streams them over a one-way push to the separately deployed tiCrypt Audit system for reduction, reporting, and forensic reconstruction. Audit data is isolated from tiCrypt administrators and users and is accessible only to a limited set of infrastructure-privileged users.
Requirement. Identify the event types the system is capable of logging and log the events selected for auditing.
tiCrypt Implementation. tiCrypt records more than 110 distinct event types. Because all data in tiCrypt is encrypted and every access requires a key request, all key requests are logged, covering file access, sharing and permission changes, group creation and modification, drive creation and attachment, VM start and stop, and VM-to-drive and VM-to-user connections. Administrative actions such as account, team, and project creation and privilege grants are logged, as are privileged-user actions. Event coverage is built into the product and does not depend on per-event configuration to capture these activities.
Requirement. Ensure audit records contain what type of event occurred, when and where it occurred, its source and outcome, and the identity of associated individuals or subjects.
tiCrypt Implementation. Every tiCrypt audit record contains the originating system identifier, the event timestamp, the action or event type together with the relevant event data, the success or failure outcome, the associated user when applicable, and the remote address when applicable. These fields satisfy the what, when, where, source, outcome, and identity elements of the control. Record content is fixed by the product and is applied uniformly to all logged event types.
Requirement. Generate audit records containing additional, more detailed information beyond the baseline record content.
tiCrypt Implementation. Beyond the baseline fields, tiCrypt records event-specific detail data for each of its 110 plus event types, such as the objects, keys, drives, VMs, and permissions involved in an action. Key-request logging ties each data access to the specific encrypted resource requested, providing per-object detail for forensic analysis. Alerts derived from log entries never contain sensitive data, so additional detail is captured without exposing protected content in notifications.
Requirement. Alert on audit logging process failures and take defined actions in response.
tiCrypt Implementation. tiCrypt is fail-safe with respect to logging: if the logging service stops, the dependent backend services stop as well, so the system cannot continue operating without producing an audit trail. Capacity alerts fire at configurable thresholds as log storage fills, and the key manager halts key issuance at 90 percent utilization, which pauses data access until the condition is resolved. A logging failure is therefore surfaced and acted upon rather than silently ignored.
Requirement. Review and analyze audit records for indications of inappropriate or unusual activity and report findings to designated personnel.
tiCrypt Implementation. The tiCrypt Audit system provides the review and analysis capability, including audit reduction, predefined and ad hoc reports, alerts derived from log entries, and reconstruction of system state at any past point in time. Security and compliance staff can be granted full audit access without any access to the tiCrypt backend, its data, or user keys, supporting independent review. The organization must define its review frequency, assign reviewers, and configure alert thresholds and reporting procedures to operate this capability.
Requirement. Provide audit record reduction and report generation that supports on-demand analysis and reporting without altering original records.
tiCrypt Implementation. tiCrypt Audit provides audit reduction along with both predefined and ad hoc report generation for on-demand analysis. It can reconstruct the state of the system at any past point, supporting after-the-fact investigation and forensic analysis. Reduction and reporting operate on the pushed audit stream and do not alter the original record content or the time ordering of records.
Requirement. Use internal system clocks to generate audit record time stamps that map to UTC and meet a defined granularity.
tiCrypt Implementation. tiCrypt records every audit event with a UTC timestamp at millisecond precision, and tiCrypt Audit preserves the time ordering of records so timestamps support reliable sequencing and correlation during analysis. Timestamp accuracy depends on the host clock: the deploying organization synchronizes the underlying operating system clocks via NTP to an authoritative time source.
Requirement. Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
tiCrypt Implementation. Audit logs are SHA-256 hash-chained in accordance with FIPS 180-4, making them append-only and tamper-evident; any insertion, deletion, or alteration produces a detectable hash conflict. The tiCrypt Audit system is separately deployed and fed by a one-way TCP push on port 25000 with no return path, so a compromise of the audit consumer cannot reach back into the tiCrypt backend. If the logging service fails, dependent services stop rather than operate unaudited, and capacity alerts fire at configurable thresholds before storage is exhausted.
Requirement. Authorize access to management of audit logging functionality to only a defined subset of privileged users.
tiCrypt Implementation. Audit logs are accessible only to a limited set of infrastructure-privileged users with root escalation. tiCrypt administrators, super-admins, and ordinary users cannot access or even locate the audit logs, enforcing separation between platform administration and audit management. Security and compliance staff can be given full access to tiCrypt Audit without receiving any access to the tiCrypt backend, its data, or user keys, so audit review authority never implies platform privilege.
Requirement. Provide audit record generation capability for the defined event types on system components and generate audit records with the required content.
tiCrypt Implementation. tiCrypt generates audit records for all of its 110 plus event types across the platform, including file, group, drive, VM, administrative, and privileged-user activity, with the full record content defined under AU-3. Because every access to encrypted data requires a logged key request, record generation is inherent to the data access path and cannot be bypassed by users or administrators. Generated records are hash-chained and pushed one way to tiCrypt Audit, and if the logging service fails, dependent services stop so that activity cannot proceed ungenerated.
Identification and Authentication (IA)
Family · IAtiCrypt identifies and authenticates every user and device through per-user RSA-2048 key pairs, a replay-resistant challenge-response protocol, and optionally enforced multi-factor authentication, with all cryptographic operations performed by a FIPS 140-3 validated module.
Requirement. Uniquely identify and authenticate organizational users before granting system access.
tiCrypt Implementation. Each tiCrypt user receives a unique RSA-2048 (FIPS 186-5) key pair generated at account creation, and the public key serves as the basis of the user identity. Authentication is challenge-response: the server issues a random, single-use nonce, the client signs it with the user private key, and the server verifies the signature against the stored public key. No password is transmitted to or stored by the server. A user cannot access the system without successfully completing this cryptographic proof of identity.
Requirement. Implement multi-factor authentication for access to privileged accounts.
tiCrypt Implementation. tiCrypt integrates an external MFA provider as an independent proof-provider in the authentication flow. When enabled, the signed MFA certificate is verified alongside the RSA challenge response, so a session is established only when both proofs succeed, and the deployment can require this for network access to both privileged and non-privileged accounts. MFA enforcement is a configurable deployment option: the organization enables the external MFA provider integration and sets the accounts and conditions under which it is required.
Requirement. Implement replay-resistant authentication mechanisms for access to accounts.
tiCrypt Implementation. Every authentication uses a random, single-use nonce issued by the server and signed by the client with the user private key. Because each nonce is valid for exactly one authentication attempt, a captured challenge response cannot be replayed to establish a later session. This replay resistance is inherent to the protocol and applies to all accounts.
Requirement. Uniquely identify and authenticate devices before establishing a connection.
tiCrypt Implementation. Devices are uniquely identified and authenticated before a remote connection is established. Device authentication uses public/private key based authentication, so a connecting device must present a valid cryptographic proof tied to its unique key material before any session traffic is accepted.
Requirement. Manage system identifiers, prevent their reuse, and disable identifiers after a defined period of inactivity.
tiCrypt Implementation. Each user identity is bound to a unique RSA-2048 key pair generated at account creation, and identifiers and keys are never reused, so a retired identity cannot be reassigned. tiCrypt automatically disables accounts that remain inactive beyond a configurable period, removing their access to the system. The cryptographic binding between the identifier and the key pair ensures that each identifier maps to exactly one user for the life of the system.
Requirement. Manage system authenticators, including protecting authenticator content from unauthorized disclosure and modification.
tiCrypt Implementation. The authenticator is the user RSA private key, which is generated at account creation and encrypted client-side with the user password. The server never receives the password or the plaintext private key and stores no material that enables offline brute force: the salt and initialization vector are released only after a successful connection. After five failed decryption attempts the account locks, limiting online guessing against the authenticator.
Requirement. Enforce password composition rules and protect passwords in storage and transmission.
tiCrypt Implementation. The user password is never used as a network authenticator; it only decrypts the RSA private key locally on the client, and private-key password complexity is enforced. New passwords are screened against common and compromised password lists so weak choices are rejected. Because no password is transmitted to or stored by the server, and the salt and initialization vector are released only after a successful connection, there is no server-side password material exposed to disclosure or offline attack. Enforcement of password-reuse history across generations is left to the deploying organization.
Requirement. For public key-based authentication, validate certificates by constructing a certification path to a trust anchor and enforce authorized access to the corresponding private key.
tiCrypt Implementation. tiCrypt authentication is PKI-based: the user key is validated against a site-key chain of trust, and user, escrow, and software certificates all trace back to the site key as the trust anchor. Access to the private key is enforced by client-side encryption under the user password, so only the individual who knows the password can use the key. The server verifies each challenge response against the public key associated with the validated identity.
Requirement. Obscure feedback of authentication information during the authentication process.
tiCrypt Implementation. Password entry is obscured; passwords are displayed as non-differentiated characters. On authentication failure the client presents a single generic error message that does not reveal which element of the authentication process failed, preventing an observer from learning whether the identifier, password, or MFA proof was incorrect.
Requirement. Implement mechanisms for authentication to a cryptographic module that meet applicable requirements.
tiCrypt Implementation. All tiCrypt cryptographic operations run through a FIPS 140-3 validated cryptographic module. Authentication to the cryptographic module follows the module vendor procedures, consistent with the requirements of the module validation.
Requirement. Require users to re-authenticate when defined circumstances or situations occur.
tiCrypt Implementation. tiCrypt requires re-authentication with the private-key password after a period of inactivity. Administrators must also re-authenticate when switching between system layers, ensuring that elevated contexts are never entered on the strength of a stale session.
System and Communications Protection (SC)
Family · SCtiCrypt enforces communications protection through a three-layer architecture in which all data is encrypted end to end with client-held keys, all network access traverses a deny-all boundary admitted only by cryptographic key challenge, and user workloads execute inside logically isolated Secure VMs. Cryptographic operations use AES-256, RSA-2048, and SHA-256 through a FIPS 140-3 validated module.
Requirement. Separate user functionality, including user interface services, from system management functionality.
tiCrypt Implementation. The tiCrypt architecture separates the work layer, where user activity occurs inside Secure VMs, from the tiCrypt security layer, which provides end-to-end encryption and the management interface, and from the physical infrastructure layer. The backend consists of ten loosely coupled microservices, each with its own database and no shared state, communicating only over TCP, so management functions are structurally isolated from user workloads. User work executes exclusively inside Secure VMs and cannot reach system management services directly. This layered, least-privilege, zero-knowledge design reflects the security engineering and architectural principles for building the system securely.
Requirement. Prevent unauthorized and unintended information transfer via shared system resources.
tiCrypt Implementation. Secure VMs boot from immutable images that reset on every boot, so no residual user information persists in a VM between sessions or is exposed to a subsequent user. Each user's work runs in a separate Secure VM on an encrypted drive whose keys are held only by the data owner and the in-VM controller. Because every microservice maintains its own database with no shared state, compromise of one service does not expose another service's data or keys.
Requirement. Protect against or limit the effects of denial-of-service events.
tiCrypt Implementation. Only ports 22 and 443 accept inbound connections, and all traffic that does not pass the cryptographic key challenge is dropped at the deny-all firewall before reaching interior services. Secure VMs deny all inbound and outbound traffic by default. This sharply limits the surface available to a flooding or protocol-abuse attack; network-layer denial-of-service defense at the perimeter remains a shared responsibility with the deploying organization and its network provider.
Requirement. Monitor and control communications at the external boundary and key internal boundaries of the system.
tiCrypt Implementation. The external boundary permits inbound traffic only on ports 22 and 443 and denies everything else by default. All user access flows through the tiCrypt Connect client, which establishes managed, encrypted tunnels terminating at a deny-all firewall; only traffic certified by the cryptographic key challenge is admitted. Internally, Secure VMs are logically isolated from other VMs and from the network, accept no direct inbound connections, and expose only a controller-managed tunnel that does not run SSH.
Requirement. Limit the number of external network connections to the system.
tiCrypt Implementation. The system exposes exactly two inbound ports, 22 and 443, and a single access path: the tiCrypt Connect client tunnel terminating at the deny-all firewall. Secure VMs present no external access points of their own; their only open port is a controller-managed tunnel, and all VM traffic is mediated by the encrypted proxy. This design reduces external connectivity to one managed, cryptographically gated channel.
Requirement. Deny network communications traffic by default and allow it by exception.
tiCrypt Implementation. Deny by default is enforced at every layer. Inbound, all ports except 22 and 443 are denied, and the tunnel terminates at a deny-all firewall that admits only traffic certified by the cryptographic key challenge. Outbound, Secure VMs deny all traffic by default; the only exceptions are explicit licensing allowlist entries, and creating such an entry requires the highest privilege in the system.
Requirement. Prevent split tunneling for remote devices connecting to the system.
tiCrypt Implementation. Remote access is possible only through the software-defined network established by the tiCrypt Connect client. Every packet stream entering the boundary must be certified by the cryptographic key challenge; non-certified streams are rejected outright. A remote device therefore cannot route traffic into the system outside the managed tunnel, which structurally prevents split tunneling.
Requirement. Protect the confidentiality and integrity of transmitted information.
tiCrypt Implementation. All information in transit is protected end to end between the client and the destination using keys held by the client, not by intermediary infrastructure. VM session traffic is mediated by an end-to-end encrypted proxy over mutually authenticated WebSocket connections with Diffie-Hellman key negotiation; after the handshake, no component between the user and the VM, including the proxy itself, can read session traffic. Integrity is verified with SHA-256 hashing.
Requirement. Implement cryptographic mechanisms to prevent unauthorized disclosure of and detect changes to information during transmission.
tiCrypt Implementation. Transmission protection uses AES-256 (FIPS 197) for data encryption, RSA-2048 (FIPS 186-5) for key wrapping and authentication, and SHA-256 (FIPS 180-4) for integrity, all through a FIPS 140-3 validated cryptographic module. Session keys for VM traffic are negotiated per connection with Diffie-Hellman exchange over mutually authenticated channels, so disclosure or modification in transit is cryptographically prevented and detectable.
Requirement. Terminate the network connection associated with a communications session at the end of the session or after a defined period of inactivity.
tiCrypt Implementation. The encrypted tunnel is torn down when the session closes, ending the network connection rather than leaving it open. After a configurable idle interval, 15 minutes by default, the session locks and requires re-authentication, and the network connection is terminated if the session is not resumed. The deploying organization sets the idle interval to match its policy.
Requirement. Establish and manage cryptographic keys when cryptography is employed within the system.
tiCrypt Implementation. RSA key pairs are generated on the client side, so private keys never originate on or transit through the server. A site-key chain of trust signs certificates, anchoring key authenticity. Key recovery uses multi-party escrow that requires a minimum of three independent escrow groups, so no single holder can recover a key alone; the organization defines the escrow group membership during deployment.
Requirement. Implement cryptography in accordance with applicable laws and standards, including FIPS-validated cryptography for protecting CUI.
tiCrypt Implementation. tiCrypt does not implement its own cryptography. All cryptographic operations are performed exclusively by the OpenSSL 3.1.2 FIPS provider (CMVP certificate #4985) with FIPS mode enabled on the virtual machine operating system, for both standalone Secure VMs and the Slurm HPC integration. The platform uses AES-256 (FIPS 197) for data, RSA-2048 for authentication and digital signatures per FIPS 186-5, and SHA-256 (FIPS 180-4) for hashing, with all RSA key-encapsulation and key-transport operations carried out inside the validated module in its approved mode. Because every operation runs in the validated module under FIPS mode, the FIPS-validated cryptography requirement for protecting controlled unclassified information is satisfied.
Requirement. Prohibit remote activation of collaborative computing devices and indicate use to users present at the device.
tiCrypt Implementation. Collaborative computing devices such as shared cameras and microphones are not supported by the tiCrypt platform. Because the capability does not exist, remote activation is not possible, and the control is satisfied by exclusion.
Requirement. Protect the authenticity of communications sessions.
tiCrypt Implementation. Session authenticity is ensured by a secure channel established over the managed tunnel using public-key cryptography, with RSA-2048 authentication binding the session to the client-held key. VM connections use mutually authenticated WebSocket channels with per-session Diffie-Hellman key negotiation, so neither endpoint can be impersonated and a session cannot be hijacked or replayed by an intermediary.
Requirement. Protect the confidentiality of information at rest.
tiCrypt Implementation. Vault file content is split into 8 MB chunks, each independently encrypted with AES-256 (AES-CBC) using keys held only by the data owner, so file content at rest is protected as ciphertext and no server-side component holds the keys to decrypt it. VM storage uses encrypted drives, LUKS on Linux or BitLocker on Windows, with AES-256. File and directory metadata, including names, is stored separately in the platform database and is not encrypted at rest, so deploying organizations must avoid placing CUI in file or directory names. The at-rest cipher provides confidentiality; integrity of stored content relies on the surrounding platform controls rather than an authenticated-encryption mode.
Requirement. Maintain a separate execution domain for each executing process.
tiCrypt Implementation. User work executes inside separate Secure VMs on encrypted drives, giving each workload its own hardware-virtualized execution domain that is logically isolated from other VMs and from the network. Within the VM, the kernel disallows stack execution, blocking a common class of code-injection attacks. Backend microservices are similarly separated, each with its own database and no shared state.
Configuration Management (CM)
Family · CMtiCrypt provides the technical mechanisms for this family, including least functionality, controlled software execution inside Secure VMs, and information location controls, while the deploying organization owns and operates the broader change-management program, including change approval, testing, and documentation processes.
Requirement. Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.
tiCrypt Implementation. Changes to tiCrypt-level configuration, including teams, projects, and permissions, are restricted to designated administrators, and security-layer changes are separated from the data they protect. Software components are distributed as digitally signed packages tied to a site-key chain of trust, so unsigned or tampered components are not accepted. Secure VMs boot from immutable, signed images that reset on every boot; changes to the VM system disk are discarded at shutdown, so no unauthorized persistent modification survives. The organization assigns administrator roles and operates the change approval and documentation process around these mechanisms.
Requirement. Configure the system to provide only essential capabilities and restrict the use of nonessential functions, ports, protocols, and services.
tiCrypt Implementation. The platform is architected deny-by-default: only essential functions, ports, protocols, and services are enabled, with inbound access limited to ports 22 and 443. Secure VM images contain only pre-approved software, and data cannot leave the enclave without explicit authorization. This restricts each project environment to the minimum functionality required for its research workload.
Requirement. Prevent program execution in accordance with defined policies, rules of behavior, and access agreements regarding software program usage.
tiCrypt Implementation. Software execution inside Secure VMs is controlled per project: software can be blacklisted to prevent it from being brought into a VM or whitelisted to explicitly permit it, matching each project's authorization rules. Before an image is created for a project, all software is expressly authorized and no other software may be added to the image. The kernel additionally disallows stack execution, blocking a common malicious-code execution path.
Requirement. Identify software programs not authorized to execute and employ a deny-by-exception policy to prohibit their execution.
tiCrypt Implementation. tiCrypt supports per-project software blacklisting, preventing identified software from being brought into a Secure VM. Because project needs vary, there is no single global rule; the organization defines which software is prohibited for each project and configures the corresponding blacklist. Blacklisted software cannot be introduced into the project's Secure VMs.
Requirement. Identify software programs authorized to execute and employ an allow-by-exception policy to permit execution of only authorized software.
tiCrypt Implementation. tiCrypt supports per-project software whitelisting, under which only explicitly permitted software may be used inside a project's Secure VMs. Secure VM images include only pre-approved software: images are built and certified outside the enclave, signed, then inserted for a project, and before an image is created all software is expressly authorized with no other software permitted to be added. The organization defines the authorized software list for each project and configures the whitelist accordingly.
Requirement. Establish and enforce policies governing the installation of software by users and monitor compliance.
tiCrypt Implementation. Users may install software inside a Secure VM only when the installation does not require host or administrator privilege and the project imposes no constraint on that software. Project-level blacklists and whitelists enforce the organization's installation policy, and any software installed on the VM system disk is discarded at shutdown because Secure VMs reset to their signed image on every boot. Where a project requires additional software, custom images can be built and certified to meet the project's requirements. The organization defines the per-project installation policy that these mechanisms enforce.
Requirement. Identify and document the location of information and the specific system components on which the information is processed and stored.
tiCrypt Implementation. Each project's data is segregated into project-specific Secure VMs and encrypted drives, so the location of a project's information is defined by its assigned components. Only users with explicitly assigned permissions and valid certifications can reach a project's data, and data cannot leave the enclave without explicit authorization. This structural segregation makes the processing and storage location of each project's information identifiable and enforced by the platform.
System and Information Integrity (SI)
Family · SItiCrypt partially addresses the SI family through anti-virus scanning integration on encrypted drives, digitally signed software and VM images validated against a site-key chain of trust, SHA-256 hash-chained audit logs, sanitized error handling, and reliance on operating-system memory protections.
Requirement. Identify, report, and correct system flaws in a timely manner.
tiCrypt Implementation. Tera Insights tracks security flaws in the tiCrypt platform and issues corrections as digitally signed updates tied to the site-key chain of trust. Secure VM images are rebuilt from updated, signed base images so that fixes take effect on the next boot. The deploying organization applies platform updates and rebuilds images on its own remediation cadence, making flaw remediation a shared responsibility.
Requirement. Implement malicious code protection at system entry and exit points to detect and eradicate malicious code.
tiCrypt Implementation. Within Secure VMs, tiCrypt scans files with the organization's anti-virus software when they are imported into encrypted drives and again on every read and write. Secure VMs boot from immutable images that reset at each boot, so persistent malware and rootkits cannot survive a reboot. The organization supplies and manages the specific anti-virus product; tiCrypt provides the scanning integration and the reset-on-boot guarantee.
Requirement. Monitor the system to detect attacks, indicators of potential attacks, and unauthorized connections.
tiCrypt Implementation. tiCrypt Audit ingests the platform tamper-evident event stream and supports severity-based alerting and ad hoc forensic queries over more than 110 event types, giving monitoring staff near real-time visibility into authentication, access, and administrative activity. The deploying organization operates the monitoring program, defines the alert conditions it acts on, and integrates the audit stream with its own security monitoring, making system monitoring a shared responsibility.
Requirement. Employ integrity verification tools to detect unauthorized changes to software, firmware, and information.
tiCrypt Implementation. tiCrypt components are distributed as digitally signed packages tied to a site-key chain of trust and are validated before deployment. VM images are signed and certified, and every VM boots from the original signed image. Audit logs are SHA-256 hash-chained in an append-only structure, so any modification to recorded log entries is detectable.
Requirement. Perform integrity checks of software, firmware, and information at startup or at defined transitional states.
tiCrypt Implementation. The platform detects unauthorized modification of operating-system and application software and reverts affected components to the authorized signed state. Because every Secure VM boots from its original signed and certified image, each boot performs an implicit integrity restoration that discards any unauthorized changes made during a prior session.
Requirement. Generate error messages that provide information necessary for corrective actions without revealing information that could be exploited, and reveal them only to authorized personnel.
tiCrypt Implementation. tiCrypt displays error messages only to authorized personnel. Error messages and error logs are written to avoid revealing sensitive information; for example, account numbers, identifiers, and medical data are not placed in error logs.
Requirement. Implement safeguards to protect system memory from unauthorized code execution.
tiCrypt Implementation. The platform relies on operating-system memory protections, such as disallowing execution of code from the stack, to prevent unauthorized code execution in memory. These protections apply to the environments in which tiCrypt components run.
Media Protection (MP)
Family · MPtiCrypt provides the cryptographic dimension of media protection: all data written to storage media is encrypted with AES-256 under keys held only by the data owner, so possession of any physical medium yields only ciphertext. Physical media handling, labeling, marking, and custody remain the responsibility of the deploying organization.
Requirement. Physically control and securely store system media containing sensitive information.
tiCrypt Implementation. tiCrypt provides the cryptographic component of secure media storage: all data at rest is encrypted with AES-256 (FIPS 197) before it reaches any storage medium, using keys held only by the data owner on the client side. Encrypted drives use LUKS on Linux or BitLocker on Windows with AES-256, and Vault files are split into 8 MB chunks that are each independently encrypted. The infrastructure never holds plaintext or encryption keys, so physical possession of a storage medium yields only ciphertext. Physical control and custody of the media themselves are handled by the deploying organization.
Requirement. Implement cryptographic mechanisms to protect the confidentiality of information stored on media during transport outside controlled areas.
tiCrypt Implementation. Because tiCrypt encrypts all data end-to-end with AES-256 before it reaches storage, information on any medium is already ciphertext at the moment the medium is created. Encrypted media and backups can therefore be transported or stored on untrusted media without exposing the underlying data. Decryption requires the data owner's RSA private key, which never leaves the owner's control, so interception or loss of media in transit does not compromise confidentiality.
Requirement. Sanitize system media before disposal, release, or reuse so that information cannot be recovered.
tiCrypt Implementation. tiCrypt implements sanitization of file content through cryptographic erasure. Each resource is encrypted under its own unique AES-256 key, and destroying that key renders the corresponding ciphertext permanently unrecoverable and computationally indistinguishable from random noise, across all copies including backups, with no disk-level overwriting required. Because the infrastructure never holds keys or plaintext, no residual recoverable content remains after key destruction; unencrypted file and directory metadata in the platform database is sanitized through the organization media procedures.
Supply Chain and Backup Integrity (SR / CP / SA)
Family · SR · CP · SAtiCrypt is distributed as digitally signed software whose components trace to a site-key chain of trust, and all data it manages is encrypted at all times, so backups contain only ciphertext. Tera Insights develops, tests, and releases tiCrypt under configuration management with pre-release security evaluation.
Requirement. Implement cryptographic mechanisms to prevent unauthorized disclosure and modification of backup information.
tiCrypt Implementation. All tiCrypt data is always encrypted, so any backup contains only ciphertext. The same cryptographic mechanisms that protect live data protect the confidentiality of backups, and decryption requires the data owner's RSA private key, which is never present in the backup. As a result, vault chunks can be replicated to untrusted or cloud storage without compliance risk.
Requirement. Develop and implement anti-counterfeit measures that detect and prevent counterfeit components from entering the system.
tiCrypt Implementation. tiCrypt software is distributed as digitally signed packages. VM images and user, escrow, and software certificates trace to a site-key chain of trust. Signatures are verified before deployment, so tampered or counterfeit components are detectable and rejected before they enter the system.
Requirement. Require the system developer to perform configuration management during development, track security flaws and their resolution, and control the integrity of changes.
tiCrypt Implementation. Tera Insights develops tiCrypt under configuration management and tracks security flaws and their resolution through release. Only builds that complete this process are digitally signed for distribution, so the integrity of each released component is verifiable against the signing chain. Releases are validated in a staging instance before production deployment.
Requirement. Require the system developer to perform security testing and evaluation and to correct identified flaws.
tiCrypt Implementation. Tera Insights performs security testing and evaluation of tiCrypt before releasing signed builds. Identified flaws are tracked to resolution as part of the development process. Each release is validated in a staging instance before it is deployed to production.
Summary
tiCrypt implements the technical core of a NIST SP 800-171 Revision 3 and CMMC 2.0 Level 2 compliant environment: cryptographic access control, tamper-evident auditing, public-key identification and authentication, boundary and communications protection, and protection of information at rest and in transit. Because every one of these controls is enforced with keys the infrastructure never holds, none can be silently bypassed by a compromised server or a privileged insider. Combined with the organizational controls that remain the deploying institution's responsibility, the platform supplies the technical foundation for an authorized, compliant secure-research enclave.
For the cryptographic architecture behind these controls, see the tiCrypt Security Architecture whitepaper.