final year thesis -...
TRANSCRIPT
Final Year Thesis
at the Ecole Nationale Superieure des Telecommunications in Paris
Department : Communications and Electronics
Differential Power Analysis Attack Againsta Software Implementation of DES
Korinna LENZ
Deutsche Telekom AGUniversity of Applied Sciences Leipzig, Germany
March - Oktober 2006
Prof. Dr. Egon Hilt Supervisor in Leipzig
Dipl.-Ing. Jean-Luc Danger Supervisor in Paris
Dr. Philippe Hoogvorst Advisor: Smart Cards
Dipl.-Ing. Sylvain Guilley Advisor: Cryptography, Attacks
i
Personal Statement and
Acknowledgements
This final year thesis has been written at the Ecole National Superieure des Telecom-
munication Paris. My topic, which is part of a more comprehensive project at the
aforementioned institution, has been both a challenge and an enrichment to me. I have
learned that progress can only be made within an effective working group. Sometimes
it has been difficult to work in an information project since most of the time involved is
not attached to programming, but to searching errors. The experience I have obtained
from this project is precious to me and I am positive that it will prove helpful for my
future work.
I would like to take this opportunity to express my gratitude towards some persons who
have significantly helped me throughout this final year thesis and beyond. First, I would
like to thank my parents for their enduring support, in particular my mother for her
management of all administrative affairs back home in Germany. Moreover, I am very
grateful to Philippe Hoogvorst for his valuable supervision and support, which was by
no means limited to the implementation of the smart card. Third, I would like to thank
Mr.Johannes Schmidt and Sylvain Guilley for their support in the analysis part of my
project. In particular I would like to thank Toni Ahnert for his linguistic support. I do
not want to forget Jean-Luc Danger for his management of the administrative affairs at
the ENST. And also all my friends, who made my stay in Paris a pleasant one. Last
but not least I would like to thank Egon Hilt for his supervision and motivation over the
entire term.
Korinna Lenz
iii
Abstract
This final year thesis describes the attack on a software implemented DES algorithm
executed on a prototype Smart Card. It is shown that only a small operating system is
required. The Hamming Distance Model and Correlation Analysis are used to realise a
Differential Power Analysis attack.
The analysis shows that an attack on a XOR operation could not be done. That is, that
the power consumption of the assumed XOR operation is insufficient for the DPA attack.
However, the subsequent storage operation, which stores the result of the desired XOR
operation, could be attacked.
Keywords : Smart Card, Differential Power Analysis, Cryptanalysis, DES, Analysis
v
Contents
Abstract iii
Abbreviations vi
1 Introduction 1
I Bibliographic Studies 3
2 Smart Card Basics 42.1 Introduction of Smart Card Basics . . . . . . . . . . . . . . . . . . . . . 42.2 Physical Structure of the “simulated” Smart Card . . . . . . . . . . . . . 52.3 A Smart Card Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 The Client-Server Principle . . . . . . . . . . . . . . . . . . . . . 52.3.2 The Session Start . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.3 Structure of the character frame . . . . . . . . . . . . . . . . . . . 62.3.4 The Answer to Reset . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.5 The Transmission Protocol . . . . . . . . . . . . . . . . . . . . . . 8
2.3.5.1 Protocol Selection . . . . . . . . . . . . . . . . . . . . . 82.3.5.2 Error Detection with “T=0” . . . . . . . . . . . . . . . . 92.3.5.3 Data Exchange with T=0 . . . . . . . . . . . . . . . . . 9
2.4 The Application Data Unit . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.1 Communication with the Application Data Unit . . . . . . . . . . 102.4.2 The Structure of a command APDU . . . . . . . . . . . . . . . . 112.4.3 The Structure of a Responds APDU . . . . . . . . . . . . . . . . 11
II Hardware Implementation 13
3 Implementation of a Minimal Operating System 143.1 Requirements of the Operating System . . . . . . . . . . . . . . . . . . . 143.2 The ATmega128 Test board . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 The Handling and Structure of the Board . . . . . . . . . . . . . 153.2.2 The USART Interface . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2.1 The USART of the ATmega128 . . . . . . . . . . . . . . 17
vi
3.2.2.2 Initialisation of the USART . . . . . . . . . . . . . . . . 18
4 The Operating System for the ATmega128 204.1 The Minimal Implementation of the card OS . . . . . . . . . . . . . . . . 204.2 The Integration of individual APDUs . . . . . . . . . . . . . . . . . . . . 214.3 Executing DES on the “simulated” Smart Card . . . . . . . . . . . . . . . 21
III Measurement Setup 23
5 Side-Channel-Attacks 245.1 Principle of Side-Channel-Attacks . . . . . . . . . . . . . . . . . . . . . . 245.2 Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.3 Power Consumption Analysis . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.1 The Differential Power Analysis . . . . . . . . . . . . . . . . . . . 265.3.2 The Hamming Distance Model . . . . . . . . . . . . . . . . . . . . 275.3.3 The Correlation Analysis . . . . . . . . . . . . . . . . . . . . . . . 27
6 The Implemented Data Encryption Algorithm 29
7 Measurements with the ATMega128 337.1 The Laboratory Test Bench . . . . . . . . . . . . . . . . . . . . . . . . . 337.2 Measurements with the ATmega128 . . . . . . . . . . . . . . . . . . . . . 35
7.2.1 Power Consumption of the ATmega128 . . . . . . . . . . . . . . . 357.2.2 Capturing Power Consumption Traces for the DPA . . . . . . . . 36
7.3 Analysis of the Power Consumption Traces . . . . . . . . . . . . . . . . . 387.3.1 The Analysis Programme . . . . . . . . . . . . . . . . . . . . . . 387.3.2 The Hamming Distance Selection Function . . . . . . . . . . . . . 39
7.4 The Analysis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.4.1 The key guess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.4.2 The DPA on the working registers . . . . . . . . . . . . . . . . . . 43
8 Conclusion 46
A The Software Equipment 49A.1 The WinAVR Notepad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.2 The AVRStudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
B Smart Cards 52B.1 Electronic contacts of Smart Cards . . . . . . . . . . . . . . . . . . . . . 52B.2 The Elementary Time Unit . . . . . . . . . . . . . . . . . . . . . . . . . 52B.3 The ATR frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.4 The APDU - Get Response . . . . . . . . . . . . . . . . . . . . . . . . . 54
Contents
vii
C The microprocessor ATmega128 59
D The Data Encryption Standard 63
Bibliography 65
Contents
viii
Abbreviations
ACK AcknowledgeAPDU Application Protocol Data UnitATR Answer to ResetCLA Class byteCOFF/COF Common Object File FormatDDR Data Direction RegisterDES Data Encryption StandardEEPROM Electrical Erasable Programmable Read only MemoryGPIB General Purpose Interface BusINS Instruction ByteISO International Organization for StandardizationJTAG Joint Test Action GroupLSB Least Significant BitMSB Most Significant BitNIST National Institute of Standards and Technologynu Not usedOS Operating SystemOSI Open Systems Interconnection Reference ModelPIN Personal IdentifierPTS Protocol Type SelectionRAM Random Access MemoryRISC Reduced instruction Set ComputerROM Read Only MemorySC Smart CardSRAM Static Random Access MemorySW Status WordTTL Transistor Transistor LogicUSART Universal Synchronous and asynchronous serial
Receiver and Transmitter
ix
List of Figures
2.1 Smart Card communication,[URL09] . . . . . . . . . . . . . . . . . . . . 62.2 The ATR string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Capture of the ATR string . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Structure of a command APDU . . . . . . . . . . . . . . . . . . . . . . . 112.5 The 4 cases of command APDUs . . . . . . . . . . . . . . . . . . . . . . 122.6 The Response APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 The Testboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 The ATmega128 - TX and RX . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Inverter with CMOS technology [ATDPA] . . . . . . . . . . . . . . . . . 25
6.1 The DES in General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.2 Explication of the implemented DES . . . . . . . . . . . . . . . . . . . . 32
7.1 The 16 DES rounds: with optimization . . . . . . . . . . . . . . . . . . . 367.2 The 16 DES rounds: without optimization . . . . . . . . . . . . . . . . . 377.3 Power Consumption for LOAD . . . . . . . . . . . . . . . . . . . . . . . 387.4 The Analysis Result of the First DES Round . . . . . . . . . . . . . . . . 417.5 Comparison of key guesses for key 0123ABCD4567FE98 . . . . . . . . . 417.6 Comparison of key guesses for key d562bc54a4e55283 . . . . . . . . . . . 427.7 Comparison of key guesses for key 34644ab5679dd697 . . . . . . . . . . . 427.8 DPA attack: key 0123ABCD4567FE98 . . . . . . . . . . . . . . . . . . . 447.9 DPA attack: key 34644ab5679dd697 . . . . . . . . . . . . . . . . . . . . . 457.10 DPA attack: key d562bc54a4e55283 . . . . . . . . . . . . . . . . . . . . . 45
B.1 Schema Microprocessor Card with ATmega128 . . . . . . . . . . . . . . . 52B.2 The Initial Character for direct conversion . . . . . . . . . . . . . . . . . 53B.3 Scheme of the status word SW1 - SW . . . . . . . . . . . . . . . . . . . . 58
C.1 Settings of the Jumper for the processor clock . . . . . . . . . . . . . . . 60C.2 Overview of the µ processor . . . . . . . . . . . . . . . . . . . . . . . . . 62
D.1 The Key Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63D.2 The combination of sub key and right block . . . . . . . . . . . . . . . . 64
x
List of Tables
2.1 The Procedure Bytes of the Card [ISOP3] . . . . . . . . . . . . . . . . . 92.2 Implemented status words of the card . . . . . . . . . . . . . . . . . . . . 10
3.1 Settings in Register UCSR1C . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 The implemented INS values . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Used Command APDUs in the project . . . . . . . . . . . . . . . . . . . 22
6.1 The DES Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1 Measurement Setups for with optimization . . . . . . . . . . . . . . . . . 357.2 Measurement Setups for without optimization . . . . . . . . . . . . . . . 367.3 Disassembled DES source code for Message XOR key . . . . . . . . . . . 43
B.1 The ATR stored in the EEPROM,[BRO06] . . . . . . . . . . . . . . . . . 54B.2 Commands of ISO 7816 [ISOP4] . . . . . . . . . . . . . . . . . . . . . . . 56B.3 Standardized Status Words for Error and Warning Conditions [ISOP4] . 57
C.1 The Control and Status Registers UCSR1A . . . . . . . . . . . . . . . . 61C.2 The Control and Status Registers UCSR1B . . . . . . . . . . . . . . . . . 61
1
1 Introduction
Thesis Objectives
The objective of this final year thesis is to attack a software implemented cryptographic
algorithm executed on a “simulated”1 smart card. This algorithm is a simple2 Data
Encryption Standard. The main objective is to discover dependencies between the power
consumption of the Smart Cards microcontroller and the DES execution using Differential
Power Analysis.
Therefore, there are three main tasks. First, the implementation of a minimal operating
system on the “simulated” Smart Card to establish communication between the “simu-
lated” Smart Card and the card reader. Second, the integration of the Data Encryption
Standard and the corresponding functions in the operating system. Third, the attacking
of the cryptographic algorithm using Differential Power Analysis.
Required Knowledge
This final year thesis uses knowledge in the following fields: microcontrollers, smart cards
and their standards for the implementation of the operating system, cryptography and
statistics for the attacking process, programming skills, and experience in instrumenta-
tions for the measurements involved.
1Smart Card model built like shown in figure 3.1,page162Standard published by NIST[URL08], besides Triple-DES or AES
2
Hardware
The main hardware components are a Smart Card(SC) prototype with a programmable
microcontroller ATMega128. In addition, a card reader GCR410 manufactured by GEM-
PLUS and SCs belonging to the ENST laboratories developer kit are used.
Software
Different developer environments are used. For simulating and programming the AT-
Mega128, the editor WinAVR Version 2.05.48, and the AVRStudio Version 4.11−Build
406 is used. The explicit description of the version is done because there were numerous
compatibility problems with other programme versions. In general, all codes are written
in C/C + + and assembler, respectively.
Organisation of the report
This thesis is organised in three parts. First, the components of a Smart Card with ref-
erence to the components used are described. Furthermore, the communication protocol
type used and its specifications are described. The last section of this part deals with
the structure and use of the application data unit to enable the data exchange between
Smart Card and card reader.
Second, a description of requirements to implement a minimal operating system on the
“simulated” Smart Card is given. It deals in detail with the implementation for the
microcontroller, namely its implementation, the Application Data Units used and the
Data Encryption Standard.
Third, the focus will be on the attacks and their analysis. The theory of analysing attacks
is introduced. Thereafter, the laboratory test bench is described and the measurements
results are presented. Finally, some concluding remarks will be given and possible future
research is sketched.
1 Introduction
3
Part I
Bibliographic Studies
4
2 Smart Card Basics
2.1 Introduction of Smart Card Basics
Smart Cards (SCs) are widely-spread devices. They have applications within all areas of
daily life. Today, almost everyone has a credit card, a club card, a SIM card in his mobile
phone or a patient card. The first Smart Card was developed in 1974 by Roland Moreno1
in France. First plastic cards were used in the United States for club membership, later
calling cards as well as the credit card followed.
Only the development of microelectronics made it possible to integrate a single chip on
plastic cards. Real SCs are used to store sensitive data and to execute security algorithms.
For the external world, the Smart Card is a ”’black box”’. Communication with a Smart
Card is regulated by a standardised interface. The access to files on the SC can be
regulated by access conditions. Furthermore, it is also possible to create inaccessible files
for the external world.
Basically, there exist two types of SCs. On the one hand, Memory Cards, which have only
a serial port, address logic and memory logic as well as a ROM and an EEPROM. On the
other hand, microprocessor cards possess a microcontroller apart from the components
of the memory cards. Microprocessor cards represent a small universal computer with a
simple interface.
ISO/IEC 7816 represents the standard that contains all specifications of SCs. It defines
all specifications, such as length, chip position, file structure, among others. There are
three most important layers dealt with in the following sections: the Physical Layer, the
Data Link Layer, and the Application Layer.
1www.rolandmoreno.com
5
2.2 Physical Structure of the “simulated”Smart Card
The typical components of a microprocessor card are a microprocessor, a serial I/O unit,
a ROM memory, an EEPROM as well as a RAM. In this work, the microcontroller
ATmega128 of the ATMEL family, a 8 bits RISC processor, is used. However, it has to
be considered that the microprocessor type used for Smart Cards is not standardized.
Most companies do not publish any information about the microprocessor used for their
SCs. Therefore, it is mandatory on a developer to select the processor.
The ROM is an important component beside the microprocessor. Normally, the ROM
serves to store the operating system of the card. At the ATmega128, the ROM is replaced
by a 128K Bytes Flash memory. It offers thereby a high flexibility for the investigations in
this thesis, because it can be programmed arbitrarily often in the laboratory. As visible
from the memory size the implemented operating system cannot possess hundreds of
megabytes. Furthermore, an SC must be able to store personal data. Thus a Smart Card
needs an EEPROM, which stores system specific data as well as user specific data. And
last but not least,the controller provides a 4K Bytes internal SRAM used as workspace.
2.3 A Smart Card Session
2.3.1 The Client-Server Principle
For the communication between card reader and card is only one physical channel avail-
able. At any given time one communication partner acts as transmitter, while the other
one acts as receiver. The communication is always initiated by the card reader. There-
fore, the card reader transmits a command to the card. The card interprets the command
and executes the necessary operations. Subsequently, it sends a response to the reader.
The card will never transmit a message on its own. This model of communication is
called Client-Server Principle, where the reader is client and the card is server.
2.3.2 The Session Start
A Smart Card session starts with a reset sent by the card reader. The session can be
divided into several consecutive phases. Each phase is characterized by a sequence of
2.2 Physical Structure of the“simulated”Smart Card
6
certain events or processes. Figure 2.1 shows the temporal and schematic sequences of a
communication session between a terminal and a Smart Card.
At the beginning of a Smart Card session the card reader has to ensure that there is
no voltage connection at the Vcc contact of the card. Only if the physical connection
exists between card reader and card, an activation of the contacts can take place. By
the end of the activation the contact RST is low, VCC is powered and stable, I/O is
set to reception mode and CLK provides a stable clock signal. After the activation of
the contacts the card reader initiates the session with the reset. Hence, the card reader
sets the RST signal from low to high. Now the card must response to the reset within
40,000 clock cycles2. The Answer to Reset3(ATR), the response to the card readers reset
is mandatory. If the ATR is correct data exchange can start. If the ATR4 was not
transmitted or it was wrong, then the session is closed.
Figure 2.1: Smart Card communication,[URL09]
2.3.3 Structure of the character frame
As stated in section B.1, the communication between card reader and card is serial
asynchronous half duplex. Therefore, the receiver has to be synchronized with each
character of the transmitter. Every character frame begins with a start bit followed by
2A more detailed description of times for the connection establishment is written in the standardISO-Part 3 [ISOP3].
3Specified in ISO 7816 Part 44The ATR frame is explained in detail in section 2.3.4
2 Smart Card Basics
7
eight bits of data that are secured by an even parity bit. Depending on the conversion,
those results from the ATR5 the data LSB or MSB is transmitted as first in the character
frame. In this work direct conversion (LSB first) is used. The parity bit is followed by
the Guard time. It puts the minimum time between two characters transmitted by the
card reader. The time can differ and is specified in the ATR. However, the minimum
time is two elementary time units (etu)6. In this work, one elementary unit corresponds
to ≈ 100, 91µs.
2.3.4 The Answer to Reset
The ATR is a string of 33 characters maximum. This string contains information about
the communication parameters of the card, for example the transmission protocol, data
format etc. The ATR begins with the initial character followed by a formating character.
After these two Characters, the global interface parameters and special interface param-
eters follow. The final characters are 15 not standardised historical bytes maximum, and
a check character to secure the information. Figure 2.2 displays the described structure
of the ATR string.
Figure 2.2: The ATR string
Figure 2.3 shows a part of the ATR string captured in the laboratory and used in this
thesis. The ATR marked frame characters correspond to the values in table B.1. It can
be shown that all characters follows the character frame structure as already mentioned.
5See section 2.3.46See appendix B.2 for the derivation
2.3 A Smart Card Session
8
Figure 2.3: Capture of the ATR string
2.3.5 The Transmission Protocol
2.3.5.1 Protocol Selection
There are two possibilities to select the transmission protocol. The first version applies
only to multi-protocol smart cards. In this case, the protocol type can be selected
by a protocol type selection (PTS) procedure before the ATR (If the card is in the
negotiation mode). Using the PTS, the desired protocol type can be chosen and the
favoured parameter setting can be executed. As the PTS is of little relevance to this
thesis,there will be no further emphasis on it.
In the second version (the card is not in the negotiable mode or supports only one type
of transmission protocol), used in this work, the transmission protocol is specified in the
lower half byte of the global interface parameter TD1. Theoretically, 15 types of trans-
mission protocols are possible. The most common protocols for Smart Cards are “T=0”
and “T=1”. This work uses the transmission protocol “T=0”. It is an asynchronous,
byte-oriented and half duplex protocol. The character frame follows the structure as
described in section 2.3.3, page 6
2 Smart Card Basics
9
2.3.5.2 Error Detection with “T=0”
Error detection with the transmission protocol “T=0” is simple since it is character-
oriented. Thus error detection and correction is only limited to a single error. Two
parameters serve for detecting errors: the parity bit at the end of each character and
the guard time. If the receiver discovers an incorrect parity, then it switches during the
guard time the I/O level from H to L. Hence, the sender will be requested to repeat the
just transmitted byte.
2.3.5.3 Data Exchange with T=0
As described in section 2.3.1, the interaction between Smart Card and card reader is
always initiated by the card reader. This command7 consists of two sections, a mandatory
header and an optional body.
The header of each command consists of 4 bytes that contain the card information about
how to proceed. The following transmission of data bytes is under control of the card
reader. The card avails oneself of procedure bytes (described in every detail in ISO 7816
Part 3). For data exchange, it is important that both communication partners know the
direction of the data exchange. For that reason, the card uses the procedure bytes.
After the transmission of the header, the reader waits for the procedure byte of the card,
because it has to indicate the next action for the reader. Table 2.1 shows the three
possible procedure bytes. This work is confined to the implementation of the ACK byte
Table 2.1: The Procedure Bytes of the Card [ISOP3]
Procedure Byte Value Result
ACK INS All remaining data bytes are transmitted subsequentlyINS next data byte is transmitted subsequently
NULL 0x60 No further actionSW1 SW1 Waiting for SW2
and the SW1. The ACK bytes are used to control the data transfer. After the execution
of a received ACK byte, the card reader waits for a new procedure byte. If the data
7The structure of the command will be explained in detail in section 2.4.
2.3 A Smart Card Session
10
exchange was successful , the card sends the Status Words(SW)8 SW1 = 0x90 and SW2
= 0x00 and the data exchange is finished.
Is is only made use of some special Status Word pairs, if the APDU exchange was
not successful. In table 2.2 are given the meaning of the expected Status Word pairs
SW1/SW2 that are implemented in the “simulated” Smart Card.
Table 2.2: Implemented status words of the card
SW1 SW2 Meaning
61 XX Normal Processing, the card reader waits for xx data bytes67 00 Wrong LEN, length of data bytes does not equal to value Lc6A 86 Wrong P1-P2, Parameter P1 and P2 not supported6C 00 Wrong LE, length of response data does not equal to value Le6D 00 Wrong INS, Instruction byte not supported6E 00 Wrong CLA, Class byte is not 0x0090 00 OK, the data exchange was successful
2.4 The Application Data Unit
2.4.1 Communication with the Application Data Unit
Communication between card reader and card makes use of application protocol data
units (APDU). This type of protocol is arranged into the application layer of the Open
Systems Interconnection Reference Model (OSI) and is independent of the transmission
protocol. There are two types of APDUs, first the command APDUs that is transmitted
by the card reader, and second the response APDUs that is transmitted by the card.
A successful exchange of information between both communication partners requires
always a command APDU acknowledged by a response APDU. Therefore, two APDUs
that belong together are also called command-response-pair. In the following two sections
the structure of the two APDUs is presented.
8The use of the Status Word SW1 and SW2 will be explained more detailed in section 2.4.
2 Smart Card Basics
11
2.4.2 The Structure of a command APDU
A command APDU, displayed in figure 2.4, represents a request of the card reader to
the card. It contains always of a mandatory header that consists of four bytes: CLA,
INS, P1 and P2. The class byte (CLA) indicates the instruction class of the command.
In this work the class 0x00 is used for the Smart Card communication. The following
byte, instruction byte 9(INS), indicates the command that has to be executed by the
application of the card. Thought, the values 0x6X and 0x9X are not permitted to use.
These values would otherwise result in a collision with the procedure bytes. The last two
bytes of the header P1 and P2 are parameter bytes used to specify the command.
Figure 2.4: Structure of a command APDU
Furthermore, the APDU can possess a body of variable length, however, the maximal
length is 255 bytes. The Lc field is, if present, after the parameter P2 and indicates the
number of data bytes transmitted in the body of a command APDU. The data field is
only available if Lc is greater than zero. It contains data, which are to be processed
by the card. The Le field is located either after the parameter P2 (if no data will be
transmitted to the Card) or after the data transmitted to the card. It indicates the
number of data bytes that are expected by the card reader in the response of the card.
Since the fields Lc and Le are optional, four cases result for the possible command APDUs
as shown in figure 2.5. The Indication of the APDUS is usually done with 1, 2S, 3S and
4S. S is used to signify the simple length (max.256 bytes) since ISO permits also an
extended APDU form.
2.4.3 The Structure of a Responds APDU
A response APDU as illustrated in figure2.6, is returned as response of a command APDU
from the card. It consists of an optional body and a mandatory Trailer. The trailer is
9Table B.2 in the appendix lists all standardized possible values for INS to the point in time of thework.
2.4 The Application Data Unit
12
Figure 2.5: The 4 cases of command APDUs
build of the two status words SW1 and SW2. The number of the body’s data bytes is
certain for the Le field in the appropriate command APDU and can amount up to max.
256 bytes.
Figure 2.6: The Response APDU
If no data must be transmitted or an error occurred with the processing of a command
APDU, only the mandatory Trailer is sent to the card reader. This contains correspond-
ing information about the nature of the error, such that the card reader can intervene
accordingly. The value of the two mandatory bytes SW1 and SW2 depends on the re-
spective instruction to be executed next. An exception in this case is the Status Word
0x9000 that indicates a successful execution of the command. In figure B.3 is given a
brief overview of building the status words SW1 and SW2. The scheme illustrates the
simplification of the table of status words10 B.3 in the appendix.
10ISO 7816 Part 4 [ISOP4]
2 Smart Card Basics
13
Part II
Hardware Implementation
14
3 Implementation of a Minimal
Operating System
3.1 Requirements of the Operating System
The focus of this part of the thesis is on presenting the merge of existing operation system
with an existing cryptographic algorithm on the “simulated” SC. The following sections
explain the procedure of implementing the “simulated” Smart Card in two steps. First,
a simple operating system on the “simulated” SC is implemented. For that purpose, an
already existing interface implementation is changed and useful Application Data Units
(APDUs) are added. Second, a simple Data Encryption Standard (DES) is used. This
algorithm implemented in C++ has been already existed and is only integrated into the
developed operating system.
Although the Smart Card does not possess hundreds of megabytes large operating system,
it is nevertheless an operating system. In general an operating system can be defined
as programmes of a digital computing system that controls and monitors the handling
of programs with the characteristic of a computer. Furthermore, the operating system
constitutes an interface between humans and machine. Unlike to other OS the Smart
Card OS possess no user interface or access opportunities for external storage media.
The small size of the operating system that enables the execution of programs and the
access on the card, which depends on validity parameters e.g. PIN or password, offers
the Smart Card as ideal medium to store secure data.
The specifications of the applied operating system like e.g. reliability, robustness, error
freeness and protection of the system against influences from outside, are dependent on
the developer and the application of the Smart Card. However, common Smart Card OS
comprise the following major tasks:
15
• Data Exchange between Smart Card and Card Reader
• Flow control of the commands
• Administration of a File System
• Administration and execution of cryptographic algorithms
The operating system used in this thesis does not consist of a file and key system, because
the principal purpose of this work is to have a software implemented cryptographic
algorithm executed by a card.
The following section introduces in the physical structure of the “simulated” Smart Card
and the interface implementation. These two sections do not describe anything developed
by the author. The“simulated”Smart Card as well as the described parts of the interface
implementation has been already existed at the beginning of this final year thesis.
3.2 The ATmega128 Test board
3.2.1 The Handling and Structure of the Board
The Smart Card shown in figure 3.1 is used in this work as a model of a real Smart
Card. Since with the real SC necessary measurements cannot be made a “simulated”
Smart Card was developed in the ENST laboratories. This “simulated” SC possesses all
necessary for components1 performing like a real card.
In order to program the microcontrollers flash (to save an individual operating system), it
is made use of a Joint Test Action Group (JTAG) interface. Before the desired operating
system source code can be used, it must be unified using the software WinAVR 2 This
software compiles and linkes the source code to obtain an executable binary file (Com-
mon Object File Format (*.cof)). Using this common object file the microcontroller is
programmed with the help of AVRStudio3 and a JTAG adapter that connects the board
(which has to be connected with 5V operating voltage) and the personal computer.
1The circuit map is given in appendix C.2.2Some more detailed instructions for the handling with WinAVR are given in section A.1.3Free ware of ATMEL
3.2 The ATmega128 Test board
16
Figure 3.1: The Testboard
If the microcontroller is programmed with the desired code, the user has to verify, if the
required clock supply is connected. As shown in figure 3.1, the board consists of a jumper,
which operates the microcontroller with external or internal clock4. It is only applied of
the jumper in the position5 to support the external clock. That arises from the fact that
the Smart Card works with the clock of the card reader. Beside the programming of
the microcontroller and the clock settings, the internal EEPROM of the microcontroller
must be programmed with the ATR6.
4The clock type has no effect to the usage of the JTAG interface5Settings of the Jumper for the processor clock, figure C.16The table in appendix B.1
3 Implementation of a Minimal Operating System
17
3.2.2 The USART Interface
3.2.2.1 The USART of the ATmega128
This section is divided into two subsections, which shortly explain the implementation of
the USART interface of the ATmega128, since the existing documentation 7 of the inter-
face does not give sufficient information about the implementation continuant. The first
subsection describes the configuration of the initial parameters. It contains the settings
for baud rate and frame format. The second subsection deals with the transmission and
reception of data. This information is sufficient to understanding the work of the Smart
Card.
The ATmega128 possesses USART0 and USART1, which use different input and output
registers. Each of the two USARTs consists of three components. Those are a clock
generator, transmitter and receiver. Additionally, each USART has control registers
shared by the three USART components. In this final year thesis, it is only made use of
USART1 to realise the reception and transmission of data between SC and card reader.
Before the USART of the ATmega128 can be used, it has to be initialised. A source code
for the initialisation of the USART interface has already existed at the beginning of this
final year project. It was written by Bowie Brotosumpeno in a student project at the
ENST. Bowie Brotosumpeno already points out in [BRO06] that for the transmission
with the USART has to allow a resistance before the TX port, see figure 3.2. This
resistance is integrated to protect the TX port in a case that the card reader and the
card transmit simultaneously. This is an abnormal case, which can occur only if one
of the partners does not respect the communication protocol, as normally the TX port
state is moved into Tri-State.
Figure 3.2: The ATmega128 - TX and RX
7Project at the ENST,[BRO06]
3.2 The ATmega128 Test board
18
3.2.2.2 Initialisation of the USART
Before any communication can take place, the USART must be initialised. This ini-
tialisation phase sets the baud rate, configures the frame format, and sets the status of
transmitter and receiver. In this work the USART initialization contains of the baud
rate definition and the frame format settings. The Receiver and Transmitter status are
implemented in separated functions, which do not take place in the initialisation of the
USART.
The initialisation parameters are set in the five USART registers. First, the USART1 I/O
Data Register (UDR1), which consists of a Transmit Data Buffer Register of eight bits
and a Receiver Data Buffer Register of eight bit lengthSecond, the three USART control
and status registers - UCSR1A, UCSR1B and UCSR1C. Third, the USART Baud Rate
Register (UBRR1), which composed of a lower and higher byte and presents a register
of 16 bit.
Setting the baud rate
The baud rate settings are made in register UBRR1 of the USART. Therefore, a symbolic
value to set the UBRR1 register must be calculated. The calculation of this symbolic
value results after equation8 3.1 using the system clock (fosc) and the baud rate (BAUD).
As stated before, the processor clock is externally referred by the card reader over the
CLK contact with 3.6864 MHz. With the knowledge of the system clock frequency the
value of the baud rate (BAUD) can be determined, as 9909,8 baud.
UBRR =fosc
16 ·BAUD− 1 (3.1)
The substitution of BAUD with the baud rate and fosc with the clock frequency in
equations 3.1 results the required symbolic value for UBRR19.
UBRR =3.6864MHz
16 · 9909.8− 1 = 22, 25 ≈ 22 (3.2)
It follows the source code cut of the baud rate settings applied in this thesis.
8Given in the data sheet of the ATmega128 [ATMEL]9The value for UBRR1 was approximated, because the register takes only integer values.
3 Implementation of a Minimal Operating System
19
/* Set the baud rate*/
uchar baudrate;
baudrate = 22;
UBRR1H = (uchar) (baudrate>>8);
UBRR1L = (uchar) baudrate;
Setting the frame format
The frame format is standardized in the ISO 7816 Part 3 and has to have the format 1
start bit, 8 data bits, 1 even parity bit, and 2 stop bits(so that the final length equals to
12 etu10).The frame format of the USART interface are set in the USART control and
status register UCSR1C. This special register consists of 7 bit, which can be set. Table
3.1 shows the configuration of the appropriate bits in the UCSR1C.
Table 3.1: Settings in Register UCSR1C
Bit name Value Meaning
UCPOL1 0 Clock Polarity, TX = rising Edge, RX = falling EdgeUCSZ10 1 USCZ10,USCZ11 and USCZ12 setUCSZ11 1 Character Size, 8 BitUSBS1 1 2 Stop BitsUPM10 0 Even ParityUPM11 1 Enable Parity, UPM10 specifies parityUMSEL1 0 Asynchronous Operation
It has to be noticed that the character size is composed by the settings of bits UCSZ10
and UCSZ11 in register UCSR1C and the bit UCSZ12 in register UCSR1B. In this case,
the character size of 8 bit the bit UCSZ12 is not set(UCSZ12=0). In addition to the
settings in UCSR1B and UCSR1C, it has to be remarked that the bit U2X1 in the register
UCSR1A11 is set to zero, which means that normal transmission speed is used.
The following source code fragment shows the frame format settings used in this final
year thesis.
/*Set the frame format */
UCSR1C = ((3<<UCSZ10)|(0 << UPM10)|(1 << UPM11)|(1 << USBS1));
10Elementary Time Unit, see appendix B.2, page 5211Table C.1 in the appendix
3.2 The ATmega128 Test board
20
4 The Operating System for the
ATmega128
4.1 The Minimal Implementation of the card OS
As already pointed out, some sections of the implemented operating system in the AT-
mega128 were already available at the beginning of this thesis. The existing source code
is transferred and afterward widely modified. Many sections of the source code have
been removed, because they are not needed for the current work. In order to allow a
data exchange between the card reader and the card, the modifications are applied to
the implemented command and response APDUs, and some error handling in form of
Status Words.
In this thesis, the first 5 bytes of an incoming APDU are interpreted as header by the
card because the header of the applied APDUs consists of one and more data bytes. For
that reason an APDU Case 1 as already shown in figure 2.5 is not considered and returns
an error in this work. After the reception of the header, the card has to analyse and
interpret them. First, the CLA byte is checked. If it equals to the supported type(in this
work 0x00)of the header the analysis will be continued, if it is unequal a response APDU
with the Status Word value 0x6E00 is sent back.
Second, the INS byte is checked. If the INS value can not be interpreted by the card the
Status Word 0x6D00 is sent back. If the INS byte is correct the associated operations will
be executed to consider the parameter bytes P1 and P2. It follows, that the execution
of a DES on the “simulated” Smart Card can be reached by an APDU whose INS byte
is interpreted by the card.
21
4.2 The Integration of individual APDUs
In this thesis, a table with 256 possible entries is created, indexed by INS values that are
pointers to the corresponding function that has to be executed. The advantage of using
a function pointer is that the INS value does not have to check, because unused INS
values are associated with an error function. As there already exist several standardized
INS1 values and each developer can add some are made use of INS values according to
the standard for test functions and the execution of DES.
Table 4.1 shows the implemented INS values with a brief description of their meaning
as described above. All other INS values are not supported by the card and will return
an error. The parameter bytes P1/P2 are only interpreted and used in the respective
function(where they are used).
Table 4.1: The implemented INS values
INS value Function Description
0x01 led set (Test) Illumination of the led on the boardin position defined by P1
0x02 des key Generation of the secret keys for DES0x03 des cipher Encipher/decipher of a message0x05 data test (Test) Testing the right reception with the USART0x06 data resend (Test) Testing the right transmission with the USART0xC0 get response Sending of enciphered/deciphered data by the cardothers error command Sending of Status Word for wrong INS - 0x6D00
4.3 Executing DES on the “simulated”Smart Card
With the integration of the thesis-specific APDUs, the second task of the thesis objective
is finished. At this point of the thesis the APDU exchange between card and card reader
is possible. To execute DES on the Smart Card is made use of three APDUs. First, an
APDU including a DES key is send. This key is used to determine the DES sub keys
that are stored in the Smart Card. Second, the plain text message is send. Where the
parameter P1 is used to decide between encipher (P1=0x00) or decipher (P1=0x01) the
message. Third, it was decided to make use of the standardized APDU Get Response,
1Standardized values, see table B.2
4.2 The Integration of individual APDUs
22
which is used by the PC to request available data that are not yet transmitted (In this
work the enciphered or deciphered message).
Table 4.2 shows the structure of the three command APDUs, Send Key, Send Message
and Get Response as well as Switch LED, which is frequently used. The structure of
the implemented response APDUs as well as the implemented Status Words in the card
have already been covered in section 2.4.3,page11 and 2.3.5.3, page9.
Table 4.2: Used Command APDUs in the project
CLA INS P1 P2 Lc Data Field Le
Switch LED - Switching on and off of the LEDs in Position P1
0x00 0x01 LED nu 0x00 absent absent
Send KEY - Send the secret key to encipher or decipher
0x00 0x02 EN/DE nu 0x08 KEY absent
Send MESSAGE - Send the message to encipher/decipher
0x00 0x03 nu nu present MESSAGE absent
GET RESPONSE - Get the enciphered/deciphered message
0x00 0xC0 0x00 0x00 0x00 absent present
4 The Operating System for the ATmega128
23
Part III
Measurement Setup
24
5 Side-Channel-Attacks
5.1 Principle of Side-Channel-Attacks
Side-Channel-Attacks (SCA) are defined as attacks that extract secret information us-
ing phenomena, which can be observed without interfering with the functions of the
cryptographic device. The aim is to find some dependence between the secret data and
observed information, obtained from analysing, for example the time or power consump-
tion during cryptographic operations. In general the analysis of side-channel-information
is effectively done with help of simple statistical methods.
Side channel information are obtained from additional outputs or inputs, do not contain
the plain text or cipher text, of the cryptographic device. Generally, the kind of Side-
Channel information are timing information (these are information about the time that
an operation takes), power consumption or electromagnetic emission (during executing
of an operation.). The real Side-Channel-Attack task is to analyse the obtained side
channel information.
The three most common attacks are the Timing Attack, which is based on measuring
of time used to perform operations, Power Consumption Attacks, which are based on
analysing the power consumption while the target device performs the cryptographic
operations and last but not least Differential Fault Attacks, which are based on generating
faults in the system that can be used advantageously for the attacker. The side channel
information from the power consumption of the target device(ATMega128) are analysed
.
25
5.2 Power Consumption
Since the power consumption of a circuit (built in Complementary Metal Oxide Semi-
conductor(CMOS) technology) is correlated with the current executing data, the power
consumption of CMOS gates will be shortly introduced. A CMOS gate consumes the
most of the power when it changes its state (from “1”→ “0” or “0”→ “1”). A micropro-
cessor consists of a several number of CMOS gates results, if more gates changes their
states at the same time, a higher power consumption can be measured.
Figure 5.1 shows a CMOS logic for an inverter like presented in the Tutorial[ATDPA].
To monitor the power dissipated by the inverter a small resistor Rm is applied in series
between Vss and ground. In general the inverter consists of a PMOS transistor and a
NMOS transistor. If the gate works in a stable state, only a very small current (statical
power consumption) between Vdd and Vcc can be monitored, this will be ignored. The
most power consumption (dynamical power consumption) can be measured during a
change of the gates state. It can be divided in two parts. First, the dynamic short circuit
current, which occurs from the two transistors that conduct at the same moment if the
state changes. Second, the dynamic charge respectively discharge current of a capacitive
load at the output of each gate. This capacitive load, results of the parasitic capacity of
the connected wires and gates in the following stages.
Figure 5.1: Inverter with CMOS technology [ATDPA]
5.2 Power Consumption
26
A Side Channel Attack, in particular power consumption analysis uses the knowledge
of the correlation between power consumption of the circuit and operations, which are
executed by the circuit. However, as mentioned in the tutorial by Manfred Aigner and
Elisabeth Oswald [ATDPA], the measured current flow can only detect whether a tran-
sition occurred or not. It cannot be distinguished between a raising transition and a
falling transition.
5.3 Power Consumption Analysis
5.3.1 The Differential Power Analysis
Differential Power Analysis(DPA) is one among several power consumption analysis. In
this work the DPA is used to break the secret key of a software implemented DES
algorithm. According to E. Hess et.al [HES06] who describes the DPA as follows,
“Differential Power Analysis(DPA), introduced by Kocher et.al [23,24], is
an attack that allows one to obtain information about the secret key by
performing a statistical analysis of the power consumption measured for a
large number of computations with the same key.”[page 5, Line 1-3 [HES06]]
The realisation of a DPA attack requires the following information.
The attacker
1. must be able to capture the power consumption of the target device.
2. needs information about the target algorithm.
3. has to know the plain text or the cipher text.
In this thesis the DPA attack is made on a simple DES1 algorithm. It was also arranged
to try a so-called “known plain text attack”. The following two sections describe the
analysis method used in this thesis to realise the DPA attack.
1Encryption algorithm published by the National Institute of Standards and Technology [URL08]
5 Side-Channel-Attacks
27
5.3.2 The Hamming Distance Model
This section describes a Hamming Distance Consumption Model, as proposed in [BRI04]
that is made use of in this final year thesis to realise a DPA attack. This model assumes
that the information about the power consumption of the circuit depends on the number
of bits that are switched from one state into an other at a given time. Furthermore, is
assumed that the consumed current and the energy to flip bits are related. For the thesis
purpose, it is admitted that the switching from “1”→ “0” or “0”→ “1” requires the same
amount of energy. It follows, that given the number of switched bits some dependency
between power consumption and data can be found.
The model introduced in the paper of Eric Brier et.al[BRI04] determines the hamming
distance between two words. It is assumed that the first word D is a uniform random
variable and the second unknown constant machine word R. The hamming distance,
which is calculated by H(D⊕R) describes the number of flipped bits. They also assume a
linear relationship between the current power consumption and the value of the hamming
distance.
In this thesis is applied the basic model for the data dependency of Brier et.al[BRI04]
under the condition a = 1(scalar gain between H and W) and b = 0 (offsets, timing
dependent components, noise). So that follows from this:
W = H(D ⊕R) (5.1)
W - Power consumed
H - Hamming distance between word D and R
5.3.3 The Correlation Analysis
The analysis of captured traces from the laboratory to realise the Differential Power
Analysis is the main part of this work. Therefore, an analysis method is required. It is
made use of a the correlation analysis as described in [ENS06] and [PIR05]. The principle
consists of three main steps:
5.3 Power Consumption Analysis
28
1. The attacker observes P encryption operations and captures the corresponding
power trace T.
2. The attacker guesses a part of the secret key and determines interim results for
each plain text P. Afterward, a power consumption model is required to weight
the the captured traces. The hamming distance model described in section 5.3.2is
made use of to weight each trace.
3. Finally, a correlation function is required to find out, whether the guessed key was
right or wrong. It is applied of the correlation function from a further project
[ENS06]:
∆k =
∑N−1i=0 Hi,k · Ti −
PN−1i=0 Hi,k
N·∑N−1
i=0 Ti
N(5.2)
where:
• N is the total number of traces
• i is in the range of 0 to N − 1
• k is in the range of 0 to 26 − 1
• Ti is the i-th trace
• Hi,k is the Hamming Distance between the previous and current state for the
guessed key k and the corresponding trace i
The equation 5.2 was simplified in [ENS06] with the assumption that for a set
X = Xi, i ∈ [0, N [, the empirical mean X is defined by X = 1N
∑N−1i=0 Xi then:
∆k = Hk · T −Hk · T (5.3)
If the key guess is right the hamming distance correlates with the trace in the point
where the same bits are used in the cipher operation. If now all traces weighted with
the same hamming value are finally added all resulting traces, a peak will be developed
in the region where the concerned bits are processed. The rest of the trace will not be
correlated with the guessed value. If the key guess is wrong, however, the captured traces
will be uncorrelated. A noise flat trace tending to zero will be expected.
5 Side-Channel-Attacks
29
6 The Implemented Data Encryption
Algorithm
The Data Encryption Standard is the focus of these investigations. It has to be analysed
and afterward attacked by Side Channel Attacks that aim at finding the secret key. It
was sufficient for this project to understand the principle of the algorithm and to be able
to analyse the implemented version. Therefore, it is not dealt with the mathematical
description of the DES algorithm.
The DES is a block cipher with 64 bit block length and 56 bit secret key, published by the
National Institute of Standards and Technology (NIST) [URL08]. The algorithm has a
Feistel-Structure and consists of 16 rounds. To encipher and decipher the 64 bit message,
it is divided into a left and a right block with 32 bits each. Afterward the rights block is
combined with a sub key Kn, whereby n is the number of rounds, as shown in figure 6.1.
Subsequently, the resulting 32 bits are added to the current left block. The result of the
addition becomes the right block of the next round. Then the old right block becomes
the left block of the next round.
The algorithm is implemented by an already existing code that is part of “OpenSSL”1.
Nothing has been changed at the functions in the code in this thesis, but the implemen-
tation is not easy as written by NIST. However, it is essential to understand the specials
of the used implementation to ensure that the DPA can be successful.
In this thesis the attacker is interested in the operations, where the first sub key K1
is used. Being apparent from figure6.1 the key is used for a XOR operation with the
message. This operation will be shown in more detail for the applied implementation.
Extracting from the source code of the used DES the left and right block are shifted one
bit left after the initial permutation(IP), that is why, the bit in position 1 is shifted to
1OpenSSL is an open source implementation of the SSL and TLS protocols. www.openssl.org
30
the position of bit 32. The reason of this shift operation is a simultaneous calculation of
expansion of block right and XOR with the sub key K1.
Figure 6.1: The DES in General
For that reason the input bits for the Sboxes are divided in two operation flows. First,
the Sbox inputs for S7, S5, S3, S1, where the right block is shifted 4 bits right due to the
integration of the expansion into the calculation. Second, the inputs for S8, S6, S4 and
6 The Implemented Data Encryption Algorithm
31
S2, with the right that is shifted, 1 bit only. In table6.1 the several required bits of the
block right as input for the Sboxes are displayed. Since the block right consists always
only of 32 bits, the right block was shifted such a way that the resulting block has the
structure, 2 bit not used, 6 bit used for the Sbox. For example, for Sbox 1 the required
input bits are the bits on position 32, 1, 2, 3, 4 and 5 of block right.
Table 6.1: The DES Expansion
SBOX Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6
S1 32 1 2 3 4 5S2 4 5 6 7 8 9S3 8 9 10 11 12 13S4 12 13 14 15 16 17S5 16 17 18 19 20 21S6 20 21 22 23 24 25S7 24 25 26 27 28 29S8 28 29 30 31 32 1
It is hardly considered, that the key has to have always the same structure for the
calculation as the message. That is, for the operation exclusive or of message and sub
key, before the Sboxes that the sub key must have the same structure as the message,
i.e. in this case 2 bit zero, 6 bit sub key, because the round sub key is divided in two
parts of 24 bit(48 bit). The following figure 6.2 shows the XOR operation of the round
sub key and the data applied for the implemented algorithm.
32
Figure 6.2: Explication of the implemented DES
6 The Implemented Data Encryption Algorithm
33
7 Measurements with the ATMega128
7.1 The Laboratory Test Bench
This section describes, first the hardware equipment that is necessary to capture the
power consumption of the target circuit, and second an acquisition software that provides
the collection of a large number of side channel data from the target device.
The hardware equipment, to realise the electronic measurements on the target device,
consists of(see figure 7.1):
1. An AGILENT 54855A high-speed oscilloscope, which is able to sample with 40GSam-
ple per second. To synchronise the oscilloscope and the ATmega128, the circuit
generates a trigger signal.
2. A Personal Computer (PC) with a General Purpose Interface Bus (GPIB) to control
the oscilloscope, an Ethernet interface to transfer the captured traces from the
oscilloscope to an other hard disk, and an RS232 interface to control the card
reader GCR410.
3. A target circuit, in this case the ATmega128 that is connected with the oscilloscope
and the card reader.
The trigger for the oscilloscope
As already mentioned the oscilloscope is triggered by the target device. This trigger signal
will not be available in real attacking scenario, but simplifies the capturing of the traces.
To realise the trigger with the ATmega128 an additional Port is implemented as output
and the source code of DES is modified to control this bit.(It is added the two in line as-
sembler, asm volatile ("sbi 0x18,0x07;")and asm volatile ("cbi 0x18,0x07;"))
34
Within the context of this thesis,it is being made use of the software acquisition campaign1
that has already existed. This acquisition software controls all devices for the DPA, if
they are configured and the relevant functions are added. It was developed by Sylvain
Guilley et.al[ENS06] and is used in this work with the addition of two functions for the
card reader GCR410. First, the ATR request to start the Smart Card session, and second
the three APDUs to execute DES on the Smart Card.
To start the capturing of consumption traces the desired software parameters for the
target devices have to be set. In this thesis the following parameters of the acquisi-
tion campaign software are used.
• -t (target device) ATMEGA
• -a (used algorithm) DES SW
• -k (a fixed key) e.g. 0123456789ABCDEF
• -n (the number of traces) −1 → undefined
• -d (Interface for the card reader) /dev/ttyS0
• -s (a stored setup) setup atmega.set /setup atmega all.set
1Additional information about the acquisition campaign software are available from [ENS06].
7 Measurements with the ATMega128
35
7.2 Measurements with the ATmega128
7.2.1 Power Consumption of the ATmega128
Before beginning measurements with the ATmega128, it had to be checked if it was
possible to detect the 16 rounds of the DES algorithm. Therefore, the first channel of
the oscilloscope is connected with the trigger output and the third channel is connected
with the contacts of a low-resistance resistor of 47Ω to monitor the power consumption
of the circuit. The figures 7.1 and 7.2 shows two captured power consumption traces
that both shows clearly the 16 DES rounds.
The first captured trace shown in figure 7.1 is obtained from the DES with an optimized
compilation mode. The analysis with the oscilloscope and the disassembled code, which
is obtained from AVR Studio, shows that, most of the power consumption by the micro-
processor is made, when it has to load data from the SRAM into the registers. To prove
this supposition the trace is analysed more detailed, as shown in figure7.3. As results
from the data sheet [ATMEL] a load command in assembler costs two clock cycles, that
is, if 4 registers are loaded 8 clock cycles can be captured. At last the detailed analysis
of a single peak7.3 hardly proves that the ATmega consumes the most power during
executing load operations.
The comparison of the non-optimized compiled DES and the optimised compiled DES
captures shows that the power consumption for the optimized version is only concentrated
on load operations. Thus, the non-optimized power consumption captures provide more
distinguishable information. In the non-optimized version,the load operations are not
the only ones that consume more power. Although the executing time is ≈ 2, 068ms
(optimized DES) and ≈ 5, 614ms (non-optimized DES), it was decided to continue the
measurements with the non-optimized source code compilation regarding the maximum
side channel information.
Table 7.1: Measurement Setups for with optimization
Sampling Rate 250 MSa/sAveraging 256 InterpolationScale Ch1 639mV Offset 2.257VScale Ch3 85mv Offset 560mVTime base 220µsTime for DES 2.068ms
7.2 Measurements with the ATmega128
36
Figure 7.1: The 16 DES rounds: with optimization
Table 7.2: Measurement Setups for without optimization
Sampling Rate 125 MSa/sAveraging 4 InterpolationScale Ch1 1V Offset 1VScale Ch2 1V Offset 1.8VScale Ch3 100mV Offset 594mVTime base 575µsTime for DES 5.614ms
7.2.2 Capturing Power Consumption Traces for the DPA
The final task to approach the thesis objective is to capture power consumption traces
for the DPA attack. Before the measurements starts, it has to be decided whether the
DES will be attacked in the first or last round of DES. For the usage in another round
must guess a too big part of its key. In this thesis, the first round has been chosen .
7 Measurements with the ATMega128
37
Figure 7.2: The 16 DES rounds: without optimization
This decision has some several reasons. First, the first round was chosen, as the aim
is to realise a known plain text attack that is easier to do in the first round (since the
input message is known). Second, with the decision to attack the first round, the capture
window of the consumption traces can be reduced. Thus more traces can be captured
using the same resources.
To optimize the exact duration of the first DES round, a third signal is added (the same
way as the trigger). Caused by the impedance of 50Ω for the oscilloscope inputs, and
the absence of impedance converters a Port-Pair (PortB6/PortB4) for using a Jumper
adapter2is created.
After the configuration of the oscilloscope setups to capture only the first round of DES,
a set of traces of the current power consumption during processing DES are captured.
All traces of one measurement series must use the same key but different messages. This
simplifies first DPA attacks. Note, that there has to capture a sensible number of traces.
In this work the number of traces is limited by the 10GByte hard disk of the oscilloscope.
2See figure3.1, page16
7.2 Measurements with the ATmega128
38
Figure 7.3: Power Consumption for LOAD
This corresponds to around 4000 traces captured with 2GSa/s and an average of 32.
7.3 Analysis of the Power Consumption Traces
7.3.1 The Analysis Programme
An analysis programme is the main part of the DPA attack. This thesis makes use of
the analysis programme do dpa, which is developed by Sylvain Guilley et.al[ENS06] and
has already existed at the beginning of this thesis. Its analysis algorithm bases on the
theoretical descriptions of chapter5 and had to be adapted for this work. As well as the
acquisition programme can be chosen different parameters. 3
3Parameters: –weight sw hamming dist, –sorting unix
7 Measurements with the ATMega128
39
In general the analysis programme is written for DPA attacks to find a 6 bit sub key
part of the DES master key. Therefore, the attacker needs information about the plain
text message. In addition, the DES key is extracted from the traces name. With the
knowledge of the plain text message and the DES key the attacker can make a right guess.
Normally, the key guess is more difficult, because the attacker do not have information
about the secret key. It has been started with a known key and a known message, since
it was uncertain in the beginning whether the DPA attack can be make successful on the
software implemented DES.
7.3.2 The Hamming Distance Selection Function
The following section describes a hamming distance selection function. This selection
function is added to the analysis programme in this thesis and calculates a hamming
weight that is used to weight the power consumption traces and obtain a correlating peak
in analysis trace. The main idea of the analysis programme is to reproduce an operation
value, which depends on the key and calculating its hamming weight. However, the
problem is not to calculate the hamming distance of two words. The first problem is to
find a microcontroller operation that consumes enough energy to be analysed. And the
second problem is to know all information necessary for reproducing the operation. To
solve the problem finding a good operation, the disassembled code of the implemented
DES is used. This code provides information about the kind of operation that can be
attacked. Two operations as derivate from the assembled code are dependent on the key
first, the XOR operation to cipher the message and second, the selection functions for
the Sboxes that are organised in look up tables. In general the DPA attack can be made
on the working registers, which changes their content (XOR operation) and the address,
where data is stored (lookup tables). In this thesis, the working registers used for the
XOR operation key ⊕message are attacked.
The hamming distance selection function written in this work reproduces the XOR op-
eration of key and message. Therefore, a simulation programme extracts the message
and the key from the trace name. Then the programme calculates all DES values using
the same algorithm as running on the card. These results are now used to determine
the individual hamming distances for the traces to weight them. Normally, for a key
guess are 26 = 64 possibilities that have to try for each trace. Since in this thesis the
7.3 Analysis of the Power Consumption Traces
40
analysis calculation is only done for one key, namely the guessed key all captured traces
are weighted with only one hamming weight and added to one analysis trace.
It is made use of the selection function ks[0][3]=(ks[0][3]^message), where ks con-
tains a 8 bit word carrying 6 bit of the round key and message, which contains 8 bit plain
text. It was decided to build a hamming distance selection function, which depends on
key and message, because the dependency only on the key causes the same hamming
weight for all traces, since the key do not change in this work. It follows from this,
that the average of all traces will be zero. However, if the selection function depends on
message and key some more correlating regions will be obtained.
7.4 The Analysis Results
7.4.1 The key guess
One of the main parts in this thesis is to prove the analytical results. In general all
analysis traces are shaped like shown in figure 7.4. It can be easily proven that the
analysis produces more than one peak. However, in comparison with other analysis
results one outstanding peak (with an amplitude of ≈ −0.052mV ) near to the Sample
180000 is developed. Note, that due to the limitation of storage, only three measurement
series (key=0123ABCD4567FE98, key=d562bc54a4e55283 and key=34644ab5679dd697)
could be obtained.
To ensure that the obtained peak is dependent on the key, an incorrect key was tried.
The theory suggests that there are no correlations if the guess is wrong. The comparison
of right and wrong key guess, as shown in figures 7.5,7.6 and 7.7 proves that there is no
dependency for the wrong key at the right sample point. However, it is possible that for
other measurement series some determinations data correlates with the trace, because
the hamming distance selection function bases on the message and the key. In this case,
a peak can be developed beside or in point of the right peak.
7 Measurements with the ATMega128
41
Figure 7.4: The Analysis Result of the First DES Round
Figure 7.5: Comparison of key guesses for key 0123ABCD4567FE98
7.4 The Analysis Results
42
Figure 7.6: Comparison of key guesses for key d562bc54a4e55283
Figure 7.7: Comparison of key guesses for key 34644ab5679dd697
7 Measurements with the ATMega128
43
7.4.2 The DPA on the working registers
This section describes the results of a DPA attack on a software implemented crypto-
graphic algorithm executed on a “simulated” Smart Card. As mentioned before, it is
chosen a DPA on the working registers of the target circuit. For the attack the registers
R24, R25, R26, and R27 are chosen. As can be seen from the disassembled code extract
in table 7.3 changes of their content depend on the key.
For the hamming distance selection function, it is important to know the previous and
the current state of the register to attack them. In this work, it can be seen that the
previous state of the registers R24 until R27 contains the key. Then, the register values
are XORed with the register values of R18 until R21 and result is stored in R24 until
R27. Using that information the DPA analysis is started.
Table 7.3: Disassembled DES source code for Message XOR key
Operation Registers Clock cycles Description1 LDD R30,Y+3 2 Load Key address2 LDD R31,Y+4 2 Load Key address3 LDD R18,Y+9 2 Load Message4 LDD R19,Y+10 2 Load Message5 LDD R20,Y+11 2 Load Message6 LDD R21,Y+12 2 Load Message7 LDD R24,Z+0 2 Load Key8 LDD R25,Z+1 2 Load Key9 LDD R26,Z+2 2 Load Key10 LDD R27,Z+3 2 Load Key11 EOR R24,R18 1 Message XOR Key12 EOR R25,R19 1 Message XOR Key13 EOR R26,R20 1 Message XOR Key14 EOR R27,R21 1 Message XOR Key15 STD Y+9,R24 2 Store Message16 STD Y+10,R25 2 Store Message17 STD Y+11,R26 2 Store Message18 STD Y+12,R27 2 Store Message
The analysis results of the DPA attack are given in figure7.8 , 7.9 and 7.10. It is shown
that in the analysis traces developed some significant peaks, beside some peaks caused
by the correlation of the message. Furthermore, the order of the attacked registers is
clearly visible. Since it was difficult to find the agreements between disassembled code
7.4 The Analysis Results
44
and captured trace an additional signal is added on the ATmega128. To discover whether
the analysis result corresponds to the XOR operation , the clock and the added signal
are captured, which restricts the operations of message⊕key to superimpose them with
the analysis trace.
Finally, the assumption that the developed peaks correspond to the operation message⊕key cannot be proved. However, with the knowledge of the clock cycles from the dis-
assembled code (in table 7.3) and the superimposed analysis curves7.8,7.9and 7.10, the
region of the peak and the corresponding operation can be specified. In this case, the
developed peaks correspond to the storage operations.
The resulting peaks do not fall on the desired operation XOR. However, they fall on
the storage operation, as shown in figures 7.8,7.9and 7.10 that stores the result of the
XOR (key⊕message) in the RAM, directly after its execution. Interpreting this result,
it was discovered that the microcontroller consumes insufficient energy during a XOR
operation to be analysed. However, the subsequent storage operation, which handles the
same correlating data, consumes sufficient energy to be analysed. The results obtained
from the DPA has not been expected, but it proves that not any operation can be attacked
by the DPA attack.
Figure 7.8: DPA attack: key 0123ABCD4567FE98
7 Measurements with the ATMega128
45
Figure 7.9: DPA attack: key 34644ab5679dd697
Figure 7.10: DPA attack: key d562bc54a4e55283
7.4 The Analysis Results
46
8 Conclusion
Results
The implementation part for the“simulated”Smart Card has shown that is not necessary
to implement a whole Smart Card operating system to realise Differential Power Attacks.
It is already sufficient to implement the communication interfaces and the possibility to
interpret Smart Card reader commands.
Furthermore, it could be seen that the attacker has to know details information about the
algorithm, that is to be attacked. The Principle does not change, however the algorithm
specifications are necessary in order to attack the system in the right way. In this
work was shown that the compilation mode of the Data Encryption Standard strongly
influences the trace shape.
The analysis part of this thesis shows that the register used for the XOR operation could
not attacked in the desired way. However, some peaks are developed for the subsequent
storage operation. That is, that the power consumption of the assumed XOR operation
is insufficient for the DPA attack.
Future Works
There are several ideas, worth being proposed for future works. First, with the knowledge
that the power analysis results fall in the region, where the correlated data is used, one has
to check the assumed interpretation(that the power consumption for the XOR operation
is insufficient for the DPA).
Second, to judge whether the analysis software works correctly for the implemented DES
the capture window of the power consumption could be reduced. This offers the attacker,
47
first the possibility to capture more traces(> 4000) with a higher sampling rate and it
follows that the correlation function becomes more precise.
Changing the selection function for the attack might be another interesting aspect of the
further analysis. The hamming weight might not be sufficient for a successful attack.
Furthermore, it could be tried to integrate another cryptographic algorithm, such as,
AES or Triple-DES and attacking them.
49
A The Software Equipment
A.1 The WinAVR Notepad
“WinAVR is a suite of executable, open source software development tools for the Atmel
AVR series of RISC microprocessors hosted on the Windows platform. It includes the
GNU GCC compiler for C and C++.” homepage, [URL05]
The next only brief introduction to WinAVR refers particularly to this project. For a
general introduction to WinAVR the reader is asked themselves to serve of appropriate
sources to get detailed information. In this section it is pointed out, how was proceeded
in the project and which changes were made.
The output files of WinAVR can be used afterward to simulate or program the desired
microcontroller in AVR Studio. Around to create a project in WinAVR and obtaining
the required output files, the following steps are necessary.
First Step: Create a project In order to be able to compile the source code of AT-
mega128 a project must be created in WinAVR. It is to be noted, that the adjustments
described in [URL06] must be kept. After the creation of the project, the individual
source files can be added to the project. All kinds of source files may be added, since
the instructions for compiler and linker are indicated in the projects Makefile. Now, it
is necessary to create a MAKEFILE for the project to obtain an executable file. In this
case the WinAVR builds a binary file called Common Object File Format (COFF), which
is required for the AVRStudio.
Second Step: Modification of the Makefile for the ATmega128 If all adjustments
of the Software were made, now the standard Makefile of WinAVR has to be changed
for the ATmega128. Under c : \WinAV R\sample was already a finished Makefile, into
which only the file names must be registered. Here also desired compiler and linker
parameters can be modified. The following changes and adjustment were done in this
project:
• The architecture ARCH=atmega128
50
• The Target file name TARGET = main
• The List of C source files SRC = $(TARGET).c errno.c timer.c usart.c led.c
mem.c cmd_liste.c exchange_data.c trigger.c d3des.c
• The List of Assembler source files ASRC = ram_data.S
• The Debugging format for avr-gcc DEBUG = stabs, [default]
• The Optimization level OPT = 0
The optimization of the code was set to zero to obtain all arithmetic operations of the
microprocessor, needed for a analyse of the disassembled code later.
Now everything is prepared to build the executable file using the Makefile. At first make
all must be called under menu → Tools. Make all compiles and links all files to the main
file. At next make coff or make excoff, depending on the AVRStudio version, has to be
called. Make coff and make excoff must be added at the beginning by the user. How it
was already mentioned in paragraph A.1. The makefile has also built the file main.hex,
which is needed for programming the flash of the ATmega128. In this project the file
eeprom.hex for programming the internal EEPROM has already exist and was not
changed.
Now linker errors occur, since some files do not contain the standard libraries with the
necessary functions, like io.h. Sometimes the user has to configure the path specification.
In this project with the used version of avr-libc the path for the I/O library had to be
indicated as avr/io.h instead of io.h.
A.2 The AVRStudio
“AVR Studio 4 is the new professional Integrated Development Environment (IDE) for
writing and debugging AVR applications in Windows 9x/NT/2000/XP environments.
AVR Studio 4 includes an assembler and a simulator.” , homepage [ATMEL]. The
reason to use AVR Studio was to program the ATmega128. This tool provides more
applications, which are not used in this project. The simulation application of this tool,
could not used efficiently, because the running programme waits for input data after the
ATR of the card. The input registers can be manipulated, but it is very painstakingly
detailed work to change ale registers.
51
After generating the .cof using WinAVR, this file has to be opened in the AVR Studio.
The tool asks to choose the microcontroller and loads the programme to simulate. In
general this step is not necessary, because all needed files are generated by the WinAVR
software. If the card is correctly connected with the computer over the JTAG interface,
the programming of the microcontroller can be done directly. The user has to choose the
files (.hex) for the EEPROM and the Flash memory. It has to be pay attention, that the
connection between card reader and PC is only successful, if the voltage on the board is
connected and switched on.
52
B Smart Cards
B.1 Electronic contacts of Smart Cards
Figure B.1 displays the standardized electrical contacts of a SC. The I/O contact is
used for serial data exchange between smart card and card readers. Only one contact
is available to exchange data. The communication mode over this interface is selected
by a transmission protocol specified in ISO 7816. The Vpp contact was originally used
to make available a programming voltage for the EEPROM. This contact finds hardly
any applications today. The CLK contact makes the external clock feed-in available
needed for the SC. The Vcc contact supports an external feed-in voltage for all TTL
components.
Figure B.1: Schema Microprocessor Card with ATmega128
B.2 The Elementary Time Unit
The nominal duration for a bit used in I/O is defined as one Elementary Time Unit (etu)
and can be calculated by the equation
1
D· F
fi
= 1etu (B.1)
• D bit rate adjustment factor
• F clock rate conversion factor
• fi external clock frequency in MHz
53
Cards with a baud rate of 9600 baud using the internal clock have a initial etu of (1/D) ·(372/3, 5712MHz) = 1 etu ≈ 104, 16µs,where D = 1 . In this work the external clock
CLK is used for the card. Since the card reader GEMPLUS does not possess a initial
clock rate of 3,5712 MHz but 3,6864 [GEM98]. In this case the initial etu is calculated
in equation B.2 for the values D = 1 and F = 372 used in this work.
372
3, 6864 · 106Hz= 1etu ≈ 100, 91µs (B.2)
B.3 The ATR frame
The Initial Character TS
The initial symbol is the first symbol of the ATR string and provides a bit synchro-
nisation sequence. Additionally, it defines the conventions to code data characters and
subsequence characters. Figure B.2 shows the structure of TS for direct conversion, which
can be adapted for inverse conversion. The first four bits are used for bit synchronisation
LHHL, defined by the start bit L, and the first three bits of the character. The following
three bits decide the used conversion for the data bits. The last three bits are used for
parity checking. If TS equals hexadecimal 3B direct convention is used, logical one is
one and LSB is first. In this work is exclusively employed the direct conversion.
Figure B.2: The Initial Character for direct conversion
The Format Character T0
The Format Character follows the initial character and contains two parts of informa-
tion. The most significant half byte of the Format Character indicates the presence of
the Interface characters TA1,TB1,TC1 and TD1. The less significant one indicates the
number of historical bytes in the ATR string.
The Interface Characters TAi, TBi, TCi, TDi
The interface characters are divided into global interface characters and special inter-
54
face characters. The global interface characters are independent from the protocol type
and convey information used to calculate parameters which are needed by the inter-
face device as well as the protocol type. There are five parameters defined by the
global interface characters F, the clock rate conversion factor, D the bit rate adjust-
ment factor, to determine the work etu. The parameters I and P defining the active
state at Vpp, where I defines the maximum programming current and P the program-
ming voltage. The last parameter N defines the extra Guard time. The tables for the
possible values are available in ISO Part-3 [ISOP3]. The default values are given by
F = 372, D = 1, I = 50, P = 5, N = 0.
Historical Characters
The historical characters, with a maximal length of 15 bytes, contain general non-
standardised information about the smart card; for example, the card manufacturer,
the chip type, the date, and the version of the operating system.
Table B.1: The ATR stored in the EEPROM,[BRO06]
Character Name Value Description
Initial TS 0x3B Direct convention
Format TO 0xF4 TA1, TB1, TC1 and TD1 are present,four historical bytes are present
Global Interface TA1 0x11 FI=0001 → F=372DI=0001 → D=1
TB1 0x00 Vpp not presentTC1 0x05 Guard time = 5 etuTD1 0x40 TC2 is present
Special Interface TC2 0x18 Work waiting time for T0
Historical T1 0x06 yearT2 0x02 yearT3 0x02 monthT4 0x0F day
B.4 The APDU - Get Response
The APDU GET RESPONSE does not posses a data field. It is used by the PC to request
available data that are not yet transmitted. For that reason the GET RESPONSE
55
command has an indication of the number of expected data bytes in its Le field, which
are transmitted by the corresponding response. The length of the available data is
determined from the previous status word of the preceding command-response pair. This
status word has the form 61xx, where xx specify the length in bytes of the available
data.
56
Table B.2: Commands of ISO 7816 [ISOP4]
Command name INS Value
ACTIVATE FILE 44APPEND RECORD E2CHANGE REFERENCE DATA 24CREATE FILE E0DEACTIVATE FILE 04DELETE FILE E4DISABLE VERIFICATION REQUIREMENT 26ENABLE VERIFICATION REQUIREMENT 28ENVELOPE C2,C3ERASE BINARY 0E,0FERASE RECORD 0CEXTERNAL AUTHENTICATE 82GENERAL AUTHENTICATE 86,87GENERATE ASYMMETRIC KEY PAIR 46,47GET CHALLENGE 84GET DATA CA,CBGET RESPONSE C0INTERNAL AUTHENTICATE 88MANAGE CHANNEL 70MANAGE SECURITY ENVIRONMENT 22PERFORM SCQL OPERATION 10PERFORM SECURITY OPERATION 2APERFORM TRANSACTION OPERATION 12PERFORM USER OPERATION 14PUT DATA DA,DBREAD BINARY B0,B1READ RECORD B2,B3RESET RETRY COUNTER 2CSEARCH BINARY A0,A1SEARCH RECORD A2SELECT A4TERMINATE CARD USAGE FETERMINATE DF E6TERMINATE EF E8UPDATE BINARY D6,D7UPDATE RECORD DC,DDVERIFY 20,21WRITE BINARY D0,D1WRITE RECORD D2
57
Table B.3: Standardized Status Words for Error and Warning Conditions [ISOP4]
SW1 SW2 Meaning
62 00 No information given02 to 80 Triggering by the card
81 Part of returned data may be corrupted82 End of file or record reached before reading Le bytes83 Selected file deactivated84 File control information not formatted85 Selected file in termination state86 No input data available from a sensor of the card
63 00 No information given81 File filled up by the last writeCX Counter from 0 to 15 encoded by X
64 00 Execution error01 Immediate response required by the card
02 to 80 Triggering by the card
65 00 No information given81 Memory failure
68 00 No information given81 Logical Channel not supported82 Secure messaging not supported83 Last command of the chain expected84 Command chaining not supported
69 00 No information given81 Command incompatible with file structure82 Security Status not satisfied83 Authentication method blocked84 Reference data not usable85 Condition of use not satisfied86 Command not allowed(no current EF)87 Expected secure messaging data object missing88 Incorrect secure messaging data object
6A 00 No information given80 Incorrect parameters in the command data field81 Function not supported82 File or application not found83 Record not found84 Not enough memory space in the file85 Lc inconsistent with TLV structure86 Incorrect parameters P1-P287 Lc inconsistent with parameters P1-P288 Referenced data or reference data not found89 File already exists8A DF name already exists
58
Figure B.3: Scheme of the status word SW1 - SW
59
C The microprocessor ATmega128
Transmission and Reception with the USART
As already mentioned at the beginning of this section, the transmitter and receiver status
are implemented seperatly. Bowie Brotosumpeno has written an enable and disabel
function for transmitter and receiver (It results four indiviual functions). Seperation of
the source code and creation of interchangeable modules is the aim of such a programming
style and can therefore easyly used in further functions.
The reason for these functions are the haofduplex communication mode. Since the US-
ART can only receive or transmit data. The following two paragraphs give information
about the implementation of the enable and disable function done by Bowie Broto-
sumpeno as well as a short explanation of their application.
Transmission with the USART
Before data are transmitted over the USART, must be set the Transmit Enable Flag
(TXEN1) in the UCSR1B register and the frame format as well as the baud rate must
be defined. The pertinent programme lines to enable and disable the transmitter are:
• UCSR1B |= ( 1 << TXEN1 ); to enable the transmitter
• UCSR1B &= ∼( 1 << TXEN1 ); to disable the transmitter
If the transmitter is enable a data exchange can take place. The transmission is initi-
ated by loading data in the transmission buffer. Therefore the CPU writes the sending
data into the UDR register. If the transmit shift register, which carrys the tranmis-
sion data out, is ready to send new data, the content of the transmit buffer (UDR)
is load in the transmit shift register to be transmit with the agreed baud rate1. In
order to check if the transmit buffer is ready to get new data, is used the Flag Data
Register Empty (UDRE) of the UCSR1A register. How the programme line shows is
1The reader is invited to consult the ATMega128 data sheet [ATMEL] at page 171, for a betterunderstanding
60
constantly examined, whether the transmit buffer is empty, before new data are loaded.
while(!(UCSR1A &(1<<UDRE1)) ); UDR1 = data; In addition, is made use of the flag
Transmit Complete (TXC), which is set in the UCSR1A. This flag is set to one if the
entire frame of the transmit shift register has send all data, and no new data are present
in the transmit buffer. The corresponding source code used in this final year thesis reads
as follows: while ( !(UCSR1A & (1<<TXC1)) );.
Reception with the USART
The reception is similar to the transmission and makes use of similar fuctions. Like
the Transmit Enable Flag for the transmission, must be set the Receive Enable Flag
(RXEN1) in the UCSR1B register for a successfully reception. The pertinent programme
lines display the enable and disable operations for the receiver:
• UCSR1B |= ( 1 << RXEN1 ); to enable the receiver
• UCSR1B &= ∼( 1 << RXEN1 ); to disable the transmitter
If the receiver is set enable, the reception of data takes place. The reception always
starts if the receiver detects a valid start bit. The following bits of the frame will be
sampled with the agreed baud rate and shifted into the receive shift register until the
first stop bit of the frame is detected. The second stop bit is ignored by the receiver. If
the transmitted frame is completely present in the receive shift register it will be moved
into the receive buffer, and can be read by reading the UDR.
Figure C.1: Settings of the Jumper for the processor clock
61
Table C.1: The Control and Status Registers UCSR1A
Bit Name Description
0 MPCM1 Multi-Processor Communication Mode1 U2X1 Double the USART transmission speed2 UPE1 Parity Error3 DOR1 Data OverRun4 FE1 Frame Error5 UDRE1 USART Data Register Empty6 TXC1 USART Transmit Complete7 RXC1 USART Receive Complete
Table C.2: The Control and Status Registers UCSR1B
Bit Name Description
0 TXB81 Transmit Data Bit 81 RXB81 Receive Data Bit 82 UCSZ12 Character Size3 TXEN1 Transmitter Enable4 RXEN1 Receiver Enable5 UDRIE1 USART Data Register Empty Interrupt Enable6 TXCIE1 TX Complete Interrupt Enable7 RXCIE1 RX Complete Interrupt Enable
62
Figure C.2: Overview of the µ processor
63
D The Data Encryption Standard
Figure D.1: The Key Scheduling
64
Figure D.2: The combination of sub key and right block
65
Bibliography
[ATDPA] Aigner, M. and Oswald, E. , “Power Analysis Tutorial”,University ofTechnologys Graz (Austria), Institute for Applied Information Processing andCommunicationhttp://www.iaik.tugraz.at/aboutus/people/oswald/papers/dpa_tutorial.
[ATMEL] Datasheet, ATMEL, ATmega 8 bit AVR Microcontroller with 128K Bytes In-System Programmable Flashhttp://www.atmel.com
[BRI04] Brier,E., Clavier, Ch. and Olivier, F., “Correlation Power Analysis with a Leak-age Model”, Lecture Notes in Computer Science, Volume 3156/2004, CHES 2004http://www.springerlink.com/content/?k=Correlation+Power+Analysis
[BRO06] Brotosumpeno, Bowie,“Conception et Implementation de Systeme Exploitationde Carte a Puce”, Rapport de Projet, ENST, Paris, 2006, Supervisor: PhilippeHoogvorst
[ENS06] Guilley, S., Flament, F. and Sauvage L., “Traces Acquisitation and Analysis -Project”, ENST-Paris, Project Documentation, 21st July 2006
[GEM98] GEMPLUS,“GemCore Based Reader Reference Manual”, Version 1.0, January1998, France, Document Reference: E5221561/DPD06325A00
[HES06] Hess, E., Norbert, J., Meyer, B. and Schutze, T., “Information Leakage AttacksAgainst Smart Card Implementations of Cryptographic Algorithms and Countermea-sures”, A Survey http://web.engr.oregonstate.edu/~aciicmez/osutass/data/
Hess00.pdf, 31 May 2006
[ISOP3] http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.
aspx
[ISOP4] ISO/IEC 7816-4, “Organisation, security and commands for interchange”,ISO/IEC 7816-4:2005E, Second edition, January 2005.
[ISOP8] ISO/IEC 7816-8, “Commands for security operations”, ISO/IEC 7816-8:2004E,Second edition, June 2004.
[ISOP9] ISO/IEC 7816-9, “Commands for card management”, ISO/IEC 7816-4:2004E,Second edition, June 2004.
[KOC98] Kocher, P., Jaffe,J. and Jun, B.,“Introduction to differential power analysis andrelated attacks”http://www.cryptography.com/resources/whitepapers/DPA-technical.html
66
[KOC99] Kocher, P., Jaffe,J. and Jun, B., “Differential Power Analysis”, Lecture Notesin Computer Science, Volume 1666/1999, Proceedings, CRYPTO’99,Santa Barbara,California, USA, August 1999http://www.springerlink.com/content/?mode=boolean&k=DPA+AND+au%
3a(Kocher)&sortorder=asc
[PIR05] Piret, Gilles, “A Note on the Plaintexts Choice in Power Analysis At-tacks”,Technical Report, Ecole Normale Superieure, Departement d’Informatique,November 2005http://www.di.ens.fr/\simpiret/
[PUBLA] U.S. Government Printing Office, “Electronic signatures in global and nationalcommerce act”, Public Law 106-229-June 30, 2000http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=106_cong_
public_laws\&docid=f:publ229.106.pdf
[RAN95] Rankl, Wolfgang and Effing,Wolfgang; “Handbuch der Chipkarten”, 1.Auflage,Carl Hanser Verlag, 1995, ISBN 3-446-17993-3,
[SEU05] Seuscheck, Hermann “DPA-Analyse von Implementierungen symmetrischerkryptographischer Algorithmen”, Lehrstuhl fur Datenverarbeitung Technische Uni-versitat Munchen, Diplomarbeit, April 2005
[URL01] http://www.mbsks.franken.de/sosse/
[URL02] http://www.atis.org/tg2k/, 24 may 2006
[URL04] http://www.amelek.gda.pl/avr/libc/
[URL05] http://winavr.sourceforge.net/, 11 juin 2006
[URL06] http://www.jelectronique.com/WinAVR.php, 11 juin 2006
[URL07] http://www.egnite.de/pipermail/en-nut-discussion/2003-January/
000398.html, 7 juin 2006
[URL08] http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf, 23juin 2006
[URL09] http://www.inf.ethz.ch/personal/rohs/SmartcardsUndJavacards/
index.html
[URL10] http://www.nongnu.org/avr-libc/user-manual/FAQ.html, 16 august 2006
[URL11] http://www.stack.nl/$\sim$dimitri/doxygen/
Declaration of Academic Honesty
I hereby declare to have written this Diploma Thesis on my own, having used only the
listed resources and tools.
Paris, October 20th