SMS text authentication for patient access to Dutch electronic health record

The encryption algorithm A5/1 used in GSM has been suspect since at least 1994 (when the algorithm leaked). Nohl's talk at 26C3 (November 2009) demonstrates that a practical attack will become possible soon. And all of a sudden people start to get nervous in 2010.

As a follow-up to their report for the Dutch Ministry of Health Radboud University and PriceWaterhouseCoopers recently published a risk assessment focusing on GSM based SMS text authentication as a factor to strengthen the Dutch government citizen-to-government authentication solution DigiD.

SMS text authentication is already used in DigiD level 2, but the binding of a user's subscriber number to their DigiD is rather weak: anyone with access to the mailbox of the user's registered home address (the so-called GBA address) can bind a new mobile phone to the user's existing DigiD account (and subsequently order a password reset, completely hijacking the account). The original report by RU, PWC and TILT recommended to strengthen this binding process so that a patient would have to prove possession of a subscriber number to a government representative face-to-face. The strengthened DigiD (known as EPD-DigiD) can then be used by patients to access their electronic health record in a standard SMS OTP authentication scenario (during a session the user has an extra factor with a separate network connection to the provider).

The conclusion of the RU/PWC risk analysis is that although breaking A5/1 leaves SMS authentication relatively secure (the risk of actual abuse is not that high) the perceived lack of security in the public opinion and the non-compliance with security standards may be damaging to the reputation to the government. The solution is not secure enough to allow patients to access their health records at this point in time.

What I don't get is the proposed solution: a conversion table (on paper) sent to each user over regular snail mail (how secure is that?). The user uses this table to manually translate the code that was sent in an SMS message before entering it in the browser's form. This appears not to add an extra factor: an attacker that can eavesdrop on the Web channel and the GSM channel will soon learn the mapping. Also from a user experience perspective that sounds horrible.

An alternative approach would be to install a SIM toolkit applet on the SIM which performs the translation automatically for the user. Rather than a static table per user one can even use a key (but with a decent cipher; I'm sure the current generation of SIMs in the field support AES or at least 3DES) and have real security. Sort of a light-weight-Mobile-PKI-without-the-PKI solution.

NFC phones

It's 2010. The NFC revolution should have happened by now.

I know this is a classical bootstrap problem: why offer services if consumers don't own NFC handsets, why produce NFC handsets if nobody offers services?

And then there are problems with the business model, there are cultural differences between banks and mobile operators, etc. There was a problem of the location of the secure element (SE): either embedded in the device (owned by the manufacturer), or on the SIM (owned by the operator). I think the mobile operators won.

Oh, and there have been countless trials and pilots.

So where are the new handsets? Below is my list of annotated bookmarks.

• Nokia has an NFC shell (2005) that can be strapped onto the Nokia 3220.
• Samsung has its SGH-X700N (2006).
  
• Nokia's clamshell model, the Nokia 6131-NFC (2007), and bar model, Nokia 6212 classic (2008) are pretty popular. These S40 devices have a dedicated SE embedded into the handset.
• There's a nice list of handsets over at NFC Research in Hagenberg, including models by Sagem, LG, and Motorola (2008?).
• LG seems to have had an LG KU380-NFC handset with NFC support based on an STMicroeletronics chip.
  
• Nokia announced the Nokia 6216 classic (2009) which was supposed to support an SE on the SIM (via SWP). But this model has been killed now.
• Mobile-ecosystem found that Samsung and LG have new NFC enabled smart phones (2010).
• Samsung developed an NFC version of its S5230 smart phone for use in trials.
  
• And let's hope the rumors about Apple's iPhone4G are true.

(I should have checked Wikipedia before I compiled that list, theirs is a superset of mine. Never mind.)

But maybe a different strategy is needed while we wait for the handset revolution: strap something onto an ordinary smart phone to NFC-enable it.

• A sticker with a dumb RFID tag. Only tag emulation, so no smart poster support. But it should be enough for the most popular use case (proximity payment without asking for user consent).
• A sticker with a smart tag which communicates with the handset over Bluetooth.
• A MicroSD card such as the one by Giesecke & Devrient and the one by First Data and Tyfone.

Community generated trust

I like CAcert.org. The basic premise of this CA is that trust is a community effort: the "by the people, for the people" kind of stuff. A social network for security geeks. Trust in derived identities (not identities of persons but identity of domain names or of Web servers) can then in principle be based on community generated trust so that steep yearly prices for server certificates can be avoided. We all benefit (except if you run a commercial CA, of course).

I created my CAcert account ages ago, but only recently undertook some action to get my identity assured by the community. Here's how it works:

• You create an account with the service and register one or more email addresses.
• The service checks possession of each email address by sending a challenge link to click.
• You can also register domain names (where you typically host Web servers) with the service, possession of the domain is checked in a similar way.
• As a user you now have 0 points
  • You can have the service issue email certificates for your email addresses (for sending encrypted or signed emails, or for client side TLS authentication).
    
  • You can have the service issue Web server certificates for your domains (for server side TLS authentication, i.e. HTTPS).
    
  • Issued certificates (based on a CSR that you generate) are valid for 6 months and contain only basic information (not your full name, for instance).
• Once you have over 50 points, newly issued certificates will be valid for 2 years and can contain your full name.
• Once you have over 100 points, you can also have the service issue code signing certificates and you become a so-called assurer (after you take the official online exam).
  
• Certificates are signed by the service's root private key and can be checked using the service's root certificate (at the time of writing that certificate is valid until 2033). Currently viewers of your TLS secured Web site will have to manually insert the root certificate into their browser's trust store. The ambition of CAcert is to have the service's root certificate included in Mozilla's trust store distributed with Firefox.

How do you get more points? You will need to find an assurer (another user with over 100 points) and meet with him or her face-to-face. The assurer will check you passport (or driver's license or similar photo ID) according to certain guidelines and fill out a paper form which you need to sign. Depending on the experience of the assurer, he or she can give you 10 to 35 points maximum. The form is kept by the assurer for seven years and then destroyed. The service's Web site has a database that can be queried to find assurers near your location. I used this mechanism over the last couple of weeks to find some friendly people in Twente willing to check my identity (thanks Peter, Ashwin, Tom, Alex & Stephan).

So how trustworthy is all of this, really? The foundation behind the CAcert is a non-profit organization being supported by other non-profits. They seem serious about their infrastructure's security. The server side software is open source, and although it is written in PHP and Perl, it can be inspected by security researchers. For cryptography the implementation relies on OpenSSL. There's a whole community effort to train assurers in recognizing authentic government issued IDs. That all sounds pretty trustworthy (except maybe for the use of OpenSSL, which is written by monkeys ;) ).

Let's say I want a fake identity assured (i.e., a freshly generated free-mail account with a fake name and date of birth with 100 points). How difficult is that? I'll assume that until now all other users have been honest and have been perfectly assured based on government issued IDs. I'll need to find n evil assurers (at most ten). Those evil assurers should be willing to falsely assure my fake identity. Do those n assurers need to be n different people? Maybe not: creating ten different accounts under my real name is possible (the service should be available to users which happen to have the same name and date of birth as an existing user). I could get those ten accounts assured by at most (n * (n + 1)) / 2 honest assurers so that each account gets 100 points. I then use those ten accounts to give my fake account 100 points. Better yet, I create ten fake accounts this way and give each of those 100 points so that I no longer need my ten original accounts (which are all in my real name, better delete those now).

How to remedy this? There seems to be an audit program in place, where assurers are asked to contact other assurers to sanity-check past assurances. Eventually my fraudulent accounts will be discovered and traced back to my real identity (the ten accounts in my real name that were assured by honest assurers). I could then be held to the community agreement which I agreed to when I signed up for the service. The combination of government issued ID, face-to-face meetings, community vigilance, and legal agreements actually forms a pretty good deterrent security control against the described attack. In the end what CAcert is doing is not so different from what the commercial CAs are doing.

Update 2010/02/17: Looks like this same meme was recently discussed on the CAcert mailing list.