See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/259884617

Sniffing with the Portuguese Identify Card for fun and profit

Conference Paper · July 2010

CITATIONS READS

0 4,743

3 authors, including:

Paul Crocker Simão Melo de Sousa

Universidade da Beira Interior Universidade da Beira Interior
33 PUBLICATIONS   50 CITATIONS    67 PUBLICATIONS   310 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

PRICE (Privacy Reliability Integrity in Cloud Environments) View project

All content following this page was uploaded by Simão Melo de Sousa on 27 January 2014.

The user has requested enhancement of the downloaded file.

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
crocker@di.ubi.pt
m2207@ubi.pt
desousa@di.ubi.pt

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)

View publication stats