Embed Size (px)
Citation preview
Sniffing with the Portuguese Identify Card for fun and profit
Paul Crocker1,2 , Vasco Nicolau1 , Simão Melo de Sousa1 1 Department of Computer Science, University of Beira Interior 6201-001 Covilhã, Portugal 2 Institute of Telecommunications, Covilhã, Portugal [email protected] [email protected] [email protected] Abstract: In this paper we describe a case study of the re-engineering process used to discover the low-level application protocol data units (APDUs) and their associated significance when used in communications with the Portuguese e-id smart card. This was primarily done simply to learn the processes involved given the low level of documentation available from the Portuguese government concerning the inner workings of the Citizens Card. However it was also done in order to produce a generic platform for accessing and auditing the Portuguese Citizen Card and for using Match-on-Card biometrics for use in different scenarios. Given that no documentation is available concerning the use of the Match on Card capabilities of the e-id card this is a challenging procedure.
Keywords: Smart Card, e-id, Reengineering, Sniffing, Authentication, Biometrics
1 Introduction
The Portuguese government rolled out a new electronic identity card to the general Portuguese society three years ago called the “Cartão de Cidadão Português” (CC) (official CC site www.cartaodecidadao.pt). The card is produced by the “Imprensa Nacional-Casa da Moeda” (INCM www.incm.pt). The initial concept of the card was to merge various identification documents into a single electronic smart card and permit the maximum of interoperability between the various entities whilst following Portuguese law. Other objectives include permitting and enabling greater electronic interaction with the Portuguese government, simplifying access to electronic services, providing a legal and electronic infrastructure for validating electronic documents and possibility the creation of new innovative applications in general. An interesting fact is that the Portuguese constitution prohibits the use of a single ID number to uniquely identify citizens as happened during the dictatorship of the previous century.
The CC is a Java smart card containing a chip in the format of a common credit card. The card contains information written onto the card in several formats; visual human readable information, a bar-code type machine-readable zone and also information in electronic form on the chip. The chip contains the personnel information about the citizen, such as name and address, photographic image and biometric fingerprint template. Cryptographic keys and digital certificates created by the Portuguese PKI of the Portuguese Justice Ministry are also included.
The multi-application Java Card chip has a 8/16 bit CPU, ROM containing the operating system and cryptographic algorithms, minimum capacity of 64 KB EEPROM, RAM for transient data, dynamic memory management and file system management features. It supports multiple Personnel Identification Numbers (PIN) (three in this case), mechanisms for altering the PINs and internal cryptographic processing for generating digital signatures. It is combatable with multi-channel card readers for authentication and digital signatures (IAS), permits the generation of one-time passwords for alternative channels (telephone. mail, fax etc.) and executes Match-on-Card (MoC) biometric validation of fingerprints. The card is also resistant to tampering and resistant to side effect attacks (Rankl 2004). As a Java smartcard it executes Java Applets via the JCRE (Java Card Run Time Environment, or more simply, Java Card Manager) that runs on top of the native card operating system. Communication with card readers is made via standard ISO 7816 APDUS (Application Protocol Data Units).
Fig1. Diagram of applets installed in Portuguese Citizen Card
The relevant information and data on the card is accessed by diverse applets and in diverse directories and files (Rankl 2007). Also different versions of the card access the data in subtly different ways, presently there are two versions of the Portuguese CC. Obviously with complete documentation and specification of the CC this would make what is a complex task much simpler. However this is not the case; all public and relevant technical information freely available concerning the CC can be found on the official CC site developed and maintained by the Portuguese Agency for Administrative Modernization (AMA), www.ama.pt. Apart from some basic technical manuals the site also provides a restricted and high level API developed by the company ZETES (Zetes 2010). One of the principle objectives is to explore the IAS and MoC applets in order to develop an open source platform not connected to any governmental agency, able to obtain and test the citizen data, manipulate it and access features in a well understood and freely available platform, We wished to access features such as the MoC functionality that allows a citizen to authenticate by fingerprint, but which are not available to the ordinary citizens in currently available government supplied and supported software. This project shows a roadmap for developing a platform (middleware) able to access, audit and virtually any similar e-id card. The rest of this paper is organized in the following way: Section 2 simply describes the process of low level communication with a smartcard. Section 3 presents the methodology and re-engineering approach. Section 4 describes our contributions and methodology using a USB sniffer and proprietary middleware developed to obtain our platform. In section 5 the results of this approach used to develop our own applications using the Portuguese CC are presented. Section 6 extends this work to include the biometric Match-On-card process and we present our final the proof of concept application. Section 7 presents our conclusions and future work. 2 Java Card and Citizen Card Internals 2.1 APDU Commands The APDU-level communication between the card and the host computer is half-duplex. A command-response communication model is used where the host sends a command APDU to the card and the card sends a reply response APDU back to the host on the same communication channel. The actual CC Java Card platform uses a master-slave programming model between the host and the card. The host computer plays the master role sending a command to the card and then waiting for the response. The command sent effectively calls a method on the card, nothing more than a Java Card Applet running on the smart card. The applet to run on the card first needs to be selected, once selected and executed it simply waits for commands from the host. In other words the applet is playing the slave role in the communication model. The Java Card Virtual Machine (VM) passes APDUs that arrive on the card to the applet by invoking the process method of the applet. The applet
then executes, processes the APDU and creates a response APDU that is returned to the VM and then sent to the host (Li 2004). This process is illustrated in Figure 2.
Fig 2. Execution of an APDU command
An APDU consists of a header and Body and understanding the structure of the APDUs is fundamental. The Command APDUs are defined in ISO 7816-4, the format of an APDU Command is shown in Figure 3. There are four different possibilities to construct and send a command APDU, these are shown in Figure 4.
Fig 3. Header Command APDU
CLA: Class Byte that identifies the class of the instruction INS: Instruction Byte – determines specific command inside a class P1 e P2: Parameter bytes used to pass command specific parameters Le: length of the optional data Data: optional data Lc: Length of the expected response
Fig 4. Different types of Command APDUS that can be sent
The format of the response APDU is shown in Figure 5.
Fig5. The APDU response
The APDU response has an optional body and required trailer.
The body can be null or may contain a “data field”, depending on the command emitted and if this was executed with success or not. If the response APDU contains a data field, its length is determined by the Le field of the APDU command
The trailer SW1 and SW2 status words contain the resulting state of the execution of the required service, shown in Figure 6.
Fig 6. Trailer Response Codes APDU
All the reply codes can be interpreted using tables available online (Cheef 2010), the significance of each one is fundamental in the sniffing and re-engineering phase. After understanding the essence of the communication between the Smart Card via APDU commands it is necessary to study the communication with the card to obtain the information desired. Taking into account the methodology defined in the first phase of the diagram (Fig 2) it’s necessary to determine the correct sequence of APDU commands in order to access the data required. 3. Methodology & Reengineering Process Electronic-ID (e-id) cards are relatively recent documents. One such e-id card extensively studied and in fact first released as open source software, is the Belgium e-id Card (Cock 2006). Currently as part of the European stork project (Siddhartha 2008) e-id interoperability between European e-id cards and as such, well defined middleware solutions, are being discussed, however the internal working of each nation’s e-id card is still very much a national concern. In this section we describe the methodology developed for understand the functioning of the Portuguese CC. We wish to determine the degree of difficulty concerning the re-engineering of current applications in order to obtain data from a CC and also to discover mechanisms that use functionality of that the card not presently available to the public, such as MoC. In this section we shall begin by describing describe the re-engineering process followed using the Portuguese CC. The CC is a smart card and it is necessary first to understand the communication mechanisms in order to understand how to access the data on the card. After getting the data from the CC, the second phase begins where it is necessary to investigate all the processes involved in making a biometric validation of a citizen.
In figure 7 we present the methodology we used in our project, from understanding the communication processes and accessing the correct applets to constructing a platform with match-on-card biometric verification, the processes is divided into two distinct project phases. Section 4 describes in detail the techniques used for identifying and communicating with the card, selection of the e-ID applet and extraction of the personnel information on the CC
Fig 7. Diagram of the Project Methodology
4. Proposed Platform 4.1 Architecture In order to communicate with the CC it is necessary to have a SC reader, appropriate tools and an implementation of, for example, PCSC (Personal Computer/Smart Card). Simple and cheap SC readers manufactured by Gemalto can be purchased from Portuguese government offices; however any appropriate card reader can be used. PCSC is a standard, an extension of ISO 7816, that aims to provide a flexible integration platform for solutions that use smart cards on PCs. It defines the communication protocols, connectivity and application programming interface (API) that smart card readers should follow, (PC/SC Workgroup, Corcoran 2004). Windows XP implements it via the “winscard.dll”, Linux implements it via the PCSC-lite middleware. In order for us to write applications that interact with the CC in an independent fashion (free from middleware supplied by third parties such as the Portuguese Government) a wrapper, Figure 8, for the winscard.dll for communication with the smartcard via PCSC was developed. The wrapper is implemented as a dynamic link library that contains code to create and manipulate the structures of the APDU commands that we need to pass and receive. A proprietary middleware was developed.
Fig 8. Wrapper to communicate with Smart Card
Having developed the necessary tools the next step is to establish a connection with the card to obtain the cards ATR (Answer to Reset.) and thereby identify the type of card. It is important to know the type of card in order to identify the card producer and type, in order to establish the correct communication mechanisms that vary from card to card. The ATR is a sequence of bytes that defines various communication characteristics, such as the communication speed, the protocol uses, hardware parameters such as chip series, mask version etc. (Rank 2007). The ATR can be obtained via PCSC using the SCardStatus method (Corcoran 2004) via the winscard.dll. On establishing a connection to the card this returns several communication parameters, one of which is the ATR. When inserting the Portuguese CC the following ATR is obtained
3B 95 95 40 FF D0 00 54 01 32.
Several sites, such as (The SmartCard ATR Database 2010) on the internet provide regular update of lists of codes of card manufactures and types. In this case on we obtain the expected:
3B 95 95 40 FF D0 00 54 01 3. Portuguese identity card, http://www.cartaodecidadao.pt (SmartCard ATR Database)
This way we are able to establish a successful communication with the smart card and correctly recognize (or not) the card as a Portuguese ID card. The next section describes how we extract the personnel data from the card. 4.2 Sniffing The program used for sniffing the USB port was UsbSnoop (SniffUsb 2010). UsbSnoop is a USB protocol analyzer, a program that filters all the communication protocol between the computer and USB device, logging all communication. The program permits a fine grained control over the log files. It is possible to pause/resume/close/delete a log file. This functionality is useful in order to eliminate unnecessary data from the log files and simplify their analysis. Using test programs in debug mode permits one to capture all communication in, for example, a call to a high level routine contained inside a dynamic library. The APDUs that we are interested in are of course encapsulated inside USB packets. A USB connection generates a considerable amount of packets therefore it’s necessary to parse the log files to identify clearly the interesting data. The sniffer was used whilst running an application supplied by the Portuguese Government freely available on the CC site. This application accesses and displays basic information on the CC. The application is quite limited in its functionality, for instance it does not have the capability to create a digital signature of a file. The Portuguese government site bundles this application with a restricted SDK for programming in Java and C# that provides a high level API for accessing some of the cards functionality. Using the sniffer, shown in Figure 9, we were able to discover with the help of the online site (Cheef 2010) the APDU that selects the e-id applet on the smartcard for both versions of the card. Using this information we were then able to construct our own APDUs to communicate with the applet and via trial and error were able to adjust them to obtain the “90 00” success response code.
Fig 9. Screenshot of the Sniffer in action
5. Results As was stated previously we were able to extract the sequence of command and response APDUs exchanged between the card and the application. Since in this section we wish to extract the citizens’ personnel data we need to review how the information is organized on the SC (Rankl 2007).
Fig 10. Smart Card System Files
The internal structure of the file system, implemented in Smartcards, is governed by ISO/IEC 7816-4. Files contain a unique ID are resident on the EEPROM and implement a hierarchical structure shown in Figure 10 based on three types of files:
MF: Master File DF: Dedicated File EF: Elementary file
It is necessary to select the files that contain the relevant data. Therefore it’s of great importance to construct correctly the APDUS in order to correctly select the appropriate files. The example below shows how to select a file from the CC:
00H A4H P1 P2 Lc Data Le – SELECT FILE command
P1 options: P1 = 00H – select by FID
P1 = 04H – select DF by name
P1 = 08H – select from MF by path
P1 = 09H – select from current DF by path
P2 options:P2 = 00H – First occurrence
P2 = 01H – Last occurrence
P2 = 02H – Next occurrence
P2 = 03H – Previous occurrence As we can see from this example there are many options to take into account in the construction of the APDU that selects a file (Rankl 2007, Cheef 2010, SmartCard ATR Database). Using information from the sniffer and some patience to test step by step all the commands filtered, we found the correct files with the personal information of citizens. This phase took the longest amount of time because the information obtained from the sniffer is excessive, containing as well as the APDUS, all the USB
protocol information. Hence it takes a considerable time to investigate the sequence of commands exchanged between the SC and application for personal data. However, given the extensive testing made of the commands from the sniffer, it was possible to significantly simplify the number of commands used by the application to capture the information required. The information obtained from this file is 15,500 raw bytes. It is then necessary to convert it to UTF8 format in order to present the data in human readable format. This phase is complex as it is necessary to convert all information into a readable format by partitioning the output buffer of the data into different blocks, where each block refers to a different piece of information, address name etc. 5.1 Obtaining and Displaying the Citizens Photo The next challenge is to investigate the process of obtaining the photo from the CC. Contained in the 15,500 bytes of information (previously read) is the photo of the citizen. It is therefore necessary to parse this information and correctly extract the image data. The image format is jpeg2000, a wavelet based image compression. The choice of this format according to sources at AMA is due to the management of the storage space on the card. At the time jpeg2000 was considered to minimize the space needed, however there may exist other factors for the choice of this format instead of the more widespread jpg format, jpeg2000. Acquisition of the image data and its subsequent display is at first sight a trivial task. However for instance the .Net platform and standard Java libraries do not support this format. As our applications are developed in .Net and in Java it was necessary to convert the image to a format that could be rendered by a target development platform. Trial versions of commercial toolkits such as from Aurigma Imaging Technology (www.aurigma.com) were tested that converted the image in memory to a format (bmp, jpg etc). that could be rendered on the .Net platform. However the philosophy of this Project was to create an open source solution under a windows platform. After a careful search and selection process we decided to use CSJ2K-A Managed JPEG2000 Codec (http://csj2k.codeplex.com/) for the .Net platform. This toolkit proved to be simple and functional. The ease with which one obtains the picture on the CC without the need for authentication also raise questions the concerning the security level of the CC, a photo can be used for other purposes. 5.2 Presentation Application with Added functionality Using the above process we were able to develop an application that is in all respects similar to the standard Portuguese government’s applications for reading and presenting the CC personnel data. For such we have used our own middleware (entry points to the library mentioned earlier) mimicking the functionality of the Portuguese government application. As an added extra we included the capacity to digitally sign any document creating a detached signature of the file and of course verification of such a signature. This functionality is not supplied by any known Portuguese application, although the process of signing Adobe Acrobat and Microsoft Office documents is described in the CC user documents on the CC site. This application is shown in Fig 11.
Fig 11. Presentation of the personal information and signing documents
6 Biometrics The second part of this Project consists in implementing the biometric validation of a citizen, commonly known as Match-on-Card (MOC). MoC should always be performed in a controlled environment to ensure that the biometric data is extracted from the intended individual. To verify and authenticate a citizen the biometric header is first extracted from the smart card. This header is then used to capture and process the acquired fingerprint image. This will generate verification data that is sent to the card where it is verified. It’s general knowledge that the third applet contained on the CC is related to the biometric aspect of the card implemented by Precise Biometrics(PB). In order to select the applet it was found to be sufficient to slightly change the form of how the selection of the eid-applet is made and thereby select the biometric MoC applet. Once this applet is selected the SC executes inside this environment accepting only APDUS commands relative to MoC. In order to discover the low-level APDUS that are needed to interact with this applet we followed the process illustrated in Fig 2. Using a toolkit supplied by Precise Biometrics, a test card and of course the reader, a Precise Biometrics 250MC (combined biometric/smart card reader), we investigated the process of communication with the test card using the sniffer. We then extrapolated the process substituting the proprietary PB test card for the CC and were able to effect the MoC process with success. This will be explained in more detail in the following sections.
6.1 Fingerprint Template During the process of acquisition of the CC by the citizen fingerprint images of the citizen are captured in a controlled environment (enrollment). These images are converted into templates and stored on the smart card. A template is a pair and consists of reference data and an associated biometric header. The biometric header is used by the verification application to acquire and pre-process a suitable fingerprint sample. It contains information relevant to the type and form of data required by the smart card and therefore is stored in the smart cards public area. It is fundamental however that the reference data is stored in a private area of the smart card as it is this data that is used to perform the verification on the smart card. An important security aspect is that this data cannot be extracted nor altered. A biometric header is used due to performance issues. Using a header the verification application can, after acquiring the fingerprint image, preprocess it before transmission to the smart card for verification. In this way, the total MoC verification time can be minimized since the time consuming preprocessing stage is performed on a PC, which usually has a superior computational performance than the SC (PB 2008). Fingerprint validation on the CC is based on Minutia Matching. Fingerprints consist of a number of ridges and valleys. The ridges form minutia points; ridge ending (where a ridge ends) and ridge bifurcations (where a ridge splits). After enrollment the minutia points of the fingerprint image are located and their relative positions to each other and directions calculated. This data forms the template stored on the card and is subsequently used to authenticate a person. At the authentication stage, the acquired fingerprint image is pre-processed and the minutia points extracted to create another template that can be compared with the registered template see Figure 12. The comparison process simply involves trying to locate as many similar points as possible. The result of the matching is usually the number of matching minutiae. A threshold is then applied, determining if both the fingerprint and the template match (PB 2008). The value of the threshold needs to be finely tuned in order to minimize false positives and false negatives.
Fig 12: Verification using minutia points.
In order to submit a template for MoC it is therefore necessary to first construct it. This implies capturing the fingerprint image and constructing the template. After carefully considering the cost we decided to continue to use the PB toolkit, (although this task would not be difficult to implement) with the 250MC reader from PB, which is reasonably priced when matched against its competitors and also avoided compatibility problems with the software developed.
6.2 Match-On-Card After reading the fingerprint and obtaining the template the next step is to discover the APDUS necessary to execute MoC. The construction of the APDUS that transport the template to MoC was based on the documentation from PB and sniffing of the test card and toolkit previously mentioned. The APDU is described below.
Function parameters for the construction of the APDU
CLA B0h INS 32h P1 Template number P2 Sequence number P3 Data length DATA Biometric data
The template number parameter is used to select a template container on the card The sequence number is used to separate multiple verification commands where the biometric data for a specific template exceeds the maximum data length of an APDU.
Description of the sequence numbers 00h Verification initialization 01h Verification update [optional] 02h Verification finalization
After performing several tests the correct APDUS could be created and all the necessary procedures for MoC implemented. The much-expected 9000 response was obtained when a template constructed from a fingerprint compared to a template on the Portuguese CC. 6.3 Proof of Concept Considering all the previous sections, we have developed a system that permits us the ability to support any (similar) CC with MoC functionality. It should also be noted that the platform was developed entirely successfully with no relevant governmental documentation and which permits the use of card features not available to the general public. We now describe in detail one particular application developed that can be used in different scenarios. The application uses the Windows Presentation Foundation Classes (WPF) is illustrated in Fig 13 and has the following characteristics:
Automatic detection on insertion and removal of CC An animation to represent data reading on the card, a relatively slow process. Graphical presentation of citizen data including an animated photo. A feedback response on authentication via MoC. The fingerprint image (gray/black) is
manipulated to be green or red and there are simple sounds to indicate authentication or not.
Fig 13. Match on Card Authentication
7. Conclusions and Future Work We have related the process of re-engineering the Portuguese CC in order to discover the low level communication with the card. We have developed our own middleware based on the information discovered. We have shown that the development of a platform for biometric authentications is possible and developed more functional applications using the CC. The process used to achieve success, has involved many details of security, Smart Cards and Biometrics. The most complicated part was accessing and obtaining the information on the Smart Card. This was a complex procedure in the absence of detailed official governmental documents, as it was necessary to sniff, disassemble and re-engineer the whole platform of the Portuguese Citizen Card in order to get all the necessary data. Such information would probably be better off being in the public domain instead of being obfuscated behind proprietary middleware: we were able to reconstruct it! Regarding future work, one obvious avenue is to explore further the fingerprint template in order not to use a commercial toolkit, deemed possible since the methods used to build the template are standard and seem to be based on international standards [28]. Also with the knowledge gained it would be possible to develop an open source middleware for accessing the Portuguese CC that would lead to the possibility of developing richer, more functional applications and also more interest in developing applications in languages other than C# and Java. Concerning Security of the CC future work involving an independent security audit of the CC is now possible; also the implications relating to the ease of obtaining the photo and MoC functionality without the need for introducing a PIN should be studied – combined biometric and PIN authentication is often considered to be a stronger authentication method than the use of only one of the two methods There is still a third applet to be explored, the OTP applet, to our knowledge several Hardware devices exist based on EMV-CAP chip-card readers that make use of this capacity to generate one time passwords for use in, for instance, two factor authentication systems. However such software is not available to the general public. Further work also involves using our techniques for reverse -engineering other national e-id cards. Lastly one of our original motivations for this Project was to develop a low cost Hardware prototype for authentication using Match on Card biometrics. Such a system is an attractive possibility for use in third world countries and would be useful in many situations such as in voting stations where a significant proportion of the population is illiterate. Such a system has been discussed for use in several of the Portuguese-speaking African countries (PALOPs). This is of course a “for profit” commercial venture, currently ongoing.
References
Cardwerk, The ISO 7816 Smart Card Standard: Overview [online] http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx (Accessed 20-12-2009) Cheef, Smartcard Selected Information, http://cheef.ru/docs/HowTo/ (Accessed 20-12-2009) Cock, D, Christopher Wolf, C, Bart Preneel, B. The Belgian Electronic Identity Card (Overview), Sicherheit 2006: Jana Dittmann (Ed.). Corcoran, D & Rousseau, L, MUSCLE PC/SC Lite API Toolkit API Reference Documentation 2004, (online) http://pcsclite.alioth.debian.org/pcsc-lite/pcsc-lite.html INCM, Imprensa National-Casa de Moeda. http://www.incm.pt ISO/IEC 19784-1:2005, Information technology – Biometric application programming interface – Part 1: BioAPI Specification Li, P and Zdancewic, S, Advanced control flow in Java card programming, Proceedings of the 2004 ACM SIGPLAN/SIGBED conference on Languages, compilers, and tools for embedded systems, pp165-174, 2004 Microsoft Windows Developer Center, The SmartCard SDK.[online] http://msdn.microsoft.com/ PC/SC WorkGroup http://www.pcscworkgroup.com/ PB, Precise Biometrics. BioMatch Flex H - User Manual, Precise Biometrics, 2008. Rankl, W (2002) Smart Card Handbook, John Wiley, England Rankl, W (2007) Smart Card Applications Design Models for Using and Programming Smart Cards, John Wiley, England Siddhartha A ,National e-ID card schemes: A European overview, Information Security Technical Report, Volume 13, Issue 2, May 2008, Pages 46-53 SmartCard ATR Database. http://ludovic.rousseau.free.fr/softwares/pcsc-tools/smartcard_list.txt SniffUsb 2.0 - USB Sniffer for Windows http://www.pcausa.com/Utilities/UsbSnoop Zetes Industries, O desafio do lançamento do Cartão de Cidadão e do seu middleware, [online] http://www.zetes.pt/pt/articles/portugal/solutions-services/people-id/cartao-de-cidadao.cfm (Accessed 10-1-2010)
