Skip to main content
All CollectionsUsage & Deployment GuidesOn-Premise Deployment Guide
On-Premise Datasheet
On-Premise Datasheet
A
Written by Arick Disilva
Updated over 6 months ago

Deployment Options

Deployment without Application Servers

Deployment with Application Servers

Deployment with Separate Application, Database and BI Servers

deployment_with_separate_app-bi-db.png

High Availability (HA)

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

deployment_with_high_availability.png

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

Communications Protocol & Cypher

1

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)

2

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

3

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)

4

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

5

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.

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 connection on even ports in range 10000 - 11000, 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.

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

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

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

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

4

Viewer of encrypted data provides private key for decryption.

5

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.

Data Flow

1

The agent reads the RSA public key used for Key Encryption Key (KEK) from 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

AES data encryption key (DEK) is encrypted (wrapped) using RSA encryption key (KEK).

4

Data is encrypted with AES key (DEK).

5

Encrypted data and wrapped DEK are transferred to the server. Since the DEK is encrypted (wrapped), server cannot decrypt the data.

6

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 corresponding KEK private part.

8

When passphrase is provided, 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 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.

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

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

end-to-end_encryption-OCR.png

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

Related Articles
What type of encryption do you use for data at rest and data in motion?
How secure is the data Teramind collects and stores in the cloud?
On-Premise Deployment Guide
How to check if Teramind IP addresses/hosts and ports are reachable
What is End-to-End Encryption (E2EE) and how to use it (On-Premise)
Did this answer your question?