Supported Cryptographic Algorithms, Protocols, and Standards

This section lists the cryptographic algorithms and standards used by the different functions of Key Manager.

The following table lists the SSH and TLS algorithms used by Key Manager:

Table 3.3. PrivX Key Manager SSH algorithms

Used for	SSH Algorithm	TLS Algorithm
Key exchange	Hybrid Streamlined NTRU + Elliptic Curve Diffie-Hellman (quantum-safe, OpenSSH extension)	Elliptic Curve Diffie-Hellman / Diffie-Hellman
	Elliptic Curve Diffie-Hellman	Diffie-Hellman
	Diffie-Hellman
Connection encryption	ChaCha20-Poly1305	AES (128-, 192- or 256-bit key)
	AES (128-, 192- or 256-bit key)
Data integrity	UMAC-64, UMAC-128	HMAC-SHA2-256, HMAC-SHA2-512, HMAC-SHA1
	HMAC-SHA2-256, HMAC-SHA2-512	HMAC-SHA1
	HMAC-SHA1

The Administrative Interface

Communication between the Key Manager front end(s) and the administrator's web browser is protected by SSL/TLS. The Key Manager front end has an X.509 certificate for securing administrative-interface connections against man-in-the-middle attacks. The private key(s) corresponding to the certificate(s) are stored on the front ends.

The administrators are authenticated with username/password through HTTPS - The passwords are stored (encrypted) in the Management Database.

Management Connection

Management connections between managed hosts and the Key Manager back ends are protected using SSH. The exact details of each type of management connection are given below.

Agent-Based Management Connections

To manage hosts using agent-based connections, the managed host must have a Key Manager agent installed. The agent includes a secure-shell component for connecting to the management server. The managed host does not have to be installed with an SSH server, and does not have to be listening to any port. The Key Manager agent does not listen to any port either. Instead, the agent periodically connects to a Key Manager back end. When a host is taken under management, Key Manager’s public host key is copied to the managed host and validated whenever the managed host connects to Key Manager, to ensure that it has connected to the intended Key Manager server, and to prevent man-in-the-middle attacks. The managed host also creates a new private key for authenticating itself to Key Manager, and sends the public key to Key Manager. Key Manager configures its SSH server to accept this key for authenticating the managed host; however, the key cannot be used for anything else on the Key Manager than running a servant process that receives information from the managed host, and enables key management actions to be performed.

Agentless Management Connections

When using agentless connections, Key Manager relies on having an SSH server (OpenSSH or Tectia SSH) installed and running on the agentless hosts. Normally the SSH server would be listening to port 22. Additionally, firewalls in the network must allow the Key Manager Server to access port 22 on the agentless hosts.

When a host is taken under management, its public host key is copied to the Key Manager system so that Key Manager can verify that it has connected to the intended host (this prevents a man-in-the-middle attack on the connection). Key Manager also generates a passphrase-protected private key for the target host, and installs the corresponding public key on it as an authorized key. Key Manager uses this public key to discover and manage keys on the managed host. The generated private key is stored in the Key Manager Database in an encrypted fashion.

Management Database

Communication between the Key Manager front end(s)/Key Manager back end(s) and the SQL database uses the native (PostgreSQL or Oracle) interface on the front end and the back end, and is protected by a database-specific mechanism. Each database system provides proprietary mechanisms (typically SSL/ TLS) for ensuring that only the Key Manager servers can access the database, and for encrypting database connections. If required, IPSec protection (using a pre-shared secret in IKE) can be configured between the Key Manager computers and the database. No individual should have access to the database, with the exception of the Key Manager system itself. However, backups of the database should be taken regularly to enable recovery in situations where the database is lost (for example, due to a catastrophic system failure). The database system implements crash recovery, replication, and distribution using database specific mechanisms. The Key Manager assumes that the database itself is secure (private keys on the hosts under management are never sent to the Key Manager and are not stored in the database).

Information stored in the management database is encrypted with a random key generated during the initial configuration of Key Manager. The used encryption algorithm is AES-CBC.