Presentation

ON DEVELOPMENT OF INSPECTION
SYSTEM FOR BIOMETRIC PASSPORTS
USING JAVA
Authors:
Luis Terán ([email protected])
Dr. Andrzej Drygajlo ([email protected])
AGENDA
•
Goals
•
ICAO Technical Advisory Group
•
Machine Readable Travel Documents ( MRTD )
•
Logical Data Structure ( LDS ).
•
File Structure
•
Security of E-passports
•
Implementation of Inspection System Simulator
•
Conclusions
GOALS
• Implementation
Specifications.
• Design
of an Inspection Systems Simulator for E-passports.
• Implementation
E-passports.
Goals
ICAO
of a E-passport Applet according to ICAO
MRTD
of Security (Basic Access Control) for
LDS
File Structure
Security
Implementation
Conclusions
ICAO TAG
•
Machine assisted identification and confirmation (based on
biometrics).
•
Considerations for MTRD’s:
-
Global Interoperability
Uniformity
Technical Reliability
Practicality
Durability
• Main reports:
- LOGICAL DATA STRUCTURE (LDS)
- PUBLIC KEY INFRASTRUCTURE (PKI)
- CONTACTLESS IC CHIP
Goals
ICAO
MRTD
LDS
File Structure
Security
Implementation
Conclusions
MRTD
•
International Travel Document (e.g. visa or passport).
•
Contains in a standard format, holder details.
•
Includes a mandatory Machine Readable Zone (MRZ).
•
Facilitates inspection and enhance security.
ICAO
MRTD
LDS
File Structure
Security
Implementation
Conclusions
MRTD’S EVOLUTION
1968: ICAO starts working on MRTD
1980: Machine Readable Zone
1997: ICAO starts working on biometrics.
2001: After 9/11 US speeds up development of MRTD’s
2002: Face recognition, finger prints, and iris recognition
(main biometric for MRTD’s).
2003: Contactless IC for MRTD’s.
2005: Deployment of E-passports in several countries.
2006: EU starts development of Extended Access Controls.
MRTD
LDS
File Structure
Security
Implementation
Conclusions
MRZ
P<USAAMOSS<<FRANK<<<<<<<<<<<<<<<<<<<<<<<<<<<
0 0 0 0 7 8 0 0 4 3 U S A 5 0 0 1 0 1 3 M 1 5 111 6 9 1 0 0 0 0 0 0 0 0 < 3 8 1 5 6 4
•Document Type
•Issuing State or Organization
•Name of Holder
•Document Number
•Check Digit - Document Number
•Nationality
•Date of Birth
•Check Digit - Date of Birth
•Sex
•Date of Expiry or Date or Valid Until Date
•Check Digit - Date of Expiry
•Optional Data
•Check Digit - Optional Data (ID-3 Document Only)
•Check Digit - Composite.
MRTD
LDS
File Structure
Security
Implementation
Conclusions
LOGICAL DATA STRUCTURE
MRTD
LDS
File Structure
Security
Implementation
Conclusions
LOGICAL DATA STRUCTURE
MRTD
LDS
File Structure
Security
Implementation
Conclusions
FILE STRUCTURE
•MRTD according to ISO/IEC 7816-4
-Master File (MF) --> root
-Dedicated File (DF’s) --> contain EF’s or DF’s
-Elementary File (EFs) ---> DG stored in EF’s
•Each data object is encoded using Tag - Length - Value (TLV)
-Example: { T - L - V {T1 - L1 - V1} ... { Tn - Ln - Vn } }
•Length Field
1st byte
2nd byte
3rd byte
4th byte
5th byte
Length of Value Field
1 byte
‘00’ to ‘7F’
-
-
-
-
0 to 127
2 bytes
‘81’
‘00’ to ‘FF’
-
-
-
0 to 255
3 bytes
‘82’
‘0000’ to ‘FFFF’
-
-
0 to 65535
4 bytes
‘83’
-
0 to 16777215
5 bytes
‘84’
‘000000’ to ‘FFFFFF’
‘00000000’ to ‘FFFFFFFF’
LDS
File Structure
Security
0 to 4294967295
Implementation
Conclusions
DATA GROUP CODIFICATION (DG2)
File Structure
Security
Implementation
Conclusions
DATA GROUP CODIFICATION (DG2)
12700 bytes
File Structure
Security
Implementation
Conclusions
SECURITY
•
ICAO Specs for Security of MTRD’s:
•
Authentication:
•
•
Passive Authentication ---> Authentic Information
•
Active Authentication ---> Authentic Chip
Access Control:
•
None
•
Basic Access Control ---> Optional
•
Extended Access Control ---> Optional (up to each
Country)
File Structure
Security
Implementation
Conclusions
MRTD’S AUTHENTICATION (I)
•
Passive Authentication
-
SOD = [h(DG1), h(DG2),..., h(DGn)]
-
Inspection Systems verify SOD
-
No processing capabilities in the IC chip required
-
Proves that LDS is authentic and it is not changed
-
Does not prevent exact copy of the chip ---> BAD
Security
Implementation
Conclusions
MRTD’S AUTHENTICATION (II)
• Active
Authentication
-
Uses a challenge-response protocol
-
IC chip saves KPrAA and KPuAA pairs for authentication.
-
Requires processing capabilities of the IC chip
-
Prevents chip substitution --> BETTER
Security
Implementation
Conclusions
ACCESS CONTROL
•
Main treats of contactless IC chips:
•
Unauthorized Access to the Card.
•
Unencrypted communication (reader-chip) can be
Eavesdropped.
Security
Implementation
Conclusions
BASIC ACCESS CONTROL (I)
Derivation of KIFD/ICC from MRZ_information
• Inspection System reads MRZ ---> MRZ_information derived from MRZ
P<USAAMOSS<<FRANK<<<<<<<<<<<<<<<<<<<<<<<<<<<
0000780043USA5001013M1511169100000000<381564
MRZ_information = 000078004500101151116 (Doc. Number || Data of Birth || Date of Expiry)
• IS computes SHA_1 of MRZ_information
• IS takes 16 most significant bytes of SHA_1(MRZ_information).
• The key seed KIFD/ICC is:
KIFD/ICC = Trunc16 (SHA_1(MRZ_information))
• KENC and KMAC are computed with KIFD/ICC (next slide)
Security
Implementation
Conclusions
BASIC ACCESS CONTROL (II)
Derivation of KENC and KMAC from KIFD/ICC
•
IS concatenates KIFD/ICC with a value c
(c = 1 for KENC and c = 2 for KMAC)---> hash --->truncates to 16 bits.
HASH1 = Trunc16(SHA_1(KIFD/ICC||00 00 00 01))
HASH2 = Trunc16(SHA_1(KIFD/ICC||00 00 00 02))
•
KaENC ---> first 8 bits of HASH1
KbENC ---> last 8 bits of HASH1
KaMAC ---> first 8 bits of HASH2
KbMAC ---> last 8 bits of HASH2
•
KENC and KMAC ---> 3DES - 2KEY
•
•
•
Security
Implementation
Conclusions
BASIC ACCESS CONTROL (III)
Authentication and establishment of KSENC and KSMAC
•KENC and KMAC previously derived from MRZ (previous slides)
IFD
ICC
CHALLENGE
PICK RND.IFD, KIFD
RND.ICC
PICK RND.ICC, KICC
E[KENC](S) || MAC[KMAC](E[KENC](S))
CHECK RND.ICC
S = RND.IFD|| RND.ICC ||KIFD
E[KENC](R) || MAC[KMAC](E[KENC](R))
CHECK RND.IFD
R = RND.ICC|| RND.IFD ||KICC
•Both, IFD and ICC compute new KIFD/ICC = KICC ⊕ KIFD
•KSENC and KSMAC are derived from KIFD/ICC (previous slide)
Security
Implementation
Conclusions
SECURE MESSAGING
•
Ensures secure communication of APDU’s between inspection systems
and MRTD’s.
Security
Implementation
Conclusions
INSPECTION SYSTEM SIMULATOR
•
It is a GUI which allows to test Java Card Applets
(E-Passports).
•
Three interfaces:
•
DataBase (Create/Update user)
•
JCWDE Simulator (test Java Card Applet)
•
PC/SC communication with real Java Card.
Security
Implementation
Conclusions
INSPECTION SYSTEM SIMULATOR
ARCHITECTURE
Create/Updated
E-PASSPORT
JAVA CARD
DB
JCWDE
PC/SC
JAVA
Implementation
Conclusions
IMPLEMENTATION
Write Card from Data Base (UML Sequence Diagram)
Implementation
Conclusions
DEMO
Implementation
Conclusions
CONCLUSIONS
•
•
Conclusions:
•
Simulator helps to understand better ICAO E-passports.
•
JCWDE and Java Card Version 2.2.1 ---> limited
Future work:
•
System Improvements (CREF simulator).
•
eGovernment --> eVoting (security issues).
•
A2B using ePassports (i.e. Bank accounts opening)
•
Java Card Version 3 (TCP/IP, HTTP, better security)
QUESTIONS? IDEAS?
Implementation
Conclusions
THANK YOU
Conclusions