Category: Privacy

Dynamite interview with Latanya Sweeney

Scientific American has published a must-read-in-its-entirety interview with Carnegie Mellon computer scientist Latanya Sweeney. She begins by showing that privacy is not a political issue, but an animal need:

“We literally can't live in a society without it. Even in nature animals have to have some kind of secrecy to operate. For example, imagine a lion that sees a deer down at a lake and it can't let the deer know he's there or [the deer] might get a head start on him. And he doesn't want to announce to the other lions [what he has found] because that creates competition. There's a primal need for secrecy so we can achieve our goals.”

Then she ties privacy to human ontogenesis – again, a requirement for the existence of the species: 

Privacy also allows an individual the opportunity to grow and make mistakes and really develop in a way you can't do in the absence of privacy, where there's no forgiving and everyone knows what everyone else is doing. There was a time when you could mess up on the east coast and go to the west coast and start over again. That kind of philosophy was revealed in a lot of things we did. In bankruptcy, for example. The idea was, you screwed up, but you got to start over again. With today's technology, though, you basically get a record from birth to grave and there's no forgiveness. And so as a result we need technology that will preserve our privacy.

Continue reading Dynamite interview with Latanya Sweeney

Linkage with CardSpace in Auditing Mode

As we said here, systems like SAML and OpenID work without any changes to the browser or client – which is good.  But they depend on the relying party and identity provider to completely control the movement of information, and this turns out to be bad. Why? Well, for one thing, if the user lands at an evil site it can take complete control of the client (let's call this “extreme phishing”) and trick the user into a lot of evil.

Let’s review why this is the case.  Redirection protocols have two legs.  In the first, the relying party sends the user’s browser to the identity provider with a request.  Then the identity provider sends the browser back to the relying party with a response.   Either one can convince the user it's doing one thing while actually doing the opposite.

It’s clear that with this protocol, the user’s system is “passive”. Services are active parties while the browser does what it is told.  Moreover, the services know the contents of the transaction as well as the identities and locations of the other service involved.  This means some classes of linkage are intrinsic to the protocol, even without considering the contents of the identity payload.

What changes with CardSpace?

CardSpace is based on a different protocol pattern in which the user’s system is active too.  Continue reading Linkage with CardSpace in Auditing Mode

The Biometric Dilemma

Vision researcher Terrence E. Boult has identified what he calls the “Biometric dilemma” – the more we use biometrics the more likely they will be compromised and hence become useless for security.   

This is a hugely important observation – the necessary starting point for all thinking about biometrics.  I'd even call it a law.

Terrence was responding to a piece by Sean Convery that picked up on my post about reversing biometric templates.  Terrence went on to call our attention to more recent work, including some that details the reversibility of fingerprint templates. Continue reading The Biometric Dilemma

Paper argues biometric templates can be “reversed”

Every time biometrics techology is sold to a school we get assurances that the real fingerprint or other biometric is never stored and can't be retrieved.  Supposedly the system just uses a template, a mere string of zeros and ones (as if, in the digital world, there is much more than that…)  

It turns out a Canadian researcher has shown that in the case of face recognition templates a fairly high quality image of a person can be automatically regenerated from templates.  The images calculated using the procedure are of sufficient quality to  give a good visual impression of the person's characteristics.  This work reinforces the conclusions drawn earlier by an Australian researcher, who was able to construct fingerprint images from fingerprint templates.  Continue reading Paper argues biometric templates can be “reversed”

Ensuring Privacy and Consent

I think many will benefit from Marco Casassa Mont's Research on Identity Management blog.  He discusses business-driven identity management – and its foibles.

A recent post invites us to an upcoming Kable conference that I would attend if I possibly could:

An interesting conference is going to take place on July, 9th in London, UK on “Ensuring Privacy and Consent in Identity Management Infrastructures”. It is supported by DTI and free to attend to the private sector and academics. The conference program and online registration form are available here.

“The Department of Trade and Industry (DTI), through the Technology Strategy Board's Network Security Innovation Platform, is working with the Identity and Passport Service (IPS), the Home Office, the Economic and Social Research Council (ESRC) and the Engineering and Physical Sciences Research Council (EPSRC) to develop a work package that will sponsor a £10m, 3-year, research and development programme into how to balance the potentially intrusive nature of identity services and network security with users’ expectations of privacy and consent. This research will be cross-disciplinary, combining social science with technological innovation. …

The aim of this initial workshop on 9 July is to discuss and refine the areas of importance for research, as well as identifying where the research is needed and where the UK has potential to develop world-leading commercial services. The findings of the workshop will lead to the development of projects and proposals using the EPSRC's sand-pit concept at a further workshop to be held in early October.”

You might want to consider attending if you work in the areas of identity and privacy management …

Charles Fitzgerald doing “platformonics”

I just discovered that Charles Fitzgerald, General Manager of Platform Strategy at MS, has started a blog called Platformonics.  I know a lot of industry people will be interested – Charles has really been around the block at the highest level.  I think he learned more from “Hailstorm” than anyone else who I've spoken to.  Beyond that, he's a great business person, well-read and beautifully wry.  Here's a piece full of implications called There is no free lunch (especially in France):

The BBC reports the French security service has told French government officials not to use Blackberries because their data is stored in foreign countries and could be susceptible to prying eyes. Expect many more such awakenings going forward to the tradeoffs to putting data in the cloud.  Not just national security concerns, but trade secrets, privacy and compliance requirements will all require people to think more explicitly about the risks and tradeoffs of where you put your data and what can happen to it.  Today's all or nothing approach is a crummy way to do it. Three contenders for the most amazing part of this story:

  1. They're just realizing this now?  Did they just figure it out or did some incident precipitate this decision?  There is probably a pretty good spy novel in if you combine this with almost any headlines from France in recent years.
  2. French officials are “flouting the ban”.  I predict the upcoming ban on smoking in public places in France takes “flouting” to a whole new level.
  3. RIM insists the US National Security Agency can't read content on their service.  Disciples of Taleb might call that epistemological arrogance.

Oh yeah, I almost forgot.  Charles has been a great supporter of the Laws of Identity – ribbing me by somehow learning to recite the title with reverb.  He was also one of the first to see the potential of Information Cards.

Trustworthy Computing Privacy Award

While working on the Laws of Identity and CardSpace, it seemed that each new idea led inevitably to the next.  I really had no choice in arriving at the concepts that arose.  There was no other way to create an identity layer for the internet.   

But as the issues unfolded, it became clear that the road to be travelled wasn't going to be easy.  In fact, it was going to be hard.  It involved risk.  It required people and organizations to rise to challenges that seemed almost impossible.  It needed profound goodwill.  Do we dare say it required trust?

In the early days, as I shared my conclusions, my colleagues in the blogosphere and the conference rooms would say, “Kim, we don't doubt your personal integrity, or your vision; but surely you can't expect us to believe that Microsoft is really going to back you on this stuff…”

And when I looked coldly at what would be required of Microsoft, I could see that there was probably no large company in the world that could do all the counter-intuitive things necessary for success. 

  • In a world where the erosion of privacy was becoming endemic, I would need a Microsoft relentless in championing privacy. 
  • In a world where you are normally lucky just to get your research funded, I would need a Microsoft that would not only fund but then freely share every aspect of the new technology. 
  • In a world polarized between open-source and inventor-owned software, I would have to ask both sides to work together in a single community for the good of everyone. 
  • Having concluded that the original thinking about Passport broke the laws of identity, I would need a Microsoft willing to admit to the mistake, and show it could learn from it. 
  • Above all, I would need a Microsoft that would let me be completely open about what I was thinking, despite my internal role as an architect.  That was the only way I could speak both to Microsoft and to the rest of the industry, to argue for the changes everyone would need make if we were to be successful. 

The project could not succeed if we failed to achieve any of these.  And then, only after that, you had all the uncertainty associated with the introduction of any new paradigm, and any new product.  I would need a team willing to buy fully into all the architectural tenets, and to defend them with passion while building something eminently usable.

Other than love, there is little that is higher in my estimation than authenticity.  To actually be the architect of identity I was supposed to be, I would have to express what was required, try to find the language, try to build the context.   That's what this blog has been about, transforming itself so that more and more it became a place for me to learn and to work.  

If this has all been a voyage, this week was a milestone.  The interoperability event at the Burton Group's Catalyst conference was stunning (more later).  The combined impact of the open source community and Microsoft and many other companies charging into this new world of Information Cards and claims-based computing was intoxicating.   

But there was a second milestone as well – one which I had never predicted.  And although it seems like a personal one, it really isn't, so I hope you will let me share it with you.

I received an award from my colleagues at Microsoft.  Here's the congratulatory letter:

To: Kim Cameron
From:  Bill Gates and Scott Charney
Re: 2007 Trustworthy Computing Privacy Award

On behalf of Microsoft, we want to congratulate you for your outstanding contributions to Trustworthy Computing during the last year.

In recognition of your efforts – which stem from your passion, determination and leadership – you have been chosen to receive the Trustworthy Computing Privacy Award.  Your work is having a tremendous impact across the company, and has significantly improved customers’ interactions with Microsoft.

Specifically, your Laws of Identity, and the work you are leading on the Identity Metasystem, is establishing the foundation for electronic credentials in the virtual world, and is leading a renaissance for identity solutions.  By placing individuals at the center of trust decisions and establishing contextual frameworks where credentials can be recognized, these laws are able to address security requirements while respecting the privacy needs of individuals.  These seven laws, and the identity metasystem, governed the design of the potentially game-changing functionality of Windows CardSpace.

The Trustworthy Computing Privacy Award is a key achievement that recognizes outstanding contributions in advancing an important company tenet. It acknowledges and rewards individuals and teams who have pioneered noteworthy process improvements and innovations in their pursuit of trustworthy computing.  Receiving the Trustworthy Computing Privacy Award is a level of recognition that only few of our finest employees achieve.  Everyone involved in this project should be extremely proud of this accomplishment.

Congratulations again on your achievement, and congratulations on your efforts.

Sincerely

Bill Gates, Chairman, and

Scott Charney, Corporate Vice President, Trustworthy Computing.

Not only had Microsoft supported my work.  It had risen to the extreme challenges my work set for it.  And this would not have been possible without the contribution of many others, like Scott Charney, who were working to guide Microsoft in the same direction I was. 

I was especially happy to receive the award from Bill Gates, whose vision reaches across every aspect of technology.  He, above anyone else, is the symbol of a Microsoft that “gets” identity, and I thank him very deeply.

I don't normally get into a lot of stuff about Microsoft on the blog, but this award thing has made me stop and think about what she has been willing to do, OSP and all.  I congratulate her on what she has done already, and will continue to do, to move us closer to the identity big bang.

Control, not nagging

In a piece called Pleading down the Charges, Jeff Bohren of talkBMC  refers to the discussion I've had with Conor about invisible redirection as ‘inflammatory’, and adds: 

“In subsequent exchanges Kim and Conor plead the charges down from a felony to a misdemeanor. Kim allows that the redirection is OK so long as the IdP is completely trusted, but he is concerned about the case where the IdP is not trustworthy…

It's probably true that my “hand in wallet” metaphor was a bit stark.  But how can I put this?  I'm doing a threat analysis.  Saying everything is OK because people are trustworthy really doesn't get us very far.  Even a trustworthy IdP can be attacked;  threats remain real even in the light of mitigations. 

When we put on our security hats, and look at the security of a system, we try as hard as we can to explore every possible thing that can go wrong, and develop a complete profile of the attack vectors.  No one says, “Hey, don't talk about that attack, because we've done this or that to prevent it.”  Instead, we list the attack, we list what we do to mitigate it, and we understand the vulnerability.  We need to do the same thing around the privacy attack vectors.  It is revealing that this doesn't seem to be our instinct at this point in time, and reminds me of the days, before the widespread vulnerability of computer systems became apparent, when people who brought up potential security vulnerabilities were sent to stand in the corner.

Jeff continues:

What is missing from this discussion is the point that “automatic redirection” is not mandated by SAML. Redirection, yes, but automatic redirection is not required. The SP could very well have presented at page to the user that says:

“Your browser is about to be redirected www.youridp.com for the purposes of establishing your identity. If you consent to this redirection, press Continue. If you do not consent, press Cancel….

Correct.  This could be done.  But information can also be made to fly around with zero visibility to the user.  And that represents a risk.

Jeff concludes:

Nobody does this kind of warning because the average user doesn’t want to be bothered and isn’t concerned with it. Not as concerned as, for instance, having a stranger reach into their pocket.

Actually, thanks to “invisible system design”, the “average user” has no idea about how her personal information is being sent around, or that with redirection protocols, her own browser is the covert channel for sharing her identity information between sites.  This might be all right inside an enterprise, when there is an implicit understanding that the enterprise shares all kinds of personal information.  It might even be OK in a portal, where I go to a financial institution and expect it to share my information with its various departments and subsidiaries.  But in the age of identity theft, I'm not so sure she would not be concerned with the invisible exchange of identity information between contextually unrelated sites.  I think she would probably feel like a stranger were reaching into her wallet. 

To be clear, my initial thinking about the “hand in wallet” came not from SAML, but from X.509, where the certificates described in Beyond maximal disclosure tokens are routinely and automatically released to any site that asks for them without any user approval.  SAML can be better in this regard, since the IP is able to judge the identity of the RP before releasing anything to it.  In this sense, not just any hand can reach into your wallet – just a hand approved by the “card issuer”…  This is better for sure.

Do we need to nag users as Jeff suggests might be the alternative? No.  Give the user a smart client, as is the case with CardSpace or Higgins, and whole new user experiences are possible that are “post nagging”.  The invisibility threat is substantially reduced.

In my next post in this series I'm going to start looking at CardSpace and linkability.

Beyond maximal disclosure tokens

I concluded my last piece on linkability and identity technology by explaining that the probability of collusions between Relying Parties (RPs)  CAN be greatly reduced by using SAML tokens rather than X.509 certificates.  To provide an example of why this is so, I printed out the content of one of the X.509 certificates I use at work, and here's what it contained:

Version V3
Serial Number 13 9b 3c fc 00 03 00 19 c6 e2
Signature Algorithm sha1RSA
Issuer CN = IDA Enterprise CA 1
Valid From Friday, February 23, 2007 8:15:27 PM
Valid To Saturday, February 23, 2008 8:15:27 PM
Subject CN = Kim Cameron
OU = Users
DC = IDA
DC = Microsoft
DC = com
Public Key 25 15 e3 c4 4e d6 ca 38 fe fb d1 41 9f
ee 50 05 dd e0 15 dc d6 2a c3 cc 98 53
7e 9e b4 c7 a5 4c a7 64 56 66 1e 3d 36
4a 11 72 0a eb cf c9 d2 6c 1f 2e b2 2a
67 4f 07 52 70 36 f2 89 ec 98 09 bd 61
39 b1 52 07 48 9d 36 90 9c 7d de 61 61
76 12 5e 19 a5 36 e2 11 ea 14 45 b1 ba
12 e3 e2 d5 67 81 d1 1f bb 04 b1 cc 52
c2 e5 3e df 09 3d 2b a5
Subject Key Identifier 35 4d 46 4a 13 c1 ae 81 3b b8 b5 f4 86 bb 2a c0 58 d7 ad 92
Enhanced Key Usage Client Authentication (1.3.6.1.5.5.7.3.2)
Subject Alternative Name Other Name – Principal Name=kc@microsoft.com
Thumbprint b9 c6 4a 1a d9 87 f1 cb 34 6c 92 50 20 1b 51 51 87 d5 a8 ee

Everything shown is released every time I use the certificate – which is basically every time I go to a site that asks either for “any old certificate” or for a certificate from my certificate authority.  (As far as I know, the information is offered up before verifying that the site isn't evil).  You can see that there is a lot of information leakage.  X.509 certificates were designed before the privacy implications (to both individuals and their institutions) were well understood.

Beyond leaking potentially unnecessary information (like my email address), each of the fields shown in yellow is a correlation key that links my identity in one transaction to that in another – either within a single site or across multiple sites.  Put another way, each yellow field is a handle that can be used to correlate my profiles.  It's nice to have so MANY potential handles available, isn't it?  Choosing between serial number, subject DN, public key, key identifier, alternative name and thumbprint is pretty exhausting, but any of them will work when trying to build a super-dossier.

I call this a “maximal disclosure token” because the same information is released everywhere you go, whether it is required or not.  Further, it includes not one, but a whole set of omnidirectional identifiers (see law 4).

SAML tokens represent a step forward in this regard because, being constructed at the time of usage, they only need to contain information relevant to a given transaction.  With protocols like the redirect protocol described here, the identity provider knows which relying party a user is visiting. 

The Liberty Alliance has been forward-thinking enough to use this knowledge to avoid leaking omnidirectional handles to relying parties, through what it calls pseudonynms.  For example, “persistent” and “transient” pseudonyms can be put in the tokens by the identity provider, rather than omnidirectional identifiers, and the subject key can be different for every invocation (or skipped altogether). 

As a result, while the identity provider knows more about the sites visited by its users, and about the information of relevance to those sites, the ability of the sites to create cross-site profiles without the participation of the identity provider is greatly reduced.  SAML does not employ maximal disclosure tokens.  So in the threat diagram shown at the right I've removed the RP/RP collusion threat, which now pales in comparison to the other two.

As we will see, this does NOT mean the SAML protocol uses minimal disclosure tokens, and the many intricate issues involved are treated in a balanced way by Stefan Brands here.  One very interesting argument he makes is that the relying party (he calls it “service provider or SP), actually suffers a decrease in control relative to the identity provider (IP) in these redirection protocols, while the IP gains power at the expense of the RP.  For example, if Liberty pseudonyms are used, the IP will know all the customers employing a given RP, while the RP will have no direct relationship with them.  I look forward to finding out, perhaps over a drink with someone who was present, how these technology proposals aligned with various business models as they were being elaborated.

To see how a SAML token compares with an X.509 certificate, consider this example:

You'll see there is an assertionID, which is different for every token that is minted.  Typically it would not link a user across transactions, either within a given site or across multiple sites.  There is also a “name identifier”.  In this case it is a public identifier.  In others it might be a pseudonym or “unidirectional identifier” recognized only by one site.  It might even be a transient identifier that will only be used once.

Then there are the attributes – hopefully not all the possible attributes, but just the ones that are necessary for a given transaction to occur.

 Putting all of this together, the result is an identity provider which has a great deal of visibility into and control over what is revealed where, but more protection against cross-site linking if it handles the release of attributes on a need-to-know basis.