UNBIND

Unbind a Key Receiving Device (KRD) from a Key Distribution Host (KDH). This is done before the KRD is taken out of service or if the KDH otherwise needs to remove ownership/bind/keys from a KRD. These are the steps, in sequence, with the CCA service APIs identified:
  1. On KDH
    • The KDH requests a random number from the KRD.
  2. On KRD
    • Call CCA service CSNBRNGL with 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.
    • Send RT-KRD to KDH and also store RT-KRD locally in application space for the later validation step.
  3. On KDH
    1. If CRL-CA held by the KDH, representing 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. Call CCA service CSNDT34B with keyword UNBINDCR.
      • 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: KDH credential with ID and public key.
        5. D-kdh: Private key to sign data block.
      • OUTPUT:
        • UBT-KDH: UNBIND 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 UNBIND.
    2. Call CCA service CSNDT34C with keyword UNBINDRV.
      • INPUT:
        1. UBT-KDH token: UNBIND token received from KDH.
        2. CredKRD: KRD credential with ID and public key.
        3. CredKDH: KDH credential with ID and public key.
        4. RT-KRD: Token originally sent by the KRD to the KDH, used now for validation.
      • OUTPUT:
        • UBT-KDH – is – valid: (yes or no/error).
    3. The application on the KRD removes all the keys associated with the KDH that sent the UNBIND request, which completes the UNBIND phase.