Dave's Bit Bucket

Nintendo Wii brings a new emphasis to "Watch the television!"

It seems some new Wii owners have been getting a little over-enthusiastic with their new toys, and the straps which are supposed to secure the controllers to their wrists during play have been failing in some cases. Unsurprisingly, the main Wii page is now dominated by safety information, about correct wrist strap and controller usage.

More at http://www.wiihaveaproblem.com/.

Here's hoping, for their sake, Nintendo's investment portfolio includes TV manufacturers...

(2006-11-30 10:07:03.0) Permalink Comments [0]

Reinventing "IDS"

I had a rather illuminating discussion with A Really Big Customer a little while back, in the context of a Really Big Project they are working on.

The customer have an issue which states that they are getting worried about "not having an IDS solution on Solaris 10". In terms of IDS, they are typically an ISS shop - they want something agent-based which will do centralised reporting and alerting on perceived usage anomalies.

It turns out that only one IDS vendor - this being Prelude, about whom the customer knew nothing - currently do an agent for Solaris 10. From their perspective, this is "a bit of a bugger".

Now, in my (moderately) humble opinion, there are only three reasons why an organisation would consider having IDS in the first place...

1. Most of the time folk talk to be about IDS, they are working from a mechanistic risk evaluation and mitigation analysis system such as One I Won't Name Here which gets used when designing lots of Government stuff. This approach sometimes takes people down a technology path which might not be appropriate for them, and IDS isn't for everyone.

2. Consider that IDS doesn't actually secure anything - it merely alerts an admin team to its belief that an environment is under attack. I've met a very few folk who want IDS because they have their entire underlying security infrastructure well and truly organised, and want to add IDS as not so much "the icing on the cake" as the "100s and 1000s and the cherry on top".

3. Plain, simple pointy-haired stupidity, usually from some senior manager who just came back from Infosecurity or some other major show with a big wedge of brochures.

I don't find many folk (only two so far) in the situation of 2, and there's a lot more in 1. There's even more folk in 3. Really, IDS is only worth considering if everything else is nailed down properly already.

So, I was fortunate enough to get around a table with some senior geeks in the customer's admin and IDS department, and thrash a few things out in a forum where honesty ruled and political correctness was pretty much left at the door.

Things went roughly like this...

IDS Products

• Enterasys Dragon is a dead duck - development basically ceased 18 months ago.
• PrevX Enterprise is very good on Solaris 9 (or it was when I looked at it 18 months ago - it even found a rootkit concealed as a loadable kernel module), however it had issues with false positives around IPMP (reported to PrevX and which they said they would fix), and rather more serious issues around causing nodes in a Sun Cluster to panic. There is supposed to be a Solaris 10 agent coming, but I've yet to hear a peep about it.
• The customer has prior experience with, and likes, ISS. Unfortunately, I have never rolled my sleeves up and got my hands messy with ISS products. Apparently, ISS have made no commitment on their roadmap to produce a Solaris 10 agent. I suggested that the customer have a word with ISS about this directly, to seek clarification (and also apply an incentive to ISS to do the port).

  We discussed network-based IDS for a while, too. It looks like this technology (especially if it can handle decryption of encrypted streams) is probably off the menu, particularly as a result of the huge level of paranoia around the subject of interception or potential disclosure of cleartext data in the infrastructure's databases. This is a pity, as our N2000 kit would have been really cool to get in here to do said decryption...

  Customer Issues with IDS

  Your typical formal IDS appears to be set on a hair-trigger. For instance, the poor front-line IDS alert analysis guys in the customer's organisation get alerts whenever a webserver or appserver gets manually restarted, because the IDS agent they use on Solaris 9 thinks it's a SYN flood attack.

  Now, there's no remotely conceivable reason why a SYN flood should be seen by a server's live service interfaces when it is presenting a load-balanced service. Any load-balancer worth its salt is smart enough to drop something like a SYN flood right on the floor by default.

  Also, even if you have a physical intrusion by a Bad Guy on a site (which other security measures should catch anyway), what clueless weenie of an attacker is going to try to take a multi-CPU SPARCbox down via something as lightweight as a SYN flood, given that we've sanity-checked for them for years?

  IDS solutions need a lot of configuration to prevent false-positive alerts like this showing up; in fact, "tuning" a traditional IDS feels like taking an undifferentiated instrument so sharp that it can cut daylight, and selectively blunting parts of it with a lump hammer.

  Customer Procedure

  I explored with the guys exactly what it is that they do when they get an IDS alert. After all, if you get an SNMP trap screaming at you that you're being attacked, you have to do something to qualify and act on it, right?

  Given the fragmented nature of their groups, there was a lot more politics and a lot less solid response definition involved that I would have hoped for - as a real killer, the procedure included at least 3 levels of inter-departmental handoff, so there was no single joined-up procedure that was contained within a single person's head. IMHO this is not the way to run an IDS, or any other aspect of system management, for that fact. However, the groups have apparently been re-orged to the point where they are now joined up, so here's hoping that everyone starts talking to eachother sooner rather than later...

  In common with everyone else I've spoken to who is deploying IDS, this customer get a very large number of false positives. In fact, they get more than 2000 reports a day, which are analysed by "eyeball 1.0" and typically reduced to 2 reports a day which may be worth actual investigation. Note that the infrastructure they are working on isn't even live yet - this is all test data and sysadmin activity. I pity them when it all goes live, they will find out what "inundation" really means.

  Other than lack of knowledge about event correlation and root cause analysis software, the main reason why the customer isn't doing this stuff in an automated or semi-automated fashion yet is that they still don't have all their system clocks synchronised to a single, monotonically increasing time source. I believe their top priority has to be to get everything on NTP and UTC.

  Once they have done that, they might find some mileage in looking at Tier-3 Huntsman or e-Security Sentinel, for log and root cause analysis, or letting their perl hackers loose on read-only copies of the logfiles.

  Oh, they aren't using Tripwire either. Or N1SPS. Or the Solaris Security Toolkit (yet). This makes determining by audit process "what their servers are actually set up to do" not so much a real problem as an utter bastard. Trying to deploy an IDS into an infrastructure in an unknown state feels to me like a real exercise in futility, and a lot of hard, ongoing work for no reward. They definitely need to nail the infrastructure down, first!

  Standards - and How to Get Around Them

  As I suspected, the infrastructure security is designed to meet the requirements of a prescriptive recipe. So, let's think laterally here. What does this recipe define as constituting an IDS?

  According to the customer, the given definition of an IDS is "woolly" (which might be a contributor to why the recipe is in the process of being rewritten).

  So, if I define an IDS as being "some software capability which gives realtime reporting on odd or bad stuff happening", then there's a whole bunch of possibilities which can arise.

  In fact, a properly configured Solaris 10 install - along with some analytical stuff at the log aggregation point which a typical system and network management product should be able to handle - could be considered to contain enough functionality to comprise an IDS for this purpose :-).

  Start by privilege-limiting all the services which a host serves up to the network. Compared to most IDS-associated technologies, this also has the benefit of actually tightening the system's security up. I've also sending the customer all the details of restricted privileges within zones (and also Glenn and Darren's excellent BluePrint on priv debugging), so that they may construct per-app zones with limit sets conducive solely to the apps (1 zone per app) running in them.

  If such a configured environment logs any attempt of privilege violation, then this is a guaranteed bona fide hit that "Something Is Going On That Shouldn't Be".

  Use this mechanism to get rid of a lot of false positives, add Solaris-Audit-over-syslog, and you're suddenly really getting somewhere :-).

  Similarly, set ipfilter up in the global zone (as, indeed, you must today) and get it to log anything that isn't expected traffic (ie outside the simple ruleset you've configured it to allow).

  So, once you have tracking of privilege violation attempts, port scanning and other anomalous network traffic, and kernel-level auditing tracking who does what - especially when things are done with legitimately enhanced privileges - you use syslog to shunt it all to a dedicated log gatherer, which also runs some code to look for this kind of behaviour and send appropriate SNMP traps.

  What more would you want in an suitably tuned IDS? :-).

  Seriously - what more would someone be likely to want in an IDS, which is not covered in the above? Could it be put together fairly easily?

  (2006-11-30 07:34:47.0) Permalink Comments [0]

It's official, Tony isn't Adolf...

Found here on El Reg.

I've never had much of a bee in my bonnet about the civil liberties elements of ID cards, so I don't usually follow what the folk at NO2ID get up to, but the poster in question is very well-produced.

Full marks to the Advertising Standards Authority for a very sensible assessment.

(2006-11-29 08:49:25.0) Permalink Comments [0]

Digga ding ding ding ding ding...

I've been watching Heston Blumenthal's TV series "In search of perfection" (BBC2, Tuesdays, 20:00 or 20:30, it varies), and there's a couple of tricks I think he's actually still missing.

The episode the week before last, on steak and salad, I found particularly excellent - as well as going to considerable lengths to find the perfect cut of beef, Blumenthal's method of cooking it (brown with gas torch and then put in a 50 degree oven to cook for 24 hours) is both simple, and from a Physics perspective, blindingly obvious. Yet, this is not the way beef is typically cooked. I'll probably give it a go :-).

Last week's programme, on perfect fish and chips, was excellent from the perspective of finding the perfect fish (Cornish turbot) and the batter techniques (borrowing from Japanese tempura), however he still peels the potatoes he uses for his chips. I'm surprised he hasn't noticed that the most flavoursome part of a potato is the skin. Fish and chip shop proprietors "in the know" wash their spuds and put them straight in the chipper rather than peeling them.

This week's, on pizza, concentrated (and justly so) on the tomatoes. In my view, it's the tomatoes that really define an excellent pizza. I've eaten in the Neapolitan restaurant he visited, and I must say that I thought it was outclassed by Gino's in Vico Equense, which is on the mountain road between Naples and Sorrento; the pizzas there are rectangular and you buy them by the unit length :-). The bases at Gino's aren't just unusual in their shape, though; the texture is also very different, and is probably best characterised as "Victoria sponge cake but a bit firmer". They are about 4mm thick and actually melt-in-the-mouth, very different to either the typical thin and slightly-crisp traditional Italian base or the more doughy, thicker American base. It would have been cool if Blumenthal had managed to replicate this instead.

His idea of using a well-heated heavy iron pan as the object to cook your pizza on, thus getting your oven hot enough to cook the pizza quickly, is a neat one.

(2006-11-29 08:37:57.0) Permalink Comments [0]

Why Microsoft Windows Vista cannot be deployed in Government, Critical National Infrastructure, or Battlespace

...and I may well have missed a few categories for the sake of a concise subject line, especially where Finance, Aerospace, etc are not specifically included under the banner of "Critical National Infrastructure".

Read this, and be startled.

Update:

Putting a black hat on for a moment, this also means that Microsoft's licensing verification servers will be the number 1 target for any actual Black Hat who wishes to cause general chaos, rather than target specific organisations; taking the licensing servers down in a manner which resulted in an outage of significant duration would precipitate a worldwide Vista outage.

Also, in battlespace, if you're running Solaris and your enemy is running Vista, it may be within the rules of war to target Microsoft's licensing infrastructure (with either electronic warfare methods or, depending on the sphere of conflict, ordnance) and watch your enemy's C4I infrastructure collapse...

(2006-11-22 06:43:54.0) Permalink Comments [0]

Google Analytics

For bloggers who want to know where their hits are coming from, you'd have to go a very long way to beat what Google Analytics gives you, for free.

Signing-up for the service is very straightforward; I did it the day before yesterday, and about the only trick a blogs.sun.com-based blogger needs to know is how to embed the Analytics script within your page:

• when you're logged-into blogs.sun.com at the point where you'd normally be editing a blog entry or creating a new one, go to "Preferences" (next to "Create & Edit" in the top bar)
• from here, go to the "Template" entry in the bar underneath
• click the Edit icon for the "Weblog" template
• paste the Analytics script into the template, out of the way of any major formatting stuff
• save

...and you're done :-).

It's straightforward to verify from within Analytics that the script is installed and working; don't worry that you don't see any stats for a few hours though, it can apparently take up to 24 hours to get something which can be reported on (my own experience is that all was working and giving interesting information 12 hours after install).

(2006-11-16 01:12:51.0) Permalink Comments [0]

Woot! (aka "Want One Of Those")

Consider your typical keyring laser pointer.

Now consider something in a "typical keyring laser pointer" form factor which has the output of a low-energy beam weapon (well, sufficient to light a cigarette at short range, anyway).

Welcome to the world of http://www.wickedlasers.com/, makers of handheld Class IIIB lasers for the scientific and military communities.

US FDA information and regulation on lasers of Class IIIa and higher output can be found here, I have yet to see whether UK firearms regulations say anything about directed-energy devices...

Update:

It looks like you can make yourself a similarly-decent laser pointer for rather less cost, provided you start with the right kind of DVD burner. See http://www.makezine.com/blog/archive/2006/11/how_to_make_a_d_3.html?CMP=OTC-0D6B48984890.

(2006-11-16 00:59:29.0) Permalink Comments [1]

Contemplating Second Life

Whatever your opinion of Second Life - and given the huge range of opinion I've seen in the press, ranging from "it's the future of the Internet" to "it's a complete waste of time" I suspect that you, dear reader, have an opinion and cleave to it fairly strongly - I'm rapidly reaching the conclusion that "ignoring it is probably a Bad Idea, and it's time I found out more about it".

The fact that we have our own pavilion on our own island, and that illuminati of the likes of John Gage, Tim Bray, Simon Phipps and Chris Melissinos have presided over conferences there, suggests that Sun sees some mileage in having a Second Life presence. There's also a growing list of Sun employees who have "incognito" avatars (ie ones with names which are not associated either with their own real-world names or with Sun); I've heard that one or two geographically-dispersed groups have even held team meetings there.

Further, from my perspective, the sanctioned crossover and exchange between the Linden dollar and the US dollar means that, not only can folk make a real-world living from virtual-world work, but if there are any security holes in the system which allow Linden dollars to be either transferred in an unauthorised manner or created from thin air in an unauthorised manner, someone could be on to a small fortune by nefarious means and Linden would be in serious trouble. I'd rather like to find out more about security in Second Life (not to exploit any holes I might find, of course - I'm a good boy really :-) ).

Second Life has a few barriers to entry. First of all, you need a fairly seriously-equipped box to run the client software on - and there isn't a Solaris client yet (although as there's a Mac OS X client available I could cope, even though my box is only at the specified entry level). Second, you need a reasonable pipe to the net at large, in terms of bandwidth; I don't have Internet connectivity at home, and Sun's external gateway blocks a bunch of ports that Second Life traffic flows over (SL requires UDP and TCP connections, inbound and outbound, on network ports 443 and 12020 to 13050, inclusive - the need for inbound connection initiation surprises me, I'd have hoped they'd be more firewall-friendly), so I'd have to get DSL installed at home (which is something I'm not hugely inclined to do, to be honest).

Finally, you need a name. This is more of an issue than is perhaps necessary; Linden only expose a small subset of possible surnames, and to get one which reflects your real-life affiliation (Chris Melissinos, for example, managed to get "ChrisMelissinos SunMicrosystems" as his SL name, all Linden employees have Linden as the surname of their SL avatars, and when Reuters set up their in-world bureau, "Adam Reuters" was created to head it up) involves a mechanism I don't know about yet. Pinging Linden tech support resulted in no useful feedback, but (provided you don't mind believing some things you read in the press) there's an article here which suggests that Linden may start selling names outside of their free-registration choices. The naming scheme from "Jennifer Government" appears to be coming to SL :-).

Also, I hear that the user interface isn't the world's easiest to drive - getting your avatar to walk, even, is a skill which needs to be acquired. When it comes to making arm gestures, at least, I wonder who'll be the first to splice together an interface which allows the controllers from Nintendo's Wii console to be used in an SL environment - maybe a Second Life client for Wii will happen at some point?

Update:

Well, synchronicity happens from time to time - here's me musing about the possibility of security holes in SL upsetting the Linden economy with real-world repercussions, and now I find out that someone has produced "CopyBot", a tool which can clone any in-world object and change its declared ownership to that of the CopyBot user. See the "SL Insider"'s view on the problem here...

Further Update:

It gets worse - now SL has had a brief period offline so that an in-world object which self-replicated when interacted with (effectively, an application-level fork bomb) could be cleaned-up. "Hello, nice folk at Linden, would you be interested in engaging the services of a bunch of security geeks to review your application design?"

(2006-11-15 08:33:26.0) Permalink Comments [1]

In praise of British supercars

In today's Daily Telegraph, there is a thoroughly heart-warming story which shows that British automotive engineering is far from dead. Bristol Cars have just released the "Fighter T", which hits 60mph from a standstill in 3.5 seconds and is claimed to max-out at 275mph, thus claiming the mantle of "the world's fastest production road car".

This follows on from my pal Alec's blog entry on the Trident Iceni R, which is (AFAIK) the world's only diesel-powered supercar.

My own Aston Martin DB7 Vantage (I know, I really must get round to figuring out how to include pictures in postings on blogs.sun.com as I have some nice pics of mine) is rather slower than either of these, getting to 60mph in a comparatively-pedestrian 5 seconds and maxing-out at a claimed 184mph (I'll test this next Easter, when I expect to be taking a jaunt with some pals to Monte Carlo via Germany), however I while I'm more than thoroughly happy with what I have for the forseeable future, at least I can keep an eye on what I might go for next :-)

(2006-11-09 06:32:15.0) Permalink Comments [1]

DRM and the "Westminster irregular verb"

Following a brief discussion with a colleague who wishes to remain nameless, there's yet another interesting angle on why the use of DRM within Government could cause the wheels of power to seize up. With a "tip of the hat" to the work of TV comedy genius which was "Yes, Minister", consider the Westminster irregular verb:

• I "inform"
• You "leak"
• He / she / it "breaches the Official Secrets Act"

Fundamentally, the nature of the relationship between Government, the Press and the electorate is such that disclosures of sensitive information are sometimes necessary, in order that the feedback loop whereby "morally moribund practices within Government are exposed to the electorate, to the effect that the perpetrators usually get voted out at the earliest opportunity" is preserved.

This is one of the things that various Governments' Freedom of Information Acts are all about, and I, for one, find such legislation thoroughly enlightened.

Whether intentionally or otherwise, DRM would most likely act to block such disclosures taking place in a timely fashion. Discuss the consequences :-).

(2006-11-09 06:18:42.0) Permalink Comments [0]

DRM and the Law of Unforseen Consequences

There's another very good reason why DRM in both media and the enterprise is likely to fail, and it goes all the way to national and foreign intelligence and security services.

Despite what you see in the movies, much intelligence work is pretty mundane - get feeds of as many TV channels and as much printed or otherwise-circulated news media from around the world as possible, translate (where necessary) and analyse them, and pass anything deemed "interesting" (either from personal initiative or based on a list of "things to look out for") up the chain. I don't know how much Internet-based content is monitored right now, but given the timeliness of posting and detail of various blogs written by residents of Baghdad, Israel, Palestine etc, I'd be very surprised if a whole bunch of such data wasn't included today.

Now, consider what happens if DRM gets thrown into the mix.

All of a sudden, the need arises for such monitoring and intelligence services to be able to strip the DRM control away from the content. If the content can't be readily "passed up the chain" and potentially made available in multiple copies for examination and discussion by The Powers That Be, and maybe also archived in perpetuity as evidence (not to mention potentially being made available under the Freedom of Information Act at some future date), then Trouble arises. So, monitoring services need to either:

• coerce DRM vendors to include a "back door" which will enable them to easily strip DRM from content - a situation which would look remarkably similar to the Clipper key escrow fiasco and would probably end the same way
• raise their computing resources game to brute-force the DRM protections
• do something else I've not thought of yet

...since they can't necessarily do a simple exploit of the "analogue hole" by pointing a video camera at a monitor showing a legitimately-decrypted feed (after all, they wouldn't want to make a legitimate subscription to some monitored services, in order to ensure that the owners of the service couldn't determine that they were being monitored).

Also, depending on how you look at it, the Freedom of Information Act could be considered as "legislation which prohibits or places very onerous limits on Government use of DRM technology"... but that may be another posting in itself :-).

(2006-11-09 03:53:47.0) Permalink Comments [0]

"Dear Tony..."

I know it's fairly obvious from the press that you no longer consider - or even acknowledge - the opinions of your electorate, but given your recent outbursts on national ID cards, you might like to have a look at the following.

Disclaimer: These are the words of one well-to-do reasonably-savvy computer security geek, who is never likely to vote Labour.

Said words do not necessarily reflect the opinions of my employer, even though I wish they did.

Anyway, Identity cards do not - and cannot - solve the problems you claim they will. Here's why, along with some further thoughts.

The Main Problem

Gathering the data is not the main problem (although that data gathering has its own issues, such as people not having precisely-gatherable biometrics); the main problem is mediating who is allowed to access the data, from where, when, in what manner (readonly / read-write, whether censored / elided or not), on whose behalf, and for what purpose. Managing metadata associated with data sensitivity and access control is the definitive problem which may sink the whole proposal for end-to-end surveillance. There is also the matter of whether the data as gathered is itself reliable; see http://www.antipope.org/charlie/blog-old/2006/05/17/ about the all-too-plausible failure of the NIR from a data integrity perspective (although the dates probably need updating). Such a scenario would spell out the pointlessness of the whole exercise. Labelling of data and accessing entities, as can be done with Trusted Solaris 8 and Solaris 10 (labels comprising a tuple of a hierarchical sensitivity (eg CONFIDENTIAL, SECRET) and a non-hierarchical compartment (eg SECURITY SERVICES, NHS) is a solid foundation upon which to build, but the means to sufficiently express fine-grained access criteria - in terms of delegation, subject duress, etc - are still, AFAIK, being developed or onerous to deploy. See also commentary on the re-emerging proposal for the US equivalent at http://www.schneier.com/blog/archives/2006/10/total_informati.html.

Terrorism

In a world where many terrorists are now "single use" entities - individuals who have no recorded history of terrorist activities, and are frequently required to die in the execution of their single act of terrorism - being able to verify an individual's identity gives little benefit. The September 11th terrorists travelled under their own names using valid passports and visas (and in some cases, genuine Virginia driving licenses obtained fraudulently), and there is no evidence that the Madrid bombers used forged ID. National ID cards would not have prevented the 7/7 attacks, either; the attackers were registered and, until that point, law-abiding British citizens.

If an ID card is to be able to contribute to reducing the threat of terrorism by this kind of terrorist, not only would it need to be produced and verified in order to obtain any ticket for travel on any means of public transport, or when making any vehicle purchase or lease, but all communications associated with all individuals would need to be recorded, analysed for content, sources and destinations, and tied to individuals' identities. US Adm. Poindexter's Total Information Awareness study, which proposes this kind of pervasive communications interception and analysis, fell out of favour but now appears to be re-emerging in the form of Tangram; nonetheless, the Regulation of Investigatory Powers Act 2001 prevents such systems arising here (unless some further excessive blanket characterisation of data happens, to the effect that everyone's movements, transactions and communications are considered to be "matters of national security").

Identity Theft

While an identity card which can be provably associated with a subject (see requirements on "what should be stored on the card" below) reduces the risk of identity theft when the subject and the inspecting officer are physically co-located, the officer has requested the card and the subject has it on their person and is willing to present it rather than lie about it being elsewhere, it has limited effect when the subject is not present in person. If synchronisation and maintenance of synchronisation of data across various departments' databases could be performed under the auspices of the ID card project, however, the ability to masquerade as deceased subjects or subjects who have permanently left the country could be significantly reduced.

However, the principal milieu in which stolen identities are used today is that of credit / debit cards and their use to purchase goods and services. If this area is to be addressed, elements of Government-held identity databases would need to be opened up for read access by credit card companies and vendors of goods and services - alternatively, the identity card, if suitably compartmentalised, could also potentially be used by banks as a replacement for current credit and debit cards provided the Government and the finance industry can put mutually acceptable collaboration and data sharing agreements in place.

Invasive and semi-invasive attacks which can read information stored on a card (cf Skorobogatov's and Anderson's paper at http://www.cl.cam.ac.uk/ftp/users/rja14/faultpap3.pdf) mean that the electronically-stored component of ID cards could almost certainly be "cloned".

"Identity fraud" needs to be re-investigated as a legal concept; see Ross Anderson's security group's blog. There is also the matter of what constitutes "identity" anyway - I suspect cheques are falling out of favour as a payment mechanism as a result of excessive duplication of personal names (http://www.yournotme.com/ tells me that there are another 3590 David Walkers known to be resident in the UK; for your information, it also says that there are 39 Anthony Blairs and 4 Cherie Booths, so at least you are at lower risk of unexpected name collisions).

Benefit Fraud

From a mitigation perspective, this can be considered as a functional equivalent to identity theft, above - the principal difference being that the DWP replaces the vendor of goods or services.

Illegal Immigration

Illegal immigration is unlikely to be significantly reduced by a National ID card scheme, as it has no way of impinging on "people smuggling" activities. Illegal working by illegal immigrants once they are in Britain, however, could possibly be reduced using such a scheme - provided the organisation the would-be worker attempts to gain employment with is itself legitimate and registered, and that all such organisations are mandated to perform identity checks on their workers on pain of serious fines. However it must be borne in mind that such illegal working cannot be eliminated until it becomes impossible to transfer funds in a manner which is not audited and where the transaction is nonrepudiable - ie until banknotes, coins and other unauthenticated promisory instruments are phased out or otherwise made traceable at legitimate point of use (eg by putting barcodes on all of them, and requiring that they be scanned at point of transaction). Even then, some illegal working is likely to continue, by dint of workers being paid in kind, in terms of food and lodging (cf the modus operandi of some gang masters, as revealed after the Morecambe Bay disaster).

Organised crime

As with illegal working above, the ability to transfer ownership of goods or promissory instruments in a manner where the transaction is not subject to Government audit means that organised crime will continue despite the introduction of an ID card.

It recently came to light, for example, that fully 75% of all 500-Euro notes in circulation were issued in Spain; when the Euro was adopted there was some discussion as to whether a note of such high denomination should be printed, as it would make money laundering easier. The Spanish banks do not know where these notes now are. Spain has an ID card scheme where cards are issued to everyone at or above the age of 14, and carrying of the card at all times is compulsory. Go figure.

The Nature of Identity

"Identity" is a complex subject. A person's identity can be considered as being some subset of all the information which is known about them and the items, organisations and other people to whom they are connected. For example, the following information comprises a subset of the information that HM Government already possesses today, in different departments, about a typical British citizen born and resident in the UK:

• Name (and maiden name(s), where appropriate)
• Home address(es)
• Telephone number(s)
• Date of birth
• Place of birth
• Gender
• Parents' names
• Marital status (and spouse's name, if married)
• Children's names (where applicable)
• Driving licence number, endorsements, photograph (for licences issued since 2001)
• Passport number (and photograph without hat or veil)
• Foreign travel history
• Car and motorcyle registration(s)
• NHS number
• Medical history
• National Insurance number
• Tax history, savings information, bank accounts, share dealings, other financial assets
• Employment history
• Social Security benefits claimed
• Signature specimen

Other information, such as criminal record, Government vetting details (whether for Government security clearance or licensing to work with children and vulnerable adults), etc is also held - as are court appearance details, Probate records and many others - however most of these are applicable only to a small subset of citizens.

For the most part, only the person to whom the identity parameters refer is ever likely to need to know about the whole set of parameters (eg under the Freedom of Information Act).

Arbitrary subsets of this information can be considered as an appropriate identity for a subject by various Government departments, and also by private-sector industry.

Biometric information - other than a photograph and signature specimen - is not currently gathered. The proposed National ID Card is intended to change this, for reasons which are debatable.

While this information is known to HM Government for British nationals, "bootstrapping" identity (ie the act of verifying identity and compiling data to a point where a UK National ID card can be issued) is more difficult for foreign nationals who may be resident in the UK. Many citizens of EU member states already have a national ID card or a passport which could be considered as sufficient proof of identity to facilitate issue of a UK identity card, and American citizens resident in the UK will similarly have a passport and (most probably) a US driving licence (although this could have been obtained fraudulently). However, asylum seekers and citizens of other countries who may need a UK national ID card to go about their daily business while resident here will often not have sufficient documentation to constitute proof of their identity, based on records from their nation of origin. While I've seen stories recently regarding how would-be immigrants are to be subject to "deep background checks" when entering the EU, this presupposes that the governments of their home nations will be willing to cooperate - or even that their home nations have a government. Would-be arrivals from Somalia would definitely have problems in this regard.

Further, if an address is considered to be a mandatory datum within an identity, the homeless or travellers will not be able to acquire National ID cards. This may have adverse interactions with the Human Rights Act, if access to services is mediated on the ability to produce a card. Travellers of Romany descent may even feel provoked to raise the issue of Racial Discrimination.

Biometrics

As Bruce Schneier famously wrote in his book "Beyond Fear", "biometrics are not secrets".

The meaning behind this statement is that biometric data cannot be managed with the same efficacy as alternative authentication mechanisms such as passwords or PKIX certificates. Biometric information can be readily captured via innocuous real-world interactions, and cannot readily be revoked or renewed. For example, if a subject leaves their fingerprints on an object, they can be captured and, provided human supervision is not mandated at a biometric authentication point, replayed (see, for example, http://www.schneier.com/crypto-gram-0205.html#5).

The biometric mechanisms understood to be proposed for the National ID Card comprise:

• a photograph - which can be compared with the face of a subject standing in front of a sighted officer suitably authorised to request and examine an ID card, without recourse to a computer. Such a photograph could be laminated into a card equipped with suitable tamper-evident / holographic laminations that forgery would be extremely difficult.
• digital characterisation of a set of fingerprints - which would need to be stored on the ID card in a tamper-proof manner (eg signed with a Home Office private key), so that they can be examined by a suitably authorised officer without having to connect to a central database of such information. Such an officer would need to be equipped with a device to read the information as stored on the card and verify the integrity of the signature (eg by holding a Home Office public key), and also to scan the fingerprints of the subject stood in front of him. It should be borne in mind that the pads of the fingers are easily damaged in accidents - burns while cooking, cuts and grazes while gardening, etc, even wrinkling after an hour's immersion in water - so the ability to match records to the biological entities presented may vary with circumstances.
• digital characterisation of the pattern of blood vessels on the iris - which would need to be stored on the card in the same tamper-proof manner as fingerprint data, and for the same reasons. Scanning irises requires more sophisticated equipment than scanning fingerprints - to the point where it would be difficult and very expensive to equip an officer's portable verification device with such a capability - and is not efficacious in cases where the subject has significantly reduced blood pressure to the eyes (ie has suffered significant injury or is deceased).

Ultimately, an issue of bootstrapping arises. Even for a subject born in the UK, there is no mapping between their identity as described in current national records (such as a birth certificate) and a biometric. I have had personal experience of this:

I was born in the same hospital as another David (no middle names) Walker, on the same day. Granted, our mothers were different women. However, our births were also registered on the same day by the same registrar. Therefore, there is somewhere another David Walker who has a short-form UK birth certificate exactly the same as mine (other than serial number), and which is also completely legitimate.

The long forms of our birth certificates are different, as the long form also contains the mother's signature (it's worth noting that blood groups, other biometrics, etc are not included even on the long form). However there is nothing on paper which could potentially have stopped him masquerading as me or vice-versa based on the short form, as the short form is accepted in legal circles. The only difference between our short forms would be the serial number, and as the hospital and its associated registrar's office closed over 30 years ago, I have no idea where the long forms ended up.

I still don't have the long form of my birth certificate - ie, I can't produce a piece of paper to show that I'm my mother's son - yet this didn't stop me being able to obtain probate and therefore inherit my mother's (not exactly trivial) estate when she died. The other David Walker could conceivably have tried to contest the probate decision on the grounds that I wasn't me, and he was. Fortunately for me, he didn't.

If biometric information is to be gathered and recorded, it therefore needs to be gathered and recorded at birth, rather than the proposed age of 16, if it is to serve to disambiguate individuals reliably. Therefore, full introduction of a properly-bootstrapped, biometrically trackable ID card will take a century to permeate the population pervasively.

Returning to biometrics, the pattern and size of the biometrics proposed changes as the subject ages. If a need is identified to be able to unequivocally match a subject with an identity, irregardless of the physical condition of the subject, then the only biometric currently known which does not change over time - DNA base sequence - needs to be encoded into the documents which are required in order to obtain an ID card (such as the birth certificate), and verified before an ID card can be issued.

The issue of bootstrapping applies to even greater effect for foreign nationals, as discussed above.

What should be Stored on the Card?

Given the proposed physical format of the ID card and the circumstances under which its integrity would need to be verified (ie detecting whether a card is a forgery, and the examining officer not being in a situation where network connectivity was feasible), it is expected that a number of items would need to be encoded onto the card itself. The proposed items to be encoded are:

• a photograph (without hat, dark or mirrored sunglasses, or veil), printed on and laminated into the card in such a manner that it could not be easily replaced or forged
• the subject's name, printed on and laminated into the card in such a manner that it could not be easily replaced or forged
• Home Office imagery and seals / holograms printed onto the card using anti-forgery techniques such as those described in the Secure Printing chapter of Ross Anderson, "Security Engineering"
• digital representation of a set of fingerprints, signed with a Home Office private key
• digital representation of the subject's name and any maiden or previous name(s), signed with a Home Office private key
• an index into the identity database, signed with a Home Office private key Where an officer does not have network connectivity and can therefore cannot connect to the identity database, it will nonetheless be possible to unequivocally verify the integrity of the card provided the officer has a device able to read the digital representation of the subject's name and verify the associated digital signature by virtue of carrying a copy of the appropriate Home Office public key. Even if the officer were unable to examine the fingers of the subject, it will be possible to readily verify the subject as the rightful custodian of the card provided the subject is facially identifiable (ie, any such officer must be empowered to require a veiled woman to remove her veil for facial identification).

  Other biometric information which is not expected to be readily gatherable and analysable by a portable device - such as iris prints and DNA base sequence (which really should be stored, if we're going to go about this reliably) - can be stored in an online identity database instead. Authorised officers' centres of operation will need to be equipped with more sophisticated equipment able to gather and analyse such biometric data against an online identity database.

  The manner in which digital information is stored on an identity card is also a subject for discussion. If a subject is eventually to be expected to carry their ID card at all times, the card must be able to retain the digitally stored data with full integrity in a variety of hostile environments - for example in temperatures between -20 and +40 degrees Celsius, and following immersion in fresh, salt or chlorinated water for up to 24 hours.

  It is therefore suggested that, if possible, digital data should be stored on the card not only in silicon-based storage (eg a smartcard with contact pads) but also printed on the card as a 2D barcode. RFID is likely to be deprecated as a means of communicating data stored on a National ID Card, owing to the likelihood of interference with other RFID devices in proximity, and also the threat of interception or unauthorised reading of the data as stored - in fact, there is an interesting US Dept of Homeland Security draft doc which deprecates RFID for the purposes of people-tracking at http://www.dhs.gov/xlibrary/assets/privacy/privacy_advcom_rpt_rfid_draft.pdf.

  Further, the electronically stored contents of the card should be resistant to attack. Skorobogatov's and Anderson's paper not only expounds on a novel optical method of attacking a chip's contents, but also provides a useful overview of, and references to, other out of band attacks of varying degrees of invasiveness. It is with these attacks in mind that the importance of signing all data stored electronically within the card is emphasised.

  To reduce the possibility of card content forgery which the paper above reveals, the parameters stored electronically on the card should be signed both individually and as an overall tuple - so, for example, an apprently-valid card could not be created which contained the fingerprint data for person A and the name of person B.

  If the card itself were to potentially be used as more than a store of identity information - eg if an ID card was also to be used as a bank ATM card - the storage within the card can be segregated and managed by multiple entities, each authorised to only have write access (and potentially also read access) to their specific area of storage. Such mechanisms were developed some years ago as part of the Multos initiative, and have since reached maturity as part of the JavaCard framework. However, research from Skorobogatov and Anderson, among others, suggests that careful management of the data via encryption and signing is also to be strongly recommended.

  The Identity Register

  HM Government currently stores the information above in disparate, disjoint sets of databases within "stovepipe" infrastructures owned by, and dedicated to the service of, individual Government bodies (eg DVLA, NHS, Home Office). If the identity database which will be required to support the Identity Card scheme is to be constructed as a further isolated "stovepipe", much duplication of data - and growth in inconsistency of data across the stovepipe databases, over time - will result.

  Alternatively, identity federation technologies could be employed to enable the national identity database to synchronise with the existing infrastructures. Provided a common network infrastructure (GSI, xGSI) exists which connects all these stovepipes, the national identity database and its infrastructure could be configured with appropriate workflow to make reference to data stored in the existing stovepipes, and apply synchronisation across stovepipes when existing citizen data needs to be changed. As version 2 of the Liberty protocols enables configurability of the subset of identity information exposed as part of any transaction, and identity provider software provides transforms between identity sets, it would be feasible for this to be done.

  Applying a workflow synchronisation mechanism across multiple databases in this way would itself act to reduce some of the threats the ID card is intended to mitigate - for example, it would no longer be possible to conduct benefit fraud by stealing the identity of someone who has died, since issue of a death certificate and revocation of the deceased's ID card would also remove entitlement to benefits from the benefits databases.

  Another possibility might be to obtain an appropriate aggregative view of data stored on repositories using data repository integration products.

  The database itself is likely to require a significant amount of storage, especially if multiple biometrics need to be stored for each individual - it is expected that, given the current proposals, biometric data will constitute the largest volume of data in the system. Appropriate data for storage for each individual might comprise:

  • 16-point correlation tables for 10 fingers (where each point is stored as a pair of 8-bit coordinates)
  • 16K JPEG image of a photograph (higher quality, requiring more storage, is recommended)
  • correlation images for 2 retinas (400 points each, where each point is stored as a pair of 8-bit coordinates)
  • DNA base sequence (10,000 base pairs)

  Data Security and Privacy

  Clearly, data stored in an identity database must be protected from unauthorised access. Unauthorised acess to such a database would constitute a breach of not only the Data Protection Act, but probably the Human Rights Act. If, rather than having a single "stovepipe" database, an identity database is established which aggregates existing data stored in current "stovepipe" Government databases, the fact that the data is not stored in one place means that, even if one database was to be compromised, not all of the information necessary to steal sufficient data to masquerade as another person could potentially be gathered.

  Also, tight control needs to be kept regarding who is permitted to access which aspects of citizens' identity information. While this could be segregated within a unified "stovepipe" identity database using role-based access control, compromise of the overall system would still result in an attacker having access to the entire set of data.

  Having separate databases under separate administration - as is the status quo - not only makes an attacker's task more difficult in gathering a sufficient body of data to be usable for fraudulent activity, it also makes such an attack more obvious when it happens. Attempting to gather data on many citizens at once from the databases would produce a marked increase in network activity between the various databases, which could be trapped as an anomaly by suitably configured anomaly detection systems.

  However, if the data or subsets of the data are to be made available to appropriate organisations both inside and outside Government, then auditing of access to the data will constitute a significant issue. Not only will tens of millions of user accounts need to be created - especially if each citizen is to be granted access to their own records, and prevented from accessing another individual's records - but several thousands of roles and privileges will need to be created and mapped to these users. The audit records themselves will need to be managed securely, and will constitute a very large set of data to be mined for anomalous activity.

  What is the visible benefit to the Citizen?

  Finally, while a small majority of British citizens were in favour of a National ID card for a while, it is not particularly clear what additional benefit the citizen would receive as a result of having one - in addition to having an "incentive by imposition of fines and denial of access to currently available services" to obtain a card, it would be useful to make clear cases for "incentive by easier interaction with Government".

  In some circumstances, such as moving house, a traditional "stovepipe" database would mean that having an ID card would result in a citizen having yet another required transaction with Government to complete, at further personal expense, if a record of home address is mandated as part of the identity information stored within the identity database.

  However, if identity federation was used to join up the databases of different government departments, a citizen could see practical benefit from having a national ID card - changing home address would require a single notification to the Home Office, at which point the citizen's identity card, driving licence, medical records, council tax details, the V5 vehicle registration document(s) of their vehicle(s), etc could all be updated in synchrony. Similarly, many of the various forms of identification which have to be carried today (driving licence, etc) could be integrated into the one ID card - although passports are likely to remain separate entities, owing to the fact that their nature must be agreed upon with the ICAO.

  If the National ID Card also functions as a smartcard for the purpose of authentication to computers equipped with smartcard readers within a multi-factor authentication scheme, a citizen with a National ID card could potentially use the card to access a Government portal to change their personal details. Alternatively, even if the Government rather than the citizen is considered to have ownership and exclusive change rights to the citizen's identity data, such a portal could be used by a citizen to verify that the details held about them are correct, making compliance with the Freedom of Information Act easier in many cases.

  (2006-11-08 06:51:09.0) Permalink Comments [3]