Students enlist readers’ assistance in CardSpace “breach”

Students at Ruhr Universitat Bochum in Germany have published an account this week describing an attack on the use of CardSpace within Internet Explorer.  Their claim is to “confirm the practicability of the attack by presenting a proof of concept implementation“.

I’ve spent a fair amount of time reproducing and analyzing the attack.  The students were not actually able to compromise my safety except by asking me to go through elaborate measures to poison my own computer (I show how complicated this is in a video I will post next).  For the attack to succeed, the user has to bring full administrative power to bear against her own system.  It seems obvious that if people go to the trouble to manually circumvent all their defenses they become vulnerable to the attacks those defenses were intended to resist.  In my view, the students did not compromise CardSpace.

DNS must be undermined through a separate (unspecified) attack

To succeed, the students first require a compromise of a computer’s Domain Name System (DNS).  They ask their readers to reconfigure their computers and point to an evil DNS site they have constructed.  Once we help them out with this, they attempt to exploit the fact that poisoned DNS allows a rogue site and a legitimate site to appear to have the same internet “domain name” (e.g. www.goodsite.com) .  Code in browser frames animated by one domain can interact with code from other frames animated by the same domain.  So once DNS is compromised, code supplied by the rogue site can interfere with the code supplied by the legitimate site.  The students want to use this capability to hijack the legitimate site’s CardSpace token.

However, the potential problems of DNS are well understood.  Computers protect themselves from attacks of this kind by using cryptographic certificates that guarantee a given site REALLY DOES legitimately own a DNS name.  Use of certificates prevents the kind of attack proposed by the students.

The certificate store must also “somehow be compromised”

But this is no problem as far as the students are concerned.  They simply ask us to TURN OFF this defense as well.  In other words, we have to assist them by poisoning all of the safeguards that have been put in place to thwart their attack.  

Note that both safeguards need to be compromised at the same time.  Could such a compromise occur in the wild?  It is theoretically possible that through a rootkit or equivalent, an attacker could completely take over the user’s computer.  However, if this is the case, the attacker can control the web browser, see and alter everything on the user’s screen and on the computer as a whole, so there is no need to obtain the CardSpace token.

I think it is amazing that the Ruhr students describe their attack as successful when it does NOT provide a method for compromising EITHER DNS or the certificate store.  They say DNS might be taken over through a drive-by attack on a badly installed wireless home network.  But they provide no indication of how to simultaneously compromise the Root Certificate Store. 

In summary, the students’ attack is theoretical.  They have not demonstrated the simultaneous compromise of the systems necessary for the attack to succeed.

The user experience

Because of the difficulty of compromising the root certificate store, let’s look at what would happen if only DNS were attacked.

Internet Explorer does a good job of informing the user that she is in danger and of advising her not to proceed. 

First the user encounters the following screen, and has to select “Continue to the website (not recommended)”:


 
If recalcitrant, the user next sees an ominous red band warning within the address bar and an unnaturally long delay:

The combined attacks require a different yet coordinated malware delivery mechanism than a visit to the phishing site provides.  In other words, accomplishing two or more attacks simultaneously greatly reduces the likelihood of success.

The students’ paper proposes adding a false root certificate that will suppress the Internet Explorer warnings.  As is shown in the video, this requires meeting an impossibly higher bar.  The user must be tricked into importing a “root certificate”.  This by default doesn’t work – the system protects the user again by installing the false certificate in a store that will not deceive the browser.  Altering this behavior requires a complex manual override.

However, should all the planets involved in the attack align, the contents of the token are never visible to the attacker.  They are encrypted for the legitimate party, and no personally identifying information is disclosed by the system.  This is not made clear by the students’ paper.

What the attempt proves 

The demonstrator shows that if you are willing to compromise enough parts of your system using elevated access, you can render your system attackable.   This aspect of the students’ attack is not noteworthy. 

There is, however, one interesting aspect to their attack.  It doesn’t concern CardSpace, but rather the way intermittent web site behavior can be combined with DNS to confuse the browser.  The student’s paper proposes implementing a stronger “Same Origin Policy” to deal with this (and other) possible attacks.  I wish they had concentrated on this positive contribution rather than making claims that require suspension of disbelief. 

The students propose a mechanism for associating Information Card tokens with a given SSL channel.   This idea would likely harden Information Card systems and is worth evaluating.

However, the students propose equipping browsers with end user certificates so the browsers would be authenticated, rather than the sites they are visiting.  This represents a significant privacy problem in that a single tracking key would be used at all the sites the user visits.  It also doesn’t solve the problem of knowning whether I am at a “good” site or not.  The problem here is that if duped, I might provide an illegitimate site with information which seriously damages me.

One of the most important observations that must be made is that security isn’t binary – there is no simple dichotomy between vulnerable and not-vulnerable.  Security derives from concentric circles of defense that act cumulatively and in such a way as to reinforce one another.  The title of the students’ report misses this essential point.  We need to design our systems in light of the fact that any system is breachable.  That’s what we’ve attempted to do with CardSpace.  And that’s why there is an entire array of defenses which act together to provide a substantial and practical barrier against the kind of attack the students have attempted to achieve.

European Identity Awards

The recent European Identity Conference 2008 featured the presentation of Kuppinger Cole's European Identity Awards. Vendors, integrators, consultants and user companies were asked for nominations. For each category, three outstanding projects and innovations were nominated as finalists. Here is how Kuppinger Cole framed the results:

Best Innovation

“The award went to a group of companies that are driving forward the process to outsource authentication and authorisation, making it easier to control application security ‘from outside’.   There are several providers with different approaches in this field but during the past year, they all contributed a lot to promote this concept, considered as indispensable by KCP.   The winners in this category are Bitkoo, CA, iSM, Microsoft and Oracle.

“Also among the finalists were Aveksa and Sailpoint for their Identity Risk Management solutions and Microsoft for making a significant contribution to identity information protection in distributed environments through their takeover of Credentica and the planned integration of U-Prove technology into user-centric Identity Management.”

Best New/Improved Standard

“The award went to the OpenID Foundation and to Microsoft for their InfoCard initiative. These standards form the base for Identity 2.0, the so-called user-centric Identity Management.

“Other outstanding solutions nominated as finalists were the eCard API Framework and the simpleSAMLphp project driven forward by Feide RnD. The eCard API Framework has been jointly developed by Secunet and the Bundesamt für Sicherheit in der Informationstechnik (abbreviated BSI – in English: Federal Office for Security in Information Technology) to simplify the interaction of applications with different card technologies. With simpleSAMLphp, federation functions can easily be integrated into existing and new applications.”

Best Internal Identity Management Project

“The award went to BASF for their AccessIT project, which realises Identity Management within a complex corporate structure and excells in consistent approaches to centralised auditing.

“Another finalist in this category was the Royal Bank of Scotland, with its project to control a multitude of applications by an integrated role-based access control.”

Best B2B Identity Management Project

“The award went to Orange/France Telecom.  Their project is revolutionary due to the consistent use of federation and the opening of systems to partners.

“Also among the finalists in this category were Endress+Hauser for their business customer portal and education network SurfNET which is at present one of the most comprehensive federation implementations.”

Best B2C Identity Management Project

“The award went to eBay and Paypal which support strong authentication mechanisms, thus making a significant contribution to the protection of online transactions and creating more awareness on this issue among the wider public.

“Other finalists were Karlsruhe-based company Fun Communications for their innovative approach to the use of info cards as virtual customer cards, which is groundbreaking in our opinion, and KAS bank for their consistent use of strong authentication and encryption technologies to protect transactions.”

Best eGovernment Identity Management Project 

“The Republic of Austria received the prize in the “Best eGovernment Identity Management project” category for their eGovernment initiatives which we think are leading with regard to the implementation of Identity Management.

“Other finalists were Crossroads Bank, Smals and BAMF  – the Bundesamt für Migration and Flüchtlinge (Federal Office for Migration and Refugees).”

Special prizes

Dale accepting award and champagne on behalf of Higgins/Bandit“Special prizes were given to two initiatives considered as groundbreaking by KCP.

“In KCP's opinion, the VRM project by Doc Searls is an innovative approach that applies user-centric Identity Management concepts to customer management. In the VRM Unconference 2008 at the EIC 2008, this issue was intensely discussed in Europe for the first time.

“The second special prize went to open source projects Higgins and Bandit which we think are the most important open source initiatives in Identity Management.”

[Thanks to Jackson Shaw for Photos]

Microsoft to adopt Stefan Brands’ Technology

The Internet may sometimes randomly “forget”.  But in general it doesn't. 

Once digital information is released to a few parties, it really is “out there”.  Cory Doctorow wrote recently about what he called the half-life of personal information, pointing out that personal information doesn't just “dissipate” after use.  It hangs around like radioactive waste.  You can't just push a button and get rid of it.

I personally think we are just beginning to understand what it would mean if everything we do is both remembered and automatically related to everything else we do.  No evil “Dr. No” is necessary to bring this about, although evil actors might accelerate and take advantage of the outcome.  Linkage is just a natural tendency of digital reality, similar to entropy in the physical world.  When designing phsyical systems a big part of our job is countering entropy.  And in the digital sphere, our designs need to counter linkage. 

This has led me to the idea of the “Need-to-Know Internet”.

The Need-to-Know Internet

“Need to Know” thinking comes from the military.  The precept is that if people in dangerous situations don't know things they don't need to know, that information can't leak or be used in ways that increase danger.  Taken as a starting point, it leads to a safer environment.

As Craig Burton pointed out many years ago, one key defining aspect of the Internet is that everything is equidistant from everything else. 

That means we can get easily to the most obscure possible resources, which makes the Internet fantastic.  But it also means unknown “enemies” are as “close” to us as our “friends” – just a packet away.  If something is just a packet away, you can't see it coming, or prepare for it.  This aspect of digital “physics” is one of the main reasons the Internet can be a dangerous place.

That danger can be addressed by adopting a need-to-know approach to the Internet.  As little personal information as possible should be released, and to the smallest possible number of parties.  Architecturally, our infrastructure should lead naturally to this outcome. Continue reading Microsoft to adopt Stefan Brands’ Technology

Why OpenID leads to CardSpace…

The recent announcements about OpenID made enough impact that I've had a number of people ask what our interest in OpenID means for Information Cards in general and CardSpace in particular.

The answer is simple.  OpenID provides Single Sign On to social networking sites and blogs.  It means we can use a public personna across sites, and just log in once to use that persona.

But OpenID doesn't have the privacy characteristics that would make it suitable for government applications or casual web surfing.  And it doesn't have the security characteristics necessary for financial transactions or access to private data.  In other words, its good for a specific set of purposes, and we are interested in it for those purposes, but we remain as committed to more secure and privacy-oriented technologies as ever.  In other words, we are interested in OpenID as part of a spectrum.

Information Cards are a way of safely organizing a palette of digital identities into a “digital wallet”.  Over time, some of these identities will be very valuable, controlling access to government information, bank accounts, and corporate resources.  Other identities will be very private, like those associated with health information or perhaps dating.  Others will be the kind of public personas we are talking about with OpenID.

These different identities will co-exist in a metasystem with contextual separation but a similar use model.  Importantly, the metasystem won't replace the underlying technologies – it will unify them and provide a consistent experience. 

The relation between OpenID and CardSpace provides a good example of the issues involved here.   OpenID provides convenience and power but suffers the problem of all the Single Sign On technologies – the more it succeeds, the more dramatically phishable it will become.  I've created a visual demo to help explain how this works – and how CardSpace works with OpenID to solve the problems.

My takeaway is that OpenID leads to CardSpace.  I don't mean by this that Information Cards replace OpenID.  I just mean that the more people start using cross-site identities, the more the capabilities of CardSpace become relevant as a way of strengthening OpenID and put it in a broader technology context.  

Information Cards were created to put in place an infrastructure that can solve the security problems of the web before they explode in our faces.  It's a serious technology and involves secure high-strength products emerging across the industry.  The recent announcement by Higgins of the new user-centric identity framework for Eclipse  is a great sign of the progress being made.  And there are other important announcements coming as well.

[In this demo I use my favorite OpenID provider, which is myOpenID.com.  It is super important to point out that I think the company is great.  None of my analysis is a critique of myOpenID – I'm explaining some of the “browser-redirect” problems that face all OpenID providers (as well as SAML and Shibboleth providers). Importantly, myOpenID have supported Information Cards for a long time – and their implementation works well.  So they are at the forefront of working these problems.  Try using their Information Card solution.]

Paul Madsen's Identerati greeting cards

Paul Madsen has submitted the following card set for standardization with the ITU. 

Ashish Jain has already asked if the various options will light up according to the policy requirements of the person to whom they are sent.

Paul has assured all those concerned that the preference URLs will be standardized through the UN.

Display Tokens in Information Cards

I recommend an interesting exchange between Citi's Francis Shanahan, Microsoft's Vittorio Bertocci, and University of Wisconsin's Eric Norman.  Here's the background.  Francis has spent a lot of time recently looking in depth at the way CardSpace uses WS-Trust, and even built a test harness that I will describe in another piece.  While doing this he found something he thought was surprising:  CardSpace doesn't show the user the actual binary token sent to a relying party – it shows a description crafted by the identity provider to best communicate with the user.

(The behavior of the system on this – and other – points is documented in a paper Mike Jones and I put together quite a while ago called “Design Rationale Behind the Identity Metasystem Architecture“.  There is a link to it in the WhitePapers section on my blog.)

Francis has his priorities straight, given the way he sees things:

I'm not sure how to solve this. I'm not sure if it's a fault inherent in the Identity Meta-system or if it's just a fact of life we have to live with.

I would never want to put the elegance of a meta-system design and accommodation of potential future token types ahead of supporting Law #1.

There is no question that elegance of design cannot be pitted against the Laws of Identity without causing the whole design to fail and any purported elegance to evaporate.

So clearly I think that the current design delivers the user control and consent mandated by the First Law of Identity. 

Let's start by seeing the constraints from a practical point of view.  In an auditing identity provider, one of the main characteristics of the system is that the provider knows the identity of the relying party.  Think of the consequences.  The identity provider is capable of opening a back channel to any relying party and telling it whatever it wants to.  In fact, from a purely technical point of view, the identity provider can just broadcast all the information it knows about you, me and all our activities to the entire world! 

We put trust in the identity provider when we provide it with information that we don't want universally known.  And more trust is involved when we accept “auditing mode”, in which the identity provider is able to help protect us by seeing the identity of the party we are connecting with (e.g. during a banking transaction).

Should we conclude the existence of scenarios requiring auditing mean the laws aren't “laws”?

“Going back to my original question which was “Does the DisplayToken violate the First Law of Identity?” I am not convinced it does. What I think I am discovering is that the First Law of Identity is not necessarily enforced.

“For me, being Irish Catholic (and riddled with guilt as a result) I take a very hard-line approach when you start talking about “Laws”. For example, I expect the Law of Gravity to be obeyed. I don't view it as a “Recommendation for the Correct Implementation of Gravity”…

The point here is that when the user employs an auditing identity provider, she should understand that's what she is doing. 

While we can't then prevent evil, we can detect and punish it.  The claims in the token are cryptographically bound to the claims in the display token.  The binding is auditable.  So policy enforcers can now audit that the human readable claims, and associated information policy, convey the nature of the underlying information transfer.  

This auditability means it is possible to determine if identity providers are abiding by the information policies they claim they are employing.  This provides a handle for enforcing and regulating the behavior of system participants.

We've spoken so far about “auditing” identity providers.  The system also supports “non-auditing” providers, who do not know the identity of the relying party.  In this case, a back channel is not possible.  The auditing of the accuracy of the display token is still possible however.

There is also an option for going even further, through the use of “minimal disclosure tokens”.  In such a system, the user can have an identity provider that she operates, and which submits her claims to a service for validation.  In this architecture, the user can really be guaranteed that there are no back channels or identity-provider injected goop.

Again, we are brought to understand that the identity metasystem spans a whole series of requirements, use cases and behaviors.  The most important thing is that it support all of them. 

I do not want a “non-auditing” bank account.  In that context, display tokens bound to information tokens and associated with an information policy all seem fine to me.

On the other hand, when browsing the web and doing many other types of transactions I want to prevent any identity provider from profiling me or obtaining any more information than necessary.  Minimal disclosure tokens are the best answer under those circumstances.

The uberpoint:  unless we have a system that embraces all these use cases, we break more than the first law.  We break the laws of minimal disclosure, necessary parties, identity beacons, polymorphism, human integration and consistent experience.   We need a balanced, pragmatic approach that builts transparency, privacy, user control and understanding into the system – integrated with a legal framework for the digital age.

MSN and Windows Live hook up InfoCard Beta

Video of Hotmail Beta of Information Cards

In this video of the Windows Live ID beta (1:20) we use Bandit's DigitalMe to register and log into Hotmail from a Mac.  If anyone has been concerned that Information Cards won't scale to handle large sites, they can relax now.  To see another version of the demo, this time using CardSpace, watch this (2:20). 

MSN and Windows Live CardSpace Beta

You can now use Information Cards at Hotmail and all the other MSN/Windows Live sites. 

Just go here to associate an Information Card with your existing account.   I found that both Windows CardSpace and the Mac DigitalMe information card selectors worked beautifully with the system.  Check out this video to see what it was like registering and logging in from my Mac using DigitalMe. 

It's worth taking a step back to think about what can go wrong when you add a feature of this importance to a site with 300 million accounts.  If things don't work, you don't have a software bug – you have a trainwreck.  So the Windows Live people have done a lot of thinking, planning and testing in order both to create a cool experience and keep from confusing their users.   

There are still some anomolies.  In the words of the Beta announcement: Continue reading MSN and Windows Live CardSpace Beta

Nick Shelness on CardSpace

The strangest thing just happened.  I was following a link that had just appeared from vowe.net  – a site published by Volker Webe.  An interesting site, for sure – and on it, I read this piece by Nick Shelness:  

Establishing identity and authenticating on the web are a mess. I doubt I’m alone in using the same user id and password over and over again. If they’re hacked once they can be employed a hundred times over. Yeah, some sites make you change your password at regular intervals, but how do you remember them? I write them down, and carry them with me. OK, they’re somewhat encoded, but …

For some time now, there has been the possibility of improvement under the “Identity 2.0” banner. To the surprise of some (many?), a significant chunk of Identity 2.0 innovation has come from Microsoft, and no, no, no, it’s not “Passport”. It is expressed in two seminal papers: The Laws of Identity and The Identity Metasystem, both by Kim Cameron.

But this is not all. There is a Microsoft product. It’s called “CardSpace” (it used to be called “Info Card”). It ships as part of Vista. It also ships as an automatic XP upgrade, and there are a host of alternatives, including open source ones.

CardSpace and its analogues, on their own, are not a solution. They are a component, albeit a key one, of an Identity Metasystem. What needs to come next is for web sites (“Relying Parties”) to start requesting and employing CardSpace-managed security assertions. This in turn will create a demand for Identity Provision (yes, this is where ActiveDirectory and son of Passport come in).

Will this happen? It’s too early to say. But by seeding the digital world with CardSpace, Kim and Microsoft have taken us a long first step down this path, and IMHO done us all a big favor.

It took me a minute to click in to the name Nick Shelness.  He is a great visionary – CTO at Lotus and later an IBM fellow (now with his own practice in the UK).  His support means a lot to me. 

As for his “will it happen?” question, I've asked it too on a hundred ‘bleak and dreary days’.  But I continue to think there are historical inevitabilities at work here.  

Distributed computing is dammed up behind a wall of identity friction.  The one good thing about the friction is that it limits phishing and cyber crime as much as it limits business.  Remove the friction with something like single sign-on and you massively increase the attraction of the digital honeypot, providing a one-stop attack surface for evil.  The more consolidated identity initiatives succeed, the more they will fail – unless there is a paradigm change like CardSpace that compensates for risk aggregation.  

Few may understand these dynamics through theory alone, but Professor Reality will come to tutor them before too long.  Meanwhile, there are more and more people with enough vision that they don't have to “go over Niagra Falls in a barrel to know it hurts.” 

Day after day, week after week, month after month, CardSpace “sockets” are appearing on desktops.  One day – not too far into the future – it will be present on 50% of them.  Then on 75%!  Meanwhile the software will get slicker and slicker, with multiple versions and choices by people like our friends at Higgins running on Mac and Linux.  This is a historic thing we are doing together, and we can't be impatient.  But this baby is going to light up big time.

Unifying the experience of online identity

Jon Udel zeros in on the problem of web sites that introduce “novel” authentication schemes once these schemes start to proliferate.   I had the same concerns when I set out the seventh law of identity (consistent experience).  Jon says:

Several months ago my bank implemented an anti-phishing scheme called Site ID, and now my mortgage company has gone to a similar scheme called PassMark. Both required an enrollment procedure in which I had to choose private questions and give answers (e.g., mother’s maiden name) and then choose (and label) an image. The question-and-answer protocol mainly beefs up name/password security, and secondarily deters phishing — because I’d notice if a site I believed to be my bank or mortgage company suddenly didn’t use that protocol. The primary anti-phishing feature is the named image. The idea is that now I’ll be suspicious if one of these sites doesn’t show me the image and label that I chose.

When you’re talking about a single site, this idea arguably make sense. But it starts to break down when applied across sites. In my case, there’s dissonance created by different variants of the protocol: PassMark versus Site ID. Then there’s the fact that these aren’t my images, they’re generic clip art with no personal significance to me. Another variant of this approach, the Yahoo! Sign-In Seal, does allow me to choose a personally meaningful image — but only to verify Yahoo! sites.

These fragmentary approaches can’t provide the grounded and consistent experience that we so desperately need. One subtle aspect of that consistency, highlighted in Richard Turner’s CardSpace screencast, is the visual gestalt that’s created by the set of cards you hold. In the CardSpace identity selector, the images you see always appear together and form a pattern. Presumably the same will be true in the Higgins-based identity selector, though I haven’t seen that yet.

I can’t say for sure, because none of us is yet having this experience with our banks and mortgage companies, but the use of that pattern across interactions with many sites should provide that grounded and consistent experience. Note that the images forming that pattern can be personalized, as Kevin Hammond discusses in this item (via Kim Cameron) about adding a handmade image to a self-issued card. Can you do something similar with a managed card issued by an identity provider? I imagine it’s possible, but I’m not sure, maybe somebody on the CardSpace team can answer that.

In any event, the general problem isn’t just that PassMark or Site ID or Sign-In Seal are different schemes. Even if one of those were suddenly to become the standard used everywhere, the subjective feeling would still be that each site manages a piece of your identity but that nothing brings it all together under your control. We must have, and I’m increasingly hopeful that we will have, diverse and interoperable identity selectors, identity providers, relying parties, and trust protocols. But every participant in the identity metasystem must also have a set of core properties that are invariant. One of the key invariant properties is that it must bring your experience of online identity together and place it under your control.

The “novel authentication” approach used by PassMark and others doesn't scale any better than the “pocket full of dongles” solutions proposed by Dongle queens or – for that matter – than conventional usernames and passwords. 

So far Information Cards are the only technology that both prevents phishing and avoids the novel authentication and multiple dongle problems.

By the way – if what Jon calls the “dissonance” problem that arises from the use of different images and questions on web sites were to be overcome by reusing the same images and questions everywhere, things would only get worse!

Once sites begin to share the same “novel authentication” model, you no longer have novel authentication. 

In fact you return full circle to the deepest phishing problems.  Why? 

If you went to an evil site and set up your reusable images and questions, you would have taught the evil site how to impersonate you at legitimage sites.   Thus in spite of lots of effort, and lots of illusions, you would end up further behind than when you started.