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.

3 Comments | Uncategorized | Tagged: , , , | Permalink
Posted by Maarten Wegdam

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.

Leave a Comment » | Uncategorized | Tagged: | Permalink
Posted by Maarten Wegdam

Follow

Get every new post delivered to your Inbox.