Kim Cameron's excellent adventure

I need to correct a few of the factual errors in recent posts by James Governor and Jon Udell.  James begins by describing our recent get-together:

We talked about Project Geneva, a new claims based access platform which supersedes Active Directory Federation Services, adding support for SAML 2.0 and even the open source web authentication protocol OpenID.

Geneva is big news for OpenID. As David Recordon, one of the prime movers behind the standard said on Twitter yesterday:

Microsoft’s Live ID is adding support for OpenID. Goodbye proprietary identity technologies for the web! Good work MSFT

TechCrunch took the story forward, calling out de facto standardization:

Login standard OpenID has gotten a huge boost today from Microsoft, as the company has announced that users will soon be able to login to any OpenID site using their Windows Live IDs. With over 400 million Windows Live accounts (many of which see frequent use on the Live’s Mail and Messenger services), the announcement is a massive win for OpenID. And Microsoft isn’t just supporting OpenID – the announcement goes as far as to call it the de facto login standard [the announcement actually calls it “an emerging, de facto standard” – Kim] 

But that’s not what this post is supposed to be about. No I am talking about the fact [that] later yesterday evening Kim hacked his way into a party at the standard using someone else’s token!  [Now this is where I think some “small tweaks” start to be called for… – Kim]

It happened like this. I was talking to Mary Branscombe, Simon Bisson and John Udell when suddenly Mary jumped up with a big smile on her face. Kim, who has a kind of friendly bear look about him, had arrived. She ran over and then I noticed that a bouncer had his arm across Kim’s chest (”if your name’s not down you’re not coming in”). Kim had apparently wandered upstairs without getting his wristband first. Kim disappeared off downstairs, and I figured he might not even come back. A few minutes later though and there he was. I assumed he had found an organizer downstairs to give him a wristband… When he said that he actually had taken the wristband from someone leaving the party, and hooked it onto his wrist me and John practically pissed our pants laughing. As Jon explains (in Kim Cameron's Excellent Adventure):

If you don’t know who Kim is, what’s cosmically funny here is that he’s the architect for Microsoft’s identity system and one of the planet’s leading authorities on identity tokens and access control.

We stood around for a while, laughing and wondering if Kim would reappear or just call it a night. Then he emerged from the elevator, wearing a wristband which — wait for it — belonged to John Fontana.  Kim hacked his way into the party with a forged credential! You can’t make this stuff up!

While there is certainly some cosmic truth to this description, and while I did in fact back away slightly from the raucus party at the precise moment James says he and Jon “pissed their pants”, John Fontana did NOT actually give me his wristband.  You see, he didn't have a wristband either. 

So let's go through this step by step.  It all began with the invite that brought me to the party in the first place:

As a spokesperson for PDC2008, we’re looking forward to having you join us at the Rooftop Bar of the Standard Hotel for the Media/Analyst party on October 27th at 7:00pm

This invite came directly from the corporate Department of Parties.

I point this out just to ward off any unfair accusations that I just wanted to raid the party's immense Martini bar. Those who know me also know nothing could be further from the truth. You have to force a Martini into my hands.  My attendance represented nothing but Duty.  But I digress.

Protocol Violation

The truth of the matter is that I ran into John Fontana in the cafe of the Standard and we arrived at the party together.  He had been invited because this was, ummm, a Press party and he was, ummm, Press. 

However, it didn’t take more than a few seconds for us to see that the protocol for party access control had not been implemented correctly.   We just assumed this was a bug due to the fact that the party was celebrating a Beta, and that we would have to work our way past it as all beta participants do. 

Let’s just say the token-issuing part of the party infrastructure had crashed, whereas the access control point was operating in an out-of-control fashion.

Looking at it from an architectural point of view, the admission system was based on what is technically called “bearer” tokens (wristbands). Such tokens are NOT actually personalized in any way, or tied to the identity of the person they are given to through some kind of proof. If you “have” the token, you ARE the bearer of the token.

So one of those big ideas slowly began to take root in our minds.  Why not become bearers of the requisite tokens, thereby compensating for the inoperative token-issuing system?

Well, at that point, since not a few of the people leaving the party knew us,  John and I explained our “aha”, and pointed out the moribund token-issuing component.  As is typical of people seeing those in need of help, we were showered with offers of assistance.

I happened to be rescued by an unknown bystander with incredibly nimble and strong fingers and deep expertise with wristband technology.  She was able to easily dislodge her wristband and put it on me in such a way that it’s integrity was totally intact. 

There was no forged token.  There was no stolen token.  It was a real token.  I just became the bearer.

When we got back upstairs, the access control point evaluated my token – and presto – let me in to join a certain set of regaling hedonists basking in the moonlight.  

But sadly – and unfairly –  John’s token was rejected since its donor, lacking the great skill of mine, had damaged it during the token transplant.

Despite the Martini now in my hand, I was overcome by that special sadness you feel when escaping ill fate wrongly allotted to one more deserving of good fortune than you.  John slipped silently out of the queue and slinked off to a completely different party.

So that's it, folks.  Yet the next morning, I had to wake up, and confont again my humdrum life.  But I do so inspired by the kindness of both strangers and friends (have I gone too far?)

 

The Emperor's new clothes

The UK's Register has been running a a series of articles by John Leyden  (here, here and here) about Verified By Visa. (VByV)  Verified By Visa uses the same kind of “site redirection” I've written about many times with respect to OpenID and other password-based federation technologies – but in this case it is a banking password that can be stolen.

The phishing scenario is simple enough.  If you happen onto an “evil” site and are tricked into purchasing something, it can “misdirect” your browser to a counterfeit VByV signon page.  As John explains, you have little chance, as a user, of knowing you are being duped, but once you enter your password it is available to the evil site for both instant use an future reuse.  Those familiar with this site will understand that this is yet another example of an attack that cannot be made against Information Card users.

Beyond focussing attention on the phishing problems inherent in “site redirection” approaches, John argues that the system – though claiming to be more secure – is actually just as vulnerable as non-VByV mechanisms.  He then argues – and I have know knowledge as to whether this is the case – that the false claims about increased security are being used to reject complaints by end-users about irregularities and fraudulent purchases made in their name.  If that were true, it would be scandalous.

Friends, this is a case of “The Writing on the Wall”.  I think people in the industry should see John's work as a sign of what's to come.   He is the guy in the fable who is shouting out that “the Emperor has no clothes!”  And he's doing it cogently to the wide readership of the Register.

If I were an advisor to the emperor at this point I would insist on two things: 

  1. admit the vulnerability of all systems based on “site redirection”; and
  2. start getting into phishing-resistant technologies like Information Cards while one's modesty can still be protected.

John makes his points without the stench of jargon.  In spite of this, North American readers will require a dictionary to follow what he's saying (I did).  I'm talking here about a dictionary of British idioms (thanks to my friend Richard Turner for boosting my vocabulary on this one) :

punter n guy. A punter is usually a customer of some sort (the word originally meant someone who was placing bets at a racecourse)…

To see a bit of what mainstream press worldwide will be writing about as the paucity of redirection technology for long-tail scenarios is concerned, I do suggest looking first hand at these articles.  One small taste:

Both Verified by Visa (VbyV) and MasterCard's equivalent SecureCode service are marketed as offering extra security checks to online purchases. Importantly, the schemes also transfer liability for bogus transactions away from merchants who use the system back towards banks (and perhaps ordinary e-commerce punters).

Online shoppers who buy goods and service with participating retailers are asked to submit a VbyV or SecureCode password to authorise transactions. These additional checks are typically submitted via a website affiliated to a card-issuing bank but with no obvious connection to a user's bank.

Punters aren't informed up front that a merchant has signed up to Verified by Visa. Sites used to authenticate a VbyV or SecureCode password routinely deliver a dialogue box using a pop-up window or inline frame, making it difficult to detect whether or not a site is genuine.

The appearance of phishing attacks hunting for Verified by Visa passwords are among the reasons some punters are wary of the technology.

Once obtained by fraudsters, either by direct phishing attack or through other more subtle forms of social engineering trickery, VbyV login credentials make it easier for crooks to make purchases online while simultaneously making it harder for consumers to deny responsibility for a fraudulent transaction…

The little-publicised mandatory use of the technology by some banks means that those with reservations have an uphill struggle to opt out of the scheme…

Verified by Visa and Mastercard SecureCode are there purely to protect the banks, not the card holder. They offer zero additional protection to the consumer, but allow the bank to claim that transactions using purloined credit card credentials were really made by the card holder. It is as simple as that.

[More here}.

 

IIW 2008B November 10-12 in Mountain View

The next Internet Identity Workshop (IIW) is coming up in November.  Identity Woman Kaliya and Phil Windley do a great job running this, and I did a double take reading Kaliya's list of what was accomplished there.  It really happened.

If you attend, you'll meet people thinking deeply about identity from a hundred points of view – and doing great software.   Here's Kaliya's description:

The community that comes together at the workshop is really amazing.  It is a working meeting for a range of groups focused on the technical, social and legal issues arising with the emergence identity, relationship and social layer of the web. The key thought leaders in the area are all there in a highly interactive environment.

We have been focused on “user-centric identity” – considering how end-users, regular people, can manage their own identity across the range of websites, services, companies and organizations that they belong to, purchase from and participate with.

A lot has happened since we first met in the fall of 2005 in Berkeley:

  • We have several foundations that have formed around key technologies – OpenID and Information Cards.
  • LIberty Alliance continues to be actively involved in the community
  • OASIS TC's have started actively participating.  
  • The Vendor Relationship Management project has sprung up out of the community continues to evolve. 
  • OSIS – (Open Source Identity Systems) was founded at IIW and is working on its 4th major interop event happening at DIDW next week (#3 was at RSA in the spring).

 As a community we have been exploring these kinds of questions:

  • How are social networking sites and social media tools applying user-centric identity?
  • What are the open standards to make it work? (identity and semantic)
  • What are technical implementations of those standards?
  • How do different standards and technical implementations interoperate?
  • What are the new social norms and legal constructs needed to make it work?
  • What tools are needed to make it usably secure for end-users?
  • What are the businesses cases / models that drive all this?

 You can check out our community aggregate blog http://www.planetidentity.org

Here is my blog on the conference http://www.identitywoman.net/?p=784

 Who comes to  IIW?:

  • Anyone interested in identity (user profiles, social linking, user history & metadata etc) on the web and in digital systems. 
  • Entrepreneurs  who are working companies about people and their identities online – profiles, social linking, group formation. Basically those doing ANYTHING with the word SOCAIL in it.
  • Product Managers who are trying to figure what to do now and plan for interms of user-identity and information sharing in your product. 
  • Engineers/Programmers who have to implement the emerging standards that are covered at IIW.
  • Researchers/Academics studying identity online. 
  • Lawyers who are interested in end-user agreements and how new technologies change/improve how people interact with companies.
  • Sociologists, Anthropologists who are considering online life and the implications of identity online.

This is a conference where you get out of it what you want.  If you have something to present you are most welcome to. If you have questions you need answers to you can find them.

You can read what community members have said about the quality of the event.

Cost:

The event is VERY affordable for a 2.5 day high quality conference with the leading professionals in the industry.

  • Students – $50
  • Independents (small startups, nonprofits)- $200
  • Corporate – $350

 

The Identity Metasystem and its Identity Selectors

Paul Madsen at ConnectID makes a good point in his “Could someone hand me that hammer please?”

I have a dead horse here that needs some beating.

Does  ‘identity metasystem’ not imply “a pluralism of operators and technologies”? Isn't this even almost a law?

If so, should a TC focused on a single (albeit important) identity technology claim within its name the ‘meta’ scope?

The OASIS Identity Metasystem Interoperability (IMI) Technical Committee will work to increase the quality and number of interoperable implementations of Information Cards

The IMI TC's mandate respects the ‘pluralism of operators’ required by the metasystem definition, but not the other piece.

NB: Any comment that includes any combination of  ‘forgot SAML token’ will be summarily rejected.

 

Metasystem and Identity Selector

Paul is completely right that the Identity Metasystem is a unifying model intended to bring together many contributing technologies – including Kerberos, PKI, browser-only federation protocols like SAML, WS-Security, WS-Trust and lightweight protocols like OpenID.  And in fact, reaching across this diversity is the most important thing about it.  Breadth is what allows us, as an industry, to create “one identity model” in terms of application development, deployment and most important, user experience.

To make this vision a reality, we need a component of the metasystem that has been missing: a common “Identity Selector”  (early examples being CardSpace and DigitalMe). 

Clearly such an important component needs to evolve in the context of an international standards body, so the announcement of the new OASIS Technical Committee dedicated to Information Cards and their interoperability is an important milestone:

Boston, MA, USA; 23 September 2008 — OASIS, the international open standards consortium, has formed a new group to enable the use of Information Cards to universally manage personal digital identities. The OASIS Identity Metasystem Interoperability (IMI) Technical Committee will work to increase the quality and number of interoperable implementations of Information Cards. A rapidly-developing, Web 2.0-friendly method for shared light authentication, Information Cards let people authenticate themselves on multiple web sites without maintaining passwords for each site.

But back to the name 

While I think Information Cards are beneficial to the whole metasystem, they are not themselves the metasytem, and don't encompass all aspects of its interoperability. 

For this reason, I don't personally think the OASIS committee's name is currently quite right.

I've never personally participated in OASIS or any other standards body (I have great respect for those who do.)  So I have no idea whether it is possible to tweak a name once a committee is formed.  If it didn't turn into a major time-waster, I think doing so would show everyone's respect for all the other contributions being made to the metasystem.  I would prefer a name that is more technically specific, like the OASIS Identity Selector Interoperability Technical Committee (ISI).

The people who put in the effort to set up the committee and come up with a name will rightly say, “I wish you had given us that feedback earlier” – and I accept that criticism.  Maybe I have missed my opportunity to provide feedback.  Basically, I was sufficiently excited about the emergence of the committee, and convinced that the Identity Selector did contribute to Metasystem Interoperability, that the potential issues with the name didn't jump out at me. 

And now to Occam

And now for something completely different.  In a recent post Paul also reveals the origins of the third law of identity, and makes a great connection:

“William of Occam was a 14th century English philosopher, best know for his ‘principle of parsimony‘ in comparing different explanations for some phenomena.

entia non sunt multiplicanda praeter necessitatem

“When translated and applied to identity, it's clear that Kim's Law 3 was preempted by some 700 years

entities must not be multiplied beyond necessity

Are Countrywide's systems designed around need to know?

I'm mad as hell and I'm not taking it any more

It was inevitable, given how sloppy many companies are when handling the identity of their customers, that someone would eventually steal all my personal information.  But no matter how much science you have in your back pocket, it hurts when you get slapped in the face.

The theory is clear:  systems must be built to withstand being breached.  But they often aren't.

One thing for sure: the system used at Countrywide Mortgage was so leaky that when I phoned my bank to ask how I should handle the theft, my advisor said, “I don't know.  I'm trying to figure that out, since my information was stolen too.”  We commiserated.  It's not a good feeling.

And then we talked about the letter.

What a letter.  It is actually demented.  It's as though Countrywide's information systems didn't exist, and weren't a factor in any insider misbehavior. 

I agree there was a bad employee.  But is he the only guilty party?  Was the system set up so employees could only get at my personal information when there was a need to know? 

Was the need to know documented?  Was there a separation of duties?  Was there minimization of data?  Can I see the audit trails?  What was going on here?  I want to know.

My checks rolled in to Countrywide with scientific precision.  No one needed to contact me through emergency channels.  Why would anyone get access to my personal information?  Just on a whim?  

How many of us were affected?  We haven't been told.  I want to know.  Iit bears on need to know and storage technologies.

But I'm ahead of myself.  I'll share the letter, sent by Sheila Zuckerman on behalf of “the President” (“President” who??).

We are writing to inform you that we recently became aware-that a Countrywide employee (now former) may have sold unauthorized personal information about you to a third party. Based on a joint investigation conducted by Countrywide and law enforcement authorities, it was determined that the customer information involved in this incident included your name, address, Social Security number, mortgage loan number, and various other loan and application information.

We deeply regret this incident and apologize for any inconvenience or concern it may cause you. We take our responsibility to safeguard your information very seriously and will not tolerate any actions that compromise the privacy or security of our customers’ information. We have terminated the individual's access to customer information and he is no longer employed by Countrywide. Countrywide will continue to work with law enforcement authorities to pursue further actions as appropriate.

I don't want to hear this kind of pap.  I want an audit of your systems and how they protected or did not protect me from insider attack.

If you are a current Countrywide mortgage holder, we will take necessary precautions to monitor your mortgage account and will notify you if we detect any suspicious or unauthorized activity related to this incident. We will also work with you to resolve unauthorized transactions on your Countrywide mortgage account related to this incident if reported to us in a timely manner.

I find this paragraph especially arrogant.  I'm the one who needs to do things in a timely manner although they didn't take the precautions necessary to protect me. 

As an additional measure of protection, Countrywide has arranged for complimentary credit monitoring services provided by a Countrywide vendor at no cost to you over the next two years. We have engaged ConsumerInfo.com, Inc., an Experian® Company, to provide to you at your option, a two-year membership in Triple Advantage Credit Monitoring.  You will not be billed for this service. Triple Advantage includes daily monitoring of your credit reports from the three national credit reporting companies (Experian, Equifax and TransUnion®) and email monitoring alerts of key changes to your credit reports.

Why are they doing this?  Out of the goodness of their hearts?  Or because they've allowed my information to be spewed all over the world through incompetent systems?

To learn more about and enroll in Triple Advantage, log on to www.consumerinfo.com/countrywide and complete the secure online form. You will need to enter the activation code provided below on page two of the online form to complete enrollment. If you do not have Internet access, please, call the number below for assistance with enrollment.   You will have-90 days from the-date of-this letter-to-use the code to activate the credit monitoring product.

Borrower Activation Code: XXXXXXXXX

And now the best part.  I'm going to need to hire a personal assistant to do everything required by Countrywide and still remain employed:

In light of the sensitive nature of the information, we urge you to read the enclosed brochure outlining precautionary measures you may want to take. The brochure will guide you through steps to:

  • Contact the major credit bureaus and place a fraud alert on your credit reports;
  • Review your recent account activity for unauthorized charges or accounts;
  • Be vigilant and carefully review your monthly credit card and other account statements over the next twelve to twenty-four months for any unauthorized charges; anTake action should any unauthorized activity appear on your credit report.

I need more information on why I only need to be vigilant for twelve to twenty-four months, when, thanks to Countrywide, my personal information has spilled out and I have no way to get it back!

We apologize again that this incident has occurred and for any inconvenience or worry it may have caused.  If you have questions, please call our special services hotline at 1-866-451-5895, and a specially trained representative will be ready to assist you.

Sincerely,

Sheila Zuckerman
Countrywide Office of the President
Enclosure

O.K.  This is going to be a long process.  It drives home the need for data minimization.  It underlines the need for stronger authentication.  But EVERY case like this should make us deeply question the way our systems are structured, and ask why there are no professional standards that must be met in protecting private information.

When a bridge collapses, people look into the why of it all.

We need to do that with these identity breaches too.   As far as I'm concerned, Countrywide has a lot of explaining to do.  And as a profession we need clear engineering standards and ways of documenting how our systems are protected through “need to know” and the other relevant technologies.

Finally, we all need to start making insider attacks a top priority, since all research points to insiders and our number one threat.

 

Hole in Google SSO service

Some days you get up and wish you hadn't.  How about this one:

Google SSO problem

The ZDNet article begins by reassuring us:

“Google has fixed an implementation flaw in the single sign-on service that powers Google Apps follow a warning from researchers that remote attackers can exploit a hole to access Google accounts.

“The vulnerability, described in this white paper (.pdf), affects the SAML Single Sign-On Service for Google Apps.

“This US-CERT notice describes the issue:

“A malicious service provider might have been able to access a user’s Google Account or other services offered by different identity providers. [US-CERT actually means ‘by different service providers’ – Kim]

“Google has addressed this issue by changing the behavior of their SSO implemenation. Administrators and developers were required to update their identity provider to provide a valid recipient field in their assertions.

“To exploit this vulnerability, an attacker would have to convince the user to login to their site

Incredibly basic errors

The paper is by Alessandro Armando,  Roberto Carbone, Luca Compagna, Jorge Cuellar, and Llanos Tobarra, who are affiliated with University of Genoa, Siemens and SAP, and is one of an important series of studies demonstrating the value of automated protocol verification systems.

But the surprising fact is that the errors made are incredibly basic – you don't need an automated protocol verification system to know which way the wind blows.  The industry has known about exactly these problems for a long time now.   Yet people keep making the same mistakes.

Do your own thing

The developers decided to forget about the SAML specification as it's written and just “do their own thing.”  As great as this kind of move might be on the dance floor, it's dangerous when it comes to protecting peoples’ resources and privacy.  In fact it is insideous since the claim that Google SSO implemented a well vetted protocol tended to give security professionals a sense of confidence that we understood its capabilities and limitations.  In retrospect, it seems we need independent audit before we depend on anything.  Maybe companies like Fugen can help in this regard?

What was the problem?

Normally, when a SAML relying party wants a user to authenticate through SAML (or WS-Fed), the replying party sends her to an identity provider with a request that contains an ID and a scope  (e.g. URL) to which the resulting token should apply.

For example, in authenticating someone to identityblog, my underlying software would make up a random authentication ID number and the scope would be www.identityblog.com.  The user would carry this information with her when she was redirected to the identity provider for authantication.

The identity provider would then ask for a password, or examine a cookie, and sign an authentication assertion containing the ID number, the scope, the client identity, and the identity provider's identity.  

Having been bound together cryptographically in a tamperproof form where authenticity of the assertion could be verified, these properties would be returned to the relying party.  Because of the unique ID, the relying party knows this assertion was freshly minted in response to its needs.  Further, since the scope is specified, the relying party can't abuse the assertion it gets at some other scope.

But according to the research done by the paper's authors, the Google engineers “simplified” the protocol, perhaps hoping to make it “more efficient”?  So they dropped the whole ID and scope “thing” out of the assertion.  All that was signed was the client's identity.

The result was that the relying party had no idea if the assertion was minted for it or for some other relying party.  It was one-for-all and all-for-one at Google.

Wake up to insider attacks

This might seem reasonable, but it sure would sure cause me sleepless nights.

The problem is that if you have a huge site like Google, which brings together many hundreds (thousands?) of services, then with this approach, if even ONE of them “goes bad”, the penetrated service can use any tokens it gets to impersonate those users at any other Google relying party service.

It is a red carpet for insider attacks.  It is as though someone didn't know that insider attacks represent the overwhelming majority of attacks.  Partitioning is the key weapon we have in fighting these attacks.  And the Google design threw partitioning to the wind.  One hole in the hull and the whole ship goes down.

Indeed the qualifying note in the ZD article that “to exploit this vulnerability, an attacker would have to convince the user to login to their site” misses the whole point about how this vulnerability facilitates insider attacks.  This is itself worrisome since it seems that thinking about the insider isn't something that comes naturally to us.

Then it gets worse.

This is all pretty depressing but it gets worse.  At some point, Google decided to offer SSO to third party sites.  But according to the researchers, at this point, the scope still was not being verified.  Of course the conclusion is that any service provider who subscribed to this SSO service – and any wayward employee who could get at the tokens – could impersonate any user of the third party service and access their accounts anywhere within the Google ecosystem.

My friends at Google aren't going to want to be lectured about security and privacy issues – especially by someone from Microsoft.  And I want to help, not hinder.

But let's face it.  As an industry we shouldn't be making the kinds of mistakes we made 15 or 20 years ago.  There must be better processes in place.  I hope we'll get to the point where we are all using vetted software frameworks so this kind of do-it-yourself brain surgery doesn't happen. 

Let's work together to build our systems to protect them from inside jobs.  If we all had this as a primary goal, the Google SSO fiasco could not have happened.  And as I'll make clear in an upcoming post, I'm feeling very strongly about this particular issue.

Jerry Fishenden in the Financial Times

It's encouraging to see people like Jerry Fishenden figuring out how to take the discussion about identity issues to a mainstream audience.  Here's a piece he wrote for the Financial Times:

Financial times

If you think the current problems of computer security appear daunting, what is going to happen as the internet grows beyond web browsing and e-mail to pervade every aspect of our daily lives? As the internet powers the monitoring of our health and the checking of our energy saving devices in our homes for example, will problems of cybercrime and threats to our identity, security and privacy grow at the same rate?

One of the most significant contributory causes of existing internet security problems is the lack of a trustworthy identity layer. I can’t prove it’s me when I’m online and I can’t prove to a reasonable level of satisfaction whether the person (or thing) I’m communicating or transacting with online is who or what they claim to be. If you’re a cybercrook, this is great news and highly lucrative since it makes online attacks such as phishing and spam e-mail possible. And cybercrooks are always among the smartest to exploit such flaws.

If we’re serious about realising technology’s potential, security and privacy issues need to be dealt with – certainly before we can seriously contemplate letting the internet move into far more important areas, such as assisting our healthcare at home. How are we to develop such services if none of the devices can be certain who or what they are communicating with?

In front of us lies an age in which everything and everyone is linked and joined through an all pervading system – a worldwide digital mesh of billions of devices and communications happening every second, a complex grid of systems communicating within and between each other in real time.

But how can it be built – and trusted – without the problem of identity being fixed?

So what is identity anyway? For our purposes, identity is about people – and ”things”: the physical fabric of the internet and everything in (or on) it. And ultimately it’s about safeguarding our security and privacy.

If we’re to avoid exponential growth of the security and privacy issues that plague the current relatively simple internet as we enter the pervasive, complex grid age, what principles do we adhere to? How can we have a secure, trusted, privacy-aware internet that will be able to fulfil its potential – and deserve our trust too?

The good news is that these problems are already being addressed. Technology now makes possible an identity infrastructure that simultaneously addresses the security and public service needs of government as well as those of private sector organisations and the privacy needs of individuals.

Privacy-enhancing security technologies now exist that enable the secure sharing of identity-related information in a way that ensures privacy for all parties involved in the data flow. This technology includes ”minimal disclosure tokens” which enable organisations securely to share identity-related information in digital form via the individuals to whom it pertains, thereby ensuring security and privacy for all parties involved in the data flow.

These minimal disclosure tokens also guard against the unauthorised manipulation of our personal identity information, not only by outsiders such as professional cybercrooks but also by the individuals themselves. The tokens enable us to see what personal information we are about to share, which ensures full transparency about what aspects of our personal information we divulge to people and things on the internet. This approach lets individuals selectively disclose only those aspects of their personal information relevant for them to gain access to a particular service.

Equally important, we can also choose to disclose such selective identity information without leaving behind data trails that enable third parties to link, trace and aggregate all of our actions. This prevents one of the current ways that third parties use to collate our personal information without our knowledge or consent. For example, a minimal disclosure token would allow a citizen to prove to a pub landlord they are over 18 but without revealing anything else, not even their date of birth or specific age.

These new technologies help to avoid the problem of centralised systems that can electronically monitor in real time all activities of an individual (and hence enable those central systems surreptitiously to access the accounts of any individual). Such models are bad practice in any case since such central parties themselves become attractive targets for security breaches and insider misuse. Centralised identity models have been shown to be a major source of identity fraud and theft, and to undermine the trust of those whose identity it is meant to safeguard.

It is of course important to achieve the right balance between the security needs of organisations, both in private and public sectors, and the public’s right to be left alone. Achieving such a balance will help restore citizens’ trust in the internet and broader identity initiatives, while also reducing the data losses and identity thefts that arise from current practices.

Now that the technology industry is currently implementing all of the components necessary to establish such secure, privacy-aware infrastructures, all it takes is the will to embrace and adopt them. Only by doing so will we all be able to enjoy the true potential of the digital age – in a secure and privacy-aware fashion.

Personal information can be a toxic liability…

From Britain's Guardian, another fantastic tale of information leakage:

The home secretary, Jacqui Smith, yesterday denounced the consultancy firm involved in the development of the ID cards scheme for “completely unacceptable” practice after losing a memory stick containing the personal details of all of the 84,000 prisoners in England and Wales.

The memory stick contained unencrypted information from the electronic system for monitoring offenders through the criminal justice system, including information about 10,000 of the most persistent offenders…

Smith said PA Consulting had broken the terms of its contract in downloading the highly sensitive data. She said: “It runs against the rules set down both for the holding of government data and set down by the external contractor and certainly set down in the contract that we had with the external contractor.

An illuminating twist is that the information was provided to the contractor encrypted.  The contractor, one of the “experts” designing the British national identity card, unencrypted it, put it on a USB stick and “lost it”.   With experts like this, who needs non-experts? 

When government identity system design and operations are flawed, the politicians responsible suffer  the repercussions.  It therefore always fills me with wonder – it is one of those inexplicable aspects of human nature – that politicians don't protect themselves by demanding the safest possible systems, nixing any plan that isn't based on at least a modicum of the requisite pessimism.  Why do they choose such rotten technical advisors?

Opposition parties urged the government to reconsider its plan for the introduction of an ID card database following the incident. Dominic Grieve, the shadow home secretary, said: “The public will be alarmed that the government is happy to entrust their £20bn ID card project to the firm involved in this fiasco.

“This will destroy any confidence the public still have in this white elephant and reinforce why it could endanger – rather than strengthen – our security.”

The Liberal Democrats were also not prepared to absolve the home secretary of responsibility. Their leader, Nick Clegg, accused Smith of being worse than the Keystone Cops at keeping data safe.

Clegg said: “Frankly the Keystone Cops would do a better job running the Home Office and keeping our data safe than this government, and if this government cannot keep the data of thousands of guilty people safe, why on earth should we give them the data of millions of innocent people in an ID card database?”

David Smith, deputy commissioner for the information commissioner's office, said: “The data loss by a Home Office contractor demonstrates that personal information can be a toxic liability if it is not handled properly , and reinforces the need for data protection to be taken seriously at all levels.”

Home Office resource accounts for last year show that in March of this year two CDs containing the personal information of seasonal agricultural workers went missing in transit to the UK Borders Agency. The names, dates of birth, and passport numbers of 3,000 individuals were lost.

If you are wondering why Britain seems to experience more “data loss” than anyone else, I suspect you are asking the wrong question.  If I were a betting man, I would wager that they just have better reporting – more people paying attention and blowing whistles.

But the big takeaway at the technical level is that sensitive information – and identity information in particular – needs to be protected throughout its lifetime.  If put on portable devices, the device should enforce rights management and only release specific information as needed – never allow wholesale copying.  Maybe we don't have dongles that can do this yet, but we certainly have phone-sized computers (dare I say phones?) with all the necessary computational capabilities.

 

The Laws of Identity

Thanks to Eric Norman, Craig Burton and others for helping work towards a “short version” of the Laws of Identity. So here is a refinement:

People using computers should be in control of giving out information about themselves, just as they are in the physical world.

The minimum information needed for the purpose at hand should be released, and only to those who need it. Details should be retained no longer than necesary.

It should NOT be possible to automatically link up everything we do in all aspects of how we use the Internet. A single identifier that stitches everything up would have many unintended consequences.

We need choice in terms of who provides our identity information in different contexts.

The system must be built so we can understand how it works, make rational decisions and protect ourselves.

Devices through which we employ identity should offer people the same kinds of identity controls – just as car makers offer similar controls so we can all drive safely.