# Reuse of TLS client key/certificate in challenge-response protocol

The situation: We have a custom PKI with clients communicating with the server over standard SSL/TLS encrypted channel. PKI uses ECC, server certificate supports ECDHE_ECDSA key exchange mechanism and is signed using our custom CA. Clients are authenticated to the server using their client certificates containing ECDSA public keys.

In addition, clients also communicate with each other - this channel is not encrypted and we only use a simple challenge-response protocol for unilateral authentication (only one side needs to be authenticated). The challenge-response protocol is taken from the Handbook of Applied Cryptography (10.3.3(ii)2., PDF) and goes as follows:

$A ← B : r_B$

$A → B : cert_A , r_A , id_B, S_A (r_A, r_B, id_B)$

where:

• $r_B$ is a random challenge generated by $B$.
• $cert_A$ is $A$'s certificate.
• $id_B$ is an identifier of $B$.
• $r_A$ is a random number generated by $A$ to prevent chosen-text attacks.
• $S_A(r_A, r_B, id_B)$ is a signature computed over concatenated values of $r_A$, $r_B$ and $id_B$ using $A$'s private key corresponding to $cert_A$'s public key.

So, $cert_A$ and corresponding $A$'s private key are reused in SSL/TLS and the challenge-response protocol. Are there any bad consequences of this approach? Any suggestions? Thanks.

• I'm curious: Why don't you use TLS for peer-to-peer communication as well? – SEJPM Apr 2 '16 at 18:45
• Clients are mobile devices and communication is done over NFC, so we wanted to keep the number of messages low and make it as simple as possible. Also, encryption is not required for this channel. – mirocslav Apr 4 '16 at 6:41

The second concern is also invalid as an attacker can't control the messages being signed in neither TLS nor the challenge-response protocol. In TLS, the client signs the complete transcript being exchanged yet, including the client's random and the server's random value, which the attacker can't control both. The same argument holds for this scheme. While the attacker can control $r_B$, he can't control $r_A$ and thereby he would have to hope that the random values repeat in the protocol (extremely unlikely) or that the hash to be signed is the same in TLS, which would imply a collision on the hash function, which is extremely unlikely if the hash function is chosen somewhat decently (like SHA-256).