[Continued from part II]
The second post in this series considered what makes an authentication protocol resistant to phishing, in the presence of fallible users making wrong decisions about where to authenticate. Even with public-key cryptography and smart cards, safety hinges on incorporating a “context” as additional input to the protocol when producing the proof of user identity. As long as this context is guaranteed to be different between the legitimate website and its fraudulent replica, the protocol is not susceptible to man-in-the-middle attacks leveraging user confusion.
A good choice of context for a hypothetical web authentication protocol would be the name of the website on the other side. Substituting a different name leads to different contexts, even if they appear “close enough” as far as the user is concerned. PayPa1 (spelled with 1 instead of L) may resemble PayPal to the human eye, but software is not fooled. That one letter makes all the difference in the world, especially when the strings are used as input into a cryptographic computation. It might as well have been a completely random sequence of symbols unrelated to the original; the result will be uncorrelated. In our phishing scenario, Bob will indeed receive a “response” in the form of a signature from Alice, if she decides to go ahead with authentication. But he can not turn around and use that response in the parallel session for logging into the real PayPal. The signature has been computed over a different message and bears no resemblance to what the site expects.
To take a more concrete example of a widely deployed protocol, consider the TLS or Transport Layer Security, also referred to by the name of its predecessor SSL. This protocol has an option to authenticate users with public-key cryptography during the initial handshake. This is an optional feature, not to be confused with authenticating the server, which is always part of the protocol. Dubbed client authentication, this extra step calls for the user digital signing a transcript of messages exchanged with the server when negotiating the SSL/TLS connection. While the exact contents of what is being signed is not important, the critical point is that it includes the digital certificate of the server. (The “challenge” can be viewed as other parts of the transcript that the server has freedom to choose, such as a random nonce sent during the ServerHello message. Alternatively one can view the context as predetermined part of the challenge; both parties verify this part is consistent with their expectation.) That means a transcript of TLS handshake against two different websites can never be identical, even when one is intentionally trying to masquerade as the other.
The result is a set up truly immune to phishing. Users can cavalierly authenticate to any website they come across, without having to worry about the possibility that one of them may be malicious. No site can use the result of that authentication process to impersonate that user at some other site. That is a far cry from the degree of caution required for using passwords and OTPs: if credentials associated with one site are accidentally typed into a different one, there is a real possibility that the latter site gets unauthorized access to user data at the former.
There is one subtlety, an unstated assumption: that phishing sites can not present same certificate as the target they are mimicking. That breaks down into two conditions:
- Certificate authorities will only issue a certificate with “PayPal” in the name field to the business entity known as PayPal.
- Successfully using a certificate for SSL/TLS requires having the corresponding private-key, which by assumption only PayPal has in the above example.
Surprisingly it turns out the protocol is resilient even if the first property is partially violated. Suppose a certificate authority mistakenly or deliberately grants a PayPal certificate to crooks– after all, it is axiomatic that CAs are generally incompetent and occasionally even dishonest/corrupt. Even that would not be enough to generate a response usable in a man-in-the-middle attack. The fraudulent certificate will still have a different public key than the authentic one, so the contexts are not identical. Recall that the point of a certificate is making an assertion that recognizable name such PayPal is associated with a particular public key. A certificate authority can be tricked/bribed into issuing a different certificate asserting that PayPal has a different public key, a key that is in fact controlled by a malicious actor. But no amount of CA ineptitude/malice can allow that malicious actor to magically recover the private key associated with the original certificate.
The protocol however is not resilient to breakdown of the second property. If the private key is compromised and attacker can redirect network traffic, they can “replay” the result of an authenticated session. (It is debatable whether that can be called replay, since it amounts to taking over an authenticated session after it has been established between the user and legitimate site.)
It is also worth pointing out that either of these attacks require diverting network traffic. In traditional phishing, the user is at the wrong site but does not realize it. Network traffic is not being diverted or redirected; the confusion only exists at the visual level. Trying to pass off a fraudulent certificate or use a compromised private key however requires manipulating network traffic, which is certainly possible but more difficult attack than vanilla phishing.