Epassport - SoftwareSecurity1 - 2

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 50

e- passports

Erik Poll

Digital Security Group


Radboud University Nijmegen
overview

• e-passports
• functionality and
security mechanisms
• problems, so far
• future

2
e-passports

• e-passport contains RFID chip / contactless


smartcard
– in Dutch passports, a Java Card
• chip stores digitally signed information:
– initially just facial images (photos)
– soon also fingerprints
– later maybe iris
• aka biometric passport or MRTD with ICC/chip

• introduction pushed by US in the wake of 9/11


– to solve what problem??
• international standard by ICAO (International
Civil Aviation Organization, branch of United
Nations) e-passport logo
3
Protocols & standards

ISO 14443
• defines physical communication for RFIDs
ISO 7816
• originally developed for contact smartcards
• defines standard APDU commands & responses,
ICAO  standard for e-passports
• defines specific IS0 7816 commands and
responses for passports
additional EU standards
• standardise optional parts of ICAO specs
& fix timeline
• additional advanced secuity mechanisms on top of ICAO

4
National id-cards & terminology

• Nederlandse Identiteitskaart (NIK) conforms to the same


ICAO specification

NB possible confusion
• eNIK is a future extension of NIK,
with digital signature capability
• MRTD = Machine-Readable Travel Document
just has Machine (OCR) Readable Zone,
the MRZ, but need not contain a chip
ie. e-passport = MRTD + chip
MRZ
5
European Electronic Passport

• Council decision of 13 December 2004


The facial image will be required at the latest 18 months,
– the fingerprints will be required mandatory at the latest
36 months
after the date of adoption of technical specifications
necessary for the implementation of the Regulation
• Facial images: deadline 28 August 2006
• Fingerprints: deadline 28 June 2009
– protected by additional security mechanism, extended
access control
• Participants: all members except UK, IRL, NOR

6
e-passports & authentication

• authentication of data
• authentication of the chip
• authentication of the terminal
– why? how?
• authentication of the passport holder
– how?
• passport data: age, height, gender,...
• facial image, fingerprint, iris
• signature

7
Biometrics to authentication passport holder

• Facial image (DG2, ISO 19794-5)


– JPEG or JPEG2000 image
– Basic, Full Frontal, Token Image
– Feature points (e.g. eyes)
• Fingerprint (DG3, ISO 19794-1)
– Uncompressed, WSQ, PNG, JPEG or JPEG2000
– How to indicate the fingerprint cannot be enrolled (no DG3,
empty DG3, no template), how to store 2 fingerprints (2 images,
2 templates)
• Iris image (DG4, ISO 19794-6)
• NB one would prefer not to store the raw biometrics, but
some (hash of) derived info. Why? How?

8
Security mechanisms

• Passive Authentication (PA) ICAO


– digital signature on passport data on chip mandatory
• Basic Authentication Control (BAC)
ICAO optional,
– access control to chip, to prevent EU mandatory
unauthorised access & eavesdropping
• Active Authentication (AA)
– chip authentication ICAO optional
• ie prevent cloning
• Extended Access Control (EAC) EU only, mandatory for
– chip and terminal authentication 'advanced' biometrics,
ie fingerprint & iris

9
Passive Authentication

• passport chip consists of 16 data groups (DGs)


– DG1 MRZ
– DG2 face
– DG3 finger
– DG4 iris
– ...
– DG15 Active Authentication
– ...
and a security object SO,
– signed hash values of the data groups
• To check the signatures, terminal needs country signing
certificates
• Passive Authentication mandatory on all e-passports

10
Basic Access Control (BAC)

• Contactless interface is both advantage and disadvantage


• BAC allows to read the data only after reader authentication:
– reader proves knowledge of the MRZ of the passport
• The authentication key is derived from document nr, date of
birth, date of expiry
• BAC is ICAO optional (recommended) feature, in EU
mandatory
• Interoperability issue
– How to find out the passport is BAC-protected?
→ try & you find out

11
Basic Access Control (BAC)

protects against unauthorised access Machine


and eavesdropping Readable
Zone
optically read MRZ

send MRZ

receive additional info

encrypted

12
BAC details

• Kseed derived from MRZ

• 3DES keys KENC and KMAC derived from Kseed


– KENC = first 8 bytes of HASH(KNseed , 0x 00 00 00 01)
– KMAC = first 8 bytes of HASH(KNseed , 0x 00 00 00 02)

• Terminal (IFD) and card (ICC) both generate


– 8 byte randoms RNDIFD , RNDICC
– 16 byte randoms KIFD , KICC

13
BAC details
• IFD → ICC : GET_CHALLENGE
• ICC → IFD : RNDICC
• IFD → ICC : MUTUAL_AUTHENTICATE( EIFD || MIFD)
with S = RNDIFD|| RNDICC|| KIFD
EIFD= Enc (S,KENC), MIFD= MAC (EIFD,KENC)
• ICC checks MAC and computes S, and hence RNDIFDand KIFD
• ICC → IFD : EICC || MICC
with R = RNDIFD|| RNDICC || KICC
EICC = Enc (R,KENC), MICC = Enc (EICC ,KMAC)
• Both calculate new Kseed = KIFD KICC
and derive SKENC and SKMAC for secure messaging

14
Alternative: Faraday Cage

• protects against unauthorised access, but not


eavesdropping
– used in US passports, initially instead of BAC

15
Active Authentication (AA)

protects against passport cloning (which BAC doesn't)


ie authentication of the passport chip
public key, signed by government (DG15)

send challenge

prove knowledge of
corresponding private key

16
similarity with EMV

• ICAO passive and active authentication similar to


EMV static and dynamic data authentication, resp.

17
possible drawback of AA: challenge semantics

• passport chip that supports AA will sign any challenge


• terminal could choose challenge c with some semantics
– eg. c = Sign(SKterminal, IDpassport ++ date ++ location)
– card replies Sign(SKpassport, c)
• can be useful - eg unfakeable log of entry to the country –
but do we want it?
– NB AA is – and should of course be - protected by BAC
• This can be prevented by not using a challenge signed by an
asymmetric key, but using assymmetric crypto to establish a
shared secret symmetric key that is used for MACs
• as in EAC

18
Different ways to do authentication

1. Shared key (symmetric or assymmetric, possibly diversified)


• A -> B : Encrypt(K, random || idA)
• B -> A : Encrypt(K, random || idB)
1. Cipher-based authentication using public keys
– A chooses random key K
– A -> B : Encrypt(PKB, K)
– B -> A : MAC(K, idA || idB)
1. Signature-based authentication
– A -> B : challenge
– B -> A : Encrypt(SKB, challenge || idA || idB)

Challenge semantics only possible with 3, because


signature in 3 requires assym. SKB key that only B has

19
Extended Access Control (EAC)

includes authentication of terminal by passport


• why would we want this?
– leaking privacy-sensitive information, eg at hotel check-in
– esp fingerprint & iris
• how would we do this?
– some terminal certificate
– ISO 7816 Card Verifiable (CV) certificates used rather than
X.509 public key certificates.
• what are problems with this?
– certificate revocation hard to realise
• how do you revoke a terminal certificate on all passports?
– certificates for short periods
• passport does not have time to check certificate expiry
– chip can only record date of last transaction

20
Extended Access Control (EAC)

Two phases

• Chip Authentication
– replaces AA
– starts Secure Messaging (SM) with stronger keys

• Terminal Authentication
– uses traditional challenge-response:
– terminal sends certificate chain to chip
– chip sends challenge
– terminal replies with signed challenge

21
Extended Access Control

Chip Authentication
• chip -> terminal: PKpassport
• terminal chooses ephemeral DH key pair (SKtemp, PKtemp)
• terminal -> chip: PKtemp
• chip and terminal compute shared symmetric key K
– K = KA(SKpassport,PKtemp)=KA(SKtemp,PKpassport)
with derived session keys for encryption Kenc and MAC Kmac

22
• Having the chip authenticate terminal opens up further
possibilities, eg
– updating data on chip
– uploading visa & travel records
but so far the passport does not support any writing of data
after personalisation

23
DG Content read/write mandatory / acccess control
optional
DG1 MRZ R m BAC
DG2 Face R m BAC
DG3 Finger R o BAC+EAC
DG4 Iris R o BAC+EAC
.. R

DG14 SecurityInfo* R o BAC


DG15 AA public key R o BAC
DG16 R

SO Security Object R m BAC

*ANS.1 data structure indicating support for Chip and Terminal


Authentication, and defining. Chip Authentication Public Key

24
problems with passports,
so far...
passive vs active attacks on RFID

passive attacks active attacks


• eavesdropping on • unauthorised access to
communication between passport without owner's
passport & reader knowledge
• possible from several • possible up to 25 cm
meters – activating RFID tag
requires powerful field!

• aka virtual pickpocketing


• variant: relay attack

26
Problem with BAC: low entropy in MRZ

• MRZ key based on passport number, expiry and birth dates


• passport numbers typically issued in sequence, so low entropy,
and strongly correlated with expiry date
– 3DES max 112bit, BAC max 56/74bit, in practice 30-50
• off-line brute force attack on eavesdropped traffic is
possible [Marc Witteman & Harko Robroch, 2006]
• first discovered for Dutch passport, but other countries had
the same problem
• solutions?
– changing the key derivation procedure rejected by ICAO for
compatibility issues
– not handing out passport no's in sequence caused organisational
/operational problems

27
Problems with Belgian passports

• First generation of Belgian passports (2004-2006) did not


support BAC
– so MRZ (DG1) skimmable in fraction of a second, all
passport info in about 10 secs
• These passports provide info not required by ICAO, incl
– place of birth
– digital version of signature

• Also, same problem with low entropy of MRZ as Dutch passports


– moreover, different ranges of passport no's reserved for
Flemish and Walloon passports

28
Problem with ISO 14443: fixed UIDs

• Normal ISO 14443 tags sent a fixed UID as part


of the anti-collision protocol
• This would allow tracking of individual passports

• Producing random UID requires non-standard hardware


• Some countries still used fixed UIDs

• First generation of Dutch passports does not have truly


random UIDs, as 2 bits in the random UIDs are always the
same...

29
Problems with terminals

• Lukas Greenwald reported some terminals crashing


with a buffer overflow on malformed JPEG
– missing input validation, as usual...

• Jeroen van Beek (UvA) reported some terminals


failing to check digital signatures correctly
– ICAO specs somewhat tricky
• eg will terminal spot a clone of a passport that says it
does not support AA?

30
• bla

31
Problem: determining passport origin

• Error messages of the card


reveal manufacturer
– ie provide fingerprint

• BSc thesis by Henning Richter


here in Nijmegen

32
Errors can leak information

An Error Has Occurred.


Error Message:
System.Data.OleDb.OleDbException: Syntax error
(missing operator) in query expression
'username ''' and password = 'g''.
System.Data.OleDb.OleDbCommand.ExecuteCommandTextE
rrorHandling (Int32 hr) at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextF
orSingleResult (tagDBPARAMS dbParams, Object&
executeResult) at

33
Fingerprinting passports

• All e-passports react the same to correct protocol


runs....
• but what about incorrect ones? Eg
– commands out of sequence
• eg B0 (READ BINARY) before completing BAC
– commands not in the ICAO specs at all
• eg 44 (REHABILITATE CHV)
– commands with silly parameters

34
Example commands & responses

Commands sent to card include 1 instruction byte, eg


• A4 SELECT FILE
• B0 READ BINARY
• 84 GET CHALLENGE
• 82 EXTERNAL AUTHENTICATE
• ...
Responses from card include 2 bytes status word, eg
• 9000 No error
• 6D00 Instruction not supported
• 6986 Command Not Allowed
• 6700 Wrong Length
• ...
Defined in ISO7816, re-used in ICAO specs

35
Example responses to B0 instruction
B0 means "read binary", and is only allowed after BAC

response meaning
(status word)
Belgian 6986 not allowed
Dutch 6982 security status not satisfied
French 6F00 no precise diagnosis
Italian 6D00 not supported
German 6700 wrong length

255 other instructions to try,


and we can try different parameters ...
36
Fingerprinting passports

• Response to strange inputs provides unique


fingerprint for ten nationalities originally tested
– Australian, Belgian, Dutch, French, German,
Greek, Italian, Polish, Spanish, Swedish

37
Detecting & distinguishing passports

• 4 commands suffices to distinguish between the


10 nationalities we tested
– instruction byte 82 identifies Australian, Belgian, French,
and Greek
– A4 identifies Dutch and Italian
– 88 identifies Polish and Swedish
– 82 with different parameter identifies German and
Spanish
• Code to do this is very simple & very fast

38
Fingerprinting passports

• This fingerprint depends on implementation


choices in the software
– upgrading hardware would not affect this

• If countries use the same implementation (ie. get


passport from same supplier), the fingerprints
would be identical
– Indeed, Dutch, Irish, Finnish and Slovak
passports give identical responses

39
The small print in the specs

"A MRTD chip that supports Basic Access Control


must respond to unauthenticated read attempts
(including selection of (protected) field in the
LDS) with ‘Security Status not satisfied’ (6982)"
[PKI for machine readable travel documents offering ICC read-only
access, version 1.1. Technical report, ICAO, Oct 2004.]

but what constitutes a "read attempt"?

40
More fingerprinting possibilities

passport application
operating system
smartcard hardware
• Our approach fingerprints passport application
– so upgrading hardware or OS won't affect
fingerprint
• Fingerprinting may be possible at other levels, eg
– OS
– hardware

41
More fingerprinting possibilities

• ATS (Answer To Select)


– sent by RFID on activation to indicate eg
supported data rate, but also operating system
version (in "historical bytes")
– New Zealand passport sends "JCOP41V22", so it's an
IBM/NXP JCOP card, version 4.1, running Javathis?
Remember Card 2.2
• Other OS behaviour
– eg Dutch passport recognisable as Java Card,
>telnet hera.cs.kun.nl
as it supports Global Trying
Platform131.174.142.11
• Physical characteristicsConnected to hera
Red Hattimes,
– power consumption, response Linux.... 2.4.18
login:
42
Countermeasures to fingerprinting

• better specs
– clearly prescribing standard error responses
– or, all countries could simply use a common open
source implementation
• eg our Java Card implemententation
[http://jmrtd.sourceforge.net]
– but infeasible to do now, once specs & implementations
exist

• metal shielding in passport cover (Faraday cage)


– defence-in-depth

43
Abuse cases for fingerprinting?

• Passport bomb triggered by a specific nationality


• Selection of potential victims by passport thieves

Fortunately, limited range for active attacks


(25cm, maybe a bit more) reduces any serious
threat

Also, there may be easier ways to detect


nationality...

44
Other risk: transferability

• Downside using digital signatures:


someone reading the passport info can store it, or pass
it on to a third party, with the digital signatures
– Eg if country B can read fingerprint info of passport from
country A, this info can be passed on to country C, who
can check authenticity of all info
• Instead of sending signed data, the chip could
– after being authenticated, provide unsigned data,
• This data can be trusted if we have authenticated the
chip, but trust cannot be transferred or stored
– use some protocols for non-tranferable proofs

45
Conclusions
Questions

• What is the problem solved/security improved by


RFIDs in passports?

• Does it outweight the new risks?

• Potential problem/opportunity: function creep?

47
On-line authentication

• Passive authentication only proves such a person/passport


exists (not that it is yours etc.)
• Active Authentication proves you have physical access to
passport:
AA can be used to login to computer or website like other
smartcards
– Martijn Oostdijk et al. (Novay) implemented a
demonstrator using AA to log on, using Windows
CardSpace (aka Info Card)
– [open source at http://jmrtd.org/authep]

• Remote biometric authentication is of course not secure

48
Other existing & future e-ID initiatives

• US Passport Cards and Enhanced Driver License (EDL) include a


simple RFID tag, which just broadcasts a unique UID
– readable at larger distances than ISO14443 passport tags

• ISO18013 standard for e-driving license


– very similar to ICAO specs
– first implementation done by Wojtek

• Additional functionality for e-id cards: digital signatures


– already in eg. Belgian e-id, foreseen for Dutch e-NIK
– eg for citizen access to Electronic Patient Dossier (EDP)?
– EU guidelines for digital signatures in place

49
Questions?

• Code for passport terminal and passport


available at http://jmrtd.sourceforge.net 50

You might also like