Web interface uses HTTPS over port 443 by default. Port can be changed in 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)

Agents connect to master node over HTTPS (443 by default). Same encryption settings as in #1. Also agents connect using proprietary protocol on port 10000 (if no Application Servers deployed). Encryption information for port 10000:

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

Master communicates with Miner nodes over multiple ports with different encryption settings. All communication between nodes should happen over private secure network. Only 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)

Same ports as in #3, with addition of Elasticsearch on port 9200 (HTTPS).

Miners communicate with 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.

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.

Application servers receive agent connection on even ports in range 10000 - 11000, same encryption settings as in #2 for port 10000.

• In general, agents push data to the server, server never initiates connection to the agent.
• Agent connects 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 key for audio data encryption, sends port and key to the agent. After these configuration steps 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.

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). Agent generates random AES key material, keeps it unencrypted in memory only. When encrypted data is written to disk, AES key is encrypted with server's public key and written alongside data.

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.

Data is transmitted to the server using secure TLS channel. Certificate pinning of both parties can be enabled.

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.

Encrypted data with encrypted key is transmitted to the server using secure TLS channel. Server decrypts AES data encryption key with its private key. Encrypted data is decrypted using AES.

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. AES encryption key is generated by the agent process and encrypted with configured RSA public key.

Encrypted sensitive data and encrypted AES encryption key is sent to server.

Server writes encrypted data alongside encrypted data encryption key to disk.

Viewer of encrypted data provides private key for decryption.

Server reads encrypted data and encrypted encryption key from disk. Server decodes data encryption key using provided private key. Decrypted key is stored in memory only. Server decrypts data using decrypted key and sends to the viewer. Afterwards decrypted key and data are trashed in server memory.

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. AES encryption key is generated by the agent process and encrypted with configured RSA public key.

Encrypted sensitive data and encrypted AES encryption key is sent to server.

Server writes encrypted data alongside encrypted data encryption key to disk.

Viewer of encrypted data provides private key for decryption.

Server reads encrypted data and encrypted encryption key from disk. Server decodes data encryption key using provided private key. Decrypted key is stored in memory only. Server decrypts data using decrypted key and sends to the viewer. Afterwards decrypted key and data are trashed in server memory.

Viewer of encrypted data provides private key for decryption.

Viewer of encrypted data provides private key for decryption.

Viewer of encrypted data provides private key for decryption.

Viewer of encrypted data provides private key for decryption.

Viewer of encrypted data provides private key for decryption.

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

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

• 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’);

• Server restart is required after configuration changes.

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

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.