Deployment Options

Deployment without Application Servers

Deployment with Application Servers

Deployment with Separate Application, Database, and BI Servers

High Availability (HA)

Native, built-in high availability can be fine tuned and adapted for different scenarios

Please check out the High Availability (HA) article for more information.

Communications Protocols & Ciphers

1	The web interface uses HTTPS over TCP port 443 by default. This web management interface port can be changed in the settings if needed. TLSv1.2 Ciphers: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp384r1) TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048)
2	Agents connect to the master node over HTTPS (443 by default) and uses the same encryption settings as in #1. That port can be changed in the settings as well (load balancer port). Agents also connect using a proprietary protocol on port TCP 10000 (if no Application Servers deployed). Encryption information for port 10000 is listed below: TLSv1.2 Ciphers: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp384r1) TLS_RSA_WITH_AES_128_CBC_SHA (RSA 2048) TLS_RSA_WITH_AES_128_CBC_SHA256 (RSA 2048) TLS_RSA_WITH_AES_128_GCM_SHA256 (RSA 2048) TLS_RSA_WITH_AES_256_CBC_SHA (RSA 2048) TLS_RSA_WITH_AES_256_CBC_SHA256 (RSA 2048) TLS_RSA_WITH_AES_256_GCM_SHA384 (RSA 2048) Optionally can be reduced to ECDHE ciphers only
3	The Master node communicates with Miner nodes over multiple ports with different encryption settings. All communication between nodes should happen over private secure network. Only the Master (and Application Server nodes if any) should be exposed to public. Ports Used for Miners: 22, SSH, optional - used to update child nodes through master 443, HTTPS, same ciphers as in #1 5432, PostgreSQL, supports connections without encryption 42001, proprietary protocol, no encryption, node lifecycle events are broadcasted through this port 50051, HTTPS (Google grpc)
4	Same ports as in #3, with addition of Elasticsearch on port 9200 (HTTPS).
5	Miners communicate with the Mining DB node only over 9200 port (Elasticsearch, HTTPS). Access control is IP-based, i.e., Mining DB Node servers request only from Master Node or Miner Nodes.
6	Application servers communicate with Master Node using the following ports: Ports Used for Application Servers: 22, SSH, optional - used to update child nodes through master 443, HTTPS, same ciphers as in #1 5432, PostgreSQL, supports connections without encryption 6379, Redis, no encryption 10000 - 11000, HTTPS (web sockets), each application server process acts as a web socket server on an odd port in 10000-11000 range, this web socket connection is used when streaming live screen video/audio. 42001, proprietary protocol, no encryption, node lifecycle events are broadcasted through this port.
7	Application servers receive agent connections on even ports in range 10000 - 11000, using the same encryption settings as in #2 for port 10000.

Connections

Agent ↔ Server Connection

Master ↔ Child Node Connection

In general, agents push data to the server, the server never initiates connection to the agent.
Agents connect to the master node on port 443 (by default) over TLS and receives the IP address of a server where it connects using proprietary protocol on port 10000.
When connected over port 10000, the agent sends username, computer information, etc. and the server identifies the agent.
If live audio monitoring is enabled, the server opens a random UDP port (1024 - 65535) and generates a key for audio data encryption and then sends the port and key to the agent. After these configuration steps are completed, the agent communicates with the server via established TLS channel and sends audio frames encrypted with Blowfish cipher over the UDP port.

It is expected that communication happens over a private secure network.
There is a very basic level of security applied to the communication between nodes.
Nodes serve requests only from other approved nodes identified by IP address.

Default Encryption

1	Recorded user behavior data can be stored on the endpoint in some circumstances (for example when the agent is offline). For this type of data envelope encryption (RSA+AES) is used (with the server public key used as key encryption key). The agent generates random AES key material and keeps it unencrypted in memory only. When encrypted data is written to disk, the AES key is encrypted with server's public key and written alongside data.
2	Configuration caches don't contain any sensitive information and are being read by the client itself. Basic symmetric encryption with hardcoded key is used to discourage tampering/reverse-engineering.
3	Data is transmitted to the server using secure TLS channel. Certificate pinning of both parties can be enabled.
4	Unencrypted data transmitted by agent is processed by server and written to disk. Data at rest is not encrypted on the server side. It is expected that some disk-level encryption solutions are used on the hypervisor level.
5	Encrypted data with encrypted key is transmitted to the server using secure TLS channel. The server decrypts AES data encryption key with its private key. Encrypted data is decrypted using AES.

End-to-End Encryption

Overview

1	There is an option to use full end-to-end encryption for sensitive data such as emails, keystrokes, and screen recordings. In this case, the same envelope encryption method is used, but the server does not have a private key to decrypt data. An AES encryption key is generated by the agent process and encrypted with configured RSA public key.
2	Encrypted sensitive data and encrypted AES encryption key is sent to server.
3	The server writes encrypted data alongside encrypted data encryption key to disk.
4	The viewer of encrypted data provides private key for decryption.
5	The server reads encrypted data and encrypted encryption key from disk. The server decodes the data encryption key using the provided private key. The decrypted key is stored in memory only. The server then decrypts data using the decrypted key and sends it to the viewer. Afterwards, the decrypted key and data are trashed from the server's memory.

Data Flow

1	The agent reads the RSA public key used for Key Encryption Key (KEK) from a specific location on disk. There is no limitation for the numbers of KEKs used in the system. It can be per-endpoint KEK or per-department KEK or any other method (Possibility to integrate with third-party KMS solutions).
2	The agent generates a random AES key used for data encryption (Data Encryption Key – DEK).
3	The AES data encryption key (DEK) is encrypted (wrapped) using the RSA encryption key (KEK).
4	Data is encrypted with the AES key (DEK).
5	Encrypted data and wrapped DEK are transferred to the server. Since the DEK is encrypted (wrapped), the server cannot decrypt the data.
6	The private part of the KEK is protected with a passphrase (encrypted) and stored on the server. (Possibility to integrate with third-party KMS solutions).
7	When the viewer attempts to view the data, they should supply a passphrase of the corresponding KEK private part.
8	When the passphrase is provided, the server decrypts the wrapped DEK using the KEK private part and supplied passphrase.
9	After the DEK is unwrapped (decrypted), data can be decrypted.
10	Decrypted data is sent to the viewer.

Key Management

There is no automated key management currently.
Keys should be distributed to the endpoints and put into specific locations.
The server configuration is performed through the database directly, no web interface settings are available.
Integration with third-party key management solutions is possible in the future.

Endpoint

The agent reads the KEK data from C:\ProgramData\{4CEC2908-5CE4-48F0-A717-8FC833D8017A}\certs\kek.pem.
The file should contain the RSA2048 public key in PEM format, without a passphrase..

Server

KEK public/private parts should be stored as PEM files (RSA public/private key) under /usr/local/teramind/conf path.
The private key should be encrypted with a passphrase.
After that, KEKs should be registered in the DB in the encryption_kek table.
There should be only one record for each KEK.
Example of SQL to register KEK:

insert into encryption_kek(pub_datafile, priv_datafile, priv_encrypted)
values (‘/usr/local/teramind/conf/keks/kek1_pub.pem’,
‘/usr/local/teramind/conf/keks/kek1_priv.pem’, ‘t’);

A server restart is required after configuration changes.

NOTE: In multi-node deployments, PEM files should be distributed across all nodes.

OCR

Currently OCR functionality is not supported if end-to-end encryption is used. However, support might be added using the following procedure:

*Support for storing and searching of encrypted textual data is on our roadmap and will be available soon.

On-Premise Datasheet