Category: Digital Identity

Linkage and identification

Inspired by some of Ben Laurie's recent postings, I want to continue exploring the issues of privacy and linkability (see related pieces here and here). 

I have explained that CardSpace is a way of selecting and transferring a relevant digital identity – not a crypto system; and that the privacy characteristics involved depend on the nature of the transaction and the identity provider being used within CardSpace – not on CardSpace itself.   I ended my last piece this way:

The question now becomes that of how identity providers behave.  Given that suddenly they have no visibility onto the relying party, is linkability still possible?

But before zeroing in on specific technologies, I want to drill into two issues.  First is the meaning of “identification”; and second, the meaning of “linkability” and its related concept of “traceability”.  

Having done this will allow us to describe different types of linkage, and set up our look at how different cryptographic approaches and transactional architectures relate to them.

Identification 

There has been much discussion of identification (which, for those new to this world, is not at all the same as digital identity).  I would like to take up the definitions used in the EU Data Protection Directive, which have been nicely summarized here, but add a few precisions.  First, we need to broaden the definition of “indirect identification” by dropping the requirement for unique attributes – as long as you end up with unambiguous identification.  Second, we need to distinguish between identification as a technical phenomenon and personal identification.

This leads to the following taxonomy:

  • Personal data:
    •  any piece of information regarding an identified or identifiable natural person.
  • Direct Personal Identification:
    • establishing that an entity is a specific natural person through use of basic personal data (e.g., name, address, etc.), plus a personal number, a widely known pseudo-identity, a biometric characteristic such as a fingerprint, PD, etc.
  • Indirect Personal Identification:
    • establishing that an entity is a specific natural person through other characteristics or attributes or a combination of both – in other words, to assemble “sufficiently identifying” information
  • Personal Non-Identification:
    • assumed if the amount and the nature of the indirectly identifying data are such that identification of the individual as a natural person is only possible with the application of disproportionate effort, or through the assistance of a third party outside the power and authority of the person responsible… 

Translating to the vocabulary we often use in the software industry, direct personal identification is done through a unique personal identifier assigned to a natural person.  Indirect personal identification occurs when enough claims are released – unique or not – that linkage to a natural person can be accomplished.  If linkage to a natural person is not possible, you have personal non-identification.  We have added the word “personal”  to each of these definitions so we could withstand the paradox that when pseudonyms are used, unique identifiers may in fact lead to personal non-identification… 

The notion of “disproportionate effort” is an important one.  The basic idea is useful, with the proviso that when one controls computerized systems end-to-end one may accomplish very complicated tasks,  computations and correlations very easily – and this does not in itself constitute “disproportionate effort”.

Linkability

If you search for “linkability”, you will find that about half the hits refer to the characteristics that make people want to link to your web site.  That's NOT what's being discussed here.

Instead, we're talking about being able to link one transaction to another.

The first time I heard the word used this way was in reference to the E-Cash systems of the eighties.  With physical cash, you can walk into a store and buy something with one coin, later buy something else with another coin, and be assured there is no linkage between the two transactions that is caused by the coins themselves. 

This quality is hard to achieve with electronic payments.  Think of how a credit card or debit card or bank account works.  Use the same credit card for two transactions and you create an electronic trail that connects them together.

E-Cash was proposed as a means of getting characteristics similar to those of the physical world when dealing with electronic transactions.  Non-linkability was the concept introduced to describe this.  Over time it has become a key concept of privacy research, which models all identity transactions as involving similar basic issues.

Linkability is closely related to traceability.  By traceability people are talking about being able to follow a transaction through all its phases by collecting transaction information and having some way of identifying the transaction payload as it moves through the system.

Traceability is often explicitly sought.  For example, with credit card purchases, there is a transaction identifier which ties the same event together across the computer systems of the participating banks, clearing house and merchant.  This is certainly considered “a feature.”  There are other, subtler, sometimes unintended, ways of achieving traceability (timestamps and the like). 

Once you can link two transactions, many different outcomes may result.  Two transactions conveying direct personal identification might be linked.  Or, a transaction initially characterized by personal non-identification may suddenly become subject to indirect personal identification.

To further facilitate the discussion, I think we should distinguish various types of linking:

  • Intra-transaction linking is the product of traceability, and provides visibility between the claims issuer, the user presenting the claims, and the relying party  (for example, credit card transaction number).
  • Single-site transaction linking associates a number of transactions at a single site with a data subject.  The phrase “data subject” is used to clarify that no linking is implied between the transactions and any “natural person”.
  • Multi-site transaction linking associates linked transactions at one site with those at another site.
  • Natural person linking associates a data subject with a natural person.

Next time I will use these ideas to help explain how specific crypto systems and protocol approaches impact privacy.

Age verification roundup

by Tateru NinoTateru Nino at Second Life Insider has done a roundup of age verification issues arising from Second Life's experiment in controlling access to adult content. 

There's a lot of talk about age/identity verification going on, so I've done a pile of reading of material and logs (thanks for everyone who has provided links, logs and other information to source from) and condensed them into a not inconsiderable bulleted list, below the fold.Longer than your hand, people. Grab a cup of coffee.

  • Credit cards do not provide proof of age. In some areas and with some card providers you can obtain a credit card compatible card before you can talk.
  • Verification costs. It will be available at a token fee for premium account holders, but the brunt of the verification costs apparently will be borne by basic account holders. Linden Lab is passing along the costs of verification.
  • Mobile phones do not provide proof of age. In the UK, more children under 12 possess a mobile phone than adults over 18. In the USA, almost 50% of children have a mobile phone.
  • Driver's licences are not as widely held as you might think. Particularly the old, infirm or handicapped may not possess them. Areas with highly developed public transport systems, or poorer nations may have low penetration of these credentials.
  • Online verification does not verify the person, only the validity of the documentation that person provides. The person need not provide their own documentation for verification to be successful. Therefore, this system can only realistically be used to shift blame and does not constitute a method of verification or trust.
  • The status of a minor who has provided false verification information can (apparently) no longer be contested. If it says they're of a certain age, would it be harassing behavior to attempt to challenge that?
  • Linden Lab is apparently wishes to use a third-party company to keep verification costs down, and to prevent access to or storage of verification information by Linden Lab employees.
  • The age at which you are considered to be permitted to access ‘adult content’ varies from country to country. In most, the age varies between 12 and 25. A very few jurisdictions do not permit it under any circumstances. In most US Jurisdictions the age for the apparent class of adult content Linden Lab intends to grant access to would be 21, not 18.
  • Having taken steps to attempt to verify the age of a user, and then granted them access to adult content, does Linden Lab them become liable if you are still not eligible to be transmitted adult content in your jurisdiction? Does it even matter if the age/identity is accurate or not?
  • The verification provider may not demand or require any information from you. However, they are under no obligation to provide verification for you if you do not willingly provide it.
  • Integrity Services was initially given as the verification provider, however there is good cause to believe that the provider will change before plans go ahead.
  • Merely requesting an SIN identification from a Canadian citizen constitutes a legal offense. This policy may extend to other forms of identifying information in various countries.
  • Linden Lab provides only very vague guidelines for what does and does not constitute ‘adult content’. These are “adult content is that which is overtly, graphically, or explicitly sexual in nature or intensely violent”, which obviously leaves a lot of open questions.
  • The guidelines of most nations are vague on what constitutes adult content. In some cases, certain kinds of political content may fall under this classification. In India, “scenes that are a threat to the integrity to the nation, and those which disturb the friendly peace between nations” are classifiable as adult content.
  • Flagging parcels that contain adult content is mandatory.
  • Adult content flagged parcels must be within Mature sims.
  • It is inevitable that the judgement of an individual based on their own society's and community's standards and norms will unintentionally disagree with the judgement of one or more other residents or Linden Lab staff members. What will happen then? Will Linden Lab exercise editorial control, or assign punishments or penalties?
  • Verification may not be accessible to Linden Lab or verification service employees but must be archived for a period of time that may changed or extended by law before that that period expires. Can it be extended by other means (eg: Company policy?).
  • Archived verification data may be accessed during an audit. Who can initiate an audit of this data, and under what circumstances?
  • Will this archived verification data be subject to the European Union's DPA legislation, as would be required if any EU citizen's data is stored/archived?
  • Do you know what your nation's policy is on providing your passport number to overseas third parties?
  • The Second Life website already requests that users state using a check box that they are over the age of 18. By checking this box, users are making a statement that may be held as truth in a court of law. In short, they can and will be held responsible if this statement is later shown to be untrue. Why is it necessary for Linden Lab to perform an expensive operation like this that appears to only increase their overall legal exposure? What are we missing?

The author concludes:

Whew. What did I miss?

Ben Laurie on Selective Disclosure (Part 1)

Google's Ben Laurie has a new paper called Selective Disclosure in which he argues the importance of zero knowledge proofs and privacy-enhancing cryptography. I fully share his view of the importance of these technologies.

Everyone with a technical interest in identity should look at Credentica’s recently released SDK, called U-Prove. It holistically embodies the cryptographic breakthroughs of Stefan Brands.

There is also a competing system from IBM called IDEMIX, though it is not yet publicly available and I can't talk about it first-hand.

On his way toward explaining how these systems work, Ben takes the time to put forward his own Laws of Identity (“Let a thousand flowers bloom!”)  He is responding to my Fourth Law, which asserts the need for the Identity Metasystem to support both public identifiers (for example, my blogging address) and private ones (my account number with a given company, unknown to anyone but me and them).  He says:

“For an identity management system to be both useful and privacy preserving, there are three properties assertions must be able to have. They must be:

  • Verifiable: There’s often no point in making a statement unless the relying party has some way of checking it is true. Note that this isn’t always a requirement – I don’t have to prove my address is mine to Amazon, because its up to me where my goods get delivered. But I may have to prove I’m over 18 to get alcohol delivered.
  • Minimal: This is the privacy preserving bit – I want to tell the relying party the very least he needs to know. I shouldn’t have to reveal my date of birth, just prove I’m over 18 somehow.
  • Unlinkable: If the relying party or parties, or other actors in the system, can, either on their own or in collusion, link together my various assertions, then I’ve blown the minimality requirement out of the water.”

These are important things for the Identity Metasystem to support, and I make the same points in my own version of the laws. But I don't think these characteristics are the whole story – rather, they describe requirements for certain use cases.  However, there are other use cases, and it was the goal of the original Laws of Identity to embrace them as well.

For example, when I blog I want to use an identity that is linkable. I want anyone who is interested in my ideas to be able to talk about them with anyone else, and tell them how to get to my web site, which is – in the most literal sense of the word – a “linkable” characteristic of my identity.

And when accessing my bank account through the internet, I would rather like to ensure that the party withdrawing the money is tightly linked to a real-world person – hopefully me.

So we don't always want our identity to be unlinkable. We want unlinkability to be one of our options.

Similarly, I don't want every assertion I make to be verified by some bureaucratic process. I don't run around in the molecular world armed with official documents that I present to every Tom, Dick and Harry.  Again, I want verifiability to be one of my options, but not more than that. We need to be careful about what we wish for here. Requiring individuals to employ identities verified by third parties in contexts where there is no good reason for it is a slippery and dangerous slope. So I hope that's not what Ben has in mind.

When using a public identity (which I call “omnidirectional” because you share it with everyone) I may want to divulge more information than is necessary for some specific purpose. So even the notion of minimal disclosure doesn't apply within certain contexts and when public personas are involved.

Thus I take Ben's real point to be that an important and mainstream use case is one where verifiability, minimal disclosure AND unlinkability, should all be achievable at the same time.  This I agree with.

What strikes me as strange in Ben's document is this comment:

“Note a subtle but important difference between Kim’s laws and mine – he talks about identifiers whereas I talk about assertions. In an ideal world, assertions would not be identifiers; but it turns out that in practice they often are.”

I say “strange” because when you actually read the Laws of Identity this is what you will find:

We will begin by defining a digital identity as a set of claims made by one digital subject about itself or another digital subject. (page 4)

Is what I called a claim different from what Ben calls an assertion?  Well, on page 5 of the Laws, I wrote (citing the Oxford English Dictionary, well known to Ben):

A claim is, “…an assertion of the truth of something, typically one which is disputed or in doubt”.

Clearly I'm going a bit beyond Ben's concerns in that I remind the reader that assertions must be evaluated, not just made.  But in no way can I be said to confuse identifiers and digital identity.  In fact, I go on to give some examples which make my ideas in this regard perfectly clear.  (page 5). 

  • A claim could just convey an identifier – for example, that the subject’s student number is 490-525, or that the subject’s Windows name is REDMOND\kcameron. This is the way many existing identity systems work.
  • Another claim might assert that a subject knows a given key – and should be able to demonstrate this fact.
  • A set of claims might convey personally identifying information – name, address, date of birth and citizenship, for example.
  • A claim might simply propose that a subject is part of a certain group – for example, that she has an age less than 16.
  • And a claim might state that a subject has a certain capability – for example to place orders up to a certain limit, or modify a given file.

These examples demonstrate that there is no difference between my approach to claims in the Laws of Identity and that proposed recently by Ben.  Further examples abound: 

In proffering this definition, we recognize it does not jive with some widely held beliefs – for example that within a given context, identities have to be unique. (page 5)

Or:

In this scenario we actually do not want to employ unique individual identifiers as digital identities. (page 6)

Or:

It makes sense to employ a government issued digital identity when interacting with government services (a single overall identity neither implies nor prevents correlation of identifiers between individual government departments). (Page 9)

Now I know we're all busy.  I don't expect people to be familiar with my work.  But Ben explicitly cites what he calls my “famous laws” in a footnote, and calls out the “important difference” in our thinking as being that I'm concerned with identifiers, whereas he is concerned with assertions.  He's just wrong, as anyone who reads the Laws can see. 

The fact is, I like Ben, and I like a lot of his thinking.  I hope he reads my version of the laws before citing them again, and that he corrects his rendition of my thinking about identifiers and claims or assertions.  This seems doable since his paper is still a work in progress.

Conciously false technology claims

My lawyer friends all know I am “legally challenged” – so don't take anything I say about legal issues as representing any particular expertise. 

But on the news today I saw a story about a drug manufacturer showing the consequences of making false technical claims like those I objected to here in other walks of life: 

NEW YORK (CNNMoney.com) — The maker of OxyContin, Purdue Pharma LP, agreed Thursday to a $600 million penalty as part of a plea deal with the Justice Department on a felony charge of misleading and defrauding physicians and consumers, the government said.

Three of the company's executives, including its CEO, general counsel and former chief medical officer, have separately agreed to pay $34.5 million in penalties. The company and the three men appeared in federal court Thursday to plead guilty.

The company also agreed to subject itself to independent monitoring and a remedial action program.

“Purdue … acknolwedged that it illegally marketed and promoted OxyContin by falsely claiming that OxyContin was less addictive, less subject to abuse and diversion, and less likely to cause withdrawal symptoms than other pain medications – all in an effort to maximize its profits,” said U.S. Attorney John Brownlee.

There should be accountability and penalties for those who consciously mislead people like the Marlin County school board, convincing them there is no risk to privacy by preying on their inability to understand technical issues.  It should be mandatory, when selling technology with potential privacy implications, to explain the threats and mitigations in an objective and public way.

QT and the perimeter

Jeff Bohren, The Identity Management Expert at TalkBMC, makes a great point about what laptops mean and hits gold with Quantum Tunneling.

Kim Cameron has another interesting entry on Deperimeterization here. All of this got me to thinking about another aspect of perimeter security, and that is network location. People tend to think of computers as being logically located inside or outside of the security perimeter. Or more specifically people without laptops tend to think that. If you have a laptop, you quickly realize that you flip-flop between the state of being in and out of the perimeter on a daily basis, or more frequently is you use VPN.

I like the analogy of Quantum Tunneling (QT). One moment your laptop is outside the perimeter, the next it’s magically in. Then out again. QT in, QT out. Of course any malware your laptop picks up outside the perimeter will be carried in on the next trip in. This should really be the nail in the coffin of perimeter security thinking, but unfortunately it isn’t.

The QT analogy came to me because I have been reading Ilium by Dan Simmons (author of the Hyperion series). This SF novel combines The Illiad, QT, Greek Gods, a mostly depopulated Earth, a terraformed Mars, Little Green Men, and Jovian Cyborg buddies (one who likes Shakespeare and one who like Proust). I’m not done yet, so it will be interesting to see if Simmons can pull it all together at the end.

Here is the identity tie in. In Simmon’s future Earth, the few remaining inhabitants can teleport from place to place. It turns out that peoples bodies aren’t actually teleported. The body and brain waves are scanned at origin and that information is stored in a central computer. The body, thoughts, and clothing are reconstituted at the destination based on that information.

Teleportation of identity! Fascinating.

Jeff has definitely got it.

Identity – the toy model

I look forward to seeing Dave Kearns explore the notion of Legonics in an upcoming newsletter. As Dave explains – with his usual clarity:

This morning while delivering the opening keynote address for this year's Directory Experts Conference, Kim Cameron introduced me to a new term – “Legonics“.

This is a reference to the well-known building blocks, Legos, familiar to anyone under 40, and the parents of those under 40! The great thing about Legos is that any one piece can connect to any other piece. And while you can buy a small set that can build a particular object (such as a fire truck), the pieces in that set can be put together in different ways to build other objects or combined with other sets – or other loose pieces – to build completely different things. So by creating a Legonic Identity System (LIS?) we have one which can put together identity data in various ways to fit the conditions of the moment. Relying Parties, Identity Providers and User Agents can work together to construct sets of Identity Claims from all of the available pieces of identity data.

It's a good analogy, and a good paradigm, I think. I'll probably explore his more in the newsletter.

The fire truck link is fantastic, by the way.  Meanwhile, how about:

le·gon·ics: noun

  1. (used with a singular verb) the science dealing with the development and application of devices and systems that can be assembled through claims.
  2. (used with a plural verb) Legonic systems and devices:  The legonics aboard the new aircraft are very sophisticated.

Subject oriented programming

Here's a seminal posting by =kermit at a blog called Subjectivity – mapping the world of digital identity.  I buy into the “Subject Oriented Programming” idea – it's wonderful.

More than a decade ago I happened upon this programming language called C+-, pronounced “C, more or less”:

Unlike C++, C+- is a subject-oriented language. Each C+- class instance, known as a subject, holds hidden members, known as prejudices or undeclared preferences, which are impervious to outside messages, as well as public members known as boasts or claims.

Of course it was a joke and I laughed, but the joke stung a bit. It had occurred to me that a claims-based system like this could actually be useful. I had even come up with the name “subject-oriented” for it. So it hurt a bit to find the idea “out there” only as the butt of a joke.

Well, things have certainly changed since then. Today Kim Cameron posted an item titled “Identity systems all about making claims”, and linked to another article by NetworkWorld’s John Fontana which elaborates:

Cameron said the flexible claims architecture, which is based on standard protocols such as WS-Federation, WS-Trust and the Security Assertion Markup Language (SAML) will replace today’s more rigid systems that are based on a single point of truth […]

The claims model, he said, is more flexible and based on components that can be snapped together like Lego blocks. Cameron called them Legonic Systems, which, he said, are agile and self-organizing much like service-oriented architectures. The Legonic identity system is rethinking what users know today, he said, and is defined by a set of claims one subject makes about another.

Formulations like this make it clear how fundamental the coming “identity revolution” in computing could be. The German philosopher Hans Blumenberg argued in his book The Legitimacy of the Modern Age that modern science emerged from the sterility of medieval Scholasticism precisely because of its “renunciation of exactitude.” In other words, modern science emerged by replacing the idea of “eternal truth” with that of subjective claims and methodical doubt as epitomized in Descartes.

This incorporation of uncertainty and error continued into the twentieth century with the discovery of statistical mechanics and quantum indeterminacy. Could computer science, with the discovery of digital identity, finally be leaving its own rigid Scholastic period behind as well?

Answer:  Yup.

Identity systems all about making claims

Network World's excellent John Fontana has written about an opening keynote I gave recently at the Directory Experts’ Conference (DEC).   I was talking about claims, trying to start a conversation that I will pursue on my blog over the next while.

Las Vegas — The traditional concepts of authentication and authorization will eventually give way to an inclusive identity system where users will present claims that answer who they are or what they can do in order to access systems and content or complete transactions, according to Microsoft’s identity architect.

“This is happening now and all it needs to do is gain momentum,” said Kim Cameron, Microsoft’s identity architect, who gave the keynote address Monday to open NetPro’s Directory Experts Conference. He said the transformation to a claims-based identity model is 18-24 months away.

Cameron said the flexible claims architecture, which is based on standard protocols such as WS-Federation, WS-Trust and the Security Assertion Markup Language (SAML) will replace today’s more rigid systems that are based on a single point of truth, typically a directory of user information.

“You need extroverted systems, not introverted,” said Cameron, who over the past few years has aligned Microsoft, its competitors and open source advocates around user-centric identity models.

He said identity systems that are rigid and cannot connect to other systems will become irrelevant and a competitive disadvantage.

“You may come with a claim that you are authorized to do something and it may not have any authentication [information] at all,” he said. “This tremendously important factor means we can have a consistent technology that goes between authentication and authorization. We don’t need all these different technologies and have all this new stuff to learn. It can all be done using the claims-based model.”

Cameron said this thinking is very different from a few years ago when authentication and authorization were thought of as entirely separate technologies that should never be confused.

He said the beauty of the claims model is that it can grow out of the infrastructure users have today, including PKI, directory services and provisioning systems.

The claims model, he said, is more flexible and based on components that can be snapped together like Lego blocks. Cameron called them Legonic Systems, which, he said, are agile and self-organizing much like service-oriented architectures.   (Continued here…)

The dissolving perimeter

The perimeter of the enterprise is dissolving in an environment requiring greater collaboration, oursourcing and integration with both suppliers and customers.  But Consentry's recent report shows that most IT leaders perceive that “external” threats come from inside the enterprise itself… 

Increasing network user diversity is raising concerns that there is a need for a more dynamic approach to LAN security. The following report tackles this issue, advocating an identity-based approach to managing users on the network.

The key drivers for focusing on network security from a user perspective come from the level of transitory, or non-permanent, workers who access network environments on a daily basis. The research found a significant majority of respondents seeing the following groups as a threat to the network:

  • Temporary workers (62%)
  • Guest users (54%)
  • Contractors (51%)

With 82 percent of businesses in the survey saying they have moderate to high levels of nonpermanent workers accessing the network, it appears that the changing shape of the workforce is a contentious issue for security professionals.

Further highlights from the research are as follows:

  • 87% of respondents state that they have multiple levels of user access
  • 82% of respondents recognise the need to increase network security
  • 95% believe there is an increased need for the use of identity-based control
  • 41% of businesses do not have up-to-date network access
  • 65% acknowledge that network access is becoming more diverse and difficult to manage

Download the report here.

Weaknesses of Strong Authentication?

Here is a piece by Robert Richardson from the CSI Blog .  He discusses what one of his colleages calls “some of the weaknesses or downright drawbracks of strong authentication methods”:

There's this author named Kathy Siena who's currently at the center of one of those firestorms that break out on the Web now and again. Some threatening material regarding her was posted on the Web, she blames some fairly prominent bloggers of being involved in one way or another, and the rest seems to be finger pointing and confusion.

One detail of the saga worth considering is that one of the implicated bloggers claims that actions were taken by someone using his identity and access to his passworded accounts (this is quoted from Kim Cameron's Blog):

I am writing this from a new computer, using an email address that will be deleted at the end of this.I am no longer me. My main machine despite my best efforts has been hacked, my accounts compromised including my email. and has been disconnected from the internet.

How did this happen? When did this happen?

This is, to be sure, something of doomsday scenario for an individual user–the complete breach of one's identity across all the systems one uses and cares about (I'm assuming that the person in question, Allen Harrell, is telling the truth about being hacked).

Kim Cameron writes this on his blog:

Maybe next time Allan and colleagues will be using Information Cards, not passwords, not shared secrets. This won’t extinguish either flaming or trolling, but it can sure make breaking in to someone’s site unbelievably harder – assuming we get to the point where our blogging software is safe too.

But I'm not convinced of this for a couple of reasons. First, Information Cards may or may not make breaking into someone's site unbelievably harder. Hackers sidestep the authentication process (strong or otherwise) all the time. Second, the perception of super-duper strong identity management may make it harder to prove that one's identity was in fact hacked.

InfoCard credentials are only more reliable if the system where they are being used is highly secure. If I'm using a given highly trusted credential from my system, but my system has been compromised, then the situation just looks worse for me when people start accusing me of misdeeds that were carried out in my name.

Many discussions about better credentialing begin from an underlying presumption that there will be a more secure operating system providing protection to the credentials and the subsystem that manages them. But at present, no one can point to that operating system. It certainly isn't Vista, however much improved its security may be.

Designing for Breach

I agree with Robert that credentials are only part of the story.  That's why I said, “assuming we get to the point where our blogging software is safe too.” 

Maybe that sounds simplistic.  What did I mean by “safe”? 

I'll start by saying I don't believe the idea of an unbreachable system is a useful operational concept.  If we were to produce such a system, we wouldn't know it.  The mere fact that a system hasn't been breached, or that we don't know how it could be, doesn't mean that a breach is not possible.  The only systems we can build are those that “might” be breached.

The way to design securely is to assume your system WILL be breached and create a design that mitigates potential damage.  There is nothing new in this – it is just risk management applied to security.

As a consequence, each component of the system must be isolated – to the extent possible –  in an attempt to prevent contagion from compromised pieces.

Security Binarism versus Probabilities

I know Robert will agree with me that one of the things we have to avoid at all costs is “security binarism”.  In this view, either something is secure or it isn't secure.  If its adherants can find any potential vulnerability in something, they conclude the whole thing is vulnerable, so we might as well give up trying to protect it.  Of course this isn't the way reality works – or the way anything real can be secured.

Let's use the analogy of physical security.  I'll conjure up our old friend, the problem of protecting a castle. 

You want a good outer wall – the higher and thicker the better.  Then you want a deep moat – full of alligators and poisonous snakes.  Why?  If someone gets over the wall, you want them to have to cross the moat.  If they don't drown in the moat, you want them to be eaten or bitten (those were the days!)  And after the moat, you would have another wall, with places to launch boiling oil, shoot arrows, and all the rest.  I could go on, but will spare you the obviousness of the excercise.

The point is, someone can breach the moat, but will then hit the next barrier.  It doesn't take a deep grasp of statistics to see that if there is a probability of breach associated with each of these components, the probability of breaking through to the castle keep is the product of all the probabilities.  So if you have five barriers, then even if each has a very high probability of breach (say 10%), the overall probability of breaking through all the barriers is just .001%.  This is what lies behind the extreme power of combining numerous defences – especially if breaking through each defence requires completely unrelated skills and resources.

But despite the best castle design, we all know that the conquering hero can still dress up as a priest and walk in through the drawbridge without being detected (I saw the movie).  In other words, there is a social engineering attack.

So, CardSpace may be nothing more than a really excellent moat.  There may be other ways into the castle.  But having a really great moat is in itself a significant advance in terms of “defence in depth”. 

Beyond that, Information Cards begin to frame many questions better than they have been framed in the past – questions like, “Why am I retaining data that creates potential liability?”

In terms of Robert's fear that strong authentication will lead to hallucinations of non-repudiation, I agree that this is a huge potential problem.   We need to start thinking about it and planning for it now.  CSI can play an important role in educating professionals, government and citizens about these issues. 

I recently expanded on these ideas here.