How to Clone and Modify E-Passports

The Hackers Choice has released a tool allowing people to clone and modify electronic passports.

The problem is self-signed certificates.

A CA is not a great solution:

Using a Certification Authority (CA) could solve the attack but at the same time introduces a new set of attack vectors:

  1. The CA becomes a single point of failure. It becomes the juicy/high-value target for the attacker. Single point of failures are not good. Attractive targets are not good.

    Any person with access to the CA key can undetectably fake passports. Direct attacks, virus, misplacing the key by accident (the UK government is good at this!) or bribery are just a few ways of getting the CA key.

  2. The single CA would need to be trusted by all governments. This is not practical as this means that passports would no longer be a national matter.

  3. Multiple CA's would not work either. Any country could use its own CA to create a valid passport of any other country. Read this sentence again: Country A can create a passport data set of Country B and sign it with Country A's CA key. The terminal will validate and display the information as data from Country B.This option also multiplies the number of 'juicy' targets. It makes it also more likely for a CA key to leak.

    Revocation lists for certificates only work when a leak/loss is detected. In most cases it will not be detected.

So what's the solution? We know that humans are good at Border Control. In the end they protected us well for the last 120 years. We also know that humans are good at pattern matching and image recognition. Humans also do an excellent job 'assessing' the person and not just the passport. Take the human part away and passport security falls apart.

EDITED TO ADD (10/13): More information.

Posted on September 30, 2008 at 12:24 PM • 28 Comments


PhillipSeptember 30, 2008 12:40 PM

Couldn't we build a little intelligence into the terminal? We setup a field in the format that is country code The terminal understands certain CAs are authorized to sign passports for certain country codes. If the passport isn't signed by a CA authorized for that country code, it flags an error.

Not that bad, is it?

billbSeptember 30, 2008 1:00 PM

Wouldn't a multi-agency multi-CA solution for each country help quite a bit? I.e., DoD, DoE, DHS/INS, State, etc. all run a CA (and presumably all have slightly different security practices making hacking them all difficult). Then, either multiple certs are generated for each passport and some number of them have to agree on authenticity before the passport is accepted, or a shared-secret technology is used to generate the cert and used to verify its authenticity. The multi-CA-means-Iran-can-make-US-passports problem seems like a bit of a strawman.

Ben RosengartSeptember 30, 2008 1:08 PM

I think you're mistaken about the multiple-CA setup. A CA can be authoritative for just one part of the namespace. With the right schema design, one country would not be able to forge another's passports.

CerebusSeptember 30, 2008 1:15 PM

Read this sentence again: Country A can create a passport data set of Country B and sign it with Country A's CA key.

No. Read up on Name Constraints; path constructors can check for name space violations of this type and return path errors when they occur.

Rasmus FaberSeptember 30, 2008 1:21 PM

I do not recall the exact pki-setup, but the passports are certainly not self-signed. Each country has their own pair of cas: the Country Signing CA and the Country Verification CA. A specific inspection system implementation might of course accept passports issued by any ca, but I would not hope any such system is in actual use.

JD BertronSeptember 30, 2008 1:21 PM

Have you gone mad ?
In the same article you highlight how people are unreliable (bribery) and yet reliable for pattern matching.
Wouldn't cross-over(ed) CA's be better than 2 CAs, without the need for a row of people checking our passports ?

ThoriaSeptember 30, 2008 1:30 PM

Maybe the fundamental problem is that border control using passports is the wrong solution to a problem that is rooted in 18th century political structures. Not that I have a simple alternative.

Clive RobinsonSeptember 30, 2008 1:47 PM

@ Bruce,

"We know that humans are good at Border Control"

Actually they are not that good.

Shortly after 9/11 I traveled with a group of friends to one of thos countries where the hotel takes your passport (illegaly) for security checking etc.

On leaving she gave my pasport to somebody else and I got theirs because we where in a hurry neither of us actually looked in the passports.

We both got through check in flew landed in the U.K. at a time of high alert and both got through to landside without anybody picking up on the fact we had the wrong passports.

It was only a few weeks later on presenting documentation for another purpose was the fact the passport was in a different name that the error was noticed...

So no looking at a person and their passport photo is not a reliable way at all.

Clive RobinsonSeptember 30, 2008 2:01 PM

The BIG PROBLEM with these pasports is that you can change the contents of the chip memory.

So find another person who looks sufficiently like you and copy the contents of their passport into yours (easier now the passports have RFIDs in).

Half the time Passport control officers look at the screen not the passport so don't even notice the details inside don't match.

Recently the U.K. Started trials of software passport control...

You put your passport in the machine and look into the camera, face recognition software then decides if it's you or not...

I confidently expect "ID brokering" to become quite a lucrative criminal activity real soon...

Reliable ID managment is a very hard problem and throwing money and technology at it is not going to make it any easier any time soon.

RandallSeptember 30, 2008 2:23 PM

What about a PGP-like web-of-trust approach?

Britain's key is separately signed by the US, Australia, etc., or maybe even multiple CAs within each country. US terminals trust British passports because they're signed with a British key signed by the US CAs. British terminals trust Australian passports because they're signed with a key signed by the British CA. Not everybody trusts every CA, but everybody trusts *some* CA.

Smaller countries might not run their own full-blown CAs simply because they can't arrange direct verification of all hundred-something countries' passport-signing keys; Togo would trust that a passport chip is really Mozambique's because it's signed with a Mozambique key that's in turn signed by the US, Britain, France...

Finally, there's always the backstop of having passport terminals talk to databases of their own country or another: they could flag when a country key, while properly signed, has changed unexpectedly (SSH-style); detect when someone's using a passport that was revoked or reported lost; or react to any known breaches of/fraud involving particular CA or country keys.

AprotimSeptember 30, 2008 8:52 PM

I'm confused - where does it say that if you trust CA #1 for situation #1, you have to trust it for situation #2? Obviously Country A could make a passport that looks like Country B's but electronically validates as a Country A passport, but the mismatch between what it purports to be and what it authenticates as should flag suspicion.

On the other hand, a CA per country still leads to a single, attractive target for cloning that country's passports. Moreover, the difficulty of revocation and re-authorization of valid certificates make this problematic, but it doesn't make revocation any harder than it is now, and could make it slightly easier.

GarickSeptember 30, 2008 8:59 PM

@Randall, Sure a web of trust could work, but then each organization would need to keep and distibute this trust list. Although it may not seem very different this is exactly what a PKI bridge can do very well.

The bridge sets sane rules and revokes the certifications for anyone caught breaking them.

Paths built across the bridge to other CA's EEs are limited to names and extensions that are allowed by your cross-certification to the bridge and vise versa.

Your relying party's trust anchor points to your self-signed CA. Now, you can build paths of trust across the bridge safely.

This is a (mostly) solved problem. It is just under-deployed. Too many discussions about the color of the bike-shed and not enough painting.

--- The Basic Idea ---

[ Trust Anchor (self-signed CA) ]
[ policy CA ] -- cross certs -- [bridge CAs ] ...
[ Issuing CA ]
[ EEs ] (certs you issue)

RogerSeptember 30, 2008 10:44 PM

Clearly, making your own self-signed e-passport is far easier than forging a paper document, and so greatly lowers the bar for passport forgery.

So if it is true that there are e-passport readers out there that are accepting self-signed certs, that is catastrophically stupid and indicative of the general lack of security nous that has been evident in this whole process.

However, in the ICAO rules, readers are *NOT* supposed to accept self-signed certs. There is a multi-rooted, three level CA structure specified. THC/vonJeek has discovered an implementation flaw -- a severe implementation flaw! -- in at least one type of reader, but not a protocol flaw.

Congratulations to THC/vonJeek for finding this, and it is very important as showing the poor attention to security in the whole process. However the security flaws in the overall architecture -- and they do exist!! -- lie elsewhere.

RogerSeptember 30, 2008 11:13 PM

Some further comments:
ICAO's multi-rooted CA structure actually seems to deal reasonably well with "Ministry Of Truth's" points 1 and 2 about CAs. (When assessing it, bear in mind the special conditions applying to this structure: there will only ever be about 200 entities on the second level of the list, and they change very infrequently. This means it will be practicable, for example, for all transfers to be either performed, or at least later verified, by safe hand.)

"Ministry Of Truth's" point 3 is already addressed in existing certificate architectures. A mid-level CA cannot issue a certificate outside its own domain. A top level CA cannot issue an end use certificate, and if it makes up a fake mid-level CA to sign an end use certificate, that has no effect until it has been broadcast (giving the real mid-level CAs a chance to cry foul.)

"Ministry of Truth" also says:
"We know that humans are good at Border Control. In the end they protected us well for the last 120 years."

This is highly debatable. Increasing ease of international travel, economic pressures to accelerate passage of people through borders, and economic incentives to cross borders illegally have all caused greatly declining effectiveness in traditional border control measures. Part of the problem is that previous passport technology was antiquated and fairly easy to fake. Putting digital certificates in passports was a good idea. How they have gone about it is terrible.

"We also know that humans are good at pattern matching and image recognition. Humans also do an excellent job 'assessing' the person and not just the passport. Take the human part away and passport security falls apart."

Absolutely, but the e-passport does not do that. There will still be passport officers. Notice that the biometric identifier in e-passports -- a photograph -- can only be reliably verified by a human being. (Of course, if your country does start to consider automatic face recognition, do please bombard your government representative with all available information about the extreme unreliability of that technology!!)

Incidentally, the wily immigration officer is also a fatal flaw in the self-signed cert attack. Already today, at major airports there are expert document examiners on hand, and immigration officers will send a passport to them if suspicion is sufficiently aroused. But they cannot do this very often because it takes quite a while.

In the case of an e-passport, it would be trivial to display a listing of all fields from the chip. Even if a defective reader accepted a self-signed cert, an immigration officer who bothered to examine the details could quickly discover the forgery: go straight to gaol, no document examiner required. (And yes, immigration officers are generally smart enough to understand PKIs, at least around here; it is a fairly technical job.)

vwmOctober 1, 2008 3:03 AM

"Country A can create a passport data set of Country B and sign it with Country A's CA key."

Well, still better than the current "anybody can sign any country's passports"-situation, isn't it?

It is not that difficult to compare the passport's country information to the certificate's country information and to reject mismatching ones.

SparkyOctober 1, 2008 3:53 AM

@Clive Robinson: using software to compare the photo with the image of the person from a camera sounds like a very bad idea. There is no way this software is not going to be leaked, and when it is, criminals basically have an "authentication oracle". They can tune their appearance trough trial and error until the software accepts them a the rightful owner of the passport.

Nomen PublicusOctober 1, 2008 4:54 AM

Regarding using a CA and digital certificates... I immediately wonder what happens if someone manages to revoke a countries certificate? You can't not have a revocation mechanism but will the "powers that be" remember protect that facility?

It doesn't even have to be a malicious action, this year there have been at least a couple of well known companies who managed to forget to renew their certificates.

Just imagine what would happen in airports when a perfect denial of service attack is made against tourists?

AndyOctober 1, 2008 5:34 AM

I have one specific story (or example if you generalise it) why passports aren't good for authenticating people.

If you gather 20 people (say all one gender) and their passports and then give one of them the task to hand back the passports to the corresponding persons. My hypothesis is that in the majority of the cases you'd end up with at least one mix-up.

I have tried the scenario at the Pentagon where one unfortunate marine had to hand back the passports to a group of visiting soldiers from a different country.

Just looking at name and pictures he even managed to mix up female and male passports (as the names did not make sense to him).

Like other commenters have mentioned, travellers mixing up their passports are common and (in my experience) is usually foiled by the traveller himself rather than the passport controller.

gregOctober 1, 2008 7:51 AM

One problem with CAs that everyone seems to be ignoring is revocation.

If the US root key is compromised, do we need to reissue all the passports that used the key? What about all the people that are already abroad? etc....

In practice even if there are revocation procedures they are rarely implemented properly because its just so impractical ( after key revocation passports coming up as a fake is *normal*). Just look at CSS and the HD leaked keys for real world examples.

msmithOctober 1, 2008 9:53 AM

It immediately occured to me that a Byzantine Generals solution connecting independent CA's is one possibility. A quick search turned up the link - though they seem to be replicated rather than independently developed.

JimOctober 1, 2008 12:53 PM

Did anyone else read Secrets and Lies? Why do we trust technology so much? So we can hire airport screeners at minimum wage and provide them with minimum training.

There are things in neuro-linguistic programming that would help sharp airport screeners with spotting suspicious persons.

But there are other problems too. Whereas Detectives may have NLP and use it all day, their day is varied. How do you keep a screeners job interesting, or at least, what else could they do when they are on frequent breaks.

As usual, the technology is the easy and least expensive part of any effective system.

It seems like we have ignored the advice of Einstein "Make everything as simple as possible, but not simpler." and also ignored his definition of insanity: "doing the same thing over and over again and expecting different results."

Effective screening is not a simple, low-cost process, and though it involves technology, it involves a lot of other things too.

You can substitute a lot of other things for the word screening above.

Peter PearsonOctober 1, 2008 7:24 PM

Bruce did THC Blog a great favor by truncating the quotation just before this line:

"Never let a computer do a job that can be done by a human."

That's a pretty silly rule, don't you think?

AdrianOctober 2, 2008 9:48 AM

"Country A can create a passport data set of Country B and sign it with Country A's CA key."

Isn't this defeated by just checking that the signing key matches a known set for Country B? (and discovering that Country A signed a set of data that claims to be from Country B)

kLOctober 2, 2008 9:56 AM

Here's an idea:
Sign passport with 3 different CAs and require that at least 2 of them must be valid.

This way when one CA is revoked, there's still time to re-issue passports without disruption.

These CAs can be under control of completely differnt organisations and people, so this doubles amount of corruption/bribery needed to forge a passport or cause denial of service.

MOctober 2, 2008 10:00 AM

I wonder if it occur to people that the biggest user of fake passports are the different intelligence / security agencies of different countries trying to get their people in somewhere....

JohanOctober 6, 2008 5:09 PM

The EU standard for machine readable passports will be mandatory from 2009-06-26. It is built as non-X509 PKI with short lifespan of end entity certificates to "work-around" revocation issues. The URL is for the doc of the implementation used in EJBCA (an LGPL heavy duty CA).

tommyDecember 6, 2008 3:54 PM

Pls tell me how to get a fotocopy of another person's passport. An individual committed a crime against me and I am trying to locate him. Is there an agency I can contact to subpeona a copy of the individual's passport?

Thank you.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Resilient Systems, Inc.