Rowland Watkins

Exploring the use of Web and SOA technology in Hong Kong

On Exploiting ePassport Vulnerabilities

Posted by Rowland Watkins on 08 August, 2008 at 12:49

The Times, Engadet, and otherbloggers highlighted apparent vulnerabilities in the current ePassport initiative, run by the International Civil Aviation Organization.

The crux of the issue is that apparently, Jeroen van Beek (University of Amsterdam) and a colleague were able to copy an ePassport, modify biometric (facial image and personal data) data that is not related to the passport holder, and create a new passport (from a suitably appropriated blank). Such a fraudulent passport would pass through border security software recommended by the ICAO.

Unfortunately, The Times incorrectly attributes the ability to clone, create and validate a new ePassport solely on the security of the RFID microchip (which does require an encrypted connection to retrieve data). Based on The Times report, I believe that the real issue is that ePassports are susceptible to classic flaws in PKI processes and procedures.

This post attempts to deconstruct van Beek’s approach and explain how the ICAO Public Key Directory is where most of the problems with ePassports lie.

Validating an authoritative ePassport

Reading from various online resources (including The Times article and ICAO website), plus my PKI knowledge, here’s a rough diagram that describes the life of an authoritative ePassport from creation to validation:

Steps 1-4 essentially setup the PKI to be used by an ePassport authority
  1. UK creates its own Country Signing Certificate Authority and CRL
  2. UK creates one of many Document Signing Certificates
  3. UK Country Signing CA signs each UK Document Signing Certificate
  4. UK negotiates with PKD to have all Document Signing Certificates, Country Signing CA, and CRL added to the PKD. PKD then serves as a root of trustfor all future ePassport validation
Steps 5-8 describe a traveller requesting and using their ePassport
  1. Darth Vader (a fictional traveller) applies for an ePassport so he can travel to France for a holiday
  2. UK Passport Authority checks his identity thoroughly. They create and sign his new ePassport
  3. UK Passport Authority attach the Document Signing Certificate used to sign Vader’s ePassport
  4. Vader buys his Eurostar (passengers are pre-authorised in St Pancras – too boring) EasyJet ticket and travels CDG
Step 9 shows verification against the PKD
  1. At CDG, French Border Control uses the Golden Reader Tool to validate Vader’s ePassport against the populated PKD
Golden Reader Tool should check the following (non-exhaustive):
  1. Vader’s ePassport was signed by a known UK Document Signing Certificate (added in Step 4)
  2. The UK Document Signing Certificate was signed by the UK Country Signing CA (added in Step 4)
  3. The UK Document Signing Certificate has not been added to the UK Country Signing CA CRL. The CRL must be kept up-to-date!

As can be seen from this lengthy set of steps, correct identification of certificates added to the PKD is critical. Accidentally adding the wrong certificates (Document Signing, Country Signing CA or CRL), could either cause entry refusal, or worse (if there is insider collusion), admit nefarious visitors.

Copying an ePassport

Let’s face it, Darth Vader is not likely going to be able to get a real ePassport from the UK Passport Authority – he’s the Dark Lord of the Sith. Following van Beek’s idea, he thinks he can copy someone elses ePassport, then create his own with bogus details.

Here’s something interesting about data: if you can read it, you can copy it!

Copying data from an RFID enabled passport is not new as can be seen here. Lukas Grunwald used publicly available ICAO standards.

If you have a suitable RFID card reader, you can get all the data off your ePassport using software from RFIDiot. The cheapest reader is something like £5. Adam Laurie also has a non-exhaustive list of known EU government signing certificates and X.500 Distinguished Names for their corresponding CAs.

Once Vader has copied the data from his chosen ePassport using ICAO standards, he is able to manipulate it as the Dark Lord wishes…

Creating a Sith ePassport

Here’s a rough recipe for Vader to use to create his new ePassport that satisfies Jeroen van Beek’s exploit:

  1. Get access to a blank ePassport – there should be plenty available after this recent robbery
  2. Write ICAO standard data to new ePassport
  3. Sign data and write signature and Document Signing Certificate to ePassport

For a comprehensive explanation of PKI, X.509 certificates, digital signatures, roots of trust, and Certificate Revocation Lists, please consult Wikipedia – it’s pretty thorough.

Signing a Sith ePassport

This is where things become a bit more tricky. The Times article notes:

“The Home Office has always argued that faked chips would be spotted at border checkpoints because they would not match key codes when checked against an international data-base.”

In this context “key codes” = UK Document Signing Certificate, UK Country Signing CA, and CRL, stored in the PKD. Basically, the UK Government believes wholeheartedly that PKI will protect ePassports and completely ignore the human factor in PKI management.

While The Times article does not explicitly state it, I’m betting van Beek created his own “key codes”. It is highly unlikely that Jeroen van Beek broke or faked the signatures of the original ePassports. UK and New Zealand Signing Certificates found at RFIDiot show the use strong hash functions (SHA256).

If Vader really wants to subvert the system to go on holiday, he needs to create is own “key codes” and add them to the PKD. In this case, he’ll be using OpenSSL, a freely available tool for basic PKI management:

  1. Create a new Sith Country Signing CA
  2. Create a new Sith Document Signing Certificate
  3. Write ICAO standard data to new ePassport
  4. Sign data with Sith Document Signing Certificate and add to ePassport
  5. Update PKD

Please note that Vader will not be silly enough to show that the Sith Country Signing CA and subsequent Document Signing Certificates are of Sith origin. This is the nature of the Sith. Vader will simply create his certificates to look and feel like the UK (or another country) certificates. Unless you know the real provenance of a certificate, you cannot tell the difference.

Updating the PKD is the hardest part in all this. Later, we’ll take a look at the PKD and see whether it is realistic for Vader to perform a bit of Social Engineering) to get his new Sith certificates recognised internationally.

Validating a Sith ePassport

The diagram below summarises what Vader has achieved:

Steps 1-4

As we noted earlier, adding Sith certificates to the PKD is no easy feat. Step 4 is therefore problematic – Dark Force tactics are required here.

Steps 5-8

Nothing difficult here. Vader’s use of RFIDiot and OpenSSL makes copying, creating and signing his new ePassport a breeze.
He’ll go by RyanAir this time to CDG.

Step 9

Assuming Vader has successfully added his Sith certificates to the PKD, the Golden Reader Tool should let Vader through French Border Control to visit the Eiffel Tower.

Updating the Public Key Directory

Question: Is it realistic for Vader to add his Sith certificates to the PKD?

Answer: To some extent, yes. But Vader will not be able to do it on his own. The ICAO apparently have several security provisions to protect the PKD from unauthorised manipulation. But not everyone is confident in the ICAO.

The Public Key Directory is an LDAP server that contains the Document Signing Certificates, Country Signing CAs, and CRLs for participating countries in the ePassport initiative. It is unclear from public information what the access control policies are for this repository, but it is apparently inadequate enough for the German government to complain. Incidentally, the PKD is operated by a Singapore-based company, Netrust.

According to the ICAO in March 2007:

“The PKD currently holds Document Signer Certificates and Certificate Revocation Lists that have been validated against the respective Country Signing CA Certificates, and these are now available for secure download by the other participating States.

The security surrounding the PKD operation is significant. The Montreal infrastructure of the PKD is located in a purpose built vault within the ICAO offices. Access to the vault is limited to a small number of suitably cleared staff of ICAO and of the service provider who constructed the system, Netrust Pte Ltd.

The vault features layers of physical controls and monitoring. Once access is gained to the vault, system controls ensure that only authorised operators can access the system and that their work in the system is comprehensively logged both on the system and through CCTV.”

The German Government complained about this setup in July 2007:

“You have to store a huge number of preverified (certificates) securely in your inspection systems. Imagine what happens if someone manages to add his own (certificate),” he said. “Even worse, there’s the idea that all information taken from the directory already is preverified, and, therefore, receiving states do not have to verify the (certificates). That’s a real security nightmare.”

The UK and France have proposed cross-certification of Document Signing Certificates. This would require multiple bilateral agreements between participating states, completely nullifying the need for the PKD!

Potential Attacks on PKD

Based on the above information and other precedence, Vader could do one or more of the following:

  1. Vader could remotely update the PKD.
  2. Vader pretends to be the UK Country Authority, wishing to update the UK Country Authority CA and add a new Document Signing Certificate
  3. Vader could bend ICOA employees with access to the PKD to his will (e.g. give them a lot of money)

The first approach is unlikely as network access would be heavily protected.

Options 2 and 3 are more feasible given known successes with social engineering. With Option 2, triggering an update to an existing Country Signing CA could be used to introduce an nefarious one. If you’ve ever looked at the list of CAs in your web browser, you’ll see that it is VERY difficult to distinguish two CAs with the same Distinguished Name. In fact, the only reliable way to identity, it to compare the each signature and what is known as the Subject Key Identifier – just hope you reliably recorded then when adding to the PKD.

Option 3 is also feasible – we’ve seen disgruntled employees deny access to the entire San Francisco IT network. There’s also the German Government purchasing confidential information on apparent tax evaders in a Lichenstein bank.

Summary

Jeroen van Beek’s claim that he and a colleague cloned and created a new ePassport using available tools is viable, even if he was not able to test in a live experiment. The main problems behind the ePassport initiative lie in the Public Key Directory and the security surrounding it. The German government have complained about its security, and apparently only 10 out of 45 countries are using it.

My hastily conceived scenario with Darth Vader and his Sith certificates, shows that van Beek’s ideas could extended to real fraudulent ePassports, but that the PKD would be a challenge to subvert successfully, without ICAO authorities becoming aware.

Please note that it is unclear how Golden Reader Tool was configured when van Beek performed his experiment for The Times. van Beek claims that he was able to validate is newly cloned ePassports with Golden Reader Tool. Unfortunately, Golden Reader Tool is no longer available as a public download from Secunet so I cannot confirm configuration options. I am assuming that the Golden Reader Tool can be configured to check the Country Signing CA and CRL locally. The non-use of the PKD suggests that CA validation was “local” to the machine running Golden Reader Tool and CRL checking was either “local” with an empty CRL or disabled.

Credits

Special thanks to George Lucas for conceiving Darth Vader and the Sith. Many thanks also to olde_fortran for the Lego stencil set.

Hierarchy: previous

Comments

There are 0 comments on this post. Post yours →

Post a comment

Required fields in bold.