Month: August 2008

Identity as externality: Trustbearer, CAC, eID

TrustBearer has become the first public demonstration of an idea this blogger first described in a ThinkWeek paper in 2006: identity management systems create positive externalities. Once built for a purpose, they are often easily extended, adopted or co-opted for completely different objectives. This pattern predates the Web, PKI and even the development of modern computing systems. The classic example is the social security number. Originally introduced by the FDR’s New Deal-era Social Security Administration for the purpose of administering benefits, it has become the de facto identifier for everything from credit rating agencies to some badly designed online banking websites; Fidelity originally used SSN as “username” but later changed the system to allow for choosing nicknames. Drivers licenses were introduced to control who can drive vehicles on public roads. When laws introduced minimum drinking age and imposed penalties for serving to minors, bars found it the natural choice to decide who gets to order drinks. (A bartender in Seattle once declined to server this blogger due to an expired driver’s license.)

Not all of these extensions are necessarily good ideas. In particular the re-purposing of the social security number from a simple identifier into a credential– something that proves identity, never intended in the original design– created  the current identity theft mess. In another example, RFID tags are a primitive identity management system designed for tracking inventory; the tag identifies the object it is attached. But when the tags are not deactivated after they are sold to consumers, they can be repurposed for tracking. Each tag emits a constant identifier that can be scanned by anyone with the appropriate transmitter and receiver set up, allowing tracking of individuals in physical space.

Occasionally unofficial extensions to an identity system provides unexpected benefits. Typically there is a very large upfront investment in deploying a system, driven by a well-defined objective. But once the system is built, adding one more person who can use it, or one more website which uses that system for authentication has a small marginal cost. Take for example the Common Access Card or CAC, soon to be replaced by the PIV. These are both PKI systems managed by the Department of Defense, for the purpose of controlling access to systems with national security implications. But once the PKI deployment is operational, individuals have been issued their cards and smart-card readers, they can be used for purposes completely unrelated to defense sector. Case in point: TrustBearer’s OpenID service accepts CAC/PIV cards for authentication to any OpenID enabled relying site. DoD certainly did not design the system for employees to check their personal email accounts or write blog comments in spare time. But given that the smart-cards were already out there in the hands of users, it was a no-brainer for TrustBearer to accept these credentials for strong authentication. Any other website could have done the same: called “SSL client authentication,” the underlying functionality has been supported by web browsers and web servers in some fashion since the late 1990s. The user interface may be clunky because it is rarely seen outside the enterprise context, but all it takes is tweaking some settings in IIS or Apache. The Department of Defense created a positive externality for all websites.

Design matters of course: some technologies are far more amenable to being re-purposed this way. For example, Kerberos is inherently a closed system: adding another relying party requires coordinating with the people in charge. Public-key infrastructure is open by design: once a digital certificate is issued, people can use it to authenticate anywhere. There are still gotchas: revocation checking imposes costs on the identity provider (adding another relying party is not a free lunch when it is hammering the system with revocation checks) or it may not work at all for an entity “outside” the official scope. Some new protocols such as OCSP stapling address that by making freshness proofs portable. More important is the question of acceptable use policy. Just because the cryptography works out does not mean that the official owner of the identity system will approve the creative re-purposing.

That brings us to the European eID deployments. These are national ID systems, with the cards containing PKI credentials. Here is one case where a PKI based system funded by tax-payer money is built with the express intent that anyone can use it for authentication to their service. (This is what governments do after all– they generate externalities, much to the chagrin of libertarians.) Not surprisingly eID cards are also accepted by TrustBearer– specifically Belgian eID. This is an even greater externality because there are bound to be many more of them in existence even today, and this will only improve over time as other EU governments make progress on their deployment. On the other hand, the precedent for using eID online is scarce and chances are most users lack the required card-readers and drivers, while the CAC/PIV users already use their cards regularly in a professional context.

cemp

Six-and-a-half degrees of seperation

An interesting paper out of MSFT research lends new support to the six-degrees of separation meme.

Quick recap: the idea that on average every individual can be linked to any other by a chain of no more than 5 acquintances in between dates to the work of Stanley Milgram at Stanford in the 1970s. Milgram used an old fashioned communication network: the postal system aka “snail mail.” Subjects in the experiment were asked to deliver letters to individuals they knew only by name and geographic location. Surfer Bob in San Diego might be asked to deliver a letter to investment banker Alice in New York, by forwarding the letter to somebody that he suspects is closer to Alice.  On average letters were passed on six times along the way to their final destination, hence the six-degrees concept which later became a Tony award-winning play on Broadway, later jumping to the big screen with Will Smith before achieving mainstream status as an online game featuring Kevin Bacon. Early part of this decade witnessed a surge of interest in studying so-called “small world graphs” which resulted in the publication of several books that poplarized the concept.

Six-degrees took a major hit in credibility when another researcher discovered in 2006 that 95% of the letters in the Milgram experiment had never reached their intended destination. One possible conclusion was that the social network was in fact, not the connected, small-diameter graph everyone imagined it to be. If 95% of the nodes had no routes between them that would paint a picture of a fragmented, disjoint society reminiscent of high school, broken up into cliques and tribes. Or it could have been that the subjects did not follow through, because sending letters takes up non-trivial amount of time.

Fast forward three decades and instant messaging has drastically lowered the overhead for communication. So the MSR group– which includes the designer of infamous Clippy— looked at the social network formed by users of MSN/Live Messenger. Specifically they studied the social graph implied by 30 billion messages sent among 240 million users in June 2006. If two people exchange messages, they are assumed to know each other. (There are situations when that is not true: for example there are spammers sending IM to random people. Also users may have more than on identity, so individuals do not map uniquely to nodes– this can distort paths because user Alice may be appears as contact on Bob’s personal IM account but not work IM account.) This is a much larger data set than Milgram’s original sample of <200 and crunching that would not have been possible without massive computing power. Finding the shortest-path between two people in a graph is very expensive and requires looking at all connections. There are some optimizations for doing this on all pairs of individuals but it is still a very expensive proposition on such a large dataset.

The result came close to vindicating the original idea: average distance between two IM users was right around 6.5 and 78% of users were seperated by less than seven links. In fact the slightly higher number would be expected because the instant messaging graph has a subset of all real world connections. First not everyone uses the Internet; the digital divide remains very much alive in the US. This has the effect of removing entire nodes from the graph; nodes that could have provided shorter conncetions between people. Similarly not all Internet users have instant messaging. Even two heavy Internet addicts may use different IM networks (one on AIM, the other on GMail for example) because interoperability is still not the norm in this space. The combined effect of these biases is to remove edges from the graph and “inflate” the distances.

cemp

New York Times badly confused on identity management

Goodbye Passwords is that rare misstep form the otherwise consistently solid Digital Domain section in the Sunday NYT: confused, misinformed and way off base. Among the several muddled arguments, four of them stand out:

1. Equating OpenID to passwords.

“OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else’s Web site.”

Minor factual error: actually the password is not being typed into a random website. It is supposed to be provided only to the website where the identity was originally created, not the website where it is being used. But the general difficulty of determining whether one indeed starting at the authentic site instead of a fraudulent replace– especially when the user has been sent there by the “someone else’s Web site” in question leads to the standard critique of OpenID as increasing phishing risks.

Major factual error: OpenID is a federation standard, not a new user authentication approach. It does not mandate passwords or any other scheme for verifying identity. Open ID 2.0 specification is loud and clear on this point:

“Methods of identifying authorized end users and obtaining approval to return an OpenID Authentication assertion are beyond the scope of this specification.”

That means the identity provider can choose to use good old-fashioned passwords, smart-cards, biometrics or experimental approaches such as reading tea-leaves to authenticate the user; OpenID is silent on this. In fact one of the more hyped extensions to the protocol, added at the urging of MSFT which has been desperately trying to promote CardSpace, is a way for signaling to websites that the user authenticated with credentials resistant to phishing— Infocards in the original vision that carved out this niche case, but also more generally strong authentication mechanisms such as PKI capable smart-cards.

2. Narrow definition of single sign-on:

OpenID promotes “Single Sign-On”: with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials.

In the most general sense, single sign-on refers to one identity being valid for accessing multiple systems. This is in contrast to the current state of affairs on the web: most websites have their own notions of user identities, requiring users to create a new account. Each account is valid at exactly one website and not recognized anywhere else. Single sign-on (“federation” using the fashionable term) is about merging these disconnected islands of identity such that the scope of an identity can extend beyond that one site.

Quick peek at the Wikipedia entry would have hinted that SSO is not tied to passwords. So it comes as surprise that a Microsoft architect is quoted as criticizing SSO. Cardspace is an instance of single sign-on: the vision calls for one identity held by the user’s machine to be usable for logging into any number of websites. Inside the enterprise, Active Directory is single sign-on because it allows the same credentials to be used for accessing everything from logging into a workstation with the three-finger salute to accessing email or HR systems.

3. Misconception that “information card” is a generic term-of-art as it relates to identity management. Information card, or infocard to use the original name for the technology before it was rebranded into CardSpace, is a particular proposal that defines specific formats and protocols for identity management. Writing about “the information cards” makes about as much sense as writing about “the Facebooks” and “the Googles.” Each is a specific incarnation of a general concept: a social networking site, a search engine and an identity management protocol.

4. No hint of the history of strong authentication or alternatives. A reader may walk away from this article with the impression no realistic alternatives to passwords existed until Cardspace magically burst on the scene. Basic fact checking would have unearthed some not entirely obscure facts: there is a concept of digital certificates dating back to the 1970s, leveraging the same brew of “hard to break cryptography” whose virtues are extolled in the article. Since late 1990s, digital certificates have been standardized by X509, a stable and widely implemented supported format. It would be a small jump from there to realize that the SSL protocol universally used for securing communications online has provisions for users to verify their identity with digital certificates and that many large organizations, including the United States Department of Defense have been depending on this capability for years.

This is not to say that there are not good points in the article. OpenID is a major distraction and duplication of effort precisely because it is a mediocre reinvention of the wheel, ignoring all the investments made towards deploying PKI on the web compliments of SSL and muddying the waters one more time just when there was a fighting chance that the industry might converge on a standard (SAML, far from perfect as it may be) as the underlying format for identity assertions. But it is a non-sequitur to argue that OpenID is doomed because of its dependence on passwords and inherent problems with single sign-on.

cemp

BlackHat: making the news while reporting it

DefCon attendees always knew that using the wireless network at the conference is living on the dangerous side– even on the rare occasions a few packets managed to route their way across the congested airwaves with thousands competing for the scarce bandwidth. (This blogger has been depending on his Novatel CDMA modem compliments of Sprint to continue writing.) If there is a real-life incarnation of the proverbial “untrusted network” this is it, and The Wall of Sheep has been the favored tradition for publicly embarassing those using weak protocols that transmit credentials in the clear.

This year the tradition expanded to Blackhat, putting attendees– a much different crowd than DefCon, it goes without saying– on notice that their name could be next on the hall of shame.

Journalists had a better deal: they got their own wired, private network in the press room, free from the shenanigans of creative researchers.

It did not work out. As reported by CNet, French journalists decided to step up to plate and impress their colleagues with their “l33t credentials.” Exact details are unclear but it appears that they managed to take control over the router and capture traffic from other journalists. For anyone not using VPN, that included the stories their they were filing. So much for good sportmanship– why bother attending the conference sessions or interviewing speakers when you can “rephrase” your colleagues’ dispatches instead? The French crew were so proud of their achievements that they wanted to get the spoils displayed on the Wall of Sheep. Conference organizers were not impressed by what they viewed as illegal wiretapping and interception. Neither were fellow members of press, when they were briefed on the incident. The proto-hackers were booted off the conference, which was not enough to appease the irate journalists. The reaction reportedly included at least one person from ZDNet going through the roof.

cemp

From 0wning DNS to 0wning SSL (2/2)

But SSL does have an Achilees heel: its trust model is anchored on the digital certificate used by the web server: the only proof that the website you are communicating with Bank of America (as opposed to an impostor in Estonia) is the fact that they have a digital certificate issued by Verisign claiming that this website indeed is http://www.bankofamerica.com.

The fragility of this model has been pointed out before. Verisign is not the only recognized certification authority; out of the box Windows ships with close to 100 CAs, all of them equivalent for trust purposes. Any one of them incorrectly issuing the Bank of America certificate to somebody else is enough to ruin any guarantees provided by the cryptography– it does no good to secure your traffic, when the person at the end of that encrypted channel is the bad guy. (Perhaps the biggest CA goof was Verisign issuing Microsoft code-signing certificate to impostors in 2001. The implications were much worse than for SSL certificates, but revocation has addressed the fall-out for the most part.) While MITM attacks against SSL due to incompetent CA practices have always been possible, the challenge of playing that messenger in between so far made this a low-likelihood attack vector. Owning DNS changes that.

More importantly– and this is Kaminsky’s main point regarding SSL– the certification process itself uses DNS. According to this version of the story, when the proud new owner of the domain http://www.acme.net wants a digital certificate, the CA consults DNS records to verify ownership. They might even ask the user to insert some DNS records or add a particular page to the website, as additional proof. All of these checks are trivially subverted if DNS is corrupt because all of them will be routed to servers controlled by the attacker. This means that while the existing Bank Of America certificate is safe and sound, the enterprising criminal will:

  1. Choose a moderaly incompetent CA
  2. Subvert DNS to confuse name resolution for that CA
  3. Pass the domain ownership checks made by the CA
  4. Obtain a new valid certificate in the name of Bank of America
  5. Subvert DNS resoution for an ISP
  6. MITM all of the users at that ISP by using the perfectly valid certificate from step #4

That, at least is the picture painted in the presentation. The critical details are certification steps used– not just by Verisign, Geotrust and other major CAs but every single one of the dozens of certification authorities recognized by IE and Firefox. Extended validation does not help for two reasons: on the usability front, users pay no attention to all the fancy eye-candy browsers waste on displaying EV status, as demonstrated nicely by The emperor’s new security indicators.. On the the implementation level, the browser grants exactly same privilege to regular certificates; embedded content for example can still be subverted using a vanilla cert while keeping the main page over EV.

If this attack does indeed work– and it is impossible to determine without consulting the certification practices for CAs– it shows a circularity in the security model. SSL/TLS are designed to survive exactly the type of mayhem created by DNS hijacking. It does not matter whether traffic is routed to the right website or the wrong one. When the protocol is implemented correctly and the certificate checks out, the user is supposed to be guaranteed that they are dealing with the legitimate website. (That is not much of a guarantee: if the certificate has errors, the protocol will detect it but until recent web browsers used to respond by displaying a cryptic warning that users simply ignored. Even when the certificate is validated correctly, that only proves the identity is what is stated in the URL– which may not be at all the same one that is in the user’s mental picture, to the delight of phishing syndicates everywhere.) Weak certification practices destroy even this glimmer of hope by placing critical faith in DNS to bootstrap a protocol that was purportedly designed to survive complete breakdown of all naming and routing infrastructure.

cemp

From owning DNS to owning SSL (1/2)

Dan Kaminsky walked away with the Pwnie award for most overhyped bug and being a good sport, appeared in person with a brief acceptance speech. The BlackHat presentation did turn into an over-crowded spectacle as expected, there was nothing new to report. (Even though a section of the deck was prefaced with “Here is something that did not leak…”) The cat had been out of the bag, compliments of earlier speculation by Halvar Flake and a miscue by the folks at Matasano. And that’s just the public disclosure: the presentation itself credited several people who identified the same vulnerability within days independently but decided to remain quiet, in keeping with the unusual request.

The more interesting was the second piece of the talk: the question of “why”, why it is worth subverting DNS and what can be accomplished. Decidedly more speculative in nature, in this section Kaminsky argued that SSL,  most software updates and online identity management services are vulnerable. If these claims hold for real-world implementation, not simply the marginal ones written by careless developers, it would be more remarkable than the original discovery.

SSL and in general PKI were designed to be resilient against an untrusted network. The design of the protocols assumes the transport is completely unreliable. The metaphor this blogger uses to describe it in security orientation classes is two people, say Alice and Bob, trying to communicate but restricted exchanging post-it notes carried by a shady messenger. In this model it is clear the messenger may fail to deliver the note, and the two sides never manage to communicate. No surprise there. But more interestingly, our shady messenger can erase part of the mesage, add forged languge, for that matter replace the entire note by a new one fabricated out of thin air, change the order in which notes are delivered, even replay one person’s note back to him/her as if it originated from the other side. This bizarre threat model is intended to capture the man-in-the-middle (MITM) attack in the abstract, where a malicious adversary is capable of reading and modifying any message sent between two people.

Communication protocols including SSL/TLS are designed to be secure in this model, in the sense that the nefarious messenger can not read a private message intended for Alice, nor convince Alice that Bob sent a message he did not in fact originate. SSL/TLS protocol itself has lived up to this claim so far– there are no known, practical cryptographic attacks against the protocol itself (as opposed to specific implementations, which can have coding issues that are not intrinsic in the protocol)  The closest call was the Bleichenbacher attack against RSA padding first published in 1998 and later refined.

[continued]

cemp

Net neutrality developments: West Coast and East Coast

Two developments on this front, one involving East Coast code and one compliments of West Coast code:

  • FCC instructed Comcast to stop tampering with network traffic. This ruling was widely expected,  so much that one senator decided to file a pre-emptive response criticizing the decision. The final outcome still came down with a narrow 3-2 majority. Typical of East Coast code, this response was largely symbolic and arrive several months late to the scene. Comcast voluntarily suspended the practice in March after its earlier fabrications and denials were publicly proven wrong. This is unlikely to be the final word; Comcast issued what appears to be the opening salvo in a protracted legal battle. It has plenty of ammunition: writing for the minority one of the commisioners called the order “doomed on appeal.”
  • EFF released a new neutrality testing framework called Switzerland. It requires users to download an install an application, which then allows stress testing the available network bandwidth by connecting to other users running the same application and simulating various protocols. Switzerland could have detected the BitTorrent tampering last year, if the experiments were designed to look for that evidence. One challenge in effectively using these distributed sensor networks is knowing which questions to ask. Another potential challenge is that the framework is designed to only check for peer-to-peer connectivity. For example an ISP could still artificially slow down traffic to one website while boosting speeds for its competitor. Because the IP ranges for large websites are well known, this type of tampering can be done without tripping the sensors that check for P2P connectivity.

cemp

Standardizing on a standards body

Greetings to the Open Web Foundation. OWF is a new organization for promoting community-driven specifications:

“The Open Web Foundation is an attempt to create a home for community-driven specifications. Following the open source model similar to the Apache Software Foundation, the foundation is aimed at building a lightweight framework to help communities deal with the legal requirements necessary to create successful and widely adopted specification.”

The next statement goes on to state that one of the objectives is to avoid creating a separate foundation for each new technology. Of course the natural reaction to that will be: “In that case, why are you creating yet another self-appointed standard organization? What is wrong with IETF or W3C?” To recap:

  • W3C is the World Wide Web Consortium. It maintains core standards related to the web: HTML, CSS, XML, XSL, XPath, SOAP– for the most part, anything involving angle brackets falls under the jurisdiction of the W3C. Most of these are commonly recognized, widely supported data formats or data manipulation frameworks. (By contrast W3C forays into protocol design such as PICS, P3P and SOAP have met with mixed results.) The consortium charters working groups and issues official, versioned specifications.
  • IETF is the Internet Engineering Task Force. IETF does not officially endorse standards. Its documents go by the more modest name RFC or “request for comments,” suggesting ideas in flux, perennially under editorial review, always open to improvement and changes. Yet many of the core protocols and specifications underlying the Internet can be attributed to an RFC. Email addresses? That would be RFC822. The HTTP protocol shuttling web pages around? RFC 2616. The official TLS protocol that gives us the peace-of-mind and security of the lock-icon on those pages? RFC 2246.

Ben Laurie seeks to preempt that question, also raised in the discussion group. Jury is out on the characterization of W3C as pay-to-play-cartel but the article does highlight a basic problem with IETF: being too inclusive. A former colleague at MSFT described it the requirements for participation in IETF as “a keyboard and Internet connection.” (We can also add: “… and an unshakeable conviction in the infallibility of your ideas.”) This model probably worked well when the workings of arcane protocols was of interest to the academic community only, and everyone that cared to participate started out on the same page, sharing common interests. Today the Internet is too large, the range of stake-holders too diverse and too much commercial success hinges on the outcome of standardization process to continue with that naive assumption of unified purpose.

That same colleague provided this insightful comment on the IETF process: It is a great forum to capture the dominant paradigm on paper and enshrine it as the Internet standard when consensus exists around one. It is not a very good forum for creating consensus in the first place, when everyone shows up at the table with different ideas and irreconcilable objectives. These words were uttered in the aftermath of the Sender ID meltdown where the working group rejected an anti-spam proposal from Microsoft.

OWF raises anew the question of who gets the privilege of a seat at the table once the IETF model (anyone is welcome or “no fool left behind”) is declared dysfunctional, because there is too much randomization. Intuitively those writing software to implement the standard emerge as obvious candidates. But are some implementors more equal than others? Surely not every crackpot with a copy of networking for dummies is entitled to derail the standard process. What about individuals who are recognized subject matter experts but not currently developing software in this space? Moving away from the core, how about companies whose products will be indireclty impacted? Do ISPs get a say in the development of a P2P filesharing protocol, considering it is their infrastructure about to get hammered? Does a firewall vendor get to express an opinion on anti-spam technology because they want to inspect traffic at the edge? Do other participants have the right to declare that they are not interested in supporting that scenario, shutting them out of a particular market segment? Even more controversially, what about companies whose business model is at risk from the existence of the technology? (Advertising networks, criticially dependent on third-party cookies for their existence, were participants in the working group tasked with developing the privacy standard P3P that Internet Exporer uses to manage cookies.)

Assuming that OWF gains any traction, at least one benefit will be forcing some soul searching inside IETF and W3C.

cemp