Does PKI Make Sense for Authentication on Consumer Web Sites?

By eweek  |  Posted 2007-11-12
Mark Diodati, Burton Group, senior analyst, Identity and Privacy Strategies, talks with Jeff Gould, CEO & director of Research at Peerstone Research, about PKI and its application on different types of Web servers.

Peerstone: U.S. financial institutions and consumer Web sites resorting to softer forms of strong authentication instead of traditional hardware-based authenticators provoked a fair amount of controversy. Lets look at some of the objections to this and get your responses to them. The problem starts from the fact that American consumers dont like hardware tokens, and American financial institutions dont want to hand them out because theyre afraid of the support costs. So instead, the institutions are experimenting with less intrusive methods such as typing biometrics, which authenticates users by measuring their keyboard typing speed and dwell time. In particular, Tim Renshaw of mobile PKI vendor TriCipher, wrote in his blog in response to our last Q&A that typing biometrics are vulnerable to man-in-the-middle attacks [commonly known as MITM]. He argues that consumer Web applications really need the higher level of protection offered by public key encryption based on Public Key Infrastructure [PKI]. He also thinks that American consumers wont necessarily object to the inconvenience of downloading special software or using smart cards issued by their bank to get the benefits of this kind of security. Is he right that U.S. consumers really need PKI?
One important concept to understand is that when it comes to authentication, no technique is bulletproof from a security perspective. Attacks on authentication systems include man-in-the-middle and also PC malware that can capture user passwords. Smart cards are considered the strongest form of authentication because they have a secure storage area that is tamper-resistant. But smart card systems can be compromised by PC malware after the user authenticates to the card. Mobile PKI systems, which deliver public key credentials in a secure way, can be compromised by keystroke capture. Because nothing is bulletproof, multiple authentication techniques should be layered to get to a sufficient level of security. That said, mobile PKI can mitigate against MITM attacks. Im not summarily dismissing either the typing biometric or PKI technologies, Im simply pointing out the realities on the ground.

Peerstone: Can you give me a brief explanation of public key encryption and how it relates to PKI?
From an authentication perspective, private key infrastructure might be a better descriptor of what really happens in PKI. In summary, each entity [e.g., both the user and the Web server] possesses two keys that are mathematically related. One key is called the private key. The second key-the public key-is placed in a public document called a certificate. If a message is encrypted with the users public key, only the users private key can decrypt it. If a message is signed with the users private key, the signature can be verified by using the public key. These encryption and signature processes are basic to PKI. For these processes to work, the private keys must be secured.

Peerstone: How do we get from basic public key encryption to online authentication with PKI?
Web servers and browsers can use these PKI credentials to mutually authenticate the user and the Web site. This process is called mutually authenticated SSL [secure socket layer], and can mitigate the risk of man-in-the-middle attacks. However, mutually-authenticated SSL is not widely deployed. Typically, only the Web server has a certificate and private key-the user does not have PKI credentials, and in this case the SSL authentication is only one way. The Web server authenticates to the browser via its PKI credentials, which facilitates some basic trust and session encryption to prevent eavesdropping of the session. This process is called server-side SSL. The user does not authenticate to the Web server via PKI credentials, but typically just uses a username and password after the server-side SSL session is established. Server-side SSL sessions can still be attacked by a MITM, though, because the server cant be completely sure the messages it receives are really coming from the true user rather than from someone who has stolen the users password and user name.

Peerstone: So why doesnt my bank just put my digital certificate and my private key on some kind of hardware gadget like a smart card to make sure it isnt compromised?
The process of deploying smart cards, smart card readers and smart card software to retail banking consumers is a Herculean task that is currently economically infeasible for financial institutions. Some smart cards have a USB form-factor, which eliminates the deployment of a smart card reader. Either way, the deployment and support costs would exceed the anti-fraud benefits that the solution provides.


Rocket Fuel