tiCrypt

Cryptographic Modules

AdministratorRequires: Administrator access to a VM and to the backend host for the verification commands

A cryptographic module is the software that performs cryptographic operations and that the Cryptographic Module Validation Program (CMVP) validates as one unit against FIPS 140. tiCrypt implements no cryptography of its own. The operations that protect CUI are the key operations on the user's client and everything the VM controller does, and both perform them through the OpenSSL 3.1.2 FIPS provider, CMVP certificate #4985, in approved mode. Two operations run on an operating system's own module instead, because operating system software performs them: drive encryption inside a virtual machine (VM), and TLS termination by NGINX on the backend host. The backend's own cryptography protects no CUI, and it runs on the Java runtime's libraries (see The backend). A cryptographic module is not an algorithm. AES-256 is an algorithm. The module is the validated implementation of it, and the certificate belongs to the module.

Why the certificate matters

The requirement names validation, not strength. CMMC practice SC.L2-3.13.11 reads "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI." NIST SP 800-171 Revision 3 requirement 03.13.11 leaves the type of cryptography as a parameter, and the Department of Defense sets that parameter to "FIPS Validated Cryptography" (see Rev 3 Readiness). An assessor therefore asks for a certificate number. "AES-256" does not answer the question.

A certificate covers a module in a stated mode. Certificate #4985 carries the caveat "When operated in approved mode". The evidence has two parts: the module that performs each operation, and the setting that keeps that module in FIPS mode. This page gives both for every operation.

One unvalidated operation leaves the practice unmet. The System Security Plan states the control once. This page lists the operations one by one, so you can show that none of the operations that protect CUI falls outside a validated module.

The validated module

The following table describes certificate #4985 as the CMVP lists it. The details were read from the certificate page on November 12, 2026. Check the page again before an assessment, because a certificate's status changes when it reaches its sunset date or is revoked.

Field	Value
Certificate	#4985
Module name	OpenSSL FIPS Provider
Module version	3.1.2, as stated in the module's Security Policy
Vendor	The OpenSSL Project
Standard	FIPS 140-3
Overall level	1
Module type	Software
Status	Active
Validation dates	Initial validation on March 11, 2025. Updated on November 21, 2025.
Sunset date	March 10, 2030
Caveat	"When operated in approved mode. No assurance of the minimum strength of generated SSPs (e.g., keys)."
Security Policy	140sp4985.pdf. It lists the operating environments the module was tested on and the installation steps that place it in approved mode.

In the caveat, "SSPs" are sensitive security parameters, the CMVP's term for keys and similar secrets. They are not System Security Plans.

Operations and the module behind each

The following table describes each cryptographic operation in a tiCrypt deployment. "Client" is the tiCrypt application on the user's computer. "Certificate #4985" in the module column means the OpenSSL 3.1.2 FIPS provider described above.

Operation	Algorithm and parameters	Approved by	Performed by	Module and certificate	Where FIPS mode is enforced
User key pair generation	RSA-2048. The key pair is generated on the user's client.	FIPS 186-5	Client	Certificate #4985	Always on. The client has no setting that turns approved mode off.
Authentication and digital signatures	RSA-PSS with SHA-256, with the user's RSA-2048 key.	FIPS 186-5 for the signature, FIPS 180-4 for SHA-256	Client signs. The VM controller and the backend verify.	Client and VM controller: certificate #4985. Backend: the Java runtime's libraries, which are not a validated module (see The backend).	Client: always on. VM controller: at startup (see below).
Resource key wrapping	RSA-OAEP with SHA-256, with the recipient's RSA-2048 public key. This protects file keys, drive keys, and shares.	NIST SP 800-56B (key transport)	Client	Certificate #4985	Always on.
Vault file encryption	AES-256-CBC with PKCS#7 padding. Each file has its own AES-256 key. Content is encrypted in 8 MiB chunks, and a random 16-byte IV is prepended to each chunk.	FIPS 197, NIST SP 800-38A	Client	Certificate #4985	Always on.
Private key file protection	A key derived from the user's password by PBKDF2-HMAC-SHA256, with 300,000 or more iterations for new files, encrypts the private key with AES-256-CBC.	NIST SP 800-132, FIPS 197, NIST SP 800-38A	Client	Certificate #4985	Always on.
VM session key agreement	Ephemeral ECDH on curve P-256. The VM signs the handshake and the user signs the handshake transcript, both with RSA-PSS. HKDF with SHA-256 over the shared secret, with a random 32-byte salt and the transcript hash as context, produces two AES-256 keys, one for each direction.	NIST SP 800-56A (ECDH), NIST SP 800-56C (key derivation), FIPS 186-5 (signatures)	Client and VM controller	Certificate #4985	Client: always on. VM controller: at startup.
VM session traffic	AES-256-GCM with the two session keys.	FIPS 197, NIST SP 800-38D	Client and VM controller	Certificate #4985	Client: always on. VM controller: at startup.
Drive key generation and delivery	A random 256-bit key for each drive, generated on the user's client and wrapped with the user's RSA-2048 public key, so only the private key recovers it. It reaches the VM controller over the authenticated, encrypted VM session.	NIST SP 800-56B (wrapping)	Client	Certificate #4985	Always on.
Bulk drive encryption	Linux: LUKS with aes-xts-plain64 and a 512-bit volume key, which is AES-256. Windows: BitLocker with XTS-AES 256.	FIPS 197, NIST SP 800-38E	The operating system inside the VM	The operating system's own module. See Operating system modules.	The operating system's FIPS mode, enabled in the VM image.
Audit log integrity	A SHA-512 hash chain over the log entries.	FIPS 180-4	Backend logging service	The Java runtime's libraries, which are not a validated module (see The backend).	Not applicable.
Tunnel transport	TLS 1.2 or later, with ECDHE key exchange on NIST curves and AES-GCM. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is preferred.	NIST SP 800-52 Rev. 2	tiCrypt Connect and VM controller	Certificate #4985	tiCrypt Connect: always on. VM controller: at startup.
HTTPS endpoint	TLS, terminated by NGINX on the backend host with your certificate. Your NGINX configuration sets the protocol versions and cipher suites.	NIST SP 800-52 Rev. 2	NGINX, an operating system package on the backend host	The host operating system's own module. See Operating system modules.	The host operating system's FIPS mode.

The following points qualify the table.

• VM controller FIPS mode: The VM controller turns FIPS mode on when it starts, and it stops if FIPS mode cannot be turned on. The FIPSModeOff option at the top level of controller.toml disables this. Its default is false, and it must stay false where FIPS is required.
• Session key derivation: The session keys come from the two-step key derivation of NIST SP 800-56C. HMAC-SHA-256 extracts a key from the ECDH shared secret and the salt, and HKDF expands it into the two AES-256 keys. The context for the expansion is the hash of the handshake transcript, which covers the VM's ID, the user, both ephemeral keys, both nonces, and the salt, so the keys belong to that one handshake. PBKDF2 is used only where a key is derived from a password, which is the private key file.
• Handshake signatures: The user's signature covers the transcript, which includes the ephemeral key and the salt that the VM generated for this connection. A recorded handshake therefore cannot be replayed, on the same VM or on another one. A party that relays the handshake cannot change the user or any other field without the signature failing.
• Private key files: A file keeps the iteration count it was written with. A new file is written at registration, at a password change, and at escrow recovery.
• BitLocker method: BitLocker fixes the encryption method when a volume is first encrypted. A drive keeps the method it was created with, so check the method of existing drives (see Drive encryption).
• BitLocker protectors: The VM controller reads the Windows FIPS policy. When the policy is on, it protects each new drive with a BitLocker recovery password protector derived from the drive key, instead of a password protector.
• HTTPS endpoint settings: Nginx TLS Configuration covers verifying the certificate and key and creating 2048-bit Diffie-Hellman parameters. The NGINX configuration documented for tiCrypt Audit in Configuration and Setup enables TLS 1.2 and TLS 1.3 only, with AES cipher suites.
• Layering: File content, drive keys, and VM session traffic are encrypted by the client before they enter a TLS connection, so TLS is a second layer around data that is already ciphertext. Requests and metadata, such as file names, are protected in transit by TLS alone.
• FIPS 186 edition: Certificate #4985 lists the module's RSA key generation and signature testing under FIPS 186-4, the edition in force when the algorithms were tested. FIPS 186-5 replaced it and keeps RSA-PSS as an approved signature scheme.

Operating system modules

Two operations are performed by operating system software, on the operating system's own cryptographic module: drive encryption inside a VM, and TLS in NGINX on the backend host. Each operating system vendor holds its own CMVP certificates, and a certificate applies to a named release and package version. Tera Insights holds none of them. The following table describes where to find the certificate for your release.

Operating system	What it performs in a deployment	Who holds the certificates	Where to find yours
Red Hat Enterprise Linux	LUKS drive encryption in Linux VMs. TLS for NGINX on a backend host.	Red Hat	Red Hat FIPS page, which lists certificates by release and by module.
Rocky Linux	LUKS drive encryption in Linux VMs. TLS for NGINX on a backend host.	CIQ, for the packages it ships in Rocky Linux from CIQ	CIQ FIPS certification status
AlmaLinux	LUKS drive encryption in Linux VMs. TLS for NGINX on a backend host.	TuxCare, a division of CloudLinux. The validated packages are installed from the TuxCare repository.	AlmaLinux FIPS page
Ubuntu	LUKS drive encryption in Linux VMs.	Canonical. The certified modules are available with Ubuntu Pro.	Overview of FIPS-certified modules
Windows	BitLocker drive encryption in Windows VMs.	Microsoft	Windows FIPS 140 validation, which links to one page for each release with the certificate of every module.

On Linux, the kernel's cryptographic API performs the AES-XTS encryption of the drive through dm-crypt, and cryptsetup handles the LUKS header with the distribution's user-space cryptographic library. Look for both on the vendor's certificate list. The CMVP search gives the current status of any certificate.

▲FIPS mode is not the same as a validated module

Turning on an operating system's FIPS mode restricts it to approved algorithms. It does not make the installed packages a validated module. The module is validated only when the installed release and package versions match a certificate. On Rocky Linux and AlmaLinux the validated packages come from the vendors named above, and on Ubuntu they come through Ubuntu Pro. A release that its vendor's page does not list has no completed validation to cite. Record the release, the package source, and the certificate number of each VM image and of the backend host in your System Security Plan.

The backend

The backend holds no key that decrypts CUI, and it encrypts and decrypts no file or drive content. Its own cryptography has three uses, and none of them protects the confidentiality of CUI.

• Signature verification: The backend verifies the RSA-PSS signatures on logins and on signed requests.
• Tokens: The backend computes HMAC-SHA-256 values for tokens, such as multi-factor tokens.
• Audit integrity: The backend logging service computes the SHA-512 hash chain of the audit log.

These operations run on the Java runtime's cryptography libraries and on Bouncy Castle, which are not a FIPS-validated module. Practice SC.L2-3.13.11 applies to cryptography "used to protect the confidentiality of CUI". The CMMC Assessment Guide for Level 2 (version 2.13) adds: "Encryption used for other purposes, such as within applications or devices within the protected environment of the covered OSA information system, would not need to use FIPS-validated cryptography." State this in your System Security Plan next to the certificate for the operations that do protect CUI.

TLS on the backend host is a separate matter. NGINX terminates it on the operating system's validated module (see Operating system modules).

How to verify this on your deployment

Each check below produces a line or a screen that you can show an assessor.

The certificate

Open certificate #4985 and confirm that Status reads Active. Record the date you checked.

VM controller FIPS mode

• Startup log line: The VM controller writes one of two lines when it starts. On a Linux VM, read the controller log.

  journalctl -u ticrypt-vm-controller.service | grep "FIPS mode is"

  The expected line is FIPS mode is ENABLED. The line FIPS mode is DISABLED means the configuration sets FIPSModeOff = true.

• Configuration: Confirm that the controller configuration in the VM image does not disable FIPS mode. The file is /etc/ticrypt/controller.toml on Linux and C:\Program Files\Tera Insights\tiCrypt VM Controller\controller.toml on Windows.

  grep -n "FIPSModeOff" /etc/ticrypt/controller.toml

  The expected result is no output, or the line FIPSModeOff = false.

• FIPS enabled badge: The Virtual Machines table and the VM details show a FIPS enabled badge for a VM whose controller reports FIPS mode.

• Provider version: openssl list -providers prints each provider that an OpenSSL installation loads, with its name, version, and status. On a Linux VM the VM controller's OpenSSL installation is in /usr/local/ticrypt-vm-controller. Run the openssl program from that directory with list -providers. The output must include these lines.

  Providers:
    fips
      name: OpenSSL FIPS Provider
      version: 3.1.2
      status: active

  A different version means the VM image carries an older VM controller. Update the image before you cite certificate #4985 for it.

Operating system FIPS mode

• Linux: The kernel exposes a read-only flag. Run this in a VM built from each Linux image, and on the backend host.

  cat /proc/sys/crypto/fips_enabled

  The expected output is 1.

• Windows: The VM controller reads the FIPS policy from the registry. Run this in a VM built from each Windows image.

  Get-ItemPropertyValue -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy' -Name Enabled

  The expected output is 1. The VM controller writes FIPS mode is enabled on OS to its log when it reads this value. The value is set in the Enable FIPS Mode step of the Windows image procedure.

Drive encryption

• LUKS drives: The VM controller maps each unlocked drive as drive followed by its disk number. List the mapped drives with ls /dev/mapper, then read the cipher of one.

  cryptsetup status drive1

  The expected output includes the cipher aes-xts-plain64 and the key size 512 bits.

• BitLocker drives: Read the encryption method of a mounted drive. Replace E: with the drive letter.

  (Get-BitLockerVolume -MountPoint 'E:').EncryptionMethod

  The expected output is XtsAes256. Run this on every existing Windows drive that holds CUI, not only on a new one. A drive that reports another method was created before XTS-AES 256 became the method for new drives. Create a new drive and move the data to it.

Audit log integrity

The backend logging service writes hash entries into the secure log, which is /var/log/ticrypt/ticrypt-secure-log.log in the standard configuration. Each hash entry starts with ##01 and carries a SHA-512 digest of 128 hexadecimal characters.

grep -m 1 "^##01" /var/log/ticrypt/ticrypt-secure-log.log

HTTPS endpoint

Print the TLS settings that NGINX has loaded on the backend host.

nginx -T | grep -E "ssl_protocols|ssl_ciphers"

Confirm that the protocols are TLS 1.2 or later and that the cipher suites are ones your policy approves.

What your organization is responsible for

Tera Insights supplies the software and its use of the validated module. The following items stay with your organization.

• Keep FIPS mode on in the VM controller: Leave FIPSModeOff out of controller.toml or set it to false in every VM image, including in a file copied from an example.
• Build VM images with the operating system's FIPS mode on: Enable FIPS mode in each Linux and Windows image before you add it to tiCrypt, following the vendor's procedure. For Windows, see Enable FIPS Mode.
• Choose operating system releases that have a certificate: Build VM images and the backend host from a release and a package source that the vendor's certificate list names, and record the certificate numbers in your System Security Plan.
• Enable FIPS mode on the backend host: NGINX uses the host operating system's module, so the host needs FIPS mode on and a TLS configuration limited to TLS 1.2 or later.
• Keep tiCrypt current: Install tiCrypt releases and rebuild VM images so every component runs a release that uses the module on this page. The provider version check above shows what a VM image carries.
• Check existing BitLocker drives: Confirm the encryption method of drives created under earlier releases, and replace any that do not report XtsAes256.
• Protect the endpoints: The operations on this page protect data inside tiCrypt. A file that a user downloads or exports to a workstation is protected by the workstation's own cryptography, such as its disk encryption. Select validated modules for your workstations and document them.
• Keep CUI out of file and folder names: Names are metadata. They are stored in the platform database and are not encrypted by the operations above, as the System Security Plan states.
• Watch the certificate dates: Certificate #4985 has a sunset date of March 10, 2030. Check its status at each assessment, and check the status of your operating system certificates at the same time.

Related

• System Security Plan: the control statements for SC-13, SC-8, and SC-28 that this page supplies the evidence for.
• Security Whitepaper: the encryption architecture and key management in full.
• CMMC Level 2 control guide: practice SC.L2-3.13.11 and the other practices that depend on these operations.
• Scoping Guide: which components these operations run on, and why encrypted data stays in scope.
• Assessment Evidence: the artifact to show for every other practice.