Feeds

ID cards: a guide for technically-challenged PMs

Save us all billions - don't do it, Tone...

  • alert
  • submit to reddit

Securing Web Applications Made Simple and Scalable

Biometrics work

Did we ever say they didn't? In the shape of fingerprints, biometrics have provided a highly accurate mechanism for identifying criminals for many years now. In this role they clearly work, and their accuracy has contributed heavily to the general viewpoint that fingerprinting must therefore surely be a kind of gold standard for identity. But think - what mechanisms are used and what data is required in order to match a suspect up with the scene of the crime? Well, first of all, you need a crime at which a fingerprint is left - note that this will in most cases be absent when a fingerprint is being used to check identity, but a databank containing the relevant fingerprint alongside hundreds of millions of others will exist.

In the case of the scene of the crime fingerprint, the matching is done against a database of known suspects and criminals, and may also be compared with the fingerprints of specific suspects. The matching process can be time-consuming and can involve a considerable amount of manual effort, but this is acceptable on the basis that the search being conducted is limited and relatively targeted. But on a wider, a far, far wider basis, this all gets complicated.

The fingerprints you leave vary to an extent, and although this won't save you if you left them at the murder scene, it can most certainly confuse automated systems. Obviously, the checking of fingerprints that are being used as the standard to validate ID documents has to be automated. You could leave a different print depending on the surface you touch, what you've been touching recently, how clean your hands are, or what you've been working with.

Bricklayers, apparently, tend to have rather faint fingerprints. So you can maybe think of fingerprints as being a little bit analogue, variable enough to confuse machines, although still static enough to be readily-identifiable by human experts. It may be significant that already, just a few months into its introduction of fingerprint checking, the US government has started trying to define standards of compatibility for fingerprint reading equipment. This may be entirely because it's simply concerned about incompatibility, but could also be flagging growing matching problems.

Ultimately these can probably be licked by the application of computing power, but this is not the only difficulty. Let's assume we have a passport or a driving licence with a fingerprint on it, and a bearer we wish to match up. The simplest way to do this is as a local transaction. You have what ought to be a clear and standard print on the passport, you have what ought to be a pretty effective machine for reading fingerprints (sole purpose of machine - if it is ineffective, you have a big problem with your supplier), and you have a finger. Should be easy, right?

Whose identity is it anyway?

Well it is, because all you're doing is checking two things. First you're checking that the finger of the bearer is the finger that left the print in the passport, which ought to be easy, and second, you're checking that the passport is genuine. Which is maybe harder. Virtually all countries have some level of problem with forged and falsely obtained passports. In the case of forgery it's a continual battle to make it harder (and actually, biometrics are a pretty good addition to the armoury in this area, because at this level they're relatively cheap and effective). Falsely obtained passports are however a lot trickier.

Biometrics on a document can by themselves only provide conclusive proof that the person presenting the document is the person whose biometrics are on the document, not who that person is. If you wish to be absolutely certain of this, then you need to be absolutely certain of the integrity of the issuing authority.

In the UK at the moment, we can really only go as far as saying there is a high probability that the integrity of the Passport Office has not been compromised in the case of a particular document, and that there is a fairly high probability that the integrity of the DVLA has not been compromised with respect to a drivers licence. But it happens in both cases, and while steps are slowly (very slowly) being taken to increase the confidence we can have in these documents, only a fool would say fraud can be absolutely eliminated.

It's no accident that passport and drivers licence are being used as the cornerstones of the UK's universal identity card scheme, but beyond that we have a significant percentage of the population which will need to be added, without the creation of new false identities, and the integrity of the system as a whole will only be as good as the integrity of the authorisation used for this part of the population. Although most of these people will have some other kind of identifier, such as a national health or national insurance number, these are already too compromised to provide a solid basis for identity.

The current controversy in the UK over the entry of economic migrants also provides us with an example of how the overall integrity of a national ID system can be compromised. The numbers involved are apparently small in this case, but nevertheless a system which is designed to make decisions on the basis of validated data (in this case, concerning the subject's identity, resources and business plans) has been compromised by the rubber-stamping of applications based on fraudulent data.

This route could have been used to convert false ID into legitimate UK ID. In this case the loophole appears to have been created by the operators (it's not yet clear at what level) overriding control systems in order to deal with backlogs. All large-scale data processing operations are vulnerable to this, and it would be reasonable to presume that large-scale ID data processing systems will at least initially introduce many vulnerabilities of this kind.

The smart choice: opportunity from uncertainty

More from The Register

next story
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
Manic malware Mayhem spreads through Linux, FreeBSD web servers
And how Google could cripple infection rate in a second
How long is too long to wait for a security fix?
Synology finally patches OpenSSL bugs in Trevor's NAS
Don't look, Snowden: Security biz chases Tails with zero-day flaws alert
Exodus vows not to sell secrets of whistleblower's favorite OS
Roll out the welcome mat to hackers and crackers
Security chap pens guide to bug bounty programs that won't fail like Yahoo!'s
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
Researcher sat on critical IE bugs for THREE YEARS
VUPEN waited for Pwn2Own cash while IE's sandbox leaked
prev story

Whitepapers

Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.