|
Home > |
|---|
This supplemental information is provided to help you to satisfy security auditors and compliance queries, regarding the end-to-end security of your HSM contents and of authentication data.
The PED client and server are software components that allow the HSM and PED to communicate via a TCP/IP network.
The PED server resides on the host computer where a remote-capable SafeNet PED is USB connected. The PED server acts as an intermediary, accepting requests and serving PED prompts and actions and data to requesting HSMs (usually located at a distance from the Remote PED and its associated PED server).
The PED Client resides on the system hosting the HSM. That could be a workstation or server with a SafeNet USB HSM connected or a SafeNet PCIe HSM embedded, or it could be a SafeNet Network HSM appliance, any of which can request PED services from the PED Server through the network connection
Once the data path is established and the PED and HSM are communicating, they establish a common Data Encryption Key (DEK) which is used for PED protocol data encryption and authenticate each other as described below.
An authentication failure disconnects the parties.
DEK establishment is based on the Diffie-Hellman key establishment algorithm and an RPV (Remote PED Vector), shared between the HSM and the PED via the orange Remote PED iKey (RPK). Once a common Diffie-Hellman value is established between the parties via the Diffie-Hellman handshake, the RPV is mixed into the value to create a 256-bit AES DEK on each side. If the PED and the HSM do not hold the same RPV, the resulting DEKs will be different between them, and the parties won’t be able to talk. This property is used in providing mutual authentication of the PED and the HSM.
Mutual authentication is achieved by exchanging random nonces, encrypted using the derived data encryption key. The authentication scheme operates as follows:
| HSM | _ | Remote PED |
|---|---|---|
| Send 8 bytes random nonce, R1, encrypted using the derived encryption key. |
{R1 || padding}Ke -> | |
| <- {R2 || R1}Ke | Decrypt R1. Generate an 8 byte random nonce, R2. Concatenate R2 || R1 and encrypt the result using the derived encryption key. |
|
| Decrypt R2 || R1. Verify that received R1 value is the same as the originally generated value. Re-encrypt R2 and return it to Remote PED. |
{padding || R2}Ke -> | Verify that received R2 value is the same as the originally generated value. |
Following successful authentication, the random nonce values are used to initialize the feedback buffers needed to support AES-OFB mode encryption of the two communications streams (one for each direction).
Sensitive data in transition between a PED and an HSM is end-to-end encrypted: plaintext security-relevant data is never exposed beyond the HSM and the PED boundaries at any time. The sensitive data is also hashed, using a SHA-256 digest, to protect its integrity during transmission.