1-pass key transport

Edit online

This key transport typically installs a Terminal Master Key (TMK) at the Key Receiving Device (KRD). '1-pass' indicates that the KRD is not expected to be online.

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.

The protocol includes a timestamp (or other monotonic increasing number) to be sent by the KDH so that the KRD can defend against replay attacks.

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 (required for comp-tag keys) 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 CKDS.
      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 CKDS.
      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 CKDS 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 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 (required for comp-tag keys) 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 CKDS.
      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: AES EXPORTER key with usage EXPTT31D for wrapping output TR-31 key blocks.
        3. KEY STORAGE: Stored in CKDS.
      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 CKDS until export.
      4. CCA services:
        • Use the CSNBKTB2 or CSNBT31C service to create skeleton tokens for the EXPORTER/IMPORTER copies of the key.
        • 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-HSM 2016 compliance mode and other standards. The maximum TR-34 wrapping key strength is AES 128-bit.

Protocol steps for key transport

  1. On KDH
    1. TR-34 application creates a Timestamp. This is the freshness test that will be used by the KRD.
    2. Create the Key Transport token:
      1. Overview: Call CCA service CSNDT34D: "1PASSCRE".
      2. INPUT:
        1. Kn-T: CCA or TR-31 key token to be exported to the KRD.
          • KEY STORAGE: Stored in CKDS.
        2. Timestamp freshness indicator to defend against replay attacks.
        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 PKDS.
        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 (1-pass) token.
          • KEY STORAGE: Stored in application space until sent to KRD.
    3. KDH TR-34 application sends the KT-KDH token to the KRD.
  2. 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: "1PASSRCV".
      2. INPUT:
        1. KT-KDH: Key transport (1-pass) token received from KDH.
          • KEY STORAGE: Stored in application space until this call occurs.
        2. CredKDH: KDH credential with ID and public key.
          • KEY STORAGE: Stored in application space or key ring.
        3. Timestamp-min: Minimum timestamp value allowed. It could be the last timestamp received or a bootstrap value. If passed, card validates that the KT-KDH contains a newer timestamp than Timestamp-min.
        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 PKDS 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 CKDS on KRD.
        • Timestamp-rcv: Timestamp value received from the KDH in the KT-KDH.
          • STORAGE: Stored in application space as the next minimum.
    4. If necessary, the application validates Timestamp-rcv in a customized fashion.
  3. On KRD
    • Key Check Value generated and returned to KDH.
      • The KRD generates a Key Check Value (KCV) for Kn-T using CCA service CSNBKYT2: GENERATE and ENC-ZERO or CMACZERO service depending on the key algorithm. KRD sends this to the KDH. There is no special encoding for the KCV.
  4. On KDH
    • 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: VERIFY and ENC-ZERO or CMACZERO service depending on the key algorithm can be used for this value.