Waterken^TM YURL

Schneier's PalmPilot

2003-10-21

In "Secrets and Lies", Bruce Schneier discusses the failure of PKI on the Internet. The purchase of a PalmPilot accessory is used to demonstrate this failure. This document shows how YURLs are used to implement authentication on the Internet while avoiding the ineffective burdens of PKI.

PKIs On The Internet

From "Secrets and Lies", by Bruce Schneier, Chapter 15, "Certificates and Credentials", section "PKIs On The Internet" (page 238):

Most people's only interaction with a PKI is using SSL. SSL secures web transactions, and sometimes PKI vendors point to it as enabling technology for electronic commerce. This argument is disingenuous; no one is turned away at an online merchant for not using SSL.

SSL does encrypt credit card transactions on the Internet, but it is not the source of security for the participants. That security comes from credit card company procedures, allowing a consumer to repudiate any line item charge before paying the bill. SSL protects the consumer from eavesdroppers, it does not protect against someone breaking into the Web site and stealing a file full of credit card numbers, nor does it protect against a rogue employee at the merchant harvesting credit card numbers. Credit card company procedures protect against those threats.

PKIs are supposed to provide authentication, but they don't even do that.

Example one: the company F-Secure (formerly Data Fellows) sells software from its Web site at www.datafellows.com. If you click to buy software, you are redirected to the Web site www.netsales.net, which makes an SSL connection with you. The SSL certificate was issued to "NetSales, Inc., Software Review LLC" in Kansas. F-Secure is headquartered in Helsinki and San Jose. By any PKI rules, no one should do business with this site. The certificate received is not from the same company that sells the software. This is exactly what a man-in-the-middle attack looks like, and exactly what PKI is supposed to prevent.

Example two: I visited www.palm.com to purchase something for my PalmPilot. When I went to the online checkout, I was redirected to https://palmorder.modusmedia.com/asp/store.asp. The SSL certificate was registered to Modus Media International; clearly a flagrant attempt to defraud Web customers, which I deftly uncovered because I carefully checked the SSL certificate. Not.

Has anyone ever sounded the alarm in these cases? Has anyone not bought online products because the name of the certificate didn't match the name on the Web site? Has anyone but me even noticed?

I doubt it. It's true that VeriSign has certified this man-in-the-middle attack, but no one cares. I made my purchases anyway, because the security comes from credit card rules, not from the SSL. My maximum liability from a stolen card is $50, and I can repudiate a transaction if a fraudulent merchant tries to cheat me. As it is used, with the average user not bothering to verify the certificates exchanged and no revocation mechanism, SSL is just simply a (very slow) Diffie-Hellman key-exchange method. Digital certificates provide no actual security for electronic commerce; it's a complete sham.

What needs to be protected?

In both Example one and Example two, we must guarantee that Bruce Schneier's credit card information is only revealed to the legitimate vendor. Should a fraudster get the credit card information, Bruce will lose $50 and the time required to resolve the dispute with his credit card company. The credit card company will lose the amount of the fraud, plus the cost of investigating and resolving the dispute. The state will lose the cost of prosecuting and incarcerating the fraudster. The fraudster stands to lose the most.

If we can correctly authenticate the 'legitimate vendor', we can use the SSL protocol to protect Bruce's credit card information from both eavesdroppers and imposter websites. As Bruce points out, this protection is only part of a comprehensive security solution, but it's a necessary part.

Who is the 'legitimate vendor'?

The key to this puzzle is understanding who the 'legitimate vendor' is.

In Example two, the PKI solution assumes that the 'legitimate vendor' is "Modus Media International". Considerable effort is expended to authenticate "Modus Media International" and issue it a certificate for the palmorder.modusmedia.com domain name.

As Bruce implies, authenticating "Modus Media International" is not a useful security measure. The user is expecting to do business with Palm and likely has never even heard of "Modus Media International". As far as the user knows, palmorder.modusmedia.com could be an imposter website. Knowing that the website is operated by some unknown company is of little use.

To understand who the 'legitimate vendor' really is, we have only to look at why the user went to palmorder.modusmedia.com. The user went to this website because the www.palm.com website told him to. If www.palm.com had directed the user to a different website, the user would need to trust this other website instead of palmorder.modusmedia.com. So the 'legitimate vendor' is not any particular website, but whoever www.palm.com says it is.

Securing the introduction

Correctly authenticating the 'legitimate vendor' means securing the introduction of the vendor by Palm. If the user is securely introduced to the vendor specified by Palm, the user's credit card information will be delivered to the correct website.

Since Palm is the authority on who the 'legitimate vendor' is, Palm should provide all the information needed to authenticate the vendor website. Palm can easily do this by linking to the vendor website using an httpsy: URL. There's no need to involve a third-party Certificate Authority (CA). The effort that was required to authenticate "Modus Media International" can instead be deployed towards more useful ends.

Using an httpsy: URL enables Palm to securely identify the 'legitimate vendor'. To secure the introduction, we must ensure that this identifier is securely transferred from the Palm website to the user's WWW browser. Securing this transfer requires authenticating the Palm website to the user's WWW browser. This authentication could be done with a standard https: URL for www.palm.com, or could be done with another httpsy: URL. Palm could put an httpsy: link to its online store in the documentation delivered with sale of its PalmPilot.

YURLs On The Internet

Using YURLs, Bruce's purchase of a PalmPilot accessory would proceed as follows:

Bruce Schneier buys a PalmPilot. He wishes to buy an accessory for his PalmPilot. He clicks on a link in the PalmPilot documentation delivered with his PalmPilot. [keyword] The link takes him to an online store where he sets up purchase of the desired accessory. He clicks on a "purchase" link given to him by the online store. The "purchase" link takes him to a credit card processing site. Bruce completes the credit card transaction with this site.

On each link click, Bruce's browser ensures that the public key fingerprint specified in the link's httpsy: URL matches the fingerprint of the target site's public key. The cryptography therefore guarantees that Bruce is giving his credit card number to the correct site.

Note that the YURL solution does not require Verisign certificates, nor the manual verification of any certificates, or URLs. The browser automatically takes care of the authentication tasks. From the user's perspective, the YURL solution is invisible, proceeding much as any other WWW interaction does. The cryptography is used to enforce the expectations the user naturally has for the interaction.

Footnotes

[keyword] The httpsy: link to Palm's online store could also be obtained from a keyword system operated by either the user, or a third-party.

The Mozilla Firebird web browser allows the user to associate a keyword with a bookmarked URL. When the user enters the keyword in the browser's "Location Bar", he is redirected to the bookmarked URL.

If the user has never visited Palm's website, he could obtain an initial httpsy: link from a keyword system hosted by a third-party. A web form would accept a keyword and return a redirect to the corresponding httpsy: URL. The user could then bookmark the httpsy: URL for subsequent visits.

Copyright 2003 Waterken Inc. All rights reserved.