Asumptions

In our analysis we assume the following (based on the extensive blog entry by
Jesper Johansson on this matter, but extended and adjusted based on other sources).

• Password characters are typically selected from a set of 76 symbols: 26 lowercase letters, 26 uppercase letters, 10 digits and 14 other symbols (!@#$%^&*()-_+=). Not all of them are as frequently used however. Many passwords are restricted to a subset of the 32 most common symbols. A truly random password can use all printable ASCII characters, of which there are 95.
• English language has over 600.000 words. The average passive vocabulary (receptive knowledge) of a native speaker ranges from 10.000 to 20.000 words.
• The number of words actually used (productive knowledge) by a native speaker is much lower than that. Jesper Johansson estimates this to be 300, but I think this is highly conservative. One source claims a random copy of the Sun (a popular UK newspaper) contains 8000 distinct words. Basic word lists on the other hand contain 850-3000 words.
• Frequency of word use is highly unbalanced. The first 25 most common words make up about one-third of all printed material in English, and the first 100 make up about one-half of all written material. This may bias words used in passphrases.

Types of passwords and passphrases

We distinguish the following classes of passwords and passphrases.

• mutilated word passwords, where a single uncommon word is taken as a password, after which certain characters are replaced with similar looking ones, and some non-letter symbols are appended (to comply with the password policy).
• random passwords where each character is selected at random from all 95 available symbols.
• common word passphrases, where each word is taken from the 1000 most basic words.
• uncommon word passphrases, where each word is taken from an extended list of 10000 words. (The motivation here is that for a strong passphrase, people should pick words they know, not necessarily ones that they would ever use in actual conversation.)

The case of a single word used as a password (like “password”, or a personal name) is covered by the common word passphrase of length one.

Entropy

A common means to express password strength is to compute the entropy of the class to which it belongs. Without getting to be too mathematical, the entropy of a set of words loosely corresponds to the number bits needed to uniquely represent each word in the set. A set of 16 words that are all equally likely to occur have an entropy of 4 bits.The expected number of tries needed to find the one that matches an entry in a password file is given by the guessing entropy of the set. If all these words are equally likely, to find the one that matches  will on average require you to try half of them. In other words in this case the guessing entropy is   tries.

We make the (simplifying) assumption that, within each class, each password or passphrase is equally likely. In general this is not the case, so in general the attacker is expected to discover the password or passphrase sooner than suggested by the entropy alone. In practice, the attacker will launch several attacks in parallel, using different assumptions about the construction of the password used. For example, the attacker will try a list of common passwords (like “password”) in one of these threads. By distinguishing the classes above, we crudely approximate this. In any case, without any data to approximate the distribution of passwords or passphrases in a single class, this is the best we can do.

Analysis

Given the above assumptions, we can compute the entropy of entries in each class. In the following, is the password length (in characters) or passphrase length (in words). In other words, is the number of units a user needs to memorise.

• mutilated word passwords: . Here 4 bits of entropy are added for substitutions in the uncommon word used as password, and 2 times is added for adding two non-letter characters at the end of the password.
• random passwords: , where 95 is the number of printable ASCII characters.
• common word passphrases: , where 1000 is the number of common words.
• uncommon word passphrases: , where 10.000 is the number of uncommon words.

The following table presents the entropy for entries of different length in each class.

The amount of time an attacker needs to verify a password or passphrase guess depends on several factors.

For an online attack, a typical estimate for the number of guesses an attacker can try is a 1000 per second. However, we will not consider this case here
as online services may easily make such attacks impractical by using increasingly more time to respond to a login for an account that has many failed login attempts. Note that blocking the account after a few tries is not a good idea, as this can be abused for a denial-of-service attack.

In an offline attack, where the attackers has a copy of the password file from the server, it heavily depends on the resources (i.e. money) of the attacker and the hashfunction used to map the password onto the digest stored in the password file. It is for this reason that the hashfunction used for passwords should be special and take a significant time to compute. An attacker can easily try a million of guesses a second, and even more with dedicated hardware. Against such an attacker, a password or passphrase in a class of 46 bits of entropy takes on average a year to crack, and a 28 bit password or passphrase only a day.

Note that the Ecrypt II recommendations for cryptographic key lenght specify 80 bits as the minimum entropy for the smallest general purpose security level. This corresponds to a passphrase consisting of 6 uncommon words.

This clearly shows that the passphrase “This is fun” is really not that secure, contrary to what is claimed here. It is important to stress why this is the case: an adversary will first try the short list of common words. This is the same reason why a password like “jskerv” is risky while “J4fS<2″ is more secure. As long as many people choose letter only passwords, a smart attacker first tries only such passwords before trying more complex ones.

Conclusions

An empirical study from Cambridge University found that passphrases are easier to remember than strong random passwords. Moreover, mnemomic passwords derived from such passphrases (by using the first letter of each word as a password character) are just as secure as those random passwords (of the same length).

However, the above discussion shows that using a full passphrase (instead of a mnemomic password derived from it) is as secure as a random password of twice the length!

So, xkcd is right: passphrases are easier to remember and harder to crack, while passwords are hard to remember and still easy to crack. (Although the example password he uses is not really random.)

De eerste vraag is eenvoudig te beantwoorden. Ook al zijn euro munten en euro biljetten een wettig betaalmiddel, winkeliers zijn niet verplicht die te accepteren. Datzelfde geldt bijvoorbeeld ook voor de ChipKnip of een pinpas.

Roofovervallen op winkeliers worden als reden genoemd. In een gesprek dat ik laatst met een aantel kennissen uit Amsterdam had bleek zelfs dat het daar als asociaal wordt gezien als je contant betaalt. Je zadelt immers iemand met een onnodig risico op. Toch is dat vreemd. Het aantal overvallen is al flink gedaald de laatste jaren. Dat zal zeker te maken hebben met de toename van het gebruik van PIN en de daardoor afnemende hoeveelheid contant geld in de kassa. Maar ook de kosten voor het accepteren van contant geld spelen een rol. De laatste jaren zijn de bancaire kosten van PIN gedaald, en kosten van het afstorten van contant geld verhoogd.

De echte vraag is of dit allemaal wel zo gewenst is. Het feit dat een winkelier mag kiezen hoe er betaald wordt volgt uit het principe van contractsvrijheid. Winkelier en klant gaan een overeenkomst aan, waarvan de inhoud en de vorm volledig vrij is, tenzij de wet anders bepaalt. Belangrijk is wel dat de inhoud van de overeenkomst echter niet tot maatschappelijke onaanvaardbare mag gevolgen leiden. En hier wringt de schoen toch wel een beetje.

Bij iedere PIN betaling ziet de bank hoeveel geld je uitgeeft in een bepaalde winkel. Pinnen bij het tankstation: de bank kan redelijk goed schatten hoeveel kilometer je per jaar rijdt. Kan interessant voor de autoverzekering zijn, omdat de premie hier soms van af hangt. Door te pinnen bij de snackbar, in de kroeg, of in de tabakszaak geef je de bank informatie over je ongezonde lifestyle. Op zich geen probleem als je daar zelf voor kiest. Maar als steeds meer winkels contant geld weigeren, heb je straks geen keuze meer. En dan leidt de individuele keuze van winkeliers om geen contant geld te accepteren collectief tot een onaanvaardbaar gevolg.

Daarnaast is er nog een ander ‘praktisch probleempje’. Vorige maand had de ING te kampen met een storing waardoor het saldo van rekeninghouders soms te laag werd ingeschat. Met als gevolg dat ze virtueel rood stonden en niet konden pinnen in de winkel. Detailhandel Nederland riep op tot maatregelen, waaronder het regelen van een goede backup. Ik weet nog wel een betrouwbare backup die al eeuwenlang zijn waarde heeft bewezen.

Contant geld.

Doomed because this is the perfect password phishing email! Send all Google account holders this email, and many of them will click on this link because they (indeed) did not change their password. Let the link point to a website that looks like the genuine Google password reset page. And ask all users to enter their old password before offering to reset it. Then, using the old password just entered, take over the account.

Doomed because I have no clue how to prevent this. Sending the email makes perfect sense to notify people of possibly suspicious behaviour on their account. Offering a link to click makes perfect sense from a usability perspective. But because people hardly ever visit the Google account recovery page, they have no idea what to expect, and will be quite gullible to enter whatever information is asked of them. In fact, they would expect to have to enter a lot of information to prove they are the real owner of the account. So hackers can also ask for a additional information like credit card information as well. (Don’t laugh: I’ve once tried to regain control over an account at Google that someone screwed up and I was in fact asked to supply credit card information… I did not comply and was forced to abandon the account and create a new one).

Embedding some secret information in the account recovery page that the account holder should recognise does not help. Because you hardly ever visit this page, you don’t know you should look for this authenticating piece of information. (If, however, this was standard practice for all account recovery pages, this might actually work. But note that in this case the reset link in the email should contain an access token that allows the account reset page to retrieve the secret information from within your account.)

If anybody has an idea, please mention it in the comment section below!

In the privacy debate, pseudonyms are a red herring. They offer only a weak level of protection. People often believe that they can hide behind a pseudonym. But this belief is wrong. Pseudonyms only provide context separation. They make it impossible to link data about me in one context with data about me in another context. Within one context, pseudonyms act like real identifiers, and behave just like real names.

Whether a data record refers to me by name, or by email address, or by a strong pseudonym (that cryptographically prevents the pseudonym to be linked to me) does not really matter. The data refers to me, and the data will be used, within that context, to judge me, make decisions about me, etc. Therefore, the protection offered by the regulation is just as necessary for pseudonymous data as it is for non-pseudonymous data. This is not to say that pseudonyms are useless. They are a sane technical measure in the privacy-by-design toolchest. But they should not provide an escape route to avoid compliance with the data protection regulation.

Onder de Foreign Intelligence Surveillance Act (FISA) – en recente amendementen – is de Amerikaanse overheid gerechtigd om gegevens over een willekeurig persoon bij een dienstaanbieder op te vragen, ook als er geen concrete verdenking op deze persoon rust, en ook als deze gegevens nooit op Amerikaans grondgebied zijn opgeslagen of verwerkt. De enige eis is dat de dienstaanbieder die de gegevens (in Europa) verwerkt structureel activiteiten binnen de VS ontplooit, bijvoorbeeld door een vestiging te hebben, of onderdeel te zijn van een in de VS gevestigde onderneming die controle heeft over de betreffende gegevens. Dit is een veel ruimere bevoegdheid dan de mogelijkheden die een rechtshulpverzoek biedt. Details zijn terug te vinden in dit uitermate interessante IViR rapport over deze materie.

Anders dan de minister suggereert bieden de huidige Wet bescherming persoonsgegevens, en ook de nieuwe Europese verordening aangaande gegevensbescherming, geen soelaas. Ook contractuele afspraken met dienstaanbieders geven geen bescherming tegen het Amerikaanse ‘datagraaien’. Het enige wat deze tegenstrijdige wetten en afspraken doen is de dienstaanbieder in een onmogelijke positie brengen. Hij moet immers zowel aan de Amerikaanse als aan de Europese wetgeving voldoen, terwijl dat dus niet allebei kan. Wat hij ook doet, de dienstaanbieder zal gestraft worden. Zijn keuze hangt dan waarschijnlijk af van de hoogte van de straf…

Veel lijkt er niet te doen te zijn om deze onwenselijke situatie op te lossen. Uiteindelijk zullen internationale afspraken gemaakt moeten worden om deze conflicterende wetten op één lijn te brengen. Misschien dat het helpt om de Amerikanen op andere gedachten te brengen door vergelijkbare wetten op te stellen die het ons mogelijk maken om in hun data te graaien….

Naschrift: wat u zelf natuurlijk wel kunt doen is een Europese dienstaanbieder gebruiken. Maar dan wel een die zijn diensten niet in Amerika aanbiedt.

Een penetratietest moet een serieus onderdeel zijn van een totaal beveiligingsplan, en dus professioneel opgepakt worden. Gratis studenten gebruiken wekt bij mij de indruk dat de overheid beveiliging niet echt serieus neemt. Zeker als je bedenkt dat een goeie exploit voor (tien)duizenden euros verkocht kan worden… Daar komt nog bij dat een penetratietest op zichzelf nog maar weinig zegt over de veiligheid van een systeem. Wel als er lekken gevonden worden. (Maar ook dan geldt dat er geen koe zo bont is of er zit wel een vlekje aan.) Maar als er geen gaten gevonden zijn betekent dat niet meteen dat die er ook echt niet zijn. Dat hangt onder meer af van de reikwijdte van de uitgevoerde penetratietest, de tijd die je er in stopt, en de kwaliteit en ervaring van de testers natuurlijk.

Daar staat tegenover dat wij wel de waarde zien van zo’n penetratietest voor de studenten zelf, als onderdeel van hun opleiding tot security expert. Aan de Radboud Universiteit zijn we op dit moment bezig een bachelorprogramma computer security op te zetten, die 1 september 2013 van start gaat. Onderdeel van het bachelorprogramma zou een 2e of 3e jaars vak kunnen zijn waar zo’n penetratietest een onderdeel van uit maakt. Daar gaan we nog eens over nadenken.

Veiligheid van elektronisch stemmen is het hete hangijzer. De stemcomputers van Nedap waren onveilig. Terecht dat in 2008 dus is besloten om die af te schaffen. Maar daarmee is niet gezegd dat iedere vorm van elektronisch stemmen onveilig is. De Adviescommissie inrichten verkiezingsproces, onder voorzitterschap van Korthals Altes, heeft hier in 2007 al uitgebreid bij stil gestaan. De samenvatting van het rapport begint met een aantal eisen waaraan een (elektronische) verkiezing moet voldoen. Zij constateert dat “geen enkele vorm van stemmen [ook die met papier en potlood] absoluut aan alle waarborgen voldoet”.

Naar mijn mening zijn er zeker varianten van elektronisch stemmen die aan een groot aantal van deze eisen kunnen voldoen. Zo zijn er cryptografische systemen (voter verifiable voting schemes) die de kiezer zelf in staat stellen om te controleren of zijn stem is meegeteld in de einduitslag. Wel is een ‘paper trail’ van groot belang om naderhand bij vermoeden van fraude op terug te kunnen vallen. De essentie is immers dat een druk op een knop niet later nog eens teruggehaald kan worden. Met zo’n paper trail zouden ook stemcomputers, mits op de juiste wijze ontworpen, aan de eisen kunnen voldoen. Een grondige, onafhankelijke, analyse moet uitwijzen of dergelijke systemen echt een vergelijkbare veiligheid bieden als stemmen met potlood en papier.

Sommige van deze technieken zijn ook voor stemmen over het Internet toepasbaar. Wel moet men zich realiseren dat bij Internet stemmen er veel minder controle is op de omgeving waarin gestemd wordt. Zo is er een verhoogd risico op stemdwang, of de verkoop van een stem. Aan de andere kant gelden veel van die bezwaren ook voor het per post stemmen in het buitenland. Heikel punt blijft wel de onveilige omgeving (veelal de PC thuis) waarmee in dit geval gestemd wordt. En laat nu juiste de mogelijkheden van Internet stemmen het interessantst zijn voor directe vormen van democratie… Dat is een lastig dilemma.

Ook de voordelen van het elektronisch stemmen voor mensen met een handicap moeten worden meegenomen. Speciaal ontworpen stemcomputers kunnen hier van dienst zijn. Daar staan de kosten van het ontwikkelen en in gebruik nemen van een systeem voor elektronisch stemmen tegenover. Voor een landelijke stemming eens in de zoveel jaar is het maar zeer de vraag of het uitkan. Als de enige reden is dat we de uitslagen graag een uur na het sluiten van de stemlokalen willen weten, dan moeten we ons nog maar eens even achter de oren krabben…

Samengevat: ja, er zal een risico zijn. De vraag is of dat risico beheersbaar is, en vergelijkbaar met de huidige situatie is. En natuurlijk ook of de kosten opwegen tegen de baten. Maar we doen ook aan Internetbankieren, en ook in het ziekenhuis wordt bij ingewikkelde operaties steeds meer op ICT vertrouwd, ook als het gaat om zaken van leven of dood. Dus een principieel ‘njet’ (net als een kritiekloos ‘ja en amen’ overigens) vind ik geen antwoord op de vraag of elektronisch stemmen kan of niet: tussen die twee uitersten ligt een wereld van genuanceerde antwoorden.

The problem to solve is the following. Attribute based credentials are in principle a privacy enhancing technology. They allow a user to selectively disclose certain personal attributes. This, in turn, implements context separation: attributes relevant in a private context need not be revealed in a work context, and vice versa. Often, a form of sector specific pseudonyms are also supported. These allow you to securely use different pseudonyms in different contexts that cannot be linked.

Current digital signature functionality is often blissfully unaware of context. The smart card contains one signing key, and a corresponding certificate that binds that key to your real identity, i.e. name. Using such signatures in a particular context totally breaks the context separation that was so carefully established using the attribute based credentials. As explained before, the signature of a notary is highly valuable, and it should not be possible to mix a notary signature for private use by accident.

Therefore, it would be useful to extend the signature functionality of eID cards in two ways. First of all, one should be able to create a signature under a sector specific pseudonym, such that the signature does not allow linking to the real identity. In other words, a different signing key (and corresponding certificate that links this key to the pseudonym) needs to be used for each pseudonym. This should be implemented in an efficient manner. How to do this is something worth thinking about.

Secondly, a user should be able to sign under a collection of attributes. That is to say: the signature proves that the signer was in the possession of the specified set of attributes. This should in fact be implemented in two forms: a privacy friendly one where no other information is revealed, and a version where the signature is actually linked to the identity of the signer. The latter case supports use cases where for example a notary can use his private key to sign both in an official capacity (i.e. the document has a special status because it is signed by a notary), and in a private capacity (when signing the contract for selling his own house).

Without consideration of these issues and use cases, the use of integrating digital signature capabilities on smart cards that support attribute based credentials is rather limited.

Identity management systems

When we consider identity management systems from a broad perspective (and not just limited to providing authentication and single sign on), such systems allow a user to reliably prove certain characteristics (called attributes) about themselves to others. Typically, these attributes are used by businesses to make a business decision during a transaction between the user and the business. A common example is verifying the age of a customer before selling alcohol or cigarettes. But more complex examples are certain possible, like verifying whether a user is a legitimate representative of a company with a certain creditworthiness, or verifying that the user is a doctor that is allowed to prescribe this medicine at the requested dose or quantity. In the realm of identity management, the business relying on these attributes to make a business decision is called a relying party. In very generic terms, a relying party protects access to a resource and provides access to this resource depending on the credentials a user can show.

A simple approach to identity management is to create an identity provider that has accounts for all users, and that stores all attributes for these users in those accounts. To learn the attributes of a user, the relying party asks the user to sign in to the identity provider, after which the relying party will ask the identity provider about the user attributes directly. This works and has been implemented. It is also quite straightforward to make money in this model, as the identity provider is involved in all transactions on-line. It is the spider in the web. It can ask a small fee for each attribute requested by the relying party. The relying party is typically willing to pay for this, as the attribute allows him to automate his business processes and makes them more secure. However, this architecture for identity management is a privacy nightmare.

Privacy friendly architectures for identity management do exist, for example using attribute based credentials. In these systems, credentials are secure containers that store the user attributes. Users obtain such credentials from a credential issuer, that can vouch for the validity (for this user) of the attributes contained in the credential. The credential (being a secure container of the attributes) allows the user to prove possession of the attribute to the relying party. Privacy is guaranteed by making the proof involving a credential unlinkable to other proofs involving the same credential, or to the issuing of the credential. Note that the attribute provider is not involved in the proof of possession of a credential. Moreover, using the technique of selective disclosure, the user can choose to reveal only a selection of the attributes contained in a credential.

When using attribute based credentials, the user is the spider in his own little web. The question then is how to make money as the provider of (a service within) such an identity management infrastructure.

Before answering this question it is important to realise that typically three more parties play a role in an identity management systems. First and foremost, there is the scheme authority that lays down the architecture of the system, and governs its operation. It is responsible for ensuring the system is useful, economically viable, secure and respects privacy. The scheme authority, for instance, decides which attribute providers and relying parties are allowed to use the system (and revokes their access if they fail to comply with the rules). Typically, relying parties need to authenticate and provide the appropriate certificates to the user in order to read out certain attributes. This relying party authentication (traditionally called terminal authentication) prevents relying parties from sneakily collecting all attributes of a user.

Moreover, there are so called token issuers (for lack of a better name) that provide the security tokens (typically smart cards) that users use to securely obtain, store, and use credentials.

Looking at this from a slightly higher level of abstraction, we can distinguish the following classes of roles.

• Providers (Credential Issuers, Token Issuers) that offer identity management functionality.
• Users (User, Relying Parties) that benefit from the functionality offered by the providers in the identity management scheme.
• Governors (Scheme Authority) that govern the identity management scheme and are responsible to maintain the trust and value of the scheme.

Additionally, there may be one or more service providers that offer services that make it easy for attribute providers or relying parties to connect to the system by offering tailor made services. For example, a service provider may offer a relying party to do the validation of credentials in its place, and only return whether the credentials verified correctly. (This does incur a privacy risk if a service provider serves many different relying parties, and the attributed revealed are identifying. In this case, the service provider learns the visiting patterns of users over a large set of relying parties.)

Initial analysis of business issues

The primary value of the identity management system is determined by the (perceived) trust in the system by all parties involved. It is the main responsibility of the scheme authority to ensure this (by proper rules and enforcement of these rules). As a consequence, the level of security provided by the token providers and attribute providers must be high, which comes at a cost. (Relying parties primarily cause damage to themselves if they fail to reliably verify credentials, although repeated incidents will have an impact on the overall reputation of the scheme.) This cost must be earned back to justify the investment.

Users and relying parties are the main parties that benefit from an identity management system. Relying parties now have a secure way to verify attributes of their customers. This may solve legal compliance issues (the need to verify age for certain types of business, for example), lead to new business opportunities, and streamline existing business by reducing risks due to uncertainty. As a consequence, relying parties may use the expected benefits to be obtained for their normal business as a factor to justify the investment in an identity management system. Similarly, users have a privacy friendly and secure way to present attributes. This increases the online user experience. Moreover, attributes may be used to protect access to user assets stored at relying parties, making them more secure. However, it may be hard to convince users to actually pay for tokens or getting credentials. They may perceive this as an artificial barrier, an extra cost incurred for accessing a service that they previously did not have to pay. On the other hand, citizens are used to paying a significant amount for passports and physical identity cards.

The other system entities, and especially credential issuers, have no external business needs to join an identity management system (it does not enable them to do the business they are already engaged in, except if they are a relying party as well). They may of course see a business opportunity within the identity management system itself, but this is a different driver. In particular, benefits obtained outside the identity management system are not foreseen and therefore cannot be used to justify an investment.

Because relying parties allow access to an asset depending on the credential a user can show, credential issuers hold, in fact, the keys to these assets. This makes them as responsible for protecting these assets (through proper issuing of credentials) as the relying parties. This raises the issue of liability if something goes wrong. If access to an asset is given because of an improperly issues credential, the relying party is not at fault. But if we want to make the issuer liable, then the risk they run when their credentials are used to protect very valuable assets becomes high. As a result, the cost of issuing credentials becomes high as well, potentially raising the cost of a credential beyond reasonable proportions. The extent of this effect needs further investigation.

Identity management systems (like credit card systems) are a two-sided market (or network) with cross-side effects. Such markets have two types of parties that provide network advantages to each other: the value of an identity management system for the users increases with the number of relying parties, whereas the value for the relying parties increases with the number of users. The number of users increases with the number of tokens and attributes providers they can use to connect to the system. Such markets run the risk of the two sides waiting for each other to grow. To maximise the growth of such a two sided market (with cross side effects) the system must be open. It is especially important that a free and open market of service providers is established that make it easy to set up and connect attribute providers (to increase the user side) and relying parties.

Possible solutions

Below I briefly sketch two (of the possibly many) ways to make a business out of privacy friendly identity management.

Providing identity management services

In the German eID system, so called eID services exist that handle the verification of card attributes on behalf of the relying parties. Users visiting the relying party are redirected to the eID service, that subsequently runs the identity management protocols to determine the user attributes. After a successful run, the eID service returns the user attributes to the relying party using a very simple protocol. This makes it very easy for relying parties to incorporate the German eID card in their current web environment. The eID service can charge a fee for each credential verified.

The German approach is a very good way to kick-start the uptake of eID by relying parties. But it incurs a privacy risk, as the eID service sees all attributes it verifies, and sees for which relying parties these attributes are used. This allows the eID service to link users to relying parties. This can be mitigated by requiring that the eID service is stateless and does not keep any logs of the interactions it is involved in. This should be fiercely monitored by the scheme authority. Also, the scheme authority should stimulate that many different eID services exist.

Another approach is to in-source the verification of credentials to the relying party. This essentially boils down to moving the server that runs the eID service within the relying party premises. This ensures that different relying parties run a different instance of the eID services, greatly reducing the privacy risk. In terms of business opportunities, the eID server can be sold as a plug-and-play device that requires little maintenance. Additional maintenance contracts (guaranteeing updates when new versions of the identity management system are released, or offering the addition of new eID standards when they appear) can also be sold. Alternatively, a licensing scheme can be agreed on, where the fee depends on the number of credentials verified with the locally installed system.

Using the smart card as a purse

The main problem of a user-centric identity management system, like those that are based on attribute based credentials, is that there is no direct link between the credential issuer (that provides value) and the relying party (that consumes this value). This makes it hard to force the relying party to pay for the use of a credential. However, this can be mitigated by letting the user be the go-between. An electronic purse on the same smart card that is used to store and show the credentials can be used to receive a payment whenever a credential is shown at a relying party, and pay with that money the next time a credential is requested from an issuer.

Om het probleem aan de kaak te stellen is het logisch dat de media zijn ingeschakeld. Maar gezien de gevoeligheid van de gegevens is de NOS niet de aangewezen organisatie om in dit soort gegevens rond te neuzen. (Ik ga er maar even van uit dat de NOS hiervoor bij Digital Investigation op bezoek is geweest, en niet een kopie heeft gekregen…). De vraag is dan wel: wat moet je doen als je zo’n bak met data in handen krijgt?

Er zou een onafhankelijke organisatie moeten zijn waar je met deze data heen kunt. Een organisatie die op een absoluut veilige manier om kan gaan met deze (privacy) gevoelige informatie. Een centraal loket ‘gevonden data’. Deze organisatie moet vervolgens er voor zorgen dat misbruik van de informatie zo snel mogelijk wordt gestopt. Daarnaast kan zij een inschatting maken van de omvang van de schade, en eventueel iets zeggen over de mogelijke oorzaken, en de daders.

Om misbruik te stoppen is het niet zinvol direct de eindgebruikers te benaderen. Ten eerste is het vaak lastig om te bepalen om wie het gaat, en om ze vervolgens te bereiken. Daar is vaak extra informatie voor nodig. Daarnaast zullen die eindgebruikers dan eerst zelf stappen moeten ondernemen voordat het misbruik ook echt stopt.

Beter is het om naar het type informatie te kijken (is het een IP adres, een creditcard nummer, een bankrekening nummer, een Facebook account, etc.) en vervolgens direct contact op te nemen met de uitgever van de informatie (de ISP, de creditcard maatschappij, de bank, Facebook, etc.). Deze uitgever kan het account meteen blokkeren, en vervolgens de klant inlichten en hem helpen het probleem op te lossen.

Bovendien maakt zo’n ‘loket gevonden data’ het voor de goedwillende klokkenluider meteen duidelijk waar hij met zijn vondst heen moet – en maakt zo het melden van misstanden iets minder onaantrekkelijk.