From The Economist: the Identity Parade

It's great to see mainstream publications really taking the time to understand and convey the issues of digital identity and privacy.  A recent article in the Economist discussed the Laws of Identity at length.  Cambridge researcher Ross Anderson and others are quoted as well.  Here's an excerpt that gives you a sense for the full article

Internet users have become used to providing personal information to any convincing-looking box that appears on a screen. They have little idea of either the technology that helps to provide electronic security in practice or the theoretical principles that determine whether it will work. According to Mr Cameron, “there is no consistent and comprehensible framework allowing them to evaluate the authenticity of the sites they visit, and they don't have a reliable way of knowing when they are disclosing private information to illegitimate parties. At the same time they lack a framework for controlling or even remembering the many different aspects of their digital existence”…

Cybercrime discredits the use of the internet not only by business but by government too. Mr Cameron suggests rethinking the whole issue, starting from the principle that users may be identified only with their explicit consent. That sounds commonsensical, but many big government databases do things differently. Britain's planned central records for the NHS, for example, will assume consent as it combines all the medical records held in local practice databases.

The second principle, says Mr Cameron, should be to keep down the risk of a breach by using as little information as possible to achieve the task in hand. This approach, which he calls “information minimalism”, rules out keeping information “just in case”. For example, if a government agency needs to check if someone falls into a certain age group, it is far better to acquire and store this information temporarily as a “yes” or “no” than to record the actual date of birth permanently, which would be much more personal and therefore more damaging if leaked.

Third, identity systems must be able to check who is asking for the information, not just hand it over. How easy it is for the outside world to access such information should depend on whose identity it is. Public bodies, Mr Cameron suggests, should make themselves accessible to all comers. Private individuals, by contrast, should be protected so that they have to identify themselves only temporarily and by choice…

[More here...]

Handbags at dawn?

Here is Pat Patterson's post on my recent discussion with Ben Laurie.   Pat is a widely respected member of Sun's identity team, blogs at Superpatterns, and runs the useful PlanetIdentity RSS feed.   There are a number of ways you could build a Password Manager for CardSpace, but I thought readers would enjoy seeing Pat's take on it:

You might have noticed the exchange between Ben and Kim over the past day or two… Ben made a point that CardSpace makes OpenID redundant – why not just send a password to the RP? Kim jumped all over him – somewhat misinterpreting what Ben later describes as one of my most diabolical hungover bits of prose ever. Ben goes on to clarify that maybe CardSpace can have a role in helping the user manage passwords; Kim says “Hmm… Food for thought” (okay, I'm paraphrasing); Ben admits he didn't explain himself too clearly to begin with; and, glory be, they're violently agreeing. Phew! I thought we were going to be seeing handbags at dawn

Reading all this lit a spark in my mind of how this could work. The crux is to consider the username/password token, usually sent as one of a set of possible input tokens to an identity provider security token service (IP/STS), as an output token.

Here's how it would work… Borrowing a diagram from Microsoft's Guide to Interoperating with the Information Card Profile V1.0:

First of all, the IP/STS would specify ic:RequireAppliesTo in the managed card. This tells the identity selector to include a wsp:AppliesTo element in the wst:RequestSecurityToken (RST). The IP/STS is going to need this later…

Now, the user visits the relying party (RP) in step 1, requesting some resource. In step 2, the ‘service requestor’ (application client with identity selector) requests security policy from the RP. The RP would indicate, in step 3, that it wanted a username/password token by specifying a token type of http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0 in the policy.

Now the identity selector presents some set of information cards (hopefully just one) to the user (step 5) and the user selects one (step 6). Steps 7 and 8 would see the RP requesting security policy from the IP/STS, and the IP/STS supplying it, exactly as in the standard information card interaction. Here the IP/STS could require any form of input token, but username/password is most likely.

Between steps 8 and 9, the identity selector prompts the user for credentials (bad Microsoft, missing that out of the diagram!) and in step 8, the identity selector packages up the user's credentials in a WS-Trust RST and send them to the IP/STS.

Now, here's the interesting bit. The IP/STS authenticates the user, exactly as in the standard CardSpace case, but now it looks at the wsp:AppliesTo element, and looks up the user's username/password pair for that RP (this is an implementation detail – there could be a mapping of RP identifiers to username/password pairs per user, all encrypted on disk, of course). The IP/STS packages them as a wsse:UsernameToken, which is then encrypted with the RP's public key and returned to the identity selector (step 10). The display token could just show ******** for the value of the password claim. Now we have a nice, securely packaged credential that the identity selector can send to the RP in step 11.

Here's the other nice bit… All the RP has to do is to decrypt the incoming token and it has the user's username and password, exactly as if they had arrived by a conventional form post. No further customization required at the RP – no changes to directory or database schemas, no extra steps of associating an information card with your account. Passwords on steroids.

If the RP uses https, I'm not even sure there is any need to decrypt at the token layer, which simplifies implementation to decoding a simple xml structure.  RP's who are looking for greated levels of security should switch to public key.

I'd like to hear Pat's ideas about the user experience of bootstrapping the passwords into the Identity Provider.

UK Chip and PIN vulnerable to simple attack

LightBlueTouchpaper, a blog by security researchers at Cambridge University, has posted details of a study documenting easy attacks on the new generation of British bank cards.  Saar Drimer explains, ”This attack can capture the card’s PIN because UK banks have opted to issue cheaper cards that do not use asymmetric cryptography”.  Let's all heed the warning: 

Steven J. Murdoch, Ross Anderson and I looked at how well PIN entry devices (PEDs) protect cardholder data. Our paper will be published at the IEEE Symposium on Security and Privacy in May, though an extended version is available as a technical report. A segment about this work will appear on BBC Two’s Newsnight at 22:30 tonight.

We were able to demonstrate that two of the most popular PEDs in the UK — the Ingenico i3300 and Dione Xtreme — are vulnerable to a “tapping attack” using a paper clip, a needle and a small recording device. This allows us to record the data exchanged between the card and the PED’s processor without triggering tamper proofing mechanisms, and in clear violation of their supposed security properties. This attack can capture the card’s PIN because UK banks have opted to issue cheaper cards that do not use asymmetric cryptography to encrypt data between the card and PED.

Ingenico attack Dione attack

In addition to the PIN, as part of the transaction, the PED reads an exact replica of the magnetic strip (for backwards compatibility). Thus, if an attacker can tap the data line between the card and the PED’s processor, he gets all the information needed to create a magnetic strip card and withdraw money out of an ATM that does not read the chip.

We also found that the certification process of these PEDs is flawed. APACS has been effectively approving PEDs for the UK market as Common Criteria (CC) Evaluated, which does not equal Common Criteria Certified (no PEDs are CC Certified). What APACS means by “Evaluated” is that an approved lab has performed the “evaluation”, but unlike CC Certified products, the reports are kept secret, and governmental Certification Bodies do not do quality control.

This process causes a race to the bottom, with PED developers able to choose labs that will approve rather than improve PEDs, at the lowest price. Clearly, the certification process needs to be more open to the cardholders, who suffer from the fraud. It also needs to be fixed such that defective devices are refused certification.

We notified APACS, Visa, and the PED manufactures of our results in mid-November 2007 and responses arrived only in the last week or so (Visa chose to respond only a few minutes ago!) The responses are the usual claims that our demonstrations can only be done in lab conditions, that criminals are not that sophisticated, the threat to cardholder data is minimal, and that their “layers of security” will detect fraud. There is no evidence to support these claims. APACS state that the PEDs we examined will not be de-certified or removed, and the same for the labs who certified them and would not even tell us who they are.

The threat is very real: tampered PEDs have already been used for fraud. See our press release and FAQ for basic points and the technical report where we discuss the work in detail.

[Thanks to Richard Turner for the heads up.]

New plans for German identity card

IdealGovernment's William Heath describes a planned identification card for German citizens that incorporates a pseudonym capability for electronic commerce: 

The German Home Office has confirmed that a new electronic identity card for German citizens will incorporate the use of pseudonyms for secure web access.

According to the plans of the German Home Office, a credit card sized electronic identity card will be introduced in 2009. It will replace the larger, non-electronic identity cards currently in use. “Apart from the usual personal information, the electronic identity card will contain biometric information, in particular digital fingerprints of both index fingers, and additional information for facial recognition”, says secretary of state August Hanning.

Hanning confirmed that the new identity card will contain a pseudonym function. In a leaked letter to Gisela Piltz, a Member of German Parliament for the Liberal Democrats (FDP), Hanning stated that the card could be used as a “passport for the internet” in the future. “The new identity card offers the possibility of an electronic identity proof for E-Government- and E-Business-applications”, writes Hanning.

The central idea is that the individual card number is used to generate a pseudonym that cannot be reconverted mathematically into the original card number. This pseudonym could then be used to register at, for example, eBay, or any other web service that requires personal identification.

I don't yet know the details of how this works.  I would be concerned if the card generates a single pseudonym that remains constant everywhere it is used.   This would still be an “identifier beacon” that could be used to link all your digital activities into a super-profile. Such a profile would be as irresistable to marketers as it would be to organized crime, so we can be pretty sure it would emerge .  If any aspect of this profile is linked to a molecular identity, all of it is.

In a sense, using a pseudonym that ends up creating a super-dossier would be worse than just using an official government identity, since it would create false expectations in the user, breaking the First Law of identity that ensures the transparency of the identity system so the user can control it.

Regardless of the details of the proposal, it is great to see the German government thinking about these issues.  Once you start to look at them, they lead to the requirement to also support “directed identities”.  There are leading academics and policy makers in Germany who are capable of guiding this proposal to safety.  The key here is to take advantage of the new generation of intelligent smart cards, identity selectors and web service protocols.

[Read more on the  e-health Europe site.]

Not the browser!

Google's Ben Laurie bookends our dialog (work back from here) with a really clear statement:

Kim correctly observes that the browser is not the place to be typing your password. Indeed. I should have mentioned that.

Clearly any mechanism that can be imitated by a web page is dead in the water. Kim also wants to rule out plugins, I take it, given his earlier reference to toolbar problems. I’m OK with that. We want something that only a highly trusted program can do. That’s been so central to my thinking on this I forgot to mention it. Sorry.

This sounds really positive.  Now, just so I don't end up with a different security product from every big web site, I hope Ben's work will include integration with the CardSpace framework.  I'm certainly open to discussions about ways we might evolve CardSpace to facilitate this.

Ben Laurie's “Single Passwords”

Given his latest post, I guess I got the gist of Ben Laurie's proposal for using what I'll call “Single Passwords” rather than “Single Signon”:  

“Kim Cameron, bless him, manages to interpret one of my most diabolical hungover bits of prose ever. I am totally with him on the problem of pharming, but the reality is that the average Cardspace user authenticated with nothing better than a password (when they logged into Windows).

Wow.  I appreciate the blessing from Father Laurie, but this is kind of a “We're going to die one day, so who cares if we die tomorrow?” type of argument – surprising for a priest. 

While it's true that pharming is a challenge for the operating system as well as the browser, let's not seriously equate the dangers of entering passwords into browsers (a malleable experience, the goal of which is to be infinitely and easily modified by anyone) with those involved in booting up your PC (a highly controlled environment designed to allow no modification and use a secure desktop).  It's true that both involve passwords.  But the equation is simplistic, best summed up as: “Tables have legs, people have legs, therefore tables are people.”

Anyway, I'm sympathetic to Ben's concerns about portability:

“Furthermore, if you are going to achieve portability of credentials, then you can either do it in dreamland, where all users carry around their oh-so-totally-secure bluetooth credential device, or you can do it in the real world, where credentials will be retrieved from an online store secured by a password.

I don't dismiss dreamland – isn't that what iPhones want to be?  But we do need lightweight roaming.  Using an online vault secured by a passphrase is a reasonable way to bootstrap a secret onto a machine.

But not the browser! 

The rub is:  once a user gets into the habit of typing this secret into the browser, she's ready to be tricked.  I'll go further.  If  the vault one day accrues enough value, a browser-based system WILL fail the user - sooner or later.   

Ben concludes:

“If you believe the Cardspace UI can protect people’s credentials, then surely it can protect a password?

“If it really can’t (that is, we cannot come up with UI that people will reliably identify and eschew all imitations), then how will we ever have a workable, scalable system that includes recovery of credentials after loss or destruction of their physical goods?”

There's food for thought here.  Start to take advantage of the engineering in CardSpace, and you inherit significant protection in terms of both phishing and pharming.  So if Ben implements his “Single Password” this way, he could start to be reasonably confident that the “function of the password” is what is released, while the password is guarded.

Understanding Windows CardSpace

There is a really wonderful new book out on digital identity and Information Cards called “Understanding Windows CardSpace“. 

Written by Vittorio Bertocci, Garrett Serack and Caleb Baker, all of whom were part of the original CardSpace project, the book is deeply grounded in the theory and technology that came out of it.  At the same time, it is obviously their personal project.  It has a personal feeling and conviction I found attractive.

The presentation begins with a problem statement - ”The Advent of Profitable Digital Crime”.  There is a systematic introduction to the full panoply of attack vectors we need to withstand, and the book convincingly explains why we need an in-depth solution, not another band-aid leading to some new vulnerability.

For those “unskilled in the art”, there is an introduction to relevant cryptographic concepts, and an explanation of how both certificates and https work.  These will be helpful to many who would otherwise find parts of the book out of reach.

Next comes an intelligent discussion of the Laws of Identity, the multi-centered world and the identity metasystem.  The book is laid out to include clever sidebars and commentaries, and becomes progressively more McLuhanesque.  On to SOAP and Web Services protocols – even an introduction to SAML and WS-Trust, always with plenty of diagrams and explanations of the threats.

Then we are introduced to the concept of an identity selector and the model of user-centric interaction.

Part two deals specifically with CardSpace, starting with walk-throughs, and leading to implementation.  This includes “Guidance for a Relying Party”, an in-depth look at the features of CardSpace, and a discussion of using CardSpace in the browser.

The authors move on to Using CardSpace for Federation, and explore how CardSpace works with the Windows Communication Foundation.  Even here, we're brought back to the issues involved in relying on an Identity Provider, and a discussion of potential business models for various metasystem actors.

Needless to say, much of what's covered in this book applies to Higgins and OpenInformationCard and Bandit as well as CardSpace. 

Above all, it is a readable book that balances technology with the broader issues of identity.  I imagine almost anyone who reads this blog will have something to gain from it.  I especially recommend it for people who want a holistic introduction to digital identity, CardSpace and web services.  I think the book is excellent for students.  I even expect it will be enjoyed by more than one policy maker who wants to understand the underlying technical problems of identity.

So check it out, and let me know what you think.

[By the way:  One chapter of the book is now online as a stream of html text, but I'd avoid it. The printed layout and interplay of commentaries add both life and interest...]

Booze and Identity

Let's turn to New Zealand's Identity and Privacy Blog for the latest in… news about Canada:  

It’s interesting to see how booze seems to bring up great questions of identity and privacy. Or maybe it’s just the Canadians?

Canadian Dick Hardt uses buying booze as an example in his famous Identity 2.0 presentation and makes very interesting points about using ID, such as a drivers licence, to buy booze.

Now comes another angle from Canada involving booze: if your ID is scanned when entering a bar, would that make you behave? That was one of the issues at the heart of a case decided by the Information and Privacy Commissioner of Alberta.

The Tantra Nightclub in Calgary had a practice of scanning driver licences before allowing people in. Clearly it is collecting and storing personal information as it includes an individual’s photograph, license number, birth date, address, and bar codes with embedded information unique to the individual driver’s license.

The club says that “We’ve got hard data that it works, we that says crime and violence is down in our venues by over 77%.” On the other hand, the Information and Privacy Commissioner described ID scanning as a deterrent to violent behaviour “conjecture” not backed up by hard data and ordered the club to stop the practice.

In terms of consent, the only thing that the complainant agreed to was the club confirming his date of birth off the licence.

This is precisely the kind of situation that the Laws of Identity frowns upon in digital identity systems, in particular User Control and Consent; Minimal Disclosure for a Constrained Use; and Directed Identity. And another example of unjustified expectations from ID cards that knowing a person’s identity somehow magically solves most societal problems.

Wow.  You have to love this nightclub chain.

The owner is apparently bitter.  But he could get around these problems if he would just change the club's name to something more fitting.  How about the Mein Kampf Eagle Lounge?  Then having a functionary scanning ”your papers” would just be part of the show – justifiable by any measure.

The whole report is worth a read, but this argument by Tantra management really stands out:

“The SC System [SecureClub ID System - Kim], as part of the overall comprehensive security system, is intended to act as a deterrent to potential wrongdoers in that all patrons know that their identification is scanned and that therefore they could easily be identified if they were involved in any violent or illegal activity. It is submitted that potential wrongdoers would be less likely to engage in violent or other illegal behaviour if their ability to remain anonymous was removed. It is further submitted that the SC system removes the anonymity of potential wrongdoers, and is therefore one effective component of an effective overall comprehensive security system.”

Hey, come to think of it, we should all have our papers scanned wherever we go, day and night!

Gee, maybe it's that Canadian thing, but it all makes me want to go for a beer.

Eric Norlin takes OpenID to CSOs

Digital ID World's Eric Norlin explains why security executives should pay attention to OpenID in this article from CSO – the Resource for Security Executives

Kim Cameron has posted another thoughtful piece about why he (and by extension Microsoft) is supportive of OpenID. For those of you that don't eat, sleep, dream and breathe identity, Kim is the guy at Microsoft that was responsible for writing the “Seven Laws of Identity,” which led to the idea of an identity metasystem, which effectively gave birth to all kinds of meetings (the “identity gang”), which led to things like OpenID and Higgins really taking off. Bottom line: Kim's a VIP in the identity world (he's also one helluva nice guy).

Kim's main point is this:

“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.”

Its important to note that Kim is thinking about identity ecosystems, not “one protocol to rule them all.” Really, it comes down to making the use of an identity a “ritual.” That sounds a bit off, I know, but hear me out. Believe it or not, the great majority of humanity had its first contact with email in a workplace setting. Now, if the interface (and interaction) for email was substantially different for work-usage and home-usage (or should I say, WorkUsage and HomeUsage?), do you think the adoption curve would've been the same? I don't.

One of the essential points that Kim's been hammering on for a couple of years is that we have to make the underlying “ritual” of using identity similar in a foundational sense.

Yet one more reason why you (as a CSO) should be paying attention to OpenID. After all, people don't always first see and experience things in the workplace.

This matter of influences from the internet converging with the enterprise is incredibly important, and I'm going to expand on it soon.  By the way, it was Eric's encouragement that got me hooked on writing the Laws of Identity.

From “Screen-Names in Bondage” to OpenID

Google's Ben Laurie proposes using “functions of passwords” rather than plain passwords as a way to avoid phishing: 

Kim Cameron writes about fixing OpenID’s phishing problems by using Cardspace. Certainly I agree that using strong authentication to the OpenID provider fixes the phishing problem – but if you have strong authentication, why bother to use OpenID at all? Why not strongly authenticate to the site you are really trying to log into, instead?

Of course, Cardspace is a pretty heavyweight solution for this, so perhaps that’s what Kim’s getting at? It also doesn’t work well if you have more than one machine – moving your credentials around is not something Cardspace does well.

In my view, there’s a sweeter spot for solving this problem than Cardspace (or OpenID, obviously) – and that is to do strong authentication based purely on a password. That way, you can use the same password everywhere, so no problem with moving between machines, but can still resist phishing attacks and don’t have to make yourself linkable across all sites. Obviously supporting this would be way easier than taking the whole of Cardspace on board, but would have all of the immediate advantages. Clearly it would get you nowhere with advanced identity management, but its not like we don’t already have protocols for that and nor does there seem to be much demand for it yet.

I take it Ben is talking about having a toolbar that asks for your password, and transforms it based on the site's identity so you can use the same password everywhere.  Perhaps he is even thinking about a digest protocol where this transformed password would be used to calculate a “proof” rather than transported over the wire.

Phished or Pharmed 

Problem is, such a toolbar is as easily “pharmable” as OpenID is phishable.

How does a user know she is typing her password into the legitimate toolbar – rather than an “evil replica”?  Our experience with toolbars teaches us that is easy to trick a LOT of people into using fakes.  In fact, sometimes the fakes have propagated faster than the real thing!  Once people get used to typing passwords into a toolbar you have truly opened Pandora's Box.

Let's look at what happens when the kind of ”common password” Ben proposes is stolen. In fact, let's compare it to having money stolen. 

If you go into a store and are short-changed, you just lose money in one store.  If you are pick pocketed, you just lose what's in your wallet - you can cancel your cards.  But if your “common password” is intercepted, it is as though you have lost money in ALL the stores you have been in.   And sadly, you will have lost a lot more than money.

The ultimate advantage of moving beyond passwords is that there is then NO WAY a user can inadvertantly give them away.

Is CardSpace too heavy-weight? 

CardSpace should be a lighter-weight experience than it is today.  We're working on that, making it less “in-your-face” while actually increasing its safety.  I also agree with Ben that it needs to be easier to roam credentials.  We're working on that too. 

The point is, let's evolve CardSpace – and the interoperable software being developed by others – to whatever is needed to really solve the relevant privacy and security problems, rather than introducing more half-measures that won't be effective.

So why OpenID?

If that's all true, Ben wonders why we bother with OpenID at all…

The most important reason is that OpenID gives us common identifiers for public personas that we can use across multiple web sites – and a way to prove that we really own them.

That is huge.  Gigantic.  Compare it to the cacophony of ”screen-names” we have today – screen-names in bondage, prisoners of each site.

Technology people are sometimes insulted when you imply they haven't solved the world's problems.  But to be really important, OpenID doesn't have to solve the world's problems.  It just has to do this one common-identifier thing really well.  And it does.  That's what I love about it.

CardSpace doesn't address the same problem.  CardSpace plus OpenID solve it together.