User flows

This section explains user actions to accomplish various tasks and how the TR-34 services are used in context of the protocol. There are two scenarios:
  1. Peer-to-peer exchange where two parties use the protocol to establish a common transport key to exchange symmetric keys securely. In the peer-to-peer scenario, one party is the KDH (Key Distribution Host) and the other party is the KRD (Key Receiving Device).
  2. One KDH (Key Distribution Host) to many KRDs (Key Receiving Device) where the host uses the protocol to establish a transport key for distributing symmetric keys with each of the receiving devices in service.

Parameters used in the protocol

The following are descriptions of some of the common parameters in the TR-34 protocol. They are credentials, certificates, TR-34 tokens, and CCA key tokens.
CSR-KDH
PKCS #10 certificate signing request for KDH.
CSR-KRD
PKCS #10 certificate signing request for KRD.
CredKDH
KDH credential (X.509 certificate) with ID and public key.
CredKRD
KRD credential (X.509 certificate) needed for key distribution.
CredCA
Certificate Authority credential.
CRL-CA
Certificate Revocation List from CA.
CT-KDH
KDH credential token, KDH bind token.
RBT-KDH
KDH rebind token.
UBT-KDH
KDH unbind token.
CT-KRD
KRD credential token, containing CredKRD.
RT-KRD
Random number token, generated by KRD.
KT-KDH
KDH key token – 1 or 2 pass.
D-kdh-T
CCA RSA private key token for KDH, contains the private key (D-kdh) and public key (E-kdh).
D-krd-T
CCA RSA private key token for KRD, contains the private key (D-krd) and public key (E-krd).
Kn
Key to be exported using TR-34.
Kn-T
CCA key token.
Note: These scenarios assume that the KDH and KRD are using IBM CCA services and servers for the TR-34 setup and applications. When CCA services are not being used, other appropriate cryptographic services should be substituted and used. The same situation applies to hardware and key storage.

Setup

These are the setup steps at each party: the Key Receiving Device (KRD) and the Key Distribution Host (KDH).

On the KDH (Key Distribution Host)
  1. Create the KDH administrative RSA key pair for TR-34 use with target (or set of targets):
    • Overview: Generate RSA private key token (D-kdh-T).
    • Use CCA service: CSNDPKG
      INPUT:
      Key strength and type (RSA 2048, SIGN-ONLY).
      OUTPUT:
      The private key (D-kdh-T) token contains the private key (D-kdh) and the public key (E-kdh).
      KEY STORAGE:
      Store the output private key token (D-kdh-T) in the PKDS.
  2. Create PKCS #10 certificate signing request for the public key of the administrative key pair:
    • Overview: Extract public key E-kdh into PKCS #10 certificate signing request (CSR-KDH).
    • Use CCA service: CSNDPIC
      INPUT:
      Private key token (D-kdh-T).
      OUTPUT:
      PKCS #10 certificate signing request (CSR-KDH).
      KEY STORAGE:
      Store the signing request (CSR-KDH) in the application space or key ring until the certificate can be generated.
      Note: The signing request (CSR-KDH) is an intermediate object, but might be useful to have stored if the same private key is to be used with multiple ATM vendors or as a backup. It is recommended to have a unique private key for each group of receiving devices.
  3. Create the KDH credential (CredKDH) from the certificate signing request (CSR-KDH):
    • Overview: KDH sends the CSR-KDH to a Certificate Authority (CA) trusted by all parties to be turned into a certificate CredKDH under the agreed CA.
      • Application step or manual step such as loading the (CSR-KDH) to a web portal.
    • KDH receives from the CA the following TR-34 objects:
      CredKDH
      Certificate holding (E-kdh). Store certificate for use with all devices during BIND.
      KEY STORAGE
      Store the (CredKDH) in application space or key ring.
      CRL-CA
      Current Certificate Revocation List. Store for use until not considered fresh any longer.
      KEY STORAGE
      Store the (CRL-CA) in application space or key ring.
      CredCA
      A certificate for CA. Install this in the CCA HSM PKI manually from the TKE workstation for each domain that will perform the TR-34 protocol. Also keep this available for new HSM provisioning.
      KEY STORAGE
      Store the (CredCA) in application space or key ring.
  4. At the TKE workstation: Install the CA credential (CredCA) to the HSM domains that will perform TR-34 operations.
    • Overview: The KDH administrator saves the CredCA in the internal PKI of the appropriate domains of the HSM as a trust root, using the TKE workstation.
On the KRD (Key Receiving Device)
  1. Create the RSA key pair for TR-34 key management use. Each KRD will have an RSA key pair.
    • Overview: Generate RSA private key token (D-kdh-T).
      • For peer-to-peer exchange, use CCA service: CSNDPKG.
        INPUT:
        Key strength and type (RSA 2048, KEY-MGT).
        OUTPUT:
        The private key (D-krd-T) token contains the private key (D-krd) and the public key (E-krd).
        KEY STORAGE:
        Store the output private key token (D-krd-T) in the PKDS.
      • For one host to many devices, typically the RSA key is generated and installed in the device at the factory.
        • The private key (D-krd) is installed on the device.
  2. Create PKCS #10 certificate signing request for the public key E-krd:
    • Overview: Extract public key E-kdh into PKCS #10 certificate signing request (CSR-KRD).
      • For peer-to-peer exchange, use CCA service: CSNDPIC.
        INPUT:
        Private key token (D-krd-T).
        OUTPUT:
        PKCS #10 certificate signing request (CSR-KRD).
        KEY STORAGE:
        Store the signing request (CSR-KRD) in application space or key ring until the certificate can be generated.
      • For one host to many devices, generate the CSR-KRD for each device with the devices public key E-krd.
  3. Create the KRD credential (CredKRD) from the certificate signing request (CSR-KRD):
    • Overview: KRD sends the CSR-KRD to a Certificate Authority (CA) trusted by all parties to be turned into a certificate CredKRD under the agreed CA.
      • Application step or manual step such as loading the (CSR-KRD) to a web portal.
    • KRD receives from the CA the following TR-34 objects:
      CredKRD
      Certificate holding (E-kdh). Store certificate for use to BIND with the KDH.
      KEY STORAGE
      • Peer-to-peer exchange: Store the (CredKRD) in application space or key ring.
      • One host to many devices: Typically, installed on device at the factory.
      CRL-CA
      Current Certificate Revocation List. Store for use until not considered fresh any longer.
      KEY STORAGE
      Store the (CRL-CA) in application space or key ring.
      CredCA
      A certificate for CA. Install this in the KRD.
      KEY STORAGE
      • Peer-to-peer exchange: Store the (CredKRD) in application space or key ring.
      • One host to many devices: Typically, installed on device at the factory.
  4. Install the KRD credential holding the KRD public key (CredKRD):
    • For one host to many devices: This is typically installed on device at the factory.
    • For peer-to-peer exchange: The CredKRD might be stored in application space for the TR-34 implementation.
      KEY STORAGE
      • Store the (CredCA, CredKRD) in application space or key ring.
      • Store the KRD private key token (D-krd-T) in the PKDS.
  5. Install the CA credential (CredCA) (primary, secondary, ‘higher’ primary/secondary, and so on):
    • Peer-to-peer exchange: The CredCA is installed in the CCA HSM PKI manually from the TKE workstation, for each domain that will use the TR-34 protocol. Also, keep the CredCA available for new HSM provisioning.
    • One host to many devices: This is typically installed on the device at the factory.