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…”
“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: InfoCards, Identity Metasystem, Centralization, Threat analysis]
