Trust Management for Humans
This document compares the human interface for trust management in the PKI to that for YURLs, specifically focusing on resilience to phishing attacks.
The World Wide Web is, as the name implies, a web of interconnected, but independent sites. A user has a different trust relationship with each site. For example, a user may trust one site, but not another, to perform a credit card transaction. When a user follows a link from one site to another, the transition from one trust relationship to another must be apparent and unspoofable.
Currently, trust relationship transition within the WWW relies on the PKI. This document explains the PKI solution, highlights its flaws, and shows how trust relationship transition is better implemented without the PKI.
When surfing the WWW, a user finds an interesting book review. The book review links to an online bookstore which sells the book. Following the hyperlink to purchase the book involves a trust relationship transition. The user has an existing relationship with the online bookstore and trusts it to complete credit card transactions. The user does not place the same trust in the newly discovered book review site. Unfortunately, to purchase the book, the user follows the hyperlink provided by the untrusted book review site. A fraudulent book review site links to a spoof site that appears the same as the online bookstore. The spoof site attempts to make a fraudulent charge to the user's credit card.
In the fraudulent bookstore example, a deceptive site transition occurs, causing the user to make an unwarranted trust relationship transition. The user believes that a site transition to the trusted bookstore has occurred, when in fact, a transition to a spoof site has occurred. The user is deceived about the true target of the site transition and makes an incorrect trust relationship transition.
Currently, the WWW uses the PKI in an attempt to protect against deceptive site transitions. After the site
transition, the user is expected to examine the target URL displayed in the browser's address bar. The
user must verify that the target URL is in the
For example, suppose the bookstore in the bookstore example is Amazon Inc. After clicking on the book
review site hyperlink, the user must verify that the URL in the browser address bar starts with:
In the switch from the book review site to the bookstore site, two transitions take place: the site transition to the bookstore site and the trust relationship transition to the bookstore site. As the provider of the hyperlink, the book review site must be allowed to specify the target for the site transition; however, the book review site must not be allowed to specify the target of the trust relationship transition. Accepting directions from a stranger is safe, but accepting a stranger's advice on who to trust is not. Unfortunately, the PKI solution logic makes this error.
The PKI solution uses a single domain name as the identifier for both the site transition target and the trust relationship transition target. This conflated name is specified in the link URL provided by the potential attacker. As a consequence of this conflation, the name used to recognize the target trust relationship is also specified by the potential attacker. It is inherently dangerous to use the link target identifier, an element whose value is necessarily chosen by the potential attacker, as the key user interface element in recognizing a trust relationship.
Phishing attacks commonly exploit this flaw in the PKI's logic. Domain names, deceptively similar to that of a trusted site, are frequently registered. Users frequently receive fraudulent email containing URLs which appear to have the same domain name as a trusted site.
Expecting a human to detect a small and deceptive change to a domain name is unrealistic. Given this constraint, using a domain name as a trust relationship identifier is dangerous.
A YURL does not rely on a global namespace, like a PKI URL does. A YURL identifies a target site by the hash of its public key. Given the absence of a global namespace, a user can conveniently create a local namespace.
In the YURL solution, the user's browser maintains a mapping of public key hash to petname. [PNML] When a user visits a page identified by a YURL, the browser prominently displays the petname the user previously associated with the public key hash contained in the YURL. If no such association exists, the browser allows the user to create one. After a site transition, the user verifies that the expected petname is displayed.
For example, after the site transition from the book review site to the Amazon Inc. site, the petname toolbar displays the user's previously chosen petname for the Amazon Inc. site, say "Amazon". An example display is shown in Figure 1.
Figure 1: A site transition to the trusted "Amazon" site.
If the book review site linked to a spoof site, instead of the Amazon Inc. site, the petname toolbar indicates that there is no associated petname. An example display is shown in Figure 2.
Figure 2: A site transition to an untrusted site.
Note that in neither case can the book review site craft the content of the petname toolbar. The petname toolbar can only be populated with a petname created by the user. Presentation of an untrusted site is readily recognized by the absence of a corresponding petname. The absence of a petname indicates the absence of a trust relationship. The presence of a petname indicates the existence and applicability of a particular trust relationship.
A petname is assigned to a site by the user when the user decides that he has a trust relationship with the site. The user chooses a petname that he feels best describes the relationship. When the user visits a page from the site, the petname toolbar displays the chosen petname, helping the user recognize the trusted site and remember the nature of his trust relationship with the site.
Since the user manages his trust relationship namespace, he can select localized names that maximize his ability to make correct trust relationship transitions. This feature is especially important for non-English-speaking users.
Phishing is an attack upon the user's mind. The attacks exploit human frailties in recognizing trusted entities and confusion in the user's mind about what trust applies to a particular entity. Defending against phishing attacks requires defending the user's mind by bolstering the user's ability to identify and track his trust relationships. The petname toolbar is designed to provide this support.
To be readily disambiguated, subjects must first be identifiable. For the transition from one trust relationship to another to be apparent, the trust relationship must be raised to a first class entity within the GUI. A first class entity is an entity which can be identified independent of any other entity.
Humans recognize things and reason about them using names. The petname toolbar supports naming of trust relationships. In addition to enabling recognition and reasoning, this function raises the trust relationship to first class status within the GUI. By raising the trust relationship into the user interaction model, we gain the channel needed to communicate explicit information about trust relationships between the user and the browser software. This communication enables augmenting the user's abilities with those of software.
By creating a petname, the user signals the birth of a trust relationship and provides it with an identity. By updating the petname display on each page transition, the petname toolbar makes the transition from one trust relationship to another apparent. By occupying a static position within the GUI, even when there is no applicable trust relationship, the petname toolbar provides a consistent basis from which the user can make decisions about information or actions presented by a web page.
Human memorable names form an unusual namespace. Alphabetically similar names are often interpreted as being the same name. Even alphabetically dissimilar names may be interpreted as synonyms. A relationship is assumed to exist between names that contain a common substring. All of these interpretations vary widely from one user to another. For the transition from one trust relationship to another to be unspoofable, it is crucial that the user not confuse the identifier of one trust relationship with that of another.
Given the custom nature of name recognition, the safest way of assigning a name to an entity is for the user of the name to choose the name. The user himself is the best judge of which names are likely to be confusing and which not.
The fragility of human memorable namespaces requires providing the user absolute control over the members of the namespace. Were the user required to adopt a foreign name into his custom namespace, subtle and hard to correct conflicts with existing names could be created. An attacker could purposefully create such conflicts to perpetrate a spoof. Similarly, the user must never be asked to determine if a foreign name matches a member of the user's custom namespace. The foreign name was not constructed to obey the user's criteria for distinct names and so a safe comparison is not possible.
By supporting a namespace that conforms to the user's expectations for distinct names, the petname toolbar maximizes the user's ability to recognize an identified trust relationship. By exclusively using this namespace, the petname toolbar deprives attackers of the opportunity to perpetrate a spoof.
For the user to wisely interact with an entity, the user must accurately remember the full nature of his trust relationship with the entity. This nature is determined by experience with the entity, recommendations obtained through other trust relationships and the user's judgement.
In addition to being an identifier, a name is a memory aid. Since the nature of a trust relationship is highly specific to the particular user, and it is the user's memory that is being aided, the user is best suited to name the trust relationship. Moreover, since the user will continue to accrue experiences and recommendations for an entity, the user may need to evolve an entity's name to track the evolving relationship.
Equally important to the customization of a name is the absence of a name. The petname toolbar acts as a catalogue of a user's trust decisions. The absence of a petname indicates the absence of a trust relationship. Foreign insertion of a petname into the user's namespace is tantamount to the forging of memories. To maintain a coherent memory, clearly distinguishing untrusted entities from entities with a corresponding trust relationship is crucial.
By providing a constantly accessible and editable display of an entity's corresponding petname, the petname toolbar maximizes the utility of a petname as a memory aid. By ensuring that petnames are only created through explicit user action, the petname toolbar bolsters the user's understanding of the origins of trust and protects the sanctity of the user's memory of trust decisions.
For some, creation of a new first class entity within the browser GUI, and user maintenance of this entity, may seem like too great a burden. This section lists less intrusive mechanisms and provides arguments showing these mechanisms insufficient.
Application designers rightly have a strong desire to provide a system that does as much as possible for the user and requires as little as possible from the user. This desire can easily lead to the assumption that a global namespace for websites is the required solution. A more in-depth study of the problem reveals this assumption to be incorrect. Not only does a global namespace not help defend the user against phishing attacks, it is in fact the root cause of phishing attacks. The global namespace is the source of the problem, not the solution to the problem.
A global namespace suffers from name conflation. As a result of this conflation, the user is required to distinguish foreign generated names from trusted names. Human memorable namespaces do not support this kind of recognition.
A global namespace provides the user with no control over the namespace of trusted sites. Without this control, the utility of names as a memory aid is greatly reduced. By injecting names into the user's namespace, a global namespace gives the appearance of a trust relationship, where none actually exists. Under the PKI, an untrusted site has all the same visual hallmarks as a trusted site. This practice misleads the user and lends assistance to fraudsters.
Moreover, the desire to restrict the user's role in trust management is misguided. If the user is not engaged in the management of trust, he is less able to understand trust and is thus more vulnerable to fraud. Phishing is an attack upon the user's mind. We must enable that mind to defend itself, not make it a more idle and easy target for fraudsters.
Under normal circumstances, a user will visit known and trusted sites more frequently than unknown sites. It is tempting to have the browser count page views and present this information to the user as an indication of familiarity. Such a mechanism would break down under attack. There are multiple ways to automatically fetch pages in a browser. A fraudster could readily inflate a page view count for a spoof site before directing the user to the spoof page.
Clicking of a hyperlink is not an indication by the user of trust for the target site. Trying to infer trust from a non-explicit user indication of trust is dangerous. The user's correct understanding of trust is crucial to the user's security. Employing partial measures to protect the weakest link in the chain is reckless design. If the user is vulnerable to a phishing attack, no amount of cryptography or certification can protect him. Engaging the user in a deliberate mechanism for managing trust is necessary to ensure the user's safety and the value of the provided cryptographic protections.
A petname system is solely for the benefit of humans; software has no trouble differentiating between YURLs. A web service, or other software that uses YURLs, should operate exclusively by direct use of YURLs.
Copyright 2003-2004 Waterken Inc. All rights reserved.