2-pass key transport

Edit online

This key transport typically installs a Terminal Master Key (TMK) at the Key Receiving Device (KRD). '2-pass' indicates that the KRD is expected to be online for the initial part of the protocol where a random number token is requested. If the KRD is expected to be offline, the '1-pass' protocol may be more appropriate.

Another name for the key is the TR-31 wrapping key name: Key Block Protection Key (KBPK). These represent the same key, a key-encrypting key (KEK), that is shared by the KDH and KRD so that more keys can be shared without going through the entire TR-34 protocol again. However, the type of key transported can be any type of key supported by the TR-31 key block that is carried in the TR-34 protocol token. For this flow, the assumption is that a typical KEK is being exchanged.

Setup steps for key transport

On KDH
  1. Refresh CRL-CA if needed:

    If CRL-CA held by the KDH, representing that the CA shared between the KRD and KDH is not fresh any longer, the KDH should obtain a new CRL-CA before doing the next step.

  2. Create TMK/KBPK: The KEK to be shared with the other party.

    CCA has restrictions on the type of key that can be used to wrap another key for TR-31 export (the CSNBT31X wrap_kek_identier). Therefore, one of these key types should be generated for exchange:

    DES:
    1. KDH-Wrapping-KEK:
      1. This is an known or random value EXPORTER KEK created using the TKE workstation or CSNBKPI.
      2. This key is used with CSNBKGN to create the KRD-Import-KEK, which must be generated in external form under a KEK according to CSNBKGN processing restrictions.
      3. KEY STORAGE: Stored in CCA key storage.
    2. KDH-Export-KEK:
      1. This is the KDH copy of the TMK key that will be used later to wrap keys being exported to the ATM.
      2. Type: DES EXPORTER key for wrapping output TR-31 key blocks.
      3. KEY STORAGE: Stored in CCA key storage.
    3. KRD-Import-KEK:
      1. This is the KRD copy of the TMK key that will be used later by the ATM to unwrap TR-31 key blocks for key distribution completion.
      2. Type: DES IMPORTER or IKEYXLAT key for unwrapping input TR-31 key blocks.
      3. This is the key (Kn) to be exported using TR-34. Because the key is in a CCA or TR-31 token, the notation (Kn-T) is used.
      4. KEY STORAGE: Stored in CCA key storage until export.
    4. CCA services:
      1. Use the CSNBKTB or CSNBT31C service to create skeleton tokens for the EXPORTER/IMPORTER copies of the key.
      2. Use the CSNBKGN or CSNBT31C service to generate a new DES key and populate to each token.
    AES:
    1. KDH-Wrapping-KEK:
      1. This is an known or random value EXPORTER KEK created using the TKE workstation or CSNBKPI2.
      2. This key is used with CSNBKGN2 to create the KRD Import KEK, which must be generated in external form under a KEK according to CSNBKGN2 processing restrictions.
      3. KEY STORAGE: Stored in CCA key storage.
    2. KDH-Export-KEK:
      1. This is the KDH copy of the TMK key that is used later to wrap keys being exported to the ATM.
      2. Type: AES EXPORTER key with usage EXPTT31D for wrapping output TR-31 key blocks.
      3. KEY STORAGE: Stored in CCA key storage.
    3. KRD-Import-KEK:
      1. This is the KRD copy of the TMK key that will be used later by the ATM to unwrap TR-31 key blocks for key distribution completion.
      2. Type: AES IMPORTER key with usage IMPTT31D for unwrapping input TR-31 key blocks.
      3. This is the key (Kn) to be exported using TR-34. Since the key is in a CCA or TR-31 token, the notation (Kn-T) is used.
      4. KEY STORAGE: Stored in CCA key storage until export.
    4. CCA services:
      1. Use the CSNBKTB2 or CSNBT31C service to create skeleton tokens for the EXPORTER/IMPORTER copies of the key.
      2. Use the CSNBKGN2 or CSNBT31C service to generate a new AES key and populate each token. Note that the key strength must be 128 bit if key strength rules are to be followed for PCI PTS HSM compliance and other standards. The maximum TR-34 wrapping key strength is AES 128-bit.

Protocol steps for key transport

  1. On KDH
    1. The KDH TR-34 application requests a random number from the KRD.
  2. On KRD
    1. KRD TR-34 application receives the random number request and processes it.
      1. Overview: Call CCA service CSNBRNGL using the keyword RT-KRD to create the TR-34 token that contains random number that is needed by the KDH.
      2. INPUT: RN-length: Length of the random number needed.
      3. OUTPUT: RT-KRD: Random number token.
        • KEY STORAGE: Stored in application space or key ring until the TR-34 Key Transport token (KT-KDH) is received that matches this RT-KRD random number.
    2. Send RT-KRD to KDH. Also, store RT-KRD locally in application space for a later validation step.
  3. On KDH
    1. Create the Key Transport token:
      1. Overview: Call CCA service CSNDT34D using keyword 2PASSCRE.
      2. INPUT:
        1. Kn-T: CCA or TR-31 key token to be exported to the KRD.

          KEY STORAGE: Stored in CCA key storage.

        2. RT-KRD: Key Receiving Device (KRD) Random Number Token (RT-KRD) received from KRD.

          KEY STORAGE: Stored in application space until this call happens.

        3. CRL-CA: Certificate Revocation List from CA.

          KEY STORAGE: Stored in application space or key ring.

        4. CredKRD: KRD credential with ID and public key. The public key from this is used to RSA-encipher the RSA-encrypted part of the key block.

          KEY STORAGE: Stored in application space or key ring.

        5. CredKDH: KDH credential with ID and public key.

          KEY STORAGE: Stored in application space or key ring.

        6. D-kdh: Private key to sign data block.

          KEY STORAGE: Stored in CCA key storage.

        7. KBH inputs: TR-31 KBH for a terminal master key is not actually variable, but a peer-to-peer exchange will have more inputs to describe keys.
      3. OUTPUT: KT-KDH: Key transport (2-pass) token.

        KEY STORAGE: Stored in application space until sent to KRD.

    2. KDH sends the KT-KDH token to the KRD.
  4. On KRD
    1. The KRD receives the KT-KDH token from the KDH and must process it to complete the Key Transport.
    2. Create key token to hold output TMK (CCA / peer-to-peer step).
      • Use CCA service CSNBKTB, CSNBKTB2, or CSNBT31C to create Kn-TS, a skeleton CCA or TR-31 key token appropriate for a importing the TMK/KBPK.
    3. Process the KT-KDH token received from the KDH.
      1. Overview: Call CCA service CSNDT34R using keyword 2PASSRCV.
      2. INPUT:
        1. KT-KDH: Key transport (2-pass) token received from KDH.
          • KEY STORAGE: Stored in application space until processed.
        2. CredKDH: KDH credential with ID and public key.
          • KEY STORAGE: Stored in application space or key ring.
        3. RT-KRD: Token originally sent by the KRD to the KDH and used now for validation.
          • KEY STORAGE: Stored in application space.
        4. D-krd: The private key matching the public key in CredKRD. D-krd is stored in the KRD (but not in the HSM). Used to RSA-decipher part of the KT-KDH key block.
          • KEY STORAGE: Stored in CCA key storage for peer-to-peer / CCA TR-34.
      3. OUTPUT:
        • Kn-T: CCA or TR-31 key token containing the transported TMK/KBPK.
          • KEY STORAGE: Stored in CCA key storage on KRD.
  5. On KRD
    1. key-check value generated and returned to KDH.
      • The KRD generates a key-check value (KCV) for Kn-T using CCA service CSNBKYT2 using keywords GENERATE and ENC-ZERO or CMACZERO depending on the key algorithm. KRD sends this to the KDH. There is no special encoding for the KCV.
  6. On KDH
    1. key-check value verified by KDH:
      • KDH verifies the KCV against the original Kn-T that was sent for export using TR-34. The CCA service CSNBKYT2´using keywords VERIFY and ENC-ZERO or CMACZERO depending on the key algorithm can be used for this value.