Naive approaches against identity theft

2010/05/20

Two things happened today that made me think about how current measures against identity theft are so very naive. The first is a US bank that I’m a customer with. I hardly ever log in on their website, and of course had forgotten the password. To assure that I am myself, I had to provide two answers about myself that I’m sure many (10s or 100s of) people know, and many more can very easily find out (including place of birth, which I had to put on page 5 of my PhD thesis that is publicly downloadable). And since the web interface did not allow me to do what I wanted (to terminate the account), I had to call them. During this call I had to provide those two same answers, plus my home address (which is listed in the phonebook). The funny thing is that I had to provide these answers twice during the same phone call, which did not make me feel more secure at all …

This type of static knowledge authentication is simply NOT suitable to authenticate any transaction that requires more than a very minimal level of assurance, and it is very naïve to use it for online banking (see also).

The second thing that happened today is a commercial I saw from the Dutch government, part of a campaign for a safer internet (“Veilig Internet. Heb je zelf in de hand”). The campaign seems to focus on peoples own responsibility to prevent identity theft.  The commercial however was very limited, stating that people should change their password once in a while, and make sure who you email your personal data. The first recommendation is very naïve because 1) I’m convinced people don’t do this unless forced to and 2) it doesn’t help much against e.g. malware, phishing or using the same password at many sites. The second recommendation assumes that personal data is used to authenticate yourself, which it simply shouldn’t (see the first paragraph).

Although I welcome the attention that this campaign brings to the issue of identity theft, I wonder if spending more energy and time on better authentication and identity solutions for the internet wouldn’t be more effective than this campaign.


Network Approach to E-identification (eRecognition)

2010/04/20

Recently the Dutch company Innopay published, on behalf of the Ministerie of Economic Affairs, a report called A Network Approach to E-identification (http://www.innopay.com/index.php/plain/newsletters/04_2010_e_identity_as_a_two_sided_market_the_business_case_will_drive_adoption_not_the_technology). This is an interesting report that gives some background and motivation for the Dutch eRecognition program which works on a trust framework, of scheme, for business-2-government identity. Together with Paul Oude Luttighuis, a colleague and interoperability expert, we wrote a short reaction. This reaction is below, but in Dutch … For non-Dutch speakers, among others we discuss:

  • We support the choice for a network model (or trust framework or scheme)
  • The report advocates the use of a four party model, as is used in the financial world, contrary to the probably more common three-party model (user, identity provider, relying party).
  • We discuss the risk that new parties trying to enter this market are prevented from doing so by the parties already active in it.
  • We discuss the opportunity to have mutual authentication, i.e., the service provider could also authenticate to the user.
  • We discuss semantic issues, and pseudonyms.

What follows is the Dutch text (feel free to experiment with Google Translate …).

Wie bent u om mijn klant te zijn?

Recent publiceerde het bedrijf Innopay op verzoek van het Ministerie van Economische Zaken hun rapport A Network Approach to E-identification (http://www.innopay.com/index.php/plain/newsletters/04_2010_e_identity_as_a_two_sided_market_the_business_case_will_drive_adoption_not_the_technology) .  Dit belangwekkende rapport bespreekt het gedachte­goed ach­ter hui­dige e-identity-ontwikkelingen bij de Nederlandse overheid. Paul Oude Luttighuis ( Enterprise Interopera­bility expert bij Novay) en Maarten Wegdam (Identity Management expert bij Novay) rea­geren.

============================

Het stuk bepleit een netwerkbenadering. Die gaat uit van interoperabiliteit tussen concurrenten, gevat in een expliciete en goed beheerde set van afspra­ken (door het stuk een scheme genoemd), in plaats van een centrale voor­ziening. Als concept is dat niet nieuw, maar in het e-over­heids­veld is inderdaad de “centrale voorziening” vaak het leidende concept. Door in het netwerk rollen te onderscheiden wordt er niet alleen gekoppeld, maar ook ont­koppeld: de rollen krijgen de kans zich in hun eigen dyna­miek te ontwik­kelen. Zo’n model kan daarom soepeler groeien dan een centrale-voorzie­ning-model, zolang de rollen goed gekozen zijn en er voorzieningen zijn om te inno­veren op de koppelvlakken tus­sen de rollen.

Specifiek kiest het stuk voor een zogenoemd vier-partijenmodel, waarin twee hoofdrollen, in dit ge­val de eind­gebruiker en de dienstverlener, elk worden be­diend door een ondersteunende rol aan hun zijde. In dit geval is dat de authentica­tieprovider, die de eindgebruiker voorziet van authenticatie­middelen, en de zoge­naamde rou­ting service, die de dienstverleners toegang biedt tot het netwerk. De kernafspraak in dit netwerk is dan dat alle authenticatieproviders ver­bon­den zijn met alle routing services. Deze we­derzijds gedwongen winkelnering vraagt wel om maatregelen tegen het oneigen­lijk weren van nieuwe toetreders tot het netwerk.

Een ander voordeel van het vier-partijenmodel is dat eindgebruiker en dienstverlener via één partij toe­gang krijgen tot het hele netwerk. Natuurlijk moeten zij dan wel het hele net­werk ver­trouwen en, in­direct, de au­thenticatieproviders en routing services daarbinnen. Overigens is ook een decentraal drie-partijenmodel denk­baar. Sterker nog, gang­bare identity-fede­ratiestandaarden gaan daarvan uit en niet van een vier-partijenmodel. Sommige identity-federaties, zoals de SURFfedera­tie, hebben wel een vierde rol, maar centraliseren deze.

Overigens, het geschetste vier-partijenmodel is asymmetrisch. Bij authenticatie is sprake van twee hoofdrol­len: de partij wiens identiteit wordt vast­gesteld en de par­tij die die vaststelling ontvangt. In het stuk worden de­ze rollen geïdentificeerd met respec­tievelijk de eind­ge­bruiker en de dienstverle­ner. Dat ziet over het hoofd dat in een transactie ook de eindgebruiker behoefte kan hebben aan zekerheid over de identiteit van de dienstverlener. Is het netwerk niet ook daarvoor te gebruiken?

Een andere adder onder het gras is dat het besproken netwerkmodel weliswaar functioneel decen­traal is, maar semantisch wel degelijk cen­traal. Elke eindgebrui­ker die het netwerk als zodanig kent, heeft namelijk maar één identiteit in dat netwerk. Anders kunnen niet alle authenticatie­midde­len worden geaccep­teerd door alle dienstverleners. Dat brengt privacy-issues met zich mee, die niet door het stuk worden bespro­ken. De voor de hand liggende manier om hier­mee om te gaan is om één per­soon meerdere “eindgebruikers” te kun­nen laten spelen, door middel van pseudo­niemen. Dit is gebrui­ke­lijk in modern denken over elektroni­sche identiteit. Het stuk maakt echter niet duidelijk of het afsprakenstelsel dit gaat toe­staan en hoe wordt geborgd dat pseudoniemen niet toch worden ge­combineerd in een omvattender persoonsidentiteit.

Daarnaast heeft een eventuele centralisatie van het identiteitsbegrip ook informatiekundige gevolgen. In rela­tie met een school is een persoon leerling of student, in relatie met een vereni­ging is hij lid, in zijn relatie met een bank is hij bankklant. Dat kunnen écht andere rela­ties zijn, die dus een andere iden­titeit vragen. Denk bijvoor­beeld aan een gezinslidmaat­schap van een vereniging, of aan één persoon die ver­schil­lende relaties heeft met één dienstver­le­ner, in verschillende hoedanig­heden.

Deze semantische kwestie wordt alleen maar groter als dit afsprakenstelsel wordt uitgebreid richting eindge­bruikers die namens hun organisatie optreden, zoals het stuk aan het eind suggereert. Zo zou ook een organisa­tie-an-sich kunnen worden geauthen­ticeerd. Echter, of zo’n optreden wer­kelijk námens een organisatie is, kan van veel dingen afhangen: van een expliciete autorisatie, van de precieze ge­bruikte dienst, van het tijdstip, van de locatie of van de situatie (denk bijvoorbeeld aan noodgevallen). Deze semantische variëteit dreigt veel complexiteit in het netwerk brengen. Het zal in elk geval niet de bedoeling zijn deze genuanceerde autorisatie onmogelijk te maken, nemen we aan.

Tot slot, het stuk claimt dat zo een centralistische machtspositie wordt voorkomen. Moch­ten deze net­werken echter suc­cesvol blij­ken, zullen zij vanzelf een oligopolie of monopolie vestigen en de keuzevrijheid toch weer be­perken. Daarom moet het beheer van het afsprakenstelsel zorgvuldig en voldoende open worden vormgege­ven.


Mobile PKI and mobile centric identity

2010/01/08

Together with my colleague Martijn Oostdijk (see also his post) we did a project on Mobile PKI technology. We did a technology assessment, focusing on security and also usability, and consulted our client SURFNet on its application for higher education and research.

It proved to be a very interesting project, not only because of the interesting and promising technology, but also because we are advocating what we call mobile centric identity, and Mobile PKI is a good example of “use your mobile phone as an authentication device”. We concluded that Mobile PKI is both a secure and usable technology, and that the main issue is the business model (since the SIM is owned by the mobile operator).

The report that came out of the project is publicly available: in Dutch and in English. Among others, SURFnet employees Roland Rijswijk and Joost van Dijk also provided input and feedback on this report. Below I’ve copied the management summary.

A GSM/UMTS telephone has a SIM card. This is a standardised smartcard that is issued to the user by the telecom operator and is primarily used to authenticate the user on the mobile network. However, the SIM card has more potential uses. For instance, it allows for secure storage of digital keys that can be used for online authentication and digital signatures. This is referred to as Wireless PKI and Mobile PKI.
This report is an assessment of Mobile PKI technology and its potential application for authentication in education. This assessment focuses on its security and its application within the educational domain, with a specific emphasis on applications for SURFfederatie.
Mobile PKI employs encrypted SMS text messages that are used to represent authentication or a digital signature. The user has to express consent by entering a PIN code that secures the private key and which typically needs to be entered for each transaction separately. The relevant standards for this are well established and are supported on all mobile phones. This has advantages compared to other secure means of authentication. For instance, no additional authentication device is required, which also means that no software needs to be installed by the user on either the phone or on other client devices such as a PC. Neither is there a need to manually enter codes, as in the case of one-time passwords via SMS text messages. This improves user-friendliness. Malware such as viruses and key loggers that may have been installed on a PC cannot interfere with Mobile PKI.
This report considers the issue whether Mobile PKI is a secure means of authentication. The analysis identifies a “man in the middle” channel. However, the authors of this report deem Mobile PKI to be more than sufficiently secure compared to other means of authentication and considering the kind of applications in (higher) education.
In our view the most important issues regarding Mobile PKI technology are not related to security or technology but have to do with the costs and the business model. In the Netherlands, Mobile PKI technology has only been deployed for limited pilots and it is therefore difficult to estimate the costs. These could turn out to be too high for many applications in the educational domain if there are no other large-scale deployments of Mobile PKI. A related aspect is the business model. Use of this technology requires the cooperation of the mobile operator, who is the owner of the SIM card. This means that the cooperation of all mobile operators is required for a large-scale deployment.
The final conclusion of this report is that Mobile PKI provides a secure means of authentication that in time will find wide application within the educational domain in the Netherlands. For the near future Mobile PKI will only be employed for services that require a high standard of security and that are used by a limited group of employees due to a) the expected costs, b) insufficient insight into the business model, and c) limited support from the mobile operators. It seems too early for a deployment for students or for general authentication for SURFfederatie or any other large-scale application for SURFnet, Kennisnet or other service. In the meantime it may be useful to consider one-time passwords via SMS text messages as step-up authentication or for password reset because this is cheaper and prepares users for Mobile PKI.


Levels of assurance, per attribute

2010/01/06

I’ve been working with a group of Dutch identity enthusiasts on a Dutch trust framework for OpenID (OpenID.nl+), for low-trust consumer identity (e.g., for web shops). Contrary to relying on self-asserted attributes, as is usually the case for OpenID, we want Identity Providers (IdPs) to provide verified attributes. This is similar to the levels of assurance concept as standardized by NIST (see also a previous post of mine on this), and used by e.g. the EU STORK project. However, level of assurance refers to the identity as a whole, not on specific attributes, and we believe that there is value in providing a level of assurance per attribute. For example, for IdPs may be able to provide bankaccount numbers that are thoroughly verified, but not verified birthdays, and they should be able to specify this per attribute. An IdP could provide a mix of verified and self-asserted attributes.

Doing this in OpenID (AX actually) is a bit beyond the current spec, but not so difficult (see also this draft from Google/Yahoo). What is more difficult is the semantics of what “verified” means for a specific attribute. We are considering simply defining one of more verification processes per attribute. An example of a process for a verified bank account attribute is: the bank account was verified by requiring the user to transfer some money to the IdP. By lack of a standard that describes these verification processes, we’re inventing them ourselves using common sense combined with existing practises at the involved IdPs. This is work in progress, so I cannot give any firm statements yet on how well this will work, and if this will also scale. I’m happy if it will work for a small set of frequently asked attributed, and for most verification processes. Alternative approaches include

  1. Defining numeric levels per attribute, comparable to the 1 to 4 of the NIST levels of assurance with higher meaning better, and mapping the verification process used by an IdP to one of these levels.
  2. Defining it simply as “verified” (boolean), but defining the minimum amount of verification an IdP should have done for that specific attribute. This can be considered the same as alternative 1, but only with 2 levels (verified or not verified).
  3. Defining it simply as “verified” (boolean), without semantics, and thus leaving it up to the RP to check with the IdP what this means for that specific attribute from that specific IdP. We can of course provide a URL to an explanation from the IdP on how the attribute was verified.

A recent blog post of Eve Maler describes her ideas on levels of assurance. She makes a good case that the 4 levels from NIST are not suitable for use cases were a website want to recognize a returning user, without needing to know who that user is exactly (persistent pseudonym). Or put differently: have a good authentication, but no identity binding process. She also pointed to this interesting diagram from an Internet 2 Tao of attributes workshop that I would have loved to attend.


Tuesday Update event on (consumer) identity

2009/12/04

My employer organizes networking events called Tuesday Update by Novay. The theme this time was identity, and more specifically consumer identity (consumer2business). We had an audience that was a very good mix of business people (financial industry, some media, some operators), government, ‘identity industry’ and people who more generally are involved with innovation. It was an interesting and lively event!

We invited Frank Leyman from FEDICT to give a talk on the Belgian eID, and it’s usage for consumer identity. FEDICT is the Belgian government organization responsible for the eID card. The Belgian government eID can, contrary to the Netherlands, be used by private businesses, and they appear to be ahead of the Netherlands in this area (e.g., an actual eID card …). This made it a very interesting case, and Frank explained the different functionalities very well. See here for his slides.

We also invited Yme Bosma from Hyves to present the Hyves view on identity. Hyves is the by-far-largest Dutch social network, and Hyves is, as its US/international counterparts, becoming an Identity Provider for low-trust identity. Think OpenID, oAuth etc. Hyves is, with some limitations, also a relying party. What’s especially interesting to me is that Yme is quite straightforward on their business case (my wording): we provide more value to our users, and it’s easy to do, so we do it. See http://docs.google.com/a/yme.nl/present/view?id=dg22g52h_10c29qhvdj for his slides.

I also gave a presentation, discussing among other business models, market entry en privacy aspects. And I advocated user centric identity, and our personal buzzword: mobile centric identity. I also briefly discussed our high-trust consumer identity for the Netherlands project proposal, and the OpenID.nl+ initiative (by ECP-EPN) which I’m becoming more involved in (as project manager for the proof-of-concept). See http://www.slideshare.net/wegdam/consumer-identity-tuesday-update-on-1-december-2009 for my slides (the first few slides have some Dutch, but don’t worry, you can easily skip those).


Presentations on Id Fed, user centric and mobile centric identity

2009/10/22

I gave two presentation recently that I’ll share in this post. They were for quite different audiences, and in different countries, but both in the area of identity federation, user centric identity and mobile centric identity.

The first presentation was at the Dutch Identity 2009 event, which was co-located with ISSE 2009 this year. This took place in Schevingen (The Hague), on 6-7 October 2009.  I presented my views on trend in identity federation, and user centric identity. Among others, I argued that SAML is just as user centric than OpenID, or at least, can and should be…

Highlights on Identity/ISSE 2009 for me were the presentations by Don Schmidt (Microsoft), who talked about claim-based identity, and a presentation on the Norwegian BankID, which discussed the status of the Norwegian collaboration between banks to provide identity services to public and private sector.

The second presentation was at the National eID & ePassport conference, which is taking place as I type this (22-23 October 2009), in Lisbon. It was organized by among others Multicert, who invited me to talk about and discuss mobile centric identity. It was an audience not very familiar with user centric identity, so I first introduced this. I then argued that this implies mobile centric identity, and that using the mobile phone is only the first step towards mobile centric identity.


Mobile User Centric Identity through Information Cards

2009/10/16

infocard-mobile-mockupThere are three things I believe will continue to gain importance in the coming years: identity federation, user centric identity and mobile applications. I can combine them in what we refer to as mobile centric identity. When considering mobile centric identity, we do not only refer to an identity solution that works for mobile applications, but also consider the mobile phone to be a good (or best) way to control your identity when using ‘old fashioned’ PC-like applications (including web browsers). I’ll focus in this post on a specific way to implement mobile centric identity: using InfoCards on a mobile phone. I’ll leave the more general mobile centric identity subject, including how to use mobile phones for authentication (Mobile PKI etc), for another time.

With all its promise, InfoCard has so far been mostly a desktop-only way to implement user centric identity. I looked around for a student to work with me on the subject of making InfoCards mobile, and found Florian van Keulen. He also found the subject interesting, and did his BSc Telematics graduation assignment with me (and Marten van Sinderen). He dived into the status of the different implementations, and analyzed what the issues are to make InfoCard mobile. The good news is that we did not find any reason why InfoCard could not become mobile, and that there are even some first implementations coming. The main issue when porting the InfoCard identity selector appears to be that then needed libraries are not there, making it a lot of work. Making InfoCard mobile is however more than porting the identity selector, the more challenging part is how to (securely) roam once’s identities between the different fixed and mobile devices. This means that a user can use the same identities on his or her mobile phone, as on other (fixed or mobile) devices the user may be using. Of course without having to manually import/export InfoCards… The main contribution of Florian’s work is comparing the different architectures to do this. One way to do this is to store the cards ‘in the cloud’, as Azigo seems to be doing (but they do not have a mobile identity selector as far as I’m aware). The architecture we decided to detail is however a different one: we put the InfoCards and the identity selector in the mobile phone’s SIM card, and connect this via BlueTooth to a fixed PC. It’s more complicated to implement, but we believe it is also more secure. I’ve put Florian’s thesis online so you can read it for yourself: http://www.novay.nl/okb/publicaties/mobile-user-centric-identity-through-information-cards/7248  (titled: “Mobile User Centric Identity through Information Cards, Architectures to use same identities on mobile phones and computers”). Unfortunately, implementing it was too much work for a BSc assignment, but I may find another student or some project to continue working on making InfoCards mobile.


No need for Level of Assurance level 1 and thus OpenID for e-government?

2009/10/01

In both EU and US there is a lot happening on how citizens identify themselves for e-government services, especially the STORK project in the EU, and the ICAM work in the states. Their approaches to e-government identity are drastically different, but I’ll focus in this post with what they share: levels of assurance. Basically level of assurance refers to how certain an identity provider is w.r.t. the identity of the user, which depends on both the used authentication means and the identity binding process (see, e.g., here for an informal explanation) . Both sides of the ocean use (more or less) the same four levels that originate from NIST:

  1. Level 1: Little or no confidence in the asserted identity’s validity.
  2. Level 2: Some confidence in the asserted identity’s validity.
  3. Level 3: High confidence in the asserted identity’s validity.
  4. Level 4: Very high confidence in the asserted identity’s validity.

Looking at the US profiles for OpenID and InfoCard, what got my attention right away is that OpenID is only permitted for level 1 (i.e., no confidence), and that InfoCard is permitted for levels 1 to 3 (I couldn’t find the levels for SAML). This seems to me a good decision, OpenID is much less secure than InfoCard, and (in it’s current version) should IMHO only be used for low security e-services. I had a brief discussion with my colleague Bob Hulsebosch, who was the main author of STORK D2.3 deliverable (Quality Authenticator Scheme) that describes the mapping of the different national authentication levels to the STORK (NIST based) levels. My conclusion from this discussion is that I’m not convinced of the need for an assurance level 1 solution for e-government, and, as a consequence, of the usefullness of OpenID for e-government. Most e-government services I expect are level 2 and up. This is also confirmed by the fact that many EU countries (including the Netherlands) do not have a level 1. Also the examples in the US document “E-Authentication guidance for federal agencies” for level 1 seem somewhat far fetched IMHO. And even if there are some significant e-government services for which level 1 would be ok, then still InfoCard would be much preferred because of it support for higher levels as well.

Of course, I only follow the US e-government identity discussion from a distance, and maybe there are excellent reasons for supporting a level-1-only scheme.  Anyone who has a pointer to an explanation for this, please send this to me. Also a motivation for the Levels of Assurance decisions for OpenID, InfoCard and SAML is very welcome.

What I didn’t cover explicitly in this post is the very interesting choice to support all three major identity (federation) standards OpenID, InfoCard and SAML. Most (all?) governments that I’m aware off  use only SAML.


paper on ePassports and InfoCard

2009/09/26
passport

passport

We’ve been working on ePassports for a while now, using the chips embedded in passports for online authentication. For a couple of years now passports have an embedded chip with information on the passport holder (social security number, name, birth date etc), standardized by the International Civil Aviation Organization. This chip is primarily used to facilitate automated inspection at border control, but can potentially be used for online authentication as well. Without going into technical details here, this means that a ePassport can be considered a state-of-the-art smartcard (contrary to apparantly Canadian driver licences)  that is issued via a trusted process, and which can be used to authenticate for e-government as well as for non-government services.

Our work basically had two dimensions:

  1. Figure out what the consequences of using ePassports for online authentication were – this boils down to the privacy sensitive information on the holder that is stored in the chip. Details vary per country, but since the ePassport was not designed with online usage in mind, you basically have to share all the data, which includes things like social security numbers. This is a major concern, which basically means you have to have a very-trusted-third-party to filter out attributes (minimal disclosure).
  2. How to use this in combination with Information Cards – We did an experiment where a InfoCard-based identity provider would use the ePassport to authenticate the user, as well as pass the government-certified attributes to relying parties. Of course: with user consent!  The good news is it works, the bad is that IMHO it’s a bit complicated to explain to the average user, especially to create the InfoCard.

Last week my colleague Dirk-Jan van Dijk (who did most of the development) presented a paper on the SecureComm conference on our ePassport & Infocard work. Since SecureComm has post-proceedings, I cannot link to the final version of the paper just yet, but just send me an email to get a final-except-maybe-layout-stuff version.

The lead for this work is with my colleague and ePassport guru Martijn Oostdijk. Martijn will give a presentation on our work on at RSA Conference Europe 2009 (next month). Martijn also made a nice overview of articles in the Dutch press on our work, including an English translation of an article in the business newspaper Financieel Dagblad. This work was partly sponsored by the NLnet Foundation, the software is open source.

UPDATE on 26 october 2009:  The paper can now be downloaded from http://dx.doi.org/10.1007/978-3-642-05284-2_17, or from my homepage at the University of Twente.