> ## Documentation Index
> Fetch the complete documentation index at: https://syteca.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Syteca Encryption
> Cryptographic architecture of Syteca — RSA-2048 Master Certificate, AES-256 for monitoring data, FIPS 140-2 certified implementations, Diffie-Hellman key exchange, and SHA-256 password hashing.
## Cryptography that satisfies the security review
Every security buyer evaluating a monitoring or PAM platform asks the same questions: *what algorithms, what key lengths, what key exchange, where are keys stored, how is data at rest protected, how are connections encrypted*. The answers either satisfy the security team or stop the procurement. This page is the complete cryptographic architecture of Syteca — built around **FIPS 140-2 certified implementations** on both ends (Application Server and Client), so the answers fit on a single page.
| Layer | Algorithm | Implementation |
| ------------------------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------- |
| **Master encryption** | RSA-2048 (Syteca Master Certificate) | Microsoft .NET Framework (Application Server) |
| **Monitoring binary data** | AES-256 in CTR mode (per-fragment Key/IV pairs, wrapped by Data Protection certificate) | Crypto++ (Client side); .NET (Application Server) |
| **Client ↔ Application Server connections** | AES-256, with key generation via Diffie-Hellman | Crypto++ 5.6.1 |
| **Application Server ↔ Management Tool** | TCP encrypted with self-signed certificate | WCF .NET |
| **Browser ↔ Management Tool** | HTTPS (certificate defined before MT install) | Standard TLS |
| **Application Server ↔ Database** | Optional SSL (MS SQL Server, PostgreSQL, AWS RDS for PostgreSQL) | Standard database SSL |
| **Internal user passwords** | SHA-256 hash | .NET |
| **PAM secrets (privileged credentials)** | AES-256 | .NET |
| **Forensic Export files** | RSA-1024 | .NET |
| **TOTP initial vectors** | Encrypted with Syteca Master Certificate | .NET |
| **Database connection string** | Encrypted with Syteca Master Certificate, stored in registry | .NET |
**FIPS 140-2 certified.** All encryption algorithms in Syteca use **FIPS 140-2 certified implementations** on both the Application Server side (Microsoft .NET Framework) and the Client side (Crypto++). FIPS 140-2 compliance is required for many US federal contracts and is a common control in SOC 2 Type II, NIST 800-53, and similar frameworks.
## The Syteca Master Certificate
On its **first startup**, the Syteca Application Server generates the **Syteca Master Certificate** — internally identified as `EkranMasterCertificate` — and stores it in the Windows Certificate Store on the Application Server host. The Master Certificate is a unique **RSA-2048** certificate, and without it, Syteca cannot read its own encrypted data.
The Master Certificate sits at the top of Syteca's key hierarchy. It encrypts:
* The **Syteca Data Protection certificate** (which encrypts all monitoring data — see below).
* The **TOTP initial vectors** in the database.
* The **database connection string** stored in the Windows registry.
* The password protecting the symmetric key used to encrypt logged keystrokes.
**The Master Certificate must be backed up before moving the database.** If the Master Certificate is lost, the database becomes unreadable — there is no recovery mechanism. See [Export the Master Certificate](/docs/administration/security/master-certificate#export-the-master-certificate) and [Import the Master Certificate](/docs/administration/security/master-certificate#import-the-master-certificate) for the backup and migration procedures.
For storing the Master Certificate in a Hardware Security Module instead of the Windows Certificate Store, see [Move the Master Certificate to a Thales HSM](/docs/administration/integrations/thales-hsm).
## Monitoring data encryption
The flow for encrypting captured screen captures and other binary monitoring data:
1. **At Client side, during recording:** for each fragment of binary data, a fresh **AES-256 Key / IV pair** is generated. The fragment is encrypted with this pair.
2. **The Key/IV pair itself** is then encrypted with the public key of the **Data Protection certificate** (an RSA-2048 certificate whose public key is distributed to all Clients; its private key stays only on the Application Server).
3. **Both the encrypted fragment and the encrypted Key/IV pair** are sent to the Application Server, where they're stored in the database.
4. **At decryption time** (when an authorized user views a session in the Session Viewer), the Application Server uses the Data Protection certificate's private key to decrypt the AES-256 Key/IV pair, then uses that to decrypt the binary data fragment.
| Detail | Value |
| -------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Per-fragment symmetric algorithm | **AES-256** in **CTR mode** *(also called Integer Counter Mode / ICM or Segmented Integer Counter / SIC)* |
| Per-fragment Key/IV wrapper | **RSA-2048** Data Protection certificate (public key only on Clients) |
| Master wrapper | **RSA-2048** Syteca Master Certificate (encrypts Data Protection certificate) |
**The Data Protection certificate's private key never leaves the Application Server.** Clients only have its public key. This means a compromised Client can encrypt data going *into* the database but cannot decrypt data already there.
**Offline-cached data is already stored encrypted.** When a Client is offline and caches monitoring data locally before transmission, that local data is already in the encrypted form described above — no additional encryption pass is needed when the Client reconnects.
### Keystroke encryption
Logged keystrokes are encrypted in both MS SQL and PostgreSQL databases using a **symmetric key**. The symmetric key itself is stored in the database, password-protected, and **the password is encrypted with the Syteca Master Certificate** — completing the chain back to the root of the key hierarchy.
## Connection encryption
### Client ↔ Application Server
Each Client establishes an AES-256-encrypted connection to the Application Server. The key for this connection is generated using the **Diffie-Hellman key exchange algorithm** — meaning the encryption key is never transmitted across the network, only derived independently on both sides from shared exchanged values.
| Detail | Value |
| ------------------- | ----------------------------------------- |
| Symmetric algorithm | **AES-256** |
| Key derivation | **Diffie-Hellman key exchange** |
| Library | **Crypto++ 5.6.1** *(on the Client side)* |
### Application Server ↔ Management Tool
The TCP connection between the Application Server and the Management Tool is encrypted with a **self-signed certificate** using **WCF .NET**. This is a server-internal connection — typically inside the same network or trusted infrastructure.
### Browser ↔ Management Tool (HTTPS)
User browsers reach the Management Tool over standard **HTTPS**. The TLS certificate used is defined before installing the Management Tool — for production deployments, use a certificate from your organizational PKI rather than the default self-signed one. See [Using a self-signed certificate](/docs/administration/deployment/management-tool-prerequisites#4-provide-an-ssl-certificate) for the configuration steps.
### Application Server ↔ Database
The connection between Application Server and database can be configured for **SSL encryption** — supported for both **MS SQL Server** and **PostgreSQL**, including **AWS RDS for PostgreSQL** managed databases. See [Configuring SSL for the database connection](/docs/administration/database/database-parameters) for the configuration steps.
## Other encrypted data
| Data | Algorithm | Notes |
| ------------------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------- |
| **Time-based one-time password (TOTP) initial vectors** | Encrypted with the Syteca Master Certificate | Stored in the database |
| **Internal user passwords** | **SHA-256 hash** | Stored in the database; non-reversible |
| **PAM secrets (privileged credentials)** | **AES-256** | Stored in the database |
| **Forensic Export files** | **RSA-1024** | Standalone file encryption — see [Forensic Export](/docs/session-monitoring/forensic-export) |
Forensic Export files use **RSA-1024**, which is weaker than the RSA-2048 used elsewhere. For evidence handovers where stronger encryption is required, optionally protect the export with an additional **password** (configured at export time) and use a secure transport channel separate from the hash verification. See [Forensic Export](/docs/session-monitoring/forensic-export) for the password protection and SHA-256 integrity verification workflow.
## Related
Store the Master Certificate in a Thales Hardware Security Module instead of the Windows Certificate Store.
Configuration for HTTPS certificates between browser and Management Tool.
Encrypted session evidence with SHA-256 integrity hashing and optional password protection.
Audit trail of administrative actions — complements the encryption controls described here.