Rowland Watkins

On Exploiting ePassport Vulnerabilities

rowland@rowlandwatkins.com (Rowland Watkins) — Fri, 08 Aug 2008 20:49:00 GMT

The Times, Engadet, and other bloggers 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

UK creates its own Country Signing Certificate Authority and CRL
UK creates one of many Document Signing Certificates
UK Country Signing CA signs each UK Document Signing Certificate
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

Darth Vader (a fictional traveller) applies for an ePassport so he can travel to France for a holiday
UK Passport Authority checks his identity thoroughly. They create and sign his new ePassport
UK Passport Authority attach the Document Signing Certificate used to sign Vader’s ePassport
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

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):

Vader’s ePassport was signed by a known UK Document Signing Certificate (added in Step 4)
The UK Document Signing Certificate was signed by the UK Country Signing CA (added in Step 4)
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:

Get access to a blank ePassport – there should be plenty available after this recent robbery
Write ICAO standard data to new ePassport
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:

Create a new Sith Country Signing CA
Create a new Sith Document Signing Certificate
Write ICAO standard data to new ePassport
Sign data with Sith Document Signing Certificate and add to ePassport
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:

Vader could remotely update the PKD.
Vader pretends to be the UK Country Authority, wishing to update the UK Country Authority CA and add a new Document Signing Certificate
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.

Cardspace Pharming Vulnerability Discovered

rowland@rowlandwatkins.com (Rowland Watkins) — Sun, 01 Jun 2008 03:56:00 GMT

It appears that Windows Cardspace is susceptible to pharming techniques similar to threats that exist in OpenID. According to Intology. It’s always best to go to the source of apparent exploits; there’s an overview here, and the actual paper: On the Insecurity of Microsoft’s Identity Metasystem CardSpace.

While this exploit is a slight headache for Microsoft, it is only as effective as the validity of the SAML token minted by the Cardspace token issuer. All the token issuer needs to do is change their policy for the validity period to alter the risk period. What would be more worrying is if the fraudulent web server was capable of minting SAML tokens. I don’t know how easy it is to be an issuer, so this may not be practical.

It’s interesting to note that the exploit procedure requires restarts to the fraudulent web server. While this in itself can be automated, it does limit the rate of successful pharming incidents if the web server is unavailable. Virtualisation could alleviate this somewhat, creating a farm of pharming servers.

There’s also a mention of so-called Extended Validation (EV) Certificates and the question of whether such certificates (and corresponding browser support) can help tackle such attacks. As the researchers correctly point out, a usability study by Standford University and Microsoft has shown the introduction of EV Certificates in IE 7 has not significantly affected a users’ ability to discriminate between valid and fraudulent web pages; user training remains the best way highlight the on-going risks to users.

I haven’t tried the exploit against Microsoft’s own Cardspace provider, but I might evaluate this myself to see just have practical this pharming technique is.

Clifton's Enterprise IT Security Forum

rowland@rowlandwatkins.com (Rowland Watkins) — Mon, 19 May 2008 06:43:00 GMT

The other week I was lucky enough to attend a seminar hosted by Cliftons on Enterprise IT Security. I’ve been to several events hosted by Cliftons so far, and I have to say that all have been very worthwhile.

There were three guest speakers, each of whom provided key insights and good business practises on range of topics: Ken Ume (Thales e-Security) – authentication, Jason Healey (Goldman Sachs) – cyber attacks, and Thomas Parenty (Parenty Consulting) – secure communication on the move.

Ken Ume | Authentication: Essential Part of Everyday Life

Ken provided a good overview of authentication schemes as used in eCommerce by consumers and business. His argument is that increasing scales of communication has meant that trust has gradually decreased, since B2C can be achieved without either party meeting face-to-face. This has been compounded by consumers having access to more information and being more informed.

Authentication is an interesting problem with a raft of solutions out there, some based strong (PKI-based), others not (OpenID-based). Accessibility is a real concern, especially when faced with the so called digital divide. If an authentication scheme (or process) is inaccessible, people and those in business will bypass the scheme, rendering it useless. As Ken rightly stated, open standards are essential to overcoming business challenges, not to mention auditing.

Jason Healey | Caught in the Middle: Asia Business and Cyber Attacks

Recent Internet activism has highlighted the increasing number of instances where businesses and other organisations are being targeted based on [primarily] political agendas. Two examples that Jason cited were previous defacement of the AIPAC website and protests (online and outside shops) against Carrefour. He argued that there appears to be a “China ceiling”, based on analysis that many of these attacks (at least against Carrefour) originate from mainland China.

The talk’s catch phrase “stuck in the middle” refered to whether these increasingly popular cyber attacks are specific (as in the case of AIPAC), or “guilty by association” in the case of Carrefour, since it is a French brand (fallout over disruption of the Paris leg of the Olympic torch relay). In the previous Web Wednesday meetup, there was a related presentation on Chinese activism and propaganda after the CNN gaff.

Thomas Parenty | Staying Connected Securely: A Guide for the Traveling Executive

Thomas presented the image of a travelling businessman, planning the next M&A or releasing the next product. During his travels, the businessman uses airport Wi-Fi, hotel networks and business centre computers. In each case, unless security is considered, emails can be read, resulting in the M&A failing to a rival or the product details being revealed to another competitor.

Roving security is obviously a big problem, but can be mitigated with cryptographic tools including SSL/TLS (as stated by Thomas). Other techniques such as two-factor authentication (let’s not worry about some of the associated issues highlighted by Bruce Schneier) could also be considered.

There was a short question and answer session, but it was unfortunately rather short – free food on the horizon! There were a few questions, but none from business leaders relating their own experience, which is a shame.

Google App Engine vs. AWS

rowland@rowlandwatkins.com (Rowland Watkins) — Wed, 30 Apr 2008 23:03:00 GMT

Is the Google App Engine a viable competitor to the current generation AWS?

To first approximation, I would argue no. As a Python (for the time being) web application platform, Google App Engine provides a highly scalable sandboxed environment that reduces what a developer can do with the underlying platform. In addition, the Google App Engine is a single Software as a Service (SaaS) platform. Developers and businesses cannot reuse distinct services for deploying OS images, storing data, creating complex business processes.

AWS on the other hand, is a low-level middleware infrastructure for developing new platforms. It provides primitive services for storage (S3), databases (SimpleDB), queuing (SQS), and computation (EC2) that enable high resilience and scalability. Consider Morph eXchange which offers Rails app hosting as a SaaS in a very similar fashion to the Google App Engine. And guess what, it actually runs on AWS! Unlike Google App Engine, however, Morph appears to allow businesses a free-er hand in their development decisions, permitting a full Ruby and Rails environment, together with managed access to S3.

The clear separation of duty in AWS is what gives it the edge over Google App Engine. EC2 allows businesses to deploy complete OS images from S3 to produce novel environments such as Morph. It gives business more control on how to put together business processes which currently isn’t possible with the Google App Engine.

Google App Engine is still in closed beta so it’s early days. It’s possible it will pick up and enable business to do things not possible in AWS. Then we would have competition and even more innovation at our finger tips.

First encounter with the Google App Engine

rowland@rowlandwatkins.com (Rowland Watkins) — Wed, 30 Apr 2008 20:18:00 GMT

Google have taken a first step by exposing part of their infrastructure capability through their new [invitation-only] Google App Engine. It’s a Python-based infrastructure that provides access to many core services using by Google – more information here.

While I haven’t been lucky enough to get to the head of the waiting list, I have played around with the SDK released by Google, which offers a complete development environment, including a development server. I haven’t utilised all interfaces yet, just looking at what Google offers in terms of interfaces for remote connections to other WWW services.

Google have been quite sensible in creating a sandbox for running potentially hazardous third-party developer code, removing access to many core Python modules that use C interfaces. This is OK, until you want to do something exciting like HTTPS GET – urlfetch will perform the GET, but has no way of validating the server. That’s not too bad, but it’s not clear if urlfetch even provides the ability to access the TLS session and for the developer to validate the certificate themself – seems like a valid alternative.

It would be nice if Google at least loosen the rope a little more to provide full TLS functionality. Of course, what I really want to do is TLS with mutual auth – that should be good fun. In the mean time, I’ll see what I can do with other TLS toolkits that run in pure Python.