Secure communication is central to today’s web applications. Communication is secured by encrypting the data that flows over the network. To ensure adequate performance, encryption and decryption operations are done using the same key. This is called symmetric key encryption.
In symmetric key encryption, the client and server must agree on a symmetric key that cannot be exchanged in plaintext over the network. Key exchange or key agreement algorithms are used to achieve this; the prominent ones being RSA, ECDSA and Diffie Hellman (DH).
Authentication is another aspect of secure communication. It is a way to establish trust. How does a communication endpoint know if the other end is what it really says it is? For this every endpoint that wishes to be identified publicly, gets a certificate signed by a trusted third party. This signed certificate is used to establish its identity.
Public key cryptography is used for authentication and to agree on the shared secret - the symmetric encryption key. Public key cryptography, also referred to as asymmetric cryptography, involves a key pair, where the public key is be shared with everyone and the private key is only known to the owner. A message encrypted using one key can be only decrypted by another key from the same pair. Public key cryptography also forms the basis for authentication where an endpoint establishes its identity by signing a message using their private key.
Public/Private key pair can either be provided by RSA or ECDSA. So both of them can be used for authentication and key exchange. DH can also be used for key exchange and is more efficient and secure, but DH without authentication is susceptible to man-in-the-middle attacks. To avoid this, DH is used with authentication provided by RSA or ECDSA.
In the diagram below, we show RSA key exchange and one variant of DH exchange that authenticates the identity of the server. the identity of the client can be authenticated as well. However, only server-side authentication is shown to describe the use of private key used by the server that wants to be authenticated. Let us first see how the operations are carried out in absence of an external key store device (Hardware Security Module). The important thing to note here is that the server has the private key with itself which it uses to perform the crypto operations (both for RSA and DH exchange).
Hardware Security Modules (HSM) are devices used to safely store and manage cryptographic keys. When the HSM client communicates with the device, it provides support for cryptographic operations to be performed using these keys. The key benefit of HSMs is the ability to provide both logical and physical protection of digital keys. Highly regulated industries and organizations with a greater need for security typically deploy these keys. We now illustrate how SSL handshake looks in presence of HSM. Note that crypto operations required to support the handshake - i.e. signing using the private key and decryption of session key are performed on the HSM. This is because only the HSM has the private key to perform these operations. In presence of a HSM, private keys do not leave the HSM boundary.
Clients that wish to communicate with the HSM have to install the software provided by the HSM vendor. Additionally there are steps that are performed to authenticate a client and establish a secure channel with the HSM device. Load balancers are examples of such clients. Avi Controller and Avi Service engines are examples of such clients in this article.
Traditional load balancers, like F5 and Citrix NetScaler, are monolithic hardware boxes that need expensive hardware to scale. This is especially easy to visiualize when you compare Avi Networks against both hardware load balancers. HSM software is installed on these boxes. If additional boxes are added, they also have to be configured again. A hardware refresh can probably import the configuration from old boxes but would still need re-installation of HSM software.
Avi’s distributed architecture solves this problem with horizontal scaling that adheres to the “configure only once” paradigm. Avi Vantage’s software-defined architecture uses a single pane of control for all management operations; the Avi Controller implements this central point of control and runs in a cluster to provide fault tolerance. The data path is implemented using the Avi Service Engines (SEs) which are ephemeral entities created dynamically to serve traffic. They do not store any configuration and are programmed by the controller during creation and during their lifetime.
On the Avi platform, HSM software installation and group configuration happens only once on the Controller which is propagated to Service Engines.
Keys and certificate creation on the Controller is HSM-agnostic. This is possible since (1) In the Avi solution, the controller is established as a client to HSM and can communicate with it (2) and the controller can execute HSM-specific commands applicable to that HSM provider for key and certificate creation. A consistent interface to manage SSL keys/certificates simplifies the job of administrator, since they do not have to rely on HSM specific utilities provided by HSM vendors. A single uniform REST API can create or delete a key/certificate which are local either on the controller or live on the HSM. This makes scripting and automating such tasks trivial.
Let us now focus on Avi's integration with HSMs:
- We install HSM software on Avi Controller and configure HSM settings on it. This software and configuration is then propagated to Avi Service Engines automatically.
- Create HSM bound keys and certificates using the Controller REST/UI
- Configure Virtual Services on Controller.
- Attach HSM bound key/certificates on Virtual Services.
- Service Engines learn about Virtual Services and associated key/certificates from controller.
- Service Engines serve traffic on the newly created Virtual Services.
- For Virtual Services that have HSM bound key/certificates installed, the Service Engine communicates with the appropriate HSM to perform crypto operations
The diagram below represents these operations pictorially. Note the grouping of service engines to help better manage them. We refer to such group as a Service Engine Group - a logical group of Service Engines that can be configured as one logical entity. Similarly HSM are grouped to form a logical entity called HSM group. We show typical deployments where more than one HSM pair to form a HA group. HSM-G1-1 and HSM-G2-2 form one HSM-HA pair HSM-G1. Similarly HSM-G2-1 and HSM-G2-2 form another HA pair HSM-G2.
The grouping and central control of such groups simplifies configuration. All this can also be automated using the Avi SDK that uses REST services provided by the controller.
One unique capability that Avi solution provides is the ability to configure multiple HSM groups from the same device. Such deployments are common in multi-tenancy environments.
As additional applications/Virtual Services are added, they can be secured using HSM bound key/certificates without any additional configuration. These HSM bound key/certificates are installed and managed just like regular non-HSM SSL objects.
HSMs are an integral part of security-focused deployments. We at Avi are committed to delivering security while simplifying operational challenges presented by such security-first deployments. Avi’s solution simplifies HSM integration by providing automation, ease of use and scalability; the core principles on which it was founded.
