More on the honeypot

Some good news from Radovan regarding my response to (believe it or not) this.

“That's not your skull there, Kim 🙂

“That would be a terrible waste of good resources, in the first place. The graphic is just a generic reference to mean danger … and to add a bit of dark gothic look, to indicate the current state of “identity technology” :-)”

I'm suddenly feeling more warmly towards Radovan. He continues:

“I have not seen InfoCards as PC-centric solution (but the example I've used caught on well, eh?) :-).

I was just afraid that some people may use InfoCards for pure PC-based identity and still feel secure; or may they propose other PC-based or “self-hosted” solutions. I will write more about it in near future.”

To me everything comes down to handling risk. The InfoCard “self-asserting identity” is immensely harder to subvert than current (password-based) mechanisms for user authentication. The level of assurance it provides is fine for a lot of applications. One cannot compare the difficulty of installing current pharming implements (like keystroke loggers) with what would be necessary to subvert even the most basic InfoCard identity provider.

That said, we must do everything we can to avoid creating a “honeypot” effect – where by centralizing information and access we make attack so potentially lucrative that there is no practical limit to the resources that can be dedicated to devising a breach. We shiver when we see proposals to create such honeypots on centralized servers (as was the case in Britain, for example, with initial proposals for a governmental identity system). The wrong approach could create such a honeypot on PCs as well.

This requirement then conjoins that of having multiple identity technologies and operators providing technological, contextual and topological separation that can be used in different contexts and for different purposes (Fifth Law of Identity). The polymorphism of the approaches means it is impossible to attack them all in one blow.

As an example, let's look at how these ideas might be brought to bear on the use of credit cards on the web.

Recently, I referred to a survey investigating how fear of identity theft is affecting consumer purchases. I went on to say, “As web sites begin to take advantage of InfoCards, users will get an initial upgrade in security…”

Ben Laurie responded:

“You claim that infocard will improve security, which may or may not be so, but has nothing to do with credit card theft. Unless you change the way credit cards are processed (good luck with that: remember what happened to SET, which comprehensively solved this problem), infocard has no impact on the security of online shopping.”

Now Ben is a man who has paid his dues, and his reference to SET conjures up a movie where the mere mention of a name from the past throws all the survivors of a terrible wartime battle into painful trauma. Without going into details, he is referring to the fact that in the ’90s a great deal of intellectual work went into devising a congent technical solution to strenghtening credit transactions with cryptography – but despite heroic efforts it never really saw the light of day at a practical level. (I personally felt exhausted by the SET initiative – and all I did was to review the many drafts of the evolving specifications).

But despite the heavy burden of the past, I think InfoCards can succeed where SET failed. There are several possible approaches, but for the purposes of discussion I will just give one.

In the last few years we have seen the rise of one-time credit card numbers. This is an existing and proven mechanism for reducing phraud (and, just as important, perception of risk) by allowing credit card users to obtain a single-use number they can release instead of their conventional card number.

In the InfoCard environment it is easy to imagine a “managed InfoCard” issued by a bank or some other institution, and which would represent a given credit card within the Identity Selector. In financial transactions, the image of the credit card would be illuminated. If the user selected it, and provided the right PIN, the Identity Selector would contact the “credit card identity provider” and obtain a token containing a one-time password. The long-term credit card number would never be revealed.

The InfoCard system is flexible enough that an identity provider may declare itself to be “auditing” – meaning that it must be told of the identity of the relying party so it can encrypt its payload in a way that only that party can read it. Through this mechanism, the “credit card identity provider” can be certain about exactly who receives any one-time passwords it generates.

One of the advantages of this approach is that from the relying party's point of view, there is no need to know anything about the one-time nature of the credit card number. Further, the coupon delivering the one-time number and signed by the credit card provider would indicate that the provider had verified the user's identity.

In terms of any PC honeypot effect, note that the credit card number is never stored on or revealed to the PC. The encryption channel between the credit card issuer and the merchant (relying party) is as impervious to attack from the PC as any back channel would be.

What I am trying to get at here is that we don't need to look at credit cards as being completely unrelated to other forms of identification. In fact, I suspect that the nature of SET as a complex, esoteric, single-purpose technology was what led to its failure.

[tags: , , , ]

User Centric, not PC Centric

Radovan Semanèík, who publishes Storm Alert, is a Slovak software architect who is also “a swordsman and archer.” He just posted an interesting comment on my piece about overcentralization of identity information. But before I get to it, there is the matter of the strange little graphic he used to enliven his piece (shown at right). Is this a skull crusher? Is this my skull? Or is the reference more generic?

Anyway, we have to stay focussed, and I don't want to be more paranoid than necessary.

Radovan writes:

Kim Cameron blogged today about something that I've been pondering about for some time – Personal Information Centralization.’

‘Overcentralization of identity information increases the risks involved once the idea of a breach is accepted. So does the ability to assemble information from different contexts which should strictly be separated. ‘

‘That's right, I believe. Overcentralization is not good. But that does not apply to server-side only. The information may be overcentralized on the client-side also.

‘Take InfoCards as an example. If we'll use only self-issued claims in the InfoCards system, all the personal information will be stored on one's personal computer. That will make common PC a rewarding target for attack. Do you know how difficult is to hack a PC? I do not. PCs were not much targeted by hackers, yet. There was nothing really important there. But now, it may change … And the PCs are well uniform. Find one good hole and you can hack millions of PCs all around the world in few minutes.

‘I do not think that storing personal data on PC is any better that storing them on a server. Overcentralization is equally bad in both cases, but the “PC case” is much harder to recognize. And the things that are hidden are the worst ones … and that's not limited to computer security.’

As I said recently, we have to assume our systems will one day be compromised. So guess what? I totally agree with Radovan that storing all your data on the PC is no better than storing it all in any other place. Help me get the message out, folks. This is not what the InfoCard system represents.

Let's begin with what the self-asserted identity provider (e.g. the “starter” provider which stores data on the PC itself) is actually intended to do.

When we designed it, we purposely limited it to a narrow subset of personal information – all of which is in fact available in public records. We do not allow the PC-based provider to be used, for example, to store credit card information or social security numbers or other sensitive information on the PC.

We didn't impose these limitations because we thought our design was insecure! Quite to the contrary. We have struggled day and night for a secure design. But we chose this approach because we accept that breaches are inevitable, especially when you are working on building an identity layer for the internet. So you have to ask, how do you minimize the impact of those breaches? In fact, if you can sufficiently reduce that impact, you can remove the economic incentive to attack the system in the first place.

So our strategy is to do what is necessary to promote initial usage of the system while creating an impetus for people to develop and install additional identity providers that distribute storage of contextual information such that no one breach can be catastrophic.

InfoCard identity providers store information in different places – on servers in the sky, in dongles and smart cards, on phones – and can require multiple factors, from secrets stored in your head and on smartcards to fingerprints and other biometrics. The key here is to understand that the InfoCard proposal doesn't put all your information on the PC or concentrate it in a single location.

InfoCards are not PC centric just because they put the user at the center.

I know there are people around who think there must be some bias of vision going on here (if not an outright ploy) given Microsoft's role in powering PCs. But my colleagues and I actually understand that this incredibly hard problem has no silver bullet other than use of every possible resource to create a multi-dimensional solution. Again, this is what led us to the metasystem idea.

[tags: , , , ]

Will we learn?

Straight from the Department of Unfortunate Matters, as reported by Andy McCue on silicon.com.

‘The government has come under fire after it emerged ministers have known for months that criminals were using stolen identities to make £30m of fraudulent online tax credit claims.

‘HM Revenue and Customs (HMRC) was warned about the flaw over six months ago but only closed the tax credit portal down last week after it discovered criminals had used the identities of 1,500 civil servants at the Department of Work and Pensions (DWP) to make fraudulent claims.

‘The tax credit website handles around half a million transactions a year and the fraudsters were able to change claim details and redirect the money into their own bank accounts by getting hold of a genuine claimant's name, date of birth and national insurance number.

‘The latest fraud involving innocent staff at the DWP only came to light during compliance checks by HMRC, and MPs have been told the tax credit website has been hit by over £30m of fraudulent claims.

‘The police have now been called in and a spokesman for HMRC declined to comment further while the criminal investigation is ongoing – but said the tax credit website will remain down until the review of its security is completed.

‘Liberal Democrat Work and Pensions secretary David Laws slammed the government and said ministers must make a statement as to why they took so long to take action to stop the fraud

‘He said: “This complicated and chaotic system is wide open to fraud. Ministers have known for some time that organised criminals were using the internet to defraud the system.”

‘The debacle is yet another embarrassment for the government's flagship tax credits programme, which has suffered from problems since it was launched in 2003. Much of that has been down to an IT system described as a “nightmare” by MPs. EDS was last month forced to shell out £71m to HMRC to settle the dispute over problems with the tax credits IT system.’

The fact that it was possible to use the identities of the employees of the Department of Work and Pensions to create fraudulent claims and redirect money into a criminal bank account boggles the mind. Yet somehow I doubt this project went forward without the usual security reviews and audits.

That's why, for me, this kind of thing always drives home the notion that systems must be designed in light of the assumption that they will be breached, in spite of the security reviews. This may in fact not be true, but even knowing this, it is the best assumption one can make.

In fact, I'm starting to think that failure to do this is an act of professional incompetence.

It should be impossible to get a degree in computer science without demonstrating an understanding of this concept: system designs must include not only security and privacy threat analysis and mitigation strategies, but must indicate how breaches are dealt with so as to minimize damages.

Overcentralization of identity information increases the risks involved once the idea of a breach is accepted. So does the ability to assemble information from different contexts which should strictly be separated.

It is key people see that the privacy requirements of contextual isolation and limitation of information centralization are precisely the same requirements leading to maximal resilience and minimization of risk in the face of attack and breach.

If we care about security, privacy is our friend.

[tags: , , , ]

Banks plan to share cardholder data – but are they allowed to?

Thanks to my British friends for pointing me to this article by Dan Ilett in silicon.com, a CNET property in the UK (FYI, it's a way cool publication.)

Four major credit card issuers are planning to share cardholder information with each other and credit reference agencies.

Abbey, Barclaycard, the Co-operative Bank and Egg have said they will share cardholders’ “behavioural” data in a move they claim will “help identify customers getting into financial difficulty”.

The companies said they are looking to identify changes in circumstances that suggest an individual is experiencing problems with personal debt. The data will also be shared with credit reference agencies Callcredit, Experian and Equifax.

Data that will be shared includes the amount spent and repaid on a credit card each month, changes to credit limits, bounced cheques and spending patterns.

In a statement, Barclaycard CEO Gary Hoffman said: “This move will improve our ability to help customers by making better lending decisions. Whether it's a customer applying for a card or asking for an increased credit limit, the better the information we have access to, the better chance we have of getting the decision right.”

There are laws around how customer data should be used, particularly in ensuring shared data is not used for marketing purposes. But the banking industry has shared data about customers who have fallen behind on payments since the late 1980s.

Today the Information Commissioner's Office, which regulates how consumer and business data is used by companies, said it is investigating exactly what the banks are trying to do.

A spokesman for the department told silicon.com: “We've been in touch with the banks about this and we are currently looking into it.”

Clive Davies, a partner at technology law firm Olswang, said there could be some sticking points in the plan.

He said: “I think there may be confidentiality issues. When you enter into a credit card agreement you probably sign something where you give consent for data to be used with that company. What you probably don't do is give consent to share that information and let companies check you as big brother would to see if you have too much credit.”

According to Barclaycard, MBNA and Nationwide are also supporting the scheme.

This seems to raise almost the same issues as the court decision described here.

New Study from IBM

As the Laws of Identity pointed out:

‘A deepening public crisis [in terms of continuously increasing “phraud”] would mean the Internet would begin to lose credibility and acceptance for economic transactions when it should be gaining that acceptance… The absence of an identity layer is one of the key factors limiting the further settlement of cyberspace.’

Recently another study, this time commissioned by IBM, confirms this observation. According to an article in Information Week:

‘Consumers fear their personal information will be stolen over the holidays and are altering their behavior because of it, according to a new survey commissioned by IBM.

‘Sixty-one percent of respondents in the survey, conducted by Opinion Research Corp., said they believe their bank cards are vulnerable during the holidays. Forty-nine percent of holiday shoppers said they fear their credit and debit information could be stolen, and 46 percent worry about personal information theft.

‘One out of seven Americans, or 14 percent, has had a credit card stolen, according to the sampling of 1,000 adult consumers. Ten percent of the victims said the theft occurred over the holidays. A third of them said it will affect their behavior. Nearly 20 percent plan to avoid or reduce online transactions for the rest of the year.

‘Two-thirds said they are more concerned about fraud and identity theft than they were a year ago. Half said online purchases are most worrisome, and 49 percent said they believe phone transactions are risky.

‘One-third of cardholders who believe they are vulnerable said they would spend less this year on online purchases than they have in the past. Thirty-one percent said they would spend less through catalogs. Twenty-nine percent said they would spend less at stores.

‘Half of the respondents said they would feel more secure with biometrics. One-third said they favor iris scanning. Forty percent said their fears could be alleviated by encryption and technology to prevent forgery, but 75 percent don't plan to upgrade security on their computers.

‘More consumers hold credit card companies responsible for their information than retailers , by a margin of 27 percent to 15 percent. And 26 percent believe individuals are responsible for keeping their information secure. ‘

As web sites begin to take advantage of InfoCards, users will get an initial upgrade in security without earmarking any money for security (a good thing if 75% don't currently plan to upgrade security on their computers!). This stems from use of strong cryptography in the builtin (“starter”) self-asserted identity provider, and “managed” identity providers “run” by third parties.

But let's suppose that later, when purchasing a new computer (or mouse), the user selects one with a built-in fingerprint sensor. How hard will it be to begin taking advantage of that sensor?

In a metasystem, it is possible to factor biometric devices so the system easily incorporates use of new underlying authentication technology.

In this example, after installing the new computer (or mouse), the user can employ InfoCards that require her to present her fingerprint. Later, if she decides she doesn't like using a fingerprint, she can go back to what she was doing before – or try something new. In other words, be human. Importantly, none of these changes require changes to the web sites she visits, which can be insulated from the vagaries of identity technology.

The analogy I'm trying to make is this: we can plug in different keyboards or different video displays until we find one that meets our needs. As users we require the same flexibility in deciding how we protect our identities. At the same time, clearly we can't ask every web site to know all about our identity configurations. Thus the need for an identity metasystem.

[tags: , , , ]

A Guide to Integrating with InfoCard

I have to apologize for dropping out off the face of the earth for a while.

I've been in input mode – meeting with a whole series of absolutely brilliant people from all over the world – and just as many walks of life. I wish I could share the contents of those discussions, but unfortunately all I can do is try to infuse my work with what I've learned.

Meanwhile, some news that really means a lot to me. We have completed all the hoops necessary to publish a really detailed technical explanation of InfoCards that allows anyone and everyone to interoperate with Microsoft products through open web services protocols.

There are two documents. To me, the most important is “A Guide to Integrating with InfoCard v1.0“. I want to thank the people at Ping Identity Corporation – significantly innovative engineers who have already demonstrated interoperability with InfoCards – for helping to put this publication together. I think the result is clear and will make sense to people coming at interoperability from a non-microsoft point of view.

Here's the abstract:

The InfoCard system in the Windows Communications Foundation (WCF) of WinFX allows users to manage their digital identities from various identity providers, and employ them in different contexts where they are accepted to access online services. This Guide describes a model built upon the mechanisms described in [WS-Trust] and [WS-SecurityPolicy] to allow digital identity to be integrated into a user-centric identity framework that promotes interoperability between identity providers and relying parties with the user in control.

The mechanisms described in this document provide the framework for an identity metasystem. The interactions between the InfoCard system and a relying party or an identity provider are illustrated to allow others to create identity systems and applications that can use and interoperate with the Windows InfoCard system in WCF. This document is intended to be read alongside the InfoCard Technical Reference [InfoCard-Ref] which provides the normative schema definitions and behaviors referenced by this document.

What is the status of these documents? We see the relevant standards as being WS-Trust, WS-SecurityPolicy, and WS-Security. The Guide is really a document intended to make it as easy as possible to achieve interoperability with the InfoCard system that will be present in Windows Vista and XP. Our goal has been that no one will have to “reverse engineer” anything to play – it's all described. The authors put it this way:

This draft of the InfoCard Guide reflects what is implemented by the InfoCard system in WCF in the Beta2 release of WinFX. The documented behavior and schema described here are subject to change in the final release of the product.

I want to introduce readers to Arun Nanda, the product architect for InfoCard, and the man responsible for these documents from the Microsoft end. Arun is wonderfully open and innovative by nature. I've had a ball working with him. And no one could have done a better job at conceptualizing and rationalizing the vast array of protocol decisions, nuances and details involved in building a flesh and blood metasystem.

Making InfoCard design decisions clear

I've come across a posting by Ben Laurie which deserves comment. Ben begins this way:

Here’s some specific criticisms. Feel free to correct me if I’m wrong.

  • Law 4, “Directed Identity” says

    “a consumer visiting a corporate Web site is able to use the identity beacon of that site to decide whether she wants to establish a relationship with it. Her system can then set up a “unidirectional” identity relation with the site by selecting an identifier for use with that site and no other. A unidirectional identity relation with a different site would involve fabricating a completely unrelated identifier. Because of this, there is no correlation handle emitted that can be shared between sites to assemble profile activities and preferences into super-dossiers.”

    However, as I’ve shown, this is not actually possible with any traditional type of signed assertion.

  • Apparently, InfoCard kicks ass because its inclusive of other systems. If it were true, then it could fix the problem above by supporting Stefan Brands’ stuff (shame its patented). But, amazingly, despite the claims made, no-one actually knows whether it can!

Actually, I've been working with Stefan to ensure that Credentica (the name of Stefan's system) can work within the InfoCard model. I've said publicly that if it can't, our implementation needs to be fixed. We have figured out several possible implementations, and Stefan's team is moving forward on the analysis. Naturally we want to do a proof of concept and pilot before screaming this from the rooftops. Isn't that OK?

Further, there are additional proposals for “anonymous credentials” coming out of the academic community which also transcend the limitations of X.509 and PKI. I am workjing with other novel proposals in addition to those being made by Stefan. I have been tireless in arguing the need to support new token formats essential to such systems – rejecting the prevelant bugaboo that we should limit all future technology to SAML and then congratulate ourselves on how clever we are. Isn't that OK too?

Beyond this, the basic InfoCard implementation allows the blinding of the identity provider to the identity of the relying party by putting that identity through a one-way function with per-user salt. Any identity provider can then manufacture unidirectional identities and sign assertions without knowing what site they are being submitted to. This has none of the problems of the X.509 certificate, which really is an omnidirectional identifier. I will describe this in more detail as I go through the design decisions behind InfoCard in some upcoming postings.

Ben continues:

  • A specific example given of a system that could be supported is Sxip. Yet I am told that the UI planned for InfoCard is wrong for Sxip. What use is it if the protocols support something but the user has no access to it?

To the extent that sxip wants its own unique user experience that has nothing to do with the user experience of other identity systems, then any common UI is “wrong for Sxip”. But Sxip should be able to distinguish between offering a basic identity experience within the framework of a metasystem (for example, working with InfoCard), and providing a unique value-add through its own supplementary UI (such value-add is a good and great idea).

Ben concludes:

In short, there’s a lot of hype around InfoCard – but it's increasingly unclear to me that it survives close examination. It seems to me that some of these issues could be fixed (linkability with legacy certificates does not strike me as fixable, though), but in the rush to get to market they’re being swept under the carpet.

Nothing is being swept under the carpet. My goal is to deliver increasing clarity as we move forward.

Traditional certificates are linkable. But InfoCard Identity Providers can easily produce unlinkable identity assertions. Systems like Credentica can add further advanced privacy and security properties. Systems like Sxip can expose basic capabilities through the InfoCard UI, and expose value-add in whatever ways make sense for them.

I would say the problem is not that close examination reveals defects in the InfoCard proposals, but that insufficient examination misses on the capabilities being offered and leads to false assumptions.

Is this Ben's fault? No, it's mine. I need to do a much better job of getting these capabilities documented, published and understood. I need to write in a systematic way about the design decisions and capabilities of the Identity Metasystem proposal. Hopefully as that happens we can zero in on things that need to be fixed and extended going forward.

[tags: , , , ]

Sir Jerry?

I chose the article below, entitled “Microsoft slams UK ID card database”, out of more than 10,000 blogosphere and magazine references to Jerry Fishenden's recent piece in the Scotsman (I carried it here.) What an amazing demonstration of the way the Blogosphere can light up when someone says what needs to be said.

Jerry is the National Technology Officer for Microsoft in Britain, and I really commend him for trying to convince the British Home Office to back away from a plan which doesn't at all seem to have been thought through technically or embody the Laws of Identity.

On my recent visits to England, I didn't encounter one individual with an IT background who approved of the current Home Office proposals – whether they were high ranking government officials, industry experts, consultants or people interested in public policy. And I met many hundreds.

Here's the content of the vunet.com article.

Microsoft‘s national technology officer has attacked the UK government's plans for a centralised database supporting the proposed national ID card scheme.

Jerry Fishenden told vnunet.com that current plans for a centralised database with large amounts of information on each person are a mistake, and could lead to “massive identity fraud”.

He went on to criticise the IT industry for not clearly voicing the real concerns.

“It is unnecessary to build a system with all the data in one place,” he said. “The Home Office should be basing the design on the knowledge that any system of that size will be breached, most likely by criminal gangs with huge resources.”

When asked why he was making such statements on the day the Commons voted on the ID Card Bill, Fishenden said only that the IT industry had so far not been getting its views across properly.

“When we attend meetings with the Home Office I have noticed that industry representatives do not voice their concerns very much. Only outside the meetings do you hear their concerns,” he explained.

Fishenden pulls no punches concerning the industry's lack of input so far. ” I do not think that the IT industry has been coherent and consistent enough about the way the ID card system is conceived,” he said.

“Any ID system needs only to keep information that is appropriate to a particular search in one location. That way you reduce the impact of loss or theft by decentralising the data.”

Part of the problem could be because the Home Office liaises with a number of IT industry groups, notably Eurim, Intellect and the British Computer Society (BCS).

Fishenden maintained that his views are supported by the BCS, which has made similar representations to the Home Office.

“The IT industry needs to find a language in relation to privacy and identity to talk to the wider community,” said Fishenden.

Critics may see the attack as a means of pulling the programme more in the direction of Microsoft's view of IT systems.

Fishenden sees no conflict of interest in saying that “decentralised IT is part of Microsoft's philosophy. It's all part of our shared services agenda.”

Again, hats off to Jerry Fishenden – I look forward to seeing him and shaking his hand. I hope one day he will be one of those knighted for bravery, valor, and defense of Britain's identity information. And I continue to hope the Home Office will look at some of the ways they could use cryptography and distribution to build a much safer system capable of achieving the goals they seek without tempting entropy.

The ultimate biometric

Stefan Brands pointed us recently to an editorial by Neils A Bjergstrom, long-time IT security expert and editor of the Information Security Bulletin. As Stefan says, the piece does “a great job of explaining in plain language the most important concerns and issues that ought to be addressed:”

If you still haven't gotten around to reading LSE's report into the UK government's Identity Project you can fetch it here:

It's a bit over 300 pages long and fascinating reading. It concludes – like earlier editorials in ISB – that the proposed project is not feasible, saying that the proposals are too complex, technically unsafe, overly prescriptive and lack a foundation of public trust and confidence. LSE's report also concludes that the risk of failure in the current proposal is therefore magnified to the point where the scheme should be regarded as a potential danger to the public interest and to the legal rights of individuals.

I will add to this that the proposals are particularly unimaginative. Given a blank slate for such a fascinating potentially future-shaping project, is this really the best vision politicians and government employees can come up with?

The whole approach to this project is reactive rather than forward-looking and proactive. The justifications for introducing a national identity system in the Bill include ‘the interest of national security’, ‘the enforcement of prohibitions on unauthorised working’, ‘enforcement of immigration controls’ and ‘prevention and detection of crime’.

These goals seem to be missing: ‘enabling and facilitating a society based on e-commerce’, ‘increasing individual freedom by enhancing anonymity and privacy’, ‘enabling irrefutable authentication of humans to machines’ and ‘providing individuals with transactional security’. These are some of the positive drivers of an eID system, some of the drivers that will actually be able to underpin the acceptance by the public and justify the huge expenses initially associated with establishing and not least running an eID system. I also think that the positive drivers are better predictors of a positive ROI of such a project. In fact I think it will be quite easy to demonstrate a high likelihood of a positive ROI if you follow the path of analysing the potential benefits of an eID system rather than focussing on the preventive measures you can tie to such a system like the legislation does.

For a moment, let us look at the concept of identity. What is an identity? Well, a person normally has a whole range of different identities: the ‘IT trouble-shooter’ on the job, the ‘regional champion’ in the go-kart club, ‘Mrs. Smith’ in the GP's office, etc. Thus, identities are context-specific. They are maintained by individuals as social and economic players in society.

How can one substantiate a claim to a particular identity? By having an employee badge at the job, a membership card in the go-kart club and a National Security card at the medical centre, for example. In other words, by authenticating oneself. An identity can only be substantiated through authentication. This again implies some sort of enrollment process: in order to acquire an identity in a given context you need to enroll. In the UK most identities are based on being able to show documents such as a driving license or utility bills, i.e. resting on an earlier enrollment and its ensuing identity. At the bottom of this hierarchy somebody witnesses a birth and testifies to the fact: Mrs Jones has had a baby girl (who later married Mr. Smith but that is an added complication). Somebody issues a birth certificate, which is recorded by the local registrar of births.

In the 21st century this is of limited use. Even if someone carries her birth certificate it suffers from two problems:

  • the carrier of the document can't prove the connection between the piece of paper and herself
  • machines are not very good at reading paper documents, so authenticating on the basis of a birth certificate always requires human intervention (a man-in-the-middle) and at the end of the day, some other kind of authentication

In a digital world what we need is an irrefutable electronically readable document that can serve as a ‘digital birth certificate’, without the problems of the paper one, in other words, a Root Identity.

This, I would argue, should be the main line of thought when designing an eID system. The eID must serve as a Root Identity.

If you adopt this line of reasoning you find that in order to function in this capacity the eID must have some specific properties:

  • it must be able to bind out to other processes
  • it must specifically be able to facilitate an irrefutable link between its user and itself
  • it must be able to participate in authorisation procedures, in my view without leaking any identity information – helping to answer the question: is this individual allowed to do this in this context? In most cases you do not need identification to answer this type of question
  • it should be able to facilitate authentication processes without compromising identity – allowing anonymity or pseudonymity most of the time is a fundamental requirement of any eID system in a free society
  • it should be able to uniquely represent the legitimate holder (and only the legitimate holder) in public key cryptographic protocols – a consequence of the two points above
  • it should be able to participate in identification processes if identification is required and legitimate
  • it must not depend on irreplaceable personal characteristics, in the sense that the system as such must be able to cope with the problem of compromised or lost/changed characteristics
  • the token containing the eID must be replaceable without unwanted consequences, or as a corollary, theft or loss of a token must not enable impersonation
  • all its functions, including any disclosure of information in the token, must be fully controlled by the owner

There are more necessary factors but I don't have space to write a book about it here. I would like to draw your attention to one extremely important fact, though: a national eID system bears very limited resemblance to a corporate Identity Management system, and the solutions cannot simply be transferred!

Hear! Hear!

Several problems are in evidence here. The issue of irrefutability is not easy. It basically implies that a given token can only function in connection with one particular individual on the planet, and it must not be able to function unless it is provably authorised to do so by that individual.

The system must not rely so heavily on any particular personal characteristic that a compromise or loss of that characteristic (amputation of a finger for example) makes it impossible for the individual to participate.

Both these two problems point at biometric solutions and how these are used. The thing is that unless the token and the person can be irrefutably tied together, an eID is no worse and not much better than a birth certificate and the whole exercise a waste of time and money. To create this tie you need to use some suitable biometric.

There are not many of those – universally usable across races, constant with age, replaceable in case of compromise or loss – in fact I can only think of one: DNA. If you want to know more about how DNA can be used as the basis of eIDs without leaking information or compromising personal details, look at the presentation/paper I gave at InfoSeCon 2005 in Dubrovnik last June. There is no real alternative.

Don't get me wrong here. Using DNA analysis on a day-to-day basis is not technically feasible, nor desirable.

However, for an eID to really constitute a Root Identity DNA must be included (establishing a correct database begins at birth and takes a generation – this is why, even if not used, DNA should be included in a national identity system from the outset. Adding DNA information to an existing database without making too many errors will not be easy). I suggest DNA verification be used mainly in case an individual needs other types of biometrics updated or installed on her eID. This information should not be stored in any database and it doesn't need to be. It is sufficient to store a cryptographic value derived from the information.

The whole system must be as decentralised as possible, building on information inside the eID token (ideally an eID token should only be asked to answer yes or no to (cryptographic) questions, never to give out information stored on the token). Implementations interfacing to the eID system must be subject to strict risk analysis, so that the level of credential asked for is proportional to the risk involved per transaction. Otherwise it gets far too expensive because in many cases multiple biometrics must be used (for the simple reason that any particular biometric system is not sufficiently universal or reliable to be used as a stand-alone system for high-value transactions – ‘value’ in this context does not only mean financial value but e.g. also ‘privacy value’).

With regard to the UK bill I am not going to argue with it here although – technical issues aside – it certainly is an obnoxious piece of legislation, moving the relationship between state and citizen several hundred years back, introducing important components of a totalitarian state by stealth – the ID card part is in a way the least important. It is a piece of legislation that does not belong in a democratic country (which of course, given the role of the unelected House of Lords, the UK isn't anyway).

Technically, it builds on a range of false assumptions, including the pie-in-the-sky idea that technologies to solve these issues exist and can be deployed. This is not the type of project you can simply give to a vendor or two and expect them to be able to deliver. More than anything I can recall ever seeing, this project requires a top-down architectural design process. It is not a vendor-problem that you can throw existing components at. This problem is so complex that it requires close co-operation between scientists, government and vendors. It will take a small extremely competent work group at least a year to identify possible solutions and consequences.

Unfortunately the current bill is so poorly drafted that it can't form the basis for discussion and amendment – back to square one. Normally that would make me complain bitterly over waste of my tax money but in this case there are only a handful of people in the world competent to do it right. Those are the individuals the UK government needs to find.

I think I know the people who can design and produce most of the deliverables but who asks the old editor? 🙂

I have to think a lot more about the use of DNA as the ultimate biometric in a system like this. I am impressed that Neils is himself aware that it carries its own dangers – I'll try to find the hyperlink to his paper. It also strikes me that even if this is theoretically the right thing to do, there is a vast amount of technological progress to be made before initiatives in this regard can be taken safely.

I'd like to know what conclusions Simon Davis, of Privacy International, has come to about this ultimate biometric. I think I'll ask him.

AMs shocked to test positive for drugs

Watching Them Watching Us, from UK's SpyBlog, posted this comment on my piece about the vile GE Entryscan:

I tried one of those GE machines at a security exhibition (priced at about a quarter of a million pounds!). Presumably the air jet blasts have been designed to forever replay the “Marilyn Monroe over a subway grating” scenario.

There is no reason to suppose that these machines are being calibrated or operated any better than the other drug and explosives testing machines which GE sell: False Positives for Drugs in the Welsh Assembly.

What happens to your characteristic “chemical aroma” signature data ? Is it stored and used as a “smell biometric” without your permission, or is it destroyed ?

The very concept of a smell biometric is something I've never considered before. I guess it works for dogs. Perhaps I'll get over it.

Following Watching's link takes you to a really nice page from the SpyBlog, and a very bizarre article about the whole sniffer technology by Gareth Morgan of the Western Mail in Wales. I'm guessing that AM's are representatives elected to the Welsh National Assembly:

‘ALMOST everybody in Wales will have hard drugs on their hands at some point today, according to a cutting-edge detection machine.

‘The problem has reached the point that bank notes, taps and door handles in pubs, nightclubs and even the offices of Wales have traces of class A narcotics.

‘It even infiltrates the National Assembly building in Cardiff Bay.

‘Depending on how cynical one might be about the behaviour of our fine upstanding political representatives, this may not seem the most obvious place to demonstrate the powers of the Ion Track Trace Detector Machine.

‘But AMs were yesterday shocked to discover readings of drugs like heroin and cocaine on their hands. Out of curiosity, they queued to volunteer themselves for trial using the machine with its stern beeping noises and complicated light-up screen. And there were a few raised eyebrows as the machine did its work.

‘Edwina Hart, social justice minister for Wales, tested positive for cannabis after her hands were swabbed using a special cloth.

‘She said, “You could pick it up anywhere, couldn't you?

‘”It could come out of cash, a cash-point, a beer mat, or anything else.

‘”It is a very sophisticated system that can pick up anything, if you have been in contact with someone's jacket or anything.”

‘Conservative AM William Graham organised the demonstration using the first machine introduced to Wales, which is owned by Gwent Police.

‘But even he was shocked to test positive for THC, the chemical found in cannabis. “Good gracious, where the dickens could I have got that from?” he asked.

‘Nick Bourne, leader of the Welsh Conservatives, was one of the AMs who tested negative.

‘He said, “May I pay tribute to the Ion Track system, despite the fact that both the Minister and William Graham tested positive.

‘”I was relieved that I didn't – but it is an excellent system nonetheless.”

‘With their pin stripe suits and attempts to cultivate a clean-cut image, politicians are hardly the stereotype of the drugs criminals that police regularly deal with.

‘PC Simon James, crime prevention officer, said that it showed there was no place to hide.

‘”The major use will be in nightclubs and drug dealers would be an idiot to come into a club with this machine in there.

‘”It is a deterrent and preventive measure really. In Gwent we have a hit-list of 10 pubs and can use this machine to do swabs on tables, chairs and narrow things down to improve our intelligence.

‘”It can be used to search houses. For example in some parts of the UK where there is a problem with crack cocaine they have swabbed microwaves and found traces.”

‘PC James denied that this machine casts suspicion on everybody, and that it is not subjective enough.

‘”The way we interpret the readings plays a big part, as does the way a person reacts if found with traces of drugs on their hands,” he said. “We can adjust the sensitivity and exclude certain drugs depending on how the machine is being used.”

‘Gwent Police had the first machine in Wales but recently two have been installed at Cardiff International Airport and South Wales Police also acquired a machine last week.

‘Despite his positive testing, Mr Graham said he supported the machine. He said, “Anything that deters people from taking drugs is a good thing. If people know this thing exists, then they know they might get caught.”

‘THE £40,000 Ion Track narcotics detection machine will be used in pubs, clubs, schools, workplaces and during roadside checks.

‘The machine is so sensitive it can detect the equivalent in drugs to a grain of salt in an Olympic-sized swimming pool.

‘It works even days after a person has handled drugs or explosives, and no matter how many times they wash, it can pick up traces.

‘A swab paper is wiped over the person's hands and then placed into a slot in the machine.

‘It analyses the swab for a range of drugs, from heroin and cocaine to cannabis and the sports- enhancement drug ephedrine.

‘The levels of contamination on that person's skin are also revealed by the machine, to help police determine how much contact with the substance has been made.

By the way, the price of the aweful and painful GE blaster contraption which I originally wrote about, inferior in every way to a competing product by Smiths, has dropped to a mere $120,000.00. It would be interesting to know how the issues described in the article above affect results.