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.

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.

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.

A few years ago I was given a very good piece of advice about technologists expressing a view on matters of policy: don’t.

“Think of three layers”, was the suggestion of my older and wiser colleague: “a bottom layer of technology, a ‘good practice’ middle layer, and a policy top-layer. Be aware that decisions at the policy layer are driven by all kinds of factors over which you will never have control… and however tempting it may seem to do otherwise, restrict yourself to opinions on the other two layers”. I took this advice to heart, and while I have had the occasional lapse, it has not let me down when I have stuck to it.

So, then, what to say about the UK government’s announcement, last week, of its plans to establish a cyber-security operations centre?

Well, I think there are three questions to ask (even as a technologist…):

1 – is there a pressing need for a cyber-security capability? I suspect the answer to that one is a clear ‘yes’. There’s no doubt that cyberspace represents an element of the Critical National Infrastructure (CNI), just like the transport, water, power, communications, financial and sewage networks on which our country depends. And just like all those other elements, the UK’s cyberspace presence is inextricably linked into the global network. (“Sewage?”, I hear you mutter… “How is the sewage system cross-border?” Ask the Dutch… I read a report that, if the Netherlands couldn’t export the excrement by-product of its bacon industry, the whole country would be ankle deep in pig-poo before the year was out. And with all those greenhouses, they use a lot of fertiliser…).

2 – is the government justified in maintaining/using an offensive cyber-security capability? This one is tricky to answer at the policy layer.

• At the technical layer, I have no reservation in saying that I want the security services to know how cyber-attacks work, and even in maintaining significant expertise: after all, they can’t mount passive defences if they don’t thoroughly understand the attacks.

• At the ‘good practice’ layer, offensive cyber-security capabilities tend to be restricted to getting malicious sites/services taken off the internet – and that only after going through ‘due process’ with the telcos, service providers, hosting companies and so on. Clearly, the latest policy announcement is based on the assumption that there may be cases where the security services expect to need to go further than that.

• At the policy layer, then, I think it boils down to this: what confidence can we have that those responsible for exercising such a capability are doing so proportionately, justifiably and accountably? In other words, it raises all the governance and oversight issues which have been so much in the political searchlight in recent months. There are established structures (such as the Intelligence and Security Committee – ISC) which are intended to make it possible for those ‘on the outside’ to be confident that those ‘on the inside’ have to at least tell a cleared and trusted few what they are up to. It is quite possible that those structures, though, are effective at providing policy oversight, but not effective at building and reinforcing public trust. For instance, Tory MP Michael Mates, a long-standing ISC member, has recently said that policy-forming documents he saw in the run-up to the Iraq War would “make people’s eyes water” if and when they are made public through the proposed enquiry… and yet, the Iraq War went ahead.

3 – Can the cyber-security team meet the security policy objective, while simultaneously protecting the UK against repercussions from the policy, safeguarding citizens’ use of the internet, and providing sufficient evidence of accountability to maintain the public trust?

In policy terms, the cyber-security announcement does include a statement about the appointment of an ‘ethics advisory group’ to complement whatever other governance measures are put in place. This group is apparently to monitor the ‘proportionality‘ of actions taken under the policy. But the ethical issues don’t stop there.

Supposing the cyber-security folks pre-emptively take down a malicious server outside the UK… presumably they would want to do that in a way which leaves no evidence of the attack having originated in the UK (for fear of reprisals…); perhaps they might consider launching the attack from elsewhere, in the hope that any blame (and retaliation) would fall on someone else.

I think the ethics advisory group is going to have a busy time.