About Remote PED
A Remote PED connection allows you to access PED-authenticated HSMs that are kept in a secure data center or other remote location where physical access is restricted or inconvenient. This section provides descriptions of the following aspects of Remote PED connections:
>PEDserver-PEDclient Communications
Remote PED Architecture
The Remote PED architecture consists of the following components:
>Remote PED: a Luna PED with firmware 2.7.1 or newer, connected to a network-connected workstation, powered on, and set to Remote PED mode.
>Remote PED Vector (RPV): a randomly generated, encrypted value used to authenticate between a Remote PED (via PEDserver) and a SafeNet Luna HSM (via PEDclient).
>Remote PED Key (RPK): an orange PED key containing an RPV (or multiple PED keys with a split RPV in an M of N implementation).
>PEDserver: software that runs on the remote workstation with a USB-connected Luna PED. PEDserver accepts requests from and serves PED actions and data to PEDclient.
>PEDclient: software that requests remote PED services from PEDserver. PEDclient runs on the network-connected system hosting the HSM, which can be one of the following:
•SafeNet Luna Network HSM
•Host computer with SafeNet Luna PCIe HSM installed
•Host computer with USB-connected SafeNet Luna Backup HSM, configured for remote backup
Remote PED Connections
A SafeNet Luna PCIe HSM
>PEDServer is running
>a SafeNet Luna PED with firmware version 2.7.1 or newer is connected
>The orange PED key containing the Remote PED Vector (RPV) for that HSM is available
Priority and Lockout
If a Local PED connection is active and an operation is in progress, a Remote PED connection cannot be initiated until the active Local PED operation is completed. If the Local PED operation takes too long, the Remote PED command may time out.
When a Remote PED connection is active, the Local PED connection is ignored, and all authentication requests are routed to the Remote PED. Attempts to connect to a different Remote PED server are refused until the current connection times out or is deliberately ended. See Ending or Switching the Remote PED Connection.
One Connection at a Time
Remote PED can provide PED services to only one HSM at a time. To provide PED service to another HSM, you must first end the original Remote PED connection. See Ending or Switching the Remote PED Connection.
Timeout
PEDserver and PEDclient both have configurable timeout settings (default: 1800 seconds). See pedserver mode config or pedclient mode config. The utilities are not aware of each other's timeout values, so the briefer value determines the actual timeout duration.
Once a partition has been Activated and cached the primary authentication (PED key) credential, the Crypto Officer or Crypto User can log in using only the secondary (alphanumeric) credentials and the Remote PED connection can be safely ended until the Partition SO needs to log in again.
Broken Connections
A Remote PED connection is broken if any of the following events occur:
>The connection is deliberately ended by the user
>The connection times out (default: 1800 seconds)
>SafeNet Luna PED is physically disconnected from its host
>VPN or network connection is disrupted
>You exit Remote PED mode on the Luna PED. If you attempt to change menus, the PED warns:
If the link is broken, as long as the network connection is intact (or is resumed), you can restart PEDserver on the Remote PED host and run ped connect in LunaCM to re-establish the Remote PED link. In a stable network situation, the link will remain available until timeout.
PEDserver-PEDclient Communications
All communication between the Remote PED and the HSM is transmitted within an AES-256 encrypted channel, using session keys based on secrets shared out-of-band. This is considered a very secure query/response mechanism. The authentication conversation is between the HSM and the PED. Authentication data retrieved from the PED keys never exists unencrypted outside of the PED or the HSM. PEDclient and PEDserver provide the communication pathway between the PED and the HSM, and the data remains encrypted along that path.
Once the PED and HSM are communicating, they establish a common Data Encryption Key (DEK). DEK establishment is based on the Diffie-Hellman key establishment algorithm and a Remote PED Vector (RPV), shared between the HSM and the PED via the orange Remote PED Key (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 are different and communication is blocked.
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 in 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.
