Perspectives: Improving SSH-style Host Authentication withMulti-Path Probing

Dan Wendlandt David G. Andersen Adrian PerrigCarnegie Mellon University

AbstractThe popularity of “Trust-on-first-use” (Tofu) authentica-tion, used by SSH and HTTPS with self-signed certificates,demonstrates significant demand for host authenticationthat is low-cost and simple to deploy. While Tofu-basedapplications are a clear improvement over completely inse-cure protocols, they can leave users vulnerable to evensimple network attacks. Our system, PERSPECTIVES,thwarts many of these attacks by using a collection of “no-tary” hosts that observes a server’s public key via multiplenetwork vantage points (detecting localized attacks) andkeeps a record of the server’s key over time (recognizingshort-lived attacks). Clients can download these recordson-demand and compare them against an unauthenticatedkey, detecting many common attacks. PERSPECTIVES ex-plores a promising part of the host authentication designspace: Trust-on-first-use applications gain significant at-tack robustness without sacrificing their ease-of-use. Wealso analyze the security provided by PERSPECTIVES anddescribe our experience building and deploying a publiclyavailable implementation.

1 IntroductionDespite decades of research into techniques for establish-ing secure communication channels for networked applica-tions, many of today’s popular protocols remain vulnerableto Man-in-the-Middle (MitM) attacks. Some applicationsprovide no security whatsoever (e.g., HTTP), and othersrely on self-signed keys or Diffie-Hellman-like key ex-change that can protect against eavesdroppers, but notagainst active adversaries who can interpose on communi-cation between the two parties.

While MitM attacks are not new, widespread use ofshared wireless networks coupled with recent discoveriesof automated MitM attacks in the wild indicate that thethreat is increasingly relevant. For example, the Arpiframeworm uses ARP poisoning to interpose on the HTTP trafficof other hosts on the same LAN [26], while worms exploit-ing simple vulnerabilities in home routers exposed end-hosts to “drive-by pharming” attacks that use DNS to redi-rect clients fake versions of security-sensitive websites [9].

Furthermore, a study by Reis et al. used client-side mea-surements to confirm that real-time snooping and modifi-cation of web traffic is a reality in today’s networks [20].

In this paper, we examine a novel approach to authen-ticating a server’s public key. Traditional approaches toserver key authentication, such as a public-key infrastruc-ture (PKI) [7, 5], rely on trusted entities (e.g., Verisign)that grant certificates based on the validation of real-worldidentities. When done securely, such verification requiressignificant (often manual) effort. While some networkhosts, primarily commercial websites, can afford to paythe high verification cost for these certificates, clients haveno simple and effective means to authenticate connectivityto most other hosts on the Internet.

Because the high cost of creating and managing a hostPKI presented a substantial barrier to the replacementof completely insecure protocols such as telnet, the SSHmodel of host authentication emerged as a pragmatic so-lution. Authentication in the SSH model relies on theuser’s discretion to decide if an unauthenticated key isvalid. Keys deemed valid by the client are cached locallyand used to authenticate subsequent communication withthe same server. While some users may verify all newor changed server public keys in a secure manner (e.g.,by memorizing a key fingerprint or verifying the key viaan alternate trusted channel), users often simply assumethe absence of an adversary on the initial connection andaccept the initial key without verification. We refer to thiscommon approach as Trust-on-first-use (Tofu) authenti-cation (it is also known as “leap-of-faith” authentication).

The Tofu approach has two primary weaknesses:1. By accepting any key on the initial connection, users

render themselves vulnerable to attack by any adver-sary either on the path between the user and the serveror on a shared wireless LAN.

2. On subsequent connections, the user must still man-ually determine the validity of any key that conflictswith a cached key. A user who assumes such keychanges are valid without verification receives no pro-tection against MitM attacks.

These weaknesses in the Trust-on-first-use approach areparticularly severe in the case of websites using self-signedSSL certificates, because web clients tend to visit a large

number of sites, increasing the number of vulnerable initialconnections. Moreover, web users often lack the meansand/or expertise to manually verify keys.

PERSPECTIVES improves on basic Tofu authenticationby having a collection of semi-trusted hosts called networknotaries periodically probe a large number of networkservices (e.g., SSH and HTTPS servers) to build a recordof the public keys used by those services over time. Whena client receives an unauthenticated public key from aservice, it contacts the notaries to download the historyof keys used by that service. This additional data fromdiverse network vantage points over a span of time givesclients the “perspective” to make a strictly better securitydecision: clients can often detect attacks during an initialconnection or a key cache conflict, the two scenarios whenthe standard Tofu authentication is most vulnerable.

Because notaries generate their data using automatednetwork probes, applications using PERSPECTIVES enjoythe same simplified deployment model as SSH: no certifi-cate authority is needed to verify the identity of serverowners and grant them certificates. Instead, the validityof a service’s key is determined by its existence on thenetwork over time. While the notary infrastructure addssome complexity to a Tofu-based application, it exists in-dependent of both clients and servers. Servers can remainunmodified while updated clients benefit from notary data.

While this paper focuses on protocols that use unauthen-ticated keys (i.e., the SSH model), PERSPECTIVES canalso help even when PKI-signed certificates are used. Aswe discuss in Section 8, because users often ignore browsersecurity warnings [21, 10], a MitM attacker can fool a userby injecting a bogus self-signed certificate in the place ofa PKI-signed certificate. PERSPECTIVES clients can eas-ily detect this attack by comparing the received certificatewith those seen by the notaries.

This paper makes four primary contributions:

1. It presents the design of a modular network notaryinfrastructure that tolerates internal failures and com-promises (Sections 3 and 5).

2. It describes a framework for (possibly automated)client policies that aggregate notary replies and deter-mine if a key is trustworthy (Section 4).

3. It analyzes PERSPECTIVES’s ability to resist a vari-ety of network attacks within a realistic threat model,demonstrating that it can protect Tofu-based applica-tions from many MitM attacks (Section 6).

4. It describes the implementation and benchmarkingof a publicly available release of PERSPECTIVES, in-cluding a robust notary server and modified OpenSSHand Mozilla Firefox clients capable of implementingbasic key trust policies (Section 7).

ServiceNetwork

Notary returns records of

key history to the client4

accepts/rejects keyrelevant key data and Client interprets

5

If offered key is untrusted,client contacts notary

3

1 2

Service respondswith public key

Notary

Client connects to service

Client

Figure 1: Overview of a client using PERSPECTIVES. Inpractice, several notaries would be contacted in parallel be-fore making a key trust decision.

2 Overview of PERSPECTIVES

We name our system PERSPECTIVES because it helpsclients make sound security decisions by leveraging viewsfrom multiple network vantage points. PERSPECTIVES’task is to help clients determine whether they should ac-cept an untrusted public key received while connectingto a particular network service. Example services includeSSH access to an end-host or HTTPS access to a websitethat uses a self-signed SSL certificate.

PERSPECTIVES uses a set of publicly available servers,called network notaries, that monitor and record the his-tory of public keys used by a network service. A notarycryptographically signs (i.e., notarizes) statements sayingthat at time t it observed service S using public key K. Thebasic operation of PERSPECTIVES is shown in Figure 1.When a client connects to a network service, it receivesan offered key in reply. If the offered key is unauthenti-cated (i.e., it does not match an existing key in the clientcache) the client must either accept the offered key, takinga security risk, or reject the key, losing the ability to com-municate with the service. To obtain more information tomake this decision, the client contacts a set of notaries andrequests all observed key data for that service. The clientthen uses application-specific key-trust policies (Section4) to interpret this data and accept or reject the key. Thesepolicies check for consistency between the offered keyand the keys seen by each notary, often allowing clients todistinguish between a legitimate key and an attack.

2.1 Threat Model & Attack ResistanceAttackers mount MitM attacks by providing clients witha false public key in order to observe or modify networkcommunications. In our attack model, an adversary cancompromise any path in the network as well as components

of the notary infrastructure itself. Only the client andserver themselves must be completely trusted, a standardrequirement for host authentication schemes.

While our model allows any network or notary com-ponent to be compromised, we borrow from AbrahamLincoln and assume that an attacker “can fool all of the[components] some of the time, and some of the [compo-nents] all of the time, but it cannot fool all of the [com-ponents] all of the time.” That is, we assume that attacksare either: (1) localized to a particular network scope or(2) of limited duration, since a larger attack is more easilydetected and remedied.

In this paper, we use the term redundancy to describethe protections that PERSPECTIVES provides. Key obser-vations gathered from multiple network vantage pointsprovide spatial redundancy, since unless an attacker cancompromise all network paths to a destination, notary datawill let a client to detect that an attack is likely underway.Temporal redundancy, provided by the key history datareturned by each notary, can offer additional protectionbecause even if an attacker compromises all paths to theserver, clients can still detect that a recent key change oc-curred and regard the new key with suspicion. Finally, dataredundancy (described in Section 5) helps clients detectmalicious notaries that supply inconsistent information,thereby limiting the effectiveness of attacks on the notaryinfrastructure itself.

The precise attack resistance provided PERSPECTIVESdepends entirely on how a client’s key-trust policy sets theparameters defining spatial, temporal, and data redundancyin order to balance the risk of accepting an unauthenticatedkey with the possibility of incorrectly rejecting a valid key.Sections 4 and 6 explore this trade-off in detail.

2.2 PERSPECTIVES vs. a Standard PKI

At a high level, PERSPECTIVES might be described asa “lightweight PKI”. While both PERSPECTIVES and astandard PKI require that clients securely retrieve one ormore public keys to bootstrap trust, there are two keydifferences between PERSPECTIVES and the traditionalPKI currently used to grant SSL certificates:

1. Mechanism for binding hostnames to public keys:Traditional PKIs use an offline mechanism to deter-mine that the real-world entity requesting a certifi-cate in fact owns the associated hostname. PERSPEC-TIVES uses automated network probing to bind keysto a hostname.

2. Degree of client control over trust decisions: Witha traditional PKI, the certificate authority makes auniversal judgment regarding key validity. With PER-SPECTIVES, each client independently interprets no-tary data and makes a decision based on its own secu-rity requirements.

Because probing by network notaries does not protectagainst all possible network attacks, we expect that highlysensitive services like bank or large e-commerce websiteswill continue to use heavyweight PKI mechanisms (pos-sibly augmented with notary data, see Section 8). How-ever, we believe that PERSPECTIVES provides a simpleand cost-effective way to improve the attack resistance ofservices that currently either use Trust-on-first-use or arecompletely unauthenticated.

3 The Notary Architecture

We now explore how the notary infrastructure provides spa-tial and temporal redundancy to help clients evaluate an un-trusted public key. We defer some implementation detailsuntil Section 7. Notary servers are a coordinated group ofhosts distributed across the Internet. Notary clients are in-tegrated into applications (e.g., an SSH client) and contactnotary servers to download observed key data with whichto make a key-trust decision.

3.1 Notary Administration

We envision a network notary group to be a fixed group ofat least five (but possibly many more) servers located in di-verse network locations. The group may be run by a singleentity, but we design it in a decentralized fashion to alsosupport a cooperative deployment in which universities,ISPs, hosting providers, or other well-known organizationseach contribute one or two nodes.1 Cooperative Internettestbeds like PlanetLab [18] and RON [2] are another at-tractive deployment option. For simplicity we describe asingle notary group, but in practice multiple notary groupscontrolled by different entities could operate in parallel.

Each notary group is organized by a notary author-ity that determines which machines are legitimate no-tary servers. The notary authority has a public/privatekey pair and publishes its public key (KAuthority) using anout-of-band mechanism (e.g., as with Tor, the key couldbe distributed with any software that accesses the notarygroup). To add a notary server X to the system, X’s ownergenerates a public/private key pair and furnishes the pub-lic key KX and its IP address AX to the notary authority.Each day the notary authority publishes a list of notaryserver IP address (Ai) and public key (Ki) pairs to each ofthe notary servers in the systems, along with a signatureS = {Date,(A1,KA1),(A2,KA2), . . . ,(An,KAn)}K−1

Authority. A

client can contact any notary server, download the list, and

1Several existing projects have successfully used a similar decen-tralized deployment model, including the large collection of publiclyavailable traceroute and looking-glass servers [25], the Tor anonymizingnetwork [8], and the NTP Pool’s large set of publicly available networktime sources[16].

Key 1t−start, t−end

Key 2t−start, t−endt−start, t−end

Signature

Service−Type, Service−ID:

A Single Service

Entry in Database

NetworkService

ServerNotary

& DatabaseAccess Code

Query Processing

Other

HTTPS

SSH Observe Public Keyof Network Service

NotaryClient

Policy Code

SSH Client

Query &

and RepliesNotary Queries

Notary Database

Probing Modules

Basic SSH Connection

Figure 2: Schematic of a notary server and SSH client.

validate this signature using KAuthority to receive a fresh listof notary IP addresses and public keys.

3.2 Notary Server Key Monitoring

Notary servers monitor the public key(s) used by a net-work service over time. A notary server provides clientswith an application-independent query interface, but usesapplication-aware probing modules to monitor differenttypes of services (e.g., SSH or HTTPS). A probing moduleobserves keys by connecting to the service and mimickingan ordinary client until it receives the service’s public key,at which point it disconnects.

Each notary server uses a local database to store a ser-vice entry for each monitored service. A service entrycontains all observed key data the notary has recordedwhile monitoring that service over time (see Figure 2).An entry is uniquely identified by the combination of aservice-type, which identifies the protocol used to retrievethe key (e.g., HTTPS)2 and a service-id, which providesthe information necessary to contact the service (e.g., host-name and port). The observation history of each key isstored as one or more key timespans. A key timespan isa start and end timestamp pair (tstart , tend) that indicatesa period of time during which the notary observed onlythat key for the service. When the notary makes a newobservation it updates the corresponding service entry inthe following manner: if the observed key is the same keyobserved during the previous observation, the notary sim-ply updates the tend value of the most recent key timespanto the current time. Otherwise, the notary creates a new

2 A single logical protocol may have multiple service-types (e.g., anSSH2 server can have both RSA and DSA keys).

Notary Protocol:C → N : S = (service-id, service-type)N : (O,{O}K−1

N) = f ind_service_entry(S)

N →C : O,{O}K−1N

Figure 3: The basic notary protocol between a single client(C) and the notary server (N).

key timespan with both tstart and tend set to the current timeand adds this timespan and the new key (if necessary) tothe service entry. If a probe fails to receive a key from theservice, the notary creates or updates a timespan with a“null key” containing no key data.

The notary also stores a cryptographic signature for eachservice entry in the database. Using its private key, thenotary calculates a signature over all data in the serviceentry: the (service-id, service-type), as well as each keyand its associated key timespans. This signature is updatedfollowing each modification of the service entry. Section7 measures the overhead of this simple signature schemeand mentions potential optimizations.

3.3 Querying Notary Servers

The client application contacts the notary whenever it re-ceives a key from a service that does not match an existingentry in its cache. This may occur because the client hasnever contacted the service or because the offered key doesnot match the already cached key for the service.

When contacting an individual notary (Figure 3), theclient specifies a (service-type, service-id) pair. The notaryfinds the corresponding entry in its database and replieswith observed key data consisting of keys and their asso-ciated timespan(s), along with a signature over that datausing the notary’s private key.

The process by which a client queries for and receivesnotary data is described in Figure 4. Recall that a notaryclient learns about all notary servers and their public keysusing a list distributed by the notary authority. The client’skey-trust policy (Section 4) determines n, the number ofnotaries that the client should contact. The client thenrandomly chooses n entries from the list of notaries andqueries these servers in parallel using UDP.3 The queryingprocess is complete once enough notaries have replied forthe client policy to make a trust decision, or when the clientdetermines that all remaining notaries are unreachable(clients implement a simple retransmission strategy). Theclient validates the signature for each response using thatnotary’s public key, discarding any invalid responses.

3 Using the implementation parameters described in Section 7, a1460 byte MTU-sized UDP datagram can hold a notary reply with 44key/timespan pairs. If necessary, multiple UDP packets are used for largereplies to avoid IP fragmentation.

Check-Unauthenticated-Key(s, Ko f f ered)O = {}//all observations for servicesAll-Notaries= load_notary_addresses()Chosen-Notaries= choose_random(n,All-Notaries)foreach x in Chosen-Notaries in parallel

(Ox,{Ox}K−1x

) = contact_notary(x,s)Kx = load_notary_key(x)i f (veri f y_signature(Ox,{Ox}K−1

x,Kx))

O = O∪Oxi f ( ! check_trust_policy(Ko f f ered ,O))

abort_connection()

Figure 4: How a client checks an unauthenticated keyKo f f ered for service s. Details of check_trust_policy() are dis-cussed in Section 4.

4 Notary Client Key-Trust Policies

Once a client has received observed key data from notaryservers, it uses a key-trust policy to accept or reject anoffered key based on this data. Code implementing theclient policy decision examines the offered key and allvalidated observed key data, and may also consider inputssuch as previously cached keys, user security preferences,or even active user input. Upon completion, the clientapplication either accepts the key and continues runningthe protocol or rejects the key and disconnects.

4.1 The Security vs. Availability Trade-off

The SSH model (which includes both Trust-on-first-useand PERSPECTIVES) presents clients making a key-trustdecision with a basic security vs. availability trade-off :faced with an untrusted key, the client can take a securityrisk and accept the key, or be safe and reject the key, at thecost of making the service (at least temporarily) unavail-able. For example, when faced with an unauthenticatedkey, standard Trust-on-first-use makes two different secu-rity vs. availability trade-offs: First, if no key is cached forthe service, Tofu chooses availability at the cost of securityby always accepting the offered key. Second, in the caseof a key conflict, a Tofu application cannot automaticallyaccept the key, so it must favor security over availabilityor prompt the user for help.

Lacking useful information about the key’s validity,Tofu applications are stuck making this inflexible trade-off.In contrast, because PERSPECTIVES provides additionaldata indicating whether a key is likely to be the result ofan attack, it allows application key-trust policies to makesignificantly more intelligent security vs. availability trade-offs.

In this section we explore several variations on clientkey-trust policies. We do not claim that these policies areoptimal (in fact, significantly more nuanced and complexpolicies exist), but rather offer them as evidence that even

simple policies can support a wide range of security vs.availability trade-offs.

4.2 Quorum: A Key-Trust Primitive

Recall that PERSPECTIVES provides security by allowingclients to leverage spatial redundancy (key observationsfrom multiple vantage points) and temporal redundancy(key observations over time). Therefore, the role of aclient policy is to test the spatial and temporal consistencyof the offered key with respect to notary data. To providea framework for reasoning about spatial and temporalconsistency, we introduce threshold parameters thatquantitatively represent these properties.

Definition: For a set of n notary servers, a service S, anda threshold q (0 ≤ q ≤ n) we say that a key K has quorumat time t iff at least q of the n notaries report that K is thekey for S at time t.

Intuitively, for values of q that are large relative to n,a key that has quorum indicates consensus among theobservations made by the all notaries at a single point intime. We use another threshold parameter to extend theconcept of quorum into the temporal realm.

Definition: For a set of n notary servers, a service S, anda quorum threshold of q, a key K has a quorum durationof d at time t iff for all t ′ such that (t−d)≤ t ′ ≤ t the keyK had quorum with threshold q at time t ′.

Quorum duration indicates how long, without interrup-tion, a set of notaries has consistently seen a particularkey.4 Applications can make security vs. availability trade-offs by choosing to accept an untrusted key only if it ex-ceeds a particular quorum duration threshold. Higher qand d thresholds provide more security, but risk reducingavailability by incorrectly rejecting valid keys. For ex-ample, setting q equal to the total number of notaries nprovides the strongest protection against accepting a falsekey, but also means that a single unavailable or compro-mised notary could cause the client to reject a valid key.Similarly, a higher quorum duration threshold d protectsagainst a strong attacker that compromises many pathsfor a significant amount of time, but would also requireclients to reject connections to services that are new orhave recently changed keys.

Next, we consider three examples of how the conceptsof quorum and quorum duration might be used by aPERSPECTIVES client policy.

4 We intentionally do not require that the quorum be comprised of astable set of notaries over the entire duration.

Example Policy: Expert UserSame number of warnings, more useful data.We first consider a client application policy for a “expertuser” who understands the risk of a MitM attack andis familiar with the SSH authentication model. In thiscase, the client always warns the user but also includesconcise summaries of the notary data that help the usermake a better security vs. availability decision. Similar toexisting Tofu client, policy behavior depends on whetherthe offered key conflicts with an existing cache entry.

Case 1: No Server Key CachedIn this case, the user is not necessarily suspicious of thenew key, but she will use observed key data to confirmthat the key is consistent across many notaries and thatthe duration of the key history is commensurate with herexpectation of key age. If quorum duration is satisfied, thepolicy module may supply a message like:

Key seen consistently for the past Z days.

If the key fails to achieve quorum or does not havesufficient quorum duration based on policy parameters,the user might see one of the following warnings:

SUSPECTED ATTACK: Offered key is NOT consistent.

Only X of Y notaries currently see it.

WARNING: Server key has only been seen

consistently for the past Z days.

Case 2: Offered Key Differs from Cached KeyIn this case, the user must distinguish between a legitimateserver key change and a falsely injected key. As in Case 1,the user will be interested in the prevalence and durationof the offered key, since a substantial quorum durationindicates a higher likelihood that the conflicting key is theresult of a legitimate server key change:

Offered key conflicts with cached key, but has

been consistently seen for Z days.

Additionally, because the policy has access to the cachedkey that is currently trusted for the server, the policymight also highlight portions of the key history that castsuspicion on the new key. For example, a warning mightindicate that some notaries are still currently observingthe cached key, suggesting that the server has not actuallychanged its key:

LIKELY ATTACK: Offered key conflicts with

cached key and cached key is still observed

by X of Y notaries!

Interpreting such statements requires little additional work

on the part of the user but provides her with vastly moreinformation than warnings in current Tofu applications likeSSH. In the rare case that such a summary is insufficient,expert users may view all observed key data, similar tohow web browsers optionally display SSL certificates.

Example Policy: Non-Expert User 1Same number of warnings, varied severity.Because non-expert users are unlikely to want or be ableto make good security decisions based on the notary dataitself, another policy approach is use a quorum durationtest to determine how severe of a warning to give theuser. For example, a simple approach would be to giveusers a standard warning as long as three-quarters of thenotary servers have seen the key for at least a day (i.e., q =0.75 ·n and d > 1 day), but give them a more severe andintrusive “security failure” warning if notary data detects akey inconsistency indicating a probable attack. .

For HTTPS the need for such a policy to distinguishlikely attacks from valid self-signed replies is increasinglyevident, as new versions of two major browsers (InternetExplorer 7 and Firefox 3) have introduced new userinterfaces that treating self-signed certificates as failuresby default. Rather than simply displaying a warningdialog, the new interfaces do not render the page at all andinstead display an error page similar to a failed connection.

Example Policy: Non-Power User 2Fewer warnings, based on high-level preferences.Much usability research suggests that web users oftenmake bad security decisions by ignoring warnings [21, 10].Instead of using quorum duration to determine the severityof a warning, a client could choose to issue no warning atall if an offered key has sufficient quorum duration. Theprecise values for q and d may be determined by high-leveluser preferences for “high security” or ”medium security”already common in browsers today.

While the merits of this approach is ultimately a usabil-ity question, this tactic may help reduce “banner blind-ness” associated with browser security warnings. As anadditional benefit, this approach could increase overalladoption of HTTPS by eliminating the frequent securitydialogs that likely make some website owners hesitant touse self-signed certificates at all.

5 Detecting Malicious NotariesThe final aspect of the notary design is data redundancy,a cross-validation mechanism that limits the power of acompromised or otherwise malicious notary server.

To implement data redundancy each notary acts as ashadow server for several other notaries. As describedbelow, a shadow server stores an immutable record of eachobservation made by another notary. Whenever a client

receives a query reply from a notary, the client also checkswith one or more of that notary’s shadow servers to makesure that the notary reply is consistent with the historystored by the shadow server.

5.1 Benefits of Data RedundancyAn adversary in control of a notary and its correspondingprivate key can provide clients with false observed keydata. Data redundancy prevents a notary from changingdata already recorded in its observation history, much asschemes such as forward-secure signatures [3] do. As aresult, an attacker that compromises a notary cannot, forexample, create a new malicious key and falsely claimthat this key has been stably seen over a long period oftime. This cross-validation ensures that the only way anadversary can make a malicious key appear “stable” is bysustaining a network attack for a commensurate amount oftime, even with notary compromises. Additionally, data re-dundancy guarantees that a notary, even after compromise,cannot give conflicting answers to two clients queryingabout the same service. This property (which cannot beachieved using forward-secure signatures) could help hostsscan for and detect notaries that act maliciously.

5.2 Cross-Validation ProtocolEach entry in the list published by the notary authority alsolists MAX-REDUNDANCY other notaries that each actas a shadow server for the notary specified in the entry. Anotary server is responsible for keeping all of its shadowservers up-to-date. When a notary server contacts a serviceS, it updates its local database and then sends the newservice entry (including signature) to each of its shadows.5

Shadow servers update their shadow copies in a way thatprevents malicious notaries from eliminating previouslyshadowed data. To do so, the shadow server requires thateach key timespan in the old shadow copy either also existsin the new shadow copy or is “contained” within a largertimespan in the new copy (i.e., both timespans have iden-tical tstart values, but the new copy’s tend value is greaterthan that of the old copy). Additionally, no timespans inthe new copy can overlap. If the old and new data areconsistent, the old data is discarded. If an inconsistencyexists, the shadow server stores both sets of observed keydata and signatures. After updating, the shadow serveruses its own private key to generate a signature over boththe shadowed data and the signature of the other notary.This signature is stored with the shadowed data and allowsclients to authenticate that a reply to a shadow requestcame from the correct shadow server.

Client policy specifies r (r ≤ MAX-REDUNDANCY),the number of shadow servers that must corroborate a

5Client consistency checks are specifically designed so that a mali-cious notary does not benefit by failing to keep its shadows up to date.

Cross-Validation Protocol:C → SH : N,sSH : DBn = get_replica_databse(N)SH : ON , {ON}K−1

N, {ON ,{ON}K−1

N}K−1

SH

= f ind_service_entry(DBN ,s)SH →C : ON , {ON}K−1

N, {ON ,{ON}K−1

N}K−1

SH

Figure 5: A client (C) contacting shadow server (SH) for ashadow copy of notary N’s observed key data for service s.Note that the integrity of N’s service entry is protected intransit by a signature using the shadow server’s key.

notary’s observation for it to be deemed valid. For eachnotary N the client contacts, it randomly selects rq (rq ≥ r)of N’s shadow servers to query. When contacting a shadowserver (Figure 5), the client specifies the IP address of Nas well as the service-id from the original query to N. Theshadow server replies with a service entry (observed keydata and signature) created by N, along with the shadowserver’s signature over that data. If fewer than r of N’sshadows provide valid responses signed by Kn, the clientdisregards all data from N. After verifying the signatures,any inconsistencies among the original and shadowed datawill cause the client to reject data from N. Additionally,because of non-repudiation, clients can provide any in-consistent data and signatures to the notary authority asevidence of a notary’s malicious behavior.

6 PERSPECTIVES Security Analysis

To demonstrate the benefits of network notaries, in thissection we enumerate realistic attack scenarios andcompare the security provided by PERSPECTIVES to thatoffered by basic Trust-on-first-use. We analyze both anadversary’s ability to launch a MitM attack, as well as itsability to deny availability (DoS) by causing a client toreject a valid key.

MitM Attacker Resources:

Our analysis considers three possible system compo-nents which an adversary may control. Enumeratingeach combination of these possible compromises lets usanalyze all scenarios relevant to the attack resistance ofPERSPECTIVES:

Lclient: An adversary controlling the client’s locallink can modify or drop all client-to-serviceand client-to-notary communication.

Lserver: A compromise of the server’s local link letsan attacker inject arbitrary keys when eitherclients or notaries contact the server.

k ·nm: A compromise of k distinct notary servers.

Tofu PERSPECTIVESCompromise DoS MitM DoS MitMLclient 8 8 8 safeLserver 8 8 8 temporal safek ·nm safe safe k > (n - q) : 8

k ≤ (n - q) : safesafe

Lserver +Lclient 8 8 8 temporal safeLclient +k ·nm 8 8 8 k ≥ (q + q · r) : 8

k ≥ q : temporal safek < q : safe

Lserver +k ·nm 8 8 8 k ≥ (q + q · r) : 8k < (q + q · r) : temporal safe

Lserver +Lclient +k ·nm 8 8 8 k ≥ (q + q · r) : 8k < (q + q · r) : temporal safe

Table 1: Summary of attack resistance provided by PERSPECTIVES in comparison to the standard Tofu approach. The leftcolumn contains abbreviated attack descriptions as defined in the text. Columns show resistance to availability (DoS) andMitM attacks. 8 indicates no resistance, “safe” indicates that attacks are detected, and “temporal safe” indicates temporalsafety, as defined below.

As discussed earlier, Lclient is a likely attack, due tothe prevalence of open wifi hotspots and insecure homenetworks that allow compromised hosts or home routersto easily inject or modify traffic. In contrast, servers oftenreside in more controlled network environments, makingLserver significantly harder. This is particularly true in thecase of HTTPS. Thus, to achieve Lserver, an adversarymight compromise the gateway router for the destination,or use BGP to falsely announce the destination’s prefix,misdirecting some or all traffic destined for the server. Anattacker may also control arbitrary Internet routers thatplace it on k of the n notary-to-service paths. However,because this attacker is a strictly weaker version ofthe k ·nm attacker, we do not examine it separately.Additionally, since Lclient or Lserver allows the attacker tomount a trivial DoS attack in either scenario, we do notexplicitly mention this attack below.

Analysis Parameters:

As described in Section 4, the actual security andavailability that a client will receive depends on its choicefor the following policy parameters:

n: Number of notary servers contacted by theclient.

q: Quorum threshold of client.r: Number of shadow servers (per notary) the

client requires for data redundancy.

We do not directly model the length of an attack or aclient’s quorum duration. Instead, we use the concept of“temporal safety”, which means that a client will be safe aslong as its quorum duration threshold is larger than the ac-

tual duration of the attack.6 Table 1 summarizes the results.

Analysis Results:

Lclient Compromise: When only the client’s access linkis compromised, Tofu provides no defense against a MitMattack, while data from network notaries allows a client toeasily detect and avoid the same attack.

It is important to recognize that the attacker gains noMitM advantage by using Lclient to disrupt client-to-notarycommunication. All data returned by a notary is protectedby a signature from that same notary, meaning that notaryresponses cannot be spoofed, even if the attacker hascompromised other notaries. Furthermore, adversariescannot encourage acceptance of a false key by makingnotaries or shadow servers unreachable, since blockingsuch communication will prevent any key (includinga malicious one) from achieving quorum. Maliciouslydropping client-to-notary communication to prevent alegitimate key from achieving quorum does not increaseattacker power, since control over Lclient already allowsfor a trivial DoS attack by simply dropping all packets.

Lserver Compromise: A compromise of only the serverlink also renders a basic Tofu client vulnerable to MitMattacks. For PERSPECTIVES, the compromise of all pathsto the server will prevent spatial diversity alone fromdetecting an attack. However, historical key data providesa client with temporal safety against network attacks.

6Additionally, to simplify our analysis, we assume a sufficiently largenumber of notary servers such that no overlap exists among the q notaryservers and the q · r shadow servers used by a client. A set of notariesthat is too small to satisfy this assumption would reduce the number ofcompromised notaries needed to undermine data redundancy.

k ·nm Compromise: The compromise of notaries alonewill not enable an adversary to inject a false key to theclient and launch a MitM attack. However, this adversarycan attack availability by trying to cause a client toincorrectly reject a valid key. Disabling k > n - q notaryservers, either by compromising them or by makingthem unreachable, prevents the client from establishinga quorum even if the remaining servers all agree on thevalid public key. Because this attack is possible even if theadversary is not on the client-to-service path, it representsan availability vulnerability that does not exist with theTofu approach. However, this attack is limited to scenarioswhen clients receive a new key for a service; it does notapply to repeated connections between a client and aserver using a cached key.

Lclient + Lserver Compromise: The analysis of thisscenario is identical to Lserver, since, as discussed above,using Lclient to restrict client access to notary serversprovides no attack benefits.

Lclient + k ·nm Compromise: Control over the clientlink and some notary nodes lets the attacker use notariesto “promote” an invalid key using false observations.An attacker cannot perform a MitM attack unless itcompromises a full quorum q of notaries, since theclient rejects keys that do not achieve quorum. If anattacker compromises q notary servers, the situation isidentical to the Lserver scenario described above: theclient is still protected for a time period determined by itsquorum-duration. However, if the adversary compromisesan additional q · r notaries beyond the basic quorum, itcan overcome the data redundancy of the system. Withoutdata redundancy the attacker can forge the observationhistory, eliminating the protections of temporal safety. 7

Lserver +k ·nm Compromise: This attack is stronger thanthe previous Lclient + k ·nm scenario, since control overthe destination service’s link means that even legitimatenotaries will observe the attacker’s key. As a result, evenif fewer than q notaries are compromised, the client reliesentirely on temporal safety.

Lserver + Lclient + k ·nm Compromise: This scenario isidentical to the previous attack. As described in theLserver +Lclient case, client link access grants no additionalpower if an adversary already has server link access.This attack analysis demonstrates that PERSPECTIVES sig-nificantly improves resistance to MitM attacks comparedto Tofu. Additionally, PERSPECTIVES is robust to limitedcompromises of the notary infrastructure itself.

7We note that this is a worst-case analysis. If the client selects notariesrandomly and the total number of available notaries is larger than (n + n ·r), the attacker cannot easily predict which notaries or shadows it mustcompromise in order to mislead the client.

7 Experience with Notary Serverand Client Implementations

To demonstrate the viability of a network notaries and togain experience with its deployment, we have implementedand are running a publicly available network notary on theRON testbed [23]. Additionally, we have created two dif-ferent PERSPECTIVES clients: a modified version of theOpenSSH client for SSH and an extension to the MozillaFirefox browser for use with HTTPS certificates. We havemade both server and client source code publicly availableat: http://www.cs.cmu.edu/~perspectives/.Our performance measurements indicate that a single no-tary server can monitor several million hosts a day whilesimultaneously handling a large number of client queries.

7.1 Notary Server Implementation

Our notary server code is written in C and uses the Berke-ley DB library for storing observed key data and signatures.The notary probes services running either SSL or SSH us-ing probing modules based on code from OpenSSL andOpenSSH. The only substantial difference between ourimplementation and the design described in Section 3 isthat we do not implement data redundancy, in part becauseour notary deployment is run by a single trusted entity.

We benchmarked our notary server with respect to ser-vice monitoring and query response operations to demon-strate that network notaries are practical on commonplacehardware. In our implementation, notaries use 1369-bitRSA keys for service entry signatures8 and store publickeys as 128-bit MD5 fingerprints.9

We run our each benchmark on two different machines.One is a modern server (ServerFast) with two dual-core2 GHz AMD Opteron CPUs and 8 GB of RAM. Theother server (ServerSlow) is a three year old machine witha single-core P4 2.4GHz CPU and 512 MB of RAM,intended to demonstrate that a modest notary infrastructurecould still be run on older (perhaps donated) hardware. Asummary of the results is provided in Table 2.

Monitoring Load: To benchmark notary monitoring, weidentified a set of .com domains running HTTPS usinga web-crawl and had our notary server monitor thesesites (Our SSH scans exhibited nearly identical rates andare therefore omitted). When monitoring a service, thenotary must perform the protocol negotiation necessaryto retrieve the service’s key, load the existing service

8 Notary signatures covering observed key data do not need long-termsecurity, as signatures are recomputed frequently and notary keys areeasily updated. 1369-bit RSA is deemed secure through 2010[14]. OnlyKAuthority needs long-term security (e.g., 2048 bits) to enable key rollover.

9While MD5 collision resistance has been compromised, the securityof public key fingerprints depends instead on second pre-image collisionresistance, which is still considered secure for MD5.

Operation Operations / Sec

ServerSlow ServerFastMonitor service key 26 195Monitor service key (no sig.) 112 270Handle query (in memory) 21,700 25,600Handle query (disk-bound) 114 -

Table 2: Summary of notary server benchmarks for ma-chines ServerSlow and ServerFast .

entry from the database, update the entry, recompute theentry’s signature, and store the entry again. Our code usesRSA signatures implemented in OpenSSL and takes thesimple (albeit heavyweight) approach of forking a processrunning a slightly modified OpenSSH or OpenSSL clientfor each probe.10 ServerFast and ServerSlow performs195 and 26 such operations per second, respectively.While these rates may seem small, even at only 50%utilization they correspond to 8.4 million and 1.1 millionprobes per day. Table 2 also shows monitoring rates whensignatures are not computed, indicating that optimizingthe cryptographic processing by batching service recordsor creating a hash-tree over multiple service entries wouldsignificantly improve performance.

Query Handling Load: The primary consideration forquery processing performance is whether the notary’sdatabases fit in memory (recall that a notary may have mul-tiple databases due to shadowing). With the cryptographicparameters described above, a single service entry withseveral keys and timespans will consume approximately250 bytes. Thus, a database with one million entries (250MB) can easily fit even in the small memory of ServerSlow.Table 2 shows benchmarks for both servers responding torandomized client queries (measured over the loop-backinterface). If the database is in memory, the response rateis above 20,000 requests/sec for both servers (because ourserver code is single-threaded, there is little differencebetween the two machines). To identify likely responserates when the database must be accessed from disk, wetested ServerSlow with a database that was four times thesize of its main memory. In this case, the speed of adisk-seek limits the response rate to 114 queries/second.However, even this query-processing rate (which translatesto just under 10 million per day) may be viable whenclients contact notaries only on rare cache misses.11

Bandwidth Requirements: Bandwidth usage depends on

10OpenSSH’s key-scan utility served as our initial SSH scanner, but itexhibited bugs that caused us to discontinue its use.

11This disk-bound query-handling does not significantly contend withthe CPU-bound service monitoring, meaning that their respective ratesare unlikely to diminish significantly when both are run simultaneously.

both the monitoring rate and query rate. Including allnetwork headers and TCP acknowledgments, monitoringa single SSH service requires about 1.5 KB of upstreambandwidth and 2.3 KB of downstream bandwidth. ForSSL the same values are 0.5 KB and 2.0 KB. Such datasizes are comparable to a single small image embeddedin a webpage. Monitoring a million hosts a day wouldcorrespond to an average rate of less than 213 Kb/s ineach direction. With network headers, notary requestsare approximately 60 bytes and replies are 315 bytes (forstandard key sizes). While handling a flood of 20,000requests per second would require 50 Mb/s of upstreambandwidth, a server could handle 10 million requests a day(116 requests per second) using only 420 Kb/s.

Because we expect notary nodes to be deployed pri-marily by universities and large companies like ISPs orwebhosting providers, we do not expect bandwidth to be alimiting factor unless a server is under DoS attack.

7.2 Notary Client ImplementationsTo demonstrate the general nature of the PERSPECTIVESapproach, we created two client implementations thataccess our notary group. Both clients share commonlibrary code that reads notary configurations, creates andparses protocol messages and implements basic quorumduration policies. As a result, we expect that porting otherclients to work with PERSPECTIVES will not be difficult.

OpenSSH Client: We modified the popularOpenSSH [17] client software to contact notaryservers when no cached key exists or when the offered keydiffers from the cached key. The modifications consistedof a few library calls within the SSH code that checks thekey cache, as well as functionality to interact with theuser when making a key-trust decision (our client roughlyfollows the expert user example described in Section 4).We have used the modified client within our universityfor nearly a year and have found the added latency ofcontacting notary servers to be negligible.

Mozilla Firefox HTTPS Client: We implemented our no-tary client for HTTPS within the Mozilla Firefox extensionframework, meaning that users can easily install it withouthaving to download a new browser. The HTTPS notaryextension (Figure 6) is written in a combination of C++and javascript. Whenever a certificate validation fails, thenotary client extracts the public key from the certificateand contacts the notaries.

Our implementation allows users to set a preference for“High Security” or “Medium Security”, which correspondto different quorum duration thresholds. Keys that achievequorum duration are accepted automatically, while otherkeys result in disconnection with an error message. The“High Availability” security setting gives expert users the

Figure 6: This screen capture shows the bottom right-handcorner of a Firefox browser window, which contains theHTTPS notary extension’s visual indicator. In this case, thewebsite satisfied quorum duration, so the browser automat-ically accepted the certificate and suppressed the certificatewarnings usually displayed to the user. The image also showsthe tool-tip that summarizes the notary data for the user.

ability to connect even when a key does not achieve quo-rum duration. These users are provided with the certificateand a summary of notary data in order to make their ownkey-trust decision.

Because use of our OpenSSH and Firefox clients iscurrently limited to the Linux and FreeBSD/Mac OS Xplatforms, we also provide a web page that allows users toquery notary servers even without a modified client.

7.3 Generating a List of Services to Monitor

Section 3 assumes a priori knowledge of what services thenotary server should periodically monitor. We considertwo possibilities for how notaries might build this list.

The first approach, which we use in our implementation,is for a notary to add a service to its database the first time aclient queries for it. While this approach does not initiallyprovide clients with temporal redundancy, when bootstrap-ping the system, notaries might probe “on-demand” toprovide even the first client with spatial redundancy tohelp detect Lclient attacks. A client could seed the notarywith services (e.g., from the known_hosts file in SSH)and a server could register for monitoring by querying anotary with its own address as the service-id.

The second approach is to proactively discover services.For example, HTTPS websites can be found using webcrawling or search engines. For less public services, suchas SSH, TCP-layer scanning on standard protocol portscould discover a large number of services. We built onesuch scanning engine to evaluate this approach on SSHservers within our campus network and a few large publicIP blocks. We found that while scanning can quicklyidentify tens of thousands of SSH servers, it has three keylimitations. First, if reverse DNS is unavailable for an IPaddress, we cannot reference a service entry in terms ofthe DNS name. Second, such scanning misses servicesrunning on non-standard ports. Finally, scanning maybe misinterpreted as an attack. Because active discoverycannot identify all services, one promising approach is toseed notaries with data from active discovery, and thenidentify additional services as clients query for them.

7.4 Notary Parameters

We now outline the primary considerations for choosing anotary group’s global parameters.

Number of Notaries: Because MitM attacks are mostlikely at the network edge (i.e., Lclient or Lserver),increasing spatial redundancy is likely to have diminishingreturns: in the case of Lclient, even a few valid notarieswill detect an attack, while for Lserver, all notaries willsee the same false key. We therefore suggest that clientsquery from 4 to 10 notaries, depending on their desiredrobustness to notary compromises or failures.

Notary Monitoring Frequency: A notary would like tominimize the time between when a server first comesonline or changes its public key and when the notaryserver observes this change. Our measurements indicatethat a single notary could monitor several million differentservers a few times each day.

Degree of Data Redundancy: The degree of data redun-dancy required for a set of notaries depends greatly onwho administers individual notary nodes. If nodes are runby one or a few trusted entities that take great care to se-cure the machines, little or no data redundancy may beneeded. However, even when data redundancy is needed,MAX-REDUNDANCY can likely be small (2 to 4), be-cause clients can detect inconsistencies if any one of thecontacted shadow servers are not compromised.

8 Discussion

Notaries and DNS Attacks: So far, we have focusedon adversaries that compromise IP-level paths or notaryservers. Adversaries could also manipulate DNS to falselymap a service’s hostname to an IP address that places theadversary “on path”. When notaries and clients use DNSnames to identify services, a compromised local or remoteDNS server present the same threat as the correspondingLclient or Lserver attack. Thus, the analysis in Section 6applies to DNS attacks as well.

Additionally, if an attacker controls only DNS, notariescan help clients detect and even circumvent such attacks.To do so, notaries would also record the IP address usedwhen monitoring a service. If a client sees that both theservice key and IP have changed from a previously trustedor stable key, it can connect directly to the IP addressesassociated with the old key to test if that key is still visibleon the network. If the client receives the prior key fromany of the past addresses, it can (depending on localpolicy) disregard the new key as a DNS attack and instead

connect directly to the address using the prior key.12

Client Privacy Considerations: While benign notaryservers would not record a client’s IP address, a maliciousnotary could link client addresses and destination services,impinging on client privacy. Because clients access the no-tary group only rarely (when the offered key is not cached)and do so only when a legitimate security threat exists,we believe that most clients will consider this potentialprivacy risk acceptable.

However, clients that desire additional privacy couldcontact the notary group through a proxy. One promisingdesign for such a proxy is to have the notary authorityrun a DNS nameserver for a special notary domain(e.g., notary.com). A notary client looking for observedkey data for server.domain.com from num-notarydifferent servers would perform a DNS look-up for num-notary.server.domain.com.notary.com.13 The nameserverfor notary.com would then randomly query num-notaryservers and return the base64-encoded results as a DNSTXT record. Because of the recursive nature of DNSlook-ups, the notary nameserver would learn only generalinformation about the client (e.g., that they use CMU’sDNS servers), and the rest of the notaries would learnno client-specific information. Clients are unlikely tohave privacy concerns about notary queries via local DNSresolvers, since they already expose basic connectioninformation to the resolver with standard DNS look-ups.

Detecting Authentication Downgrade Attacks: Ourprimary motivation for designing PERSPECTIVES wasto help authenticate services that do not have certificatessigned by a global PKI. However, users can also benefitfrom using PERSPECTIVES even when accessing websiteswith PKI-signed certificate by gaining protection againstauthentication downgrade attacks. In an authenticationdowngrade attack, a MitM adversary injects a self-signedcertificate in place of the PKI-signed certificate sent bythe legitimate server. Because the attacker can spooflegitimate names in the domain name and issuer fields, thesignificant number of users who routinely ignore manybrowser security warnings [21, 10] would fall victim tosuch an attack. In fact, a malicious exit-node in the Toranonymizing network was recently observed runningsuch an attack [24]. However, if notaries also monitorservices with PKI-signed certificates, clients could detectthis attack by comparing the received certificate againstthe notary replies. This same approach would also helpprevent the even more damaging attack in which an

12 Adding IP addresses to the observed key data returned by a notaryalso helps clients handle cases when DNS-based load-balancing maps asingle hostname to different machines that each have their own key.

13A similar DNS trick is used by the popular Coral Cache contentdistribution network [11]. Using a TTL of 0 and appending randomdata to the beginning of the DNS name can prevent DNS caching fromproviding stale data.

attacker tricks one of the many root CAs trusted by abrowser into signing an invalid certificate.14

On-demand Service Monitoring: A slightly modifiednotary design could allow clients to request that notariesprobe a service “on-demand”, for example, when theclient’s offered key does not match the most recent entryin the notary history. Depending on client policy, this ap-proach could reduce the likelihood that a client incorrectlyrejects a key following a legitimate server key change.However, because the notary must cryptographically signthe each new probe result, it would be more vulnerable toDoS attacks. In light of this and other potential abuses,on-demand probing is best suited for either a privatenotary group with limited access or a public notary groupaugmented with a strong rate-limiting mechanism likeclient puzzles [13].

Scaling the Notary Infrastructure: Our design and im-plementation focuses on a notary infrastructure that iseasily deployed and capable of regularly monitoring sev-eral million unique services. If PERSPECTIVES is widelyadopted as a standard host authentication mechanism, itcan easily scale. First, note that notary replies are simplystatic data, which could be made available via a content de-livery network (e.g., Akamai) or a network storage service(e.g., Amazon’s S3). The physical location or ownershipof these machines would be unrelated to the hosts generat-ing observed key data. Because monitoring and updatingobserved key data is trivially parallelizable, this work canbe distributed to a cluster of machines in each notary lo-cation. Trends toward many-core machines should furtherimprove the efficiency of service monitoring.

9 Related WorkSignificant work exists on the problem of authenticating re-mote Internet hosts. Standard solutions include X.509 cer-tificates within a global PKI [5], or Kerberos [15], whichassumes that each participant has a shared secret with atrusted third party. Such solutions are extremely useful,but the popularity of the SSH model demonstrates the needfor lightweight alternatives.

Ali and Smith [1] propose improving SSH key authenti-cation using a “portable key cache”, which the user storesalong with an authenticating MAC on a personal webserver.With a modified SSH client, the user can access this cachefrom any machine, use a passphrase to verify the integrityof its contents, and then compare the offered key to entriesin the cache. This design helps users who would otherwisesee the same new or changed key warning several times

14 To accommodate legitimate key turnover, the site owner can signthe new public key using the older key that is already recognized as validby the notaries.

when connecting to the same server(s) from multiple clientmachines. However, unlike PERSPECTIVES, it providesno help in determining a key’s validity when a user eitheraccesses a service for the first time or when an offered keydoes not match the key in the user’s portable cache.

Advocating a more significant departure from the stan-dard SSH authentication model, RFC 4255 [22] proposesstoring SSH host key fingerprints in DNS. Unfortunately,this proposal relies on the deployment of the secure DNSPKI to authenticate the fingerprint data itself, and secureDNS has shown little traction to date. Additionally, theproposal requires that a domain’s DNS administrator ful-fill the responsibilities of a certificate authority: verifyingthat a real-world entity who contacts him with a certificaterequest legitimately owns a particular host. In contrast,PERSPECTIVES requires no heavyweight verification andinstead automatically creates authentication data usingprobes.

ConfiDNS [19] suggests performing DNS look-upsfrom diverse network vantage points. However, the pri-mary focus of the ConfiDNS work was dealing with thefact that DNS replies (unlike public keys used in PERSPEC-TIVES) frequently have legitimate inconsistencies due tofactors like DNS load-balancing. Additionally, becausethe system was designed to avoid pollution in cooperativeDNS systems, the design only protects against a maliciousor failed local DNS server, not an “on path” adversary(e.g., Lclient) launching a MitM attack.

Web tripwires [20] are javascript verification functionsembedded by a webserver in HTTP responses to performclient-side detection of in-flight data modification. Whilelightweight, tripwires are not robust to adversaries, whichcan remove the tripwire code from the HTTP response tothwart detection.

Notary client policies bear some similarity to clientbehavior in the “web-of-trust” model used by Pretty-Good-Privacy (PGP) [4], a decentralized PKI for email. However,because PGP uses human contact to bind entities to keys,its primary challenge is estimating the strength of key trustchains that include multiple links, each representing a pairof real-world acquaintances. PERSPECTIVES policies donot have trust chains (each notary probes a service directly),but do have other complexities not seen in PGP, includingthe temporal nature of key histories.

The concept of building a “lightweight PKI” based onthe normal operation of the network was also proposedin the context of securing BGP routing. A “GrassrootsPKI” [12] binds a public key to a prefix of IP addressspace if that key is included in a stable and widely usedrouting announcement for that prefix.

10 Future WorkWe believe that the network notary concept introducedby PERSPECTIVES opens several promising avenuesfor additional exploration in the area of host authentication.

Notary-Aware Services: As presented, PERSPECTIVESonly requires client modifications. However, if notariesbecome common, servers might be modified to also com-municate with notaries. This would provide three primarybenefits:

1. Immediate Probing of New Keys: A server couldimmediately alert notaries when it comes online orchanges its key, allowing notaries to quickly beginbuilding an observation history for the new key.

2. Reduced Need to Query Notaries: The server couldact as a caching proxy by querying notaries on behalfof clients. This would eliminate privacy issues relatedto clients querying notaries directly and would alsoallow clients to receive cached observed key data evenif notaries were temporarily unavailable.

3. Attack Detection: With access to the notary infras-tructure, a server could request observed key data forits own service-id and alert its administrator if thenotary replies include any illegitimate keys. Such afalse key is a likely indication that either a networkelement near the server is malicious or that a notaryis compromised, thereby aiding attack detection.

Unlike standard PKIs, these changes do not requireserver owners to manually prove their identity to athird-party CA, making them simple to adopt.

Applying PERSPECTIVES to Additional Protocols:PERSPECTIVES opens the door for more widespread useof SSH-style authentication with other protocols because,unlike Tofu, use of key-trust policies can automaticallyauthenticate keys in a secure fashion, even on the firstconnection to a service.

SMTP: Many SMTP servers already have self-signedSSL certificates so that local clients who manually installthese certificates can authenticate their outgoing mailserver. However, because no PKI exists for one serverto verify another server’s certificate, emails are oftentransmitted “in-the-clear,” leaving them vulnerable tosnooping by whomever controls the intermediate networks.PERSPECTIVES could support mutual authenticationof inter-SMTP server communication, allowing, forexample, a server to refuse to transmit a message theuser has deemed “sensitive” to an unauthenticated server.15

Incremental DNSSEC: The deployment of secure DNS(DNSSEC) is hampered by the fact that a sub-domain (e.g.,

15DomainKeys [6] could also benefit from PERSPECTIVES, as keysare currently acquired using unauthenticated DNS look-ups.

example.com) cannot protect its hosts until its parent do-main (e.g., .com) publishes its own public key and signsthe sub-domain’s public key. Unfortunately, to date, ma-jor top-level domains have shown little enthusiasm fordeploying DNSSEC. With PERSPECTIVES, the authori-tative nameserver for any sub-domain could publish anun-signed key used to sign its zone, with resolving nameservers using notaries to validate key prior to caching.

11 Conclusion

As evidenced by its widespread use, SSH-style host au-thentication offers a simple and attractive alternative toa heavyweight PKI. Unfortunately, “Trust-on-first-use”leaves users vulnerable to simple MitM attacks, limitingthe effectiveness of current Tofu applications and prevent-ing other protocols from being able to take advantage oflightweight SSH-style host authentication. To enhancesecurity without requiring a PKI, we designed PERSPEC-TIVES to supplement Tofu-based applications with spatialand temporal redundancy. Our implementation demon-strates that the notary concept is practical, and after usingour PERSPECTIVES clients for nearly a year, we havefound them invaluable at several occasions: when loggingin to a new server while connecting through a public wire-less network, or when connecting to a known server aftera server key change. As a result, we believe that PERSPEC-TIVES is a practical approach to improving the security ofusers communicating with SSH and self-signed HTTPS.

AcknowledgmentsDan Wendlandt was supported by a graduate fellowshipfrom the Dept. of Homeland Security and an award fromthe ARCS Foundation. This research was supported inpart by CyLab at Carnegie Mellon under grant DAAD19-02-1-0389 from the Army Research Office, grants CCF-0424422 and CNS-0716278 from the National ScienceFoundation, and a Sloan Foundation faculty fellowship.The views contained here are those of the authors and donot necessarily represent the official policies or endorse-ments of ARO, CMU, NSF, or the U.S. Government. Wethank Bryan Parno, Himabindu Pucha, and our many re-viewers for useful comments. Special thanks to RamuPanayappan for developing the Perspectives extension forFirefox.

References[1] Y. Ali and S. Smith. Flexible and scalable public key security for

SSH. In EuroPKI, pages 43–56, 2004.[2] D. G. Andersen, H. Balakrishnan, M. F. Kaashoek, and R. Morris.

Experience with an Evolving Overlay Network Testbed. ACMComputer Communications Review, 33(3):13–19, July 2003.

[3] M. Bellare and S. K. Miner. A forward-secure digital signaturescheme. Lecture Notes in Computer Science, 1666:431–448, 1999.

[4] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer.OpenPGP Message Format. Internet Engineering Task Force, Nov.2007. RFC 4880.

[5] S. Chokhani and W. Ford. Internet X.509 Public Key InfrastructureCertificate Policy and Certification Practices Framework. InternetEngineering Task Force, 1999. RFC 2527.

[6] M. Delany. Domain-based Email Authentication Using Public KeysAdvertised in the DNS (DomainKeys), Aug. 2004.

[7] W. Diffie, P. C. van Oorschot, and M. J. Wiener. Authentication andauthenticated key exchanges. Designs, Codes and Cryptography,pages 107–125, 1992.

[8] R. Dingledine, N. Mathewson, and P. Syverson. Tor: The second-generation onion router. In Proc. 13th USENIX Security Symposium,Aug. 2004.

[9] Drive-by Pharming. Symantec security response weblog: Drive-by pharming in the wild. http://www.symantec.com/enterprise/security_response/weblog/2008/01/driveby_pharming_in_the_wild.html.

[10] S. Egelman, L. F. Cranor, and J. Hong. You’ve been warned:An empirical study of the effectiveness of web browser phishingwarnings. In Proceedings of the SIGCHI conference on Humanfactors in computing systems (CHI ’08), 2008.

[11] M. Freedman, E. Freudenthal, and D. Mazieres. Democratizing con-tent publication with Coral. In Proceedings of the 4th USENIX Sym-posium on Network Systems Design and Implementation (NSDI),2004.

[12] Y.-C. Hu, D. McGrew, A. Perrig, B. Weis, and D. Wendlandt.(R)Evolutionary bootstrapping of a global PKI for securing BGP.In Proc. 5th ACM Workshop on Hot Topics in Networks (Hotnets-V),Nov. 2006.

[13] A. Juels and J. Brainard. Client puzzles: A cryptographic counter-measure against connection depletion attacks. In Symposium onNetwork and Distributed Systems Security (NDSS ’99), Feb. 1999.

[14] A. Lenstra and E. Verheul. Selecting cryptographic key sizes.Journal of Cryptology, 14(4):255–293, 2001.

[15] S. Miller, B. Neuman, J. Schiller, and J. Saltzer. Kerberos authenti-cation and authorization system. Technical report, MIT, Oct. 1988.Project Athena Technical Plan.

[16] NTP-Pool. pool.ntp.org : the Internet cluster of NTP servers. http://www.pool.ntp.org.

[17] OpenSSH. http://www.openssh.com.[18] L. Peterson, T. Anderson, D. Culler, and T. Roscoe. A blueprint

for introducing disruptive technology into the Internet. In Proc. 1stACM Workshop on Hot Topics in Networks (Hotnets-I), Oct. 2002.

[19] L. Poole and V. S. Pai. ConfiDNS: Leveraging scale and history toimprove DNS security. In Proceedings of Third Workshop on Real,Large Distributed Systems (WORLDS), November 2006.

[20] C. Reis, S. D. Gribble, T. Kohno, and N. C. Weaver. Detectingin-flight page changes with web tripwires. 2008.

[21] S. E. Schechter, R. Dhamija, A. Ozment, and I. Fischer. Theemperor’s new security indicators. In SP ’07: Proceedings of the2007 IEEE Symposium on Security and Privacy, 2007.

[22] J. Schlyter and W. Griffin. Using DNS to Securely Publish SecureShell (SSH) Key Fingerprints. Internet Engineering Task Force, Jan.2006. RFC 4255.

[23] The RON/IRIS Testbed. http://www.datapository.net/tb/.[24] Tor Exit Node Hijacks. TOR exit-node doing MITM at-

tacks. http://www.teamfurry.com/wordpress/2007/11/20/tor-exit-node-doing-mitm-attacks.

[25] Traceroute.org. Traceroute.org. http://www.traceroute.org.

[26] W32.Arpiframe. W32.arpiframe. http://http://www.symantec.com/business/security_response/writeup.jsp?docid=2007-061222-0609-99.