Physical Proximity Verification based on Physical Unclonable Functions

(1)

INOM

EXAMENSARBETE INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK,

AVANCERAD NIVÅ, 30 HP STOCKHOLM SVERIGE 2018,

Physical Proximity Verification based on Physical Unclonable Functions

MARCO SPANGHERO

KTH

SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP

(2)

Physical Proximity Verification based on Physical Unclonable Functions

MARCO SPANGHERO

Master in Embedded Systems Date: August 10, 2018

Supervisor: Mark T. Smith Examiner: Elena Dubrova

Swedish title: Detta är den svenska översättningen av titeln School of Electrical Engineering and Computer Science

(3)

(4)

iii

Abstract

There are rapidly growing concerns about security of hardware implementing cryptographic algorithms. A compromised device can po- tentially be used as an entry point for cyberattacks on other devices connected to the network, as evidenced by the recent Spectre and Melt- down CPU bugs. The attack surface of future mobile networks with billions of connected devices will be enormous. This brings a need for new methods for designing secure hardware that constrain the hardware attack surface and protect against classes of attacks that exploit hardware vulnerabilities.

Physical Unclonable Functions (PUFs) have been proposed as a low-cost cryptographic primitive suitable for resource-constrained IoT devices. PUFs can be applied to uniquely identify a hardware device and to protect it against counterfeiting and tampering. In this thesis, we show how PUFs can be used for verifying physical proximity of two objects, e.g. a SIM card and a mobile phone. This makes possible checking if a SIM card is indeed located in a mobile phone in order to prevent subscription fraud.

The key idea is to decompose a PUF into two parts and to place these parts into the two objects so that only when the objects are physically close to each other the composed PUF computes a correct response to a given challenge. Due to the uniqueness of the PUF responses for a given chip, a correct response provides assurance on the authenticity of two objects as well as their physical proximity. We present an FPGA prototype of the proposed PUF-based physical proximity verification method and discuss it advantages and disadvan- tages.

(5)

iv

Sammanfattning

Det finns en snabbt växande oro för säkerheten med hårdvara som im- plementerar kryptografiska algoritmer. En komprometterad enhet kan användas som ingång för en cyberattack på andra enheter anslutna till samma nätverk, vilket nyligen bevisades av CPU-buggarna Spec- ter och Meltdown. Med framtidens mobilnät ökar attackytan enormt då antalet anslutna enheter till ett nätverk kan uppgå till miljarder.

Nya metoder behövs för att utforma säker hårdvara som begränsar attackytor och som skyddar mot attacker som utnyttjar sårbarheter i hårdvara. Fysiskt oklonbara funktioner (PUFs, eng. Physical Unclo- nable Functions) har föreslagits som en kostnadseffektiv kryptografisk metod lämplig för billiga IoT-enheter. PUF kan användas till att unikt identifiera hårdvara och skydda den mot förfalskning och manipule- ring. I denna avhandling visar vi hur PUF kan användas för att verifi- era att två objekt befinner sig nära varandra, t.ex. ett SIM-kort och en mobiltelefon. Detta gör det möjligt att kontrollera att ett SIM-kort fak- tiskt finns i en mobiltelefon för att förhindra abonnemangsbedrägerier.

Grundtanken är att dela en PUF i två delar och placera de två delarna i varsitt objekt så att först när objekten är fysiskt nära varandra ger de sammansatta PUF-delarna ett korrekt svar på en given utmaning. Ef- tersom PUF-svaren är unika för ett specifikt chip ger ett korrekt svar en försäkran om de två objektens äkthet samt att de befinner sig fysiskt nära varandra. Vi presenterar en FPGA-prototyp med den föreslag- na PUF-baserade fysiska avståndsverifieringsmetoden och diskuterar dess för- och nackdelar.

(6)

List of Figures

1.1 Typical subscription fraud scenario . . . 1

2.1 Conventional 6T SRAM cell . . . 10

2.2 N by M stage ring oscillator PUF . . . 11

2.3 Multiplexer based swithcbox . . . 12

2.4 Two stage arbiter PUF - Delay back-annotate . . . 13

3.1 System Architecture - General overview. . . 15

3.2 Composed PUF - Block Diagram . . . 16

3.3 Decomposed PUF - Block Diagram . . . 17

3.4 RTL view of the implemented LFSR . . . 18

3.5 RTL view of the launcher . . . 20

3.6 Validity Frame for sampling the signal . . . 22

3.7 Frequency plot for SR-Latch . . . 23

3.8 RTL view of a switchbox as implemented in the design . 25 3.9 RTL view of the serial transmitter . . . 28

3.10 RTL view of the serial to parallel register . . . 29

3.11 Byte request data flow . . . 32

3.12 Handshake diagram between the backend system, the master device and the slave device. In an embedded system backend and host can be the same system . . . . 33

3.13 Interconnect structure with Vias, Input and Output buffers 34 3.14 Lumped model of interconnect . . . 34

3.15 Lumped model of interconnect . . . 35

3.16 IO Buffer specific capacitance - EP4CE40F29 . . . 35

4.1 Test system setup . . . 37

4.2 0x3CAA6CF6A839FF11 - HD . . . 40

4.3 0x3CAA6CF6A839FF11 - HW . . . 41

4.4 0xB9ADD027120BAF35 - HD . . . 42

vii

(9)

viii LIST OF FIGURES

4.5 0xB9ADD027120BAF35 - HW . . . 43

(10)

Acknowledgements

I would like to thank Prof. Dr. Elena Dubrova for the continuos fee- back and the great discussions about the project. This project would not have reached this outcome without the great input and review work I received. I would like to thank also Dr. Felipe Marranghelo for the feedback and review work during the project.

I would also like to thank my family, that helped me in this long and amazing journey, comforted me in the moments of delusion and shared my joy in the good moments. I will always be grate for the support I received.

At last, I would like to thank all the friends and colleagues that con- tributed to this work, in various manners, by reviewing the drafts or simply by being interested to my work.

I will always carry with me the amazing people I met in this ad- venture.

Thanks all, Marco Spanghero

(11)

(12)

Chapter 1 Introduction

Subscription fraud is a type of fraud in which a forged identity is used to get services for which the fraud perpetrator is not willing to pay.

Subscription fraud is a long standing problem in telecommunications industry where there is need to ensure that a SIM card is indeed located within an endpoint device, e.g. a mobile phone. We consider the scenario described in Figure 1.1, in which a subscription fraud is presented.

Figure 1.1: Typical subscription fraud scenario¹.

The attacker is able to steal the identity of the victim and to use the victim’s subscription. In case of a mobile communication scenario, the service can be an expensive data plan the attacker can use without possessing an authentic SIM card.

Another area of interest in which physical proximity is relevant is Digital Right Management (DRM). The way DRM works is that the re-

1

(13)

2 CHAPTER 1. INTRODUCTION

ceived digital content (e.g. music, videos, movies) can be played by the reproduction device only if the content is decrypted by a tampering resistant decryption unit with a given subscription. For example an IP-based set-top box uses a key contained in a smart card to decrypt protected content.

The third area of application for physical proximity detection and authentication is preventing the use of unauthorized or counterfeit devices. From the system integrity point of view, physical proximity detection and anti-tampering methods will help fighting the diffusion of imitation devices. This means manufactures must be able to guarantee to the customers that the goods they sell are guarding customer’s privacy.

One famous example where privacy guarding and hardware mod- ule authentication has been critical regards Cisco Networking hardware. In 2008, the FBI reported that the Department of Defense of the United States had several critical issues in the supply chain management for key components of the server infrastructure [2] [3].

These issues were due to the purchase of hardware from non controlled vendors. This problem is then propagated to the entire system as its security was compromised. The case of counterfeit Cisco equip- ment is particularly significant as the device had been tampered and altered to spoof and intercept part of the traffic on the switch. This problem could have been avoided if a secure authentication system was integrated in the platform. Physical proximity detection can prevent forgery if it includes a security layer that is able to uniquely identify the hardware components. The market of counterfeit hardware is growing faster than the authorities can control it. Even if the punish- ment for crime of forgery for hardware devices has been hardened by the Bush administration, there is still a constant flow of devices that are rebranded, modified and distributed not only trough side chan- nels but also trough official distribution lines. The most well known operation has been Operation Cisco Raider. The FBI task force recov- ered approximately 3500 counterfeit network devices for an estimated value of $3.5 Million. The gravity of this issue is well depicted by the FBI report that was originally leaked out and was classified as Top Se- cret [4] [5].

(14)

CHAPTER 1. INTRODUCTION 3

Nowadays, a modern hardware device can be composed of several parts. Each part the device is composed from raises a security issue for the entire system. For this reason the problem of identifying, au- thenticating and verify physical proximity of hardware components becomes critical.

1.0.1 Purpose and Research Scope

The aim of this work is to verify the practical feasibility of the idea of using Physically Unclonable Functions (PUFs) to detect physical proximity of two devices, which was proposed in Patent application [6].

For what concerns the consumer market, one of the most looked after applications for physical proximity verification is SIM cards detection and authentication. If we consider the Patent application [6], the presented application shows the need to detect the physical presence of the SIM card in the end-point device. The need for a secure way to guarantee system’s integrity is one of the upcoming most requested features by the market. This research is aimed to present a proof of implementation of a physical proximity detection system.

1.0.2 Sustainabiliy and social impact

The lack of security rises several issues both on the ethical and on the economical plane. As showed in a survey conducted by McKinsey [7], the need for security is impelling in the market but circuits manufacturers are not willing to pay the overhead needed to secure their devices. In 2020 the market is expected to see between 50 billion and 100 billion connected devices. In this thesis author opinion, it is part of the ethical responsibility as a manufacturer to secure the deployed devices. Software, computer and network security areas have developed across the past 30 years and now are able to provide a reasonable level of security even if there is a constant race between the defenders and the attackers [8]. The strive to develop more effective secure hardware implementations continues, both in academia and industry [9]. With the number of connected devices growing, there is a need not only to protect the data generated and exchanged in the networks, but also to identify both, malicious devices and compromised hardware components. By this we mean that the upcoming generation of networks must be able to identify and suppress devices that are suspected to

(15)

4 CHAPTER 1. INTRODUCTION

be untrustworthy. The second ethical aspect we must consider is sustainability, both economical and environmental. Increase in computational power and device density come at a very high environmental cost. More complex machines mean higher energy consumption. In- creasing the number of components per device implies more need for resources and less possibility of recycling. In addition, the need for more powerful computational platforms to allow the implementation of advanced security algorithms comes at the cost of higher power consumption. From a sustainability point of view we must focus on reusing the resources already available in the system’s architecture.

We will consider in more details how to enforce this in the following sections.

1.0.3 Research Questions and Risks

We want to evaluate if it is possible to implement an unbiased PUF system that is evaluated across two different boards and allows secure hardware identification of the two devices. We call one board the system master and the slave board the accessory device. The project shows an implementation where the system master can detect the hardware physical proximity and authenticate the slave accessory device by evaluating the PUF path. We present an attack that is meant to skew the PUF response and we show how the system is able to detect tampering and change its response accordingly.

In the future work section, we discuss several possibilities of how the PUF response can be analysed without introducing biasing and analyse their feasibility.

The critical questions that are to be answered concern the physical structure of the PUF. The main challenge in the implementation is to provide an unbiased connection between the board by providing symmetrical links across the two devices. Another engineering challenge to be solved concerns the number of signals needed to implement the device. The major risk about the project is that even if the PUF is correctly implemented we might not be able to detect tampering events because environmental factors might skew the measurements.

(16)

CHAPTER 1. INTRODUCTION 5

1.0.4 Methods

The presented project implements the technique presented in [6]. The implementation is realized on FPGA board from Intel Altera. We selected the DE2-115 education platform with Cyclone V GE devices.

The data is generated by the platform and analyzed in Matlab to extract the statistical properties. All the data post-processing is made using Matlab. The diagrams are designed in draw.io and the tool for reporting is L^ATEX.

1.0.5 Innovation content and Goal

The innovation content of the project consists in the implementation of the decomposed PUF concept. The challenge response pair authentication system also presents an innovation part, due to the unconven- tional implementation of the PUF. The presented design assumes that the challenge is initialized on two separate devices and then the evolu- tion of the challenge generation method is independent on each side of the system. On the other hand, in traditional challenge response pair the sampling of the response from the device can be done by just considering one single device. We will also present a novel approach to switchbox configurations that allows to minimize the exchange of data between the two boards. In a split PUF implementation the sampling and matching of challenge response pairs need to be done considering the complete system master and complimentary accessory device.

Timing matching presents several technological challenges and mod- elling the interconnect system is a critical part of the work. The system present several challenges also from the point of view of verification measurements. We will explain how verification measurements can be interpreted as an ongoing attack on the device.

1.0.6 Outline

Chapter 2 introduces the concept of PUFs and give an overview of the background and the state of the art in the implementation of PUFs is FPGAs. Chapter 3 presents the implementation strategy for the device and outline the details of the implementation of each stage of the PUF and the control systems. Chapter 4 describes the attack strategy and the setup used. At last in section 5 we summarize the obtained results and the future work.

(17)

Chapter 2 Background

The aim of this work is to verify the practical feasibility of the idea of using Physically Unclonable Functions (PUFs) for verifying physical proximity of two devices, proposed in Patent application note [6].

Several types of PUFs have been proposed in [10] and [11]. A PUF exploits the characteristics of the silicon to generate a unique response to given PUF instances. The following characteristics are common to every PUF:

• Easy to manufacture, as the realization and integration overhead should be minimal compared to the complexity of the system.

• Stable, as the response should be the same for the same input challenge.

• Unique, as the response must be distinguishable from other de- vices and must be not reproducible by other devices.

A common way to implement PUFs in a cost effective manner is to exploit process variations in the manufacturing. The error on the realization process introduces a variation that is impossible to control.

This can be exploited to obtain unique signatures from the devices. At present state of the art in silicon manufacturing, there is no practical way to control the process to the level where is it possible to create two physically identical chips. PUFs provide a possible alternative to key storage methods where the key is always present in the device, by generating the key on request. We cite, among the most popular key

6

(18)

CHAPTER 2. BACKGROUND 7

storage methods, programmable efuses and battery powered memories.

More detailed description of these methods is presented in [12].

There are several types of PUFs. The most common are:

• Delay PUFs: This class of PUFs exploits the uniqueness in prop- agation delays to generate an output. One type of delay PUFs is arbiter PUFs that exploit a race condition between two symmetrically designed paths. We use this type of PUFs in our work.

• Memory based PUFs: These PUFs exploit the fact that the ma- jority of memory bits tend to consistently produce either a low or high level at each memory power up [13]. The most popular implementations are based on SRAM memories.

One of the applications of PUFs is replacing the traditional key storage systems. This gives several advantages including cost reduction and flexibility of the implementation.

However, even if PUFs are theoretically stable and to the same challenge they are expected to produce the same response, several factors can influence the behaviour of the PUF in practice. First of all, as we use physical characteristics of the substrate, any environmental variation may produce variations in the response. PUFs are specifically sensitive to changes in temperature because the resistivity of the substrate can change, modifying the propagation delay characteristics. To enforce robust and consistent responses of the PUF, majority voting techniques can be used in order to statistically produce the same response at the same challenge. There are also other techniques for making the output of PUFs more robust, including [14].

2.0.1 State of the Art

This section describes the state of the art in PUF implementations. We start by exploring the requirements for arbiter PUFs and by analyzing the existing implementations available in research studies. We will divide the topic based on the type of PUF to be considered. For delay based PUFs, we consider ASICs and FPGAs implementation while we only give a brief outlook of memory based PUFs. Considering delay PUFs, the most common types are arbiter PUFs and ring oscillator

(19)

8 CHAPTER 2. BACKGROUND

PUFs. Several other types have been studied, such as butterfly PUFs.

In [15], the characteristics of arbiter and ring oscillator PUFs are described. The paper also presents a physical characterization system to evaluate entropy estimation of the PUF. The implementation proposed in [15], is focused on ring oscillator PUFs that are more suited for FPGA implementation. An authentication scheme for PUF enforced devices is also presented in the paper and describes possibilities and limitations of PUF-based challenge response authentication method.

The major limitation is that there is the need to have a secure chan- nel to collect the challenge response pairs for the first characterization.

After the manufacturing process there is need to sample the behaviour of the PUF system to collect the challenge response pairs. These pairs are meant to be used in the authentication method when the device is deployed in field. The main limitation to this type of authentication is the need to know beforehand the behaviour of the PUF. This information is needed to allow a remote authentication server to verify the device. We will see in Section 5.0.1 how this is a limitation of the presented design too. Other implementations are described in [16] where the SRAM PUF implementation is also presented. In reference to the last paper we consider the difference between Strong and Weak PUFs.

This terminology can be used to classify PUFs into two groups.

A Weak PUF is a device that has high internal entropy and provides a method to express the PUF’s disorder with limited challenge set and restricted access to output. The first means that only few challenges need to be presented to the PUF to obtain a response. The latter means that there is no possibility for an attacker to have access to the output of the PUF even if in physical possession of the device. One example of Weak PUFs are SRAM based PUFs. A Strong PUF is a device that needs a more complex challenge response system, compared to the previous definition, to exploit the internal entropy of the system.

The previous classification is based on the number of challenges each type accepts. A strong PUF accepts a large set of challenge response pairs, up to 2ⁿ. A weak PUF can produce the response only to a limited set of challenges, in the minimum case only to one.

PUFs can also be classified into modellable PUFs, that have a model and non-modellable PUFs. One clear disadvantage of modellable PUFs is that an attacker is able, given access to enough Challenge Response Pairs (CRPs), to build a matematical model that is able to emulate the

(20)

behaviour of the PUF. This is an hot topic in reaserch and one important development is machine learning based attacks on PUFs [17].

One example of Strong and Modellable PUF is the Arbiter PUF presented in [18].

2.0.2 Memory Based PUF

We will now discuss the structure of memory based PUFs. Several implementations have been presented basing the design on external memories. One issue with memory PUF implementations in FPGA is the countermeasures that FPGA manufacturers put in place against data retention. Memory mapped PUFs are not possible in FPGAs as the memory is zeroed at every power cycle to avoid retention effects.

The current implementations, that are commercially available, show that implementing PUF response extraction from memories is possible under specific conditions, like environment and power supply limitations. We will refer as an implementation example to Intrisic ID solutions. Intrinsic ID presents SRAM based PUF solutions for server and IoT authentication. The implementation uses the snapshot from the non initialized SRAM of the system to extract an unique key after power on. The major challenge is to ensure the key is reliable over time and is unique. The reliablity of the PUF can be influenced by external conditions like temperature and voltage variations. The variance that is expected from the change in temperature can be compensated by robust software implementation that can manage to recover the correct response information. We refer to [19] for more information about an example of a commercially available solution.

For what concerns the resistance of the memory to power supply changes, we refer to [20]. From the referenced paper, we see there is possibility to destroy the response of the device by thermally stress- ing the memory IC alongside modifying the voltage conditions and by making the chip work outside the specified region. This procedure is called accelerated aging. By forcing the non optimal conditions around the IC we can induce faster aging in the memory and permanently destroy the PUF signature. This does not allow the attacker to extract and model the signature but forces the device to enter a state in which it cannot be used. The attack is performed stress- ing the memory cells with multiple power bursts and thermal stresses.

This introduces forced aging in the SRAM cells that force the status

(21)

to change and modify the original fingerprint. From the diagram of a SRAM cell we see that forcing changes in temperature in the memory and aging the cell can skew the original imbalance that produce the signature. The following schematic is taken from [21] where a novel type of SRAM cell implementation for high speed and ultra low power applications is presented.

Figure 2.1: Conventional 6T SRAM cell

As already said, process variations and noise make the cell reach either the logic high either the logic low state. The state in which both control halves of the cell are logic high is unreachable and unstable.

Variations introduced by aging will modify the biasing introduced by the production process. This reduces the robustness of the PUF and makes the identification system less precise. In a good state, a 64 bit signature can be used to identify one chip among a population of 5120 other identical devices, as reported in [20]. The applications for this type of technology are already market-ready solutions. An advantage of these solutions is the possibility to provide one-time key generation from devices that are already on-board, without increasing the cost of the device.

2.0.3 Delay Based PUF

Compared to Memory Based PUF, delay PUFs are more a research topic than an industrial product. Delay PUFs use a different paradigm

(22)

than memory based PUFs. They rely on the matching in propagation time between two delay paths and the process variation to make the paths delay unique. Both ASICS and FPGA implementations of this type of devices are available and present different advantages and dis- advantages. We will briefly introduce ASICs implementation and then discuss FPGA implementations, that are more relevant for the scope of this project. The two major classes of delay PUFs are Ring Oscillator PUFs (RO PUFs) and Arbiter PUFs. Ring oscillators structures that are made oscillating at a specific frequency using a feedback delay line made of inverters. We refer to Figure 2.2 for more clarity, where a PUF made by M ring oscillators of length N is presented.

[...]

[010010101...10010]

Ring Oscillator

Feature Extraction

Figure 2.2: N by M stage ring oscillator PUF

To compose the RO PUF several RO are placed in parallel and the outputs are fed to a XOR gate. The oscillation frequency is the same for all the ROs but will change slightly depending on the process variation and on the length of the feedback loop. The significant part of the res- onant frequency is determined by the number of inverters in the loop.

This topology of PUF is extremely effective to be used a True Random Number Generator (TRNG). A ring oscillator PUF can provide similar levels of entropy as a noise generator.

We focus now in more detail on the analysis of arbiter PUFs. Any logic circuit has a specific propagation time that jitters from the theo- retical value by a small amount that does not compromise functional-

(23)

ity. For this small variation, there is a randomized distribution of characteristics that make every circuit unique. The arbiter PUF exploits this indetermination to generate an unique response.

The PUF is build around two main components. The delayline is composed of an arbitrary number of switchboxes and constitutes the two paths were the signals propagate. Each switchbox can be config- ured as a passtrough for the signal or can switch the signal by swap- ping the outputs. Figure 2.3 presents the structure of a multiplexer based switchbox.

The arbiter PUF operates by creating a race condition between two different signal that are produced at one end of the puf and produce a logic High or Low value based on an arbitration system at the other end of the device. The device used to produce a response from the outcome of the race condition is called arbiter.

0

1 1

0 A In

B In

A Out

B Out SB

Control

Control path Input path Output path

Figure 2.3: Multiplexer based swithcbox

The implementation of these devices exist both in ASICs and FP- GAs. The arbiter PUF is mostly implemented in ASICs because of the better control that can be enforced on the paths placement. The implementation on FPGA are interesting, reasearch wise. Delay PUFs do not suffer of the problem addressed for Memory based PUFs as there is no need to protect the implementation from data retention as there is no data resident in the PUF when the system is offline. For this reason De- lay PUFs can be implemented in FPGAs as a Hard IP. We define Hard IPs those design blocks that need manual place and route in addition to the normal synthesis procedure. These blocks have different names depending on the manufacturer (in case of Intel Altera these regions are called LogicLock). Considering in major detail the structure of the

(24)

PUF and its functionality, we refer to Figure 2.4, showing the structure of a two stage delay PUF.

D2,1

D0,2 D2,2

D_4,1

D_4,2

Arbiter D0,1

Launcher D1,4 D3,3 D3,4

D1,2

D3,1

D3,2 D1,3

D1,1

SB₁ SB2

Figure 2.4: Two stage arbiter PUF - Delay back-annotate

Each delay is back-annotated considering the following notation Di,jwhere i stands for the stage of the depth of the considered element in the delay line starting to count from the arbiter side and j is the internal connection in the selected element numbered in cardinal order from the top. The passthrough connections are always numbered 1, 2 while the crossed connections are 3, 4, with the odd numbers where the signal starts from the upper branch and the even numbers where the signal starts from the lower branch. The following equation sets define the delays of the PUF for all the possible control combinations in the case of the 2 stage arbiter PUF:

S0; S1 DP U F

(0, 0) D0,1+ D1,1+ D2,1+ D3,1+ D4,1

D0,1+ D1,2+ D2,2+ D3,2+ D4,2

(0, 1) D0,1+ D1,1+ D2,1+ D3,3+ D4,2

D0,2+ D1,2+ D2,2+ D3,4+ D4,1

(1, 0) D_0,1+ D_1,3+ D_2,2+ D_3,2+ D_4,2 D0,2+ D1,4+ D2,1+ D3,1+ D4,1

(1, 1) D_0,1+ D_1,3+ D_2,2+ D_3,1+ D_4,1 D0,2+ D1,4+ D2,1+ D3,3+ D4,2

Extending the previous concept to N number of stages, we can ob- serve as, ideally, one configuration of input should always lead to the same response at the arbiter. This allows us to define a challenge (the configuration value of the delay line) and a response (the comparison outcome of the arbiter).

We will now briefly discuss some limitations of arbiter PUFs. The

(25)

stability of the response is heavily dependant on the environmental conditions. The PUF is sensible to temperature variations and to physical implementation. Considering the implementation difficulties first, we immediately address the complexity of routing an arbiter PUF to guarantee minimal skewing in the delay line. ASICS designs allow for manual design and placement of the individual cells. For this reason the best matching can be achieved and the uniqueness and symmetry properties are improved compared to the FPGA implementation. The FPGA implementation requires hard constraints for what concerns the placement of the design in the device. The implementation is strictly dependant on the manufacturer and on the technology used. In [22]

is presented a fair comparison between an arbiter PUF implemented in FPGA and in ASICs. The implementation described is a variation of the standard Arbiter PUF that combines the advantages of the arbiter and ring oscillator PUF. The uniqueness and stability of the PUF results improved by the modification on both the ASIC and FPGA implementation. Other critical aspects to be considered are the temperature and voltage conditions the design is operated at. As presented in [22], both parameters can be used to modify the response of the PUF.

When moving away from nominal operative conditions, the feedback loop in the new PUF topology presented stabilizes the output. We presented general rules to deal with delay PUF and some criticalities in their implementation. More details on the specific issues in the implementation of these devices, more attaining to the scope of this project, are presented in chapter 3 and following sections.

(26)

Chapter 3 Implementation

This chapter presents the implementation of the prototype and the structure of the software and hardware blocks. We discuss the implementation for what concerns the routing characteristics and the placement considerations to minimize the bias of the PUF. We also consider the engineering challenges concerning the board to board communication that allow the design to minimize bias at system level. The implementation is made on Intel Altera Cyclone IV devices but at the present state does not require any specific hardware binding and can be implemented on any FPGA. The only requirement is for the FPGA’s floor- plan size. The size of the device floor plan needs to be large enough for the delay line to be placed with one multiplexer per cell. The Figure 3.1 presents the overall representation of the implemented architecture.

HOST SYSTEM - Bus controller - Motherboard - System Master

SLAVE SYSTEM - Bus Slave - Additional Devices

PUF STAGE1 PUF STAGE2

Com BUS (Periph. speciﬁc)

Dedicated control signals Time constrained signals

Power Management Power Management

Power Man

Figure 3.1: System Architecture - General overview.

The host and slave systems are connected by an application spe-

15

(27)

16 CHAPTER 3. IMPLEMENTATION

cific bus that transfers control signals and time constrained signal for the PUF between the two modules. This general representation can be referred to the SIM card application example, where the end point device acts as the host and the SIM card is a slave.

3.1 System architecture

The system architecture is composed of two main blocks that build the PUF and four control blocks that allow the PUF to compute the response as expected. The main blocks are:

• SwitchBox LFSR: the LFSR is used to provide challenges to the SwitchBox. The LFSR is seeded with an initial value that allows to update its state at each startup.

• Delayline: the delay line block constitutes the PUF path itself.

Each switchbox is synthesized using a two MUXs structures as shown in Figure 3.8.

• Arbiter: the arbiter is the block that generates the output of the PUF

• Shift buffer and Serial Controller: the shift buffer and the serial controller sample the PUF responses and transmit the data using a serial port back to the main system.

• Launcher: the launcher generates the initial pulse for the PUF. It is controlled by the shift register to reset its behaviour after each sequence of pulses is generated.

Figure 3.2 presents the test implementation to verify the system functionality.

Launcher SB1 SB2 SB63 SB64 Arbiter

64 Bits LFSR

8 Bit Shift Register

UART Transmitter controller LFSR 64

Seed LFSR Init

[...]

SR Reset

UART_TX

Figure 3.2: Composed PUF - Block Diagram

(28)

CHAPTER 3. IMPLEMENTATION 17

Figure 3.3 presents the effective configuration of the device for the decomposed PUF configuration between the two FPGAs. The decom- position of the PUF makes necessary to duplicate part of the components.

Launcher SB1 SB2 SB63 SB64 Arbiter

64 Bits LFSR

8 Bit Shift Register

UART Transmitter controller

LFSR Seed LFSR

Init

[...]

SR - LNC Reset UART_TX

SB1 SB2 SB63 SB64

64 Bits LFSR [...]

[...]

NIOS2 Core NIOS2 Core

LFSR Init

LFSR Seed

64 bit 64 bit

PCB - MASTER PCB - SLAVE Control Bus TX

Control Bus RX

PUF to Core UART

System Enable

Figure 3.3: Decomposed PUF - Block Diagram

Next, we discuss the general behaviour of the decomposed PUF and explain how the system generates byte long responses from the PUF and transmits responses back to the controller. The device work- flow is meant to produce one response byte at a time to allow the serial transmitter to send the produced data to the master controller. This be- havior is due to the fact that the generation of CRP pairs is much faster than the serial transmitter controller. Once enabled the system runs in free running mode, generating CRP response pairs. Only the response bits are sent over the serial communication line, as the challenges can be generated on the master system once the initial seed for the LFSR is known.

The system works by launching a sequence of eight pulses through the delay line and sampling the respsonse of the arbiter trough a 8 bit shift register that is clocked synchronously with the launch device.

This assumes that the propagation time in the delay line is faster than one clock cycle period.

The system is automated with the usage of a NiosII core from Al- tera. This solution is used to control the PUF device and to provide an abstraction layer for user commands. The structure of the control commands is presented in section 3.1.5. This allow the device to operate in command mode instead of free running mode.

We conclude this chapter by discussing the interconnection and data exchange protocol that allows to decompose the PUF in two parts.

(29)

We consider propagation delays of the interconnect structure and pro- file the behaviour of the interconnect. We also provide an interconnection scheme that allows two boards to work synchronously by simply interconnecting the clock pipes between the two devices. The interconnect board provides both control and time critical connections. We discuss the role of the interconnect board in time critical domains in Section 3.2. In the following we analyze the structure of the single implementation blocks.

3.1.1 Configuration Linear Feedback Shift Register

The system generates a set of CRP to verify physical proximity of the host and slave board and authenticate the slave board. Challenges need to be updated at every pulse event from the launcher that happens at the rising edge of the clock. To update the challenges we use a Linear Feedback Shift Register to generate pseudo random numbers starting from a seed provided by the system controller. Figure 3.4 shows the RTL view from the Intel Quartus Prime RTL viewer.

Date: June 08, 2018 Project: launch_partition

Page 1 of 1 Revision: launch_partition

LFSR:SBCONF

clk en seed_DV[7..0]

seed_LFSR_data_h[63..32]

seed_LFSR_data_l[31..0]

data_LFSR[63..0]

= Equal0 A[63..0]

B[63..0] OUT

r_LFSR[64..1]

D CLK ENA SCLR 64'h0

Q

r_LFSR~[62..0]

0 1

r_LFSR~63 0 1

w_XNOR w_XNOR~0

w_XNOR~1

32:63 63:32

1:31

0

31:0

60 61

63 64 1:63

0:62

Figure 3.4: RTL view of the implemented LFSR

LFSRs provide a very efficient way of producing pseudo-random numbers of a arbitrary length. An n-bit LFSR can produce 2ⁿ 1dif- ferent pseudo random numbers given that a primitive characteristic polynomial of degree n is used¹. The basic operation is the following.

1A primitive polynomial is a polynomial that generates all elements of an extension field from a base field. Source:http://mathworld.wolfram.com/

PrimitivePolynomial.html

(30)

At each clock rising edge the content of the LFSR is shifted by one position and the input stage is fed back with a linear combnation (XOR or XNOR) of selected taps in the LFSR, specified by the characteristic polynomial. The use of primitive polynomials ensures that the LFSR has the maximum length period 2ⁿ 1. This means that the LFSR can produce 2ⁿ 1different pseudo random numbers before returning to the initialization value. Depending on the implementation of the LFSR two illegal states exist. The first one is the all logic low state. This is illegal in the XOR configuration because the LFSR is stuck in the all- 0 state. For the same reason the all logic high state is illegal for the XNOR implementation, as the LFSR would be stuck in the all-1 state.

The list of primitive polynomials is known and it is mapped up to 168 bit long LFSRs in Xilinx application notes². The same approach can be used to implement an LFSR in Intel Altera FPGAs. The current implementation uses two 64 bit LFSRs.

2https://www.xilinx.com/support/documentation/application_

notes/xapp052.pdf

(31)

3.1.2 Launcher and Arbiter devices

The launcher and arbiter are fundamental blocks to ensure the correct functionality of the PUF. They are connected at the two ends of the delay line and are used to generate the pulse that is propagated through in the delay line and to decide the response, respectively. We start by analyzing the behaviour of the launcher and we dedicate a separate section for discussing the arbiter.

Launcher

The launch device is used to generate a pulse at every rising clock edge. It is composed of a control system for the pulse generation and an output frontend that connects to the delay line. The control logic allows to time the pulses sequences of eight pulses per operation cycle.

This is done to adapt the speed of the PUF to the serial transmitter used to communicate the response to the controller system. The routing of the launch device needs dedicated care. As the pulses generated at the output of the device need to reach the ports on the delay line ideally at the same time, the length of the connections need to be matched as close as possible. The launcher needs to be designed in such a way that the unbalance between the two lines is minimized. To allow this, the pulse is generated by a single block of logic and then the routing is performed manually by constraining the Place and Route engine such that the resulting connections are symmetrical. Figure 3.5 shows the implementation of the control logic and pulse generator.

Date: June 08, 2018 Project: launch_partition

Page 1 of 1 Revision: launch_partition

launcherv2:LNC

i_clk

i_en

i_reset_launcher

launch_A

launch_B

o_count[3..0]

SRLatch:pulser

R S

Q

<

LessThan0 1'h0CIN

A[3..0]

B[3..0]

4'h8 OUT

launch_A 1'h00

1

LC1

IN0 OUT0

Q_i

Q

DATAIN OUT0

notQ

notQ~0

IN0 OUT0

counter[3..0]

D CLK

CLRN ENA 4'h0SCLR

Q data_ok

int_launch~direct

DATAIN OUT0

+ Add0 1'h0CIN

A[3..0]

B[3..0]

4'h1 OUT[3..0]

launch_B 1'h00

1

Figure 3.5: RTL view of the launcher

We instantiate a counter inside the device that updates at the clock flank and controls a tristate output. The counter is asynchronously reset by the serial transmitter at the end of the transmission. Moreover,

(32)

the generated pulse needs to be shorter than a clock cycle. Hence, we use a pulse generator with a Set Reset latch where the output is connected in feedback to the reset input. We exploit the delay in the return path to generate pulses from the latch. We can tune the length of the pulse by manually controlling the length of the return path. We use the clock as an input on the set of the SR Latch to generate the rising edge front. It is important for the pulse to be shorter that a clock cycle because this allows the shift register to sample the arrival of the two signals on the next clock flank. The entire propagation time of one pulse needs to be shorter that clock period. We can account for the propagation time with the following expression:

TP ropagation = TDL1 + TM etal1 + TGP IO1

+TInterc.+ TM etal2 + TGP IO2 + TDL2

Where TDL: propagation time inside the delay line

T_{M etal}: propagation time in the interconnect fabric inside the FPGA TGP IO: propagation time trough the GPIO buffer and the GPIO Pin TInterc.: propagation time in the interconnect fabric between the boards

We can obtain a very precise estimation of the propagation time of the signal in the interconnect wires that is due to the physical model of the wires, we can only have a estimation of the propagation time inside the FPGA that can be inferred from the propagation time of signals in the interconnect matrix. A proper estimation of the internal delays of the FPGA is dependant on the specific implementation platform and is outside the scope of this work. For the implemented design the critical part is the matching of the electrical lengths. The propagation time of the signal from the launcher to the output pins needs to be the same in both propagation paths.

Arbiter

The design of the arbiter is conceptually simple but presents several pitfalls that might prevent the PUF to function properly. If we consider the situation described in picture 3.6. The delay in the signal edges arrival determines the result produced by the arbiter. This is exploited to translate the PUF delays into a binary digital signal that can be processed. The arbiter needs to be latched and non clocked to

(33)

allow the change to be dependant only from the arrival time of the input edges. This rises a number of problems due to the metastability of the arbiter. Considering the picture we see that the arbiter is pre- vented from metastability only in the interval of time corresponding to the DATA valid area.

DATA Wait Window DATA Valid

Window Metastability area

~ n100 pS

Metastable Transition puf_A

puf_B

ARB

Time T₀

Figure 3.6: Validity Frame for sampling the signal

We will define this time interval as DATA Valid. During the time DATA Valid, the arbiter latches the output and depending on the arrival time of the signals the result is either logic high or logic low. The arbiter is stable only in this time window. The main issue is that the time window is much smaller that the actual duration of the metastable phase. To perform this, a local clock step up is needed to oversample the output of the latch and a filtering system must provide the correct decimation factor to drop the meaningless samples. We consider meaningless any sample that is taken outside the opportunity win- dows marked by DATA Valid. On the other hand, an asynchronous solution would avoid the need for an oversampling system and retain the sample up to the successive event.

We will discuss three possible approaches for solving this problem which we investigated. The first approach, based on the Set Reset Latch, uses a latch structure to sample the arrival order of the signals.

Depending on the DATA Valid window, the collapse of the state might not depend on the delay line but is due to external and internal noise of the system. The Latch arbiter is presented due to the simplicity in the implementation. As from the present research work, seems that

(34)

the latch does not provide consistent results. Figure 3.7 shows the results obtained reading the PUF output and sampling the output at the Latch.

Figure 3.7: Frequency plot for SR-Latch

The buckets are the decimal representation of all the possible configurations of 8 bits. We plot the frequency histogram for 1 million samples of the PUF. From the collected data we can see that the output is very unbalanced and does not present and presents trends due to repeating patterns in the data.

The second possible approach is using an asynchronous design to sample the output of the delay line. We assume the following constraints:

• The device needs to hold the state until the next transition on the inputs.

• The transition in the inputs is never simultaneous. Only one input toggles at each moment.

The first requirement is typical for asynchronous designs [23]. The point in implementing an asynchronous system is that we want to be

(35)

able to hold the asynchronous event until the next event happens at the input. The second requirement is more complex. By asynchronous implementation rules, only one signal can toggle at the same time. We can ensure this by studying the properties of the delay line. The length of the paths is consistently different. For this reason we can ensure the arrival times of the signals will be slightly different from one another.

The difference in arrival times is also the data we want to determine.

The design and implementation of an asynchronous arbiter is left for future work.

The third possibility is to use a D flip flop to perform the arbitration between the arrival times of the signal. One side of the delay line is connected to the data line of the DFF while the other side is connected to the clock input on the DFF. Doing this, the signal is sampled correctly in either direction and hold by the DFF until the next clock input. This allows to sample the outcome of the device synchronously with the clock. This third option is implemented in the design. The implementation of the DFF balances performances and development effort. Moreover, the DFF needs to be manually placed to ensure symmetry in the arbiter. The implemented structure fits in one logic cell of the FPGA, so it is possible to precisely place the arbiter symmetrically in reference to the delay line.

(36)

3.1.3 SwitchBox and Delay line structure

This section presents the structure of the switch boxes and of the delay line. It is critical that they are carefully implemented and placed. The device is composed by concatenating the switch boxes into a chain that is then manually placed. Each switchbox is composed as in Figure 3.8.Date: June 08, 2018 Project: launch_partition

Page 1 of 1 Revision: launch_partition switchbox_struct:\SB:1:S

as_in bs_in

switch_control as_out

bs_out struct_mux:M1

s

x1 x2

xt

struct_mux:M2

s

x1 x2

xt xt~0

xt~1

xt~2

xt~0

xt~1

LC[2..1]

IN0 OUT0

xt~2

1 2

Figure 3.8: RTL view of a switchbox as implemented in the design Each switch box is implemented using two multiplexers controlled in 180 phase shift. This results is either the pass-trough configuration or the crossed configuration, depending on the value of the control bit.

The multiplexers are implemented in structural VHDL style to have maximum control on the placement during the synthesis.

The delay line is constructed by concatenating the switch box structures and it presents ports for input, output and a 64 bit long configuration port to set the crossing in the switch boxes. The delay line structure needs to be protected from the synthesis process. Intel Quar- tus Prime synthesis engine removes replicated structures like delay lines. This happens because the delay line by itself is assumed to be a sub optimal component. From the synthesis engine point of view, the amount of area used to instantiate the delay line can be optimized by connecting directly the launcher to the arbiter. To prevent the device to be optimized away, we tune the synthesis engine as follows. The design approach is to use Altera low level primitives to partition each slice of the delay line. Low level primitives are components that can be

(37)

instantiated in VHDL that allow to protect logic block from optimization. The used primitive is called LCELL and constitutes in a simple buffer. By instantiating one LCELL buffer on each output of the switch box we can protect the device itself. The second adjustment is to set the the compile options to skip optimization of switch boxes. By doing this we deactivate any automatic optimization done by the compiler.

This is helpful to control the layout and implementation but relies on the designer ability to optimize the design. These settings are usually not needed and are part of specific and advanced options of the compiler. Regarding the placement of the PUF, the Place and Route (PnR) algorithm and the Fitter from Quartus will place the blocks awareness of the need to place the PUF blocks in a symmetric way. The placement is realized to minimize the area consumption and the Fitter will try to pack the maximum amount of devices in a specific area. The general optimization is done by synthesis speed optimization. This means that the optimization effort is minimized to reduce compilation time.

(38)

3.1.4 Shift Buffer and Serial interfaces

The collection of data presents several issues. The timing window in which the data is available is the one defined as Rise in section 3.1.2.

The arbiter provides a valid data bit only in this opportunity window.

Outside this interval the data produced by the arbiter is influenced by the convergence point of the metastability of the device and is un- correlated from the characteristics of the delay line. For this reason is important to sample the arbiter value at the correct time.

The transmission device is made of two components. The first device is a Serial to Parallel shift register that collects single bit signatures and turns them into byte long data that are passed to the serial transmission block. Figure 3.9 shows the structure of the serial transmitter while Figure 3.10 shows the structure of the serial to parallel register used to sample the response.

The device is also provided with useful control signals that signal the fillup of the register and the current status of the device. These controls are used to start the transmission of the data packet on the serial interface. The register is protected from overwrite and the reset system is connected to the transmission completion controller from the serial port. In this way the transmission device is able to stream continuosly the data coming from the PUF in frames that are one byte wide. This design choice is due to the fact that the transmission of one data frame is significantly longer than the time needed to generate one data frame from the PUF. The launcher generates one sample per clock cycle. This meaning that the PUF produces one complete data frame in 8 clock cycles. After the generation the Serial to Parallel register is ready and the serial transmission begins. The serial interface is a standard UART compliant interface used only in transmission mode. The serial bus operates accordingly to the standard uart specification and has a transmission rate of 115200 baud. This allows the serial port to communicate to standard serial interfaces and to RS232 interfaces with external logic level converter. If we consider the following parameters:

• Baud rate: 115200

• Control: 1 start bit, 1 stop bit, no parity

• Data: 8 bit data

The total symbol in made of 10 bits, the time per bit is 8.68uS, obtained from the baud rate and the total symbol time is 86.8uS. The clock pe-

(39)

Date: juni 08, 2018Project: arbiter_partition Page 1 of 1Revision: arbiter_partition

UART_TX:TX i_Clk

i_TX_DV

i_TX_Byte[7..0] o_TX_Done

o_TX_Serial +Add0CIN1'h0A[3..0]B[3..0]4'h1

OUT[3..0]

+Add1CIN1'h0A[2..0]B[2..0]3'h1

OUT[2..0]

<

LessThan0CIN1'h0A[2..0]B[2..0]3'h7

OUT <LessThan1CIN1'h0A[3..0]B[3..0]4'h8

OUT

Mux0SEL[2..0]DATA[7..0]OUTSelector0SEL[2..0]DATA[2..0]OUT Selector1SEL[3..0]DATA[3..0]OUT Selector2SEL[3..0]DATA[3..0]OUT

Selector3SEL[4..0]DATA[4..0]OUT Selector4SEL[4..0]DATA[4..0]OUT Selector5SEL[4..0]DATA[4..0]OUT Selector6SEL[4..0]DATA[4..0]OUT Selector7SEL[2..0]DATA[2..0]OUT

Selector8SEL[2..0]DATA[2..0]OUT Selector9SEL[2..0]DATA[2..0]OUT WideOr0

o_TX_Active~reg0 DCLKSCLR1'h0Q o_TX_Active~0 o_TX_Active~1

o_TX_Serial

o_TX_Serial~reg0 DCLKSCLR1'h0Q

r_Bit_Index[2..0] DCLKSCLR3'h0

Q

r_Bit_Index~[2..0]03'h01r_Bit_Index~[5..3]01 r_Clk_Count[3..0] DCLKSCLR4'h0

Qr_Clk_Count~[3..0]04'h01r_SM_Mainclki_TX_DVr_Bit_Index[2..0]r_Clk_Count[3..0]

s_Cleanups_Idles_TX_Data_Bitss_TX_Start_Bits_TX_Stop_Bit

r_TX_Data[7..0]DCLKENASCLR8'h0

Q

r_TX_Data~[7..0]01 r_TX_Done DCLKSCLR1'h0

Q

r_TX_Done~001'h11

r_TX_Done~1

3->D AT A[0]

89

5 1<-19]9[0TADA 0<-31]9[0TADA 2<-07]9[0TADA

1->D AT A[1]

95

02<-42]9[1TADA <-0 61]9[1TADA

4->D AT A[0]

94

9-31< A[0]94 AT <-5D 60]9[0TADA

3{1}

3{0} 3{2} 3{3}

Figure 3.9: RTL view of the serial transmitter

Physical Proximity Verification based on Physical Unclonable Functions

Physical Proximity Verification based on Physical Unclonable Functions

MARCO SPANGHERO

Physical Proximity Verification based on Physical Unclonable Functions

MARCO SPANGHERO

Abstract

Sammanfattning

Contents

List of Figures

Acknowledgements

Chapter 1 Introduction

1.0.1 Purpose and Research Scope

1.0.2 Sustainabiliy and social impact

1.0.3 Research Questions and Risks

1.0.4 Methods

1.0.5 Innovation content and Goal

1.0.6 Outline

Chapter 2 Background

2.0.1 State of the Art

2.0.2 Memory Based PUF

2.0.3 Delay Based PUF

Chapter 3

Implementation

3.1 System architecture

3.1.1 Configuration Linear Feedback Shift Register

3.1.2 Launcher and Arbiter devices

3.1.3 SwitchBox and Delay line structure

3.1.4 Shift Buffer and Serial interfaces