.

D3.1: Hybrid FPGA ASIC prototype.

Project number: 835932Project acronym: CODESProject title: Algorithmic extraction and error correction

codes for lightweight security anchors with re-configurable PUFs

Start date of the project: 01.10.2012Duration: 24 months

.

Deliverable type: Prototype (Accompanying Report)Deliverable reference number: 835932/ D3.1Deliverable title: Hybrid FPGA ASIC prototypeWP contributing to deliverable: WP03Due date: 31.07.2014Actual submission date: 30.07.2014

.

Responsible organisation: TECAuthors: Martin Deutschmann, Michael Hoberl,

Christina Petschnigg, Ingrid Schaumuller-Bichl, Andrea Kolberger, Michela Mazzoli,Clemens Heuberger

Abstract: This document is the accompanying report tothe hybrid FPGA ASIC prototype. The reportdescribes shortly the demonstrator goals, as wellas the setup, design and the implementation.

Keywords: Physically Unclonable Functions, Prototype,Scenarios, Architecture, GUI

.

Dissemination level: PURevision: 1.0

.

.

Contents

1 Introduction 51.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Definition of Terms 6

3 System Design 73.1 Demonstrator I: Mutual Authentication . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.2 Components Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.3 Interfaces of the Components . . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.4 Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.5 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Demonstrator II: Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.2 Components Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.3 Interfaces of the Components . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.4 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Stand-Alone Application (LR-PUF, HW/SW Binding) . . . . . . . . . . . . . . . . 183.3.1 Fault Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.2 Replay Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Implementation and Integration 204.1 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.1 Design of the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.2 Implementation of the Relevant Building Blocks . . . . . . . . . . . . . . . 214.1.3 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 FPGA Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.1 General Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.2 Implementation of an ECC in Hardware . . . . . . . . . . . . . . . . . . . . 24

4.3 Communication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Usage of the Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Conclusion 28

References 29

A Stand-alone Application: Scenario 30

List of Abbreviations

ASIC Application Specific Integrated Circuit

CC Common Criteria

CRP Challenge Response Pair

ECC Error Correction Code

FPGA Field Programmable Gate Array

GUI Graphical User Interface

HD Helper Data

IC Integrated Circuit

LR-PUF Logically Reconfigurable PUF

MFC Microsoft Foundation Classes

PUF Physically Unclonable Function

SFR Security Functional Requirements

SRAM Static Random Access Memory

TOE Target of Evaluation

UART Universal Asynchronous Receiver Transmitter

VHDL Very High Speed Integrated Circuit Hardware Description Language

3/33

List of Figures

1 Architecture of Demonstrator I: Mutual Authentication . . . . . . . . . . . . . . . 72 Interfaces of the Component “GUI/Verifier” . . . . . . . . . . . . . . . . . . . . . . 93 Interfaces of the Component “FPGA board” . . . . . . . . . . . . . . . . . . . . . . 94 Interface of the Component “ASIC board” . . . . . . . . . . . . . . . . . . . . . . . 95 Interface of the Component “Database” . . . . . . . . . . . . . . . . . . . . . . . . 106 Flowchart of Demonstrator I: Mutual Authentication - Enrolment . . . . . . . . . . 107 Flowchart of Demonstrator I: Mutual Authentication - Reconstruction . . . . . . . 118 Sequence Diagram of Demonstrator I: Mutual Authentication - Enrolment . . . . . 129 Sequence Diagram of Demonstrator I: Mutual Authentication - Reconstruction . . 1310 Architecture of Demonstrator II: Key Generation . . . . . . . . . . . . . . . . . . . 1411 Interfaces of the Component “GUI/Verifier” . . . . . . . . . . . . . . . . . . . . . . 1512 Interfaces of the Component “FPGA board” . . . . . . . . . . . . . . . . . . . . . . 1613 Interface of the Component “ASIC board” . . . . . . . . . . . . . . . . . . . . . . . 1614 Sequence Diagram of Demonstrator II: Key Generation - Enrolment and Key Re-

construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715 Design Concept of the First GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2016 Final GUI for both Demonstrators . . . . . . . . . . . . . . . . . . . . . . . . . . . 2117 Soft-Core Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2318 Xilinx KC705 and UNIQUE ASIC Board . . . . . . . . . . . . . . . . . . . . . . . 2419 RS Encoder Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2520 Reed Muller Encoder in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2521 Ready-to-use Demonstrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2822 Architecture of LR-PUF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3023 HW/SW Binding - Enrolment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3124 HW/SW Binding - Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3225 HW/SW Binding - Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4/33

1 Introduction

1.1 Purpose

In Work Package 3 novel crypto primitives such as error-correcting codes and anti-ageing mech-anisms have been integrated into a hybrid FPGA-ASIC prototype. All functions worked out inWork Package 2 have been implemented either in hardware (VHDL) or software (C/C++) and puttogether to demonstrate a set of pre-defined real-world use cases. The aim of this deliverable is todescribe the design and the implementation of the FPGA-ASIC prototype including all relevantbuilding blocks, interfaces as well as the Graphical User Interface (GUI).

1.2 Scope

The scope of this document is limited to the design and implementation process of the prototypeitself. Thus, the setup, architecture, components and implementation details of the prototype arediscussed here.The chosen use cases and a detailed description of them can be found in deliverable D1.1 - SWOTAnalysis of existing PUF security modules [4]. For a detailed description of the implemented error-correcting codes we refer to deliverable D2.1 - Report on suitable post processing methods [5].Since the upcoming deliverable D1.2 - Final Report on prototype testing covers the overall systemtests, this deliverable focuses purely on the architectural description of the demonstrators setup.

1.3 Outline

This document is structured as follows:Section 2 defines the terms used in this report. Since these terms are frequently used in the report,it is essential to know their exact meaning. Section 3 is split into three parts, one for each demo.The sub-sections always start with a description of the high-level system architecture, going on tothe description of the components and the interfaces between the components. Furthermore, thedeveloped protocols are illustrated with a flowchart and a sequence diagram.Finally, Section 4 covers the implementation of the prototype in detail. At the beginning theGUI is presented and some relevant implementation steps are described. Further, the hardwareimplementation on the FPGA board is discussed. At the end the communication protocol betweenthe PC and the FPGA board is described and the general usage of the prototype is explained.The deliverable comes to its end with the conclusion in Section 5.

5/33

2 Definition of Terms

Term Synonym DescriptionASIC board The ASIC board comprises six different PUF types

that can be activated through the FPGA board. Inour demonstrators we are going to use an Arbiter anda SRAM PUF.

Building Block Module The demonstrator consists of several building blocks,each of them providing a specific functionality. Theinteraction of the building blocks realizes a certain usecase implementation. Examples of building blocks arethe PUF, key generation, en-/decryption, Fuzzy Ex-tractor, etc.

Challenge-Response-Pair(CRP)

A CRP is the mapping between the unique value of theresponse to a certain challenge, whereas the generatedresponse depends on the inherent physical propertiesof a PUF instantiation.

Component Our prototype comprises four main components: (i)database, (ii) GUI/verifier (on the PC side), (iii)FPGA board, and (iv) ASIC board. Each single com-ponent again comprises several building blocks provid-ing different functionalities.

Database The database stores challenge-response pairs (CRPs),helper data (HD) and other information needed for theintended demonstrator. The database is located on thePC side.

Demonstrator Use Case,TOE

A demonstrator represents a certain use case: Demon-strator I “Mutual Authentication” and DemonstratorII “Key Generation”. The demonstrators are the ob-jects of investigation, i.e. the Target of Evaluation(TOE).

FPGA board On the FPGA board cryptographic operations andother functionalities are carried out in HW and SW.

GUI Verifier The GUI is located on the PC side and enables theselection and execution of both demonstrators, MutualAuthentication or Key Generation.

Prototype The prototype consists of an FPGA board, an ASICboard (comprising the PUFs) and a PC. The FPGAboard together with the ASIC board can be regarded asa single Integrated Circuit (IC) in a real-world product.The PC comprises the Graphical User Interface (GUI)and a database (storing CRPs, Helper Data, etc.) andacts as the terminal/verifier in our laboratory setting.

6/33

3 System Design

This section illustrates and describes the design and the system architecture of both “DemonstratorI: Mutual Authentication” and “Demonstrator II: Key Generation”.

3.1 Demonstrator I: Mutual Authentication

Demonstrator I provides the capability for mutual authentication, i.e. the GUI/verifier is authen-ticated by the FPGA board and vice versa. Therefore the PUF is enrolled in the early phase,which means that several PUF-related challenges and responses are collected and stored. Thesepairs (CRPs) are then used when the authentication protocol is executed.In Section 3.1.1 the components of the demonstrator, with their respective functionalities, arepresented; Section 3.1.2 narratively describes them. The interaction and data to be exchangedbetween the demonstrator components are explained in Section 3.1.3. Furthermore, the enrolmentand reconstruction procedures of mutual authentication are displayed by flowcharts in Section 3.1.4and sequence diagrams in Section 3.1.5.

3.1.1 System Architecture

Figure 1 shows the system architecture of “Demonstrator I: Mutual Authentication” as well asthe functionalities provided by each component. The demonstrator is made up of the componentsGUI/verifier, database, FPGA board and ASIC board. Each of them fulfils certain tasks byproviding the so-called building blocks (e.g. Authentication, Error Correction and Reconstructionof PUF response, . . . ). The building blocks are labelled by a unique name (e.g. FIA_UAU.2) whichcorrespond to the terminology of Common Criteria (CC) [1] and represent a security functionalrequirement (SFR) either selected from CC Part 2 [2] or defined as an extended component in theProtection Profile for PUF-based Devices [3].

GUI / Verifier(on PC side)

Database(stores CRPs)

FPGA Board ASIC BoardChallenge

Represents Use Case Mutual Authentication

Authentication (accept/reject)

[FIA_UAU.2]

Supplies PUF response

[FPT_PUF.1]

Generation of helper data: Fuzzy Extractor

[FCS_CPP.2]

Replay detection

[FPT_RPL.1]

Cryptographic operation (Hash)

[FCS_COP.1]

Anti Ageing[FRU_AIA.1]

Error Correction and reconstruction of PUF response [FCS_CPP.1]

Response

Authentication (accept/reject)

[FIA_UAU.2]

Figure 1: Architecture of Demonstrator I: Mutual Authentication

3.1.2 Components Description

The demonstrator pictured in Figure 1 comprises the following components:

• Graphical User Interface (GUI)/verifier, located on the PC side

• FPGA Board, connected to the PC and the ASIC board

7/33

• ASIC Board, connected to the FPGA board and providing PUFs

• Database, storing CRPs and located on the PC side

GUI/Verifier. This component is situated on the PC side and represents the use case “MutualAuthentication”. The authentication procedure is triggered by the GUI, i.e. it requests a PUFresponse from the FPGA board and is able to verify the data received from the FPGA board.In order to perform this task, the GUI provides cryptographic operations (FCS_CPP.1) and anauthentication mechanism (FIA_UAU.2). The GUI is directly connected to the FPGA board andindirectly to the ASIC board.

FPGA Board. The FPGA board represents the interface between the GUI on the PC sideand the ASIC board accommodating the PUF instantiations. The FPGA board directly interactsand exchanges data with the GUI, i.e. it receives and processes requests. The FPGA board isequipped with an authentication mechanism (FIA_UAU.2) to verify data received from the GUI.Therefore it provides the capability to challenge the ASIC board and perform cryptographic op-erations (FCS_COP.1) on the received PUF response in order to extract helper data (FCS_CPP.2).Cryptographic operations are also needed for computation of hash values. Furthermore, the FPGAboard implements a mechanism for replay detection (FPT_RPL.1). The implemented anti ageingprotocol guarantees the reliable execution of the protocol despite aged PUF data (FRU_AIA.1).

ASIC Board. This demonstrator employs the Arbiter PUF. The purpose of the ASIC board isto receive a challenge from the FPGA board, activate the Arbiter PUF and return the individualPUF response to the FPGA board (FPT_PUF.1).

Database. The database on the PC side stores challenge-response-pairs (CRPs) generated bythe Arbiter PUF instantiation that are required by this application. First the PUF has to beenrolled and generated CRPs are stored in the database. During the authentication protocol, theGUI accesses the database to select a certain CRP in order to request the PUF or to reconstructa PUF response.

3.1.3 Interfaces of the Components

Demonstrator I consists of the aforementioned components comprising several building blocksthat provide different functionalities. This section describes the interfaces of the demonstratorcomponents and which data are exchanged.

GUI/Verifier. The GUI provides two main interfaces: on the one hand it interacts with thedatabase located on the PC; on the other hand it communicates with the physically connectedFPGA board (see also Figure 2).

→ Database: The GUI can request and receive data, namely PUF challenges and PUF re-sponses, from the database. These data are part of hash computations, reconstructionissues, and they are needed for authentication procedures.

→ FPGA board: The GUI interacts with the FPGA board and requests (resp. receives) hashedvalues and other data (e.g. challenges, IDs).

8/33

GUI / Verifier(on PC side)

Database(stores CRPs)

requests challenge, response

sendsrequested

dataFPGA Board

requests and sends data(hashed value, challenge, ID)

sends data(hashed value, ID, HD)

Figure 2: Interfaces of the Component “GUI/Verifier”

FPGA board. As shown in Figure 3 the FPGA board communicates with the GUI/verifier andwith the ASIC board.

→ GUI/verifier: The FPGA board receives data from the GUI and responds to these requests.Data transmitted to the GUI include hash values as well as generated helper data (HD). Inorder to compute HD, an interface to the ASIC board is required.

→ ASIC board: The FPGA board requests a PUF response (R) from the ASIC board byproviding a selected challenge (C).

GUI / Verifier(on PC side)

FPGA Board ASIC Board

requests a PUF response(by providing a challenge)

requests and sends data(hashed value, challenge, ID)

sends data(hashed value, ID, HD)

sends PUF response(according to challenge)

Figure 3: Interfaces of the Component “FPGA board”

ASIC board. The ASIC board is only connected to and provides functionality for the FPGAboard (see also Figure 4). This component receives a challenge for the Arbiter PUF and returnsthe according response to the FPGA board.

ASIC Board

requests a PUF response(by providing a challenge)

sends PUF response(according to challenge)

FPGA Board

Figure 4: Interface of the Component “ASIC board”

Database. The database containing CRPs is located on the PC side and provides data forthe GUI/verifier. It receives requests from the GUI and returns the according CRPs (see alsoFigure 5).

9/33

GUI / Verifier(on PC side)

Database(stores CRPs)

requests challenge, response

sendsrequested

data

Figure 5: Interface of the Component “Database”

3.1.4 Flowchart

Use case Mutual Authentication can basically be split into two main parts. First of all, thePUF has to be enrolled, i.e. a certain amount of CRPs are generated and stored in the database.Secondly, during authentication procedures the enrolled CRPs are used in order to execute theauthentication protocol. The process of these activities is illustrated by the following flowchartsin Figures 6 and 7.

STARTDemonstrator: Mutual Authentication

Enrolment

TOE sends ID to GUI

GUI selects Challengeand sends it to TOE

TOE generates Response

TOE returns Response to GUI

GUI stores ID and CRP

Generation of another CRP?

END / TOE is enrolled

No

Database(stores CRPs)

ASIC board:Arbiter PUF

Yes

Figure 6: Flowchart of Demonstrator I: Mutual Authentication - Enrolment

10/33

STARTDemonstrator: Mutual Authentication

Reconstruction

TOE sends ID to verifier

Verifier:Does this ID

exist?

END / Reject

No

Verifier selects according Challengeand sends it to TOE (+ del Challenge)

Yes

TOE generates Response

TOE calculates HD

TOE calculates a hashed value (a), sends hash and HD to verifer

Verifier reconstructs Response with HD and calculates hashed value (a‘)

a = a‘ ?No

Verifier calculates a hashed value (b) and sends it to TOE

TOE is authenticated

yes

TOE calculates the hashed value (b‘)

b = b‘ ?

No

END / mutually authenticated

Yes

Database(stores CRPs)

ASIC board:Arbiter PUF

Replay detection?

No

Yes

Figure 7: Flowchart of Demonstrator I: Mutual Authentication - Reconstruction

11/33

3.1.5 Sequence Diagram

Figures 8 and 9 show the consecutive procedures of demonstrator I. The first diagram showsthe single steps that have to be conducted during enrolment, i.e. the collection and storage ofPUF-specific challenge-response pairs (CRPs). The second diagram displays each computationstep and interaction between the components in order to mutually authenticate both componentsGUI/verifier and FPGA board.

Database [ID,C,R’] GUI / Verifier FPGA Board ASIC Board

request(ID)

send(ID)

select(C)

request(R’);send(C)

request(R’)

generate(R’)

send(R’)

send(R’)

send(ID,C,R’)

store(ID,C,R’)

done

EnrolmentEnrolment

Figure 8: Sequence Diagram of Demonstrator I: Mutual Authentication - Enrolment

12/33

Database [ID,C,R’] GUI / Verifier FPGA Board ASIC Board

request(ID)

send(ID)

send(ID);request(C,R’)

select(C,R’)

delete(CRP)

send(C,R’)

request(a,HD);send(C)

replayDetect()

request(R)

generate(R)

send(R)

generate(HD)

antiAgeing()

a ← Hash(ID,R,HD)

send(a,HD)

R ← reconstruct(R’,HD)

a’ ← Hash(ID,R,HD)

auth(a’=a)

b ← Hash(a’,R)

send(b)

b’ ← Hash(R,a)

auth(b’=b)

Figure 9: Sequence Diagram of Demonstrator I: Mutual Authentication - Reconstruction

13/33

3.2 Demonstrator II: Key Generation

Demonstrator II: Key Generation provides the capability to generate and reconstruct a PUF-dependent secret/key. Once the SRAM PUF is enrolled, the FPGA board is capable to reconstructthe secret. During the enrolment phase, the secret key and the according helper data (HD) arecomputed. Merely the HD and a textphrase (e.g. “Reconstruction works!”) are stored in theFPGA’s non-volatile memory. The textphrase is encrypted with the secret key generated duringenrolment. In the reconstruction phase the key is reproduced and used to decrypt the encryptedand stored textphrase, which is returned as an output to the LED display.Important to mention for this use case is, that the secret key is solely available on the FPGA boardand never leaves this device. So the key is not stored in memory or on an external entity at all.Furthermore, the encrypted string is bound to the physical device as only this device comprisingthe according PUF is capable to reconstruct the decryption key (HW/SW binding).In Section 3.2.1 the components of the demonstrator, with their respective functionalities, arepresented; Section 3.2.2 narratively describes them. The interaction between the demonstratorcomponents is illustrated in Section 3.2.3. Furthermore, the overall protocol is displayed in thesequence diagram in Section 3.2.4.

3.2.1 System Architecture

Figure 10 shows the system architecture of “Demonstrator II: Key Generation” as well as thefunctionalities provided by each component. The demonstrator is made up of the componentsGUI/verifier, FPGA board and ASIC board. Each of them fulfils certain tasks by providing the so-called building blocks (e.g. Cryptographic operation, Generation of helper data, . . . ). The buildingblocks are labelled by a unique name (e.g. FCS_COP.1) which correspond to the terminology ofCommon Criteria (CC) [1] and represent a security functional requirement (SFR) either selectedfrom CC Part 2 [2] or defined as an extended component in the Protection Profile for PUF-basedDevices [3].

GUI / Verifier(on PC side)

FPGA BoardASIC

Board

Challenge

Represents Use CaseKey Generation

Supplies PUF response

[FPT_PUF.1]

Cryptographic operation (Hash)

[FCS_COP.1]

Anti Ageing[FRU_AIA.1]

Response

Error Correction and reconstruction of PUF response [FCS_CPP.1]

Cryptographic key generation[FCS_CKM.1]

Generation of helper data: Fuzzy Extractor

[FCS_CPP.2]

Figure 10: Architecture of Demonstrator II: Key Generation

3.2.2 Components Description

The demonstrator depicted in Figure 10 comprises the following components – similar to “Demon-strator I: Mutual Authentication” – but provide different functionalities:

• Graphical User Interface (GUI)/verifier, located on the PC side

• FPGA Board, connected to the PC and the ASIC board

14/33

• ASIC Board, connected to the FPGA board and providing PUFs

GUI/Verifier. This component is situated on the PC side and represents the use case “KeyGeneration”. The GUI triggers the enrolment and the key reconstruction, but it does not storeany sensitive information.

FPGA Board. The FPGA board stores the HD generated during enrolment and the textphraseencrypted with the secret key that has been derived in the enrolment phase too. In order to becapable to derive or reconstruct the key, the FPGA board requests a PUF response from theSRAM PUF located on the ASIC board and applies the implemented cryptographic operations(FCS_CpP.1, FCS_CPP.2 and FCS_CKM.1). Additionally, the FPGA board provides mechanisms tocounteract ageing effects (FRU_AIA.1).Note: In order to detect security violations (e.g. the number of errors in a response exceedsa predefined value) a security alarm might be integrated (FAU_ARP.1). This mechanism is notimplemented in the prototype.

ASIC Board. This demonstrator employs a SRAM PUF. The purpose of the ASIC board isto receive a challenge (i.e. memory address) from the FPGA board, activate the SRAM PUF andreturn the individual PUF response to the FPGA board (FPT_PUF.1).

3.2.3 Interfaces of the Components

Demonstrator II consists of the aforementioned components comprising several building blocksthat provide different functionalities. This section describes the interfaces of the demonstratorcomponents and which data are exchanged.

GUI/Verifier. The GUI communicates with the physically connected FPGA board (see alsoFigure 11) and requests, respectively receives the decrypted string.

GUI / Verifier(on PC side)

FPGA Board

requests and sends data(string)

sends data

Figure 11: Interfaces of the Component “GUI/Verifier”

FPGA board. As shown in Figure 12, the component FPGA board communicates with theGUI/verifier and with the ASIC board.

→ GUI/verifier: The FPGA board receives data from the GUI during enrolment and respondsto these requests. Furthermore the GUI triggers the key reconstruction process by requestingthe (decrypted) string stored on the FPGA.

→ ASIC board: The FPGA board requests PUF responses (R) from the ASIC board by pro-viding a challenge (C).

15/33

GUI / Verifier(on PC side)

FPGA Board ASIC Board

requests a PUF response(by providing a challenge)

requests and sends data(string to be stored on FPGA)

sends data sends PUF response(according to challenge)

Figure 12: Interfaces of the Component “FPGA board”

ASIC board. The ASIC board is only connected to and provides functionality for the FPGAboard (see also Figure 13). This component receives a challenge for the SRAM PUF and returnsthe according response to the FPGA board.

ASIC Board

requests a PUF response(by providing a challenge)

sends PUF response(according to challenge)

FPGA Board

Figure 13: Interface of the Component “ASIC board”

16/33

3.2.4 Sequence Diagram

Figure 14 shows the consecutive procedures of demonstrator II. The first loop describes the en-rolment phase, where HD are extracted and the PUF-specific key is derived. The second loopcontains procedures that are carried out when the key is reconstructed.

GUI / Verifier FPGA Board ASIC Board

enroll();send(String)

gen(Wr)

codeWord = Encode(Wr)

request(R);send(C)

generate(R)

send(R)

HD = codeWord⊕R

store(HD)

K = hash(R)

store(EncryptK(String))

Enrolment OK

EnrolmentEnrolment

request(String)

send(C);request(R’)

generate(R’)

send(R’)

codeWord’ = R′ ⊕HD

codeWord = Decode(codeWord’)

R = HD ⊕ codeWord

K = hash(R)

displayLCD = DecryptK(String)

ReconstructionReconstruction

Figure 14: Sequence Diagram of Demonstrator II: Key Generation - Enrolment and Key Recon-struction

17/33

3.3 Stand-Alone Application (LR-PUF, HW/SW Binding)

In addition to the above described prototypes, a third stand-alone application was implemented,which includes a LR-PUF to apply binding of SW to dedicated HW. This stand-alone applicationdoes not include a Graphical User Interface, however a concept and a possible scenario on howto use these building blocks was defined. The details of this scenario are available within theappendix of this report (Appendix A).During the implementation of the error-correcting codes required for this stand-alone application,a possible way for detecting faults was evaluated and is described in the next paragraphs. Fur-thermore, a new approach to detect replay attacks based on the mapping of IDs to challenges isdiscussed in more detail. Research in this direction will proceed in the last months of the projectand we expect to be able to include some results in deliverable D1.2 - Final Report on prototypetesting, which is due in M24 (end of September 2014).

3.3.1 Fault Detection

Fault attacks on post processing methods of PUFs pose an increasing security risk as unnoticedattacks could lead to the exposure of the secret key. During one of these attacks, transient or per-sistent malfunctions are introduced in the fuzzy extractor. The computation results are exploitedto get the key. Developing and implementing countermeasures against fault attacks is a toughchallenge and not much has been published yet in this direction. Therefore we will follow anotherapproach, which allows us to detect that a fault has been implemented, by always calculating thenumber of errors to be corrected during the reconstruction step. If the number of errors is signif-icantly higher than the expected normal PUF behaviour, then it could mean that a fault attackis going on. When a fault has been detected, it is possible to take immediate countermeasures,such as putting the device into sleep mode, to avoid loss of sensitive data. The question of howto react and how to re-use the device after a potential attack needs to be defined in a dedicatedsecurity policy, which heavily depends on the application environment.Currently several measures to detect the induction of faults are being investigated for differentfuzzy extractor designs. The main overview is briefly described in the following paragraphs.

Syndrome ConstructionIn case of systems using a syndrome construction, fault detection can be easily implemented asthe number of errors that occurred is directly determined during the reconstruction process. Inthis process the syndrome of the error vector is computed and so is the error vector itself. A majoradvantage of the syndrome construction is that this error vector of a received response alreadycontains all the important information on the number of errors and their location in the bit string.When working with a binary code, the number of errors corresponds to the number of non-zerocomponents of the error vector and the location of the errors corresponds to the position of thenon-zero components of the error vector. When using a non-binary code, the number of errorscorresponds to the weight of the error vector and the location again corresponds to the positionof the non-zero components of the error vector. If the number of occurred errors is significantlyhigher than the number of expected errors, fault injection could be suspected. In this case thedevice detects a fault attack and raises an alarm.

Code Offset ConstructionIn case of a code offset construction the calculation of the exact number of errors works in adifferent way, as there is no explicit error vector used hence other methods have to be worked outto detect fault attacks. Currently two different approaches are pursued to detect fault induction.The first way is to detect errors by re-encoding the message w. In more detail this means thatduring enrolment the codeword c = Enc(w) and the PUF response R are combined with an XOR-operation giving the helper data. In the reconstruction phase the erroneous PUF response R′ andthe helper data are again linked with an XOR-operation giving c′. It is assumed that the ECCis powerful enough to correct all the errors in c′ so that the original message w can be retrieved,

18/33

otherwise the key could not be generated. This message can then be re-encoded giving c. Finally,the error vector is computed by combining c and c′ with an XOR-operation.The second approach is to implement a counter in the loops of the decoding algorithm of a givenECC. In several codes the value of the counter is not necessarily the exact number of errors in theresponse, however, it can be used as a lower bound for the number of errors. A comparison of theabove described methods will be presented in D1.2.Furthermore, several alternative parameters that could indicate a higher probability of fault at-tacks could be observed in terms of reliability and efficiency. These alternative parameters includethe decoding time and the amount of internal power needed to perform the reconstruction process.Here the computing time and the computing power are measured and an unreasonably long timeor an abnormally high computing power could also indicate a fault attack.

3.3.2 Replay Detection

Replay attacks are always a hazard in a system with more than one device. The aim of an attackeris to eavesdrop and record the current communication between two parties. The recorded data canthen be sent again to the receiver to trigger a certain action. In particular, the verifier’s messagesare a potential target for a replay attack, because they trigger the token. Thus it must be ensuredthat the token is able to detect a replayed message.During the enrolment the token stores the generated IDs with the corresponding challenge in avector. As soon as the verifier requests an authentication, the token selects an unused ID, forwardsit to the verifier and marks this ID as used. The verifier selects a challenge from the databaseaccording to the received ID, and forwards it to the token. The token performs a look-up to theaforementioned vector, in order to check whether this challenge has been already used or not. Ifthe challenge was already used, then the token throws an error and shuts down to prevent furthermalicious action.

19/33

4 Implementation and Integration

This section is divided into three parts. The first part covers the implementation of the GraphicalUser Interface and the second part discusses the FPGA Board within the demonstrator. Finally,the third part summarizes the communication protocol and explains how the prototype can beused.

4.1 Graphical User Interface

The main goal of a demonstrator is always to illustrate the main results of the project. The CODESproject focuses on the evaluation and the implementation of different post-processing methods forPUF applications and it is hard to present such results in a general and easily understandableway. This is why we decided to also develop an additional Graphical User Interface, giving us thechance to present the main ideas and the usage of the demonstrator in a more illustrative way.This GUI has to be functional but it is also necessary to show the advantages of the chosen usecases. This means that the user should have the ability to see the information flow and to interactwith the demonstrator.To achieve this goal it is not enough to simply build a user interface with some buttons where theuser can perform several actions. Owed to this fact, the process of setting up the GUI was splitinto three sub-tasks, which are explained within the following three subsections.

4.1.1 Design of the GUI

The design process of a GUI is always very challenging, because the GUI should be on the onehand easy to use and on the other hand it should display the main advantages of the implementedfunctions.Achieving this goal is only possible if a graphical concept of the design is developed in advance.One of the first concepts was to set-up a GUI for both demonstrators. After the concept wasfinished it was clear that this is not a suitable solution, because the GUI would be a congestedapplication. Therefore this concept was split into two separate GUIs for the both demonstrators.Figure 15 displays the concept that has been developed for the first demonstrator GUI.

Figure 15: Design Concept of the First GUI

20/33

This concept enables the user to choose between three different scenarios. The first scenario MutualAuthentication is based on the defined protocol. The aim of the second and third scenario is toshow that the protocol is able to detect possible attacks.During the implementation of the GUI it was decided to replace the possibility of choosing a PUFtype with the possibility to choose one of the five available ASICs on the board, because the PUFtype is already predefined within the protocol. Furthermore, the user got the ability to performthe protocol step-by-step to see the data that is exchanged during this step instead of only seeingthe data after the protocol is finished. Figure 16 displays both GUIs for the two demonstrators.

(a) Demonstrator 1 (b) Demonstrator 2

Figure 16: Final GUI for both Demonstrators

4.1.2 Implementation of the Relevant Building Blocks

In this case, the GUI is not just a simple window that displays some information, it acts as acontrolling centre of the demonstrator. The best and easiest here to advance is to split the tasksof the GUI into several building blocks and implement them as a standalone application to be ableto test them. These building blocks can be derived from the needed functionality.

1. DatabaseThe CRPs stored within the database must be provided to the demonstrator and it must bepossible to change the content of the database.

2. CommunicationThe GUI as a standalone application would not be sufficient, as the main functionalityis implemented on the FPGA board which is also connected to the ASIC board with thePUF-ASICs on it.

3. CryptographyThe defined protocols need cryptographic functions like a Hash function or an AES encryp-tion and decryption module.

4. Error Correcting CodesThe concept of the reverse Fuzzy Extractor defines that the verifier (GUI) must be able toperform the post processing. Thus the GUI must be able to perform decoding steps of thechosen ECC.

These building blocks must be able to act as a standalone application as mentioned above. Due tothis each building block is covered by a class within C++. The main advantage of this techniqueis to implement the functionality in a modular way and to test it. Furthermore these classes canbe integrated easily in the final demonstrator as described in Section 4.1.3.

21/33

DatabaseAs already mentioned the database contains the CRPs, a state and the helper data. The GUI hasto be able to read out, modify and delete data from the database. The easiest way to set-up thisdatabase is to use a simple text-file and to insert the data during an initialization step.The implemented class provides methods for setting up the database during the enrolment step,reading out a CRP and deleting the chosen CRP.

CommunicationThe set-up of the RS-232/UART connection must be matched with the settings given by the driverfrom the FPGA board. The following settings were set:

• Baud rate: 9600

• Parity: No

• Stop bit: 1

The implemented class offers methods for opening a specific COM-port, sending and receiving data.

CryptographyThis class bundles functions for the encrypting and decrypting of data with the AES algorithmand for calculating a hash. The functions are taken from https://polarssl.org/.

Error Correcting CodesThis class is only needed for the first demonstrator, because the GUI has to be able to decode anoisy codeword. Therefore, the implemented methods are able to perform the decoding procedureof the Reed Solomon and BCH code.

4.1.3 Integration

The GUI is a MFC (Microsoft Foundation Classes) based application. MFC is a library thatwraps parts of the Windows API in C++ classes and acts as an interface to the non-objectoriented functions from the Windows API. With these classes it is possible to set-up a graphicaluser interface using the common controls and predefined windows.Visual Studio 2010 was used as development tool, as the build-in assistant makes it easier to createthe graphical user interface.The MFC framework was chosen, because it enables the developer to include C and C++ code intothe application. As already mentioned the single building blocks are implemented as C++ classesto be able to test them as a standalone application. As soon as the implementation and testingof these classes were finished, it was possible to simply integrate them into the MFC application.The upcoming deliverable D1.2 will focus on the testing of the implemented GUIs. Thus, it willalso include detailed screenshots and descriptions on how to use it.

22/33

4.2 FPGA Board

Since, the token is represented with an evaluation board, that contains a Field ProgrammableGate Array (FPGA) this section discusses the used soft-core architecture and the implementationof an ECC.

4.2.1 General Setup

The used PUF ASICs were developed and fabricated in the course FP7 research project “UNIQUE-23881” [7], founded by the European Commission. The ASICs are mounted on an external boardand so an interface is needed to be able to stimulate the PUF with a challenge and to receivethe response. An FPGA board realizes this functionality. One outcome of the before mentionedproject was a driver written in VHDL to enable interaction with the ASIC board. This driver alsoprovides an interface with the Microblaze processor that can be integrated within the FPGA. AMicroblaze core emulates a processor that enables the user to write C/C++ code that can be usedto control the functional blocks that are integrated in VHDL. Figure 17 shows the FPGA withthe implemented Microblaze processor. It can be seen that the Microblaze is able to communicatewith the IP-cores which are implemented in VHDL. Therefore it is possible to implement interfacesbetween the VHDL blocks in C/C++.The controlling of the implemented IP blocks is realized as a state-machine. Therefore the PC hasto send the commands via an UART connection (see Section 4.3) to the FPGA board. These com-mands are interpreted and the according functions are triggered (the commands can be found inTable 1). As an example the enrolment step can be considered: The PC sends the trigger commandand a challenge to the FPGA board. The processor interprets the command and forwards theresponse via the UNIQUE driver to the ASIC board. The ASIC boards sends the response back tothe FPGA board, where it is stored in a register to be able to read it out with the processor. Theresponse is read out from the register and forwarded via the UART driver to the PC. Figure 18

FPGA

Microblaze

Hash

ECC

UART

UNIQUE

Figure 17: Soft-Core Architecture

shows the basic set-up of the demonstrator. The particular FPGA development board which weselected to use for implementing the Prototype was the Xilinx KC705 Evaluation Board 1. Thisboard contains a Xilinx Kintex-7 FPGA (XC7K325T) and a number of useful peripherals. TheASIC board is connected via a custom flat cable to the extension header of the evaluation board.Despite the fact that the FPGA is used as an interface between the two boards, several ErrorCorrecting Codes have been implemented directly in hardware. This was done, because the aim

1http://www.xilinx.com/products/boards-and-kits/EK-K7-KC705-G.htm

23/33

was to implement lightweight error correcting algorithms also in a hardware description language.

Figure 18: Xilinx KC705 and UNIQUE ASIC Board

4.2.2 Implementation of an ECC in Hardware

Since the prototype consists of an FPGA board, and error-correcting codes can be implementedin a very efficient way in hardware, this section focuses on the HW implementation of a ReedSolomon encoder in more detail.The set-up of the prototype forces the hardware designer to implement an interface between theMicroblaze and the encoder (Figure 19). This interface is needed because in the Mircoblaze arandom word is generated and transferred to the hardware module. The codeword is then trans-ferred back to the Microblaze controller. This interface is provided by the user logic.vhd, whichconnects the inputs and outputs of the encoder with the AXI (Advanced eXtensible Interface) bus.Thus, the Microblaze is able to read and write data from/to the encoder. This set-up is shown inFigure 19. Furthermore, it is necessary to perform a data type conversion from std logic vector tointeger within user logic.vhd file, since the soft-core provides data as a bit vector whereas encoderworks with integer type.Another necessary feature is the synchronization between the hardware component and the Mi-croblaze to trigger the encoding and to signal that the encoding is finished. This mechanism isrealized with two flags. The first flag is set by the Microblaze to start the encoding as soon as thedata is written to the interface. The second flag is set by the encoder as soon as the encoding isfinished and the data is written to the interface.

24/33

Microblaze

AXI

user logic.vhd

RS main.vhd

UART

bit vectorstd logicvector

std logicvector

integer

PC

integer

Figure 19: RS Encoder Setup

After discussing the top-level design approach of an ECC implementation this subsection finisheswith a description of the real implementation of an algorithm. As an example the Reed Mullercode is chosen, because it is used within the first and third demonstrator.The first step during the design process of a component in VHDL is to define the input and outputports of this component (Figure 20). In this case the encoder needs four input signals. The clock

RM encoder

clk

reset

enable

message

codeword

Figure 20: Reed Muller Encoder in VHDL

input is connected to the internal clock of the board, the reset input is needed to initialize theencoder, the enable input allows the user to trigger the encoding process and via the messageinput the encoder receives the message which has to be encoded. The result of the encoding iswritten to the output.The described inputs and output can be described in VHDL within the entity block.

−− Descr ip t ion o f the componententity encoding i sPort ( c l k : in STD LOGIC;r e s e t : in STD LOGIC;enable : in STD LOGIC;message : in STD LOGIC VECTOR (4 downto 0 ) ;codeword : out STD LOGIC VECTOR (15 downto 0 ) ) ;

end encoding ;

The defined input and output ports are then connected within the user logic.vhd to the AXI-busas described above.The next design step for the component is to define the internal architecture and thus the func-

25/33

tionality of the component. Within the process a temporary storage is needed and this storageis realized with a variable. Compared to a signal a variable changes its state immediately. Thus,the encoding step needs just one clock cycle. Another clock cycle is needed for writing the resultof the process to the output.

−− Beginning o f the i n t e r na l a r c h i t e c t u r e d e s c r i p t i onarchitecture Behaviora l of encoding i s

−− Signa l i s a g l o b a l d e f i n i t i o nsignal r e s u l t b i t : STD LOGIC VECTOR(15 downto 0 ) ;

−− Define the processbegin−− Process i s s e n s i t i v e to the c l o c k s i g n a lPROCESS ( c l k )

−− Variab le are j u s t v a l i d wi th in the processvariable col lum : STD LOGIC VECTOR(4 downto 0 ) ;variable r e s u l t : STD LOGIC;

−− S tar t ProcessBEGIN−− I n i t / r e s e t e ve ry th ing ( from ou t s i d e )IF ( r e s e t = ’1 ’ ) THENr e s u l t b i t <= x”0000” ;col lum := ”00000” ;

−− I f the c l o c k has a r i s i n g edgeELSIF ( r i s i n g e d g e ( c l k ) ) THEN−− I f enab le i s ”1” ( from ou t s i d e )i f ( enable = ’1 ’ ) thenfor i in 0 to 15 loop

−− conver t the ” i ” in to a 4 b i t s t d l o g i c v e c t o r ( e . g . : 6 −−> 0110)−− and conca t ina te 1 ( e . g . : 6 −−> 0110 1)

col lum := s t d l o g i c v e c t o r ( to uns igned ( i , 4 ) ) & ’ 1 ’ ;col lum := message and col lum ;r e s u l t := col lum (0) xor col lum (1) xor col lum (2) xor col lum (3) xor col lum ( 4 ) ;r e s u l t b i t ( i ) <= r e s u l t ;end loop ;

end i f ;END IF ;END PROCESS;−− Process i s f i n i s h e d −−> copy the r e s u l t to the outputcodeword <= r e s u l t b i t ;end Behaviora l ;

The process is split into two parts that can be triggered via the soft-core. The first part resets theinternal state of the encoder whereas the second part covers the calculation of the codeword. Thus,the developer has to trigger via the soft-core processor each state to receive a valid codeword.

//Reset the encoderReedMuller mWriteReg ( baseaddr , 0 , 0x01 ) ;//Write the message to the encoderReedMuller mWriteReg ( baseaddr , 4 , message ) ;//Enable the encoderReedMuller mWriteReg ( baseaddr , 0 , 0x02 ) ;//Read out the codewordcodeword = ReedMuller mReadReg ( baseaddr , 8 ) ;

The base address of the hardware component is generated by the development tool and must beprovided to the read or write function. Furthermore, the register’s number has to be provided forthe reading or writing function of a register.

26/33

4.3 Communication Protocol

The setup of the demonstrator requires a connection between the PC, FPGA and ASIC board.This connection is realized as a UART connection. The FPGA board offers an emulated UARTport via which this connection is established in this prototype.Xilinx offers an IP core to use the before mentioned emulated UART port. Therefore it is possibleto send data via Microblaze to the connected computer. This driver can be set up in two differentways. Firstly, the UART port works in the blocking mode and secondly in a non-blocking mode.The blocking mode always waits until new data has arrived at the port and blocks the programfrom being executed during this time. The non-blocking mode uses interrupts to receive incomingdata. Both demonstrators are working with the non-blocking UART mode.As soon as new data are received the first byte of the buffer is exterminated, because this bytetriggers the next state of the implemented state machine. All other bytes within the buffer areused for the computation and are defined within the protocol. In Table 1 the used commands arelisted and explained.

Command Data In Data Out Description0xff 1 0 The GUI selects which PUF should be

used.Demonstrator I: Authentication

0x11 1 256 During the enrolment the GUI requestsresponses to given challenges.

0x12 0 1 The GUI requests an ID and the FPGABoard sends an ID, which should be used.

0x13 1 256 The verifier sends a challenge, that wasloaded from the database, to the Tokenand receives the generated Helper Data.

0x14 0 32 The GUI requests and receives the hashvalue a.

0x15 32 1 The Verifier sends the hash value b tothe Token. The Token sends back an ac-knowledgement if the authentication wassuccessful. If the authentication was notsuccessful an error code is returned.

Demonstrator II: Key Generation0x11 text length 1 The GUI sends the enrolment trigger and

the text, which should be encrypted. Thetoken acknowledges the successful enrol-ment.

0x12 0 text length The GUI requests the previously sentmessage.

Table 1: Communication commands

4.4 Usage of the Prototype

Starting the demonstrator consists of two steps. The first step is to open the GUI (UseCase1.exe)and select the used COM port. The second step is to switch-on the FPGA board, connect theJTAG cable with the PC, which is used to program the FPGA, and connect the USB-to-UARTbridge with the board and PC. Programming the board is done via opening a command prompton the computer and executing the UseCase1.bat. This script loads the necessary files from thePC to the FPGA board using the Xilinx tool-chain. As soon as this is done, the demonstrator isready to use (Figure 21 shows the ready-to-use demonstrator including FPGA and ASIC board as

27/33

well as the GUI). The user has now the possibility to choose one of the five available PUFs on theASIC board by clicking on one of the radio-buttons on the GUI. The switching of a PUF is doneimmediately and can be seen on the ASIC board, because every PUF has a LED, that is switchedon, if this PUF is enabled.The next step is to choose one of the scenarios and press the Enrolment button. After this stepis finished, the user is able to step through the protocol by clicking on the Next Step button.Furthermore, the message monitor displays the current state of the demonstrator and the textboxes are displaying live data.

Figure 21: Ready-to-use Demonstrator

5 Conclusion

Integrating a set of functions in a running prototype is always challenging, especially if the pro-totype consists of more than one part. In our case three devices have been merged together intoone demonstrator. Firstly, a GUI represents a Use Case and acts as a control unit. Secondly, anFPGA board provides cryptographic and error-correcting functionalities. Furthermore, the FPGAboard acts as an interface to an ASIC board, which is the third component of the prototype.The main challenge of this setup is the synchronisation between the single components, becauseeach part has a crucial role to fulfil and has to deliver data at a given point of the protocol. Thiscan only be managed by setting up state-machines and defining a sophisticated communicationprotocol between the single components. Furthermore, the implementation of efficient crypto-graphic functions and error-correcting codes in SW and HW requires on the one hand a great dealof testing, and on the other hand HW implementations additionally need a good understandingof the used HW platform.Above all, integration work is always a tough challenge, especially in research projects with agroup of partners. It is important to define interfaces and integration policies at the very begin-ning to avoid troubles during the implementation. An important aspect, which turned out to bevery helpful in CODES, was a thorough modelling/visualisation of the relevant algorithms and usecases. The designed flow charts helped a lot when implementing the actual protocols in VHDLor C.Finally, Deliverable D3.1 ended up longer than actually intended, even though the report shouldonly support the actual prototype. However, we decided to explain the single components in avery detailed manner, to allow the reader to better understand the setup and the ideas behindit. We avoided to insert endless source code, as we do not feel this would bring any additionalvalue. We are confident the report reflects the outcome of the CODES project in an illustrativeand understandable way.

28/33

References

[1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction andGeneral Model; CCMB-2012-09-001, Version 3.1, Revision 4, September 2012

[2] Common Criteria for Information Technology Security Evaluation, Part 2: Security Func-tional Components; CCMB-2012-09-002, Version 3.1, Revision 4, September 2012

[3] CODES Consortium: Common Criteria Protection Profile for PUF-based Devices: DraftVersion, expected availability in September 2014

[4] I. Schaumuller-Bichl, A. Kolberger, M. Deutschmann, C. Heuberger, W. Muller, B. Hackl,“D1.1: SWOT analysis of existing PUF security modules”, CODES Project, July 2013.

[5] B. Hackl, C. Heuberger, M. Mazzoli, W. Muller, V. Brunner, M. Deutschmann, M. Hoberl,“D2.1: Report on suitable post-processing methods”, CODES Project, March 2014.

[6] I. Schaumuller-Bichl, A. Kolberger, M. Deutschmann, “D4.1: Risk analysis, definition ofsecurity objectives and security requirements”, CODES Project, September 2013.

[7] UNIQUE – Foundations for Forgery-Resistant Security Hardware, 09/2009 – 05/2012;FP7 research project funded by the European Commission and coordinated by TechnikonForschungs- und Planungsesellschaft, http://www.unique-project.eu

29/33

A Stand-alone Application: Scenario

In addition to the two demonstrators described above (Authentication and Key Generation), wedeveloped all necessary functions, protocols and descriptions for a third use case, namely theHW/SW binding. In the following sub-sections parts of those descriptions are included. We didnot set up another GUI for this demo, but focussed purely on the development and implementationof the mathematical functions (in SAGE) and used this demo as a platform for research on faultdetection and the syndrome construction. (see Section 3.3 for details)The following figure shows the defined architecture of a LR-PUF.

NVM

FERec

PUFR’

HD

K

New Statereconf()

S*

S

NVM

...S

Figure 22: Architecture of LR-PUF

The sequence diagrams below illustrate UC3 - Key Reconfiguration / HW-SW Binding:

• Figure 23 shows the communication during enrolment.

• Figure 24 shows the simple reconstruction.

• Figure 25 shows the reconfiguration of the key.

30/33

Database GUI / Verifier / Database FPGA Board ASIC Board

generate(state0)

send(state0)

store(state0)

enroll();send(SW,state0);request(K0)

store(state0)

gen(Wr)

codeWord = Encode(Wr)

select(C)

request(R);send(C)

generate(R)

send(R)

HD = codeWord⊕R

store(HD)

K0 = hash(R,state0)

store(EncryptKo(SW))

send(K0);Enrolment OK

send(K0)

store(K0)

EnrolmentEnrolment

Figure 23: HW/SW Binding - Enrolment

31/33

Database GUI / Verifier / Database FPGA Board ASIC Board

request(message)

gen(Wr)

codeWord = Encode(Wr)

select(C)

request(R);send(C)

generate(R)

send(R)

codeWord’ = R′ ⊕HD

codeWord = Decode(codeWord’)

R = HD ⊕ codeWord

K0 = hash(R,state0)

message = execute(DecryptKo(SW))

send(message)

Key ReconstructionKey Reconstruction

Figure 24: HW/SW Binding - Reconstruction

32/33

Database GUI / Verifier / Database FPGA Board ASIC Board

staten = generate(newState)

request(K0);send(staten)

store(staten)

send(K0)

m = DecryptKo(staten)

send(m);request(message,newK)

send(C);request(R’)

generate(R’)

send(R’)

codeWord’ = R′ ⊕HD

codeWord = Decode(codeWord’)

R = HD ⊕ codeWord

K0 = hash(R,state0)

DecryptKo(SW)

staten = DecryptKo(m)

Kn = hash(R,staten)

store(EncryptKn(SW))

message = execute(DecryptKn(SW))

newK = EncryptKo(Kn)

return(message,newK)

Kn = DecryptKo(newK)

send(Kn)

store(Kn)

ReconfigurationReconfiguration

Figure 25: HW/SW Binding - Reconfiguration

33/33