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 token (D-kdh-T) 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.