Install a Hardware Security Module in SWG

Cluster distributed HSM

Cluster distributed HSM support was added in version 7.5.0. Using Cluster distributed HSM allows a SWG share the HSM capabilities with other SWGs. This is beneficial when limited HSM PCI cards are available.

Deployment

The HSM must be installed into at least one appliance. Once deployed into an appliance it is possible to configure cluster distributed HSM. Using cluster distributed HSM makes it easy to share the capabilities an HSM and also configure for failover when more than one appliance has an HSM installed/connected.

Administrator and Operator Cards

Use of the HSM is governed by Administrator and Operator cards, these are smart cards that can be inserted into the smart card reader to perform certain tasks.

Supported Web Gateway Models

• 5000A and 5500A (Dell based)
• 5000B, 5500B, 5000C, 5500C, 5000D, and 5500D (Intel based)

Supported HSM cards and Network HSM

• Thales nShield Solo 6000+ module
• Thales (formerly nCipher) nShield 500e F3 or compatible (legacy)
• Thales nShield Connect (support added in 7.7.1)
• SafeNet Network HSM formerly Luna SA, now owned by Gemalto (support added in 7.7.0)

Physical Installation

Installation of the HSM card into the Web Gateway is fairly straight forward. We will walk through the installation on a WG5000C.

Create the HSM Security World key (only for initial setup)

Security Worlds are used to identify one or more modules that belong to the same group of HSMs and can share the same kind of configuration. You can create a new Security World or transfer an existing one. If you use multiple HSMs in your environment you will most likely just create one Security World and use it on all of your HSMs.

/opt/nfast/bin/nopclearfail –c –a

# Example output:

/opt/nfast/bin/nopclearfail -c -a

Module 1, command ClearUnit: OK  

# For just module 1 mode output:

/opt/nfast/bin/enquiry -m1|grep mode

# For module 1 output:

/opt/nfast/bin/enquiry -m1

# For full output

/opt/nfast/bin/enquiry  

/opt/nfast/bin/new-world –i –Q x/y

/opt/nfast/bin/nopclearfail –c –a

# For just module 1 mode output:

/opt/nfast/bin/enquiry -m1|grep mode

# For module 1 output:

/opt/nfast/bin/enquiry -m1

# For full output

/opt/nfast/bin/enquiry

Create Operator Card Set (OCS)

Operator Card sets are used to protect your private keys and encrypt them in the HSM. You can create new Operator Card sets or transfer existing ones to use them on multiple HSMs. If you use multiple HSMs in your environment you will most likley just create one Operator Card set and use it on all of your HSMs.

After this you are able to create the Operator Card Set. Operator cards are necessary for the creation of the needed keys in the correct way. You create the card set by entering the command:

/opt/nfast/bin/createocs –m1 –Q x/y –N <name>

• m1 stands for the module, you want to create (module 1)
• Q x/y has the same meaning for operator cards as described above for the administrator cards. (Q 1/2 or Q 1/1 …)
• -N <name> identifies the name of the card set

During this process, you are asked to insert the appropriate card(s), that shall be created. You cannot use an old operator card, you have to use empty cards. You also have to enter a for each Operator card used.

Create HSM protected private keys

After creating the operator card set, you must create or import private keys to be protected by the HSM. In Web Gateway there are three keys that can be used by your policy:

1. SSL Scanning CA key
2. SSL Scanning Domain key
3. Reverse proxy server key
4. Client certificate key

In the examples below we will create the key for SSL Scanning purposes for these purposes.

/opt/nfast/bin/generatekey -g hwcrhk

[root@swg1-hsm-server ~]# /opt/nfast/bin/generatekey -g hwcrhk

type: Key type? (RSA, DSA, DH) [RSA] > RSA

size: Key size? (bits, minimum 1024) [1024] > 2048

OPTIONAL: pubexp: Public exponent for RSA key (hex)? []

>

ident: Key identifier? [] > sslscannerca

nvram: Blob in NVRAM (needs ACS)? (yes/no) [no] >

key generation parameters:

operation       Operation to perform        generate

application     Application                 hwcrhk

verify          Verify security of key      yes

type            Key type                    RSA

size            Key size                    2048

pubexp          Public exponent for RSA key (hex)

ident           Key identifier              sslscannerca

nvram           Blob in NVRAM (needs ACS)   no

Key successfully generated.

Path to key: /opt/nfast/kmdata/local/key_hwcrhk_rsa-sslscannerca [root@swg1-hsm-server ~]#

/opt/nfast/bin/generatekey -i hwcrhk

 /opt/nfast/bin/nfkminfo -l

Keys with module protection: key_hwcrhk_rsa-sslscannerca

Create a Certificate Signing Request (CSR)

This step can be skipped if you imported a private key from an existing certificate/key pair.

If you created a new private key within the HSM Security World, we will need to generate a CSR to obtain a signed certificate. To generate a CSR using one of the newly protected keys use the below command, replacing your key identifier:

openssl req -engine chil -keyform engine -new -sha256 -key KEYIDENTIFIER -out FILENAME.csr

Example:

openssl req -engine chil -keyform engine -new -sha256 -key sslscannerca -out sslscannerca.csr

You can then download the CSR file (in the example sslscannerca.csr) and have it signed by your internal or external authority (in the case of a reverse proxy certificate).

Loading the private key identifiers in Web Gateway UI

In order for the Web Gateway to use the keys within the HSM's Security World, we must enumerate the available keys in the UI.

1. Navigate to Configuration > Hardware Security Module and add all of the key identifiers in the "Keys to be loaded":
   
2. Additional steps to perform for passphrase or multicard-OCS-protected private keys after configuring SWG -UI. Execute the command on the shell (e.g. via SSH):

/opt/swg/bin/hsmagent -c

The command requests the secrets required to load specially-protected private keys. It has to be executed after each upgrade and reboot.

The console will then guide/ask the administrator for each declared identifier to enter the passphrases or insert required smartcards of the OCS (Operator-Card-Set) into the HSM.

Additionally the customer can inspect the following log file to see if there are any unexpected errors:

• Troubleshooting > [Appliance name] > Log Files, then open swg-errors and view the hsmagent.errors.log
• Or from the appliance command line at: /opt/swg/log/swgerrors/hsmagent.errors.log

Use private keys in Web Gateway Policy

Now that the keys are protected by the HSM, and loaded in the Web Gateway, we need to put the keys to use.

Concept

Each SWG comes with a HSM agent (piece of software) that can be enabled. The agents communicate with each other using certificates.

For this scenario, I'm going to refer to the SWG with the HSM = SWG-HSM-SERVER. The SWG without the HSM = SWG-HSM-CLIENT.

HSM server listener

On the SWG-HSM-SERVER navigate to Configuration > Hardware Security Module, then check the box for "Allow remote connections" and define a local listener port. The default is 33808, this just means SWG-HSM-SERVER will be listening on that port for remote HSM related traffic (secured by TLS and client cert auth).

HSM server identification

Again under Configuration > Hardware Security Module, scroll down to "Server Identification" and expand that section. Once expanded click the Generate... button. Populate the "Generate Server Certificate" form fields with your organization's details. Do not leave the defaults. Once you have created your own certificate, SWG-HSM-SERVER will now present this certificate to any HSM clients (like SWG-HSM-CLIENT).

Export the certificate (Export... button) and the key (Export Key...) button. Later, we will need to install the server certificate on SWG-HSM-CLIENT.

HSM client identification

On SWG-HSM-CLIENT, navigate to Configuration > Hardware Security Module. Scroll down to the HSM Client section and check the box for "Use remote HSM server" and expand the "Client identification" section. If you wish to have a unique certificate per node, click Generate. If you are going to use a shared certificate, click Import and select the certificate and key from the Server identification export (mentioned above).

HSM client-server two-way trust

Now that the client and server identification are configured we need to configure the bullet points below (it sounds tougher than it is). This is just a matter of specifying IPs/ports and importing certificates.

• Configure client (SWG-HSM-CLIENT) to talk to server (SWG-HSM-SERVER)
• Configure client to trust server certificate
• Configure server to trust the client certificate

To configure the client to the server communication we go back to SWG-HSM-CLIENT under the Configuration > Hardware Security Module > HSM Client section and click the + icon and type the IP of the On SWG-HSM-SERVER as well as the port. Import the HSM server certificate that we exported earlier. SWG-HSM-SERVER is 10.10.65.61. I used the shared certificate for demonstration.

Now the SWG-HSM-CLIENT knows to trust the HSM server's certificate.

To configure the server to trust the client we go to SWG-HSM-SERVER under Configuration > Hardware Security Module. Scroll down to Permitted clients under HSM Server. Click the Add button and type the IP of SWG-HSM-CLIENT and import the certificate that was shared or that is unique.

Now that the server knows the client IP and the client knows the server information, the trust relationship is established and cluster distributed HSM should be ready to go.