final year thesis -...

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


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.


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


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]


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


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]


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.


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].


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


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 .


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


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


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.


41

Figure 7.4: The Analysis Result of the First DES Round

Figure 7.5: Comparison of key guesses for key 0123ABCD4567FE98


42

Figure 7.6: Comparison of key guesses for key d562bc54a4e55283

Figure 7.7: Comparison of key guesses for key 34644ab5679dd697


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


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


45

Figure 7.9: DPA attack: key 34644ab5679dd697

Figure 7.10: DPA attack: key d562bc54a4e55283


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.

pdf

[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

http://www.iaik.tugraz.at/aboutus/people/oswald/papers/dpa_tutorial.pdf

http://www.iaik.tugraz.at/aboutus/people/oswald/papers/dpa_tutorial.pdf

http://www.atmel.com

http://www.springerlink.com/content/?k=Correlation+Power+Analysis

http://web.engr.oregonstate.edu/~aciicmez/osutass/data/Hess00.pdf

http://web.engr.oregonstate.edu/~aciicmez/osutass/data/Hess00.pdf

http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx

http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx

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/

http://www.springerlink.com/content/?mode=boolean&k=DPA+AND+au%3a(Kocher)&sortorder=asc

http://www.springerlink.com/content/?mode=boolean&k=DPA+AND+au%3a(Kocher)&sortorder=asc

http://www.di.ens.fr/sim piret/

http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=106_cong_public_laws&docid=f:publ229.106.pdf

http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=106_cong_public_laws&docid=f:publ229.106.pdf

http://www.mbsks.franken.de/sosse/

http://www.atis.org/tg2k/

http://www.amelek.gda.pl/avr/libc/

http://winavr.sourceforge.net/

http://www.jelectronique.com/WinAVR.php

http://www.egnite.de/pipermail/en-nut-discussion/2003-January/000398.html

http://www.egnite.de/pipermail/en-nut-discussion/2003-January/000398.html

http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf

http://www.inf.ethz.ch/personal/rohs/SmartcardsUndJavacards/index.html

http://www.inf.ethz.ch/personal/rohs/SmartcardsUndJavacards/index.html

http://www.nongnu.org/avr-libc/user-manual/FAQ.html

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

final year thesis -...

Documents