Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Witt 2002

Witt 2002

|Views: 4|Likes:
Published by Ferry Armansyah

More info:

Published by: Ferry Armansyah on Jun 28, 2012
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Information Security Bulletin July 2002, Page 11
Advances inSmartcard Security
Marc Witteman
Over the last decade smartcards have enteredour global community. Although initially theywere only used as simple phone cards they nowsupport a large number of applications. Not allof them are successful yet, but their usage is stillgrowing. Today over one billion smartcards areused in telecommunication (GSM), banking ser-vices and various other areas.The original smartcard (or chip card) was noth-ing more than a memory chip that could hold astored value. The only security feature was asimple mechanism that prevented cards from be-ing filled up again after use. Even though thatseemed to be sufficient for phone card applica-tions it did not take talkative hackers long to break the mechanism.Today’s applications require more functionalityand security and are much more complex.Therefore smartcards are now equipped withmicroprocessors and a significant number of se-curity measures.This article gives a technical overview of the ad-vances and threats in smartcard security. Firstthe designs of smartcard hard- and software arereviewed. Then the main attack classes and theircountermeasures are discussed. Finally somesuggestions are presented concerning how toachieve and maintain appropriate security insmartcard systems.
Smartcard Design
Hardware architecture
Smartcards come in different shapes. First of allthere is a distinction between contact cards andcontact-less cards. The first kind is easily recog-nised by the characteristic contact stamp that ap-pears on both credit-card sized and SIM cardsized versions. The second one is more difficultto identify because the chip may be hidden notonly inside a credit-card sized container, but alsoin badges, car keys or labels.Secure tokens likedongles (hardwarekeys) and othertypes of smart tokens are related to smartcards, but mostly less complicated. They oftenimplement proprietary hard-encoded encryp-tion, although some newer versions use commonalgorithms like DES.The connections used on contact smartcards areshown in Figure 1.The Vcc and Ground contacts provide the powerfor the chip. The Reset contact facilitates a hardrestart of all processes. The clock contact pro-vides an external clock signal to the chip thatserves as the heartbeat for the internal processes.The Vpp contact originally provided a higherEEPROM programming voltage, but is no longerin use. Finally the I/O contact is a serial channelfor bi-directional communication between smart-cards and terminals.Contact-less cards use electromagnetic inductionto provide power from terminal to smartcard aswell as for bi-directional data exchange.Whatever the container is, the functionality ofthe smartcard is embodied in a single small chip.Figure 2 shows a basic schematic of the chip.Unlike many other chips, a smartcard chip is acomplete computer in itself. It combines func-tions that are often distributed over separatecomponents:
CPU (Central Processing Unit)
: the heart ofthe chip, all computational work and data ex-change goes via this function. Sometimes acryptographic coprocessor is included. Mostsmartcard CPUs run on a clock frequency of3.57 MHz.
Figure 1
Contact Card Connections
Smartcard ChipSecurityLogicCPUTestLogicI/OInterfaceROMRAMEEPROM
Figure 2
Basic Smartcard Chip Architecture
 July 2002, Page 12 Information Security Bulletin
Test Logic
: a verification function only usedduring the production process to test all inter-nal circuits for manufacturing faults.
Security Logic
: a continuous function thatchecks environmental conditions that could jeopardise the security of the smartcard.
I/O Interface
: a communication function thattakes care of receiving external commands andsending back responses using a serial commu-nication protocol.
: the permanent memory of the chip. Itcan contain parts of the operating system andself test procedures. The memory size is typi-cally 32 Kb.
: the CPU’s scratch pad memory. This isused for storing temporary or intermediatedata like session keys, internal variables andstack data. The memory size is typically 1 Kb.
: non-volatile updateable memory. Itis used for storing application data like keys,PINs, balances, phone numbers and sometimesapplication or even operating system code.
Data Bus
: the transfer channel within the chip.All information exchanged between the vari-ous functions passes through this channel.All these functions have to be implemented onthe small surface available for smartcard chips(typically not larger than 25 mm
). Smartcardchips do follow the tendency towards miniaturi-sation that is common practice in the chip indus-try though. State-of-the-art smartcard chips usefeature sizes less than 0.2
m and up to 7 stackedlayers of metal and silicon.
Software Architecture
Early processor cards used a monolithic softwaremodel: operating system and application func-tions were closely interwoven. Nowadays mostsmartcards use a more modular software designand also application separation. A popularsmartcard operating system is called
Java Card
and uses proven security concepts from the Javalanguage. This operating system allows for flexi- ble application design. Applications can be de-veloped and loaded after card manufacturing oreven post-issuance.Modern smartcard operating systems use life-cy-cle management. This process restricts the ac-tions that can be performed in the smartcard.The system must for instance be quite open dur-ing the manufacturing process to facilitate con-figuration, but much more closed during fieldoperation to avoid fraud.Data stored within a smartcard is organised in anested file system. The EEPROM is used simi-larly to a hard disk and can contain files and di-rectories with user and application data.The cryptographic functions may be imple-mented partly in hardware, but there is always asoftware program that controls the executionand that is stored either in the permanent ornon-volatile memory.Terminals (or card readers) talk to smartcards bymeans of commands. Figure 3 shows the com-mand structure.Commands have a five-byte header followed byan optional variable-length data part. The firsttwo bytes CLA and INS specify the
(con-text) and
. This structure allows thedefinition of 216 different commands. The nexttwo bytes P1 and P2 are
Command Parameters
. P3indicates either the
of the data includedin the command, or the length of the requestedresponse data.Some common commands are:
: open a file or directory.
: read a file
: change the contents of a file
: authenticate the smartcardto the external world
: check a cardholder’s PIN code.Smartcards enforce access conditions to protectthe data content of files. Users (terminals) canonly access files for reading or writing if theproper access conditions are fulfilled. Access con-ditions may require PIN verification or externalauthentication. More information on smart carddesign basics can be found in [1].
Smartcard security threats
Smartcards are popular targets for attackers, forvarious reasons:
Successful attacks enable fraud and are valu-able; professional attackers can make a busi-ness case.
Smartcards are cheap and easy to obtain; at-tackers can easily acquire some samples fortraining.
Smartcards are portable; the attacker can easily bring them to a hostile environment and con-trol the conditions.Manufacturers are well aware of these tempta-tions and pay particular attention to secure theirproducts. In practice 100% security is never pos-sible and designers and attackers of secure sys-tems continuously challenge each other and newadvances are made.We can distinguish between three basic attack classes:
Figure 3
Command Structure
Information Security Bulletin July 2002, Page 14
Logical Attacks
: exploits that use bugs in thesoftware implementation.
Physical Attacks
: exploits that use analysis ormodification of the smartcard hardware.
Side Channel Attacks
: exploits that use physi-cal phenomena to analyse or modify thesmartcard behaviour.The following sections discuss these attack classes and counter measures taken by the in-dustry.
Logical Attacks
Smartcards have a single communication chan-nel to exchange data with a terminal (smartcardreader). This channel is a serial interface wherecommands can be issued that the smartcardmust perform. Although smartcards are smallcomputers, there is an amazing number of com-mand options that may be supported. Due tothis complexity and time-to-market constraints ithappens that hidden flaws that do not affect thenormal behaviour, remain undetected during se-curity tests. Logical attacks abuse these flaws totrick the smartcard into surrendering confiden-tial data or allowing undesired data modifica-tions.
Logical Security Threats
Potential logical flaws may relate to many differ-ent aspects.
Hidden Commands
Smartcard operating systems can technically dis-tinguish between more than 65000 commands.Although practical use may require only a fewcommands there may be some remaining andactive commands from an initialisation phase orfrom a previous application. These commandsmay be abused to retrieve data from or modifydata in the smartcard.
Parameter Poisoning and Buffer Overflow
Commands are accompanied by a number of pa-rameters that specify the exact request. A disal-lowed parameter value or length may not be re- jected, but misinterpreted and lead to surprising results. A simple, but sometimes effective, exam-ple is a file read command where offset and re-quested length exceeds the actual file size.
File Acces
Smartcard file systems have detailed permissionson files and directories. For each command ac-cess permissions determine the security proce-dures to access a file. It may happen that the ac-cess permissions implemented allow more accessthan needed for specific files, thus creating a se-curity hole. Complex interactions can occurwhen several distinct applications need to be ac-cessed during one session, and operating sys-tems may confuse access permissions.
 Malicious Applet
Smartcards that support multiple applicationsneed to ensure application separation. The oper-ating system should create a virtual environmentwhere applets cannot harm each other. If an at-tacker manages to download a rogue applet, orabuse a flaw in one applet, he may be able tocompromise another security sensitive applet.
Communication Protocol
Information exchange between smartcard andterminal is dictated by a communication protocolthat handles data flow control and error recov-ery. By sending messages outside the scope ofthe current state it may be possible to trick thesmartcard into revealing secrets. A notorious ex-ample uses an error correction facility in thecommunication protocol. Smartcards use a smallmessage buffer within the RAM memory to storeoperation results. They also keep a length fieldthat indicates the length of the available bufferdata. Whenever a message is not correctly re-ceived the receiver can request re-transmissionof the message. If a smartcard reader were to ask for re-transmission of a message that had not yet been sent at all, a sloppy smartcard implementa-tion may decide to send the buffer anyway. If atthe same time the length field is not properly in-itialised the implementation may send a largepart of, or even the entire remaining memory.Such a memory dump results in a complete sur-render of all confidential data and secrets. Figure4 shows how a message buffer is extended overthe remaining memory due to an impropervalue of the length field (LEN).
Crypto-Protocol, Design and Implementation
Cryptographic protocols handle consecutivecryptographic operations to perform transac-tions. If such a protocol is not carefully designedit may present opportunities for attackers to per-
Figure 4
Memory Dump

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->