Category: Digital Rights

Grab them eyeballs! Any cred at all!

Want to deeply understand how OpenID would make our lives better on social networks? Check out this piece by Dare Obasanjo, a program manager within Windows Live.  But be prepared to be jolted.  According to Dare, there is indeed a promised land, but we won't be allowed into it.

Dare is responding to Wired's Slap in the Facebook:  It's Time for Social Networks to Open Up.  He talks about the common-sense economics of identity, then asks why “there seem to be more OpenID providers than there are consumers”, concluding:

Why would Facebook implement a feature that reduced their user growth via network effects? Why would MySpace make it easy for sites to extract user profile information from their service? Because openness is great? Yeah…right.

Openness isn’t why Facebook is currently being valued at $6 Billion…

Dare's explanation of how the big web properties see things is spot on.  But are they right? 
Continue reading Grab them eyeballs! Any cred at all!

Digital gifts for my digital birthday

When I do a telephone transfer at my bank, they ask me to prove I'm legitimate by giving them a few pieces of information – including my birth date.  I also know that by combining birth date, surname and zip code, marketers can uniquely identify almost the whole population.  To my way of thinking, this puts it in the same class as a social security number, and I'm careful about who I give it to.

So when signing up for Facebook I didn't consider for one moment the idea of publishing my natural birth date.   Nor did I read the terms of service.  If sites hide away their terms of service, I figure that means they don't expect me to read them anyway. Continue reading Digital gifts for my digital birthday

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

Time: no one knows you're a CEO

 Lev Grossman's The Price of Anonymity in this week's Time Magazine is interesting partly because of his unforgettable portrait of John Mackey as Marie Antoinette.  But it veers to a draconian conclusion:

As far back as the 1980s, the Internet has been an electronic masked ball, a place where people can play with new identities and get off on the frisson of being somebody else. MIT sociologist Sherry Turkle has argued that this kind of identity-play even has therapeutic value. You certainly can't ascribe a plausible financial motive to Mackey–rahodeb's postings weren't moving stock prices around. This was about just being naughty: picture Mackey chortling as he played the regular rube, like Marie Antoinette dressing up as a peasant and milking cows on the fake farm she built near Versailles. (Mackey was even in drag, sort of–rahodeb is an anagram of his wife's name, Deborah.) Continue reading Time: no one knows you're a CEO

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”

Guess what? Rabodeb is not his “real” name

A rivetting “natural” story of pseudonymity has risen to prime time in America's financial press – partly because government prosecutors have entered the fray. We're not talking here about a teenager, novelist, or garret inhabitant. This involves a corporate executive – John P. Mackey, co-founder of Whole Foods Market, who we have just found out goes by the name of “Rahodeb“. Continue reading Guess what? Rabodeb is not his “real” name

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.

Report on EEMA e-Identity Conference in Paris

Marcus Lasance has a new blog called IdentitySpace that brings us a comprehensive piece on the EEMA e-Identity conference held recently in Paris.  Reading it will give you a feeling for some of the conversations that are going on around identity in Europe.  I'll quote randomly to pique your interest:

“Olivier Delos of SEALED gave a good example of how e-Id cards issued by governments can be used to facilitate electronic transactions in the private sector. However ‘anti’ the privacy lobby may make us want to feel against such applications, the presented use case of a Belgian Water Company clearly showed what savings can be made when users are allowed to use their Belgium Citizen ID card as an identity service provider. 150,000 address change notifications are now processed this way in a matter of seconds, with zero manual input, zero errors and a user satisfaction rating of ten out of ten.

“Unfortunately this type of example where businesses are allowed to benefit from an infrastructure provided by government remain rare and citizen to government transactions requiring an e-Identity to be presented amount to only 1.7 transactions per year according to one study. Hardly what you would call a ‘killer application’. So the barrier to acceptance remains a big concern about privacy, even though according to Kim Cameron the technology is designed to enable the relying party to remain hidden from the Identity provider when privacy is a concern. Before ‘Jo public’ readily accepts this is the case, a lot of water will flow under the bridge unfortunately.”

I need to make a clarification. Out of the box, current Citizen Cards use maximum disclosure certificates and omnidirectional keys – they are only suitable for completely “public” identity contexts. But by using them to authenticate to identity providers that support minimum disclosure tokens, we can end up with true privacy enancing systems. If we accomplish this, then working together with privacy advocates, academics and influentials from across society, we can win the trust of Joe Public, who in my view has every right to be suspicious.

“David Ramirez showed an application of Federation using SAML V2.0 in the world of the converged networks of Internet and Mobile data access. For me the example of how SAML could be used to give law enforcement agents or ‘spooks’ access to mobile phone records was a bit unfortunate in view of the earlier privacy discussions, but I guess its one application of this technology which can’t be ignored. [Hope Conor reads this… – Kim]

“Kieron Salt did his expose on European Union funded research project GUIDE, an acronym for Government User Identity for Europe. This project is driven by the objectives of the Manchester Declaration which states that by 2010 all European citizens and businesses shall benefit from locally-issued electronic IDs for use across the EU. But we had seen from previous presentations, that there is plenty of scope here for identity fraudsters until interoperability issues are sorted out.

“GUIDE is not about creating a meta directory of all member states’ Identity data, but rather about creating a gateway providing interoperability between the different standards chosen by the different member states. The gateway for instance should be able to handle transactions between SAML, Shiboleth and WS-Federation schemes, if those are the three standards commonly used in Europe…

“Dr. Ruth Halperin of the London School of Economics and Political Science has conducted an in depth research project into the extent to which citizens across European Countries trust their authorities to exchange data in an appropriate manner across government departments, between governments and commerce…

“Dr. Halperin concludes from her research that in Europe citizens have far more trust in commercial organisations than in their respective governments, an opportunity that did not go unnoticed by the next presenter from Norway representing DNV – an independent foundation Established in 1864 in Norway for the purpose of independent assessment of the quality of ships to aid insurance companies in setting realistic insurance rates… So why not carry on this position to new areas like identity assurance in the digital value chains? PKI and digital signatures are key elements in securing such processes.

Marcus also covers the keynotes, including mine.

No SAML bashing intended here

Conor Cahill (Conor's Web log of Esoterica) responds to my discussion about SAML protocol and linkability in a piece called SAML bashing – which is, by the way, absolutely NOT my intent.  I'm simply trying to understand how SAML relates to linkability, as I am doing for all the other major identity technologies.  I can't take up all the points he raises at this point in the flow, but encourage the reader to look at his piece… 

Conor mentions the emerging ideas for a SAML 2.0 Enabled Client/Proxy.  I want to make it clear I wasn't analysing these proposals.  I was analysing SAML as everyone knows it today – using the “http redirect” and “post” modes that have been widely deployed in portals all over the world, and don't require changes to the browser.

Kim writes about SAML's use of redirection protocols.. To start with, he forgets to mention a few important facts as part of his discussion: 

  • SAML defines a profile for an Enabled Client/Proxy (ECP) which is an evolution of the Liberty Alliance's LECP protocol. This protocol does *NOT* involve redirection, but instead supports an intelligent client directed by the user driving SSO transactions (a similar model to that adopted by Cardspace).
  • The Browser-Profile that Kim is referring to is one written based upon a use case requirement that the profile work out-of-the-box on unmodified browsers. There is NO other possible solution that will work in this scenario that will protect the users credentials at the IdP.

That said, there are still several statements in Kim's analysis that I feel obligated to respond to. These include:

Note that all of this can occur without the user being aware that anything has happened or having to take any action. For example, the user might have a cookie that identifies her to her identity provider. Then if she is sent through steps 2) to 4), she will likely see nothing but a little flicker in her status bar as different addresses flash by. (This is why I often compare redirection to a world where, when you enter a store to buy something, the sales clerk reaches into your pocket, pulls out your wallet and debits your credit card without you knowing what is going on – trust us.”)

First off, the user only see's nothing if a) they are already authenticated by the IdP, b) they have previously established a federation with the relying party, and c) they have told the IdP that they don't want to be notified when an SSO with this party takes place. I, for one, want things to work this way for me with providers that I trust (and yes, I do trust some providers). The inability to do this type of automatic operation is one of the shortcomings in Cardspace's implementation that I think will eventually be fixed. There is no need to have repeated confirmations of operations that I say may occur without my unnecessary participation.

Secondly, the analogy is way off base, trying to make this seem like I'm bing pick-pocketed by someone I don't know which Kim knows is absolutely not the case. A more proper analogy would be something along the lines of “I give one of my providers permission to reach into my bank account and withdraw money to pay my bill”. I do this all the with providers I trust, such as my electric company, my telephone company (both wired and wireless) and may other companies.

[Much more here…]

I think Conor is misunderstanding my intentions.  I agree that with a completely trustworthy Identity Provider following best practices for end user privacy, Conor's points b) and c) above would likely apply.  But we are looking at linkability precisely to judge the threats in the case where parties to identity transactions are NOT completely trustworthy (or are attacked in ways that undermine their trustworthiness.)  So arguing that the identity provider will behave properly has nothing to do with what I am exploring:  risk.  I'll try to build Conor's concerns into my ongoing discussion.

In terms of Conor's point about letting his telephone company deduct directly from his bank account, that's a use case that “rings true”, but there are few companies to which I would want to give this ability.  That's my point.  We need a spectrum of technologies to handle different use cases and risk profiles.

[Update:  Conor later relents a bit in Perhaps not so much Bashing, bringing up a number of points I hope to make part of this exposition.] 

What does the identity provider know?

I appreciate the correction by Irving Reid in a posting called What did the identity provider know?

…And when did it know it?

Kim Cameron sums up the reasons why we need to understand the technical possibilities for how digital identity information can affect privacy; in short, we can’t make good policy if we don’t know how this stuff actually works.

But I want to call out one assertion he (and he’s not the only one) makes:

 First, part of what becomes evident is that with browser-based technologies like Liberty, WS-Federation and OpenID,  NO collusion is actually necessary for the identity provider to “see everything”.

The identity provider most certainly does not “see everything”. The IP sees which RPs you initiate sessions with and, depending on configuration, has some indication of how long those sessions last. Granted, that is *a lot* of information, but it’s far from “everything”. The IP must collude with the RPs to get any information about what you did at the RP during the session.

Completely right. I'll try to make this clearer as I go on. Without collusion, the IP doesn't know how the user actually behaved while at the RP.  I was too focussed on the “identity channel”, thinking about the fact that the IP knows times, what RPs were visited, and what claims were released for each particular user to each RP.