As you may know, I’ve recently set up the Privacy and Public Policy Work Group (P3WG) for the Kantara Initiative, and as we start mapping out the areas in which the Group wants to exercise an influence, one topic has generated more discussion than anything else on the mailing list. It goes by the rather uninformative name of “LOA”, or Level of Assurance. Even if you’ve never heard of LOAs, they have played a major part in your life online and off.

I’ve blogged before about what I call the “Chain of Trust” – namely, the sequence of events all of which need to be working if a credential is to work properly when you present it. In other words, for instance, if you apply for a passport in the name of Michael Mouse and the passport office doesn’t bother to check whether there’s any evidence that that is your name, the resulting passport won’t be that reliable as an indicator of your identity (even though people may assume that it is). Similarly, driving licences would not be much use as an indicator of which vehicles you’re entiteld to drive, if it was possible for you to alter what the licence says… and if you tell someone the PIN of your ATM card, it is no longer effective as a way to ensure that only you can take money out of your account (in fact, the bank is likely to take it as de facto evidence that you must have been responsible for the transaction, even if it wasn’t you who actually used the card and PIN…).

These are just three examples of the many ways in which the Chain of Trust can fail, at the Registration/Verification phase, over the life of the credential, and at the authentication step, respectively. There are many other points at which the Chain can be compromised and the reliability of the credential (or the assertions made using it) undermined.

LOA is about protecting the first of these – the point at which someone decides whether or not to issue a credential which represents you in some way. In other words, if you can present a relying party with not just a credential, but a ‘score’ which indicates how reliably that credential was issued to you, can judge whether it’s more likely that you are actually Michael Mouse, or that whoever gave you a passport saying so was not doing their job very well.

That, in turn, will give them useful information about what decisions to make next, particularly if they decide that the answer to your authentication question is “yes”.

The UK and US governments both have relatively simple 4-level LOA models (though, inconveniently, one runs from 0-3 and the other from 1-4…). Omitting the ‘index value’ for a moment, the four levels look remarkably similar. In fact, if I adopt a slightly different scale, just to paper over that difference, we might get something like this:

Rare

UK: no authentication of identity

US: little or no confidence in the asserted identity

Medium rare

UK: basic authentication

US: some confidence in the asserted identity

Medium

UK: greater level of assurance (e.g. credentials based on proof of identity to a third party)

US: high confidence in the asserted identity

Well done

UK: identification beyond reasonable doubt

US: very high confidence in the asserted identity

So far so good. However, when it comes to putting this simple model into practice, and because we’re talking about assurance here (and therefore judgement), a couple of different approaches emerge.

One is to give a technical specification of the kinds of authentication technology which should or must correspond to an implementation claiming to be at a given LOA level.

Another is to relate the LOA levels to levels of risk, and allow the implementer to work out how they think that risk is best mitigated.

You might think that a third, better solution would be to combine the two… define organisational risks in a way which allows them to be assessed against the four-level model, and then have a technical specification list which says: “if you face this level of risk and you want this level of assurance, you need technology such as ‘x’, implemented with the following governance measures.

Actually, I have a better idea… if you have opinions on this question (better still, if you have a good answer), come and sign up to the Kantara P3WG and join the discussion. We’d love to hear from you.

Thanks to @cheshire_puss for the pointer to this ZDNet article about Home Office plans to “engage with the industry to show that we have a ‘gold standard’ card which cannot be changed, modified or cloned”.

On one level, I’m delighted to have an opportunity, at last, to use the word “epistemological” in a blog post (who wouldn’t be…?). Because, on the face of it, the Home Office plans look like a doomed attempt at that epistemological impossibility, the proof of a negative proposition. Industry experts could help the Home Office show an ID card being cracked, could show that it’s possible but difficult, or could show a card successfully resisting a finite number of attempts to crack it… but they can’t demonstrate that the card cannot (ever) be changed, modified or cloned.

On another level, I’m puzzled as to what’s in it for a couple of the stakeholders, should these experiments go ahead. It seems to me that the industry experts are being invited to endorse the security of something which they will then neither implement nor rely on. In other words, the success or failure of the ID Cards they have certified as “gold standard” will depend on factors entirely outside their control.

If they are to bear no liability for this (and let’s face it, why should they), then what is gained by having them ‘initial’ the tests? If they are to be expected to bear some liability for the eventual outcomes of ID Card issue and use, I look forward to seeing what kind of industry experts step forward. Brave fellows, all.

And what’s in it for the citizen-stakeholder? Assuming that the tests fail to prove the negative proposition, will citizens trust the technology more, or will they simply question whatever liability model on which the cards are rolled out?

Lastly, I’m also bemused by the Home Office’s reported explanation of why it doesn’t want to see whether or not Adam Laurie’s claimed attack is genuine: they do not wish to be “overwhelmed by individuals wishing to demonstrate ID card cracks.” Do they think the cards are so insecure that every Trent, Bob and Alice is queuing up to have a go? Or that there are enough nutters out there to mount some kind of Denial of Service attack with a series of trivial attempts? (“Hullo children – and today on Blue Peter, we’ll be showing you how to make your own Home Office ID Card reader, using just this egg carton, some sticky-backed plastic and a roll of tinfoil”).

Seriously, though – why do the Home Office say they are looking for a suitable way to engage with industry to demonstrate that ID cards are secure? I thought CESG had a whole programme to do just that, and that the “E” in CLEF stood for “Evaluation”…

But perhaps I’m very old-fashioned.

The Kantara Initiative yesterday announced the formation of the Identity Assurance Review Board (ARB).  This is a tangible example of the Kantara Initiative delivering on the non-technology related, identity meta-issues that I alluded to in my last Kantara Initiative blog.  

I think in a few years we will look back to this and see it as a key step toward making the Internet a more useful and safe place for conducting commerce.  And when I say commerce I don’t mean just buying and selling stuff on the Internet. I mean using the Internet to provide the underlying wiring for cross-organizational ecosystems – supply chains, distribution partnerships, outsourcing – all needing to operate in real-time and without organizational boundaries getting in the way. 

That is a place where I believe tremendous economic value is currently trapped – between organizations.  I believe this inter-organizational friction holds back billions of dollars in potential value.  Organizations certainly do interoperate today using the Internet as the communication network, but it is currently way too hard, expensive, and slow to make this happen for large value release.  The force of friction won’t let this ball really start rolling.

Why is this type of commerce hard?  In part it is due to the existence of non-standard technologies and APIs on both sides which are tricky to integrate.  But this issue is fading with standards and APIs which often leverage XML.  So in many ways the technology hurdles for interoperation on the Internet have been addressed. 

What hasn’t been sufficiently addressed is trust and the establishment of trust.  If you are with an organization that would like to interoperate in real-time with your 100 distribution partners, a key problem is how you establish and enforce trust across this particular ecosystem?  And it needs set it up in days, not years. 

Today we don’t even have a common way of communicating certain facts which can lead to the establishment of trust, let alone the fast establishment of trust itself.  If we solve this in a widely deployable way, the tremendous economic value I mentioned can be released.  More grease will be applied to this friction problem through the establishment of the ARB.

Check out Matthew’s blog at  http://tinyurl.com/ner8cf

Organizations take leadership role in driving trusted identity-enabled enterprise, SaaS and Cloud applications based on certified identity services

August 18, 2009 – Kantara Initiative, a global identity community working to solve harmonization and interoperability challenges among identity-enabled enterprise, Web 2.0 and Cloud applications and services, today announced that representatives from Aetna, BT, SUNET/NORDUNet and the US GSA have taken leadership positions on the Kantara Initiative Assurance Review Board (ARB). The ARB oversees the Grant of Rights for use of the Kantara Initiative Assurance Mark, a mark of quality demonstrating that organizations have met stringent identity management criteria outlined in the protocol independent Identity Assurance Framework (IAF).

Marks will initially be awarded in two categories, one to industry assessors indicating they meet requirements to assess identity services for compliance to the IAF, and one to identity services that have been certified by these assessors against the four identity assurance levels detailed in the IAF. Services earning the Kantara Initiative Assurance Mark have successfully satisfied the organizational management, identity proofing, and credential management criteria associated with each identity assurance level. 

“With today’s news, Kantara Initiative is moving to reduce the business, governance and liability challenges organizations face when adding new partners and customers to their ‘trusted Cloud’ of external services,” said Mark Coderre, head of security architecture for Aetna. “Robust Kantara Initiative certification of identity services across a range of risk assessment criteria allows businesses to quickly establish trust with external parties, and to grow the value of these trusted relationships dynamically.”

Certified identity services eliminate the need for organizations to “reinvent the wheel” each time they need to assess the risk of accepting identity credentials from an outside party, making it easier and faster to deploy new services.

About the ARB

The ARB works with the Kantara Initiative Board of Trustees overseeing the Kantara Initiative Identity Assurance Certification Program, developed by Liberty Alliance and now moving forward within Kantara Initiative. The open membership structure of Kantara Initiative is bringing the right mix of identity assurance stakeholders together to advance certified identity services collaboratively. The first Kantara Initiative Identity Assurance Certification cycle is currently underway. The ARB will award Kantara Initiative Assurance Marks based on the results of this event. More information is available here http://tinyurl.com/r6le4r

http://informationanswers.com/?p=386

I’ve been doing some thinking in advance of getting stuck into the development of open standards for User Driven and Volunteered Personal Information. That work is being done here if you are interested in joining in. I’ve been thinking mainly about how best to explain what happens to buying processes and sales processes when volunteered personal information is added to the mix (underpinned by the personal data store/ My Data as set out here).

Here’s my stab at that explanation. I need firstly to set out a view of how things currently work – that’s in the first diagram below with individuals/ high level buying processes on the left, and organisations/ high level selling processes on the right. In short, at present, buyers and sellers largely do their own thing/ practice non-automated selective disclosure prior to engaging in an actual customer/ supplier relationship. That is structurally the best option for a buyer, certainly in terms of reducing complexity and protecting negotiating positions for more expensive/ complex purchases – but it does lead to a lot of guesswork; the buyer typically evaluates multiple options before deciding on one – that’s part of the guesswork referred to in the diagram below. This ‘one step removed’ approach is not the best option for the seller – which is why they try a wide range to tricks to have the potential customer engage with them. That would appear a sensible practice, but in reality it tends to fill up the ’sales funnel’ with many potential customers who actually have no right nor reason being there – and why direct marketing conversions from prospect campaigns are often well below 1%. That’s the the other part of the guesswork in the diagram. At the relevant point in the process, the customer chooses one of the supply options and decides to commence the customer-supplier relationship; the other suppliers fall by the way side/ wonder what’s happened. But those who lost out, because they don’t have the information to do otherwise, keep on turning the marketing handle – lot’s of waste comes from that area.

Moving through the process, commencing the supply relationship in the current mode means interacting on a supplier run platform, and signing up to supplier generated terms and conditions (or going elsewhere to another supplier silo/ get the same result). What that then does is put the organisation unilaterally in charge of processes and process improvement around relationship management. As a historical note, in my view this is where CRM ‘went wrong’ in the widest sense – at least in part because many deployments occurred during the economic downturn in the early 2000’s. It moved from a having been brought in as a platform for driving improvements in the customer experience, to being run as a platform for cost cutting and for risk managment; e.g. the drive to automated processes such as web based customer self-service, offshoring contact centres. Sometimes this automation worked for customers (e.g. online banking), in many cases all it did was move the waste/ inefficiency onto to the customer. Of course what then happened was that customers took their business elsewhere, where they had that choice/ a better option, or stayed but with reduced levels of satisfaction – crazy in that customer retention and satisfaction improvements were almost certainly key drivers for the original CRM business case.

So, the current process does not work that well; the sales process cannot be optimised much further within the current tool-set . But options for improving upon this are now emerging – and not through pedalling faster within the organisation/ the selling process; it comes from building capability on the buyer side/ enhancing the buying process. (note the clear parallel with how selling professionalised in the B2B world when professional procurement and its processes emerged, and also that in the B2B world deals are often concluded and managed on the customer side systems).

The first thing to note in the updated diagram below is what the individual brings to the party (via their personal data store/ user driven and volunteered personal information. They bring the context for all subsequent components of the buying process (and high grade fuel for the selling process if it can be trained to listen rather than shout). By ‘context’, I mean the combination of a wide range attributes that describe the individual and their specific buying situation. This would typically include their needs, their current understanding of how their needs relate to products/ services, their location, their existing supply relationships, their preferences (brand, colour), their role in the decision-making process, their timescales, how much they wish to/ are able to spend, when they wish to buy. In other words, the individual’s context bundle is what much of the early part of the sales process is actually trying to figure out – but can’t get access to as the individual has no current incentive to release it in full. The best an organisation can do at present is strategic segmentation of their market (differentiating products or services based on aggregated customer requirements), and tactical segmentation of their messaging content, communications channels, sales outlets or pricing. Then it’s over into guesswork mode – can we put our messages out in the right places to attract our potential customers and suck them into our sales process…..

The other adds to this second diagram are the ten numbered boxes, reflecting that the improvements we make to the buying process through user driven and volunteered personal information will impact differently at different points of the buying/ selling process. These ten areas are substantive enough to each require a post of their own, so for now i’ll list them out at the high level below the diagram and come back to them in more detail as the standards work unfolds.

User Driven and Volunteered Personal Information Enabled Improvements

1. Search/ Target (sometimes referred to as the Personal RFI, i.e. Request for Information) – through the individual bringing much richer context data to the table, suppliers prepared to engage with these new buying support tools will find that their targeting becomes much more precise, better enabling them to find potential customers whose needs closely match the unique selling propositions in the organisations product/ service offering. In turn, individuals will find that the options made available to them have been pre-qualified to fit their context (to whatever level of detail they have shared). Note – at this stage my assumption is that individuals will be engaging anonymously/ pseudonymously as there should be no need to share personal data in this part of the process. It is likely that new inter/ infomediaries will emerge in this space, acting as the individuals buying agent (4th party/ user driven services).
2. Find (engage)/ Enquiry Management (sometimes referred to as the Personal RFP, i.e. Request for Proposals)  – through having brought richer data to the table in the preceding phase the individual will now be talking to pre-qualified suppliers (and vice versa), with the qualifying data from both parties available for use in the interaction. Typically this interaction will be about having a more refined/ detailed discussion about a need/ requirement/ solution axis – potentially involving either or both parties asking for more detail, including possibly verification of data asserted in the search/ target phase. It is likely that new inter/ infomediaries will also emerge in this space, quite possibly spanning the Search and Find requirement for individuals and done from the perspective of enabling the individual to buy solutions to their needs rather than the components which they subsequently stitch together themselves.
3. Negotiate – In this stage the individual is talking to one preferred solution option and getting down to the actual proposed ‘deal’ and the terms and conditions around that – provided by either party. Improvements in this area are likely around improved transparency of terms and conditions, initiated by the individual being much clearer about their requirements, and having access to comparison tools earlier in the process. ‘Reputation’ management tools will also come into operation as the individual shares what they find out about suppliers.
4. Transact – I would expect payment intermediaries/ financial services providers to find creative ways to engage with/ be driven by VPI enabled services; there is certainly much potential for reduction in credit card fraud and card related identity theft from using the much higher levels of identity assurance that will become the norm in a VPI enabled data-set.
5. Welcome – This ‘relationship set up’ phase is typically about both parties getting to know each other, i.e. getting products/ services bought set up and configured, ensuring any ongoing account management/ billing is up and running smoothly. In the VPI enabled world this phase won’t change too much in the short term as it will still run mainly on supplier systems – but in the mid and long term i’d expect it to shift to a genuine user-centric architecture which will see the individual ‘welcome’ the new supplying organisation to their personal supply network/ federation.
6. Relationship Servicing – This is what would typically be called customer service, i.e. fixing basic operational/ service delivery problems and dealing with ad hoc issues that come up such as change of address/ change of contact details/ change of payment details. As VPI enabled tools increasingly emerge, i’d expect this whole ‘change of’ to migrate to the ‘my suppliers follow me’ approach rather than the individual have to run around updating silos as per the current model.
7. Relationship Development – This typically includes the ‘cross-sell/ up-sell’ much beloved in the CRM business case. This stage will change in the VPI enabled world, much for the better. Customer service will be provided within the context of the individuals existing solution set rather than that little snapshot of it that the supplier currently sees/ is interested in. In turn that will mean that cross-sell and up-sell will be not only be much more informed, but it will also be much more welcome from the individuals perspective – because it is now laser sharp, and running within a more equitable customer/ supplier relationship (partnership).
8. Manage Problems – This stage is only reached if a significant problem emerges in the customer/ supplier relationship; typically this involves escalation beyond tier 1 customer service (and an increasingly frustrated/ angry/ upset customer). I don’t expect the VPI approach to have a high impact in this area, although improvements further up the process might have a knock on effect rendering this stage less painful if/ when it occurs.
9. Manage Exits – Exits can and will happen, either permanently or for a period of time. They may be caused by significant problems that emerged, or by a change in the customer need, or in their circumstances (their context has changed). Less frequently, a supplier will wish to leave a market or terminate a product/ service line and thus exit those relationships affected. In the VPI world, i’d expect there to be more information around impending exits and reasons for them – some of which will enable creative supplier responses. Along with relationship development, i’d expect improved customer retention to be one of the major wins for the supply side in the VPI world – but the plumbing and mechanics for that have stilled to be worked out.
10. Re-engagement – This stage might be known as ‘win-back’ in CRM speak, and involves the lost customer being targeted with appropriate offers to return. For the individual this return to the fold might be as a result in a time-driven change of context, or that the ‘grass was not greener on the other side’ – as is often the case in utility service swaps away from an incumbent that has retained quasi-monopoly advantages. In any case, the point being made here is that in the volunteered personal information scenario, the individual would be in position to retain and share the knowledge of the prior relationship – which many current CRM architectures fail to deliver on.

So there we have it. Time to get back to working on that VPI plumbing!!!

You know what? I’m actually starting to feel twinges of sympathy for the folks at Connectivity. There are two pieces in the Guardian devoted to the suspension of their mobile directory enquiries services, one from yesterday and one from today.

Now, I’m not trying to argue that basing the service on an “opt out” principle was a good idea – it wasn’t. But at least Connectivity set it up in such a way that you would first find out that someone had looked you up, then have the opportunity to decide whether or not to take the call, and then have the option of asking to be removed from the list. All this would happen without the requesting party being told your number. So in a way, there was at least a certain amount of privacy-friendliness built into the protocol. Whether that made it a good idea for Connectivity to be sitting on a database of numbers which might get shared with other service providers is another question entirely.

However, any slight twinges of sympathy at Connectivity’s plight are (and should be) rapidly displaced by a concern that all this high-profile coverage is distracting us from a more significant issue: namely, the means by which Connectivity were able to populate their directory in the first place. As I’ve suggested above, the way they set up their enquiry protocol show at least some concern for the data subject’s privacy. The same cannot be said for those data brokers who handed over their subscriber lists to Connectivity in the first place.

It’s just that, as they are not in a part of the food chain which is normally visible to the data subject, they don’t come under the same kind of scrutiny as the company which delivers a service direct to the consumer.

For all the focus on Connectivity, we should not pass up on this opportunity to shine the spotlight on the behaviour and regulation of the intermediaries who made Connectivity’s business model possible.

[Apologies - this should have been syndicated from the FutureIdentity blog in July]

Those of you with any interest in cricket will know that today is the first day of the 4th Test Match between Australia and England for the Ashes. With the series standing at 1-0 to England (2 matches having ended in a draw), the 4th Test (out of 5) could be the clincher. Not that I’m a cricket buff in any way – but it’s a good excuse to get a couple of those bewildering sports analogies into the blog post. (See bottom of post for approximate baseball translations…)

The Home Office appeared to have been bowled a bit of a googly [1] yesterday, when it was reported that Adam Laurie had not only hacked the access controls on an ID Card chip, but had successfully copied the data onto another chip, modified an existing field and added new data in another. However, this piece on the Kable site reports that the Home Office played a straight bat [2], denying outright that there was any evidence of a successful or viable attack.

According to the spokesperson:

“This story is rubbish. We are satisfied the personal data on the chip cannot be changed or modified and there is no evidence this has happened,” said a spokesperson.”The identity card includes a number of design and security features that are extremely difficult to replicate. Furthermore, the card readers we will deploy will undertake chip authentication checks that the card produced will not pass. We remain confident that the identity card is one of the most secure of its kind, fully meeting rigorous international standards.”

What’s not quite clear is whether the phrase “personal data on the chip” has again been carefully chosen to allow for the possibility that personal data, once off the chip, could be modified successfully.

As for the comments about authentication checks between the card, the chip and the reader: I remember studying a similar design exercise when I was working with the IBM 4753 device family in the early ’90s. The 4753 was a smart card reader with an encrypting PIN pad; it included the option to connect to a 4755 cryptographic adapter (PC card), and also to have a biometric pen attached to it to produce a ‘digitised signature’. The pen incorporated three sensors (one for pressure, and one each for the two dimensions of movement across the page), which it used to generate a digital ‘map’ of your signature and thence a cryptographic hash of the resulting data. The ratio of false accepts/rejects to correct accepts/rejects was pretty impressive, and seemed consistent whether you ‘enrolled’ with your signature or with some other pass-phrase. Unfortunately it was all a bit pricey.

The other feature of the system was that each of the devices in a setup (the card reader, the crypto adapter and the smart card) was able to establish a pairwise, DES-encrypted session with each of the others.

This meant that the session keys had to form part of a standard DES key hierarchy (session/data keys, key-exchange keys, and master keys). The role of the master key in this hierarchy is to encrypt/decrypt the key-exchange keys. Good practice says that your master key should be unique to each hardware device, and should never leave a protective hardware key-storage module, or KSM. (Bear with me… this is going somewhere relevant…)

In the PC adapter and the card reader, that KSM was about the size of a pack of cards, had a long-life battery back-up and several hardware protective mechanisms to prevent physical attempts to extract the keys. My favourite was the low-temperature sensor; it had been observed that, if you cool a memory chip sufficiently and then slice away at it with a microtome (thing used for preparing stuff you want to put under an electron microscope… makes very thin slices…), you could reveal the physical record of ones and zeroes and, in principle, recover the keys (a bit like reading the pattern of pits on the surface of a CD through a microscope). The low temperature sensor was there so that, if the KSM thought someone might be trying this, it would wipe the keys from memory.

The point is that in the corresponding smart card format, the size constraints meant that it was impractical to apply several of these physical security measures – such as the temperature sensors or the battery backup. Lack of the latter meant that instead of being stored in volatile RAM, the smart card keys were written to EEPROM so that they could persist in the card.

The adapter/reader KSMs also had a Faraday shield to prevent attempts to ‘eavesdrop’ on the module while it was at work. Obviously, that’s not very practical in the smart card implementation, though, if you want to use contactless communication between the card and a reader.

The bottom line is that, at least back then, the security of the key-store smart card depended to a great extent on the fact that it was very small, and was physically sandwiched between other parts of the chip. It was still more vulnerable to physical attack than its larger siblings, and such attacks were demonstrated by Ross Anderson and his students at the Cambridge University Computer Laboratory. (Incidentally, these physical attacks – and much more – are described in Prof Anderson’s 600-page book on Security Engineering, freely available online here, which is a belter of a read if you’re at all interested in this sort of thing).

The point is that whatever authentication protocols the smart card and reader undertake, the security of that communication is very likely to depend, ultimately, on the physical security of the smart card – and that imposes design constraints which can be extremely hard to overcome, especially if you want a card which is affordable at population scales of deployment.

Adam Laurie’s current attack may or may not be fatal in principle, and may or may not be viable in practice. It’s impossible to tell, from the level of information in the public domain – but by the same token, it is also impossible to conclude, from that information, whether or not these ID card chips genuinely increase the security and integrity of the bearer’s data.

All in all, a very sticky wicket [3].

[1] googly : a ball which appears to be heading in one direction, but instead breaks the other way. Rough translation – a pitch which starts out looking like a Sinker, but turns into a Cutter (remember that in cricket the ball can hit the ground before reaching the batsman… which gives an opportunity for an abrupt change of direction).

[2] play a straight bat : to maintain a resolute defence, often by playing a ‘blocking shot’ – though offensive strokes can also be played with a straight bat. ‘Keeping a straight bat’ is a general principle which relates to the wisdom of keeping your bat well aligned with the (vertical) stumps it is used to defend. No direct equivalent in baseball, because in cricket the batsman has the option of hitting the ball and not running… but technically, the closest equivalent might be a bunt.

[3] sticky wicket : an unpredictable or difficult playing surface – hence, unpredictable or difficult circumstances. Again, no direct equivalent, because it refers to the area the ball bounces off before reaching the batsman.

PS – at the time of writing, England are all out for a paltry 102 runs, while Australia have scored 79 for the loss of just one wicket. Not looking good for England.

• March 2006 – UK introduces RFID-enabled, ICAO-compliant ‘e-passports’;
• March 2007 – Adam Laurie demonstrates ability to unlock e-passport chip data for ‘read’ access;
• August 2008 – Jeroen van Beek demonstrates ability to clone e-passport chip and implant bogus images;
• August 2009 – Same techniques applied to clone UK ID card and modify its data.

Technological progress being what it is, we can already see – over the 3 years since their introduction – the erosion of some of the security features of the RFID implementation: for instance, in response to the August 2008 attack, the Home Office responded that

“it had yet to see evidence of someone being able to manipulate data in an e-passport. A spokesman said: “No one has yet been able to demonstrate that they are able to modify, change or alter data within the chip. If any data were to be changed, modified or altered it would be immediately obvious to the electronic reader.”

Note the careful phrasing there: “data in an e-passport”. What the attacks have demonstrated is that you can read the information off a chip, write it to another chip, and modify that version in such a way that it fools the standard UN/ICAO “Golden Reader” software. These two pages give more details and are a useful counter-balance to the “e-passports cracked, nation doomed” headlines:

• Q&A about Jeroen van Beek’s hack, from 2008;
• Register article on “how to clone an e-passport”, from Aug 4th 2006 (yes, 3 years ago last Tuesday!)

So, should we be surprised at this sequence of hacks? In one sense, no: essentially, all it illustrates is one of a set of basic principles about credentials. The diagram below shows how these attacks fit into that set of principles: in this instance, the ‘weak link’ comes when an authenticating party relies exclusively on the RFID chip to establish the connection between the credential and the person presenting it.

This diagram is just the latest embodiment of something I’ve been using since about 2005 to illustrate what I call the “chain of trust”. That is: the purpose of a credential is to provide some level of proof that the person presenting it now ‘is identical with’ the person to whom it was issued. This is a narrow but very useful definition of the term ‘identity’. What level of proof the credential can provide depends on the strength of several factors over the lifetime of the credential (and, indeed, its bearer).

In the current sequence of hacks, what is being tested is the integrity of the credential as a whole (can bogus data be successfully encapsulated in a credential which appears genuine?), and the robustness of the authentication step (does it rely solely on the credential, or does it also involve comparison with an ‘authoritative’ repository?).

The Home Office, IPS and ICAO have all pointed out that the attacks fail to overcome some of the safeguards built into the system as a whole. For instance, ICAO note that the passport hack would be revealed by a check against their PKD database; the UK authorities point out that a cloned ID card with the user’s details modified will fail a check against the National Identity Register (assuming that that repository still contains the details of the user to whom the card was originally issued). Those defences are all true – but they do not prove that the implementation of these RFID chips is secure as a whole. They show that it is secure in certain use cases – for instance, when the card is not used as a stand-alone authentication mechanism, but is used in conjunction with online access to other components of the system (such as the PKD or the National Identity Register) – and that checks against those components are, in turn, secure. The also show that in some entirely realistic use-cases – for instance, where an online check against the NIR or deployment of full-function card readers would be prohibitively expensive – the level of proof the credentials can deliver is substantially reduced.

Again, the answer to the question ‘should this surprise us?’ is probably ‘no’. On the other hand, let’s not forget that successive proponents of the ID card scheme have given a hostage to fortune in the form of the phrase “the gold standard of identity”. Some of them have even referred to commercial organisations “queueing up to rely on it as proof of identity”. It is one thing to proclaim this as a political aspiration; it is, as the hacks have demonstrated since the chips’ introduction, quite another to translate that into a comprehensive implementation which delivers the same ‘gold standard’ to all relying parties.

Several people I’ve spoken to recently have remarked that real-time social media like Twitter seem to reduce the frequency with which they blog… and I suspect it’s the same for me. It’s partly because Twitter soaks up time, and partly because it also soaks up some of those spur-of-the-moment ideas and comments which otherwise might have developed into fully-fledged postings. However, looked at the right way, I guess that might also signal a flight to quality rather than quantity of blog posts. Here’s hoping…

But I digress – or whatever a digression is called when it comes at the beginning, rather than part way through.

I’ve just got back from last week’s Burton Catalyst conference in San Diego – an excellent event, by the way, and congratulations to the Burton Group analysts who did such a good job of adding value, both through their own subject-matter expertise and by making introductions and connections so constructively between attendees. Over lunch, I got into a discussion with one of the analysts about the UK National Identity Scheme (NIS), whether or not it was a good idea, and whether or not there are reliable grounds for opposing it. As ever, discussing UK policy while abroad gave a great opportunity to look at it from a different perspective.

The view he expressed was, essentially, that there isn’t a good reason to oppose ID Cards on the basis of their use for e-government service delivery – the benefit of reliable authentication for joined-up government is worth having; however, there’s a risk involved if you suspect that the government lacks the competence to run such a scheme securely, and that risk might outweigh the potential benefit.

There were two other points which we noted and then moved on:

• first, that there are those who feel the National Identity Scheme is currently unaffordable;
• second, that cancelling the ‘small, visible, individual plastic card’ component of the system does nothing to mitigate the risk of operating the large, invisible, mass-scale repositories’ component of the system.

So, what of the question of competence? Well, the picture revealed by ComputerWeekly‘s FoI requests is not entirely reassuring. They list a number of breaches involving inappropriate insider access to records in the CIS (Customer Information System) database, one of the three major repositories in the Scheme. On the one hand, some breaches are indeed being discovered and those responsible are being disciplined (including dismissal). A DWP spokesman is quoted as saying that “the small number of incidents shows that the CIS security system is working”.

On the other hand, the article questions whether all breaches are actually being noticed (and/or reported), and suggests that many were only discovered after sample checks, rather than through alerts being triggered.

There’s also the issue of how many people have, or will have, access to the data held in the NIS. Currently it stands at about 200,000 civil servants, across 480 local government bodies and a number of central government departments. That figure will increase as data-sharing between the CIS and other departments such as the DVLA (Driver and Vehicle Licensing Agency) is put in place. Interestingly, a case study on the DWP’s own website gives this description of the DVLA’s ‘purpose of use’ for access to the CIS:

“to confirm receipt of higher rate mobility component of Disability Living Allowance for entitlement to exemption of vehicle licensing duty”

That’s really quite specific. Indeed, it might lead one to wonder whether that purpose makes it proportionate to expose the CIS’ 92,000,000 records to the DVLA user population. It’s not easy to find out the size of that population, but according to the DVLA’s annual report for 2007-2008 there were about 6,500 people on their payroll (this does not necessarily include those employed as part of ‘contracted-out services’, a separate item in the accounts).

The stated purpose also makes it legitimate to wonder what safeguards are in place to ensure that the data are not accessed for other purposes. The DVLA itself does not have an especially happy history where data sharing is concerned. After it reported £6.3m of income from selling motorists’ information to third parties, the government drafted new rules on acceptable use and sharing.

Returning, then, to the question of competence to run the National Identity Scheme securely: the DWP says it’s doing a good job of keeping the CIS secure, despite a small number of identified insider breaches; but the CIS is only one of three major repositories in the Scheme, each owned by a different department. All three of them need protecting if the whole is to be meaningfully secure. Then there’s the issue of securing access by ‘user’ departments such as the DVLA: the difficulty of doing that grows with each department added, and the growth is almost certainly exponential rather than linear.