Protocols and Light-Weight Algorithms for Wireless Authentication through Side Channels in IEEE

Protocols and Light-Weight Algorithmsfor Wireless Authentication Through

Side Channels in IEEE 802.11Communication

Sebastian Rohde, B.Sc.

September 30, 2008

A Master’s Thesis submitted in partial fulfilment of the

requirements for the degree:

Master of Science in IT Security

Ruhr-Universität Bochum

Chair for Embedded Security

Prof. Dr.-Ing. Christof Paar

Co-Advised by

Dipl.-Ing. Thomas Eisenbarth and Daniel Bailey, M.Sc.

Acknowledgements

First, let me thank Prof. Dr.-Ing. Christof Paar who helped me to find a suitabletopic for my Master’s thesis and who also assisted me through his advice as well as hisactions.

I thank Dipl.-Ing. Thomas Eisenbarth and Daniel V. Bailey, M.Sc. for their excellentmentoring throughout the entire Master’s thesis.

I also would like to thank Prof. Dr. Johannes Buchmann and Dipl.-Math. Erik Dahmenfor making this work possible.

In particular many thanks go to Dipl.-Inf.(FH) Florian Becker, Dipl.-Ing Kai Daniel, andStefan Vollmer, B.Sc., who helped me patiently with reviewing this work and who alwaysprovided valuable input whenever I needed it.

Special thanks goes to my father Dipl.-Kaufm. Manfred Rohde, for unremittingly sup-porting me during my years of study and for everything else he always did to support me.Nothing less than the same holds true for my mother Ruth Marlies Rohde who sadly didnot get the chance to see me proceed from school, but who I never forgot. They madethis work possible.

This work and my studies were generously supported by the “Studienstiftung des Deut-schen Volkes”. In particular I want to thank Prof. Dr. Franz Lebsanft, Dr. Rainer Strub-Röttgerding and all fellow stipendiaries for being very supportive and always offering thechance of having open-minded conversations whenever we met.

I would like to express my thanks to all my friends and relatives who have helped medirectly and indirectly with helping this thesis and giving me a creative environment.They have always encouraged me and understood my busy lifestyle.

Contents

I. Using Wi-Fi Side Channels for Token-Based Authentication 1

1. Introduction 31.1. Problem and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1. Abstract Problem Description . . . . . . . . . . . . . . . . . . . . 31.1.2. Evaluation of Techniques for Authentication in Pervasive Computing 4

1.2. Objectives for Improved Token-Based Authentication . . . . . . . . . . . 61.3. Research Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2. Prerequisites for Understanding Side-Channel Communication Techniques 112.1. The TCP/IP Reference Model . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1. TCP/IP and Application Data - Layers 2–4 . . . . . . . . . . . . 122.1.2. Fast Ethernet and Wireless LAN - Link Layer . . . . . . . . . . . 13

2.2. Specification and Evaluation of Distinct Target Platforms . . . . . . . . . 142.2.1. The PC - Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2. The Token - Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3. The Token - OS 2008 / Maemo . . . . . . . . . . . . . . . . . . . 15

2.3. Entity Authentication and Transaction Signing . . . . . . . . . . . . . . . 16

3. IEEE 802.11 Side-Channel Communication 193.1. The Token-PC “Forward Channel” . . . . . . . . . . . . . . . . . . . . . 193.2. The PC-Token “Back Channel” . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1. The MAC-Channel . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2. The Length-Channel . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3. Library Concept and System Design . . . . . . . . . . . . . . . . . . . . . 223.3.1. The SSID-Channel from Token to PC . . . . . . . . . . . . . . . . 233.3.2. The Length-Channel from PC to Token . . . . . . . . . . . . . . . 243.3.3. The MAC-Channel . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4. Realistic Experimental Setup for Measurements . . . . . . . . . . . . . . 27

4. Concept and System Design of a Side Channel Example Application 294.1. Component Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2. Identification of Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2.1. Entity Authentication through a Pre-Shared Symmetric Key . . . 294.2.2. Transaction Signing through Digital Signatures . . . . . . . . . . 30

vi Contents

4.3. GUI Concept of the Example Application . . . . . . . . . . . . . . . . . . 304.3.1. The PC Application . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.2. The Token Application . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4. System Design and Implementation Details . . . . . . . . . . . . . . . . . 314.4.1. Windows Application . . . . . . . . . . . . . . . . . . . . . . . . . 314.4.2. Linux Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5. Results 335.1. Performance Measurements . . . . . . . . . . . . . . . . . . . . . . . . . 335.2. Channel Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6. Conclusions and Future Work 35

II. Light-Weight Implementation of a Hash Based SignatureScheme 37

7. Introduction 397.1. Problem and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.2. Objectives for the Light-Weight Implementation of a Hash Based Signa-

ture Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.3. Research Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.4. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8. Prerequisites for Designing a Light-Weight Hash Based Signature Schemeon Constrained Devices 438.1. Hash Based Signature in the Literature . . . . . . . . . . . . . . . . . . . 43

8.1.1. Lamport-Diffie One Time Signature . . . . . . . . . . . . . . . . . 438.1.2. Winternitz One-Time Signature Scheme . . . . . . . . . . . . . . 458.1.3. Merkle Signature Schemes . . . . . . . . . . . . . . . . . . . . . . 468.1.4. CMSS/GMSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8.2. Considerations on the Target Platform . . . . . . . . . . . . . . . . . . . 488.2.1. Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.2.2. Programming Language . . . . . . . . . . . . . . . . . . . . . . . 48

9. Evaluation of Cryptographic Hash Functions 499.1. Dedicated Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 499.2. Block Ciphers as Hash Functions . . . . . . . . . . . . . . . . . . . . . . 50

9.2.1. Single Block Length Construction . . . . . . . . . . . . . . . . . . 519.2.2. Double Block Length Construction . . . . . . . . . . . . . . . . . 519.2.3. Comparison to Dedicated Hash Functions. . . . . . . . . . . . . . 529.2.4. AES-Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 53

10.Hash-Based Signature Scheme 5510.1. Our Variant of the Merkle Signature Scheme . . . . . . . . . . . . . . . . 55

Contents vii

10.1.1. Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5610.1.2. Signature Generation . . . . . . . . . . . . . . . . . . . . . . . . . 5610.1.3. Signature Verification . . . . . . . . . . . . . . . . . . . . . . . . . 5710.1.4. Time and Memory Requirements . . . . . . . . . . . . . . . . . . 58

10.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5910.3. System Design for a Proof-Of-Concept Implementation . . . . . . . . . . 59

10.3.1. 4-Layer Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5910.3.2. Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . 6010.3.3. Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

11.Performance Measurements and Improvements Through Hardware Acceler-ation 6111.1. Considerations on Measuring Performance . . . . . . . . . . . . . . . . . 61

11.1.1. Intrinsic and Extrinsic Measurement of Microcontroller Performance 6111.1.2. Impact of Compiler Options on Timings . . . . . . . . . . . . . . 62

11.2. Performance Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6211.3. Hardware Accelerated AES . . . . . . . . . . . . . . . . . . . . . . . . . . 6411.4. DES Hardware Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . 64

12.Remarks on the Impact of Scheme Parametrization 6712.1. Leaf Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6712.2. MSS / BDS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

13.Conclusion and Future Work 71

III. Appendix 73

A. Sworn Declaration 75

B. Example Application Screenshots 77

C. Parametrization Table 81

D. Bibliography 83

List of Figures

1.1. IEEE 802.11 infrastructure mode . . . . . . . . . . . . . . . . . . . . . . 51.2. IEEE 802.11 communication limits . . . . . . . . . . . . . . . . . . . . . 61.3. Side channel communication . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1. TCP/IP layered architecture . . . . . . . . . . . . . . . . . . . . . . . . . 112.2. TCP/IP encapsulation example . . . . . . . . . . . . . . . . . . . . . . . 12

3.1. Cross-platform interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2. The SSID-Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3. The Length-Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4. The MAC-Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5. Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.1. Merkle signature schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

9.1. Single block length compression function due to [MVV96] . . . . . . . . . 519.2. Double block length compression function due to [Vie04] . . . . . . . . . 52

10.1. Example of the Merkle signature scheme for H = 3, s = 3 . . . . . . . . . 57

12.1. Impact of digest size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6712.2. Impact of hash size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6812.3. Impact of Winternitz parameter . . . . . . . . . . . . . . . . . . . . . . . 6912.4. Impact of tree height h . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7012.5. Impact of parameter K . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

B.1. Example application - PC - unlocked . . . . . . . . . . . . . . . . . . . . 77B.2. Example application - PC - locked . . . . . . . . . . . . . . . . . . . . . . 77B.3. Example application - PC - transaction details setup . . . . . . . . . . . 78B.4. Example application - PC - waiting for transaction confirmation . . . . . 78B.5. Example application - PC - notification of transaction confirmation . . . 78B.6. Example application - PC - notification of rejected transaction . . . . . . 79B.7. Example application - token - requesting transaction legitimation . . . . 79B.8. Example application - token - requesting unlock authorization . . . . . . 79

List of Tables

2.1. IEEE 802.11 generic frame format . . . . . . . . . . . . . . . . . . . . . . 142.2. Ethernet-II frame according to IEEE 802.3 . . . . . . . . . . . . . . . . . 142.3. Simple symmetric and asymmetric protocols for entity authentication . . 17

3.1. Probe response frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2. SSID-Channel packet structure . . . . . . . . . . . . . . . . . . . . . . . 21

5.1. Channel performance with nSSID = 4 and e = 8 . . . . . . . . . . . . . . 335.2. SSID-Channel parameter evaluation . . . . . . . . . . . . . . . . . . . . . 345.3. Length-Channel parameter evaluation . . . . . . . . . . . . . . . . . . . . 34

9.1. Overview of dedicated hash functions . . . . . . . . . . . . . . . . . . . . 509.2. Performance of hash function implementations on the AVR platform . . . 53

11.1. Execution times and compiled size for important compiler options . . . . 6211.2. Results – comparison to state of the art signature schemes . . . . . . . . 6311.3. Performance of HW accelerated AES based hash functions on the AVR

ATxMega platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6411.4. Results – AES hardware acceleration . . . . . . . . . . . . . . . . . . . . 6511.5. Performance of HW accelerated DES based hash functions on the AVR

ATxMega platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6511.6. Results – DES hardware acceleration . . . . . . . . . . . . . . . . . . . . 65

C.1. Relationship of digest/hash size and memory (public key)/#hashs . . . . 81

List of Abbreviations

AES . . . . . . . . Advance Encryption StandardAP . . . . . . . . . Access PointAPI . . . . . . . . . Application Programming InterfaceARM . . . . . . . Acorn Risc MachineBDS . . . . . . . . Buchmann Dahmen SchneiderBSSID . . . . . . Basic Service Set IDentifierCMSS . . . . . . Coronado Merkle Signature SchemeCPU . . . . . . . . Central Processing UnitDBL . . . . . . . . Souble Block LengthDES . . . . . . . . Digital Encryption StandardECC . . . . . . . . Elliptic Curve CryptographyECDSA . . . . . Elliptic Curve Digital Signature AlgorithmEEPROM . . . Electrically Erasable Programmable Read-Only MemoryESSID . . . . . . Extended Service Set IDentifierFCS . . . . . . . . Frame Check SequenceGIMP . . . . . . GNU Image Manipulation ProgramGMSS . . . . . . Generalized Merkle Signature SchemeGTK+ . . . . . . GIMP-ToolkitGUI . . . . . . . . Graphical User InterfaceHW . . . . . . . . . HardwareIEC . . . . . . . . . International Electrotechnical CommissionIEEE . . . . . . . Institute of Electrical and Electronics EngineersIETF . . . . . . . Internet Engineering Task ForceIP . . . . . . . . . . Internet ProtocolIPv6 . . . . . . . . Internet Protocol version 6ISO . . . . . . . . . International Standardization OrganizationLAN . . . . . . . . Local Area NetworkLLC . . . . . . . . Logical Link ControlMAC . . . . . . . Medium Access ControlMMO . . . . . . . Matyas-Meyer-OseasMSS . . . . . . . . Merkle Signature SchemeOS . . . . . . . . . . Operating SystemOSI . . . . . . . . . Open Systems InterconnectionOTSS . . . . . . . One Time Signature SchemePC . . . . . . . . . . Personal ComputerPCMCIA . . . Personal Computer Memory Card International AssociationPDA . . . . . . . . Personal Digital Assistant

xiv List of Abbreviations

PRNG . . . . . . Pseudo Random Number GeneratorQoS . . . . . . . . . Quality of ServiceRAM . . . . . . . Random Access MemoryRFID . . . . . . . Radio Frequency IdentificationRISC . . . . . . . Reduced Instruction Set ComputingROM . . . . . . . Read-Only MemoryRSA . . . . . . . . Rivest Shamir AdlemanRTC . . . . . . . . Real Time ClockSBL . . . . . . . . Single Block LengthSIM . . . . . . . . . Subscriber Identity ModuleSMB . . . . . . . . Server Meassage BlockSP . . . . . . . . . . Service PackSRAM . . . . . . Static Random Access MemorySSID . . . . . . . . Service Set IDentifierTCP . . . . . . . . Transmission Control ProtocolUDP . . . . . . . . User Datagram ProtocolUSB . . . . . . . . Universal Serial BusVPN . . . . . . . . Virtual Private NetworkW-OTS . . . . . Winternitz-One Time SignatureWEP . . . . . . . Wired Equivalent PrivacyWLAN . . . . . . Wireles LANZIA . . . . . . . . . Zero Interaction Authentication

Part I.

Using Wi-Fi Side Channels forToken-Based Authentication

1. Introduction

1.1. Problem and Motivation

1.1.1. Abstract Problem Description

In today’s business environment fast and barrier-free means of entity authentication andtransaction confirmation play a crucial role to the practicability of modern digital au-thentication systems. Security is usually expected to be readily available while affectingthe actual workflow as little as possible. A secure credential-device based approach tosolve this paradox situation has been suggested for a long time and was actually put intopractice through RSA SecurID products [Sec08] and their competitors. When followingthis approach the user is usually requested to enter a time synchronous password that isdisplayed on the token. This is an inconvenient solution for the end-user. It also leadsto the question why this password cannot be transmitted via radio to solve this issue.Radio transmitted security is usually much more vulnerable to protocol based attacks(like Man-In-The-Middle attacks), but the main problem for a widespread deploymentis more practical: the need to install additional radio transceivers. For mobile deviceslike laptops that are difficult to upgrade, this is a task that can only be done easilyby compromising the usability through USB or PCMCIA/CardBus extensions. At thesame time, most mobile devices have Wi-Fi (IEEE 802.11[IEE07]) capability built-in.However, certain protocol and driver limitations prevent this interface from being usedin an effective and transparent way:

• As users often utilize multiple Wi-Fi networks, it is not acceptable for them to beforced to input all their Wi-Fi security credentials into the token. Hence, the tokencan not take part in the network the PC is attached to. In addition, associationsetup is lengthy, thus not desirable on-demand to save power.

• Microsoft Windows as well as its Wi-Fi device drivers do not allow the chipset tobe in multiple simultaneous Wi-Fi sessions. The token therefore cannot create anad-hoc session with the PC while the latter keeps its association with its network.

• Microsoft Windows as well as its Wi-Fi device driver prevent sending and receivingraw and unencrypted data through the Wi-Fi network while being associated to anencrypted network. It is therefore impossible to establish a communication channelby sending unencrypted data.

So the main drawback of token based techniques today is their requirement towards theuser to enter a time synchronous password or to install additional hardware for token-PC communication. However, due the the widespread deployment of Wi-Fi devices in

4 Introduction

laptops, we chose to focus on overcoming the problems of existing Wi-Fi devices in orderto create a highly usable authentication token.

1.1.2. Evaluation of Techniques for Authentication in PervasiveComputing

Consider a typical Internet user, equipped with a full-featured browsing device. Eventhough we recognize that Internet access devices nowadays come in all shapes and sizes,we’ll call this device “the PC”. The user needs to authenticate regularly to Internetservices, like banking or enterprise e-mail, for which a credential like a password or asecret key is needed. The flexibility and extensibility that make the PC so valuable tousers also make it vulnerable to attackers. The prevalence of malware1 makes a PCan unappealing container for credentials like cryptographic keys. Alternatively, it hasoften been previously suggested that secret keys be carried in a separate device like asmartcard or mobile device like a cell phone [BF99]. As with “the PC,” even though thesecredential-carrying devices come in all shapes and sizes, we will refer to one of them as the“the token”. While it is obvious that these devices themselves are not entirely immuneto attacks, this type of occurrence is far less common in practice [MPR06, MPR05].

As depicted earlier, the main hindrance to pervasiveness of these devices is their need totransfer authentication data from the token to the PC and, depending on the protocol,vice versa. Usage of smartcards seems to be a technique that has been obviously designedspecifically for this purpose. However, as smartcard readers are still not widely deployedin today’s PCs, they have major practical drawbacks for many applications. At the timeof writing this thesis, the token-PC interface is usually created through the user. He isrequired to enter an authentication code from the display of the token into the PC – aprocess that is inconvenient and error-prone for users.

In addition, common one-pass authentication schemes like those from the ISO/IEC 9798-2 [ISO93] and ISO/IEC 9798-3 [ISO93] protocols need a timer or a consistent counter fortheir unilateral authentication. Hence, it would be strongly desirable to get rid of thissynchronization issue and apply two-pass protocols. These protocols are typically basedon nonces instead of timestamps. In order to use two-pass protocols we need a PC-token“Back Channel”. This also gives us the choice of applying any other useful bidirectionalprotocol. However, requiring the user to input data into the token is impractical forlimited size tokens. Therefore, other means of token-PC communication have to befound.

The model of a standard PC using Wi-Fi communicating to an Access Point (AP)equipped with a connection to the Internet, depicted in Figure 1.1 is now ubiquitousaround the world. Hence, the usage of Wi-Fi for token-PC communication seems to bean obvious choice. Its most common mode of operation, called “infrastructure mode”,calls for the AP to intermediate all traffic. As defined in Section 7.2.2 of [IEE07], evenif two PCs are in close proximity, data frames are sent from the PCs to the AP to berelayed, and never directly to one another.

1including viruses and Trojan Horses

1.1 Problem and Motivation 5

IEEE 802.11 association with data encryption

1. send data

2. d

istrib

ute

data

wired network

(e.g. Internet access)

no direct communication

Figure 1.1.: IEEE 802.11 infrastructure mode

Disadvantages of Using Standard Wi-Fi Association Techniques

Association Setup is Costly The token could be provisioned with access credentialsto associate with the AP and to complete 802.1X authentication (hereafter, we’ll abusethe terminology and refer to these two separate processes simply as “registration”) justlike the PC. Unfortunately, the registration process varies among APs, which becomesparticularly problematic among mobile users who may use fee-for-service hot spots. Someuse a static WEP pass phrase which would need to be manually entered into the token.Others use 802.1X, for which user name and password would be required. Still othersrely on an IPSec [IET05] Virtual Private Network (VPN) for authentication and trafficprotection.

At the same time, unlike a PC, a security token is used infrequently, say to initiallylog in to a website, or to sign a transaction or document. If a token must register toan AP, a designer faces two unappealing choices: either the token registers once andcontinuously runs its radio to remain registered during the PC’s entire session, or thetoken automatically re-registers on-demand. Re-registration introduces unacceptablylong delays while the user waits for a response. The other choice - continuously runningthe radio - quickly drains the battery.

Associations are Exclusive Wi-Fi offers “ad-hoc mode” in which two PCs may di-rectly communicate, but previous results from testing a broad range of wireless cards(ten different cards representing five different chipset vendors) on Windows and Linuxshowed that none were capable of holding simultaneous ad-hoc and infrastructure modesessions, as depicted in Figure 1.2. This fact means that for practical purposes, a PC cancommunicate directly with the token, or with the AP (and, by extension, the Internet),but not both simultaneously.

Restrictions Caused by the Operating System The Operating System does not pro-vide a low-level Application Programming Interface (API) that could be used to manuallyswitch off encryption for sending or receiving data. The use of the Wi-Fi interface pro-

6 Introduction

IEEE 802.11 association

with data encryption

IEEE 802.11

shared medium

the token the PC

no simultaneous

Ad-Hoc sessions!

Figure 1.2.: IEEE 802.11 communication limits

vides therefore almost the same programming facilities like for wired networks. The maindifference between Wi-Fi and wired networks is the presence of management functionsfor searching for and switching associations in wireless networks.

1.2. Objectives for Improved Token-Based

Authentication

In this work we target the development of techniques for overcoming the obstacles thatarise when using Wi-Fi for token-based authentication. We want to create a prototypetoken that makes use of unconventional side channels in Wi-Fi communication to con-struct a highly usable wireless user-authentication path. We aim to address the majormanagement, usability, and security obstacles to token deployment. One major benefitof the token in design should be that it does not require users to type digits from a tokendisplay into the PC. At the same time it should be using bidirectional authentication pro-tocols which yield a higher security level than standard one-pass protocols that were usedfor token authentication so far. We base on previous unpublished development effortsfrom RSALabs concerning the use of the SSID field in wireless network announcementsto create an unidirectional (side-)channel while maintaining the network association onthe PC’s end of the channel. We want to make use of side channels to simulate simulta-neous sessions, independently of Wi-Fi association or MAC-layer encryption, as depictedin Figure 1.3.

1.3. Research Approach

We consider the development efforts to be split into four phases:

• Side Channel Conception

• Library Development

1.4 Related Work 7

IEEE 802.11 association

with data encryption

IEEE 802.11 shared medium

sidechannel

communication

the token the PC

forward channel

back channel

Figure 1.3.: Side channel communication

• Example Application Development

• Analysis of the Channel Characteristics

Each of the two development projects can again be divided into the parts:

• Conceptual Specification

• System Design

• Implementation

1.4. Related Work

In this section we present2 related work to ours. The use of a PC and handheld inconcert has been explored before. The Pebbles project uses a handheld as an additionaluser interface for a PC [Mye01], as does the Apple Remote Control [Com08] and a handfulof other software applications for smart phones and PDAs.

The simultaneous use of PCs and handhelds has been seen as a way to improve thesecurity of user input and output. In “Bump in the Ether” [MPR06], the authors leveragetrusted input and output on the handheld to compensate for the possibility of malwareon the PC. The authors of “Handheld Computers can be Better Smartcards” [BF99]similarly use the assumption of trusted output on the handheld screen to allow the userto verify data before signing.

Perhaps the closest prior work to ours is found in the “Zero-Interaction Authentication(ZIA)” paper by Corner and Noble [CN02], which envisions a Wi-Fi token worn by users.That work focuses on encrypting data held on the PC with the keys supplied by the tokenas needed, with a unique symmetric key for each directory in a file system. When thePC accesses a particular directory, it requests the key from the token. In addition, thetoken and mobile perform a mutual authentication each second. This scheme requiresessentially continuous operation of the token’s radio and processor leading to high power

2originally written by Daniel Bailey

8 Introduction

consumption. The difference with our work illustrates our contribution. The ZIA tokenuses ordinary Wi-Fi association and UDP for data transmission and reception. ThePC and token use a continuous “are-you-alive” and “I-am-alive” cryptographic exchangethat allows the PC to automatically detect the presence and absence of the user. Whenthe user appears, files are automatically decrypted. When the user departs, files arere-encrypted. While on one hand this design allows automatic operation, on the other itleads to a token that must be “always on.” This exceptionally high duty cycle leads inpractice to a token with power consumption that is unacceptably high. In addition, thisdesign makes roaming difficult: in order for the PC to communicate both with Internetservices and the token, both would need to associate and communicate through the sameaccess point. This introduces an additional difficulty above and beyond the battery-lifeand management constraints: the token and the PC must both be able to hear the AP,rather than each other, potentially reducing range.

In a similar vein, in the “Zero-Stop Authentication” paper [MAMT05], the system de-signers aim to imbue the physical environment with Wi-Fi radios and RFID readers thatdetect the presence of a user and automatically engage in a challenge-response proto-col with the user’s cell phone or PDA. The system authenticates users by combiningthe cryptographic protocol with sensor data. “Context-Aware User Authentication” byBardram, et al [BKP03] also aims to combine location data into an overall authenticationdecision.

A commercial offering from Ozmo, in collaboration with the Intel Cliffside project, hasbeen announced [Mer08]. At the time of this writing, little is known about how thesystem actually works. From the available high-level description, their goals are similarto ours: an alternative use of Wi-Fi for point-to-point networking. They argue theirsolution consumes less power than Bluetooth. Like our approach, theirs aims to allowpoint-to-point networking while a PC is connected to an access point. Their solutionrequires rewriting of network drivers; our solution needs only application-layer software.It is quite difficult and expensive to write custom drivers, especially given that driversusually need to be customized for each new chipset, and few drivers are open-source;our solution does not require chipset-by-chipset customization. The requirement forcustomized drivers and/or hardware limits the applicability of their solution. Ultimately,Ozmo should be seen as a complementary solution: we could use it for data transmissionand reception.

Some wireless authenticator products are now available like Ensure Technologies’ XyLoc[Tec06]. This device is aimed at the medical community, where ease-of-use and fastauthentication is paramount. Little information is available about the authenticationprotocol; PCs must be outfitted with dedicated wireless transceivers to authenticateusers.

A different approach is taken by the plusID product line from Privaris [Cor06]. Using akey-fob form factor, these products implement a match-on-device fingerprint biometricscheme. If a match is found, the key fob releases authentication data using one of ahandful of interfaces including Bluetooth, ISO 14443, USB, and a variety of proximity-card schemes. To ease integration into existing systems, the authentication data released

1.4 Related Work 9

is used in an existing authentication protocol, just as if the credential were stored ina more traditional container. That is, the device acts as a repository of credentials,which may include static identifiers or cryptographic keys. In contrast, the present workanalyzes new possibilities for wireless authentication protocols as well as exploring adifferent radio interface.

Traditional handheld one-time password tokens are today available from commercialvendors. Standardization has begun in the IETF, including [MBH+05, MRN+08]. Au-thentication protocols have long been an area of research, leading to a series of ISOstandards [ISO93, ISO98].

2. Prerequisites for UnderstandingSide-Channel CommunicationTechniques

2.1. The TCP/IP Reference Model

,

The TCP/IP Reference Model [IET89] is the commonly used layered architecture in con-junction with network protocols that are meant for accessing the Internet. It is namedaccording to the most important communication protocols used for this purpose. In con-trast to the seven-layered ISO/OSI Reference Model [Zim88], it only defines four layers.That standards do not intend to be entirely compatible to each other. The TCP/IP Ref-erence Model consists of the layers Application, Transport, Internet and Link. Layered

Link Link

Internet

Link

Internet

Link

Application

Transport

Internet

Application

Transport

Internet

Explicit Communication

Logical End-To-End

Communication

Endpoint Router Router Endpoint

Figure 2.1.: TCP/IP layered architecture

communication architectures generally try to allow communication between two distinctcomponents of the same layer with knowing little or nothing about upper layers. Specif-ically the data structure of the upper layers is unknown for lower layers. This providesabstraction from protocols and services through encapsulation of the higher layer’s data.Figure 2.1 shows how the reference model’s layers are supposed to work together andhow they create almost fully transparent and independent communication paths for eachof them. Figure 2.2 shows the corresponding encapsulation of data.

12 Prerequisites for Understanding Side-Channel Communication Techniques

Data

TCP

Data

TCP

Header

IP

HeaderIP Data

DataMAC

Header

MAC

Footer

Figure 2.2.: TCP/IP encapsulation example

2.1.1. TCP/IP and Application Data - Layers 2–4

The most common protocols to transmit data are the Transmission Control Protocol(TCP) and the Internet Protocol (IP). The main goals TCP tries to achieve are:

Ordered data transfer: the protocol ensures that TCP-payload only reaches the appli-cation layer ordered according to the sending sequence.

Duplicate packets are removed: if packet duplication happens on any of the lower lay-ers the duplicates are not forwarded to the application layer.

Retransmission of lost packets: any data that has not been acknowledged by the re-cipient will be retransmitted.

Error-free data transfer: a checksum makes sure that most data errors are detected anderroneous packets won’t be acknowledged.

Flow Control: the receiver informs the sender about the amount of data that can stillbe received until the buffer is full.

Congestion Control: if many packet retransmissions occur the communication partnersconsider the network to be more or less congested and they alter the behavior ofthe flow of data to help solving this problem.

TCP is a connection oriented oriented protocol, hence the lifecycle of TCP connectionsconsists of three phases:

• connection establishment

• data transfer

• connection termination

TCP also handles “ports” which allow to specifically address a certain application ona target host. In contrast to IP, TCP is not packet oriented but it has been designedto be stream-oriented. This means that the packet fragmentation of data is handledby the TCP stack. This comes at the cost that chunks of data sent at the same timeare not guaranteed to arrive at the receiving party simultaneously – though the correctordering is still guaranteed. The Application layer also has to take care of this as thefragmentation of data on the Application layer is not guaranteed to be kept during the

2.1 The TCP/IP Reference Model 13

transmission. On the receiving end of the communication information about the intialdata fragmentation is not available anymore.

The Internet Protocol [IET81] on the Internet layer of the reference model is responsiblefor routing individual packets through the Internet. It is packet oriented, unreliableand unordered. It divides the set of network components into logical units, so calledsubnets. These subnets usually correspond to physical connections on the link layer. Forthis reason, information about subnets can be used for efficient routing in large scalenetworks like the Internet. Each network component has a unique 4-byte address. Inaddition a 4-byte subnet mask identifies the bits of the address that are used for routingthe packet (network part) and the bits that uniquely identify the component within itssubnet (host part). As the address space has recently been considered too small forfuture extension of the Internet a new protocol variant called IPv6 [IET98] has beendeveloped as the next generation Internet layer protocol. Its main improvement is the16-byte address field which allows many more distinct addresses than the current InternetProtocol.

2.1.2. Fast Ethernet and Wireless LAN - Link Layer

On the Link layer the most common protocols are specified in IEEE 802.3u (Fast Ether-net [IEE05]) and IEEE 802.11 (Wireless LAN [IEE07]) standards. Due to the nature ofthe Link layer these protocols regulate the Medium Access Control and the underlyingphysical hardware medium.

Wireless LAN

The IEEE 802.11 family is in fact a set of protocols regulating wireless communicationsusing over-the-air modulation techniques that use the same basic protocol. When refer-ring to Wireless LAN nowadays 802.11g is the most widespread protocol variant. Wetherefore focus on it in this work. Its radio unit works using the 2.4 GHz band and itsgross transmission rate is 54 Mbps. Variants are available that run with other transmis-sion rates and on other frequency bands. However, it is important to recognize that thestandards are very similar to each other concerning medium access control which is whywe chose to use the term IEEE 802.11 instead of IEEE 802.11g throughout this thesis.Products that have been licensed by the “Wi-Fi Alliance” [WiF08] were tested towardscompatibility with IEEE 802.11 products from other vendors. The term Wi-Fi often isused synonymously for Wireless LAN and IEEE 802.11.

The generic frame format for 802.11 frames is depicted in table 2.1. There are manage-ment, control and data frames. Management frames have subtypes that show their usagefor:

(Dis-)Authentication IEEE 802.11 supports the optional authentication of network par-ticipant against the communication partners.


(Re-)Association In IEEE 802.11 infrastructure mode an Access Point manages logicalassociations of communication partners. These associations are of particular inter-est for this thesis as encryption credentials are usually managed per association.

Access Point Discovery/Information Access points support two mechanisms to an-nounce their presence: upon requests and periodic beacons.

Control frames are used to negotiate with communication partners about the sharedmedium access control. Data frames also come in various subtypes that are used to sendand manage the data flow, i.e this also means to acknowledge the receipt of data for thecommunication partners to prevent retransmission.

Table 2.1.: IEEE 802.11 generic frame format

MAC Header Frame BodyFrame Dur. Addr Addr Addr Sequ. Addr QoS Payload FCS

Control /ID 1 2 3 Control 4 ControlBytes 2 2 6 6 6 2 6 2 0-23424 4

Fast Ethernet

Fast Ethernet uses carrier sense multiple access with collision detection. If a sendingstation detects a collision on the wire it stops sending the frame and sends instead ajam signal. It then waits a random amount of time until it tries to resend the frame(truncated binary exponential back-off algorithm). See 2.2 for the general structure ofEthernet II frames.

Table 2.2.: Ethernet-II frame according to IEEE 802.3

MAC HeaderDestination Source ProtocolID Payload Padding CRC

Address AddressBytes 6 6 2 0-1500 0-46 4

Fast Ethernet packets can be encapsulated in IEEE 802.11 packets through IEEE 802.2LLC [IEE98] encapsulation. This allows a programmer to transparently use the rawEthernet interface of the operating system to send Ethernet II data over Wireless LAN.

2.2. Specification and Evaluation of Distinct Target

Platforms

2.2.1. The PC - Windows

According to [Sha08] Microsoft Windows has a market share of over 90% and is thereforethe most important target platform for token based authentication. Microsoft Windows

2.2 Specification and Evaluation of Distinct Target Platforms 15

has very good development tools and a mostly well documented API. In particular, the.net environment allows the programmer to easily create Graphical User Interface (GUI)applications. Unfortunately when it comes to low-level programming, many WirelessLAN functionalities are very well hidden by operating system, drivers and firmware ofWi-Fi adapters. Windows drivers usually do not permit setting Wireless LAN adaptersinto monitor mode, not to mention sending raw and unmodified 802.11 packets. Windowsdoes not allow any direct access to any of its Wi-Fi encryption functions. It is thereforeimpossible to send unencrypted information during an association with an encryptednetwork. Due to the closed source nature of Microsoft Windows, and most of its drivers,modifications on that level are basically impossible.

2.2.2. The Token - Linux

As the token is a piece of specialized hardware, we were free in the choice of its operatingsystem. For our purposes it has been desirable to choose the platform that has the mostflexible Link layer support for Wireless LAN available. This is true for Linux as the opensource operating system and drivers allow manipulation in order to support low-levelfunctions. There is – given network interfaces that do not prevent it in their firmware– even packet injection of raw IEEE 802.11 packets possible. In conjunction with IEEE802.11 monitor mode this allows the programmer to transfer functions into user space,which are usually handled by the driver in kernel space. E.g. ordinary programs cantherefore send beacons to simulate managed access points.

Linux has sophisticated development tools, though some tools like the debugger gdbare hard to handle without good GUI support. GUI development has been done inGTK+ [GTK08] on this platform.

2.2.3. The Token - OS 2008 / Maemo

During our development we quickly recognized that an embedded device which runs Linuxwould be best to demonstrate the capabilities of our side channel library in a practicalscenario. We found the Nokia Internet Tablet N810 that is powered by OS 2008 /Maemo [MAE08]. This platform is a specialized variant of Linux that uses GTK+ as itsGUI library. Most sources for this platform, including kernel and drivers, are availableand therefore most things are the same as for standard Linux. However, due to the ARMprocessor, token applications Maemo developed on the Maemo development platformcalled scratchbox which is a cross compiling environment that works together with theMaemo GUI Framework. Scratchbox totally runs with normal user privileges on a Linuxhost. It supports executing ARM binaries in the development environment through theemulator QEMU [QEM08].


2.3. Entity Authentication and Transaction Signing

Entity authentication is the process whereby one party is assured (through acquisition ofcorroborative evidence) of the identity of a second party involved in a protocol, and thatthe second has actually participated (i.e., is active at, or immediately prior to, the timethe evidence is acquired). [BM+03]

Entity authentication is needed if a user wants to authenticate himself against the PC tounlock the device during login. In consideration of token based authentication approachesit seems to be difficult to see whether the token or the user is the entity that authenticatesagainst the PC. However, as a user can authenticate himself through something that heknows (e.g. passwords), something that he is (e.g. biometrics) or something that hehas (e.g key, tokens) personalized interactive tokens may act as an agent for the userwhile requesting him in the back-end to confirm the actions in question. Hence, whentalking about 2-party authentication protocols usually the token-PC communication isconsidered. Entity authentication can be achieved through symmetric and asymmetriccryptography.

If it comes to transaction signing the situation is even more complicated. Transactionsigning can be achieved through data origin authentication. Data origin authenticationcan best be described by stating that the data has not been altered on its way from theknown data origin to the recipient.

Nowadays, popular phishing attacks trick the user into offering credentials that can beused to authenticate a completely new or different transaction. This is usually donethrough manipulating the user’s GUI in a way that make the user think he needs to en-ter the credentials to achieve a specific goal. Shifting the user’s transaction confirmationto a secure device like a token makes manipulating the PC’s GUI in theory detectable,rendering phishing attacks useless. This means that the token is the protocol participantof whom the data origin needs to be guaranteed to the communication partner requestingthe authentication of the transaction. The token’s GUI is however much less vulnerableto phishing attacks and other malware. [HKW06] elaborates on this topic for onlinebanking purposes.

We consider a detailed protocol analysis of suitable protocols for these applications out ofscope. However we will give simple protocol examples for entity authentication throughsymmetric (ISO/IEC 9798-2 two-pass unilateral authentication [ISO93]) and asymmetric(ISO/IEC 9798-3 two-pass unilateral authentication [ISO98]) cryptography in Table 2.3.For details on these protocols please see also [BM+03].

2.3 Entity Authentication and Transaction Signing 17

Table 2.3.: Simple symmetric and asymmetric protocols for entity authentication

two-pass unilateral authentication

ISO/IEC 9798-2 [ISO93] ISO/IEC 9798-3 [ISO98]symmetric asymmetric

1. B −→ A : NB 1. B −→ A : NB2. A −→ A : {NB , B}KAB 2. A −→ B : NA, NB , B, SigA(NA, NB , B)

{B}KAB : Identity of B encrypted with the shared key of A and B

SigA(NA) : A nonce generated by A, signed with the private key of A

3. IEEE 802.11 Side-ChannelCommunication

3.1. The Token-PC “Forward Channel”

By exploiting different frames, we will construct two unidirectional channels: one fromthe token to the PC which we call the “forward channel”, and a channel from the PC tothe token which we call the “back channel”. We assume the PC runs Windows XP orVista and is already using its Wi-Fi adapter in an infrastructure session. This situationcorresponds with the most common case found in practice in enterprises. There arethree possible token configurations: those capable of neither monitor mode nor packetinjection; monitor mode but not packet injection; and both monitor mode and packetinjection. We will consider two possible cases for the token most important: thosecapable of both monitor mode and packet injection and those capable of neither. In alarge scale application scenario based on specifically developed tokens it would be easyto create custom Wi-Fi drivers that support both monitor mode and packet injection. Incontrast, it cannot be assumed that “software tokens”, meant for installation on existingplatforms like mobiles, are necessarily able to support any of the two modes.

The token-to-PC forward channel does not require necessarily any special modes of Wi-Fi and a basic version of it may therefore be implemented on any device. However,a performance optimized version of the channel can only be constructed if the tokenis capable of monitor mode and packet injection. To construct the forward channel,we exploit the methods by which 802.11 clients determine which wireless networks inrange offer the service they seek. Both APs and ad-hoc network participants advertisetheir existence by sending out beacon frames, which are unsolicited management framessent to the broadcast address; and probe response frames, which are sent in response toprobe frames sent out by stations seeking access points (or other stations with which topotentially associate in an ad-hoc network).

A probe response frame, illustrated in Table 3.1 contains many data fields. We concernourselves primarily with the 32-byte SSID field, which typically indicates the naturallanguage name of a network (e.g., “my home wireless”). The SSID field can be given anarbitrary value and still be received and propagated unmolested up the protocol stackby commodity 802.11 hardware and drivers on Windows platforms.

Tests representing a number of different PC Wi-Fi adapters (from Linksys, D-Link,Belkin, Hawking, Netgear, and Intel) incorporating different chipsets from Prism, Ralink,Atheros, Broadcom, and Intel in a previous work from RSA Laboratories [BBJS08]

20 IEEE 802.11 Side-Channel Communication

Table 3.1.: Probe response frame

MAC Header Frame Body

Frame Duration Destination Source BSSID Seq. SSID FCS

Control Address Address Ctl.

Bytes 2 2 6 6 6 2 32 4

showed that only the SSID field can be reliably received by the PC in this way. Otheroptions tested were unsuccessful. These options included the 6-byte network MAC ad-dress, the 8-byte supported rates field, the 8-byte timestamp, the 2-byte beacon interval,and the 2-byte capabilities field. The smaller size of these fields and their greater importin the 802.11 link layer led us to use only the SSID for the forward channel. Vendorspecific fields of up to 255 bytes can also be appended to probe response frames andused to carry authentication data. Unfortunately, one adapter only reported the first240 bytes and others did not report these other fields at all.

These two data paths define two different methods for a PC to obtain information aboutnearby APs: passive scanning, wherein a station merely listens for beacons, and activescanning where a station sends probe requests and listens for probe responses. Passivescanning is used in the popular Kismet wireless network-detection software [Ker04]. LikeKismet, previous experiments confirmed that few network adapters are capable of passivescanning on Windows, with most only supporting active scanning, and none supportingonly passive scanning. Building a widely-usable forward channel thus requires at leastsending out probe responses to allow the detection of ESSIDs during active scanning onthe PC. Our concept on the receiving side of this channel therefore involves constantlypolling the operating system’s interface for wireless network configuration. The sendingpart of the channel can either be constructed by using the operating system’s capabil-ities to create ad-hoc and access point based sessions or by directly using IEEE 802.11management frames. The latter also offers the option of simulating multiple disctinctSSID sending stations at once.

Because of these limitations, our token thus sends messages by essentially advertisingitself as an ad-hoc network participant, sending out beacon frames and probe responseframes upon activation with the SSID field set to the base-64 ASCII encoding of thecryptographic message. The SSID field identifies the frame as part of the authenticationprotocol using the “;” character (an arbitrary choice) and carries the cryptographic pay-load necessary to authenticate the token to the PC. Software on the PC continuouslysearches for access points and ad-hoc network participants; when one is found whoseSSID begins with the “;” character, it delivers the cryptographic payload to securityapplications. In our experiments, the delay from when the prototype begins to advertisethe ad-hoc network to the time the payload is passed to application software on themobile varies depending on what 802.11 chipset and driver is used on the mobile. Weexperimented the most with a Belkin F5D7050 ver. 3; using it, the delay is around threeseconds.

The SSID field is at most 32 bytes long; the “;” character consumes one bytes leaving

3.2 The PC-Token “Back Channel” 21

Table 3.2.: SSID-Channel packet structure

Header Body

Identifier Backup Identifier Ordering Number Payload

6-bit Characters 1 1 2 28

31 bytes. Using two bytes for packet ordering information. One bytes has been reservedfor future use. This “backup identifier” may be used for creating virtual “channels” ofcommunication to distinguish multiple tokens in the same area. We are therefore capableof transmitting 28 times 6 bit (base64-encoding) of information. This corresponds to 21full bytes per packet. This is a very small payload by networking standards, but it islarge enough to carry small payloads such as a pairing-based digital signature [BLS04],or fragments of a longer message. For fragmented messages, the token can masquerade asmultiple access points simultaneously to boost throughput. Details on these experimentsand other performance measurements are found in Section 5.1, with implementationdetails in Section 3.3.1. The SSID-Channel packet structure is depicted in Table 3.2.

3.2. The PC-Token “Back Channel”

Once associated with an AP using MAC-layer encryption, the currently most widespreadoperating system Microsoft Windows – in conjunction with standard hardware anddrivers – does not allow one to send unencrypted data on a frame-by-frame basis while be-ing associated with an encrypted network. For this reason, application software runningon the PC cannot directly send data frames that can be read by the token. Because thetoken does not have the MAC-layer encryption keys, even if its drivers support monitormode, the best the token can hope for is to intercept encrypted frames. This situationis depicted in Figure 1.3.

However, there is some information leakage when sending encrypted data. First, thesize and the distribution in time of packets is not disguised by the Wi-Fi encryptionschemes. Network interfaces set into monitor mode can therefore see packet sizes andtheir distribution in time. Second, every Wi-Fi interface provides the upper layers withan emulated Ethernet (MAC-) layer to maintain compatibility with Ethernet interfaces.Certain header fields of this compatibility layer are transferred without encryption intothe 802.11 (MAC-) layer when sending arbitrary Ethernet II packets. The token must becapable of monitor mode operation in order to use one of these back channels. Personalwireless devices including the Nokia Internet Tablet offer this feature and naturally anypurpose-built token would as well.

3.2.1. The MAC-Channel

The MAC-Channel uses the fact that the windows networking stack allows a user modeapplication to send unchecked raw Ethernet frames with forged sender and destination


protocol fields over the 802.11 interface. The Ethernet protocol fields concerning thesender and the destination will be transferred into the appropriate 802.11 protocol fields.These fields in the 802.11 protocol header are not encrypted (see Table 2.1).

Using only application-layer software it is possible to create explicitly malformed Ether-net-II frames. The PC can be tricked this way to set certain header fields of the IEEE802.11 protocol to arbitrary values, allowing us to create a side-channel that can bereceived by any token with monitor-mode capability. These frames can therefore be usedas a side channel to transfer data out of a Wi-Fi network.

Any device that is set into monitor mode can therefore read these fields in plaintext -regardless of its SSID. Note, that only the token needs monitor mode to “receive” theinformation.

A description of this technique can be found in Section 3.3.3.

3.2.2. The Length-Channel

The other option to transport data out of the encrypted Wi-Fi network is to use multiplepacket lengths. Using only the lengths as information n distinct length provide an entropyof e = log2(n) bits of information in a undisturbed channel. Hence sending one packet oflength li with i = 1..n will transport e bits of information. To discover noise and channelerrors we added one additional packet length ln+1 that is used as a delimiter for a simpleencoding and which will help to discover many errors in the channel.

In order to detect errors the PC begins this transmission by sending a packet of length ln+1

as a start symbol. Then, the PC transmits the application data and adds an additionalpacket of length ln+1 which serves as a stop symbol. Chunk of sizes not divisible by 8are discarded.

Implementation details can be found in section 3.3.2.

3.3. Library Concept and System Design

Generally hardware and communication protocol specific programming in a PC envi-ronment is difficult to manage. Hardware and underlying software constraints combinewith the ambiguity of today’s PC hardware. When it comes to using hardware as theyweren’t meant for in the first place Microsoft Windows and Linux offer very different pro-gramming interfaces, even on the same Platform. Windows offers a very sophisticatedhardware abstraction layer with no means of manipulating the hardware itself. Linuxon the other hand provides the end user with options to manipulate much more as thesource code of the kernel and most parts of the drivers are publicly available. However,even here many network vendors work with a closed source, binary form firmware fortheir devices which restrict the device to usage within the vendor’s specification limitsthat are often influenced by regulation organizations. These organizations want to makesure that certain (inter-)national conditions, like band regulations, are kept with. In

3.3 Library Concept and System Design 23

our scenario this mix of target platforms results in a difficult variant of cross platformdevelopment where some part of the code is shared and some part is single platform only.The shared part consists mostly of abstract interface definitions together with some gluecode (see Figure 3.1).

ITxChannel

+ ITxChannel()+ ~ ITxChannel()+ Update()+ Reset()+ SendData()+ GetSendQueueSize()

IRxChannelListener

+ IRxChannelListener()+ ~ IRxChannelListener()+ DataReceived()

IRxChannel

+ IRxChannel()+ ~ IRxChannel()+ Update()+ RegisterListener()+ UnregisterListener()+ DumpDebugOutput()+ Reset()# SendDataToListener()

Figure 3.1.: Cross-platform interface

The forward channel alone is compatible with every driver and chipset combination wetested. By contrast, the back channels require the token to operate in monitor mode –only available for certain driver and chipset combinations. When both channels shouldbe simultaneously combined packet injection capability comes as a further requirement.As the token is a specialized piece of hardware this however is no significant restriction.Nevertheless, the prevalence of Linux in personal wireless devices makes even monitormode available in in a growing number of mainstream devices such as the Nokia InternetTablet N810. For injection, driver and firmware support is needed. Unfortunately thefirmware of N810’s embbeded Wi-Fi device does not support packet injection. Section 3.4shows means to overcome this limitation for demonstration purposes. Our token imple-mentation was tested on both a Linux PC and the N810. To enable the low-level modesof the network adapter of the token in a hardware independent way a specialized librarycalled Lorcon ([Lor08]) has been used. Lorcon abstracts from the various methods to letthe network driver go into monitor mode and support injection. It also provides helpermethods to support creation of raw 802.11 packets. As all channel parts for the tokenuse this library a class CLorconMgr encapsulates the Lorcon code. The actual listeningon the channels takes place in in another helper class “CPCapHelper” which uses the li-brary “pcap”. Every class derived from that abstract class has to implement the abstractvirtual function “DataReceived” which is used to deliver the received data.

3.3.1. The SSID-Channel from Token to PC

Given the software running on the token, there are two possible ways to establish a sidechannel using the SSID field. The first is to let the network interface act as a regularaccess point. We experimented with the Belkin F5D7050 Version 3 adapter, which usesthe Ralink RT73 chipset, and the Atheros-based Netgear WG511T adapter. We found


that the driver [Mad08] for the Atheros-based card is natively capable of emulating twoaccess points simultaneously, but more lead to a kernel crash. To emulate more accesspoints, the implementation resorts to packet injection. Section 5.2 elaborates on theperformance impact of simultaneous SSIDs.

To be easily able to set the ESSID of the access points from our library the sendingpart of the SSID-Channel was split into two parts. The first one is a shell script whichlistens to a Unix socket for SSIDs, that it should apply on the driver controlled accesspoints. The second part is the CSSIDChannel class of our library which manages orderedpackaging and a simple encoding. The output of this module is written to the socket theSSID-Set-Daemon program listens to.

The second and more advanced alternative to use the SSID field for data transmissionis to simulate many access points directly using 802.11 protocol communication throughthe monitor/injection interfaces from the userspace. Linux in conjunction with appropri-ate hardware and drivers provides the necessary interfaces and capabilities. The tokensoftware responds directly to 802.11 probe requests and sends out beacons. Each virtualaccess point is announced for five seconds so the software on the PC has a chance toreceive the data. Our solution therefore provides a configurable number of access pointsannouncements and thus provides a much higher data rate.

As stated earlier the SSID field can transport 32 bytes. Because some drivers havedifficulty with non-ASCII characters, the token uses base64 encoding. The first characteris always the arbitrary “;”. The second and third bytes combine to a monotonicallyincreasing packet counter, necessary for the reconstruction of fragmented messages anddetection of lost fragments.

The receiving part of the SSID-Channel on the PC uses the wireless API introduced inWindows Vista and Windows XP SP3 to listen continuously for new networks withinreach. If new networks match the discriminator and the counter value refers to one ofthe next packets it is accepted and decoded. If the counter value was the next to beexpected the data is directly transferred to the authentication application. Otherwiseit is scheduled for delivery upon arrival of the missing intermediate packet, or a timerexpires. Figure 3.2 shows how the common properties of the distinct channel versionshave been canalized.

3.3.2. The Length-Channel from PC to Token

As described in Section 3.2, the length of packets transferred over the wireless interfacecan also be used to encode information. Therefore the PC needs to be able to send packetsand control their length which can easily be done by using the library libnet[Lib08a] whichin turn relies on WinPCap[Win08]. The receiving part for the token only needs to lookat the length of certain encrypted packets. To prevent receiving duplicate frames we lookat certain protocol fields that indicate the frames are sent from the network interface tothe access point (see Figure 1.1) while skipping frame resends. The necessary flags forthis (FCTL_ FROMDS, FCTL_ TODS, FCTL_ RETRY) are part of the unencryptedframe control field of the IEEE 802.11 protocol. The recipient has no direct way to

3.3 Library Concept and System Design 25

CSSIDRxChannel

+ CSSIDRxChannel()+ ~ CSSIDRxChannel()+ CheckInterface()+ Update()+ Reset()� PotentialDataAvailable()

IRxChannelListener


IRxChannel


CPCapHelper

+ CPCapHelper()+ ~ CPCapHelper()+ DataReceived()+ DataReceived()# PCapUpdate()

CSSIDTxChannel

+ CSSIDTxChannel()+ ~ CSSIDTxChannel()+ Update()+ SendData()+ GetSendQueueSize()

CLorconMgr

+ CLorconMgr()+ ~ CLorconMgr()+ GetIfaceName()+ InjectProbeResponse()

CSSIDV2TxChannel

+ CSSIDV2TxChannel()+ ~ CSSIDV2TxChannel()+ DataReceived()+ Update()+ GetSendQueueSize()

0..1�m_pLorconMgr

Figure 3.2.: The SSID-Channel

distinguish side-channel packets from those that are created through regular networktraffic. However, by reserving certain packet lengths to serve as start-of-block and end-of-block delimiters, one can decrease the likelihood of misinterpreted packets. This isdone through a basic encoding to detect if some packets have been falsely interpreted aspart of the side-channel communication. The data is divided into fixed-length blocks.

The encoded blocks are surrounded by a packet of a special (arbitrary) length to markthe beginning and the end of every block. As soon as the delimiter surrounds data that islonger than one block (misinterpreted packet length and/or missed delimiters) or that isshorter but does not produce complete bytes the block is discarded as packet loss. Upperlayer protocols need to take this into account. Figure 3.3 shows the static structurediagram of the Length-Channel. Coding theory is a rich area and one could applysophisticated codes to detect and repair errors; our purpose here is merely to implementand report on the basic channel characteristics to which coding could be applied.

3.3.3. The MAC-Channel

The basic mechanism of the MAC-Channel is comparatively simple. The sending partforges raw Ethernet II frames through the libnet packet factory. The destination field ofthe protocol header as depicted in Table 2.2 is used to encode data, providing six bytesof data per packet. In addition the packets are sent with only one byte of payload. TheWindows networking stack in conjunction with the appropriate drivers will just translatethese fields into the corresponding IEEE 802.11 data fields as shown in Table 2.1.

This results in a very unusual packet length which is used to distinguish these side-channel packets from other network traffic. The token therefore listens for packets with


ITxChannel


CLengthTxChannel

+ CLengthTxChannel()+ ~ CLengthTxChannel()+ Update()+ SendData()+ GetSendQueueSize()

�m_pLorconMgr0..1

CLengthRxChannel

+ CLengthRxChannel()+ ~ CLengthRxChannel()+ Update()+ DataReceived()+ DumpDebugOutput()

�m_Encoder

IRxChannelListener


CPCapHelper


IRxChannel


CLorconMgr


CLengthEncoder

+ CLengthEncoder()+ ~ CLengthEncoder()+ Init()+ GetEncodedData()+ ReceivedPacket()+ GetAvailableData()+ DumpDebugOutput()

�m_LengthEncoder

Figure 3.3.: The Length-Channel

only one byte of payload on the Ethernet layer. Hence we are able to use all six bytesof the destination address of every packet. To avoid problems in case the destinationMAC address matches an existing MAC address the Ethernet II protocol field is set toan invalid value which makes sure that no upper protocol layers are disturbed.

The token that receives these frames reassembles the data of matching packets in turnfrom the destination field of broadcast packets with the unusual packet length thatcomes up when creating raw Ethernet frames with no payload. Figure 3.4 shows thestatic structure of this channel.

CPCapHelper


IRxChannel


IRxChannelListener


0..1

ITxChannel


CMACRxChannel

+ CMACRxChannel()+ ~ CMACRxChannel()+ Update()+ DataReceived()

CLorconMgr


.m_pLorconMgr

CMACTxChannel

+ CMACTxChannel()+ ~ CMACTxChannel()+ Update()+ SendData()+ GetSendQueueSize()

Figure 3.4.: The MAC-Channel

3.4 Realistic Experimental Setup for Measurements 27

3.4. Realistic Experimental Setup for Measurements

During our development we spent a significant time on research about the way we coulduse a mobile token in conjunction with standard end user PC-Hardware. The Nokia In-ternet Tablet N810 is capable of providing the SSID-Channel and monitor mode withoutmodifications, but not arbitrary wireless packet injection – which yields higher perfor-mance for the SSID-Channel and allows the programmer to use both channels simulta-neously. For this feature we turn to an external USB Wi-Fi adapter. The USB port of

the token

Figure 3.5.: Experimental setup

the device can easily be configured to operate in USB host mode. At the same time theN810 development kit includes the complete kernel source which in turn allows one toeasily compile the RT73 open source driver [RT708] for the Belkin FD5D7050 Version 3Wi-Fi USB adapter. Because the USB port of the tablet only provides a limited amountof current, we also use a powered USB hub between the N810 and the Wi-Fi adapter asshown in Figure 3.5. To make a connection between the hub and the Nokia N810 withits standard USB-cable a female-female USB-A adapter is needed. The SDK’s cross-compiling environment is also used for the compilation of the token application. We usethis hardware setup to gather information about the channel performance by sending afixed amount of data through the various side channels. We measure the throughputand count the bytes on the receiving part of the channel to get information about itsreliability.

4. Concept and System Design of aSide Channel Example Application

4.1. Component Description

In order to demonstrate the capabilities of our proposed token we decided to develop ademonstration tool that consists of a PC application and a prototype token implemen-tation. The PC application can be used to simulate situations in which a user needsto authenticate an action. This could be unlocking the PC while approaching an work-station or authentication of an Internet banking transaction. The application uses the“Back Channel” to send out information about the action together with protocol specificdata like nonces. The token application afterwards displays the legitimation request tothe user through a GUI application. If the user chooses to confirm the request secretkey material on the token is used to generate a positive cryptographic reply that is sentthrough the SSID “Forward Channel” channel. The PC application receives this replyand simulates an appropriate action.

4.2. Identification of Use Cases

The demonstration tool should illustrate two distinct modes of operation:

• entity authentication through symmetric key material for unlocking an application

• simulation of Internet banking transaction signing through public key cryptography

In the following section we will present the use cases that describe the two modes ofdemonstration. Note that the protocol concept used here is only meant for demonstrationpurposes.

4.2.1. Entity Authentication through a Pre-Shared Symmetric Key

1. The button “Lock Application” on the PC application is pressed. In a real worldapplication this could be triggered by the login daemon of the operating system orby a screen saver. For demonstration purposes the application’s buttons are lockedafterwards.

2. The application uses the MAC-Channel to submit regularly an authentication re-quest which consists of a fresh nonce NB and B’s identity according to the ISO/IEC9798-2 two pass unilateral authentication protocol.

30 Concept and System Design of a Side Channel Example Application

3. The token application, running in the background, pops up and asks the user toauthenticate the unlock request from B.

4. Upon confirmation the token application encrypts NB, B with KAB (the commonpreshared-key) and sends {NB, B}KAB through the SSID-Channel to the PC.

5. The PC application receives the unlock reply, verifies its correctness, unlocks theapplication’s buttons and displays an authentication confirmation. In a real worldapplication the authentication process would be considered successful and e.g. ascreen saver would unlock.

4.2.2. Transaction Signing through Digital Signatures

1. The button “New Transaction” is pressed.

2. A bank transfer form pops up which can be filled and confirmed by the user

3. The applications sends the form data to the token through the MAC-Channel andrequests the token to sign it.

4. The token application pops up a window with the transaction details and asks theuser whether he wants to sign the transaction.

5. Upon user confirmation the token creates a digital signature like EC-DSA fromthe transaction data with its private key. It is assumed that the bank knows thetoken’s public key and that it is associated with the token user’s bank account.

6. The signed transaction is transmitted through the SSID-Channel to the PC appli-cation.

7. The PC-Demonstrator verifies the signature and displays: “transaction confirmed”along with the transaction details. A real world application would instead forwardthe signed transaction to the bank’s online banking transactional service where theactual validation of the signature takes place.

Note that the protocol in this demonstration mode is, among others, extremely vulnerableto replay attacks. This could however easily be solved by using applying techniques liketransaction IDs, nonces, or timestamps (see [BM+03] for more details on protocols).

4.3. GUI Concept of the Example Application

4.3.1. The PC Application

The screenshots of the example application, referenced in this section, can be found inAppendix B. The demonstration tool’s PC component consists of two GUI dialogs, themain dialog and the transaction details dialog. In the main dialog (Figure B.1) thetwo distinct demonstration modes can be initiated. The first button “Lock Application”disables all buttons (Figure B.2) as long as the application is not unlocked through thetoken.

4.4 System Design and Implementation Details 31

The second button “New Transaction” initiates the second GUI dialog that allows toenter transaction details (Figure B.3) for demonstration purposes. After confirmation ofthis dialog the main GUI is set into a “waiting for confirmation” state (Figure B.4)

Upon confirmation or denial of the transaction details the main GUI is reset and aMessage Box pops up which notifies the user of the validity status of the transaction(figures B.5 and B.6).

4.3.2. The Token Application

The token application runs in the background and it only opens a GUI dialog when itreceives through the side channel a request to one of the two demonstration modes. Incase of the confirm unlock request (B.8) the Identity of the PC requesting the unlockauthorization is displayed together with the actual question to unlock. In case of thetransaction confirmation request (Figure B.7) the question also includes the transactiondetails to make sure the user confirms the correct transaction.

4.4. System Design and Implementation Details

The demonstration tool token and PC applications consist each of three components:

The GUI that handles the user input and output. This component usually has, depend-ing on the GUI libraries, a major impact on the main loop of the applications.

The protocol logic that involves using a crypto library to handle the interaction be-tween both the token and PC components on the application level.

The side-channel library that has been extensively described in the previous section.

The side channel channel library has already been developed with keeping cross-platformthoughts in mind. However the same problems that arised there also concern protocollogic and the GUI. On the one hand the GUI is highly platform specific and requiresin fact two independent solutions for the PC and the token. The protocol logic on theother hand has – besides usual differences due to the different functionality for token andPC – the option to benefit from readily available cross-platform cryptographic libraries.We chose to use libtomcrypt for this purpose. It works extremely well in conjunctionwith libtommath for the math behind public key cryptographic routines (see [Lib08b]for information about both).

4.4.1. Windows Application

We developed the PC application on windows using the managed C++ compiler of VisualStudio 2008 [Vis08]. It allows the integration of .net GUI Widgets (to ease development)with native C++ code like our side-channel code. However, this integration is not aseasy as one might expect as there are several limitations when combining managed with

32 Concept and System Design of a Side Channel Example Application

unmanaged code [Gen03] in terms of object creation and lifecycle. This is mostly dueto the distinct memory management concepts of standard C++ and the .net platformwhich uses garbage collection.

4.4.2. Linux Application

As we are using an ordinary Linux machine to simulate the behavior of the token amajor design constraint was that the token code should work on standard Linux as wellas under the scratchbox cross-compiling environment. One major drawback of scratchboxin combination with applications that need real root privileges is that this is practicallyimpossible within the development environment. As our side-channel library needs tohave root privileges in order to setup the monitor mode on the Wi-Fi device we had toinvestigate this new challenge.

So there are basically two options: Copy the compiled application manually to the deviceand execute it there with root privileges, or use a workaround to use the available rootmode on the device without actually doing the manual copy. The latter can be achievedthrough the CPU transparency mechanism of the scratchbox. Besides emulation of theARM CPU, it its possible to run the executable on the real device while staying in thescratchbox environment and getting all output on the PC. This is what we wanted tohave during development. Unfortunately, this setup is quite complicated and includescompiling kernel modules for the N810 kernel as well as manual installation of multipleclient and server applications like NFS and specific scratchbox services on both PC andN810. If this setup is up and running it still needs to be used “manually” in terms oflogging in into the device, gaining root privileges, “chrooting”1 into the developmentenvironment and running the actual application.

In effect, this means that there is no easy way to run the application during devel-opment. We therefore chose to focus on the Linux token instead of struggling withimplementational details on the Nokia Internet Tablet N810. Nonetheless it was stilla strict requirement to use the same GUI libraries as we would if we chose to do ourdevelopment directly for the N810. The token application had therefore to be developedusing the GTK GUI framework which is - though common in the Linux world - not aseasy to manage as its .net GUI counterpart.

1Linux command “chroot” [SWF+05]: start a new subshell on the console which has a different rootdirectory

5. Results

5.1. Performance Measurements

This section reports on channel delay, throughput and the loss rate of the proposedside channels. The channel delay is measured by comparing the time when data is sentand the time when data arrives. Because of the amount of time needed by the PCto scan for APs, it is around one to four seconds for the SSID-Channel. The delayfor the other channels is close to the delay of the wireless channel itself as only a fewordinary packets are needed to deliver data to the channel’s user. Throughput denotes thenumber of uncompressed bytes per second and the loss rate gives information about thereliability of the channel. Table 5.1 shows the results. In the “No other traffic” scenario,we made no effort to generate additional load on the AP. For the “Multiple YouTubeVideo Downloads” scenario, we launched four simultaneous downloads to generate sometraffic with which the side channels would have to compete. Finally, for the “SMB FileTransfer”, we initiated a large file download. In each scenario, we averaged over fourexperiments.

Table 5.1.: Channel performance with nSSID = 4 and e = 8

Channel Throughput (bytes/s) Loss Rate

No other traffic

SSID-Channel 19 0.0%Length-Channel 80 7%MAC-Channel 2159 1%

Multiple YouTube Video Downloads

SSID-Channel 10 40%Length-Channel 32 19%MAC-Channel 1754 7%

SMB File transfer

SSID-Channel 8 50%Length-Channel 30 20%MAC-Channel 281 10%

34 Results

5.2. Channel Parameters

The SSID and Length-Channel provide configuration options to change the behavior ofthe channel. The SSID-Channel can be configured by setting the maximum numbernSSID of simultaneously used SSIDs; each is transmitted for five seconds. Unfortunatelythe increased speed offered by simultaneous SSIDs comes at a price: large numbers ofvirtual access points may confuse both the end-user and the networking stack of theirPCs. Table 5.2 shows how nSSID affects the channel characteristics.

Table 5.2.: SSID-Channel parameter evaluation


No other traffic

SSID-Channel, nSSID = 4 19 0.0%SSID-Channel, nSSID = 8 40 0.0%SSID-Channel, nSSID = 16 85 0.0%SSID-Channel, nSSID = 32 195 0.0%

The Length-Channel can be configured by the number of distinct packet lengths n thatare used. Besides some overhead, the performance is theoretically proportional to thebits of information e = log2(n) that are encoded in one packet length. For simplicity wemeasured e = 2, 4, 8 yielding (together with one delimiter) 5, 17, 257 distinct packetlengths. The throughput can be increased by choosing shorter packet lengths. We chosepacket lengths starting from 500 bytes because due to Lauradoux [Lau07] they are veryuncommon in normal TCP traffic and therefore less likely to be mistaken for ordinarynetwork traffic. In addition, it eases the burden on the decoder: the packet lengthsrepresent two bits, four bits, and eight bits respectively. The channel characteristics forthe parameterized Length-Channel can be found in Table 5.3. The loss rate decreaseswith an increasing number of lengths because the number of packets sent per data frameis decreased.

Table 5.3.: Length-Channel parameter evaluation


No other traffic

Length-Channel e = 2 22 17%Length-Channel e = 4 46 13%Length-Channel e = 8 80 7%

6. Conclusions and Future Work

We developed a prototype token that makes use of unconventional side channels in Wi-Fi communication to construct a highly usable wireless user-authentication path. Ourconcept addresses several major management, usability, and security obstacles to tokendeployment. One major benefit of the token design in this work is that it does not requireusers to type digits from a toke display while using bidirectional authentication protocolswhich yield a higher security level than standard one-pass protocols that were used fortoken authentication so far.

At the same time, one must ensure that the token itself does not become a new vectorfor attack. Careful modeling of authentication and pairing protocols is needed. Properlyanalyzed, executed, and constructed to resist unintentional side channels, one could gaina great deal of confidence in these higher functions with security proofs extending fromthe security primitives through the interplay of the cryptographic protocols.

In this thesis we introduced a constructive use of other Wi-Fi side channels which can also– although side channels are usually treated in the literature as a means to attack systems– be used as a legitimate communication channel to form an intentional information flow.We show that packet length and other protocol fields can be used to tunnel unencrypted(protocol) data to monitor mode capable IEEE 802.11 devices. These side-channels cantherefore be used to send information to an arbitrary destination despite an existing Wi-Fi association. We showed up the different characteristics of these channels which maybe combined for bidirectional communication. We reached our goals that were stated inSection 1.2 and that have been summarized in Figure 1.3.

Our token enhances the current situation for token based authentication schemes in thefollowing way:

• No need for the user to manually type digits

• Higher bandwidth and bidirectional communication channel to the PC allows publickey protocols which simplify key management across multiple servers and allowsthe token to authenticate the server

• Rich interface on the wireless device allows transaction authentication to defeatTrojans and phishing attacks while requiring only one touch from the user.

Future work and challenges to overcome include but are certainly not limited to:

Error Correction The channel analysis showed that packet loss is likely to happen whileusing the side channels. In conjunction with high round-trip times a solution tothis problem might be the transmission of additional data that can be used tocorrect errors instead of having to request retransmission on the application layer.

36 Conclusions and Future Work

Channel Properties It might be desirable to improve error detection and create otherproperties in the same way that TCP builds a reliable transport on top of theunreliable IP (see section 2.1.1).

Implementational Details For industrial applications channel setup protocols wouldhave to be developed that let the token detect the channel of the PC’s network.At the same time some flow control variables should better

Use Nokia N810 as Demo-Token It would be desirable to port the Linux part of theexample application to OS 2008 / Maemo. This would render the example moremeaningful.

Part II.

Light-Weight Implementation of aHash Based Signature

Scheme

7. Introduction

7.1. Problem and Motivation

Abstract Problem Description Digital Signatures are used in many areas of every daylife. Application areas include payment systems, electronic health cards and SIM cardsfor mobile phones. With the advent of contactless smart cards, new and important fieldsof application have recently emerged, like the electronic passport, which is now deployedin many countries, especially in Europe and the US. Other countries, like Belgium, alsoissue electronic ID cards to their citizens [ePr03]. Digital Signatures can also be used forother areas of application, e.g. detecting product counterfeiting.

Many of the above mentioned applications have a need for strong security. Digital sig-natures provide authenticity, integrity and support for non-repudiation of data and areoften used in identification and authentication protocols on embedded devices.

As embedded devices are usually provided in high quantities, there is also a need tokeep costs as low as possible. This is one of the reasons why most of the microprocessorcards in use are still equipped with small and cheap 8-bit CPUs. These small 8-bitmicroprocessors are constrained in program memory (flash or ROM), RAM, clock speed,register width, and arithmetic capabilities.

Common signature schemes such as RSA and ECDSA require operations in a finite fieldfor the signature generation and verification. For efficient implementations in microcon-trollers, costly co-processors that implement the field arithmetic are required. In 1979Merkle proposed a signature scheme that requires only hash function evaluations for thesignature generation and verification [Mer89]. Since software implementations of hashfunctions are much more efficient than software implementations of finite field arithmetic,the Merkle Signature Scheme (MSS) is a good candidate for implementations on smallmicroprocessors without finite field engine. Another benefit of the MSS is the fact thatits security relies only on the cryptographic properties of the used hash function and noton additional number theoretic assumptions. If the hash function used for the MSS isfound insecure, it can be replaced by a secure one to obtain a new and secure instanceof the MSS.

It is therefore highly desirable to have an efficient implementation of an MSS variant for8-bit CPUs.

Efficiency of the Scheme Besides throughput, efficiency is very important: resourcesneeded by an implementation of a cipher should be kept small. In fact, in many situations

40 Introduction

resource efficiency is more crucial than throughput, in particular since many embeddedapplications only encrypt small payloads. Embedded devices always make a tradeoffbetween speed, program size and other memory requirements. E.g. for software updatesit is essential that the program size and the need of non-volatile memory is as small aspossible.

Nevertheless, especially for battery-powered devices, a low computational complexity canbe of great value too because processing time directly correlates to power consumption.Modern microcontrollers offer a variety of power-down and power saving modes they canenter as soon as they have finished computation. A fast executing algorithm can hencereduce the consumed energy and lengthen the lifetime of a battery-powered device.

An evaluation of the options to tailor the concrete MSS implementation through para-metrization towards different needs is therefore an important area of research.

7.2. Objectives for the Light-Weight Implementation of

a Hash Based Signature Scheme

We want to show that an implementation of an MSS variant on 8-bit microprocessorscan not only be efficient but can also outperform other digital signature schemes on thetarget platform. The Atmel AVR platform has been the natural choice due to their gooddocumentation, their optional symmetric crypto accelerator and our prior developmentexperience. To achieve this objective, the current state of research concerning hashsignatures has to be transformed into a system design for an efficient implementation ofthe MSS on the target platform.

By design, hash based signature schemes are limited in the maximum amount of signa-tures that can be created with on private key. Constrained devices, however, usuallyhave a very limited lifetime or are unfrequently used. We primarily target to create210 = 1024 and 216 = 65536 signatures. Nonetheless, it is also desirable to analyze theeffect of the maximum amount of signatures on the performance.

7.3. Research Approach

On our way towards the objectives we start in the next chapter with with working up thecurrent state of the art techniques for Hash Based Signature Schemes. These basics leadone chapter afterwards to an evaluation of suitable hash functions for the MSS schemeon the target platform. Based on those hash functions we present our design for anefficient MSS variant on the target platform and go on with performance measurementsand performance improvements using symmetric hardware accelerators. Last but notleast we consider the effects of scheme parametrization for various input parameters todemonstrate the flexibility of the scheme and our implementation.

7.4 Related Work 41

7.4. Related Work

Gura et al. showed the feasibility of public key cryptography on constrained 8-bit mi-crocontrollers. Their implementation of RSA-1024 and RSA-2048 showed that digitalsignatures are feasible on 8-bit platforms even without expensive crypto-coprocessors.Further research regarding digital signatures on constrained 8-bit devices has been per-formed in the field of wireless sensor networks. Liu and Ning published a full ECC enginecalled TinyECC [LN07] which also does not require a coprocessor. They implemented the160-bit elliptic curve secp160r1. Winternitz one-time signatures have also been proposedto be used in wireless sensor networks for signing short messages (< 80 bit) [LPW06].The proposed solution, however, uses a public key management that is not applicable tosmart cards. Others [YlJfQq07, CLZ06] show possible use cases for MSS on constraineddevices without making any suggestions regarding the implementation. There is only onepublic implementation of the MSS for the PC platform: a Java based implementationof the CMSS [BCD+06] (see chapter 8.1.4) is available as part of the open-source Flex-iProvider [Gro08]. The FlexiProvider can also be licensed for commercial applications,though it seems that the commercial variant does not include CMSS yet [Fle08].

8. Prerequisites for Designing aLight-Weight Hash Based SignatureScheme on Constrained Devices

Designing digital signature schemes through the properties of hash functions is a chal-lenging task. This chapter describes the necessary concepts and algorithms. However itis assumed that the reader has basic knowledge about hash functions including that helearned basic principles of classifying their attack resistances (first-preimage resistance,second-preimage resistance, collision resistance).

It is also important to note that “Light-Weight” does not mean a scheme is insecure bydesign, it is moreover a term to describe that it can be used practically on constraineddevices. In this chapter we will also give some details on the target platform to whichwe try to tailor our scheme.

8.1. Hash Based Signature in the Literature

8.1.1. Lamport-Diffie One Time Signature

In 1979 Lamport and Diffie described in [Lam79] a new method to achieve a one timesignature using only hash functions as cryptographic primitive. At the end of this sectionthe reader should have understood why cryptographic hash functions can be used toconstruct digital signature schemes.

Intuitive Approach

For ease of understanding we start with an illustration of the basic idea of digital signatureschemes constructed by hash functions. In the following example customer C will be ableto convince his bank assistant B through an arbitrary messenger that a specific moneytransaction should be conducted:

1. C randomly chooses x and precomputes H(x) = y.

2. C publishes y and tells his bank assistant B - witnessed by a trusted third partyor a written contract - that revealing x means that a certain money transactionshould be conducted.

44Prerequisites for Designing a Light-Weight Hash Based Signature Scheme on

Constrained Devices

3. Any time later, a messenger sent by C comes to B and provides him with x′. Bverifies that H(x′) = y, hence he knows that the equation x′ = x holds with a veryhigh probability true (depending on the quality of the second-preimage resistanceof the hash-function). B is therefore convinced that he should conduct the moneytransaction as only C could have revealed x to the messenger. He can also provethis to anybody else (e.g. a judge) as the trusted third party or the contract canwitness the commitment.

This illustration shows that a hash function can be used to substitute a handwrittensignature which is the basic idea of digital signatures.

This concept can be formalized and written as follows:

1. C randomly selects x

2. C computes H(x) = y

3. Commitment: C publishes y but keeps x secret. He also commits himself thatrevealing x has a certain meaning.

4. C reveals at any choosen time x. Only C knows about x, hence he is the only onewho can choose to reveal it.

Generalization

This real world example shows that under certain circumstances this method can achievethe same goal as a hand-written signature. Nonetheless, the piece of information whichis signed is binary (i.e. transfer the money or leave it on the account of C) which intu-itively means that this algorithm can also be extended to sign binary data of arbitrarylength. Every bit of an arbitrary binary string (e.g. the hash of a larger message h(m))is therefore signed by one H(x) = y pair. Hence revealing xn means that bit n of thedata to be signed is a 1. Not revealing xn means the bit n is 0.

Unfortunately this idea still suffers from one fundamental defect: the receiver of themessage could falsely claim that he or she never received some of the xn and thereforedamage the integrity of the signed bitstring by changing 1 into 0 at certain (choosen)positions of the information. For example, in the case of signing a digest in a hybridsignature scheme there is a much larger chance to forge a message which would bevalidated by the algorithm so far.

Improvement

We will now explain an improvement that addresses the problem that the integrity ofthe signed bitring cannot be prooven anymore. Naturally, it is always possible that thereceiver of a certain message denies that he ever got the message. Solving this problem ismoreover a task for protocols than for digital signatures. This results in the observation

8.1 Hash Based Signature in the Literature 45

that the so far specified protocol suffers from the defect that the original message couldbe slightly altered and automatically verified without notice of the signer. Fortunately,this problem can be solved by using a specifically encoded message with some extra in-formation. The validation routine for the signature message checks for a given signaturewhether every xn really has not been revealed by the original signer. The encoding willtherefore always create an invalid message if a 1 is changed to a 0 without changinganother 0 to a 1 - which is impossible without the knowledge of the respective preimage.

In practise the easiest to understand but also most ineffective example for such a codingscheme is signing a bitstring concatenated with the bitwise inverse of itself. The attackerwould therefore need to modify both the bits for the information and their inverse bits.However, this would include the unfeasible task of toggling bits from 0 to 1 and at thecorresponding position from 1 to 0.

It is obvious that every H(xn) = yn pair can only be used once for one signature bit.This is why these kind of signatures are called one-time signatures. Unfortunately, it alsoimplies that in this basic variant you a large amount of pre-shared data to sign messagesis needed in practise. Given a message with length lm every message to be signed needs2·lm pairs of (xn, yn). Each pair has a size of 2·ls whereas ls denotes the output size of theused hash function. To create n signatures n · 4 · ls · lm bits of storage are required. Evenmore important is that the receiver of the signature and any potential third party needsto store n · 2 · ls · lm bits of information. With a hash function output length of 256 bit(SHA-256), n = 1000 potential signatures and 256 bit data to be signed the impracticalamount of 1000 · 2 · 2562 bit = 131072000 bit = 15, 625 MByte needs to be stored andpre-shared for every communication partner. Although this might be feasible for a smalland stable set of users, this does not seem to be a viable solution for larger groups. And,in particular, this is probably absolutely unfeasible for most sorts of constrained devices.

Merkle proposes in his paper [Mer89] an optimized coding scheme which reduces theamount of bits needed for a signature compared to the naive coding scheme. This schemealso has the property that the accidental or intentional conversion of a 1 into a 0 willalso produce an illegal codeword. Therfore, the amount of zeros is concatenated as achecksum to the data to be signed. The amount of bits which need to be signed istherefore not doubled but increased by ⌈log2(lm)⌉ with lm denoting the amount of bitsto be signed.

8.1.2. Winternitz One-Time Signature Scheme

The Winternitz OTSS improves this basic idea further by using hash chains, i.e. re-peated application of the hash function. It has been explicitly described in [DSS05]. Theidea bases on the observation that knowing the last result of the hash chain does notlead to knowledge about any of its predecessors. Revealing a predecessor that is morethan just one hash application ’away’ also yields more than just one bit of information.


Constrained Devices

E.g. one public value H2t−1(xi) (meaning 2t − 1 iterative applications of H) can be usedto sign t bits of information. The signature of every block bi is therefore the valueHbi(xi).

It can be easily observed that Hbi(xi) values can be used to create a Hbi′

(xi) with bi′

greater than bi. In order to prevent this type of fake, a checksum is concatenated to theoriginal data. This checksum has the property that it must decrease if any individual bifrom the original data to be signed increases. Hence, as the checksum is also signed viaHbi(xi), an attacker would always need to forge one increased and one decreased block.This kind of fraud is however impossible. The checksum is calculated through

C =⌈n/t⌉∑

i=0

2t − bi.

An algorithmic description of this scheme can be found in section 10.1 and in [BCD+06].

8.1.3. Merkle Signature Schemes

The optimizations that were presented in the last sections do not make the scheme muchmore practical. It is still a one-time signature scheme which means that for every signa-ture independent data needs to be stored. Merkle therefore suggested a new tree basedauthentication method, which almost eliminates the large storage amount needed on theverification side. It was first published in [Mer89], a proof of security can be found under[Cor05].

The basic idea behind is to create a number of public key hash value sets together witha comparable small amount of authentication data. It is the only data that needs to bepre-shared and this authentication data is used to validate individual one time publickeys. Through this mechanism these one time public keys become part of the actual sig-nature. Hence, they do not need to be stored on the signature verification side. On thesending side the storage problem can be solved by using cryptographic random numbergenerators.During key generation, the public keys are used to generate an authentication tree basedon applications of the underlying hash functions. A signature verification key is a setY = {yn} whose size and structure depends on the respective OTSS. In MSS key gen-eration 2h signature key pairs (Xi, Yi), i = 1, .., 2h are created (note that every Xi andYi pair consists of many H(x) = y pairs. To be able to authenticate with least dataa binary tree is constructed using the hash of the Yi sets as leafs. The tree is furtherconstructed by hashing the concatenation of two direct siblings and inserting the hashinto a common ancestor (see Figure 10.1).

The root of the tree is therefore bound to every Yi. This root is the only necessary pre-shared information - every Yi can be authenticated using the root. However, the mostappealing observation is that in order to authenticate a specific Yi as being part of the

8.1 Hash Based Signature in the Literature 47

Figure 8.1.: Merkle signature schemes

original tree not all Yi hash values are necessary, but some nodes of the tree are sufficientand could be submitted together with the specific Yi. This can easily be achieved asthe complete tree is publicly known - the only private information are the Xi values andwithout them all other knowledge about the tree is worthless for signing purposes.

The information that is needed to validate a specific Yi is called authentication path. Itconsists of all siblings of the path from the specific Yi to the root. Using that data Yican be validated (by calculating the root and checking whether it matches the presharedroot) to be one of the seeds of the preshared root. Due to the second preimage resistanceof the underlying hash function it is impossible to forge any predecessor of the root ofthe tree.

8.1.4. CMSS/GMSS

As MSS become impractial when it is used with a very large number of possible signa-tures, a new method that practically provides up to 240 signatures has been presentedin [BCD+06]. It is based on the MSS and uses the Winternitz improvement. It reduceskey size, key generation time and signature generation time. One of the most importantideas in that method is the layering of MSS trees whereas the root of the trees in secondlayer is signed using the layer above. This means that only parts of the complete treehave to be construction upon key generation, saving much time. CMSS uses two layersand provides up to 240 signatures with reasonable timings. In particular, only the firsttree in the second layer is contructed during key generation. The computational effortsfor creating the “next subtree” is distributed through the signatures that can be donewith the first subtree. To reduce the private key size PRNGs are used to create the trees.This fact also allows the scheme to be a key-evolving signature scheme which means thatit is forward secure. In addition, the calculation of the authentication path is also highlyoptimized as suggested in [Szy04].


Constrained Devices

GMSS [BDK+07] generalizes these principles to an arbitrary amount of layers and itmakes it possible to create a virtually unlimited number of signatures while maintainingreasonable timings.

It is strongly suggested to read [BCD+06] and [BDK+07] for further information.

8.2. Considerations on the Target Platform

8.2.1. Microcontroller

Our implementation is designed for 8-bit AVR microcontrollers, a popular family of 8-bitRISC microcontrollers.

The Atmel AVR processors [Atm07b] offer clock speeds of up to 16MHz, a few kbytes ofSRAM, up to tens of kbytes of EEPROM and additional flash or mask ROM for programmemory. For our implementation the AVRs were clocked within specification limits at16 MHz. The AVRs have 32 general purpose registers of 8-bit word size. Most of the130 assembler instructions of the microcontroller are one-cycle.

For most measurement we specifically used the Atmel ATMega128 microcontroller oftenused for wireless sensor networks. Although this is one of the better equipped micro-controllers of the Atmel series in terms of memory, the results should be portable. Forplatforms that are even more constrained in available SRAM, our implementation canalso be altered to operate on systems with much less SRAM. ATxMega is the successorof the ATMega family and these processors includes a symmetric crypto engine that iscapable of accelerating DES [fST99] and AES [fST01].

Besides the standard AVR microcontrollers, the same architecture is also used in the AVRsmart card processors family AT90SCxxx [Atm07a]. Information access concerning theseprocessors is only available through non-disclosure agreements. The available informationhowever suggests, that code that has been developed for the AVR-platform should beeasily ported to these smart card processors.

8.2.2. Programming Language

The programming languages available for programming Atmel microcontrollers are AVR-assembler and C. As assemblercode can easily be integrated into C code we chose to useassembler for performance critical routines such as some crypytographic primitives and Cto glue these routines together. There is a free compiler from Atmel and a free gcc versionfor that platform available. In general, the AVR-gcc [AVR08] has better optimizationsand has been choosen to be used for this project.

9. Evaluation of Cryptographic HashFunctions

All methods described so far depend heavily on cryptographic hash functions. Hence,it is very important to analyze the suitability of existing schemes towards the specificrequirements of hash based signature schemes.

One possible distinction for them available is:

• dedicated hash functions

• block ciphers as hash functions

Both concepts have advantages and disadavantages which will be covered in this chapter.

For hash signatures the choice of the output length of a hash function has a crucialimpact. Long output length of hash functions significantly increase the memory andcalculation requirements (see [BDK+07] for an analysis of the requirements for CMSS).In most applications the data to be signed is the result of a hash function, hence itis important to note that this hash function needs to be collision resistant. At thesame time hash signature schemes itself base on the fact that it is nearly impossible tofind a second preimage of a given hash. These varying requirements result in differentbitlength requirements for the hash output and they suggest that it might be advisableto use different hash functions for these two applications if hardware constraints motivatethis.

9.1. Dedicated Hash Functions

Dedicated hash functions are specifically designed for and have the sole purpose of hash-ing. If they were only used for digital signatures this results in adding an additionalcryptographic primitive that cannot be used otherwise and which increases the codesize.However, this problem mostly concerns embedded platforms as most other platforms donot have strict codesize requirements. For a good coverage of the currently applied hashalgorithms and their performance on a Pentium III see [NM02]. Dedicated hash functionsusually have a large bitlength that provides a good collision resistance.

Many dedicated hash functions are available and it is possible to take any of them as theunderlying hash function for the implementation on the microcontroller. However, someof them are better suited for hash signature schemes than others. In table 9.1 an overview

50 Evaluation of Cryptographic Hash Functions

of hash functions and their output and block size is given. In [NM02] performance resultsfor most of them on the Pentium III platform can be found.

Table 9.1.: Overview of dedicated hash functions

algorithm hash length block size(bit) (bit)

sha-1 160 512sha-256 256 512md5 128 512whirlpool 512 512tiger 192 512ripemd-160 160 512

It is important that some of the seem to be better suited than others. E.g. whirlpool isspecified with a hash size of 512 bit. This is way to large for an efficient digital signaturescheme using hash functions because the amount of data needed would be unnecessarilylarge. It is also interesting to note that all of them are optimized for a large amount ofdata as the blocksize is 512 bit. As for hash signature schemes, the input for the hashfunction is usually a value that has the same size as the output value. This disadvantagesuggests that these functions might provide suboptimal performance for this application.Despite this fact the large blocksize is suboptimal for an implementation on the AVRmicrocontroller platform as the state cannot be held completely in the registers.

9.2. Block Ciphers as Hash Functions

In this section we present hash functions that re-use symmetric block ciphers. Further-more we show that those single and double block length constructions are the betterchoice when used in conjunction with digital signatures. Relatively short input blocklengths and the resulting speed make them better suited for implementations on con-strained devices. Public key and private key sizes of hash based signature schemes areproportionally dependent on the hash output length. As stated earlier, a short value of128 bit offers adequate security for this scenario while staying within reasonable memorylimits. We aim to investigate constructions that use the AES algorithm which is specifiedwith a block length of 128 bit. Using AES in a double block length construction leadsto a hash length of 256 bit.

Using block ciphers as hash functions in digital signature schemes is also appealing be-cause one primitive can be used for three applications: encryption, generation of hashes,and digital signatures. In addition to this, block ciphers are much better known and ana-lyzed than dedicated hash functions. Nonetheless, they have also practical disadvantages– the output length equals the block length of the underlying block cipher. This lengthis often quite short (e.g. 64-128 bit). Concerning security this number is even reduced byhalf – due to the birthday paradoxon – to estimate the effort to find a collision. However,

9.2 Block Ciphers as Hash Functions 51

as the second preimage resistance is the most important thing for the underlying hashfunction of a digital signature scheme, this basic variant is even supposed to be sufficientfor medium term security.

In this section two constructions of hash functions from block ciphers are presented andcompared to dedicated hash functions. Both use the AES as their basis. An AES imple-mentation which is fast and small is available for the AVR platform from [Rĳ08]. Themodifications to this implementation to make it even more small and faster are presentedin section 9.2.4.

9.2.1. Single Block Length Construction

The single block length hash in our scheme is constructed using a Matyas-Meyer-Oseas(MMO) construction [MVV96]. The basic idea is to iteratively use its definition in a waysuch as the original data or the result of the previous round cannot be reconstructed.The MMO construction is recursively defined as fi+1 = Efi(Mi)⊕Mi with E being theencryption function,Mi as the current message block and f0 being an initialization vectorused as the first symmetric key (see Figure 9.1). In a hash signature scheme this variantfor constructing the hash benefits from the fact that the encryption function always usesthe same key (an initialization vector) for the first block. For data sizes that are nomultiples of the symmetric cipher’s block size it is necessary to pad incomplete blockswith zeros.

fi fi+1

Mi

E

Figure 9.1.: Single block length compression function due to [MVV96]. The output ofthe block cipher E is xored with the message block Mi. fi, fi+1, and Mi areeach of bit length 128.

9.2.2. Double Block Length Construction

For applications such as the initial digest generation in a signature scheme, collisionresistance is needed and the security of single block length (SBL) constructions is notsufficient. Hirose showed in [Hir06] how a block cipher with a key length of twice theblock length can be used to construct a double block length (DBL) hash function. Forour implementation, we use a variant of the MDC-2 [MVV96] double length constructionspecified in the ISO/IEC 10118-2 standard [ISO00]. The standard envisions the usage


of DES, but there is a variant using AES-128 [Vie04], as depicted in Figure 9.2. Thisconstruction takes a block cipher with block length n bit and produces a hash functionwith 2n bit output length. In [Ste07] the authors show, that an adversary needs at least23n/5 oracle queries to find a collision. However, the best practical attacks require 2n

queries.

In our proposed scheme the double block length construction is only used for initial digestgeneration. However, it can easily be replaced by a dedicated hash function resulting ina negligible performance loss but an increased code size.

g0i

g1i

Mi

(A ‖ B)

(C ‖ D)

g0i+1 = C ‖ B

g1i+1 = A ‖ D

E

E

Figure 9.2.: Double block length compression function due to [Vie04]. The outputs ofthe block cipher E are xored with the message block Mi and permuted.g0i , g

1i , g

0i+1g

1i+1, and Mi are each of bit length 128.

9.2.3. Comparison to Dedicated Hash Functions.

SBL and DBL constructions are much better suited for hash-based signature schemesthan dedicated hash functions. A hash function with 512 bit (e.g. whirlpool) lengthwould yield a highly inefficient signature scheme. At the same time it is also interestingto note that dedicated hash functions are optimized for large amounts of data as can beseen by the comparatively large block size (512 bit). With the MSS, the input for thehash function has mainly the same size as the output value. This is one of the reasonswhy dedicated hash functions provide suboptimal performance for appliances in hashbased signature schemes.

In addition to this, large block sizes reduce the speed of implementations on the AVRmicrocontroller platform since the state cannot be held completely in the registers ofthe processor. In Table 9.2 we provide a comparison of various hash functions and theirperformance. The results for the dedicated hash functions are taken from [GVP+03] and[Lab08].

Concerning the cycles required to hash one block, the block cipher based hash functionsprovide much better performance. This performance is also due to the large block sizeof 512 bit used by dedicated hash functions to allow efficient hashing of large amounts ofdata. The single block performance is however mostly irrelevant for other applicationsthan hash based signatures. This situation is clarified by the column “cycles per byte”which shows that dedicated hash functions and block cipher based hash functions require

9.2 Block Ciphers as Hash Functions 53

Table 9.2.: Performance of hash function implementations on the AVR platform

bit length per msec per cycles perHash function output block block block byte

SHA1 [GVP+03] 160 512 3.93 63,000 984SHA1 [Lab08] 160 512 2.57 41,113 642SHA256 [Lab08] 256 512 3.39 54,196 847MD5 [GVP+03] 128 512 1.47 23,568 368

AES-SBL 128 128 0.26 4,081 255AES-DBL 256 128 0.51 8,104 507DES-SBL 64 64 0.01 189 23DES-DBL 128 64 0.05 841 105

a more similar time to hash one input byte. However, for the Merkle signature schemeand our choice of parameters most of the time only blocks of length up to 256 bits mustbe hashed, which requires about 8,000 cycles when using the SBL construction.

The numbers show that using the DBL construction for the generation of the digest ofthe data to be signed is a good choice. Besides, using the single block length constructionwith 128 bit block size is sufficient for the hashsize of the hash signature scheme. Thelatter is also very much better in respect to performance compared to other hash functionson the target platform. This combination has the advantage that one primitive (namelythe AES encryption) allows one to take different sizes for digest and hash size. Whilefor this implementation the AES decryption has been removed from the code, it couldbe added with a very small increase in codesize yielding the full strength of the AESencryption on the microcontroller.

Hence, on the target platform SBL constructions are a better choice for the Merklesignature scheme when compared to dedicated hash functions.

9.2.4. AES-Implementation

An efficient AES implementation for the AVR platform is available at [Rĳ08]. It islicensed under the GPL. We modified this implementation to make it even smaller andfaster. In this section we describe our modifications and improvements concerning thisAES algorithm.

The RĳndaelFurious algorithm is pure assembly code that can be compiled using theAtmel AVR compiler. Some modifications made it compilable using the avr-gcc. Foreasy accessibility from C-code, a C-header file and the corresponding AVR-asm entrancemethods were created. In addition the decryption functionality has been removed as it isnot necessary for hash function constructions. If an AES decryption is needed, it can beeasily added by the cost of a small increase in code size yielding the full strength of AESencryption on the microcontroller. Furthermore, we contributed our own implementation


of the AES’ “MixColumns” function that is better in respect to performance and codesize.

The MMO construction uses the initialization vector as the first encryption key. For afurther speed-up we also implemented an alternative method with a pre-expanded key.This trick allows us to save many key expansions in the process of creating one-blockhashes.

10. Hash-Based Signature Scheme

In this chapter we present our solution to digital signature verification on a device withvery limited resources and motivate the architecture of our proof of concept implemen-tation.

The Winternitz signature scheme is parameterized and it therefore yields with distinctparameters good results for different scenarios. Hence the decision about the OTSS isreduced to a decision about the optimal winternitz parameter. However this decisionis strongly interconnected to the decision about hash value length and the target plat-form.

As stated in section 7.2 the goal for this project is to be able to verify up to 210 = 1024/ 216 = 65536 signatures. This can easily be achieved using Merkle trees of heights 10and 16 like it has been explained in section 8.1.3. It is important to note that during sig-nature creation the most difficult task is the generation of the next authentication path.However, during verification, the authentication path only has to be validated instead ofhaving to create it. This means that signature key validation is neither a performancenor a memory problem in this scenario.

In this section we formally describe the details of the variant of the Merkle signaturescheme [Mer89] we use for our implementation. In summary we use the Winternitz onetime signature (W-OTS) [DSS05] to sign the data, the ideas for efficient one-time signa-ture key generation of [BCD+06] and the algorithm from [BDS08] for the computation ofthe authentication paths. We use two different hash functions based on the AES blockcipher, both with 128-bit block length. We use a 256-bit hash function for the initialhashing (digest creation) of the data to be signed and a 128-bit hash function for theone-time signature scheme and the Merkle tree. Details on the construction of thesehash functions are described in Section 9.2. An introduction to the concept has beenpresented in chapter 8.1.

10.1. Our Variant of the Merkle Signature Scheme

We now describe1 the three algorithms for the key generation, signature generation, andverification. In the following, let F : {0, 1}∗ → {0, 1}128 and G : {0, 1}∗ → {0, 1}256 becryptographic hash functions.

1This section was in large parts taken from our publication [RED+08] and has mainly been written bymy co-author Erik Dahmen.

56 Hash-Based Signature Scheme

10.1.1. Key Generation

The first step of the key generation is to decide how many signatures should be generatedwith this key pair. We choose the parameter H ≥ 2 to be able to generate 2H signatures.The next step is to generate 2H W-OTS key pairs. For the W-OTS key generation, weapply the approach of [BCD+06] and use the following forward secure pseudo randomnumber generator.

PRNG : {0, 1}128 → {0, 1}128 × {0, 1}128,Seedin 7→ (Seedout,Rand).

As suggested in [BDK+07], we use the hash based PRNG proposed in [FIP07], i.e.

Rand← F (Seedin),Seedout ← (1 + Seedin + Rand) mod 2128.

The MSS private key is an 128-bit Seed chosen uniform at random. This Seed is fedto the PRNG to compute the initial SeedW-OTS that we use to generate first W-OTSsignature key:

(Seed,SeedW-OTS) = PRNG(Seed). (10.1)

Doing so, Seed is updated and can be used to compute the initial seeds for upcoming W-OTS signature keys. Depending on the Winternitz parameter w, the W-OTS signaturekey consists of t = t1 + t2 128-bit strings, where

t1 =⌈256w

⌉

, t2 =⌈

⌊log2 t1⌋+ 1 + ww

⌉

.

The W-OTS signature key is the sequence X = (x1, . . . , xt), that consists of t bit stringseach of length 128-bit. It is computed using the PRNG as

(SeedW-OTS, xi) = PRNG(SeedW-OTS) (10.2)

for i = 1, . . . , t. The W-OTS verification key is Y = F (y1 ‖ . . . ‖ yt), where yi =F 2w−1(xi), i.e. the hash function F is applied 2w − 1 times to xi for i = 1, . . . , t.

The 2H W-OTS verification keys are the leaves of the Merkle tree. The inner nodesare computed using the following construction rule: a parent node is the hash of theconcatenation of its left and right children, i.e.

Nodeparent = F (Nodeleft child ‖ Noderight child).

By applying this rule iteratively the root of the Merkle tree, which is also the MSS publickey, is obtained.

10.1.2. Signature Generation

To sign some data, the first step is to compute its 256-bit digest: d = G(data). TheW-OTS signature keys are used sequentially. We describe the generation of the sthsignature, s ∈ {0, . . . , 2H−1}. The sth W-OTS signature key is computed from the Seed

10.1 Our Variant of the Merkle Signature Scheme 57

as described in Equations (10.1) and (10.2). We always update the seed in the privatekey and therefore one invocation of the PRNG suffices to obtain the initial SeedW-OTS tocompute the sth W-OTS signature key. The Winternitz signature of d is then computedas follows: (1) split the binary representation d into t1 blocks b1, . . . , bt1 each of lengthw. (2) consider bi as the integer encoded by this block in binary and compute c =∑t1i=1(2

w − bi). (3) split the binary representation c into t2 blocks bt1+1, . . . , bt each oflength w. If the bit-length of c or d is no multiple of w we pad with zeros to the left. TheWinternitz signature of d is then given as σW-OTS(d) = (σ1, . . . , σt), where σi = F bi(xi),for i = 1, . . . , t. The sth MSS signature of d is given as

σs(d) =(

s, σW-OTS(d), (a0, . . . , aH−1))

.

The sequence (a0, . . . , aH−1) is the authentication path for the sth leaf, i.e. the sth W-OTS verification key. It is defined as the siblings of all nodes on the path from the sth leafto the root of the Merkle tree, see Figure 10.1. For the computation of authenticationpaths we use the BDS algorithm from [BDS08]. This algorithm is constructed suchthat the authentication path for the currently used leaf is already available and theupcoming authentication paths are prepared after the MSS signature is computed. TheBDS algorithm uses a parameter K ≥ 2 which decides how many nodes close to the rootare stored during the initialization to reduce the computational cost. The initializationof this algorithm, that requires certain tree nodes to be stored, is done during the MSSkey generation.

s

a0

a1

a2

Figure 10.1.: Example of the Merkle signature scheme for H = 3, s = 3. Dashed nodesdenote the authentication path for the sth leaf. The arrows indicate thepath from the sth leaf to the root.

10.1.3. Signature Verification

The first step of the signature verification is again to compute the digest of the data thatwas signed: d = G(data). Then d and its Winternitz signature are used to compute thesth leaf as follows: Repeat steps (1)-(3) of the Winternitz signature generation to obtainb1, . . . , bt. The sth leaf ϕ is computed as

ϕ = F(

F 2w−1−b1(σ1) ‖ . . . ‖ F 2w−1−bt(σt))


Then the path from the sth leaf to the root and the root itself is recomputed using theauthentication path and the index s:

ϕ ={

F (ϕ ‖ ah) , if s/2h ≡ 0 mod 2F (ah ‖ ϕ) , if s/2h ≡ 1 mod 2

for h = 0, . . . , H − 1. If the computed root matches the signers public key, the signatureis valid.

10.1.4. Time and Memory Requirements

We now estimate the number of evaluations of F required for the key generation, signa-ture generation and verification. We also estimate the storage requirements of the publicand private key and the signatures.

The MSS key generation requires the computation of 2H leaves or W-OTS key pairsand 2H − 1 evaluations of F to compute the root. The computation of one leaf costst(2w − 1) + 1 evaluations of F and t + 1 calls to the PRNG. Using that one call tothe PRNG costs as much as one evaluation of F , the key generation in total requires2H(t2w + 3)− 1 evaluations of F . The public key requires 128 bits of memory.

For each signature, the BDS algorithm requires at most (H − K)/2 + 1 leaves, 3(H −K − 1)/2 + 1 evaluations of F and H − K calls to the PRNG to compute upcomingauthentication paths. If s is even the BDS algorithm requires (H−K)/2+1 leaves to becomputed. One of these leaves is the sth leaf. Since the Winternitz signature of the datajust signed using the sth W-OTS key is an intermediate value during the computation ofthe sth leaf, the generation of this Winternitz signature needs no additional calculationsin this case. If s is odd, the BDS algorithm requires only (H − K)/2 leaves to becomputed and the Winternitz signature of the data must be computed separately. Sincethe generation of a Winternitz signature requires less computations than a leaf, the abovecost for the BDS algorithm also represents the total cost for signing. Hence, the total costfor signing in terms of evaluations of F is at most t2w(H−K−2)/2+(7H−7K+3)/2. TheBDS algorithm needs to store 3.5H−3K+2K−2 nodes of the Merkle tree and 2(H−K)seeds which we store as part of the private key. Together with the 128-bit seed used togenerate the signature keys, the size of the private key is given as (5.5H−5K+2K−1)·128bits. The size of the signature is given as (t+H) ·128 bits. t ·128 bits for the Winternitzsignature and H · 128 bits for the authentication path.

The signature verification on average requires t(2w − 1)/2 evaluations of F to computethe sth leaf and H evaluations of F to recompute the path to the root and the root itself.The signature generation and verification also require one evaluation of G to computethe initial digest d of the data.

The above formulas show that the Winternitz parameter w provides a time-memorytrade-off of the signature size and the key and signature generation times. However, thekey and signature generation times of the W-OTS keys are exponential in w, while thesignature size decreases only linearly in w. Therefore w should not be chosen too large.

10.2 Security 59

Also the output length of the hash functions F and G must be chosen carefully sincethe size of a Winternitz signature linearly depends on their product. Our choice of 128and 256 bit yields moderate signature sizes and, as we will explain in the following, highpractical security.

10.2. Security

The MSS is provably secure against adaptive chosen message attacks, if the used hashfunction is collision resistant [Cor05]. However, to forge a MSS signature in practice theattacker is required to compute preimages and second-preimages. Therefore the practicalsecurity of the MSS currently relies on the preimage and second-preimage resistance ofthe used hash function [NSW05]. From a practical point of view, the 128-bit hash func-tion F we use for the W-OTS and the Merkle tree provides 128-bit security. Collisionresistance is definitely required for the initial hashing of the data to sign. This is why weuse the 256-bit hash function G, which provides 128-bit security against collision attacksthat exploit the birthday paradox.

For smart card implementations, resistance against side channel attacks is of high im-portance. All parts of an implementation handling sensitive data need to be protectedagainst a possible leakage. The W-OTS signature keys X and their Seed are the onlycritical data. Since the keys X and their seeds are used as one-time keys, the values arebeing processed very few times, rendering non-template based attacks difficult. How-ever, the analysis of the vulnerability against side channel attacks and, if necessary, thedevelopment of efficient countermeasures are an interesting field for future work.

10.3. System Design for a Proof-Of-Concept

Implementation

10.3.1. 4-Layer Architecture

The architecture of the implementation has been designed as a testing platform for thechoosen algorithms while maintaining a high degree of independence of the cryptographicprimitives among each other. Every layer of the architecture can therefore be optimizedfor specific requirements of the target environment yielding optimal results. The layersof the current implementation are:

1. Block cipher

2. Single and double block length hash function contructions from the block cipher

3. Winternitz one time signature scheme

4. Merkle tree based authentication path management


10.3.2. Memory Management

The MSS is key evolving, which means that after every signing process a modificationof the private key is required. The private key needs to be stored in nonfluent memorywhen the power is lost. Our implementation stores the private key in EEPROM, sincethe maximum amount of erase/write cycles allowed on the flash memory are usuallymuch more limited than on the EEPROM. Our target platform is specified for at least100.000 erase/write cycles [Atm07a, Atm07b]. Therefore, the maximum value for theheight of the Merkle tree supported by our implementation is H = 16, which allows usto generate 216 = 65.536 signatures. We store the whole signature in the SRAM duringcreation. However, for platforms that are even more constrained concerning SRAM ourscheme can easily be altered to support incremental signature generation and verificationwith much less RAM.

The memory constraints also enforce a very economical way of organizing the data of theprivate key. Despite of heavy optimizations, some implementation details force the actualsize of the private key to be slightly larger than the calculated results from section 8.1.3.The main reason is that these formula count only the number of hash values that must bestored. For example, the stacks used by the BDS algorithm were implemented as arraysof fixed size. In addition to the stack, we need to store the index of the array element thatdenotes the top node on the stack. Also the size of the signatures is slightly larger thanestimated, because the authentication path is saved as an array of hash values togetherwith the public key index of the respective one time public key in the merkle tree. Thisindex allows us to exactly define the structure of the corresponding authentication path.Therefore, it can be easily discovered whether a authentication path value is the first orthe second part to be hashed to get the parent node.

10.3.3. Key Generation

Due to the heavy computations required, the key generation is not done on the microcon-troller but on a standard PC. For the generation of test data, we created a PC version ofthe project that uses mostly the same code base. In contrast to the AVR implementation,it uses a different implementation of the block cipher and it supports key generation. Thekey generation is computationally far too costly to run on the microcontroller which iswhy it has been disabled in the AVR implementation. The speed of the PC version hasalso been used to verify the correct behavior of our code by iterating through all possiblesignatures.

11. Performance Measurements andImprovements Through HardwareAcceleration

In this chapter we present the performance characteristics of our implementation. Wealso consider improvements that can be achieved using DES and AES hardware acceler-ation facilities on the target platform. In order to put these measurements on a strongbasis we start with considerations on how to measure performance on a microcontrollerplatform.

11.1. Considerations on Measuring Performance

Measuring performance is an important indicator of the quality of the implementation.However, it must be taken into consideration that performance is heavily dependent onenvironmental factors. The easiest to understand fact that affects the results is the clockfrequency. Doubling the frequency reduces the duration of all measurements by half.However, a frequency invariant way of evaluating performance is to measure clock cyclesinstead of absolute time measurements. We focused therefore on this type of measure-ments throughout this thesis. Absolute time measurements are also made available forconvenience reasons. In this section we will also present considerations on the measure-ment process itself and the impact of compiler optimizations on the measurements.

11.1.1. Intrinsic and Extrinsic Measurement of MicrocontrollerPerformance

Measuring performance on a microcontroller is very different to measuring performancefor a standard PC. Most notably, the latter is a complete system while a microcontrollermay only be compared to a processor. Performance measurements are therefore heavilydependent on the environment. Embedded platforms often do not even have an operatingsystem which handles in and output to a user interface. This becomes even more difficultas embedded platforms very often do not even have a standardized user interface where itis easy to output performance information. For those platforms, like our microcontroller,other means of getting performance information out of the internals of the device needto be found. Another problem is that measuring performance is usually about timeinformation that is not always easily and without restrictions available. Real Time Clocks

62 Performance Measurements and Improvements Through Hardware Acceleration

(RTCs) are only available on some platforms while other timers usually heavily depend onclock frequency of the microcontroller what makes writing generic code more complicated.There are ways to overcome these problems by using the available interfaces of themicrocontroller to export performance information. However, this intrinsic measurementprocess always affects the results because in- and output functionality requires time andprogram space. Another way of analyzing performance for microcontrollers would be toextrinsically measure the performance of an emulated instance of the microcontroller,like those that usually come with development environments. Hence, a developmentenvironment can provide runtime information like the total cycle count since startingthe application. As this measurement type is extrinsic and does not affect the actualruntime behavior, we believe this to be the method of choice. In particular, this alsoallows one to measure performance through software implementation without the needfor a complicated hardware and interface setup. However, it must be admitted thatthe quality of the measurements in this case is heavily dependent on the quality of theemulator.

11.1.2. Impact of Compiler Options on Timings

Compiling the project using reasonable compiler options shows that an intermediatevariant of our signature verification can be done with our implementation in 133ms. Atthe same time we have a small codesize of 6004 bytes. In Table 11.1 an overview is givenabout the most important compiler options and their effect on code size and executiontimes. It illustrates that in our case “-O2” is a very good tradeoff between both of them.A description of the compiler options for the avr-gcc can be found in [GNU08].

Table 11.1.: Execution times and compiled size for important compiler options

Option(s) Size Speed(bytes) (ms)

-O0 7930 210-O1 6076 136-O2 6004 133-O3 8200 130-Os 5976 140-Os -mcall-prologues 5810 141

11.2. Performance Results

In this section we present the timings of our implementation and the exact memoryrequirements for the microcontroller. We also compare these values to implementationsof state of the art signature schemes on the same microcontroller platform. For theheight of the Merkle tree we chose H = 16 and H = 10 which allows us to generate 216

11.2 Performance Results 63

and 210 signatures with one key pair, respectively. The reason for the choice of H = 16is, that 216 is near to the maximum number of allowed write cycles for the EEPROM ofthe microcontroller [Atm07a, Atm07b]. The values for H = 10 were included to clarifythe impact of the tree height on the signature generation time. For the Winternitzparameter w and the parameter K for the BDS algorithm, we tested three combinations(w,K) = (2, 2), (2, 4), (4, 4). The value t, that denotes the number of 128-bit strings inthe W-OTS signature key and the one-time signature, is t = 133 for w = 2 and t = 67 forw = 4. Table 11.2 summarizes the results. spub, spriv, ssig, and sROM denote the memoryrequirements for the public key, the private key, and the signature as well as the code sizein bytes, respectively. tverify and tsigning denote the average time in milliseconds requiredfor verification and signature generation, respectively.

Table 11.2.: Timings and memory requirements of our implementation and comparisonto state of the art signature schemes on the same platform.

Memory in bytes Time in msecScheme spub spriv ssig sROM tverify tsigning

Our MSS-128 implementation using H = 16(w,K) = (2, 2) 16 1440 2386 6600 85 1230(w,K) = (2, 4) 16 1472 2386 6600 85 1072(w,K) = (4, 4) 16 1472 1330 6600 127 1665

Our MSS-128 implementation using H = 10(w,K) = (2, 2) 16 848 2290 6600 82 756(w,K) = (2, 4) 16 876 2290 6600 82 598(w,K) = (4, 4) 16 876 1234 6600 124 946

RSA-1024 [GPW+04] 131 128 128 7400 215 5495RSA-2048 [GPW+04] 259 256 256 10600 970 41630ECDSA-160 [DPP08] 40 21 40 43200 423 423ECDSA-160 [LN07] 40 21 40 17900 1218 1001

Table 11.2 shows that our implementation features smaller code size and smaller publickeys. The above figures already include the code size of the hash function needed fordigest generation and the AES engine. Also the signature verification times are fasterthan those of RSA and ECDSA. The signature generation time of our implementation ismuch faster than the RSA implementations and comparable to the ECDSA implemen-tations. In case of H = 10 our implementation is even faster than the memory efficientECDSA variant from [LN07]. The main drawbacks of the MSS are the large memoryrequirements for the signature and the private key. However, both the private key andthe signature easily fit into the EEPROM and the SRAM of the Atmel, respectively.

We finally remark that our implementation provides a practical security of 128 bitsand hence offers long term security until the year 2090 [Len04]. RSA with an 1024-bitmodulus offers comparable symmetric security of only 72 bit, i.e. until the year 2006.

64 Performance Measurements and Improvements Through Hardware Acceleration

The security of 2048-bit RSA is at most 95-bit, i.e. until the year 2040. ECDSA using160-bit elliptic curves offers only 80 bit of security, i.e. until the year 2018. This showsthat our implementation is not only very competitive to currently used schemes, but alsooffers higher practical security [Len04]. Furthermore, the code size of our implementedhash based signature scheme is about five times smaller. While most of the code sizeoverhead is due to the complex arithmetic of ECDSA, we have to admit that our codestill lacks the signature generation part. On the other hand, the code already includesa hash engine that is performance-optimized for small message lengths, as well as ahigh-security, well-performing symmetric crypto engine, the AES.

11.3. Hardware Accelerated AES

Table 11.3.: Performance of HW accelerated AES based hash functions on the AVRATxMega platform


AESHW-SBL 128 128 0.07 1,069 66AESHW-DBL 256 128 0.13 2,086 130

The most performance critical part of our MSS implementation is the AES based hashfunction. Hence, a natural approach to improve the scheme’s overall performance isto accelerate the AES implementation. Many recent low-/mid- budget smart card pro-cessors offer hardware acceleration for symmetric encryption schemes like the AES. Onepublicly available platform offering an AES hardware acceleration is the Atmel ATxMega128A1 processor.

In contrast to the software implementation of the SBL construction using AES thatrequires 4,081 cycles per block, the hardware accelerated version requires only 1069cycles per block. However, the AES engine itself needs only 375 cycles on the targetplatform. Besides the overhead for the hash function construction, the remaining cyclesare mainly required for the necessary memory management. Table 11.4 illustrates theperformance of the MSS when utilizing AES hardware acceleration. This table shows,that speeding up the hash function by a factor ≈ 3.82 results in a speed up of the Merklesignature scheme by roughly the same factor.

11.4. DES Hardware Acceleration

Reducing the level of security while increasing speed is an option that might be of interestfor certain areas of application like Wireless Sensor Networks [DPP08]. We created avariant of our scheme that benefits from the single and double block length contructions

11.4 DES Hardware Acceleration 65

Table 11.4.: Timings and memory requirements of our implementation with AES hard-ware acceleration.


Our MSS-128 implementation using H = 16 / Hardware AES(w,K) = (2, 2) 16 1440 2386 6100 24 362(w,K) = (2, 4) 16 1472 2386 6100 24 317(w,K) = (4, 4) 16 1472 1330 6100 38 504

Table 11.5.: Performance of HW accelerated DES based hash functions on the AVRATxMega platform


DESHW-SBL 64 64 0.01 189 23DESHW-DBL 128 64 0.05 841 105

using the DES instead of the AES. This variant works with cut in half hash input andoutput block length. It also benefits from the DES hardware accelerator in the ATxMegawhich runs every DES-round single cycle and which operates on the registers yieldinghigh speed hash functions for lower security requirements.

Table 11.6.: Timings and memory requirements of our implementation with DES hard-ware acceleration.


Our MSS-56 implementation using H = 16 / Hardware DES(w,K) = (2, 2) 16 744 682 6700 4 30(w,K) = (2, 4) 16 760 682 6700 4 24(w,K) = (4, 4) 16 760 410 6700 7 36

Our MSS-56 implementation using H = 10 / Hardware DES(w,K) = (2, 2) 16 440 634 6600 4 46(w,K) = (2, 4) 16 452 634 6600 4 41(w,K) = (4, 4) 16 452 362 6600 7 61

12. Remarks on the Impact of SchemeParametrization

In this chapter we elaborate on the various parameters that affect signature size, keysizes, and computation time of the MSS. For the formula please refer to Section 10.1.4.

12.1. Leaf Calculation

One of the most crucial design considerations that have to be made is the choice of theunderlying hash function(s). In this section it is assumed that the data to be signedis also the result of a hash function. This result is called “digest”. To distinguish itfrom the result of a single hashing operation during the signatures scheme, the latter iscalled “hash” - despite the fact that the digest is also a hash value. It is important to

digest size lm (bytes)32 64 96 128 160 192 224 256

2500

1500

1000

2000

500

0

signature size (bytes)# hash calls for verification# hash calls for signing

private key size (bytes)

Figure 12.1.: Impact of digest size on private key and signature size and # of hash func-tion calls for signing and verification using w = 2, K = 4, H = 10 andls = 128 bit

note that the length of the digest to be signed and the length of the hash value for the

68 Remarks on the Impact of Scheme Parametrization

signature scheme play both important but distinct roles in the process of choosing theappropriate hash functions for the signature scheme. The Digest size affects signaturesize and the amount of hash calls during signing and verfication linearly. The privatekey size is however not affected by these parameters at all. Hence, for speedup andsmaller signatures it would be desirable to reduce the size of data to be signed. If it isonly necessary to sign a very small amount of data computational effort and signaturesize would be reduced drastically. For special areas of application like wireless sensornetworks this might be of particular interest (see Figure 12.1). In contrast, the hash size

hash size ls (bytes)32 64 96 128 160 192 224 256

1000

2000

3000

4000

5000

0



Figure 12.2.: Impact of hash size on private key / signature size and # of hash functioncalls for signing / verification using w = 2, K = 4, H = 10 and lm = 256bit

affects private key size much more than signature size, but both depend linearly on it.The amount of hash calls stays constant but increasing the hash length does usually alsoaffect heavily the performance, as an increased hash length usually also increases thecomputational effort for one hash. The actual choice of parameters is closely related tothe concrete requirements for the specific scenario. As the memory requirements bothincrease almost linearily with the hash and digest size these parameters should be heldas small as possible.

In Figure 12.3 we show the impact of the Winternitz parameter w on performance andmemory requirements. It reduces the size of signature and private key at the cost of anexponentially increasing number of hash function calls resulting in less speed. See alsotable C.1 in appendix C for the numeric impact of the Winternitz parameter and hash /digest sizes on the time and memory requirements for a single leaf calculation.

12.2 MSS / BDS Parameters 69

Winternitz parameter w1 2 3 4 5 6 7 8

35000

30000

25000

15000

10000

20000

5000

0



Figure 12.3.: Impact of Winternitz parameter on private ley / signature size and # ofhash function calls for signing / verification using K = 4, H = 10, ls =128Bit and lm = 256 bit

12.2. MSS / BDS Parameters

The Merkle tree height h increases exponentially the maximum amount of signaturethat can be created with a single private key. At the same time it only affect linearlythe computantional effort for signing and private key size. The increase in verificationtimes is almost neglibe, the tree height therefore only affects practically the private keyholder for storing the key and for signing data. See Figure 12.4 for a visualization of thiseffect.

The BDS parameter “K” trades a linear gain in creating signatures for an exponentialincrease in private key size. The optimal parameter will therefore always be very small,however the concrete optimum depends heavily on the platform’s memory.

70 Remarks on the Impact of Scheme Parametrization

tree height h6 8 10 12 14 16 18 20

1000

2000

3000

4000

5000

0



Figure 12.4.: Impact of tree height h on private key / signature size and # of hashfunction calls for signing / verification using w = 2, K = 4, ls = 128 andlm = 256 bit

BDS parameter K6 82 4

1000

2000

3000

4000

5000

0



Figure 12.5.: Impact of parameter K on private key / signature size and # of hashfunction calls for signing / verification using w = 2, H = 10, ls = 128 andlm = 256 bit

13. Conclusion and Future Work

We presented an implementation of the Merkle signature scheme on a low-cost 8-bitmicrocontroller platform. Our implementation shows that MSS is a competitive signaturescheme compared to commonly used signature schemes such as RSA and ECDSA.

Our implementation has smaller code size and faster verification times than efficientimplementations of RSA and ECDSA on the target platform. The signature generationtimes are faster than RSA and comparable to ECDSA.

Therefore we showed that strong cryptography can be used on constrained devices. Onour way towards the efficient scheme we analyzed the properties of dedicated hash func-tions and compared them to hash functions constructed from block ciphers. We foundthat block cipher based hash functions outperform dedicated hash functions on the targetplatform and that the difference between those two becomes even larger when consideringthe specific needs of hash based signatures. Such hash functions have two advantagescompared to dedicated hash functions: (1) they have a small block size which is moresuitable for the MSS and (2) they are more efficient in size and speed. The usabilityof CMMS or GMSS (see section 8.1.4) on microcontrollers would also be an interestingtarget to investigate.

Compared to the other implementations that do not rely on a cryptographic coprocessor,our implementation is the only one that offers long-term security. Yet long-term securityis usually mandatory in all areas where cryptographic smart cards are used [BSI07].Those key lengths are not supported by previously discussed implementations.

Further performance improvements are reached by using a symmetric crypto engine suchas an AES hardware acceleration. We also proposed a short-term security version ofthe scheme using the DES for use in non-critical areas of application like many sensornetworks. The research conducted by us on this area and parts of our results can alsobe found in [RED+08].

Our implementation gives a positive answer to the question whether highly secure andefficient signature schemes can be implemented on constrained devices. It is highlyscalable and can be configured to provide an ideal tradeoff between security, executiontimes, and memory requirements for the specific use case.

We reached our goals that were stated in Section 7.2. Future work and challenges toovercome include but are certainly not limited to:

• Analysis of side channel vulnerabilities

• Creation of a proof of concept smart card

• Analysis of layered merkle trees on their suitability for constrained devices

Part III.

Appendix

A. Sworn Declaration

I declare that the work presented in this thesis is the result of my own independentresearch, except where otherwise acknowledged in the text. This material has not beensubmitted either in whole or in part for a degree at this or any other university.

Sebastian Rohde

B. Example Application Screenshots

Figure B.1.: Example application - PC - unlocked

Figure B.2.: Example application - PC - locked

78 Example Application Screenshots

Figure B.3.: Example application - PC - transaction details setup

Figure B.4.: Example application - PC - waiting for transaction confirmation

Figure B.5.: Example application - PC - notification of transaction confirmation

Example Application Screenshots 79

Figure B.6.: Example application - PC - notification of rejected transaction

Figure B.7.: Example application - token - requesting transaction legitimation

Figure B.8.: Example application - token - requesting unlock authorization

C. Parametrization Table

Table C.1.: Relationship of digest/hash size and memory (public key)/#hashs (per pkgeneration)

digest hash basic variant winternitz, w=3 winternitz, w=4 winternitz, w=5

(data) (otss) memory hashs memory hashs memory hashs memory hashsbit bit byte # byte # byte # byte #

160 128 2688 168 912 399 688 645 560 1085160 160 3360 168 1140 399 860 645 700 1085256 128 4224 264 1440 630 1072 1005 880 1705256 160 5280 264 1800 630 1340 1005 1100 1705256 256 8446 264 2880 630 2144 1005 1760 1705

D. Bibliography

[Atm07a] Atmel. Overview of secure avr microcontrollers 8-/16-bit risc cpu, 2007.http://www.atmel.com/products/SecureAVR/.

[Atm07b] Atmel. Specifications of the atmega128 microcontroller, 2007. http://www.

atmel.com/dyn/resources/prod_documents/doc2467.pdf.

[AVR08] Avr-gcc documentation. available at http://www.avrfreaks.net/wiki/

index.php/Documentation:AVR_GCC, 09 2008.

[BBJS08] Daniel V. Bailey, John Brainard, Ari Juels, and Russel Silva. Manuscript:Security in a click: Designing an output-only, wireless authentication token.2008.

[BCD+06] Johannes Buchmann, Carlos Coronado, Erik Dahmen, Martin Döring, andElena Klintsevich. CMSS - an improved merkle signature scheme. In RanaBarua and Tanja Lange, editors, INDOCRYPT, volume 4329 of LectureNotes in Computer Science, pages 349–363. Springer, 2006.

[BDK+07] Johannes Buchmann, Erik Dahmen, Elena Klintsevich, Katsuyuki Okeya,and Camille Vuillaume. Merkle signatures with virtually unlimited signaturecapacity. In Jonathan Katz and Moti Yung, editors, ACNS, volume 4521 ofLecture Notes in Computer Science, pages 31–45. Springer, 2007.

[BDS08] Johannes Buchmann, Erik Dahmen, and Michael Schneider. Merkle treetraversal revisited. Manuscript, 2008. http://www.cdc.informatik.

tu-darmstadt.de/mitarbeiter/dahmen.html.

[BF99] D. Balfanz and E. Felten. Hand-Held Computers Can Be Better SmartCards. 8th USENIX Security Symposium, 271, 1999.

[BKP03] J.E. Bardram, R.E. Kjær, and M.Ø. Pedersen. Context-Aware UserAuthentication–Supporting Proximity-Based Login in Pervasive Computing.Proceedings of Ubicomp, pages 107–123, 2003.

[BLS04] D. Boneh, B. Lynn, and H. Shacham. Short signatures from the Weil pairing.J. Cryptology, 17(4):297–319, 2004.

[BM+03] C.A. Boyd, A. Mathuria, et al. Protocols for Authentication and Key Estab-lishment. Springer, 2003.

[BSI07] Advanced Security Mechanisms for Machine Readable Travel Documents –Extended Access Control (EAC). Technical Guideline TR-03110, Bundesamtfür Sicherheit in der Informationstechnik, 2007.

http://www.atmel.com/products/SecureAVR/

http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf

http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf

http://www.avrfreaks.net/wiki/index.php/Documentation:AVR_GCC

http://www.avrfreaks.net/wiki/index.php/Documentation:AVR_GCC

http://www.cdc.informatik.tu-darmstadt.de/mitarbeiter/dahmen.html

http://www.cdc.informatik.tu-darmstadt.de/mitarbeiter/dahmen.html

84 D. Bibliography

[CLZ06] Xiuzhen Cheng, Wei Li, and Taieb Znati, editors. Wireless Algorithms, Sys-tems, and Applications, First International Conference, WASA 2006, Xi’an,China, August 15-17, 2006, Proceedings, volume 4138 of Lecture Notes inComputer Science. Springer, 2006.

[CN02] M.D. Corner and B.D. Noble. Zero-interaction authentication. Proceedingsof the 8th annual international conference on Mobile computing and net-working, pages 1–11, 2002.

[Com08] Apple Computer. About the apple remote control, 2008. Available athttp://support.apple.com/kb/HT1522.

[Cor05] Carlos Coronado. On the security and the efficiency of the merkle signa-ture scheme. Cryptology ePrint Archive, Report 2005/192, 2005. http://

eprint.iacr.org/.

[Cor06] Privaris Corp. plusid product line data sheet. 2006. Referenced 2006 athttp://www.privaris.com/pdf/Privaris_plusID_datasheet.pdf.

[DPP08] Benedikt Driessen, Axel Poschmann, and Christof Paar. Comparison ofinnovative signature algorithms for wsns. In Virgil D. Gligor, Jean-PierreHubaux, and Radha Poovendran, editors, WISEC, pages 30–35. ACM, 2008.

[DSS05] C. Dods, Nigel P. Smart, and Martĳn Stam. Hash based digital signatureschemes. In Nigel P. Smart, editor, IMA Int. Conf., volume 3796 of LectureNotes in Computer Science, pages 96–115. Springer, 2005.

[ePr03] ePractice.eu. Belgian electronic ID card officially launched, April 2003.http://www.epractice.eu/document/2139.

[FIP07] Digital signature standard (DSS). FIPS PUB 186-2, 2007. Available athttp://csrc.nist.gov/publications/fips/.

[Fle08] Flexsecure website. available through http://www.flexsecure.de, 09 2008.

[fST99] National Institute for Standards and Technology. Federal information pro-cessing standard 46-3: Data encryption standard, 1999. Available at http://

csrc.nist.gov/publications/fips/index.html.

[fST01] National Institute for Standards and Technology. Federal information pro-cessing standard 197: Advanced encryption standard, 2001. Available athttp://csrc.nist.gov/publications/fips/index.html.

[Gen03] Sam Gentile. Intro to managed c++, part 2: Mixing managed and unman-aged code. 2003. accessed at http://www.ondotnet.com/pub/a/dotnet/

2003/03/03/mcppp2.htmlin09//2008.

[GNU08] Using the gnu tools. Available through http://www.nongnu.org/avr-libc/

user-manual/using_tools.html, 01 2008.

[GPW+04] Nils Gura, Arun Patel, Arvinderpal Wander, Hans Eberle, and Sheuel-ing Chang Shantz. Comparing elliptic curve cryptography and rsa on 8-bitcpus. In Marc Joye and Jean-Jacques Quisquater, editors, CHES, volume3156 of Lecture Notes in Computer Science, pages 119–132. Springer, 2004.

http://support.apple.com/kb/HT1522

http://eprint.iacr.org/


http://www.privaris.com/pdf/Privaris_plusID_datasheet.pdf

http://www.epractice.eu/document/2139

http://csrc.nist.gov/publications/fips/

http://www.flexsecure.de

http://csrc.nist.gov/publications/fips/index.html



http://www.ondotnet.com/pub/a/dotnet/2003/03/03/mcppp2.html in 09//2008

http://www.ondotnet.com/pub/a/dotnet/2003/03/03/mcppp2.html in 09//2008

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

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

D. Bibliography 85

[Gro08] Theoretical Computer Science Research Group. Flexiprovider. http://www.

flexiprovider.de/, 01 08. Departement of Computer Science at TechnischeUniversität Darmstadt.

[GTK08] The gtk project. Website available at http://www.gtk.org/, 2008.

[GVP+03] Prasanth Ganesan, Ramnath Venugopalan, Pushkin Peddabachagari,Alexander Dean, Frank Mueller, and Mihail Sichitiu. Analyzing and model-ing encryption overhead for sensor network nodes. In WSNA ’03: Proceedingsof the 2nd ACM international conference on Wireless sensor networks andapplications, pages 151–159, New York, NY, USA, 2003. ACM.

[Hir06] Shoichi Hirose. Some plausible constructions of double-block-length hashfunctions. In Matthew J. B. Robshaw, editor, FSE, volume 4047 of LectureNotes in Computer Science, pages 210–225. Springer, 2006.

[HKW06] Alain P. Hiltgen, Thorsten Kramp, and Thomas Weigold. Secure internetbanking authentication. IEEE Security & Privacy, 4(2):21–29, 2006.

[IEE98] IEEE. IEEE 802.2-1998 part 2: Logical link control. available throughhttp://standards.ieee.org/getieee802/802.3.html, 1998.

[IEE05] IEEE. IEEE 802.3-2005. IEEE lan/man csma/cd access method. availablethrough http://standards.ieee.org/getieee802/802.3.html, 2005.

[IEE07] IEEE. IEEE 802.11-2007. IEEE standard for information technology–telecommunications and information exchange between system–local andmetropolitan area networks specific requirements–part 11: Wireless LANmedium access control (MAC) and physical layer (PHY) specifica-tions. available through http://standards.ieee.org/getieee802/802.

11.html, 2007.

[IET81] IETF. Internet Protocol. RFC 791, accessible through http://www.ietf.

org/rfc/rfc0791.txt, 09 1981.

[IET89] IETF. Requirements for internet hosts - communication layers. RFC 1122,accessible through http://www.ietf.org/rfc/rfc1122.txt, 10 1989.

[IET98] IETF. Internet Protocol, Version 6 (IPv6). RFC 2460, accessible throughhttp://www.ietf.org/rfc/rfc2460.txt, 12 1998.

[IET05] IETF. Security Architecture for the Internet Protocol. RFC 4301 , accessiblethrough http://www.ietf.org/rfc/rfc4301.txt, 12 2005.

[ISO93] CD ISO. 9798-2. Information Technology: Security Techniques Entity Au-thentication Mechanisms. Part 2: Entity Authentication Using SymmetricTechniques., July 1993.

[ISO98] CD ISO. 9798-3. Information Technology: Security Techniques Entity Au-thentication Mechanisms. Part 3: Mechanisms using Digital Signature Tech-niques., 1998.

[ISO00] CD ISO. 10118-2. Information technology – Security techniques – Hash-functions – Part 2: Hash-functions using an n-bit block cipher, 12 2000.

http://www.flexiprovider.de/

http://www.flexiprovider.de/

http://www.gtk.org/

http://standards.ieee.org/getieee802/802.3.html




http://www.ietf.org/rfc/rfc0791.txt





86 D. Bibliography

[Ker04] Michael Kershaw. Kismet, 2004. Referenced 2008 at http://www.

kismetwireless.net/presentations/5hope-kismet.pdf.

[Lab08] Das Labor. Crypto-avr-lib. Available through http://www.das-labor.org/

wiki/Crypto-avr-lib, 01 2008.

[Lam79] L. Lamport. Constructing digital signatures from a one-way function. Tech-nical Report CSL-98, SRI International, October 1979.

[Lau07] Cédric Lauradoux. Throughput/code size tradeoff for stream ciphers. TheState of the Art of Stream Ciphers - SASC, 2007.

[Len04] Arjen K. Lenstra. Key lengths. Contribution to The Handbook of Infor-mation Security, 2004. http://cm.bell-labs.com/who/akl/key_lengths.

pdf.

[Lib08a] The libnet packet construction library, 2008. available at http://www.

packetfactory.net/libnet/.

[Lib08b] Libtomcrypt. available at http://libtomcrypt.com/, 2008.

[LN07] A. Liu and P. Ning. TinyECC: A Configurable Library for Elliptic CurveCryptography in Wireless Sensor Networks. Technical Report TR-2007-36,North Carolina State University, Department of Computer Science, Novem-ber 2007.

[Lor08] Lorcon (loss of radio connectivity), 2008. available at http://802.11ninja.

net/lorcon.

[LPW06] M. Luk, A. Perrig, and B. Whillock. Seven cardinal properties of sensornetwork broadcast authentication. Proceedings of the fourth ACM workshopon Security of ad hoc and sensor networks, pages 147–156, 2006.

[Mad08] Madwifi wlan driver, 2008. available at http://madwifi.org/.

[MAE08] maemo.org: open source development for internet tablets. available athttp://maemo.org/, 09 2008.

[MAMT05] Kenta Matsumiya, Soko Aoki, Masana Murase, and Hideyuki Tokuda. Azero-stop authentication system for sensor-based embedded real-time appli-cations. J. Embedded Comput., 1(1):119–132, 2005.

[MBH+05] D. M’Raihi, M. Bellare, F. Hoornaert, D. Naccache, and O. Ranen. Hotp:An hmac-based one-time password algorithm, 12 2005. http://www.ietf.

org/rfc/rfc4226.txt.

[Mer89] Ralph C. Merkle. A certified digital signature. In Gilles Brassard, editor,CRYPTO, volume 435 of Lecture Notes in Computer Science, pages 218–238.Springer, 1989.

[Mer08] Rick Merritt. Wi-fi jumps into the pan. EETimes, June 6,2008. Available at http://www.eetimes.com/news/latest/showArticle.

jhtml?articleID=208401238.

http://www.kismetwireless.net/presentations/5hope-kismet.pdf

http://www.kismetwireless.net/presentations/5hope-kismet.pdf

http://www.das-labor.org/wiki/Crypto-avr-lib

http://www.das-labor.org/wiki/Crypto-avr-lib

http://cm.bell-labs.com/who/akl/key_lengths.pdf

http://cm.bell-labs.com/who/akl/key_lengths.pdf

http://www.packetfactory.net/libnet/

http://www.packetfactory.net/libnet/

http://libtomcrypt.com/

http://802.11ninja.net/lorcon

http://802.11ninja.net/lorcon

http://madwifi.org/

http://maemo.org/



http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=208401238

http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=208401238

D. Bibliography 87

[MPR05] Jonathan M. McCune, Adrian Perrig, and Michael K. Reiter. Seeing-is-believing: Using camera phones for human-verifiable authentication. InIEEE Symposium on Security and Privacy, pages 110–124, 2005.

[MPR06] J. M. McCune, A. Perrig, and M. K. Reiter. Bump in the ether: A frameworkfor securing sensitive user input. In Proceedings of the 2006 USENIX AnnualTechnical Conference, page 185Ű198, June 2006.

[MRN+08] D. M’Raihi, J. Rydell, D. Naccache, Salah Machani, and Sid-dharth Bajaj. Ocra: Oath challenge-response algorithms, 2008.Draft available at http://www.ietf.org/internet-drafts/

draft-mraihi-mutual-oath-hotp-variants-07.txt.

[MVV96] A. J. Menezes, S. A. Vanstone, and P. C. Van Oorschot. Handbook of AppliedCryptography. CRC Press, 1996.

[Mye01] B.A. Myers. Using handhelds and PCs together. Communications of theACM, 44(11):34–41, 2001.

[NM02] Junko Nakajima and Mitsuru Matsui. Performance analysis and parallelimplementation of dedicated hash functions. In Lars R. Knudsen, editor,EUROCRYPT, volume 2332 of Lecture Notes in Computer Science, pages165–180. Springer, 2002.

[NSW05] Dalit Naor, Amir Shenhav, and Avishai Wool. One-time signatures revisited:Have they become practical. Cryptology ePrint Archive, Report 2005/442,2005. http://eprint.iacr.org/.

[QEM08] Qemu - open source processor emulator. available at http://bellard.org/

qemu/, 2008.

[RED+08] Sebastian Rohde, Thomas Eisenbarth, Erik Dahmen, Johannes Buchmann,and Christof Paar. Fast hash-based signatures on constrained devices. InGilles Grimaud and François-Xavier Standaert, editors, CARDIS, volume5189 of Lecture Notes in Computer Science, pages 104–117. Springer, 2008.

[Rĳ08] Rĳndaelfurious implementation. Available through http://

point-at-infinity.org/avraes/, 01 2008.

[RT708] The rt73 driver homepage, 2008. available at http://rt2x00.

serialmonkey.com/.

[Sec08] RSA Security. RSA SecurID authentication: Product family: Hardwareauthenticators, 2008. Referenced 2008 at http://www.rsasecurity.com/

node.asp?id=1158.

[Sha08] Market Share. Operating system market share. available through http://

marketshare.hitslink.com/report.aspx?qprid=8, 09 2008.

[Ste07] John P. Steinberger. The collision intractability of mdc-2 in the ideal-ciphermodel. In Moni Naor, editor, EUROCRYPT, volume 4515 of Lecture Notesin Computer Science, pages 34–51. Springer, 2007.

http://www.ietf.org/internet-drafts/draft-mraihi-mutual-oath-hotp-variants-07.txt

http://www.ietf.org/internet-drafts/draft-mraihi-mutual-oath-hotp-variants-07.txt


http://bellard.org/qemu/

http://bellard.org/qemu/

http://point-at-infinity.org/avraes/

http://point-at-infinity.org/avraes/

http://rt2x00.serialmonkey.com/

http://rt2x00.serialmonkey.com/

http://www.rsasecurity.com/node.asp?id=1158

http://www.rsasecurity.com/node.asp?id=1158

http://marketshare.hitslink.com/report.aspx?qprid=8

http://marketshare.hitslink.com/report.aspx?qprid=8

88 D. Bibliography

[SWF+05] Ellen Siever, Aaron Weber, Stephen Figgins, Robert Love, and Arnold Rob-bins. Linux in a Nutshell. O’Reilly Media, 5th edition, 2005.

[Szy04] Michael Szydlo. Merkle tree traversal in log space and time. In ChristianCachin and Jan Camenisch, editors, EUROCRYPT, volume 3027 of LectureNotes in Computer Science, pages 541–554. Springer, 2004.

[Tec06] Ensure Technologies. How XyLoc Works. 2006. Referenced 2006 at http://

www.ensuretech.com/products/technology/technology.html.

[Vie04] J. Viega. The AHASH Mode of Operation. 2004. Manuscript available fromhttp://www.cryptobarn.com/.

[Vis08] Visual studio website. available at http://msdn.microsoft.com/en-us/

vstudio/default.aspx, 09 2008.

[WiF08] Wifi alliance - homepage. accessible through http://wi-fi.org/, 09 2008.

[Win08] Winpcap: The windows packet capture library. available at http://www.

winpcap.org/, 2008.

[YlJfQq07] S. Yu-long, MA Jian-feng, and PEI Qing-qi. An Access Control Schemein Wireless Sensor Networks. Network and Parallel Computing Workshops,2007. NPC Workshops. IFIP International Conference on, pages 362–367,2007.

[Zim88] H. Zimmermann. Osi reference model—the iso model of architecture foropen systems interconnection. pages 2–9, 1988.

http://www.ensuretech.com/products/technology/technology.html

http://www.ensuretech.com/products/technology/technology.html

http://www.cryptobarn.com/

http://msdn.microsoft.com/en-us/vstudio/default.aspx

http://msdn.microsoft.com/en-us/vstudio/default.aspx

http://wi-fi.org/

http://www.winpcap.org/

http://www.winpcap.org/

Protocols and Light-Weight Algorithms for Wireless Authentication through Side Channels in IEEE

Documents

Transcript of Protocols and Light-Weight Algorithms for Wireless Authentication through Side Channels in IEEE