Deliverable 4.2 PUF enhanced smart meter hardware ... · Contract No 608224 Deliverable 4.2 PUF enhanced smart meter hardware architecture and an authentication/key management deployment

Contract No 608224

Deliverable 4.2PUF enhanced smart meter

hardware architecture and anauthentication/key management

deployment architecture (interim)

AIT Austrian Institute of Technology • Fraunhofer AISEC • The Queen’s University BelfastEnergieinstitut an der Johannes Kepler Universität Linz • EMC Information Systems International Ltd

KTH Royal Institute of Technology • Landis + Gyr • United Technologies Research CentreSWW Wunsiedel GmBH

Copyright c© SPARKS Consortium

Document Control InformationTitle Deliverable 4.2 - PUF enhanced smart meter hardware architecture and an

authentication/key management deployment architecture (interim)Editor Fraunhofer AISECAuthor(s) Chongyan Gu (QUB), Neil Hanley (QUB), Robert Hesselbarth (AISEC),

Martin Hutle (AISEC), Gavin McWilliams (QUB)Requested deadline 2015/08/31 .

.

Deliverable 4.2 Page 2 of 41


Abstract

This paper is the deliverable report on Task 4.2 “Smart meter authentication and key management schemeusing hardware PUFs”.

Recent research results have shown that the usage of a Physical Unclonable Function (PUF) in an au-thentication protocol faces some formerly unknown challenges. First, they have been shown to be lessresistant against side-channel attacks than previously assumed. Second, the so called strong PUFs, whichare natural candidates for implementing an authentication protocol, have been revealed to be vulnerableto modelling attacks through the use of machine learning methods. Third, it has been shown that existingattempts to overcome these weaknesses suffer from various problems.

Therefore, the activities in this task have focused on the search for an appropriate PUF design that is bothrobust against machine learning attacks, and fulfils the requirements regarding stability and robustness.In this paper we describe how a testbed composed of 234 Field Programmable Gate Array (FPGA)devices has been developed in order to perform a comprehensive evaluation of new and existing PUFdesigns.

This deliverable summarizes the recent developments in PUF research, and highlights the implicationfor the smart meter hardware architecture and authentication scheme. Based on the application scenario,evaluation criteria for PUF designs are defined. The design and construction of the evaluation testbedare also described. Several PUF candidate designs are outlined, along with the justification of why theywere selected. This deliverable concludes with an outlook on the evaluation activities and developmentof the PUF authentication demonstrator.



Contents

List of Figures 5

1 Introduction 7

2 Application Requirements on PUFs 8

2.1 Introduction to PUFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Using PUFs for authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 PUF Evaluation Metrics 14

3.1 Initial Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Machine learning evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Further evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 PUF Evaluation Setup 20

4.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 PUF Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 Mechanical Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 PUF candidates 31

5.1 Weak PUFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Strong PUFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6 Conclusion and Outlook 36



List of Figures

1 PUF challenge response interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 PUF key extraction generating helper data and reconstruction using the generated helperdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Controlled PUF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Target FPGA board : Digilent Basys-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Evaluation setup architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 PUF Node Architecture: USB↔ JTAG/UART↔ AXI/Microblaze↔ PUF . . . . . . . 22

7 PUF Node Vivado Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8 Message format for receiving data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

9 Message format for sending data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

10 Gateway Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

11 One of the 4 finished modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

12 Mechanical construction of single module incorporating 60 of a total of 234 Boards.Thus, the whole setup consists of 4 of these modules. . . . . . . . . . . . . . . . . . . . 29

13 Board stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

14 Ring Oscillator PUF (RO PUF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

15 Butterfly PUF architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

16 PicoPUF ID generator architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

17 Arbiter PUF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

18 Sum Ring Oscillator PUF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

19 Twisted Bistable Ring PUF (TBR PUF) architecture . . . . . . . . . . . . . . . . . . . . 35



SPARKS Security Scrutiny Committee Assessment

This deliverable has been examined by the SPARKS Security Sensitivity Committee (SSC), in accor-dance with the process outlined in Deliverable D2.1 on SPARKS Security Management. Accordingto the SPARKS Description of Work, this deliverable has a dissemination level of PU (Public). TheSPARKS SSC has found there is no security sensitive material in this deliverable, for example, thatcould be used to inform a cyber-attack by a malicious actor.



1 Introduction

This deliverable describes the evaluation of how a Physical Unclonable Function (PUF) can be used toimprove the security of smart meters, ensuring the authenticity, the integrity and the confidentiality ofthe data transmitted to the (energy-) provider. We propose enhancing the Public Key Infrastructure (PKI)interaction through the use of PUF-enabled protocols. This enhancement is based on what PUF propertiescan be inferred from our test results obtained from the large scale testbed environment described inthis document. These properties will determine what additional security is feasible, hence a number ofoptions are under consideration. For example, one option is to use the PUF credentials as a bootstrappingmechanism in order to perform PKI enrolment in the field. This eliminates the need to perform theenrolment within a secure, trusted environment prior to meter deployment, simplifying the smart meterdeployment. Another option is to securely bind PKI certificates to a particular device by linking thesecret key to the PUF response. This has additional anti-tampering benefits as the secret key is no longerstored in memory and is only generated when required. Alternatively, certificates can be generated asnormal, with the PKI providing for signing, encryption as the first of two factors for authentication.After the communication to the smart meter is established through the PKI/certificates, the second stepin this two-factor authentication scheme involves a mandatory authentication step, based on a challenge-response protocol involving the PUF. This ensures that all communication is authenticated by both thePKI and the PUF. Thus, in order to copy or impersonate the meter’s identity, an attacker would not onlyhave to get access to the securely stored private keys but also be able to clone or transplant the PUF.

The main focus in this task lies on selecting and implementing a suitable PUF to enable one or moreof these schemes. In Chapter 2 we define the requirements for the PUF. In Chapter 3 metrics for theevaluation of a PUF according to the requirements are discussed and selected. Furthermore, a unifiedevaluation setup for gathering measurement data from selected PUF-candidates is presented in Chapter4. In Chapter 5 we present a number of selected PUF-candidates.

The evaluation results and the implication for the application of PUFs in smart meters will be part of thefinal report deliverable.



2 Application Requirements on PUFs

Smart Meters (SMs) are anticipated to be relatively low cost and ubiquitous devices that will simplifythe provision of bills for both the customer and the utility provider, providing real time usage data foranalysis. However, the inherently embedded nature of the device, coupled with a strong incentive for adishonest customer to tamper with it, opens up a wide range of security issues. In order to resist cloningand modification of devices, it is proposed to use a PUF in order to provide a low-cost layer of securitywithin the existing PKI structure. A strong PUF (see Section 2.1.2) with a large challenge responsespace could provide secure device authentication, allowing the server to confirm the authenticity of boththe device itself as well as the data. If such a PUF turns out to be impractical in the given scenario, aweak PUF (see Section 2.1.3) in conjunction with a cryptographic pseudorandom function (PRF) can beused instead.

2.1 Introduction to PUFs

2.1.1 Basic Concept of a Physical Unclonable Function

A PUF can be thought of as a unique physical object which is unclonable and provides a challengeresponse interface.

The PUF as a physical object has a unique physical structure which has been created in a way that is irre-producible in order to make it not only unique, but also unclonable. Creating the physical structure of aPUF usually relies on random processes in order to obtain the physical properties that define the identityof the PUF. This randomness can be introduced either explicitly or by using intrinsic randomness. Exam-ples of explicitly introduced randomness include optical PUFs [Pap01] and coating PUFs [TjSS+]. Forthe former, some optically interacting particles are brought into a token made of an optically transparentcarrier material. For the latter, some dielectrically interacting particles are brought into a coating on thesurface of a manufactured chip. Typical examples of intrinsic randomness are the process variations thatoccur during the manufacture of electronic circuits. The randomness in the physical structure allows touse the same, identical PUF blueprint to create many PUF instances, each with its own logical identity.The physical structure of a PUF instance cannot be reproduced reliably using the same manufacturingprocess it was created with; the PUF is therefore assumed unclonable under the same conditions as itwas manufactured. Note, however, that this does not preclude the possibility of cloning a PUF using adifferent, more advanced or more expensive technology, although equally there is no evidence to suggestsuch a clone is technically feasible.

The challenge response interface of a PUF is shown in Figure 1. When a challenge is applied it is used toconfigure the PUF internally. Each challenge corresponds to a unique internal configuration of the PUF,returning a different unique response. The configuration mechanism depends on the implementationdetails of the PUF. For example, it could be the configuration of a multiplexer to select a certain signalpath. Often a bitstring is used as the challenge. In this case a PUF can be viewed as a machine memorywhere the challenge is the address and the response is the data stored at this address. However, thechallenge could also be any representation of the information needed to identify a certain configuration,e.g. a frequency, an angle or an intensity. The challenge could also be implicit, for instance when thereis only one possible configuration. The response to a challenge is evaluated from the configured physicalstructure of the PUF using a measurement mechanism. As with any physical measurement, the result isoften noisy. This means that the response returned by a given PUF will typically differ by some amountfrom previous evaluations of the same challenge. Hence, in this aspect a PUF does not behave strictly likea mathematical function. Depending on the physical implementation of the PUF, the returned responsesmay also change under different environmental conditions or over long time periods because of agingeffects.



challenge response

PUF

configure measure

Figure 1: PUF challenge response interface

2.1.2 Strong PUFs

Strong PUFs were originally envisioned to be used with a simple challenge response based proto-col [Pap01]. In order for this scheme to work, the properties of the strong PUF must follow somebasic requirements [GKST07]:

1. The challenge-response pair (CRP) mapping must be unique for every PUF instance and it mustnot be controllable during manufacture.

2. It must be impossible for an attacker to read out all possible CRPs from the PUF, such that theattacker can give the correct response to a random challenge (by look-up) with a significant prob-ability. In other words, the number of CRPs per PUF must be too large to enumerate.

3. It must be computationally hard to find a predictive model for the CRP-behavior of the PUF

These properties guarantee that a PUF is both unique and unclonable. They also allow public exchangeof CRPs without compromising security. Property 1 also ensures that it is impossible to purposely man-ufacture a second PUF instance – a clone – that is indistinguishable from an existing device. Property 2ensures it is impossible to fully read out the PUF in order to create a clone that way. Property 3 guaran-tees that knowledge of one or more CRPs from one or more PUF devices does not facilitate the predictionof CRPs with any significant probability for:

• the same PUF instance

• any other PUF instance

Without these properties, correlations between CRPs would exist allowing the creation of a model forthe prediction of responses. Such a model would require less storage capacity than for storing all theCRPs it can predict. If it is possible to create and store such a model, then the PUF could be cloned.With Property 3 the PUF cannot be cloned by modelling, even when CRPs are exchanged publicly.

2.1.3 Weak PUFs

In contrast to strong PUFs, weak PUFs provide only one CRP, or at most a very limited number of CRPs.This information can be used to derive a cryptographic key. The available information content of a weakPUF must be kept secret in order for it to be unclonable, i.e. the public transfer of CRPs is not permittedas the smaller set size could allow enumeration of all CRPs. A strong PUF can be used as a weak PUFif it meets the requirements described in section 2.1.2. These requirements have proven to be very hardto meet in an actual implementation however. The weak PUF concept allows to use dedicated weak PUFhardware primitives, providing just the amount of information required by the application at hand. Thiscan lead to a better design trade-off for specific applications, because the weak PUF hardware primitive



Extractionenroll

PUF

Reconstruction

HelperData

key

Initial PUF Responses

Noisy PUF Responses

Figure 2: PUF key extraction generating helper data and reconstruction using the generated helper data

faces relaxed requirements compared to those for strong PUFs. On the other hand, such dedicated weakPUF hardware primitives can in turn not be used as strong PUFs.

As pointed out in section 2.1.1, PUF responses are usually noisy. However, the generated or embeddedcryptographic key must be the same every time the PUF is evaluated. Thus, some form of error correctionis required. Figure 2 shows how error correction may be applied in case of key generation. The upperhalf of Figure 2 shows the enrolment of the weak PUF after its manufacture in a trusted environment.This involves the extraction of an initial PUF response. During the extraction, so called helper data isgenerated and permanently stored for use in the deployment stage to correct errors in the PUF response.After successful enrolment, the PUF is deployed in the field. The lower half of Figure 2 shows thereconstruction of the key in the field. Here, whenever the secret key is needed, the noisy PUF responseis evaluated. The helper data is now used to reconstruct the initial response of the PUF and to provide astable key.

The helper data should not leak any information about the response or the key derived from it as ideallyit should be public. Hence, it can be stored in some available non-volatile memory (NVM) which canbe external and does not need to be secure or protected. The helper data can also be publicly transmittedover an insecure channel. An overview of some helper data algorithms can be found in [DGSV15]

2.1.4 The Unclonability Problem

Even though PUFs are designed to be physically unclonable, there are ways to create logical clones.Assuming that the challenge response interface is public or CRPs are publicly exchanged, then CRPscan be gathered in an attempt to create a logical clone. When the CRP space is vast, as for strong PUFs,if there are correlations among the CRPs, machine learning can be used to create a model, such thatthe behaviour of this model is indistinguishable from that of the original physical PUF instance. Whenthe CRP space is small, as for weak PUFs, the responses can be exhaustively read out and stored in alook up table. In the weak PUF scenario the responses are supposed to remain secret for exactly thisreason. However, correlations among the responses of different strong PUF instances often allow theresponse of an unknown PUF instance to be guessed, or the complexity reduced such the a brute-forceguessing approach becomes feasible. Finally, one can raise the question of whether it is really impossibleto physically clone a PUF instance.

2.2 Using PUFs for authentication

There are two main approaches to authentication based on PUFs.

1. Using established authentication protocols based on cryptographic algorithms, where the requiredsecret/private key is provided by a PUF



2. Using a PUF directly with a PUF-specific authentication protocol

The first approach involves a weak PUF (section 2.1.3) while the second approach involves a strong PUF(section 2.1.2).

Weak PUFs promise a lightweight and Complementary Metal Oxide Semiconductor (CMOS) compatibleway to securely store cryptographic keys without the need for expensive secure on-chip NVM. Thekey material stored by the weak PUF can be used with established authentication protocols based oncryptographic algorithms. This provides strong and well understood security.

Strong PUFs promise extreme lightweight authentication without the need for cryptographic algorithmsor expensive NVM minimizing hardware and software overhead as well as cost. Despite their suggestivename, strong PUFs currently do not provide high levels of security because existing designs have beenshown to be vulnerable to machine learning attacks. These attacks create a software clone indistinguish-able in its CRP behaviour from that of the original PUF. The existence of a clone, however, breaks thePUF. Even where the strong PUFs can be cloned using machine learning, the process of cloning stillimplies some effort for the attacker. The effort depends on the used PUF and the protocol used with thePUF. Depending on the effort, the PUF can be deemed secure enough for certain applications, such asRadio-Frequency Identification (RFID) tags.

There have been efforts in the scientific community to come up with improved semiconductor basedstrong PUF hardware primitives, thereby increasing machine learning effort. However, so far none ofthe suggested designs have been able to resist machine learning attacks, or increase the effort for suchan attack to a sufficient level. Popular designs include the arbiter PUF [SD07a], the Bistable Ring PUF(BR PUF) [CCL+11b, CCL+12b] or the sum PUF [YD10]. Some general schemes have also beenproposed, such as XORing the response outputs of multiple PUF instances [Dev09], or through thecomposition of various PUFs [SMC13]. There have also been efforts to increase the security of strongPUFs by working on the underlying protocol it is used in. Initially, it has been suggested to use a simplechallenge response protocol with strong PUFs [Pap01] (section 2.2.1). This protocol marks the basis forfurther development as it provides no means for increasing security or machine learning effort and fullyrelies on the security features of the PUF hardware primitive. Since then, a variety of different ideas haveemerged that try to deal with this problem on the protocol level. PUFs with public models try to removeany advantage machine learning attacks can give to an adversary, and are discussed in section 2.2.2.Noise bifurcation, (section 2.2.3), obfuscates the CRP link for an attacker but not for the verifier. Finallywe discuss strong and weak PUF based authentication in the context of SM and Advanced MeteringInfrastructure (AMI) in section 2.2.4.

2.2.1 Naive Strong PUF Protocol

The naive strong PUF protocol was proposed by Pappu [Pap01] and relies on a PUF with the propertiesdescribed in section 2.1.2. After manufacture a number of randomly chosen CRPs are read out from eachdevice in a trusted environment and stored in a server-side database. Following that, the devices with thePUFs are deployed in the field. For authentication in the field, the server selects one of the CRPs in itsdatabase, queries the PUF with the challenge and compares the noisy PUF response with the one storedin its database. If the Hamming distance between the PUF response and the stored response is below apredefined threshold, the device has been successfully authenticated. Once a CRP has been used, it isdeleted from the database and never used again to avoid replay attacks.

Unanticipated Hardware Overhead Opposing Lightweight Objective On the device hardware sidethis protocol is lightweight in the sense that it does not require any NVM or cryptographic primitives,assuming that the used PUF implementation actually has the required properties as described in Sec-tion 2.1.2. However, until now no proposed PUF implementation possesses all these properties. Prop-



erty 3 in of section 2.1.2, which states that it must not be possible to model the PUF, is particularlyproblematic and has been shown to be especially hard to satisfy. Therefore strong PUF implementationstend to suffer from correlations between CRPs. These correlations can be used to create a model byobserving a small number of CRPs as opposed to the whole CRP space [RSS+10a]. This model is thenable to predict CRPs that have not been previously observed during the creation of the model. Duringthe authentication the CRP behaviour of the model is indistiguishable from that of the original PUF.Hence, using the model an attacker could take the PUFs identity. It is not yet clear, how much additionalhardware effort is required to build a strong PUF that fully satisfies property 3 and whether such a strongPUF could still be called lightweight.

Further Downsides With every authentication attempt, CRPs are deleted from the server’s database.This implies that the server has to store enough CRPs for the lifetime of the device. The required capacityfor storing all this data can become significant, especially when the number of devices is large, e.g. asfor mobile phones, passports, or smart meters. Furthermore, all this data has to be collected during theenrolment of the devices which may take a considerable amount of time.

2.2.2 PUFs with a Public Model

One approach to confront the modelling problem posed by machine learning attacks is to use a PUF thatcan be modelled, and to make the model public. This is part of the SIMulation Possible but Laborious(SIMPL) concept, the basis of which is to use a physical system whose CRP behaviour can indeed bemodelled or simulated. This type of PUF is also generalized under the term public PUFs [PG14]. Thekey prerequisite to make this concept work is that the physical device gives the response much faster thanit can be simulated. When the device is challenged, its response is compared to the simulated response.By requiring a time limit, only the physical device can be successfully authenticated.

Advantages Machine learning and physical attacks become irrelevant, because there is no longer asecret that is protected by the PUF. This scheme enables lightweight device authentication because itdoes not require on-chip NVM, a large database, on-chip error correction, or helper data.

Disadvantages SIMPL systems are not as yet analysed in depth. It is non clear how to prove that thereis a minimum simulation time limit for a given SIMPL system. In addition, it is not trivial to decide ona practical time limit. Communication delays (for example over internet or satellite) vary widely andcan be up to a few seconds; hence the simulation must take at least longer than this. It is hard to ensurethat the simulation will always remain slower than the physical device. Furthermore, the authenticationmust take at least as long as it takes to simulate the response and this may rule out some time criticalapplications. Alternatively it may impose a distance bound between device and verifier in order to reducecommunication delays.

2.2.3 Noise Bifurcation

The noise bifurcation scheme as suggested by Yu et al. [YVDM14] aims to increase the effort for machinelearning attacks by obfuscating the CRP link. This increases the noise seen by the attacker while theserver sees no increase in noise. A strong PUF that can be learned using a one time interface is used.Yu et al. suggested to use an XOR arbiter PUF, where the outputs of multiple arbiter PUF instancesare XORed together to a single response bit. However, the suggested scheme is not limited to this PUFarchitecture. During enrolment a model is obtained in a trusted environment using the one time interface,which is then permanently disabled. The model is stored on a server, and during authentication the server



challenges the PUF. The PUF generates a series of responses, which are divided into blocks of lengthd. A True Random Number Generator (TRNG) is used to randomly select one response bit out of eachblock. Only these randomly selected response bits are sent back to the server. The server can generateall of the responses using the stored model. With this knowledge it can determine the blocks with allidentical response bits and compare the decimated response sent back from the PUF with the expectedresponse.

Advantages For noise bifurcation no cryptographic primitives are needed. Also, the server only has tostore a model of the PUF which requires much less storage capacity compared to a list of CRPs. Usingthe model, the number of possible authentications is not limited as opposed to using a list of CRPs. Therandom decimation of the response bits obfuscates the CRP link and increases the effort for machinelearning attacks.

Disadvantages The decimation requires a TRNG which can pose quite a significant hardware overheadand is not trivial to implement. Due to the decimation, the required number of CRPs for an authenticationincreases drastically. The overhead increases exponentially with the block length d. Hence, only smallblock lengths d up to around 5 are practical. This means that the used PUF must exhibit a certainlevel of machine learning resistance so that the increased resistance provided by the noise bifurcationprotocol, but limited by the protocol overhead, is enough to reach the security requirements for the givenapplication. The required level of resistance is currently not well studied yet. Yu et al. claim that theirsuggested XOR arbiter PUF primitive is resistant enough. However, G. Becker claims that XOR arbiterPUFs can be learned very easily [Bec15].

2.2.4 Conclusions

In order to resist cloning and modification of smart meter devices, it is proposed to use a PUF. A StrongPUF with a large challenge response space could provide for secure device authentication. The cur-rent lack of strong PUF hardware primitives that are resistant against machine learning attacks, makesit hard to find a protocol which provides a sufficiently high security level for the advanced meteringinfrastructure.

This problem can be addressed by either finding better strong PUF hardware primitives, or by usingweak PUFs with cryptographic algorithms. Therefore, the activities in this task focus on the search foran appropriate PUF design that is robust against machine learning attacks and fulfills the requirements onstability and robustness. For this a testbed is developed which is composed of 234 Field ProgrammableGate Array (FPGA) devices, in order to perform a comprehensive evaluation of existing and new PUFdesigns. In addition, potential PUF candiates are identified and the evaluation criteria for the study aredefined. The best performing candidate will be integrated into the smart meter demonstrator platform.



Figure 3: Controlled PUF

3 PUF Evaluation Metrics

To evaluate the suitability of a PUF design with regards to its implementation in the context of a smartmeter scenario (or otherwise), a framework to allow for the testing and fair comparison of different PUFshas been implemented. We believe this is the largest evaluation of FPGA based PUFs in the academicliterature to date. The evaluation over Npuf = 234 distinct FPGAs1 lends additional significance to ourresults.

When implementing a PUF in a Hardware Security Module (HSM) or similar, the likelihood is that itwill be used in a controlled manner as suggested by Gassend et al. [GCvDD02a], as shown in Figure 3.However, the performance and analysis of error correcting codes and one-way functions are outside thescope of this study. However, the more stable, random, unique, etc., the output of the PUF response, themore secure the system is as a whole. Similarly should the output of the PUF be used for key generationor some other scenario where errors are not tolerated, the more reliable and repeatable the output of thePUF module itself, then the simpler (hence physically smaller) the error correction circuitry required.Hence we focus our evaluation solely on the output of the PUF itself.

A number of different metrics are now outlined which will be used in order to quantify the qualityof a given PUF design. While there a number of papers in the literature suggesting how to performcomparisons, e.g. [HYKS10, Mae13, MCMS10], the following are largely based on the work of Maitiet al. [MGS11] as their analysis focuses solely on the bit-string output of the PUF response. Furtherpotential metrics are examined in Section 3.3, these require further study however as there are potentialpitfalls in attempting to use them in a fair evaluation framework, which are also outlined.

3.1 Initial Evaluation

The evaluation metrics can be neatly divided into response and implementation categories. To be consid-ered for further evaluation, a PUF needs to perform well in the response categories, and while efficiencyin the implementation aspects is desirable, there will be cases where performance or area is not an issue.

Given a PUF instance Φi, applying an input challenge c = {0, 1}nchal ∈ C returns a response r ={0, 1}nresp ∈ R, such that rj = Φi (cj). Unless otherwise specified, it is assumed that nchal = nresp =n2. In order to evaluate the CRP set, for each of the Npuf FPGAs containing a PUF instance, Nchal

distinct challenges are applied, with each challenge repeated Nmeas times, giving a total CRP dataset1To the best of our knowledge, the previous largest study contained Npuf = 125 Spartan-3E FPGAs [MCMS10], however

the authors only examined Ring Oscillator (RO) type PUFs2This might not always be a realistic proposition, for many PUF designs nresp might be much less than nchal.



of size N = Npuf × Nchal × Nmeas. A response ri,j,k,l then refers to the lth response bit of the kth

repeated measurement of cj from Φi. For clarity, where not required one or both of the {k, l} indexes areomitted; and the indexes {i, j, k, l} will always refer to the PUF, the challenge, the measurement and thebit respectively. It must be noted that averaging over a large number of devices/challenges/measurementscan mask biases in the data hence careful consideration must be given to the comparison metrics. Thisissue is further explored in Section 3.3.

The number of CRP pairs required to successfully estimate the evaluation metrics is an important issue,too few pairs and overly optimistic, or incorrect, results will be returned. On the other hand, recordtoo many CRPs and the length of the acquisition time will be a problem. To determine the appropriatetrade-off, sub-sampling methods can be used to calculate the standard error (SE) of the different metricsas a function of CRP size. This is similar to that as suggested by Maiti et al. [MCMS10], and will allowus to determine to minimum number of CRP pairs required to accurately estimate the evaluation metrics.

3.1.1 PUF Response

The Probability Mass Function (PMF) of the following metrics form the basis of our PUF responseanalysis, with the empirical mean, µ̂, and standard deviation, σ̂, also given. Box-plots will be used inthe evaluation of the test results in order to provide a concise comparison between the various evaluatedPUF architectures. Note that the metrics we present here are how we plan to provide a fair comparisonbetween the various PUF constructions, and don’t necessarily directly correspond with those presentedin Section 5. The selected designs were chosen based on the results reported in each of their originalpublications. The methods use to calculate these results varies, hence a unified and consistent comparisonframework is required.

Reliability The reliability of a PUF, also known as the intra-chip distance, is a measure of how re-peatable a PUF response is. Note that the reliability can be easily increased through simple post-processing methods such as majority voting, however here we are only concerned with the rawPUF output as those post-processing methods can be applied to all PUF types. The reliability ismeasured by sending ci,j to the PUF Nmeas times and calculating the Hamming Distance (HD)between each pair of ri,j,k. The empirically estimated mean and standard deviation are given inEquation 1 and Equation 2 respectively, with µ̂iintra the empirical mean for Φi. Ideally, there isno error and µ̂intra = 0, but in reality the PMF of the HD between each pair can be viewed as abinomial distribution, which can be approximated as a Gaussian with N (µ̂intra, σ̂intra).

µ̂intra =2

N × (Nmeas − 1)·Npuf∑i=1

Nchal∑j=1

Nmeas−1∑k=1

Nmeas∑k′=k+1

HD(ri,j,k, ri,j,k′

)n

(1)

σ̂intra =

√√√√√ 2

N × (Nmeas − 1)·Npuf∑i=1

Nchal∑j=1

Nmeas−1∑k=1

Nmeas∑k′=k+1

(HD

(ri,j,k, ri,j,k′

)− µ̂iintra

)2 (2)

Uniqueness This is also known as the inter-chip distance, and represents how well Φ distinguishesbetween theNpuf different devices in the set. The HD between the responses of the same challengeon different devices is used to determine on average how many bits are different. Ideally, this valuewill be close to 0.5, and plotting the PMF of the HD gives a clear indication of the uniqueness. Notethat the optimisation of the uniqueness and reliability can be a conflicting problem (i.e. improvingone deteriorates the other), and a trade-off between them might be required.



µ̂inter =2

N × (Npuf − 1)·Npuf−1∑i=1

Npuf∑i′=i+1

Nchal∑j=1

Nmeas∑k=1

HD(ri,j,k, ri′,j,k

)n

(3)

σ̂inter =

√√√√√ 2

N × (Npuf − 1)·Npuf−1∑i=1

Npuf∑i′=i+1

Nchal∑j=1

Nmeas∑k=1

(HD

(ri,j,k, ri′,j,k

)− µ̂inter

)2 (4)

Uniformity The uniformity of each response is also important, as the number of 1’s and 0’s returnedfor each challenge should be approximately equal to ensure an adversary can never guess withPr > 50% what a given bit is going to be. Note the Hamming Weight (HW) is used here ratherthan the HD.

µ̂uni =1

N·Npuf∑i=1

Nchal∑j=1

Nmeas∑k=1

HW (ri,j,k)

n(5)

σ̂uni =

√√√√√ 1

N·Npuf∑i=1

Nchal∑j=1

Nmeas∑k=1

(HW (ri,j,k)− µ̂uni)2 (6)

Bit-Aliasing It is also important to individually examine distinct bit responses across PUF implementa-tions, to ensure that each individual bit is equally likely to be 1 or 0. Note that {µ̂alias, σ̂alias} arevector rather than scalar metrics, and that µ̂uni =

∑nl=1 µ̂

lalias .

µ̂lalias =1

N·Npuf∑i=1

Nchal∑j=1

Nmeas∑k=1

ri,j,k,l (7)

σ̂lalias =

√√√√√ 1

N·Npuf∑i=1

Nchal∑j=1

Nmeas∑k=1

(ri,j,k,l − µ̂lalias

)2 (8)

3.1.2 PUF Implementation

Chip-Area As we are performing the evaluation on Xilinx FPGAs, the area results will be reported interms of Configurable Logic Block (CLB) components → slices, Look-Up Tables (LUTs), flip-flops, Block-Ram, Digital Signal Processing (DSP) blocks, etc. It is not enough to simply reportslice or LUT/flip-flop utilisation as there may be placement restrictions preventing the use of ad-jacent components. Any such placement and routing specifications will also be noted.

Latency The latency of the PUF is defined as the number of clock cycles required from when the inputchallenge is applied and the PUF run command set (see Section 4.2.4), to when the output responseis ready. Arbiter type PUFs [GLC+04] often have a latency of only a single clock cycle, while RObased designs can require many more [SD07b].

3.2 Machine learning evaluation

Apart from the evaluation metrics above, a further metric is how well CRP behaviour can be extrapolatedusing machine learning techniques. This metric is only important in a strong PUF scenario. When



using weak PUFs, there are only a few CRPs or even just one CRP involved. If an attacker manages togain access to them, the attack is successful. This is in distinction to a strong PUF scenario, where anattacker is not able to read out all possible CRPs, even if given unlimited access to the device. In orderto perform a successful attack, the attacker needs to be able to be able to predict the remaining CRPs bybuilding a mathematical model from the subset that was already measured. This subset could be obtainedeither through directly challenging the PUF, or by observing authentication communications. The factthat PUFs are inherently noisy also helps an attacker, because a potential verifier may see erroneousresponses as noise by a potential verifier as long as the error ratio of the attacker approximately matchesthe noise of the PUF instance.

The susceptibility of strong PUF primitives to modelling and machine learning attacks was realised fromthe earliest designs, with linear classifiers and Support Vector Machines (SVMs) used to build a modelof a PUF given a CRP set [GCvDD02b, LLG+05]. A more recent an in-depth overview can be found in[RSS+10b]. Finding models for a certain PUF family via machine learning algorithms yields an upperbound for the complexity of their CRP behaviour. Apart from experimentally determining such an upperbound by trying out suitable models, there is also the possibility to proving such a bound in a formal way.An example of this is the work of Ganji et. al. [GTS15]. There, the authors were able to prove that theCRP behaviour of the Arbiter PUF family (including derived variants like Feed-Forward Arbiter or XORArbiter) is learnable with polynomial instead of exponential complexity using probably approximatelycorrect (PAC) learning. Additionally, Becker [Bec15] showed experimentally, that XOR Arbiter PUFscan be practically modelled with an adapted evolution strategy (ES) algorithm. This recent work hintsat a limit of complexity being achievable by using current electrical PUF designs and hence that currentdesigns do not fulfil the definition of a strong PUF. This scenario is also backed by an analysis of currentPUF designs in [DGSV14, DGPV14] where the authors also propose a fallback construction using aweak PUF.

Machine learning approaches can still be used in the evaluation of weak PUFs in such a construction.Here, the emphasis is not put on the predictability of challenge response pairs, but rather in findingcorrelations between PUF instances or revealing patterns of common behaviours between instances.

A complication in performing machine learning based analysis is that the same approach cannot be usedfor all PUF designs. Aside from the various different algorithms which can be used, how the problemis framed will also greatly affect the resultant security analysis. For example, the straightforward (andoften quite effective) way to build a model for an arbiter type design is by viewing it as a linear additivesum of delays, the same approach cannot be taken for RO type PUFs. This affects both the algorithmselection and input parameters, hence a fair comparative analysis is non-trivial.

3.3 Further evaluation

The metrics outlined above in Section 3.1 and Section 3.2 give an empirical overview as to the security ofa PUF, and are widely utilised in the literature. However a number of further questions such as entropyand CRP space have also been suggested and must be examined prior to utilising a PUF in a securitymodule. There is currently no clear consensus as to the best way to evaluate these parameters and furtherstudy in the area is required.

Other Metrics There have been a number of other metrics suggested instead of, or in conjunction with,those previously outlined. For example the PMF of the coefficient of variation σ̂i

intra

µ̂iintraof each

Φi is used in [MCMS10], while the Q-test and Kolmogorov–Smirnov (KS) test are proposed in[KMN+10]. The work by Maiti et al. [MGS11] on which we based the initial evaluation metrics,also define tests for steadiness, diffuseness and probability of misidentification. However we feelother metrics, such as the entropy, as outlined below are better suited to the task.



Environmental Conditions The performance of the PUF in varying environmental conditions is impor-tant, particularly where it is targeted at embedded applications. Tests while varying the ambienttemperature and voltage supply should be carried out. Alternatively, exceeding the recommendedoperating range of the device where possible as an adversary could also have this capability. Thereare, however, a number of practical issues with regards the large scale characterisation of varyingenvironmental conditions, not least the physical setup. It is envisioned that a single gateway con-taining a subset of Nenv ≈ 60 FPGAs could be used to perform these tests, as the modular natureof the FPGA array allows the gateways to be used individually.

CRP Space/Complexity/Entropy While many PUF designs aim to have an exponential CRP space asa function of n, the reality is that usually this is somewhat less with many designs displaying poly-nomial or even linear complexity. The size of the CRP space is closely related to the complexityof the PUF and how much entropy it contains. Accurate estimation of the entropy is a non-trivialproblem, and recent works look to link the min-entropy of a PUF with its susceptibility to machinelearning attacks [AMS+11, YMSD11]. Another interesting approach is through the use of theContext Tree Weighting (CTW) compression algorithm in order to estimate an upper bound onthe PUF entropy [IjSS+06, SvdL12], while in [vdBSvdL13] an approach is taken that uses MutualInformation Analysis (MIA) in order to estimate the entropy. Hence further study is required intothe method that best represents the complexity of a PUF.

Randomness Testing Closely related to the concept of entropy, is the notion of randomness testingfor the PUF responses. There are a number of defined tests to determine if a bit string is ran-dom [KS11, Mar95, RSN+01], however these are designed for long Random Number Generators(RNGs) output sequences rather than the fixed length PUF response. For example, while someof the specified tests in [RSN+01] can be utilised with short bit-lengths, it is unclear as to theirbenefits with regards to determining how random a PUF response is. Note also that these testsonly take into account the PUF output, hence cannot give an indication if there is a relationshipbetween the input challenge and the response.

Tamper-proofing It is an oft cited property of a PUF regardless of the design or target implementationplatform that it is tamperproof. While this could be a reasonable assumption for ApplicationSpecific Integrated Circuit (ASIC) based designs that are tightly coupled with protective meshlayers, the situation is much less clear for FPGA devices. Recent research [TDF+14] showed howphotonic emission analysis could be used to accurately measure individual delays in an arbiterbased PUF. Hence the assertion that a PUF is tamper-proof must be backed up with experimentaldata.

Differential & Linear Analysis An evaluation method based on traditional cryptanalysis methods forblock and stream ciphers is presented in [YTST14], where the authors examine the responses fromrelated challenges, where related challenges are such that HD (ci,j , ci,j+1) ≤ δ for some smallδ. The purpose is to examine if there is any relationship between the input and output strings.Performing their analysis on Bistable Ring (BR)-PUFs, they showed that responses are often equalfor related challenges, and how a small few PUF components can have a disproportionate effecton the response as a whole. This has interesting practical applications with regards the enrolmentstage of a PUF, possibly requiring challenges to be generated with minimum HDs.

ROC Curves In [Mae13, Chap. 5], Receiver Operating Characteristic (ROC) curves are used to examinethe trade-off between the False Acceptance Rate (FAR) and False Rejection Rate (FRR) whenselecting the threshold to use to determine if ri,j is a result of computing Φi (ci,j) or not. It nicelyillustrates the relationship between more secure PUFs and more robust PUFs. Note that this ismore of use for PUFs to be used in CRP protocols rather than key generation, in which case thereis a much tighter bound on the errors which can be tolerated.



Side-Channel Leakage Recent work [BK14, MHH+13, MSSS11, RXS+14] has begun to examineif side-channel leakage such as timing [Koc96], power [KJJ99] or electromagnetic emanations[QS01] can be used to determine some information about a PUF. Note that Side-Channel Anal-ysiss (SCAs) can be applied to all aspects of a PUF implementation including any pre- or post-processing. Interesting attacks have included combing both traditional modelling attacks withauxilary side-channel information [MRMK13]. Similar to testing environmental conditions, thisis difficult to do on a large scale, however weaknesses found in few or just one device will likelybe applicable to the set as a whole.



Figure 4: Target FPGA board : Digilent Basys-3

Host Gateway 1

...Gateway G

PUF Nodes1 . . . P

...PUF Nodes

((G− 1)× P ) + 1 . . . G× P

TCPSSH

UART& JTAG

overUSB

SSHNetwork /

Internet

Figure 5: Evaluation setup architecture

4 PUF Evaluation Setup

While in Section 3 we focused on the metrics to use for the evaluation of a suitable PUF design withregards to its implementation in the context of a SM scenario, in this section we describe the setupused to acquire the measurement data required for this evaluation. We use the Digilent Basys-3 FPGAboard as shown in Figure 4 as hardware implementation platform for the PUF Under Test (PUT). UsingNpuf=234 of these boards allows us to implement 234 individual instances of the PUT. The setup al-lows to gather responses from each instance of the PUT. The responses gathered from all instances arecombined for the evaluation.

The evaluation setup is built up from modules of 60 PUF Nodes which connect via network to a Host.This number of PUF Nodes limits the physical size and weight of the modules to a manageable amount.Also the network connection allows to liberally choose the physical location of the modules, independantfrom the Host’s physical location. The modules are designed to fit into a climate chamber available atFraunhofer AISEC, to enable measurements at different temperatures.

First, we describe the top-level architecture of the evaluation setup in Section 4.1. Then, we give adetailed description of the different entities in the top-level architecture in the following Sections 4.2 and4.3. Finally, we describe the mechanical construction of the setup in Section 4.4.

4.1 Architecture Overview

The top-level architecture of the evaluation setup is shown in Figure 5. It is a tree structure with threelevels (Host, Gateway, PUF Node). The instances of the PUTs are called PUF Nodes and are on thelowest level of the tree. They are shown on the right of Figure 5. They are controlled by the Host (shown



on the left of Figure 5), which is on the highest level of the tree. The PUF Nodes send their responsesback to the Host, where they are stored for analysis. The Host accesses the PUF Nodes via Gateways,which are shown in the middle of Figure 5. The task of the Gateways is to translate the communicationbetween the Host and the PUF Nodes from Transmission Control Protocol (TCP) (Host side) to UniversalSerial Bus (USB) (PUF Node side) and to configure the PUF Nodes on request of the Host.

The PUF Nodes are implemented using the Basys-3 FPGA board. The Gateways are implemented onthe Raspberry Pi embedded computer running the GNU/Linux Raspbian operating system. The Host isimplemented on a server machine running the GNU/Linux Debian operating system. For more detailson the implementations, please refer to the corresponding subsections below.

Each Gateway connects to up to P = 60 PUF Nodes. This maximum number of PUF Nodes per Gatewayis motivated by limitations in the practicality of the mechanical assembly of the boards as well as by themaximum number of clients for a single USB host, which is 127. Each Gateway has one USB host. Forreasons, that will be discussed in Section 4.2, each PUF Node has two USB clients. This means, that120 USB clients are connected to the one USB host of a Gateway. Hence, 60 PUF Nodes connectedto a single Gateway is an efficient use of the available resources while leaving a small margin. ThePUF Nodes are configured and controlled via their USB connection. Thus, any number of PUF Nodeslarger than 63 requires at least a second USB host. This is one of the reasons, why the PUF Nodesare not connected directly to the Host via USB but via the Gateways, as it would require the Host toprovide multiple USB hosts. The Gateways and the Host are connected the Local Area Network (LAN)via Ethernet. Thus, there is no practical limitation to the total number of connected Gateways and thephysical distance between the Host and the Gateways or the PUF Nodes. This is advantageous for theclimate chamber tests, because its location is in a different part of the building than the storage location ofthe PUF Nodes. Our architecture allows to move some of the PUF Nodes, together with their Gateway,into the climate chamber, while the others remain connected and available to the Host.

The number of required Gateways G depends on the total number of PUF Nodes Npuf . We target a totalof Npuf = 234 PUF Nodes, which means that G = 4 Gateways are required.

In order to use the evaluation setup, the users connects to the Host via Secure Shell (SSH). There, they canrun scripts in order to gather challenge-response data from the PUF Nodes. The setup allows multipleusers to access the setup simultaneously. The users can lock the individual PUF Nodes they need forexclusive access, preventing other users from interfering with their measurements. Also, the host allowsthe users to analyse their measurement data, reducing the need to copy large amounts of data over thenetwork.

4.2 PUF Node

The PUF Node is a hardware design implemented on the Basys-3 boards. It instantiates the PUT, achallenge generator and a universal asynchronous receiver/transmitter (UART) all controlled by a Xil-inx Microblaze processor, for the communication with the Gateway which forwards all communicationdirectly from and to the Host. The overall architecture is shown in Figure 6, with the block diagram gen-erated by the Xilinx Vivado toolset including additional clocking and reset modules shown in Figure 7.3

The Xilinx MicroBlaze soft processor core on every PUF Node runs at 100 MHz and with 128 kB of localmemory. An AMBA AXI bus interface [ARM11] is used to connect the master MicroBlaze componentwith UART, PUT and Pseudo Random Number Generator (PRNG) (to generate random challenges lo-cally) slave peripherals. The use of the MicroBlaze processor gives considerable flexibility with regardsto the design and testing of the different PUF cores. For example, the design is such that challenges can

3The proposed Pseudo Random Number Generator (PRNG) peripheral is not shown in this diagram



MicroblazeProcessorUART

PUFUnder Test

ChallengeGenerator

Memory

AXI

LMB

FPGAUSB to

UART + JTAGbridge(FTDI) UART

JTAGPUF NodeBasys 3

USBGateway

Figure 6: PUF Node Architecture: USB↔ JTAG/UART↔ AXI/Microblaze↔ PUF

uart

axi_uartlite_0

AXI Uartlite

S_AXIUART

s_axi_aclk

s_axi_aresetninterrupt

clk

microblaze_0_axi_periph

AXI Interconnect

S00_AXI

M00_AXI

M01_AXI

M02_AXI

ACLK

ARESETN

S00_ACLK

S00_ARESETN

M00_ACLK

M00_ARESETN

M01_ACLK

M01_ARESETN

M02_ACLK

M02_ARESETN

clk_wiz_1

Clocking Wizard

clk_in1 clk_out1

reset lockedrst_clk

axi_tbr_puf_0

axi_tbr_puf

s_axi

irq_os_axi_aclk

s_axi_aresetn

gpio_led

axi_gpio_0

AXI GPIO

S_AXIGPIO

GPIO2s_axi_aclk

s_axi_aresetn

rst_sys

gpio_sw

rst_clk_wiz_1_100M

Processor System Reset

slowest_sync_clk

ext_reset_in

aux_reset_in

mb_debug_sys_rst

dcm_locked

mb_reset

bus_struct_reset[0:0]

peripheral_reset[0:0]

interconnect_aresetn[0:0]

peripheral_aresetn[0:0]

microblaze_0

MicroBlaze

INTERRUPT DLMB

ILMB

M_AXI_DP

Clk

Reset

microblaze_0_local_memory

DLMB

ILMB

LMB_Clk

LMB_Rst

Figure 7: PUF Node Vivado Block Diagram



Figure 8: Message format for receiving data.

be either received directly from the host, or a seed can be loaded into a PRNG to reduce the communica-tion overhead of having to transmit challenges. The use of the MicroBlaze also allows for straightforwardparsing of the received commands, as well as ensuring updates to the design can be quickly applied. Theuse of the industry standard AMBA AXI bus to communicate between the different modules gives ourwork real-world relevance, and allows the selected PUF core to be directly dropped into the SM demon-strator. Similarly, extra components, or additional PUF cores, can be quickly added at a later stage ifrequired.

4.2.1 PUF Node Communication Interface

As previously mentioned, the communication between the Gateway and the PUF Node is conductedvia UART over USB through the FTDI chip on each PUF Node FPGA Board. A limited initial set ofcommands is available to the Host to communicate with the PUF Node, with further commands to beadded as required. These commands are given in Table 1. The format of these commands is given inFigure 8. The first byte contains the command. It is followed by a 2-Byte length field, which specifies thenumber of bytes of the payload. Note that the payload can be empty, e.g. if sending the RUN command.The two-byte length parameter still needs to be supplied, however.

To reduce the communications overhead, all challenges can be derived on-chip from a supplied seedusing a PRNG. For analysis, the challenges can then be reproduced on the Host. However, to test cornercases (such as all zeros or all ones), challenges can be directly set. Related challenges are also importantto investigate. These are challenges that differ from the supplied challenge in only a few bits, i.e. theHD is small. Thus, an option to automatically check all challenges within a specified HD around thesupplied challenge is also provided. The set of checked challenges forms a hamming ball. The radius ofthis hamming ball is set with the Hamming Ball parameter. For example, if it is zero, and the sourceflag is FALSE, then only a single challenge is applied to the PUF. If it is set to 1, then all challenges thathave a HD of one to the user supplied challenge are also applied, and so on4.

Communication between the MicroBlaze processor and the AXI-Slave peripherals is through memorymapped direct addressing of the slave peripherals. Each peripheral has a corresponding software APIdetailing access to these registers, however a brief outline of the register functions is detailed in thefollowing sections.

An access command for reading back data from the AXI registers of the PUF peripheral directly isprovided. This is useful for debugging purposes, and allows an easy way to access the internal values ofthe PUF design if required. The responses are returned to the Host in the format as shown in Figure 9.The first two Bytes are the length field, which specifies the number of bytes LEN of the payload. Itis followed by LEN Bytes of payload. Finally, a 2-Byte checksum is appended to ensure no data inthe current block has been corrupted. Currently it is up to the analysis software running on the Host toverify the checksums, however future versions could incorporate an online verification by the Gateway,

4For a HD greater than, 2 the number of possible challenges grows quite fast



Table 1: Host Communication Commands

Command in Hex Purpose00 run with current settings.01 set flag to select challenge source as PRNG (TRUE) or user supplied (FALSE)

(default FALSE).02 set number of independent challenges to write to PUF, note this is only used

when the challenges are being provided by the PRNG.03 set number of times to repeat each challenge.04 set PRNG seed.05 set user supplied challenge.06 set Hamming Ball radius, only applicable for user supplied challenges.07 set flag to determine if challenge is returned (TRUE) or not (FALSE) with the

responses as in Figure 9 (default FALSE).08 . . .7F reserved

80 read-back PUF peripheral register. This returns the four byte contents of theperipheral at this address. Note only the PUF address offset is required, thebase address is added by the MicroBlaze software. The data is returned in theformat of Figure 9, with the register contents replacing the challenge/responsevectors.

81 write PUF peripheral register. This sets the four byte contents of the peripheralat this address. Note only the PUF address offset is required, the base addressis added by the MicroBlaze software.

82 . . .ff reserved

Figure 9: Message format for sending data.

with any responses containing communication errors being automatically re-recorded at the end of theanalysis.

The payload contains the responses of the puf to a single challenge in repeated measurements. Thechallenge can optionally be returned with the responses. The overhead for this is small where the chal-lenge is repeated many times to investigate the reliability of the PUT and it saves the reconstruction ofthe challenge on the Host. The format of the payload, i.e. the sizes of the challenge and the responsefields, depends on the PUT. Since the Host knows the design it is uploading to the PUF Nodes, includingthe software running on the MicroBlaze processor and the PUT, it has all the information necessary tointerpret the payload correctly.

4.2.2 AXI-Slave: UART

The UART that is instantiated is the Xilinx LogiCORE IP AXI UART Lite v2.0 from the Vivado SuiteIP repository [Xil14]. This is a full duplex UART with 16-byte First In, First Out (FIFO) buffer andAXI-Lite interface. The memory map is given in Table 2, but for a full description see the specificationin [Xil14].



Address Offset in Hex Size in Bytes Purpose00 4 Receive Data FIFO04 4 Transmit Data FIFO08 4 UART Lite status registerC0 4 UART Lite control register

Table 2: UART Register Address Map

Address Offset in Hex Size in Bytes Purpose00 4 Control04 4 Status08 4 Number of Challenge Bytes0C 4 Sequence Length10 4 Iterations Since Last Reset

14 . . .1FC Reserved200 . . .2FC 256 Seed- / Start-Value300 . . .3FC 256 Generated Challenge

Table 3: Challenge Generator Register Address Map

4.2.3 AXI-Slave: Challenge Generator

The (Random) Challenge Generator should generate a reproducible, non-repeating sequence of (pseudo-random) challenges given a seed- / start-value. It must be possible to reproduce the complete sequencefrom the used seed value, and the challenge-width. This property allows to generate the same challengeslocally on the PUF Node as well as on the host. Since the challenges can be reconstructed by the host,they do not have to be sent to the FPGA explicitly. This allows to significantly reduce the communicationoverhead between the host and the FPGA. The generated sequence of challenges should be non-repeating,as this could introduce bias into the statistical analysis.

As the challenges need to be deterministic, a TRNG is neither required nor suitable. Instead a PRNGis used. There are a number of options available to create a PRNG. An Linear Feedback Shift Register(LFSR), or an LFSR based stream cipher such as Grain [HJM07] or Trivium [CP08] can be used. Theseare particularly suited to hardware implementation and are lightweight options. Alternatively as areaconstraints are not a pressing issue, the Advanced Encryption Standard (AES) running in counter-modeor a hash algorithm such as the SHA-2/3 family can be used. As we need evenly distributed numberswith a low probability of repetition, AES running in counter-mode is selected, with the least significantnumber of required bits retained as the challenge. A more specialised generator producing challengeswith specific properties can be added in parallel at a later stage should the need arise. The memorymapping addresses are given in Table 3.

4.2.4 AXI-Slave: PUF Under Test

The PUT is memory mapped via an AXI-Lite interface like the other slave peripherals. All the variousPUF cores have a common subset of commands that they respond to, however the design is flexibleenough to incorporate additional PUF-specific requirements if needed. The register addresses are givenin Table 4.

For the evaluation of a CRP of the PUF the challenge is stored in the challenge registers. When the LSBof the control register is set, then the PUF evaluates During the evaluation the LSB of the status registeris set. When the evaluation has finished, the PUF stores its response in the response registers and resets



Address Offset in Hex Size in Bytes Purpose00 4 Control04 4 Status08 4 Number of Challenge Bytes0C 4 Number of Response Bytes

10 . . .1FC Reserved200 . . .2FC 256 Challenge300 . . .3FC 256 Response

Table 4: PUF under Test Register Address Map

the LSB in the status register. The Microblaze (or any other AXI Master peripheral) should wait untilthis status bit returns low before reading back the response data from the response registers. When theresponse is read back the MicroBlaze can repeat the evaluation with the same configuration as beforeby simply setting the LSB in the control register again. Otherwise, it can store a new challenge andthen repeat the evaluation. This is minimum common instruction set for the PUF components, howeveras the Host can directly access the AXI register values, this gives great flexibility for debugging andunderstanding PUF designs.

4.3 Gateway

The Gateways reside in between the PUF Nodes and the Host. Their task is to translate and forwardthe communication between the Host and the PUF Nodes from TCP on the Host side to USB on thePUF Node side and also to configure the PUF Nodes with an FPGA configuration bitstream as requestedby the Host.

The PUF Node’s hardware design is stored in the bitstream. It depends on the PUT and the experimentto be conducted. This means that multiple bitstreams are required, and that it is not possible to providea single bitstream that could, for instance, be stored in the PUF Node’s on-board NVM (flash). Theconfiguration process requires direct access to the PUF Node via JTAG over USB. Only the Gateway hasthis direct connection, hence only the gateway can perform the actual configuration of the PUF Nodes.In order to allow the Host to control the configuration of the PUF Nodes with different bitstreams, theHost must be able to make the bitstreams available to the Gateway and then tell it which PUF Nodeto configure with which bitstream. This fine grained control over the bitstream deployment allows torun different experiments on different PUF Nodes simultaneously, making the setup more efficient andflexible.

The Gateway is implemented using a Raspberry Pi embedded computer. It runs a GNU/Linux operatingsystem (Raspbian) with a software framework specifically designed and implemented for this task. Thearchitecture of this software framework is shown in Figure 10. The arrow on the left labelled “TCP/IP”pointing towards the Host indicates the network connection between the Host and the Gateway. Thearrow on the right labelled “USB” pointing towards the PUF Nodes indicates the usb connection betweenthe Gateway and the PUF Nodes connected to it. A dedicated user called gate-keeper, indicated by theblue box, runs the software framework. It has no administration privileges. It allows remote accessvia SSH and Secure Copy (SCP) with public key authentication, as indicated by the white box labelledSSH/SCP in the top left corner. The same key pair is used for all Gateways and Host users. AuthorizedHost users are in possession of the corresponding private key. They use SCP to copy FPGA configurationbitstream files from their Host account to the Gateway. This is indicated by the arrow labelled “store”pointing towards the file shaped symbol to the right of the SSH/SCP box. The Gateway runs a Control-Server listening for TCP/IP connections on port 4800, which is indicated by the white box labelledControl-Server below the SSH/SCP box. The Host users establish a connection to the Control-Server



SSH/SCP remote access(Port 22)

Control-Server(Port 4800)

TCP/IP to USB bridge(Port > 6000)

instantiate

FPGA ConfigurationBitstream

FPGAProgrammer

(xc3sprog)

gate-keeper user

GatewayRaspberry Pi

store read

initiate programming

USBPUF Nodes

HostTCP/IP

Figure 10: Gateway Architecture

to get information from the Gateway and to initiate the programming of PUF Nodes. On request theControl-Server returns the serial numbers of all connected boards. Then the Host users can initiate theprogramming by specifying one of the configuration bitstream files, previously stored with SCP, andthe serial numbers of the PUF Nodes they want to program with the specified bitstream. For everyrequested PUF Node programming the Gateway starts an instance of the FPGA Programmer softwarexc3sprog, performing the programming of the PUF Nodes. This is indicated by the arrows labelled“read” and “initiate programming” pointing towards the white box labelled “FPGA Programmer”. Also,the Control-Server starts an instance of a TCP/IP to USB bridge used to forward/relay the communicationbetween Host and PUF Node, which is indicated by the arrow labelled “instantiate” pointing towards thewhite box labelled “TCP/IP to USB bridge” . Every bridge listens for a TCP/IP connection on a dedicatedport which is assigned to a single PUF Node. The assigned port number is the number of the lowest freeport greater than 6000. After the programming of a PUF Node was successful, the Host users can requestthe port number assigned to the PUF Node. The Host users establish a connection to every TCP/IP toUSB bridge corresponding to the PUF Nodes they programmed. Note, that a bridge accepts only oneconnection, so that there can always be just a single Host user communicating with a PUF Node.

With the establishment of the communication channels via the TCP/IP to USB bridges, the Host userscan communicate directly with their PUF Nodes. The protocol and the content of this communication iscompletely independent from the Gateway implementation and is defined exclusively by the Host usersand their PUF Node designs. This way the Host users have complete control over their designs withouthaving to touch the Gateway implementation.

4.4 Mechanical Construction

The mechanical construction of the evaluation setup is organized in following way. The whole setupis split into 5 modules. One of the fully constructed modules can be seen in Figure 11. The modulesare designed to fit into the climate chamber that is available at AISEC. The concept for a completelyconstructed module is shown in Figure 12. Each module hosts 60 FPGA-boards, 1 Raspberry Pi, 10 7-port USB hubs, a 5V 200W power supply and two terminal blocks for power distribution. The terminalblocks are two spring terminals (5 V, ground) mounted on a DIN rail. These are used to connect the hubsto the supply voltage using multiple cables on the side of the hubs, while only one cable per terminalgoes to the power supply. The power supply, terminal blocks, Raspberry Pi and hubs are mounted on aplastic groundplane as shown in Figure 12b. Note, that the 10 USB hubs are mounted on top of eachother in two stacks of 5 hubs each. This is done by using metal spacers (not shown) with one threaded



Figure 11: One of the 4 finished modules

end and one screw-type end. These can be screwed into each other through the mounting holes of thehubs. The next hub is placed on top of the spacers and fixed with either another set of spacers for anotherlayer, or a set of screws to terminate the stack. Should a second Raspberry Pi become necessary it couldbe stacked in the same way as just described, on top of the first Raspberry Pi. This has the advantage thatthe floorplan remains the same.

The 60 FPGA-boards are organized in 4 stacks of 15 boards using the same stacking technique as ex-plained above for the hubs. Two of these board stacks mounted in between two plastic planes are shownin Figure 13 looking onto the short side of the boards. The stacks are mounted on a plastic plane on thebottom-side and terminated with an identical plastic plane on the top-side. The second top plane adds tothe stability of the construction and most importantly allows to tip the stacks to the side to mount themhovering over the ground plane of the module. This can be seen in Figure 12a indicated by the bluearea. The side planes, holding the board-stacks, are mounted on the ground plane using some aluminiumprofile rails. On the bottom of the ground plane two U-shaped aluminium profiles are mounted alongthe long side. This increases the overall stability of the construction while adding very low extra cost.The ground plane is 6 mm thick. Without the U-profiles, it would have to be considerably thicker addingconsiderable extra cost.



Hub 1

Hub 2

Hub 3

Hub 4

Hub 5

Hub 6

Hub 7

Hub 8

Hub 9

Hub 10

RaspberryPi

PowerSupply

Boa

rds

1to

15

Boa

rds

16to

30

Boa

rds

31to

45

Boa

rds

46to

60

Boa

rdSt

acks

Hub

–B

oard

sU

SBC

ablin

g

Hub

–B

oard

sU

SBC

ablin

g

Cab

ling

Cab

ling

x

z

(a) Side view (x-z)

Boa

rdSt

acks

Hub

–B

oard

sU

SBC

ablin

g

Hub

–B

oard

sU

SBC

ablin

g

Cab

ling

Cab

ling

Hub

1to

5(S

tack

ed)

Hub

6to

10(S

tack

ed)

PowerSupply

TerminalBlock 1

TerminalBlock 2

RaspberryPi

x

y

(b) Top view (x-y): Ground plane floorplan

Figure 12: Mechanical construction of single module incorporating 60 of a total of 234 Boards. Thus,the whole setup consists of 4 of these modules.



Spacer

FPGA Board

PlasticPlane

x

y

Figure 13: Board stacks



Figure 14: RO PUF

5 PUF candidates

In this section we present possible candidates for implementation in a SM architecture. "Classical" PUFarchitectures, i.e. the original proposals, are also given for reference. Note that as previously mentioned,the results reported for these designs are not directly comparable due to methods and metrics being used,as well as different underlying hardware platforms.

5.1 Weak PUFs

5.1.1 Ring Oscillator PUF

Architecture The architecture of the Ring Oscillator PUF (RO PUF) is shown in Fig. 14. The RO PUFconsists of a number of ROs. A response bit is generated by measuring and comparing the frequency oftwo selected ROs. Considering the challenge to be the selection of two out of N ROs for comparison,there are

(N2

)= N ·(N−1)

2 possible comparisons. Hence, the challenge space grows with the square ofthe number of ROs. However, these are not independent as, for example, if the value returned by ROi

is greater than that of ROj , and that of ROj is greater than ROk, then it can be inferred that ROi is alsogreater than ROk giving the system less entropy than initially appears. Thus, the challenge space requiredfor a secure challenge-response applications might not be feasible for a reasonable area consumption.

Existing Results Many different variants of the basic RO PUFs architecture have been suggested. Likeall FPGA based PUFs, the routing paths must be carefully chosen in order to balance the ROs, howeverfor FPGAs the only information available is from the implementation tools which might not fully reflectthe fabrication reality. However, as noted by Maiti et al. [MS11], when using hard macros to implementthe RO, the circuits will be identical hence knowledge of the full underlying routing characteristicsisn’t required. They performed tests on a large population of 125 Xilinx Spartan-3 FPGAs on theirconfigurable RO PUF, where the configurable aspect of their PUF is the selection of paths to maximisethe frequency differences through the use of multiplexers within the RO circuit. Their experimentsshowed a average uniqueness of 47.31 % and a low number of incorrect bits over a wide temperature andsupply voltage range.



Figure 15: Butterfly PUF architecture.

5.1.2 Butterfly PUF

Architecture The butterfly PUF was introduced by Kumar et al. in [KGM+08] as a more generalequivalent of the SRAM PUF for FPGAs, as not all devices support the uninitialized SRAM startupvalues required. The butterfly PUF consists of two cross coupled latches as shown in Figure 15, withmanually routed paths in order to create as symmetrically routed paths as possible. The clock for bothlatches is always set high in order to create a combinatorial loop. To read back a response the excitesignal is set high which puts the circuit in an unstable state, when the signal is subsequently set low theoutput will randomly (but consistently) set to 1 or 0 based on manufacturing process variations.

Existing Results Experimental validation was carried out by the authors on 36 Xilinx Virtex-5 FPGAs.The experiments show a uniqueness of close to 50 %, and for reliability the HD of all measurements tothe reference response is within 6 %. Additional tests investigating the effect of temperature and clockfrequency were also carried out and the response remains relatively stable.

5.1.3 PicoPUF-ID

Architecture The architecture of a single-bit PicoPUF cell is shown in Figure 16 [GMO14]. Thisidentity generator PUF uses two matched delay paths implemented by two toggle flip-flops which arefirst reset by an synchronous CLEAR. They are then excited simultaneously on the next clock edge withthe use of a common CE. Fixed routing is used to pass each signal into a LUT based cross-coupledNAND gate which acts as an arbiter in order to determine which signal arrived first. To implement thecell on an FPGA requires just two LUTs and two flip-flops, which compactly fits into an FPGA slice.This has the benefit of ensuring all routing stays local in the SLICE and its corresponding switch matrix,rather than passing through the general interconnect. The small and independent nature of the cells alsomeans they can be placed disparately throughout the FPGA fabric in the spare logic of a design.

Existing Results Published results from the PicoPUF design show a robust response and good unique-ness properties when implemented on a Spartan-6 FPGA platform. Experimental results show an unique-ness of 48.52 %, and reliability of 92.41 % over a 25 ◦C to 70 ◦C temperature range and 10 % fluctuation



Figure 16: PicoPUF ID generator architecture.

Figure 17: Arbiter PUF.

in supply voltage. These results were obtained from a sample population size of 10 FPGAs making it aninteresting candidate for evaluation on a larger set size.

5.2 Strong PUFs

5.2.1 Arbiter PUF

Architecture The arbiter PUF was one of the first suggested architectures by Gassend et al. in [GLC+04].It is based on comparing how long it takes a signal to travel two identical paths, determined by an ar-biter at the end as shown in Figure 17. Even when the paths are layed out identically, there should be aslight mismatch due to random process variations. The multiplexor select lines are fed by the input chal-lenge and, ideally, the number of independent paths a signal can take through the circuit is exponentialin nature. However, in reality it is somewhat less than this as not all multiplexors will have the sameeffect on the output. The restricted routing options available in FPGAs also means that a straightforwardimplementation will result in heavily biased designs as the difference between the delay paths will bedetermined by the interconnect delay rather than any random process variations.

Existing Results While one of the oldest suggestions for a PUF architecture, it is still currently un-clear how to best implement the classic arbiter type PUF on an FPGA. It is suggested in [MMS09], thatit cannot be satisfactorily implemented as the delay difference due to static variation routes is an orderof magnitude higher than expected delay variation due to manufacturing variability. They are also par-



Figure 18: Sum Ring Oscillator PUF.

ticularly susceptible to modelling attacks [RSS+10a], as the switch blocks can be treated as independentcomponents in a additive linear delay model.

5.2.2 XOR-Arbiter PUF

Architecture The XOR-arbiter approach was proposed in [SD07b] in order to increase the complexityof the circuit in order to thwart modelling based attacks. The basic premise of this approach is to combinethe output of a number of arbiter circuits using an XOR gate. A number of different architectures arepossible, each with varying trade-offs. Examples include simply XORing the output of a number ofparallel arbiter circuits, or using the same arbiter circuit and deriving subsequent challenges from thebase challenge.

Existing Results The use of XOR circuits has a number of advantages such as reducing the output biasof the response, and increasing the complexity of the circuit. However as the number of XOR stagesincreases, so does the error. Modelling attacks are also still possible as shown in [RSS+13], and recentwork [Bec15] has further undermined the security of XOR-arbiter PUFs.

5.2.3 SUM Ring Oscillator PUF

Architecture The SUM RO PUF was introduced in [YD10] and is shown in Figure 18. The idea behindthis construction was to provide a much larger challenge space than the original RO PUF. Pre-determinedpairs of RO are summed together, with the challenge determining the sign of the frequency difference. Athresholding step is then used to return a single bit. This also has the effect of de-biasing the bit outputs.

Existing Results While this construction greatly increases the challenge space of the target PUF de-sign, it clearly can be viewed using a linear additive model as there is only k+ 1 independent parametersin the system [DV14], the k frequency differences and the threshold operation. While this isn’t recom-mended to be used as a secure PUF in isolation, it is a good reference for some of the other designshere.

5.2.4 Twisted Bistable Ring PUF

Architecture The Twisted Bistable Ring PUF (TBR PUF) is a PUF based on the BR PUF, first pub-lished in 2011 by Chen et al. [CCL+11a, CCL+12a], and its architecture is shown in Fig. 19.

The basic idea of the BR PUF is based on the fact that an inverter ring consisting of an even number ofinverters has two possible stable states. Similar to a static random access memory (Static Random-Acces



cell[0]

stage[0]

stage[2L− 1]

cell[1]

stage[1]

stage[2L− 2]

cell[L− 2]

stage[L− 2]

stage[L+ 1]

cell[L− 1]

stage[L− 1]

stage[L]

challenge[0] challenge[1] challenge[L− 2] challenge[L− 1]

reset

Figure 19: TBR PUF architecture

Memory (SRAM)) cell which is based on a pair of cross-coupled inverters, a ring with even number ofinverters falls into one of its two possible stable states when powered up or, more generally, when it isreleased from some unstable state. We call such kind of an inverter ring a BR.

Existing Results The TBR PUF avoids bias in the responses with the following measures. The invert-ers, implementing the stages of the BR, are always included in the BR. The challenge only changes theposition of the inverters, such that an inverter implementing an even indexed stage is always swappedwith an inverter implementing an odd indexed stage. This balances out existing differences between theaverages of odd and even indexed stage properties over all possible challenges. The balancing ensures alow bias in the TBR PUF responses and a good uniformity.

The TBR PUF shows potential for further improvement in bias and noise performance. The challengespace of the TBR PUF grows exponentially with the number of stages in its BR. It is thus a suitablecandidate for challenge-response applications.



6 Conclusion and Outlook

This deliverable motivates and describes the setup for a comprehensive evaluation of PUF designs inthe context of smart metering. The inherently embedded nature of the device, coupled with the strongincentive for a dishonest customer to tamper with and their unfettered access to it, opens up a wide rangeof security issues. PUFs could be a solution to resist against cloning and modification of devices.

Strong PUFs with a large challenge response space could provide for secure device authentication, al-lowing the server to confirm the authenticity of both the device itself as well as the data. Should sucha PUF be infeasible given available resources, a weak PUF can be used in lieu with slightly differentarchitecture and assumptions.

Recent results have shown that the usage of PUFs in an authentication protocol faces some formerlyunknown challenges. First, they have been shown to be less resistant against side-channel attacks thanpreviously assumed. Second, strong PUFs, which are natural candidates for implementing an authen-tication protocol, were shown to be vulnerable by machine learning attacks. Third, it was shown thatexisting attempts to overcome these weaknesses suffer from various problems.

Therefore, the activities in this tasks focused on the search for an appropriate PUF design that is robustagainst machine learning attacks and fulfils the requirements on stability and robustness. This deliverabledescribed the development of a testbed which is composed of 234 FPGA devices, in order to perform acomprehensive evaluation of existing and new PUF designs. In addition, potential PUF candidates wereidentified and the evaluation criteria for the study were defined.

The next iteration of this deliverable will address the experiences of the PUF evaluation, the evaluationresults, as well as the implications on the choice of the authentication protocol based on PUFs. At thecurrent stage it is an open question whether the optimal solution is based on a strong or weak PUF.

Finally, the chosen PUF design and authentication protocol will be implemented in a lab-based smartmeter demonstrator. The demonstrator will be used to show the practicality of the PUF authentication,and will serve to illustrate its robustness against various attacks.



References

[AMS+11] Frederik Armknecht, Roel Maes, Ahmad-Reza Sadeghi, François-Xavier Standaert, andChristian Wachsmann. A formalization of the security features of physical functions. In32nd IEEE Symposium on Security and Privacy, S&P 2011, 22-25 May 2011, Berkeley,California, USA, pages 397–412. IEEE Computer Society, 2011.

[ARM11] ARM. Amba axi and ace protocol specification, 2011. http://www.arm.com/products/system-ip/amba-specifications.php.

[Bec15] Georg T. Becker. The gap between promise and reality: On the insecu-rity of xor arbiter pufs. https://www.emsec.rub.de/media/crypto/veroeffentlichungen/2015/06/17/beckerChes2015.pdf, 2015.

[BK14] Georg T. Becker and Raghavan Kumar. Active and passive side-channel attacks on delaybased PUF designs. IACR Cryptology ePrint Archive, 2014:287, 2014.

[BR14] Lejla Batina and Matthew Robshaw, editors. Cryptographic Hardware and EmbeddedSystems - CHES 2014 - 16th International Workshop, Busan, South Korea, September23-26, 2014. Proceedings, volume 8731 of Lecture Notes in Computer Science. Springer,2014.

[CCL+11a] Q. Chen, G. Csaba, P. Lugli, U. Schlichtmann, and U. Rührmair. The bistable ring puf:A new architecture for strong physical unclonable functions. In IEEE Int. Symposium onHardware-Oriented Security and Trust, June 2011.

[CCL+11b] Qingqing Chen, Gyorgy Csaba, P. Lugli, U. Schlichtmann, and U. Rührmair. The bistablering puf: A new architecture for strong physical unclonable functions. In Hardware-Oriented Security and Trust (HOST), 2011 IEEE International Symposium on, pages 134–141, June 2011.

[CCL+12a] Qingqing Chen, G. Csaba, P. Lugli, U. Schlichtmann, and U. Ruhrmair. Characterizationof the bistable ring puf. In Design, Automation Test in Europe Conference Exhibition(DATE), 2012, pages 1459 –1462, march 2012.

[CCL+12b] Qingqing Chen, Gyorgy Csaba, P. Lugli, U. Schlichtmann, and U. Rührmair. Charac-terization of the bistable ring puf. In Design, Automation Test in Europe ConferenceExhibition (DATE), 2012, pages 1459–1462, March 2012.

[CP08] Christophe De Cannière and Bart Preneel. Trivium. In Matthew J. B. Robshaw andOlivier Billet, editors, New Stream Cipher Designs - The eSTREAM Finalists, volume4986 of Lecture Notes in Computer Science, pages 244–266. Springer, 2008.

[Dev09] Srini Devadas. Physical unclonable functions (pufs) and secure processors. CHES 2009Workshop on Cryptographic Hardware and Embedded Systems 2009, invited talk, 2009.

[DGPV14] Jeroen Delvaux, Dawu Gu, Roel Peeters, and Ingrid Verbauwhede. Secure lightweightentity authentication with strong pufs: Mission impossible II. IACR Cryptology ePrintArchive, 2014:977, 2014.

[DGSV14] Jeroen Delvaux, Dawu Gu, Dries Schellekens, and Ingrid Verbauwhede. Securelightweight entity authentication with strong pufs: Mission impossible? In Lejla Batinaand Matthew Robshaw, editors, Cryptographic Hardware and Embedded Systems – CHES2014, volume 8731 of Lecture Notes in Computer Science, pages 451–475. SpringerBerlin Heidelberg, 2014.


http://www.arm.com/products/system-ip/amba-specifications.php

http://www.arm.com/products/system-ip/amba-specifications.php

https://www.emsec.rub.de/media/crypto/veroeffentlichungen/2015/06/17/beckerChes2015.pdf

https://www.emsec.rub.de/media/crypto/veroeffentlichungen/2015/06/17/beckerChes2015.pdf


[DGSV15] Jeroen Delvaux, Dawu Gu, Dries Schellekens, and Ingrid Verbauwhede. Helper dataalgorithms for puf-based key generation: Overview and analysis. IEEE Trans. on CAD ofIntegrated Circuits and Systems, 34(6):889–902, 2015.

[DV14] Jereon Delvaux and Ingrid Verbauwhede. Fault injectin modelling attacks on 65 nm ar-biter and RO sum pufs via enviromental changes. IEEE Trans. on Circuits and Systems,61-I(6):1701–1713, 2014.

[GCvDD02a] Blaise Gassend, Dwaine E. Clarke, Marten van Dijk, and Srinivas Devadas. Controlledphysical random functions. In 18th Annual Computer Security Applications Conference(ACSAC 2002), 9-13 December 2002, Las Vegas, NV, USA, pages 149–160. IEEE Com-puter Society, 2002.

[GCvDD02b] Blaise Gassend, Dwaine E. Clarke, Marten van Dijk, and Srinivas Devadas. Silicon phys-ical random functions. In Vijayalakshmi Atluri, editor, Proceedings of the 9th ACM Con-ference on Computer and Communications Security, CCS 2002, Washington, DC, USA,November 18-22, 2002, pages 148–160. ACM, 2002.

[GKST07] Jorge Guajardo, SandeepS. Kumar, Geert-Jan Schrijen, and Pim Tuyls. Fpga intrinsicpufs and their use for ip protection. In Pascal Paillier and Ingrid Verbauwhede, editors,Cryptographic Hardware and Embedded Systems - CHES 2007, volume 4727 of LectureNotes in Computer Science, pages 63–80. Springer Berlin Heidelberg, 2007.

[GLC+04] Blaise Gassend, Daihyun Lim, Dwaine E. Clarke, Marten van Dijk, and Srinivas Devadas.Identification and authentication of integrated circuits. Concurrency - Practice and Expe-rience, 16(11):1077–1098, 2004.

[GMO14] Chongyan Gu, Julian P. Murphy, and Máire O’Neill. A unique and robust single sliceFPGA identification generator. In IEEE International Symposium on Circuits and Sys-temss, ISCAS 2014, Melbourne, Victoria, Australia, June 1-5, 2014, pages 1223–1226.IEEE, 2014.

[GTS15] Fatemeh Ganji, Shahin Tajik, and Jean-Pierre Seifert. PAC learning of arbiter pufs. IACRCryptology ePrint Archive, 2015:378, 2015.

[HJM07] Martin Hell, Thomas Johansson, and Willi Meier. Grain: a stream cipher for con-strained environments. Int. J. Wire. Mob. Comput., 2(1):86–93, May 2007.

[HYKS10] Yohei Hori, Takahiro Yoshida, Toshihiro Katashita, and Akashi Satoh. Quantitative andstatistical performance evaluation of arbiter physical unclonable functions on fpgas. InViktor K. Prasanna, Jürgen Becker, and René Cumplido, editors, ReConFig’10: 2010International Conference on Reconfigurable Computing and FPGAs, Cancun, QuintanaRoo, Mexico, 13-15 December 2010, Proceedings, pages 298–303. IEEE Computer Soci-ety, 2010.

[IjSS+06] Tanya Ignatenko, Geert jan Schrijen, Boris Skoric, Pim Tuyls, and Frans Willems. Esti-mating the secrecy-rate of physical unclonable functions with the context-tree weightingmethod. In In IEEE International Symposium on Information Theory, pages 499–503,2006.

[KGM+08] Sandeep S. Kumar, Jorge Guajardo, Roel Maes, Geert Jan Schrijen, and Pim Tuyls.The butterfly PUF: protecting IP on every FPGA. In Mohammad Tehranipoor and JimPlusquellic, editors, IEEE International Workshop on Hardware-Oriented Security andTrust, HOST 2008, Anaheim, CA, USA, June 9, 2008. Proceedings, pages 67–70. IEEEComputer Society, 2008.



[KJJ99] Paul C. Kocher, Joshua Jaffe, and Benjamin Jun. Differential power analysis. In Michael J.Wiener, editor, Advances in Cryptology - CRYPTO ’99, 19th Annual International Cryp-tology Conference, Santa Barbara, California, USA, August 15-19, 1999, Proceedings,volume 1666 of Lecture Notes in Computer Science, pages 388–397. Springer, 1999.

[KMN+10] Inyoung Kim, Abhranil Maiti, Leyla Nazhandali, Patrick Schaumont, Vignesh Vivekraja,and Huaiye Zhang. From statistics to circuits: Foundations for future physical unclonablefunctions. In Ahmad-Reza Sadeghi and David Naccache, editors, Towards Hardware-Intrinsic Security - Foundations and Practice, Information Security and Cryptography,pages 55–78. Springer, 2010.

[Koc96] Paul C. Kocher. Timing attacks on implementations of diffie-hellman, rsa, dss, and othersystems. In Neal Koblitz, editor, Advances in Cryptology - CRYPTO ’96, 16th AnnualInternational Cryptology Conference, Santa Barbara, California, USA, August 18-22,1996, Proceedings, volume 1109 of Lecture Notes in Computer Science, pages 104–113.Springer, 1996.

[KS11] Wolfgang Killmann and Werner Schindler. A proposal for: Functionality classes forrandom number generators, 2011.

[LLG+05] Daihyun Lim, Jae W. Lee, Blaise Gassend, G. Edward Suh, Marten van Dijk, and Srini-vas Devadas. Extracting secret keys from integrated circuits. IEEE Trans. VLSI Syst.,13(10):1200–1205, 2005.

[Mae13] Roel Maes. Physically Unclonable Functions - Constructions, Properties and Applica-tions. Springer, 2013.

[Mar95] George Marsaglia. The Marsaglia Random Number CDROM including the Diehard Bat-tery of Tests of Randomness. http://www.stat.fsu.edu/pub/diehard/, 1995.

[MCMS10] Abhranil Maiti, Jeff Casarona, Luke McHale, and Patrick Schaumont. A large scalecharacterization of RO-PUF. In Jim Plusquellic and Ken Mai, editors, HOST 2010, Pro-ceedings of the 2010 IEEE International Symposium on Hardware-Oriented Security andTrust (HOST), 13-14 June 2010, Anaheim Convention Center, California, USA, pages94–99. IEEE Computer Society, 2010.

[MGS11] Abhranil Maiti, Vikash Gunreddy, and Patrick Schaumont. A systematic method to eval-uate and compare the performance of physical unclonable functions. IACR CryptologyePrint Archive, 2011:657, 2011.

[MHH+13] Dominik Merli, Johann Heyszl, Benedikt Heinz, Dieter Schuster, Frederic Stumpf, andGeorg Sigl. Localized electromagnetic analysis of RO pufs. In 2013 IEEE InternationalSymposium on Hardware-Oriented Security and Trust, HOST 2013, Austin, TX, USA,June 2-3, 2013, pages 19–24. IEEE Computer Society, 2013.

[MMS09] Sergey Morozov, Abhranil Maiti, and Patrick Schaumont. A comparative analysis ofdelay based PUF implementations on FPGA. IACR Cryptology ePrint Archive, 2009:629,2009.

[MRMK13] Ahmed Mahmoud, Ulrich Rührmair, Mehrdad Majzoobi, and Farinaz Koushanfar. Com-bined modeling and side channel attacks on strong pufs. IACR Cryptology ePrint Archive,2013:632, 2013.

[MS11] Abhranil Maiti and Patrick Schaumont. Improved ring oscillator PUF: an fpga-friendlysecure primitive. J. Cryptology, 24(2):375–397, 2011.



[MSSS11] Dominik Merli, Dieter Schuster, Frederic Stumpf, and Georg Sigl. Side-channel analysisof pufs and fuzzy extractors. In Jonathan M. McCune, Boris Balacheff, Adrian Perrig,Ahmad-Reza Sadeghi, Angela Sasse, and Yolanta Beres, editors, Trust and TrustworthyComputing - 4th International Conference, TRUST 2011, Pittsburgh, PA, USA, June 22-24, 2011. Proceedings, volume 6740 of Lecture Notes in Computer Science, pages 33–47.Springer, 2011.

[Pap01] Ravikanth Pappu. Physical One-Way Functions. PhD thesis, Massachusetts Institute ofTechnology, 2001.

[PG14] M. Potkonjak and V. Goudar. Public physical unclonable functions. Proceedings of theIEEE, 102(8):1142–1156, Aug 2014.

[QS01] Jean-Jacques Quisquater and David Samyde. Electromagnetic analysis (EMA): mea-sures and counter-measures for smart cards. In Isabelle Attali and Thomas P. Jensen,editors, Smart Card Programming and Security, International Conference on Researchin Smart Cards, E-smart 2001, Cannes, France, September 19-21, 2001, Proceedings,volume 2140 of Lecture Notes in Computer Science, pages 200–210. Springer, 2001.

[RSN+01] Andrew Rukhin, Juan Soto, James Nechvatal, Elaine Barker, Stefan Leigh, Mark Leven-son, David Banks, Alan Heckert, James Dray, San Vo, Andrew Rukhin, Juan Soto, MilesSmid, Stefan Leigh, Mark Vangel, Alan Heckert, James Dray, and Lawrence E Bassham.A statistical test suite for random and pseudorandom number generators for cryptographicapplications, 2001.

[RSS+10a] Ulrich Rührmair, Frank Sehnke, Jan Sölter, Gideon Dror, Srinivas Devadas, and JürgenSchmidhuber. Modeling attacks on physical unclonable functions. In Proceedings ofthe 17th ACM conference on Computer and communications security, CCS ’10, pages237–249, New York, NY, USA, 2010. ACM.

[RSS+10b] Ulrich Rührmair, Frank Sehnke, Jan Sölter, Gideon Dror, Srinivas Devadas, and JürgenSchmidhuber. Modeling attacks on physical unclonable functions. In Ehab Al-Shaer,Angelos D. Keromytis, and Vitaly Shmatikov, editors, Proceedings of the 17th ACM Con-ference on Computer and Communications Security, CCS 2010, Chicago, Illinois, USA,October 4-8, 2010, pages 237–249. ACM, 2010.

[RSS+13] Ulrich Rührmair, Jan Sölter, Frank Sehnke, Xiaolin Xu, Ahmed Mahmoud, Vera Stoy-anova, Gideon Dror, Jürgen Schmidhuber, Wayne Burleson, and Srinivas Devadas. PUFmodeling attacks on simulated and silicon data. IACR Cryptology ePrint Archive,2013:112, 2013.

[RXS+14] Ulrich Rührmair, Xiaolin Xu, Jan Sölter, Ahmed Mahmoud, Mehrdad Majzoobi, FarinazKoushanfar, and Wayne P. Burleson. Efficient power and timing side channels for physicalunclonable functions. In Batina and Robshaw [BR14], pages 476–492.

[SD07a] G. Edward Suh and Srinivas Devadas. Physical unclonable functions for device authenti-cation and secret key generation. In Proceedings of the 44th Annual Design AutomationConference, DAC ’07, pages 9–14, New York, NY, USA, 2007. ACM.

[SD07b] G. Edward Suh and Srinivas Devadas. Physical unclonable functions for device authenti-cation and secret key generation. In Proceedings of the 44th Design Automation Confer-ence, DAC 2007, San Diego, CA, USA, June 4-8, 2007, pages 9–14. IEEE, 2007.



[SMC13] Durga Prasad Sahoo, Debdeep Mukhopadhyay, and Rajat Subhra Chakraborty. Formaldesign of composite physically unclonable function. PROOFS Workshop on SecurityProofs for Embedded Systems, 2013.

[SvdL12] Geert Jan Schrijen and Vincent van der Leest. Comparative analysis of SRAM memoriesused as PUF primitives. In Wolfgang Rosenstiel and Lothar Thiele, editors, 2012 Design,Automation & Test in Europe Conference & Exhibition, DATE 2012, Dresden, Germany,March 12-16, 2012, pages 1319–1324. IEEE, 2012.

[TDF+14] Shahin Tajik, Enrico Dietz, Sven Frohmann, Jean-Pierre Seifert, Dmitry Nedospasov,Clemens Helfmeier, Christian Boit, and Helmar Dittrich. Physical characterization ofarbiter pufs. In Batina and Robshaw [BR14], pages 493–509.

[TjSS+] Pim Tuyls, Geert jan Schrijen, Boris Skoric, Jan Van Geloven, Nynke Verhaegh, and RobWolters. Read-proof hardware from protective coatings. In In Cryptographic Hardwareand Embedded Systems — CHES 2006.

[vdBSvdL13] Robbert van den Berg, Boris Skoric, and Vincent van der Leest. Bias-based modelingand entropy analysis of pufs. Cryptology ePrint Archive, Report 2013/656, 2013. http://eprint.iacr.org/.

[Xil14] Xilinx. Logicore ip axi uart lite v2.0 product guide - pg142, 2014. http://www.xilinx.com.

[YD10] Meng-Day (Mandel) Yu and Srinivas Devadas. Recombination of physicalunclonable functions. http://people.csail.mit.edu/devadas/pubs/gomactech2010.pdf, 2010.

[YMSD11] Meng-Day (Mandel) Yu, David M’Raïhi, Richard Sowell, and Srinivas Devadas.Lightweight and secure PUF key storage using limits of machine learning. In Bart Preneeland Tsuyoshi Takagi, editors, Cryptographic Hardware and Embedded Systems - CHES2011 - 13th International Workshop, Nara, Japan, September 28 - October 1, 2011. Pro-ceedings, volume 6917 of Lecture Notes in Computer Science, pages 358–373. Springer,2011.

[YTST14] Dai Yamamoto, Masahiko Takenaka, Kazuo Sakiyama, and Naoya Torii. Security evalua-tion of bistable ring pufs on fpgas using differential and linear analysis. In Maria Ganzha,Leszek A. Maciaszek, and Marcin Paprzycki, editors, Proceedings of the 2014 FederatedConference on Computer Science and Information Systems, Warsaw, Poland, September7-10, 2014., pages 911–918, 2014.

[YVDM14] Meng-Day Yu, I. Verbauwhede, S. Devadas, and D. M’Raïhi. A noise bifurcation archi-tecture for linear additive physical functions. In Hardware-Oriented Security and Trust(HOST), 2014 IEEE International Symposium on, pages 124–129, May 2014.


http://eprint.iacr.org/

http://eprint.iacr.org/

http://www.xilinx.com

http://www.xilinx.com

http://people.csail.mit.edu/devadas/pubs/gomactech2010.pdf

http://people.csail.mit.edu/devadas/pubs/gomactech2010.pdf

Documents

Deliverable 4.2 PUF enhanced smart meter hardware ... · Contract No 608224 Deliverable 4.2 PUF enhanced smart meter hardware architecture and an authentication/key management deployment