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:
- 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).
- 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)
- 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.
- 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.
- 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.
- 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.
- 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)
- 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.
- For peer-to-peer exchange, use CCA service: CSNDPKG.
- Overview: Generate RSA private key token (D-kdh-T).
- 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.
- For peer-to-peer exchange, use CCA service: CSNDPIC.
- Overview: Extract public key E-kdh into PKCS #10 certificate signing request (CSR-KRD).
- 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.
- 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.
- 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.
- 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.