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

Question

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.

Answer 1

No, there are no problems (which I could see) with re-using the signature key in this scenario.

There are two potential concerns:

1. It may be possible to learn something about the private key using the challenge-response protocol
2. It may be possible to re-use the signature of a run of the challenge-response protocol for TLS

The first concern is clearly invalid, as any decent signature won't allow you to learn anything about the private key just be asking for signatures of (chosen) messages (this is the standard security notion for signature schemes). The same argument holds for TLS' client authentication.

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).