Partial identities and credentials

Conceptually, your identity is a set of attributes describing certain properties about yourself. This set is dynamic, and depends on the context in which you are known. Being a husband, friend, colleague, etc. means different things to different people. So instead of having one identity you have many partial identities, that may not and often should not be linked.

Attribute based credentials are used to implement this concept in the digital world. They store attributes about a person, without fully identifying that person. Moreover, they can be used many times by the same person without being linkable (either to that person, which is sometimes called
untraceability, or among the different uses themselves). Attribute based credentials are a perfect means to achieve the necessary context separation required in privacy friendly identity management. They allow a person to be anonymous.

Certain attributes of a person belong together within one context. In this case, they may be stored together in a single credential (issued by one credential issuer). Sometimes attributes that belong together are stored in different credentials, however. In that case, their relationship is represented by the fact that the private key used to prove ownership of both credentials is the same.

This relationship among credentials (and their attributes) is important. Although it is up to the user to decide whether to show a certain subset of his attributes, the relying party needs to be sure that the set of attributes revealed in fact correspond to one and the same person. For example, the sale of soft drugs in the Netherlands is going to be restricted to Dutch citizens that are over 18 years old. It should not be possible for a French adult and a Dutch minor to obtain soft drugs.

Securely relating attributes to one another

Ideally, the architecture of the credential system should guarantee this property as an invariant: if a set of attributes are shown to belong together, then they all describe the same person. The question is: can this be guaranteed, and how?

It is helpful to discuss what could go wrong. Consider a system of attribute based credentials based on smart cards. Each smart card belongs to a single individual. All credentials belonging to the owner are stored securely on the card. A credential containing the identity of the owner may be stored on the card as well. Now suppose that I can add a credential to my card by first authenticating to a credential issuer using for example an existing username password, after which the issuer uploads the credential to the card securely. If such procedure is allowed, I could also sign in first and then present someone else’s card to store the issued credential on. Now my credential is connected to the credentials already present on that card.

To prevent this from happening, the act of authenticating to the credential issuer should be done with credentials already present on the card. The aforementioned identity credential could be used for this, for example. In other words, the authentication procedure should be bound to the card to which the credentials are going to be issued.

Supporting multiple contexts

But the issue is more subtle that this. I already mentioned people have many partial identities, that are not necessarily connected, and often should not be linkable. If the credentials associated with each of these identities are all stored on a single card, the card needs to separate these identities internally.

This can be done by associating a different private key with each partial identity. But then the solution above for binding the authentication to the card needs to be refined. In fact, instead of binding the authentication to the card, the authentication needs to be bound to a particular private key on the smart card, and the credential should be issued to this particular private key. This way all credentials bound to a single private key are in fact connected and belong to one and the same person.

Connecting the outside world

The procedure outlined above appears to be secure, but has a severe limitation. Existing on-line accounts or existing information about your partial identity cannot easily be linked to your smart card. According to the procedure above, this can only be done if this information can somehow be related to credentials already stored on the card. This is often not the case.

We somehow need to be allow the inclusion of already existing user profiles, like your social network account, or your Amazon.com account, etc. One way to do this is by creating a new context with a separate private key for each external profile that cannot be linked to an existing context managed by the smart card. So your Facebook account becomes a separate context.

New, empty, accounts can of course be done associated with any context a user likes. When signing up, the account credential can be linked to the private key corresponding to that particular context.

But this is a bit strange. If I already have a Facebook account, I cannot link it to one of my contexts on my card. But if I create a new Facebook account (that does not contain any information), I can bind it to whatever context I like, and then start to fill my Facebook account with arbitrary data (for example, the data I already have stored in an existing account that I could not link to this context). This appears to be caused by the fact that Facebook is in a way a very unreliable credential issuer (it is basically me saying whatever I like about myself). It is however unclear yet how this all plays out with other existing online services, when connecting them to attribute based credentials stored on smart cards.

More discussion on these and related topics is certainly necessary, and I would welcome your contribution in the comment section below.

The following quotes make very clear that intelligence agencies will stop at nothing to prevent detection of this (and by extension, for anything else).

“Just before I left, they were gearing up to make a request for CIA
officers to recruit foreigners with access to immigration databases,”
said the retired NOC. “I’m sure that several people made careers
out of just this kind of operation, much as some officers did when the
NSA suddenly lost millions of access points to intelligence when the
world switched from microwave towers to fiber optic lines — whole
departments were formed to recruit telephone company assets in foreign
countries.”

Israeli’s passports are useless for their own Mossad agents: Israeli’s are typically denied access to the countries their spies are most interested in. So they have to create fake foreign passports, claiming to come from the EU for instance. Another quote from the same wired article.

Mossad puts its documents through test runs, said Ross, who retired in 2001.

“We get into, say, France, with a document, then change our appearance, then go into Germany and see if they pick up the physical change, to see if the two speak to each other and say, `Wait a minute, is this the same guy? Before he had a beard and glasses, and now he’s clean-shaven and wears contacts.’”

The keyboards have exactly the same size as the standard QWERY keyboard. The idea is to show the date keyboard when selecting a date entry field, and the time keyboard when selecting a time entry field. The date keyboard is pretty straightforward and looks like this:

It has buttons to select the day, and scroll wheels to select the month and year (which should be set to the current values when opening the keyboard). Changing month and year will adjust the month calendar buttons.

For the time keyboard, there are two options. The first one can be used to enter time in AM/PM format:

The +1 /-1 keys can be used to add or subtract a minute from the time. This is useful to enter exact times. The number of keys you need to press is at most 5 (for exact times) or 3 (for times rounded to 5 minutes).

To enter 24:00 format time, I designed a daylight/night keyboard pair.  The daylight keyboard looks like this:

This keyboard allows you to enter any time between 7 and 19:00 (mostly office hours) effectively with 2 button presses (2 more if you want to enter an exact time). To enter a time between 19:00 and 7:00 one can press the +12 button (which adds 12 hour, effectively toggling between say 9 and 21:00). Alternatively one can press the ‘moon’ button to display the  alternative ‘night’ layout:

to directly enter an hour between 19:00 and 7:00. The ‘sun’ button switches back to ‘daylight’ view.

Now all that remains is to pray someone implements this…

The eID application on the card supports, among other things, the following three functions when accessing an on-line service.

• Authentication of the card holder.
• Privacy friendly verification of the age and place or region of residence of the cardholder.
• Restricted Identification, which generates a secure pseudonym that represents the user within a particular application domain (e.g. the financial sector, or health care, or government services).

When the eID application is used, first a secure channel is set up between the smart card and the server. Chip authentication is based on a private key that is stored on the card. For privacy reasons, this key is shared with a batch of other cards. I am told the size of the batch is 500 (but I have been unable to verify this number). Sharing a key is necessary, because otherwise a particular card could be traced using the corresponding public key that is transmitted to the terminal at the start of the chip authentication phase.

Security of the authentication feature of the eID application is not very strong, because the data provided by the card (e.g. cardholder name) is not signed. (Note that in the passport application on the same card, this data is signed.) Instead, it is assumed that by virtue of the secure channel between the card and the server and the fact that authenticity of the chip is verified through chip authentication, the card will reliably deliver the correct data to the server. This means that if the private key of a single key used for chip authentication is compromised, an attacker can create a card that can send arbitrary data that will be accepted by the server at face value. As a consequence, the attacker can impersonate an arbitrary person.

Privacy protection offered by sharing the same chip authentication key with a batch of cards is also limited. If the batch is small (which appears to be the case), there are two options:

• Cards in the same batch are distributed randomly over the country. This means that it is highly unlikely that two cards from the same batch (with the same key) will be owned by two people living in the same place. As a consequence it is very likely that the public key of a card uniquely identifies a person, at least when he is using the card at or around his place of residence. (This is most notably a concern when using the eID application in offline scenario’s like buying cigarettes from a vending machine, and to a much lesser extent in on-line scenario’s.)
• Cards in the same batch are all issued to people that all live in the same place. But then the public key reveals the place of residence of the card holder.

So this is a case of ‘damned if you and damned if you don’t'…

Finally, the restricted identification feature is designed in such a way that it is not very practical. The general idea of such a feature is to generate a pseudonym based on the identity of the user as well as a sector specific public value shared among all services within this sector. Typically, a hash-function is used for this to ensure that the resulting pseudonym cannot be used to retrieve the underlying user identity. With such a setup, the pseudonyms for the same user at different sectors cannot be linked to each other (but the same user will always have the same pseudonym within a single sector). Unfortunately, the eID application does not use a user identifier but instead uses a secret key on the card as input to the hash function. This leads to problems when the user looses the card, or if the card needs to be replaced. In that case, the secret key is no longer available, and the user will get a new card with a new key. Then the restricted identification feature will generate a different pseudonym for this user based on this new key. As a results, all data associated with the old pseudonym are no longer accessible to the user, as he cannot prove that he ‘is’ the owner of that old pseudonym. [Note added 10-05-2012: part 3 of BSI TR-03110 defines generation of this key to be out of scope of the specification. It does however suggest to use a key stored by a third party to generate this key (which would solve this issue).]

There is an execellent report (by the late Andreas Pfitzmann and Marit Hansen) discussing a terminology for talking about privacy. It defines unlinkability as the property that an adversary cannot determine whether two events occurring in the system are related or not. Events could be the sending and receiving of a message for instance, or the receipt of two separate messages.

Unfortunately, the report does not discuss the term untraceability. In the context of RFID systems, untraceability expresses the property that given two readings of RFID tags it cannot be determined whether they concern the same tag or not. This exactly corresponds to the definition for unlinkability given above. In the context of exchanging messages, untraceability expresses the property that the adversary cannot determine the sender (or recipient) of a message. However, even this definition is subsumed in the notion of unlinkability if we consider the sending and receipt of a message as two separate events.

In the Pfitzmann report, anonymity is defined as the inability to identify a subject within a set (the so-called anonymity set). Given set of possible senders of a message, the real sender is anonymous within this set if he or she is not identifiable within this set. This definition can be framed in terms of unlinkability by saying that a subject is anonymous (w.r.t. a certain event) if the subject cannot be linked to that event.

Zo worden vragen over een microsimkaart (de klant heeft een dure smartphone), de mededeling dat een bestelling binnen twee dagen aankomt (het kan lonen om de bestelling op te wachten), en zelfs informatie over iemands beltegoed (en als reactie dan weer informatie over automatisch opwaarderen) over een in principe publiek kanaal over de hele wereld uitgeschreeuwd. Het voelt een beetje alsof de huisarts de resultaten van je uitstrijkje aan je doorgeeft door een groot billboard tegenover je huis te plaatsen.

Ook wordt regelmatig gevraagd om postcode en huisnummer per DM (Direct Message) te versturen. Dat is dan weliswaar niet voor iedereen leesbaar, maar dus wel door Twitter zelf. Een DM lijkt prive, maar is dat dus eigenlijk niet.

Individuele gebruikers kiezen er natuurlijk zelf voor om via Twitter vragen aan de helpdesk te stellen. Maar een bedrijf als Simyo heeft de verantwoordelijkheid om de gebruiker tegen zichzelf te beschermen. Algemene status informatie over Simyo verspreiden via Twitter is waarvoor een medium als Twitter bedoeld is. Persoonlijke vragen ontvangen en beantwoorden kan beter via email of een telefonische helpdesk.

Daar waar iTunes gewoon DRM (Digital Rights Management) vrije muziek verkoopt, loopt de digitale boeken markt kennelijk nog achter. Daar is DRM nog de norm. De bevestigingsemail van Bol (die ik checkte nadat na een paar dagen het boek nog steeds niet door de brievenbus was gevallen) bevat dus geen link naar een simpel pdf-je, maar een link naar een .acsm bestand. Om dat bestand op mijn PC te openen, heb ik volgens Bol het programma Adobe Digital Editions nodig. Vervelend, want dan heb ik weer een apart programma waarin ik maar een deel van mijn digitale literatuur kan lezen.

Bij installatie van dat programma kun je er voor kiezen om een Adobe ID aan te maken. Boeken die je koopt worden aan dit Adobe ID gekoppeld, en je kunt maximaal zes apparaten (PC, iPad, ereader) autoriseren om die boeken vervolgens te lezen. Hiervan gingen mijn haren recht overeind staan: wat heeft Adobe er mee te maken met welke boeken ik lees?

Adobe Digital Editions gebruikt een speciaal door Adobe ontwikkelde DRM technologie, ADEPT (Adobe Digital Experience Protection Technology) genaamd. Hoe ADEPT werkt is lastig te achterhalen. Het principe lijkt te zijn dat elk boek en iedere gebruiker een eigen sleutel hebben. De sleutel van de gebruiker zit verstopt in de software om digtale boeken te lezen. In dit geval dus Adobe Digital Editions. Die sleutel moet verstopt zijn om er voor te zorgen dat je boeken niet met anderen kunt delen. Dit is dus het DRM gedeelte. (NB: Zoals elke vorm van DRM is ook ADEPT gehackt en kan deze sleutel achterhaald worden).

Als je een digitaal boek koopt, krijg je de versleutelde inhoud van het boek. Vervolgens krijg je een door Adobe ondertekende licentie voor dit boek, waarin ook de decryptiesleutel voor het boek verpakt zit. In de licentie die Adobe tekent staat je gebruikersnummer (gelinkt aan je Adobe ID) en welk boek het betreft. Adobe weet dus precies welke digitale boeken je koopt. Dat lijkt me niet de bedoeling, en het is ook niet nodig. Als er dan zonodig DRM gebruikt moet worden, dan kan dat ook op een privacy vriendelijke manier.

Beste Dimitri: dank voor je boek. Ik heb er nog geen letter in gelezen, maar ik heb weer veel geleerd over DRM en hoe het niet moet.

ADEPT (Adobe Digital Experience Protection Technology) is the DRM (Digital Rights Management) system developed by Adobe to protect ebooks. The description below is based on the Adobe Content Server 4 User Manual,
this paper, a github site (confirmed by my own traces) and the following
ADEPT hack.

In the simplest ADEPT setup, there are three parties involved. A user running Adobe Digital Editions (ADE, currently at version 1.7), a distributor running Adobe Content Server (ACS, currently at version 4), and Adobe itself (!).

In ADEPT, ebooks are encrypted with a book key (i.e. each digital copy of the same book is encrypted with the same key). The distributor picks this key, and encrypts the ebook using that key.

Each user has his own user key. This key is generated when the user installs Adobe Digital Editions (ADE), and is uploaded to Adobe. Users are encouraged to activate their copy of ADE using an Adobe ID. Different devices (at most 6) may be activated using the same Adobe ID. Each of these devices then use the same user key (and hence can process any license issued to this key, allowing a single ebook to be read on multiple devices). It seems that each time ADE is started, it fetches this key from Adobe (this would make sense, because then the user key is never stored on disc making it harder to obtain it).

When a user buys an ebook, two things happen: ADE downloads the encrypted ebook from the distributor, and ADE obtains a license for this ebook through a process called fulfillment. The fulfillment proces runs as follows.

First ADE authenticates to the distributor (in fact it only identifies itself by sending three certificates and the user id). Then ADE contacts adeactivate.adobe.com with a LicenseServiceRequest that contains again the user id, a nonce, and a signature. It is unclear to me what the purpose of this step is (it is also not described in the message flow in the Adobe Content Server User Manual).

Then ADE sends a fulfillment token (basically an unsigned license containing the user id and information about the ebook bought) to the distributor. This message is signed (presumably by the user key). The distributor forwards the unsigned license to Adobe. Either Adobe or the distributor include the book key, encrypted against the user key. The resulting license token is signed by Adobe and sent through the distributor back to the user. This license is stored with the encrypted ebook. Because it contains the book key (encrypted against the user key) it allows ADE to decrypt the ebook whenever the user wants to read it.

Because the unsigned license sent to Adobe contains both the user id and information about the book, Adobe gets to know all the ebooks you buy. This is a clear privacy infringement. It is also unnecessary.

I don’t think Adobe needs to sign licenses directly. Why can’t the distributor sign the license certificate himself, with a key certified by Adobe (for which the distributor can provide the Adobe issued certificate to the user application). If a check needs to be made against the user, only the user id (not the details about the book bought) could be sent to Adobe for a ‘background check’. It would reveal to Adobe how many books you buy, but at least not which ones.

I have compiled this post based on the limited information I could find. Any more information would be appreciated.

We have

_SECURITY
__PRIVACY
---------+
NOTEQZERO

Each symbol represents a digit. We have more than 10 symbols, but require that at least all digits occur in this sum.

To make the sum correct for the most significant digits of the result (N and O), a little reasoning shows that S=9, N=1 and O=0. We now have

_1
_9ECURITY
__PRIVACY
---------+
10TEQZER0

with a carry that must be the result of E+P (more about that later)

Now lets turn to the least significant digits. We see Y+Y=0 (or 10). So we set Y=5. This gives

_1     1
_9ECURIT5
__PRIVAC5
---------+
10TEQZER0

Now we turn to C and R. They occur in two columns of the sum: we have
C+R=E and we have R-C=T+1. As a consequence, if C and R are both even or both odd, then E is even and T is odd. If the parity of C and R is unequal, then E is odd and T is even.

Moreover, E+P=10+T (because of the required carry). Several combinations for
E and P satisfying the constraint that E+P>10 have to be tried until we find a combination that ‘works’: E=3, P=7 and hence T=0.

_1     1
_93CURI05
__7RIVAC5
---------+
1003QZ3R0

This also fixes C=1 and R=2 (by C+R=3 and we have R-C=1)

_1     1
_931U2I05
__72IVA15
---------+
1003QZ320

Now this leaves us to assign the values 4, 6 and 8. We have the requirement
2+V=Z so setting V=6 and Z=8 assigns two of these values.

_1     1
_931U2I05
__72I6A15
---------+
1003Q8320

This leaves I+A=3 and U+I=Q, and the constraint that the value 4 is not used yet. Let’s set Q=4. Then I=1, A=2 and U=3 satisfy the equations and yields the end result.

_1     1
_93132105
__7216215
---------+
100348320

Now we ask ourselves: what is this number? A
google search gives us the answer:
a beautiful woman, as symbol of the beautiful road ahead when security and privacy escape from the trenches and go ahead hand-in-hand together…

And don’t worry: I’ve been accused of being uncurably optimistic before

Maar dan dat voice response systeem… Dat hebben ze expres zo gemaakt dat je uit pure ellende voortijdig ophangt! En dat moet je vooral niet doen, want (zoals het systeem zelf al zegt aan het begin van het gesprek) je voorkeuren worden alleen maar opgeslagen als je helemaal tot het eind aan de lijn blijft. Ze geven veel te veel keuzes, begrijpen antwoorden niet, en je moet ook nog eens zelf je telefoonnummer invoeren (wat ik niet zo goed snap, want ze bellen mij toch zelf?).

Hoe moeilijk kan het nou zijn: “Dit is het bel-me-niet register. Druk op 1 als u niet meer ongevraagd gebeld wilt worden door telemarketeers. Druk op 2 voor meer opties…. Dank u voor uw keuze. U kunt nu ophangen”.

P.S.: Hun website is al niet veel beter. Iets met gedwongen creëren van account, en email adres en zelfs huisadres vereist… Ik geef zo meer persoonlijke informatie prijs dan het simpele telefoonnummer dat ik wil blokkeren!