About Remote PED

A Remote PED connection allows you to access multifactor quorum-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:

>Remote PED Architecture

>Remote PED Connections

>Secure Communication Between the Remote PED and Luna PCIe HSM 7s With Firmware 7.7.0 and Newer

>Initializing the Remote PED Vector and Creating an Orange Remote PED key

>Installing PEDserver and Setting Up the Remote Luna PED

>Opening a Remote PED Connection

>Ending or Switching the Remote PED Connection

>Configuring PED Timeout Settings

>Remote PED Troubleshooting

Remote PED Architecture

The Remote PED architecture consists of the following components:

>Remote PED: a Luna PED with Luna PED Firmware 2.7.1, 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 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 quorum 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:

•Host computer with USB-connected Luna Backup HSM, configured for remote backup

•Host computer with Luna PCIe HSM 7 installed

•Luna Network HSM 7

•Host computer with Luna USB HSM 7 connected

Remote PED Connections

A Luna PCIe HSM 7 on a host computer running PEDclient can establish a Remote PED connection with any workstation that meets the following criteria:

>PEDServer is running

>a Luna PED with Luna PED Firmware 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

Remote PED connections have configurable timeout settings. For more information, refer to Configuring PED Timeout Settings.

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)

>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.

Secure Communication Between the Remote PED and Luna PCIe HSM 7s With Firmware 7.7.0 and Newer

Communication between the Remote PED and Luna PCIe HSM 7 is kept secure before and after RPV initialization.

Secure Communication Before RPV Initialization

Before the RPV is initialized, data exchanged between the Remote PED and Luna PCIe HSM 7 is protected using the same method that is used to secure communication between a Local PED and Luna PCIe HSM 7 (see Secure Communication Between the Local PED and Luna PCIe HSM 7s With Firmware 7.7.0 and Newer). However, the SHA-512 based single-step key derivation function defined in NIST Special Publication 800-56C Revision 1 is used to derive the CWKs from the shared secret, with a password used instead of an RPV.

After the RPV is initialized, the Luna PCIe HSM 7 and Remote PED re-establish a full secure channel. For more information, see the section below.

Secure Communication After RPV Initialization

After the RPV is initialized, all communication between the Remote PED and the Luna PCIe HSM 7 is transmitted within a secure channel that is protected using an AES-256-CTR data encryption key (DEK) and a SHA-512-HMAC data MAC key (DMK). CSPs transmitted within the secure channel are additionally encrypted using an AES-256-KWP CSP wrapping key (CWK). The secure channel is established using the Full Unified C(2e, 2s ECDH CDH) key agreement scheme with bilateral key confirmation, as defined in NIST Special Publication 800-56A Revision 3. The key agreement scheme requires each party to use a static ECDH key pair and an ephemeral ECDH key pair. The key pairs are generated in the following ways:

>The HSM generates its own static P-521 ECDH key on startup. During RPV initialization, the HSM generates a static P-521 ECDH key and loads it onto the RPK along with the RPV (or RPV split is MofN is used). Both static keys are assigned certificates which chains back to the HSM’s ECC HOC.

>During the key agreement, the Luna PCIe HSM 7 and Remote PED both generate their ephemeral P-521 ECDH key pair.

As part of the key agreement, the SHA-512 based single-step key derivation function defined in NIST Special Publication 800-56C Revision 1 is used to combine the shared secret, the RPV, and the derived the secure channel protection keys; that is, the DEK, DMK, and CWK. The derivation function derives separate keys (DEK, DMK, and CWK) for HSM-to-Remote PED and Remote PED-to-HSM communication.

The RPV ensures mutual authentication of both end points and the HSM’s static ECDH key ensures additional authentication of the HSM.

Secure Communication Between the Remote PED and Luna PCIe HSM 7s With Firmware 7.4.2 and Older

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 Luna 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.