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:

>Remote PED Architecture

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

NOTE Luna PED firmware versions

•2.7.4 for PEDs that require the external power block, and

•2.9.0 for USB-powered PEDs

are required for the enhanced connection security and NIST SP 800-131A Rev.1 compliance implemented with Luna HSM 7.7.0 and newer.

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

•Luna Network HSM

•Host computer with Luna PCIe HSM installed

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

Remote PED Connections

A Luna Network HSM can establish a Remote PED connection with any workstation that meets the following criteria:

>PEDServer is running

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

Bi-directionality

There are two methods of establishing a Remote PED connection to the HSM:

>HSM-initiated: When the HSM requires authentication, it sends (via PEDclient) a request for PED services to the Remote PED host (which receives the request via PEDserver). This requires that the Luna Network HSM be allowed to initiate external connections, and that the PEDserver IP port remains open. If the Luna Network HSM resides behind a firewall with rules prohibiting these connections, or if your IT policy prohibits opening a port on the Remote PED host, use a PED-initiated connection. See HSM-Initiated Remote PED.

>PED-initiated: The HSM and Remote PED host exchange and register certificates, creating a trusted connection. This allows the Remote PED host (via PEDserver) to initiate the connection to the Luna Network HSM. If you have firewall or other constraints that prevent your HSM from initiating a connection to a Remote PED in the external network, use this connection method. See PED-Initiated Remote PED.

The following constraints apply to PED-initiated connections:

>A maximum of 20 Remote PED servers can be registered in PEDclient.

>A maximum of 80 Network HSM appliances can be registered in PEDserver.

>If the connection is terminated abnormally (for example, a router switch died), there is no auto-reconnection. PEDserver automatically restarts and runs in HSM-initiated connection mode.

>When running in PED-initiated connection mode, PEDserver does not listen for new HSM-initiated connections, for security and to simplify usability.

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 hsm ped timeout. The utilities are not aware of each other's timeout values, so the briefer value determines the actual timeout duration. Timeout does not apply to PED-initiated Remote PED connections.

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 hsm ped connect in LunaSH or 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.

PEDServer Configuration File

PED-initiated Remote PED introduces a pedServer.ini/pedServer.conf file. The Appliances section manages registered appliances.

CAUTION! Do not edit the pedServer.ini/pedServer.conf file. If you have any issues, contact Thales Technical Support.

[Appliances]
ServerCAFile=C:\Program Files\SafeNet\LunaClient\cert\PedServerCAFile.pem
SSLConfigFile=C:\Program Files\SafeNet\LunaClient\openssl.cnf
ServerName00=myHSM
ServerIP00=192.20.11.78
ServerPort00=9697
CommonCertName00=66331
[RemotePed]
AdminPort=1502
BGProcessShutdownTimeoutSeconds=25
BGProcessStartupTimeoutSeconds=10
ExternalAdminIF=0
ExternalServerIF=1
IdleConnectionTimeoutSeconds=1800
InternalShutdownTimeoutSeconds=10
LogFileError=1
LogFileInfo=1
LogFileName=C:\Program Files\SafeNet\LunaClient\remotePedServerLog.log
LogFileTrace=0
LogFileWarning=1
MaxLogFileSize=4194304
PingInterval=1
PongTimeout=5
RpkSerialNumberQueryTimeout=15
ServerPortValue=1503
SocketReadRspTimeoutSeconds=60
SocketReadTimeoutSeconds=60
SocketWriteTimeoutSeconds=15

A new entry in the main Crystoki.ini/Chrystoki.conf file points to the location of the pedServer.ini/pedServer.conf file.

[Ped Server]
PedConfigFile = /usr/safenet/lunaclient/data/ped/config

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.