Skip to main content

​
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.
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 and 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.

​
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.
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.

​
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 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 for the configuration steps.

​
Other encrypted data

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 for the password protection and SHA-256 integrity verification workflow.

HSM-based Master Certificate

Store the Master Certificate in a Thales Hardware Security Module instead of the Windows Certificate Store.

Self-signed certificates

Configuration for HTTPS certificates between browser and Management Tool.

Forensic Export

Encrypted session evidence with SHA-256 integrity hashing and optional password protection.

Audit log

Audit trail of administrative actions — complements the encryption controls described here.