A simple managed payment card example

I talk a lot in this blog about InfoCards, which is a codename for visual representations of digital identities that users can see and click on, and that are associated with various attributes (ultimately claims because they may or may not be true) like name, age, address, nationality – whatever one wants.

When we first came up with the idea of InfoCards we wanted a way for users to be able to see and manipulate digital identities, just like they can see and manipulate documents and files. In the days before folder and file icons it was hard for many users to relate to virtual storage. But the use of icons turned files and directories into “things” that could be easily imagined and grasped. We wanted to do the same thing with identities.

So to give a more concrete idea of what I'm talking about here and in other pieces, when I refer to an identity selector being used to select a digital identity, or an identity being “illuminated”, I'm referring to something that might look like the following (please remember this is just a sketch for the purposes of discussion and that the use of images and trademarks and the like is just to help others follow my proposed thought exercise).

The image shows a PC screen (though it could just as well show a different device) and on it an “identity selector” has appeared. In this “artist's rendition”, a single digital identity has been “illuminated” (the one corresponding to a credit card) because the others can't be employed in the current (purchasing) context.

You may notice the Identity Selector appears on a desktop that I hope will look “grayed out”. This represents the fact that applications running on the normal desktop cannot “see” into (read “steal from”) the identity selector: deep in the operating system the two desktops are segregated so the InfoCard surface is, compared to conventional programs, secure.

Our studies show it is best to leave the user's previous context visible but grayed out when the identity selector comes to the fore so the user understands the relationship between the identity selection what she was previously doing. This way she can also develop a sense of the relative safety of the identity selection environment.

The only InfoCard representations (e.g. Cards) that appear are ones the user has created or downloaded and installed, so the contents of anyone's identity selector are hard for an attacker to predict. Further, the user can customize the card images. Together these features distinguishe any given identity selector from any other, making it difficult for an attacker to social engineer a phony identity selector.

The InfoCard representations link to “metadata” containing the URL where an identity provider is located, the types of technologies it supports, what kind of authentication it employs, and the like. So there is no tangible identity data worth stealing in the InfoCard metadata itself.

Returning to the example of the credit card identity recently used as an example, here's a high-level view of how the different pieces work together:

In this example a shopping site wants a payment identity, and supports use of InfoCards as a way of submitting it (note: the site need not relinquish other tried and true mechanisms – like good old fashioned credit cards with billing address, secret numbers, and the possibility of phraud – in order to upgrade to InfoCards).

As well, in this example the bank has previously provided the user with a banking InfoCard for use in credit transactions (this could have been downloaded from the bank using existing credentials, or a one-time password).

The shopping site has embedded a few lines of html in its check-out page that cause the Identity Selector described above to pop when people decide to do a purchase (this html will not cause problems or be visible to clients that don't use InfoCards).

If the user chooses to proceed, the identity selector authenticates the user to the bank and then employs WS-Trust to request a token. (think of it as a coupon). In this example the coupon includes a one-time credit card number – meaning that it will only work during the transaction in which it is released.

The identity selector sends the coupon on to the web site, which can validate that the transaction completes but needn't concern itself with whether the user employed a stolen card – the bank has already done the necessary authentication.

One can imagine this scenario being done in dozens of other ways. For example, one-time credit cards need not be usedz. But I leave that as an exercise for the reader's imagination.

Note that the way the identity provider works, the type of token, the kind of authentication, the content of the coupon, the branding of the card, the crypto mechanisms employed, the way identifiers are used, and many other aspects are left up to the identity providers and relying parties. In other words, the system is a platform in which other systems can play and get wide distribution.

Also, for those who just arrived at the party, the software for the relying parties and identity providers can be written in any language on any operating system on any platform using WS-Trust and associated protocols. Similarly, I am hopeful people will build identity selectors embodying the ideas described here on other platforms and devices.

[tags: , , , ]

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: , , , ]