October 19, 2002

Certificates, smartcards, tokens ... oh my!


Note: I started writing this piece last week, only to find out that most of my points are being (or had been) discussed by others. In the end, I decided that having several unfinished essays on the desktop is way too depressing and I finished it anyway.

Last week the Register published an article outlining woes with certificates in UK e-government initiatives, based on the chat John Lettice had with Alan Mather.  The headline, "Cert-based authentication 'on life support" says pretty much everything. At the end, the article suggests "to simply use the weight of government to make certificates work." This advise is well meant (surprising by the publication's standard levels of irony) but misleading.

To put this in a context, some time ago I had to investigate feasibility of using certificates for a relatively large e-business system and besides finding that it would add extra 10% to total acquisition costs, I came to following points:


  • Certificates do "nothing" from the user's perspective. Users want new fancy applications that make their life easier.
  • There is a lack of certificate aware server software (web servers support user certs OK, but there is a need to extract user attributes for further authorisation and this feature is not a available in all major technology stacks
  • User registration is awkward and and certificates are difficult to install
  • Certificates are (almost) not portable.
  • Majority of home computers are insecure.
  • Smart-cards that could to some extent fix insecurity of Win9x systems and lack of portability are expensive (because of card readers) and clumsy to deploy (on large scale).

Everything boils down to numbers of users and costs. Despite low per-unit price, the overall costs are bound to be high because of network effects involved. 

I think there's no way to resolve the issues with certificates solely using software. This leaves us with the need to use some form of hardware tokens.

When considering large user populations, (smart) cards that require extra piece of hardware at the user end are no-go. In e-government context they would probably require government to subsidise all new PCs to be equipped with the reader and you would need to forget about old computers, digital TV, mobile phones and whatnot. Judge for yourself how likely this will happen...

Tokens that don't require support at desktop (ie USB or two factor authentication) still have downsides; they don't come cheap. Not because of unit price, but  because of large user populations. Yes, each user could pay for his equipment in theory, but when considering that the certificate does "nothing" for the user how likely is this to happen?

There's also a number of other practicalities such as limited lifetime, users losing tokens and token loss not talking about the fact that tokens, as any other security hardware, are a proprietary products and you are likely going to become locked-in to a particular vendor. All this makes the whole proposition much less attractive.

I think that everything boils down to the point that e-government (and e-commerce) is meant to make life simpler. Cards, tokens and other hardware devices that are not part of everyday life already just don't fit this criteria no matter how hard you try.

Having said that, what options for strong authentication in B2C context remain?


  1. Believe that ID smartcards will become acceptable political reality and that government will get the bucketloads of money to set up the distribution infrastructure neccessary
  2. Wait until all credit cards become "smart" and get an agreement with banks (forgetting about the fact that multi-function smartcards are not completely risk-free)
  3. Use passwords and accept risk
  4. Don't provide the sensitive services online
  5. Use smartcards/tokens where it does make sense - for smaller, closed communities of users.

Posted by Jiri at October 19, 2002 06:56 PM