The PED client and server are software components that allow the HSM and PED to communicate via a TCP/IP network. The PED Client in the Luna appliance requests PED services from the PED Server through the network connection.
Once communicating (i.e., the data path is established), the PED and HSM establish a common Data Encryption Key (DEK) , which is used for PED protocol data encryption thereafter, 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.