Common use of CHECKING KEY CONSISTENCY Clause in Contracts

CHECKING KEY CONSISTENCY. At the end of key generation process, the legitimate users A and B have to make sure that they have generated the same secret key before they use this key for secure communication. To perform this check, the following three step algorithm is proposed. The security of this method in the presence of a pas- sive eavesdropper has been verified using the Automated Validation of Internet Security Protocols and Applications (AVISPA) software [28]. First- Transceiver B select a random real number R, encrypts it with its own key KB, and sends the encrypted value on the public channel, EKB (R), to transceiver A where EK (.) is encryption operator with key K. Second- Transceiver A decrypts the received value with their own key, does a hashing operation on it, encrypts it with KA, and sends EKA (H(DKA (EKB (R)))) to transceiver B on the public channel where DK(.) and H(.) are decryption with Key K and hashing operators, respectively. Third- Transceiver B decrypts received with KB. If the result is H(R) then transceivers sends an ‘OK’ acknowledge to transceiver A which confirms that both A and B’s keys are the same. On the other hand, if the result is not equal to H(R) then transceiver B sends a negative acknowledgement to transceiver A indicating that the two transceiver’s keys are not the same. It should be noted that EK(.), DK(.), and H(.) are all assumed public. Also, R cannot be reused and must be uniquely generated each time even if a replay attack would exist against the algorithm.

CHECKING KEY CONSISTENCY. At the end of key generation process, the legitimate users A and B have to make sure that they have generated the same secret key before they use this key for secure communication. To perform this check, the following three step algorithm is proposed. The security of this method in the presence of a pas- sive passive eavesdropper has been verified verified using the Automated Validation of Internet Security Protocols and Applications (AVISPA) software [2817]. First- Transceiver B select a random real number R, encrypts it with its own key KB, and sends the encrypted value on the public channel, EKB (R), to transceiver A where EK (.) is encryption operator with key K. Second- Transceiver A decrypts the received value with their own key, does a hashing operation on it, encrypts it with KA, and sends EKA (H(DKA (EKB (R)))) to transceiver B on the public channel where DK(.) and H(.) are decryption with Key K and hashing operators, respectively. Third- Transceiver B decrypts received with KB. If the result is H(R) then transceivers sends an ‘OK’ acknowledge to transceiver A which confirms confirms that both A and B’s keys are the same. On the other hand, if the result is not equal to H(R) then transceiver B sends a negative acknowledgement to transceiver A indicating that the two transceiver’s keys are not the same. It should be noted that EK(.), DK(.), and H(.) are all assumed public. Also, R cannot be reused and must be uniquely generated each time even if the a replay attack would exist against the algorithm. For our algorithm, the key checking algorithm is run on each block of the key generated from the algorithm in Section II. In the next Section, we discuss the probability of transceiver A and B agreeing to the same key.