REBIND

Edit online
Rebind a Key Receiving Device (KRD) to a Key Distribution Host (KDH). This is done when a KDH needs to update the credentials held at the KRD that represent the KDH; for example, if the certificate is about to expire. These are the steps, in sequence, with the CCA service APIs identified:
  1. On KDH
    1. Generate a new RSA key pair (E-kdh-new, D-kdh-new), made by the HSM in their mainframe.
      • Use CCA service CSNDPKG.
    2. Extract public key (E-kdh-new) into PKCS #10 certificate signing request (CSR-KDH-new).
      • Use CCA service CSNDPIC.
    3. KDH sends CSR-KDH-new to the Certificate Authority to be turned into a certificate CredKDH-new under the agreed CA.
    4. KDH receives from CA these TR-34 objects.
      1. CredKDH-new: A certificate holding (E-kdh-new). Store certificate for use with all KRDs during REBIND.
      2. CRL-CA: New Certificate Revocation List. Store for use until not considered fresh any longer.
      3. CredCA: A certificate for CA. Install this in the CCA HSM PKI manually from the TKE for each domain that will use the TR-34 protocol. Also, keep this for new card provisioning.
    5. The KDH requests a random number from the KRD.
  2. On KRD
    1. Call CCA service CSNBRNGL using keyword RT-KRD to create the TR-34 token that contains the random number that is needed by the KDH.
      1. INPUT:
        • RN-length: Length of the random number needed.
      2. OUTPUT:
        • RT-KRD: Random number token.
      3. KEY STORAGE:
        • RT-KRD stored in application space.
    2. Send RT-KRD to KDH.
  3. On KDH
    1. If CRL-CA is not fresh any longer, the KDH should obtain a new CRL-CA before doing the next step.
    2. Call CCA service CSNDT34B using keyword REBINDCR.
      1. INPUT:
        1. RT-KRD: Random number token received from KRD.
        2. CRL-CA: Certificate Revocation List from CA.
        3. CredKRD: KRD credential with ID and public key.
        4. CredKDH-new: New KDH credential with ID and public key.
        5. CredKDH-old: Old KDH credential with ID and public key.
        6. D-kdh: Old private key needed to sign the REBIND data block.
      2. OUTPUT:
        • UBT-KDH: REBIND token.
    3. KDH sends the UBT-KDH token to the KRD.
  4. On KRD
    1. The KRD receives the UBT-KDH token from the KDH and now must process it to complete the REBIND.
    2. Call CCA service CSNDT34C using keyword REBINDRV.
      1. INPUT:
        1. UBT-KDH: REBIND token received from KDH.
        2. CredKRD: KRD credential with ID and public key.
        3. CredKDH: Old KDH credential with ID and public key.
        4. RT-KRD. Token originally sent by the KRD to the KDH and used now for validation.
      2. OUTPUT:
        1. UBT-KDH – is – valid: (yes or no/error)
        2. CredKDH-new: New KRD credential.
      3. KEY STORAGE:
        • CredKDH-new stored in application space.
    3. The application on the KRD removes all the keys associated with the CredKDH that sent the REBIND request (they are regarded as invalid). The KRD stores the CredKDH-new so that future key distribution events can be handled. This completes the REBIND phase.