0

Many VoIP handsets support client-side SSL authentication for auto-provisioning. Unfortunately, some devices must be programmed with their client-side keys. (Keys generated on low-entropy devices are poor, but lets not argue that detail).

For this question, we have three players:

  1. The device (a phone)
  2. The server (some client-side authenticated HTTPS server)
  3. Eve, who has intercepted or otherwise stolen the client's key.

If a client-side private key is intercepted by Eve during the initial key install, then certainly Eve can impersonate the client.

To further strengthen Eve's position, assume the device accepts any self-signed certificate presented by the provisioning server (some devices do not have a way to program custom CA's). Also assume that Eve can redirect all connections through herself.

Given this, can Eve leverage a full MitM attack, something like the following:

Device{Client Key} => {CA2}Eve{Client Key} => {CA1}Server

I believe the answer is yes and that the only way to prevent a MitM is for the device to validate the server's certificate through a trusted CA. Please confirm or refute. I am interested in technical details here.

2

If the client accepts any certificate as a valid server's certificate, then an active attacker can impersonate the server when talking to the client.

If the attacker can steal a copy of the client's private key then he can impersonate the client when talking to the server.

If both conditions hold, then the attacker can run a successful Man-in-the-Middle attack, by definition: a MitM attack is nothing more than simultaneous double impersonation. The attacker poses as the client when talking to the server, and as the server when talking to the client; he relays traffic in both direction, inspecting and modifying data at will.


If the client can make sure that it uses the genuine server's certificate (either through validation from a known trusted root CA, or maybe because the client remembers the server's certificate from a previous connection), then the client will reject the impersonation attempt, and the MitM won't work. The attacker, who has stolen the client's private key, will still be able to replace the client, e.g. hijacking incoming calls, but that won't be a true MitM (the attacker will have to imitate the voice of the normal client's owner).

Note that if the attacker does not have a copy of the client's private key, and the server validates the client's public key in some way (e.g. the server remembers the client's public key after an initial configuration step), then the attacker will not be able to impersonate the client. Client authentication in SSL is such that even if the attacker impersonates the server, he cannot reuse the messages from a gullible client to fool the true server. Technically, the client uses his private key to sign a "challenge" which is a hash value computed over everything client and server have sent each other so far, and this includes the server's certificate; so, in case of MitM, the client will sign messages containing the attacker's public key (the fake server certificate sent by the attacker), not the certificate sent by the true server, and the signature will not match what the true server expects.


Therefore, if either the client can make sure that it uses the true server's certificate, or the server can make sure that it uses the true client's certificate, or both, then a complete MitM attempts must fail. However, even without a MitM, impersonation (an "half-MitM") is still possible:

  • If the attacker steals the server's private key, or the client fails to validate the server's certificate, then the attacker can impersonate the server.
  • If the attacker steals the client's private key, or the server fails to validate the client's certificate, then the attacker can impersonate the client.

Finally, if the attacker has a copy of the server's private key, and the SSL/TLS cipher suite is one of the non-DHE RSA suites, then the attacker can decrypt all the data after purely passive interception, and can also hijack the connection at any point after the handshake, which allows, again, a MitM. The same does not hold for a stolen client's private key; in SSL/TLS, the client certificate and private key are used only for authentication, not for the key exchange, and have no influence whatsoever on the resulting secret used for actual data encryption.

1

Yes but partially no.

Eve can make any request to the server pretending to be the mobile device and can VIEW the server response (since the private and therefor public key are known). However Eve cannot change the response the server sends to appear differently to the mobile device unless an weak hashing algorithm that is susceptible to collision attacks is used for generating the signature.

0

I believe that, by definition, a "full MiTM attack" can only occur when an attacker (Eve in this case) can ascertain BOTH the client and the server's key. Is that the definition you're working off of too?

Though the client (mobile device) is very naive in this case, I do not see how Eve can use any of her advantages above to glean the server's private key. Can you maybe see something I'm missing?

The only thing I can think of is for Eve to replace (and store) the phone and the server's public keys and intercept messages and send them on pretending that they actually came from her. Once she receives a response (which would have been encrypted with Eve's public key), she could then use the intended recipient's public key to encrypt the message and then pass it along. This doesn't mean, though, that the server's private key is ever obtained.

  • I believe she can generate her own self-signed key and use the stolen client key to connect to the server since the device will not authenticate Eve's CA. Is this not so? – ewheelerinc Dec 3 '13 at 19:53
  • I just added that fact to my comments above. You're totally right about that. I'm just not sure what definition is being used here to mean "full MiTM". Yes, what you said is exactly right. – jkovba Dec 3 '13 at 19:55
  • I think eve would use the phone's pubkey since she can derive it from the stolen privkey. – ewheelerinc Dec 3 '13 at 20:03
  • You're right that Eve would use the phone's public key, but not because she can derive it from the stolen private key. The public key is transmitted at the beginning of the discussion by both sides, so Eve just needs to intercept the public keys at the beginning of the discussion to be able to intercept messages. Can you tell me your definition of "full MiTM"? – jkovba Dec 4 '13 at 11:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.