Final Report on Prototype Testing

(1)

.

D1.2: Final Report on Prototype Testing

.

Project number: 835932

Project acronym: CODES

Project title: Algorithmic extraction and error-correction codes for lightweight security anchors with re-configurable PUFs

Start date of the project: 01.10.2012

Duration: 24 months

.

Deliverable type: Report

Deliverable reference number: 835932/ D1.2

Deliverable title: Final Report on Prototype Testing

WP contributing to deliverable: WP01

Due date: 30.09.2014

Actual submission date: 01.07.2014

.

Responsible organisation: TEC

Authors: Ingrid Schaumüller-Bichl, Andrea Kolberger, Martin Deutschmann, Michael Höberl, Christina Petschnigg, Clemens Heuberger, Michela Mazzoli, Winfried Müller, Benjamin Hackl

Abstract: This report covers a description of the per-formed functional tests of the demonstrators and a summary of the achieved results. It in-cludes testing of the implemented Error Correct-ing Codes (ECC) as well as a set of evaluation scenarios for the two demonstrators. Parts of the evaluations are depicted as screen-shots in the appendix of the document.

Keywords: Physically Unclonable Function, Prototype, Testing, ECC

.

Dissemination level: PU

Revision: 1.0

(2)

.

List of Abbreviations

ASIC Application Specific Integrated Circuit

BCH Bose-Chaudhuri-Hocquenghem (error-correcting codes)

CRP Challenge Response Pair

FE Fuzzy Extractor

FPGA Field-Programmable Gate Array

HD Helper Data

MAC Message Authentication Code

PUF Physically Unclonable Function

RM Reed-Muller (error-correcting codes)

RS Reed-Solomon (error-correcting codes)

(4)

List of Figures

1 Sequence diagram of Demonstrator I applying MACs to ensure integrity and

au-thenticity of transmitted data. . . 15

2 Screenshot of MA-TC1 . . . 22 3 Screenshot of MA-TC2 . . . 23 4 Screenshot of MA-TC3 . . . 24 5 Screenshot of RA-TC1 . . . 25 6 Screenshot of RA-TC2 . . . 26 7 Screenshot of FD-TC1 . . . 27 8 Screenshot of FD-TC2 . . . 28 9 Screenshot of ER-TC1 . . . 29 10 Screenshot of ER-TC2 . . . 30

11 LCD Display after ER-TC2 was successfully executed . . . 30

12 Screenshot of BS-TC1 . . . 31

13 LCD Display after BS-TC1 was successfully executed . . . 31

(5)

1 Introduction

1.1 Purpose

During the first phase of WP1, weak spots regarding security, complexity and reliability of PUF security modules have been analysed. The outcome was the SWOT Analysis, delivered inD1.1 - SWOT Analysis of existing PUF security modules [1]. The second phase of this work package has focused on the system testing of the developed demonstrators from WP3 [4]. The aim of the system tests is on the one hand to verify that the system behaves as previously defined and on the other hand to ensure that the system reacts on faults as foreseen.

1.2 Scope

The scope of this document is limited to the various test scenarios that were carried out on the two demonstrators. Thus, the setup, architecture, components and implementation are covered within deliverableD3.1 - Hybrid FPGA ASIC Prototype [4].

For each demonstrator test cases have been defined and carried out. Furthermore, for the imple-mented error-correcting codes dedicated test scenarios were carried out.

1.3 Outline

The structure of this document is as follows: Section 2 deals with the testing of the implemented error-correcting codes. Since the ECCs are a core component of the demonstrators, it is necessary to ensure that they are capable of correcting the noisy PUF responses. Section 3 is split into four parts. The first three parts cover different test scenarios on the Demonstrator I: Mutual Authentication that have been performed. The fourth part gives an overview of further test scenarios. Testing of Demonstrator II: Key Generation is carried out within Section 4. This section is split up into three parts. The first two parts are covering the two test scenarios that have been carried out. The third part gives an overview of further test scenarios. The deliverable comes to its end with the conclusion in Section 5.

(6)

2 Testing of Error-Correcting Codes

In WP2 AAU Klagenfurt performed a statistical analysis on the measurements of different types of PUF-based devices previously observed in the UNIQUE-Project [7]. More precisely, our analysis involved SRAM, Arbiter and Ring Oscillator PUFs. Results of the statistical analysis have already been presented in Deliverable D2.1 [3]. We have carried out the same basic analysis for all the three aforementioned PUFs and their respective challenge-response algorithms. In particular, we have investigated the following important parameters:

• error-per-bit rate

• error-per-response rate

• independence of bit errors

• ageing effects on SRAM devices.

For the SRAM PUF, more experimental data were available, therefore we were able to carry out a more extensive investigation that allowed us to develop a statistical model of such a PUF. Investigation of bit weights of given measurements shows that, for example, a Beta distribution with hyperparameters

α = 0.06203037

β = 0.06193536

is suitable to model the SRAM PUF bit weights. By using Bayesian approaches, we also proposed a more sophisticated statistical model for the noise of such a SRAM PUF (which only concerns the number of erroneous bits per response): we assumed the error rates per bit follow a scaled Beta distribution with shape parameters 2δ·K and (1−2δ)·K (whereδresembles the expected value of the Beta distribution and K again is a shape parameter). In a Bayesian setting, such parameters often are assumed to be random variables themselves; in our case we proposed a scaled Beta distribution for the meanδand a Gamma distribution for the shape parameterK. Currently, we are still working on a rigorous discussion of this model.

Furthermore, we have implemented a Sage [8] script that simulates the SRAM PUF behaviour. More specifically, our SRAM simulator can be initialised with user-defined Beta-distribution pa-rameters, and then it can generate SRAM-like bit error patterns; these binary strings represent the XOR difference between two PUF responses produced by one the the same PUF device when queried with the same challenge (where, as usual, 1 represents an erroneous bit, whilst 0 stands for a correct bit).

Selected error-correcting codes have been tested in two ways:

1. against the SRAM PUF statistical model described above, i.e. the number and position of bit errors are controlled by the SRAM PUF simulator;

2. against uniform error patterns of given weight, i.e. the number of bit errors is given as an input and the error positions are randomly distributed.

The former test is necessary to make sure that our ECCs perform as desired, i.e. as predicted by our theoretical investigation (cf. [3]), on a realistic simulation of the SRAM PUF device. The latter test, instead, is independent from the ECCs concrete application; it is meant to find out how many errors the ECCs can actually correct on a binary symmetric channel, and how the decoding failure rate gets worse by increasing the number of bit errors.

We have tested the concatenated code BCH[31,6,15] + RS[63,32,32], which has been implemented in Demonstrator I: Mutual Authentication. We recall that the resulting concatenated code is a linear binary code of length 31×63 = 1953, dimension 6×32 = 192 and minimum distance at least

(7)

and outer code interact in hard-decision mode, which means that the inner code (BCH) always attempts minimum-distance decoding, even when too many errors have been detected (but not located); thus no erased symbol is passed to the outer code.

Test 1takes place as follows:

1. generate 50 uniform bitstrings of length 192 (messagem);

2. encode each bitstring (obtaining a codewordc of length 1953 bits);

3. apply 50 bit-error patternseprovided by the SRAM PUF simulator: w=c⊕e; 4. decodewand retrieve the original messagem0;

5. ifm=m0 then decoding has been successful.

The error-correcting code BCH+RS has successfully passed this test.

Test 2takes place as follows:

1. generate 10 uniform bitstrings of length 192 (messagem);

2. encode each bitstring (obtaining a codewordc of length 1953 bits); 3. apply 100 pseudorandom bit-error patterns eof given weight: w=c⊕e; 4. decodewand retrieve the original messagem0;

5. ifm=m0 then decoding has been successful.

We have observed the following outcome in the BCH+RS error-correction simulation. error weight failure rate

<419 0 % 420–437 <1% 438–449 1% – 5% 450–459 5% – 10% 460–469 10% – 25% 470–479 25% – 45% >480 >50%

We emphasise that, due to the random nature of generated messages and error vectors, by repeat-ing the very same test, one might obtain slightly different failure rates, although the overall trend shall remain the same.

It is worth noting that the ratio ₁₉₅₃419 ≈ 0.21454173067 between the number of erroneous bits that can be corrected out of the total number of bits is equivalent to the fact that about 21% of the PUF response has been corrupted, which is much worse than the actual PUF behaviour that we have observed in the SRAM device. In fact, given the code length of 1953 bits, the SRAM PUF simulator generates bit error patterns of weight between 90 and 125 bits, which means that only between 4.6% and 6.4% bits in the PUF response are erroneous.

This higher error-correction capacity can serve as an effective anti-ageing feature.

2.1 Reed-Muller and Repetition Code

In addition to the concatenation of BCH and Reed-Solomon code, the error correction capacity of the concatenated Reed-Muller and Repetition code was evaluated. This code has been im-plemented in Demonstrator II: Key Generation. Similarly to the concatenation in the previous

(8)

Its dimension is k= 5×1 = 5 and the minimum Hamming distance is at least d= 8×5 = 40. Thus we can conclude that the covering radius is at leastt=b40−1

2 c= 19. The decoding of the

Reed-Muller code is performed using Reed’s majority logic decoder, which interacts in a hard-decision mode with the Repetition decoder. This means that the decoder of the inner code, which is the Repetition code, does not pass any erased symbols to the decoder of the outer code, i.e. the Reed-Muller code.

From now on, the parameter Ptotal, which indicates the probability that a given bit sequence

is not decoded correctly, is calculated for the above mentioned concatenation. To derivePtotalwe

make use of the simpler, homogeneous model described in [6], where the errors in a PUF response are assumed to be uniformly distributed. This model can be used to calculate upper bounds for the real value ofPtotal. In addition, we assume a bit error probabilityPbit of 8%, which is about

the bit error probability of UNIQUE chips at room temperature. We use the following formulas for the calculation ofPtotal [6]:

Pin= nin X i=tin+1 nin i P_biti (1−Pbit) nin−i _, Ptotal = nout X i=tout+1 _n out i P_ini (1−Pin) nout−i _,

where Pin represents the probability that the inner code fails, ninand nout represent the length

of the inner and the outer code respectively,tinandtout stand for the covering radius of the inner

and the outer code respectively.

For our parameterPbit, the failure probability of the concatenation equalsPtotal≈7.31e−007. In

addition, it should be noted that the ratio between the number of errors that can be corrected and the length of the concatenation ist/n=19₈₀ = 0.2375 which is about 23.75% of the code length. This theoretical assumption has been evaluated with the following test scenario:

1. generate a random bitstring of length 5 (m)

2. encode the bitstring (obtaining a codeword of length 80)

3. apply 1000 pseudorandom bit-error patterns to obtain an error-per-response rate ρ

4. decode the erroneous codeword (m0)

5. ifm=m0 then decoding has been successful

The following results have been observed with this test methodology:

ρ failure rate <25% 0 % 25%–30% <1% 30%–35% 1% – 5.5% 35%–40% 5.5% – 12.1% 40%–45% 12.1% – 23.4% 45%–50% 23.4% – 34.2% >50% >50%

Since pseudorandom error patterns are used to modify the codeword, it might be possible to obtain slightly different results by repeating this test. However, the trend should be the same.

(9)

3 Testing of Demonstrator I: Mutual Authentication

3.1 Mutual Authentication

Description of the test scenario. The objective of this test case is to check whether the FPGA board is capable to authenticate the GUI/verifier and vice versa. In the first step the enrolment will take place, i.e. the FPGA board will be initialized and a set of CRPs will be created. After enrolment, both entities should be capable to verify the authenticity of each other. Moreover, this test scenario checks whether another PUF instantiation (e.g. PUF 2) can be authenticated using a CRP enrolled for PUF 1.

Test ID MutualAuthentication (MA)

Tester Michael H¨oberl

Date August 24th, 2014 Test status passed

Test Case ID MA-TC1: Enrolment of PUF 1

Dependencies,

Pre-Conditions no CRPs are available for PUF 1

Test Data, Input, Single Test Steps

1. Select PUF: PUF 1

2. Select Scenario: Mutual Authentication 3. Press Button: “Enrolment”

Expected Test Results Message Monitor: “Enrolment of PUF 1 successful: 10 CRPs have been created!”

Actual Test Results The enrolment finished successfully and a database with 10 CRPs was created. A detailed description of the test can be found in Appendix A.1. Notes Enrolment has to be successfully executed in order to start with Test

Case MA-TC2

Test Case ID MA-TC2: Mutual Authentication of PUF 1

Dependencies,

Pre-Conditions successful execution of MA-TC1

1. Select PUF: PUF 1 2. Select CRP: #6

3. Select Scenario: Mutual Authentication 4. Press Button: “Start Scenario”

5. Press Button: “Next Step” 6. Press Button: “Next Step”

(10)

Expected Test Results

• after Step 5: Message Monitor: “PUF 1 was successfully authen-ticated”, hash a from FPGA and calculated hash a0 of GUI are equal, form field “FPGA authenticated” is edged in green

• after Step 6: Message Monitor: “GUI was successfully authenti-cated”, hashbfrom GUI and calculated hashb0of FPGA are equal, form field “GUI authenticated” is edged in green

Actual Test Results

The GUI/verifier was able to verify its authenticity to the FPGA board and vice versa. A detailed description of the test can be found in Ap-pendix A.2.

Notes Mutual Authentication of PUF 1 has to be successful in order to show in MA-TC3 that an unenrolled PUF cannot be authenticated

Test Case ID MA-TC3: Mutual Authentication of PUF 2 using CRPs en-rolled for PUF 1

Dependencies,

Pre-Conditions successful execution of MA-TC1 + MA-TC2

2. Select CRP: #4 from PUF 1 !!!! 3. Select Scenario: Mutual Authentication 4. Press Button: “Start Scenario”

• after Step 5: Message Monitor: “Authentication of PUF 2 failed”, hasha from FPGA and calculated hasha0 of GUI are not equal, form field “FPGA authenticated” is edged in red

• after Step 6: Message Monitor: “GUI is not authenticated”, hash

b from GUI and calculated hash b0 of FPGA are not equal, form field “GUI authenticated” is edged in red

Actual Test Results The authentication failed. A detailed description of the test can be found in Appendix A.3.

(11)

-3.2

Replay Attack

Description of the test scenario. The objective of this test case is to check whether a replay attack on the FPGA board is detected or not. In doing so our demonstrator provides the possi-bility to send the same challenge several times to the FPGA board.

Test ID ReplayAttack (RA) Tester Michael H¨oberl

Date August 21st_{, 2014} _{Test status} _passed

Test Case ID RA-TC1: Successful Mutual Authentication of PUF 1 using Challenge #8

Dependencies,

Pre-Conditions PUF 1 has to be enrolled with at least 8 CRPs

• after Step 6: Message Monitor: “GUI was successfully authen-ticated”, Hash b from GUI and calculated hash b0 of FPGA are equal, form field “GUI authenticated” is edged in green

Mutual Authentication of PUF 1 using Challenge #8 succeeded.

Actual Test Results

Notes Test Case RA-TC2 can only be executed and replay can only be detected when test case RA-TC1 succeeded.

Test Case ID RA-TC2: Detection of Replay Attack

Dependencies,

(12)

3. Select Scenario: Replay Attack 4. Press Button: “Start Scenario”

Expected Test Results The Message Monitor displays “REPLAY DETECTED!!!” and the pro-tocol terminates.

Actual Test Results The replay attack was successfully detected and the protocol terminated. A detailed description of the test can be found in Appendix A.5.

(13)

-3.3

Fault Detection

Description of the test scenario. The objective of this test case is to check the behaviour of the prototype when data required for authentication issues, i.e. transmitted hash values (aandb), are manipulated.

Test ID FaultDetection (FD) Tester Michael H¨oberl

Date August 21st_{, 2014} _{Test status} _passed

Test Case ID FD-TC1: Successful Mutual Authentication of PUF 1 using any CRP

Dependencies,

Pre-Conditions PUF 1 has to be enrolled

1. Select PUF: PUF 1 2. Select any CRP

• after Step 6: Message Monitor: “GUI was successfully authenti-cated”, hashbfrom GUI and calculated hashb0of FPGA are equal, form field “GUI authenticated” is edged in green

Mutual Authentication of PUF 1 succeeded.

Actual Test Results

Notes This test case should be carried out before FD-TC2 in order to show that the regular authentication mechanism works.

Test Case ID FD-TC2: Manipulation of transmitted hash values aand b

Dependencies, Pre-Conditions

PUF 1 has to be enrolled and test case FD-TC1 executed successfully; do not use the same CRP as applied in FD-TC1

(14)

2. Select any CRP (except the one used in FD-TC1) 3. Select Scenario: System Fault

4. Press Button: “Start Scenario” 5. Press Button: “Next Step” 6. Press Button: “Next Step”

• after Step 5: Message Monitor: “Authentication of PUF 1 failed”, hasha from FPGA and calculated hasha0 of GUI are not equal, form field “FPGA authenticated” is edged in red→REJECT, i.e. the FPGA could not be authenticated by the GUI

• after Step 6: Message Monitor: “GUI is not authenticated”, hash

b from GUI and calculated hash b0 _{of FPGA are not equal, form}

field “GUI authenticated” is edged in red→REJECT, i.e. the GUI could not be authenticated by the FPGA

Actual Test Results A detailed description of the test can be found in Appendix A.7. Notes An error vector is added to the hash values aand bto simulate a fault

attack. This error vector is generated randomly.

3.4 Extended Test Case

The results of the above mentioned test cases show the correct and reliable functionality of the implemented prototype as well as the error-correction algorithms. Thus the demonstrator provides the capability to authenticate both entities FPGA board and PC/GUI. Additionally, Sections 3.2 and 3.3 demonstrate how replay attacks and faults can be detected. In this way the main func-tionality of the CODES prototype, that is the correct and reliable reconstruction of error-prone PUF responses, is approved. Of course, in a real world IT product using PUF technology, further test scenarios have to be carried out; however, these do not provide added value for the prototype implementation. This section provides some information and suggestions for supplemental testing activities.

Manipulation of Helper Data. The protocol of the “Mutual Authentication” use case requires the FPGA board to extract helper data, which are sent to the PC/GUI, in order to reconstruct the PUF response. In the case that helper data generated by the FPGA board and sent to the PC/GUI are manipulated, the PC/GUI might calculate an erroneous hash valuea0 and authentication of the FPGA would fail. Thus the manipulation of helper data should also be considered in a separate test scenario.

(15)

function-possibly using the PUF response as the key or any other secret that has been previously agreed upon. In doing so the integrity and authenticity of transmitted hash values, helper data, or even state information in case of reconfigurable PUFs, can be ensured. Figure 1 gives an idea of how this can be implemented in the communication protocol.

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

request(a,HD);send(C) request(R) generate(R) send(R) generate(HD) a←hash(ID,R,HD) m = MAC(a,R) send(a,HD,m) R←reconstruct(R’,HD) m’←MAC(a,R) IntAuthCheck(m’=m)

Figure 1: Sequence diagram of Demonstrator I applying MACs to ensure integrity and authenticity of transmitted data.

Testing all available PUF instantiations. The test cases in Sections 3.1, 3.2 and 3.3 show the results using PUF 1 and 2 located on the ASIC board. For the sake of completeness, all possible tests considering different combinations of PUFs and CRPs should be performed, d.h. PUF 5 is enrolled and PUF 4 is authenticated, all challenges of PUF 3 are applied to test replay attacks, or all PUFs are subject to fault detection. Some different combinations were tested on the prototype implementation and each of them returned the same expected results. As recording all the test results in this deliverable is without added value and would just unnecessarily blow up the document only one exemplary test case is provided for each test scenario.

(16)

4 Testing of Demonstrator II: Key Generation

4.1 Enrolment and Reconstruction

Description of the test scenario. The objective of this test case is to check whether a PUF instantiation can be enrolled successfully and the reconstruction of the key works. The user sends a string to the FPGA board, which generates a secret key based on the PUF response, encrypts the string and stores it in non-volatile memory. In the reconstruction phase the FPGA board recon-structs the key, decrypts the string, returns it to the GUI and shows the string on the LCD display.

Test ID Enrolment and Reconstruc-tion (ER)

Tester Michael H¨oberl

Date August 20th, 2014 Test status passed

Test Case ID ER-TC1: Successful Enrolment of PUF 3

Dependencies,

Pre-Conditions none

2. Select Scenario: Enrolment

3. Enter Initialization Text: “DemoII” 4. Press Button: “Start Scenario”

After step 4 the PUF is enrolled and the string is encrypted and stored on the FPGA board. The form field “Enrolment” indicates that enrol-ment has been performed by showing the string “DONE”. The message window returns the string “Enrolment successful!”.

Actual Test Results The enrolment finished successfully. A detailed description of the test can be found in Appendix B.1.

Notes This test case has to be carried out before key reconstruction ER-TC2 is started.

Test Case ID ER-TC2: Key Reconstruction of PUF 3

Dependencies,

Pre-Conditions PUF 3 has to be enrolled and test case ER-TC1 executed successfully

2. Select Scenario: Key Reconstruction 3. Press Button: “Start Scenario”

(17)

Form field “Return value of SW” displays the string entered in the en-rolment test case ER-TC1 “DemoII”. The values of the following form fields are equal:

• K generated by FPGA (Enrolment) == Key generated by FPGA (Key Reconstruction)

• R generated by ASIC (Enrolment) == R reconstructed by FPGA (Key Reconstruction)

• Code Word generated by FPGA (Enrolment) == Code Word gen-erated by FPGA (Key Reconstruction)

The form field “Key Reconstruction” indicates that key reconstruction has been performed by showing the string “DONE”. The message win-dow returns the string “Reconstruction successful!”.

Actual Test Results The key reconstruction and decryption finished successfully. A detailed description of the test can be found in Appendix B.2.

Notes PUF 3 is successfully enrolled and the generated key can be recon-structed.

4.2 Binding String to PUF

Description of the test scenario. The objective of this test case is to check whether any PUF instantiation is capable to reconstruct a key and consequently decrypt the stored string, which was enrolled with another PUF instantiation.

Note: This test scenario shows that using PUFs software can be bound to a certain piece of hardware (HW/SW Binding) as only the PUF used during enrolment is capable to reconstruct the according key in order to decrypt the string/software.

Test ID Binding String to PUF (BS) Tester Michael H¨oberl

Date August 22nd_{, 2014} _{Test status} _passed

Test Case ID BS-TC1: Key Reconstruction using PUF 2

Test cases ER-TC1 and ER-TC2 must be successfully executed, d.h. PUF 3 is enrolled and the key can be reconstructed.

(18)

The protocol is executed successfully, but the string returned to the GUI and LCD display respectively, is garbled and shows “random” values instead of the enrolled string “DemoII”. The values of the following form fields must not be equal:

• K generated by FPGA (Enrolment) != Key generated by FPGA (Key Reconstruction)

• R generated by ASIC (Enrolment) != R reconstructed by FPGA (Key Reconstruction)

• Code Word generated by FPGA (Enrolment) != Code Word gen-erated by FPGA (Key Reconstruction)

The form field “Key Reconstruction” indicates that key reconstruction has been performed by showing the string “DONE” but the returned content of the decrypted string is of no value. The message window returns the string “Reconstruction successful!” as the protocol executed successfully.

Actual Test Results

The key reconstruction finished successfully, but the decryption failed due to the wrong key. A detailed description of the test can be found in Appendix B.3.

Notes

-Test Case ID BS-TC2: Key Reconstruction using PUF 3

Test cases ER-TC1 and ER-TC2 must be successfully executed, d.h. PUF 3 is enrolled and the key can be reconstructed.

Expected Test Results Key reconstruction succeeded and string “DemoII” was correctly de-crypted →see results of test case ER-TC2

Actual Test Results The key reconstruction and decryption finished successfully. A detailed description of the test can be found in Appendix B.4.

Notes

Test cases BS-TC1 and BS-TC2 show that only the PUF instantiation which was used during enrolment can reconstruct the according key and decrypt the stored string, which means the string is bound to PUF 3. Test case BS-TC1 can be repeated with any other PUF instantiation located on the ASIC board, d.h. PUF 1, PUF 4 and PUF 5; the results will always be the same as for PUF 2: the protocol executes but the returned content has no value.

(19)

4.3 Extended Test Case

Compared to Use Case “Mutual Authentication”, the main protocol of this application is per-formed on the FPGA board. Therefore data stored on it have to be protected and monitored in order to ensure the reliable and correct functionality. The above mentioned test cases show the reliable and correct enrolment and reconstruction of a PUF-based key, as well as the unsuccessful reconstruction due to the hardware-software binding effect. Additionally, the following paragraphs provide information regarding extended test cases that can be performed for real world products using PUF technology.

Manipulation of stored data. Use Case “Key Generation” requires the storage of helper data, generated during enrolment, in non-volatile memory. Assuming that an attacker is capable to manipulate the stored helper data, the PUF-based device might not be able to reconstruct the corresponding key and decryption of the stored string would fail. Thus the device should provide a functionality to periodically check the integrity and authenticity of use case relevant data, such as helper data and the stored string. This can be achieved by applying a Message Authentication Code (MACs) to the helper data and to the stored string, possibly using the PUF response or any other predefined secret as the key. Consequently, the PUF-based device can detect an unauthorized manipulation and trigger a security alarm.

MACs can also be applied to state information in case of reconfigurable PUFs. Thus unautho-rized key reconfiguration or key zeroization can be detected and an alarm can be triggered.

Testing all available PUF instantiations. The test cases in Sections 4.1 and 4.2 show the results using PUF 2 and 3. For the sake of completeness, all possible tests considering different combinations of PUF instantiations should be performed, d.h. PUF 5 is enrolled and PUF 1 is used to reconstruct the key, or the other way round, PUF 1 is enrolled and PUF 5 is used to reconstruct the secret. Some different combinations were tested on the prototype implementation and each of them returned the same expected results. As recording all the test results within this deliverable is without added value and would just unnecessarily blow up the document only one exemplary test case is provided for each test scenario.

(20)

5 Conclusion

Generating this deliverable worked very well, as valuable preparatory work has been carried out before. First of all the demonstrator was set up as defined and the functionality was exactly as expected. Further the tests to be carried out were defined before and the test descriptions were based on general Common Criteria testing. This allowed a deployment of the tests according to a well defined scheme, which proved to be a good approach. In the course of the implementation of the pre-defined tests, a few potential alternative test cases came to our mind. We decided therefore to integrate those thoughts in additional extended test cases. To not break the build-up of the single test descriptions, we included some additional relevant information about the outcome and single steps of the tests in an appendix.

(21)

References

[1] I. Schaumüller-Bichl, A. Kolberger, M. Deutschmann, C. Heuberger, W. Müller, B. Hackl, “D1.1: SWOT analysis of existing PUF security modules”, CODES Project, July 2013. [2] I. Schaumüller-Bichl, A. Kolberger, M. Deutschmann, “D4.1: Risk analysis, definition of

security objectives and security requirements”, CODES Project, September 2013.

[3] B. Hackl, C. Heuberger, M. Mazzoli, W. M¨uller, V. Brunner, M. Deutschmann, M. H¨oberl, “D2.1: Report on suitable post-processing methods”, CODES Project, March 2014.

[4] M. Deutschmann, M. H¨oberl, C. Petschnigg, I. Schaum¨uller-Bichl, A. Kolberger, M. Mazzoli, C. Heuberger, “D3.1: Hybrid FPGA ASIC prototype”, CODES Project, July 2014.

[5] I. Schaum¨uller-Bichl, A. Kolberger, M. Deutschmann, M. H¨oberl, C. Petschnigg, “D4.2: Eval-uation of developed functions with respect to criteria defined in D4.1”, CODES Project, July 2014.

[6] C. B¨osch, J. Guajardo, A. R. Sadeghi, J. Shokrollahi, P. Tuyls, “Efficient Helper Data Key Extractor on FPGAs”

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

[8] W. A. Stein and others, The Sage Development Team, Sage Mathematics Software v6.2, 2014,

(22)

A

Testing of Demonstartor I: Mutual Authentication

A.1 MA-TC1: Enrolment of PUF1

This test consists of three steps (Figure 2): 1. Selecting PUF 1

2. SelectingMutual Authentication as a scenario 3. Pressing theEnrolment button

(23)

A.2 MA-TC2: Mutual Authentication of PUF1

This test consists of six steps (Figure 3): 1. Selecting PUF 1

2. Selecting an unused CRP

3. SelectingMutual Authentication as a scenario 4. Pressing theStart Scenario button

5. Pressing theNext Step button 6. Pressing again theNext Step button

(24)

A.3 MA-TC3: Mutual Authentication of PUF 2 using CRPs enrolled

for PUF 1

(25)

A.4 RA-TC1: Successful Mutual Authentication of PUF 1 using

Chal-lenge # 8

2. Selecting CRP # 8

(26)

A.5 RA-TC2: Detection of Replay Attack

This test consists of four steps (Figure 6): 1. Selecting PUF 1

2. Selecting CRP # 8

3. SelectingReplay Attack as a scenario 4. Pressing theStart Scenario button

(27)

A.6 FD-TC1: Successful Mutual Authentication of PUF 1 using any

CRP

(28)

A.7 FD-TC2: Manipulation of transmitted hash values

a

and

b

This test consists of six steps (Figure 8):

1. Selecting PUF 1 2. Selecting an unused

3. SelectingSystem Fault as a scenario 4. Pressing theStart Scenario button 5. Pressing theNext Step button 6. Pressing again theNext Step button

(29)

B

Testing of Demonstartor II: Key Generation

B.1 ER-TC1: Successful Enrolment of PUF 3

This test consists of four steps (Figure 9): 1. Selecting PUF 3

2. SelectingEnrolment as a scenario 3. Enter an initialization text

4. Pressing theStart Scenario button

(30)

B.2 ER-TC2: Key Reconstruction of PUF 3

2. SelectingKey Reconstruction as a scenario 3. Pressing theStart Scenario button

Figure 10: Screenshot of ER-TC2

(31)

B.3 BS-TC1: Key Reconstruction using PUF 2

Figure 12: Screenshot of BS-TC1

(32)

Final Report on Prototype Testing

D1.2: Final Report on Prototype Testing

Contents

List of Abbreviations

List of Figures

1

Introduction

1.1

Purpose

1.2

Scope

1.3

Outline

2

Testing of Error-Correcting Codes

2.1

Reed-Muller and Repetition Code

3

Testing of Demonstrator I: Mutual Authentication

3.1

Mutual Authentication

-3.2

Replay Attack

-3.3

Fault Detection

3.4

Extended Test Case

4

Testing of Demonstrator II: Key Generation

4.1

Enrolment and Reconstruction

4.2

Binding String to PUF

4.3

Extended Test Case

5

Conclusion

References

A

Testing of Demonstartor I: Mutual Authentication

A.1

MA-TC1: Enrolment of PUF1

A.2

MA-TC2: Mutual Authentication of PUF1

A.3

MA-TC3: Mutual Authentication of PUF 2 using CRPs enrolled

for PUF 1

A.4

RA-TC1: Successful Mutual Authentication of PUF 1 using

Chal-lenge # 8

A.5

RA-TC2: Detection of Replay Attack

A.6

FD-TC1: Successful Mutual Authentication of PUF 1 using any

CRP

A.7

FD-TC2: Manipulation of transmitted hash values

a

and

b

B

Testing of Demonstartor II: Key Generation

B.1

ER-TC1: Successful Enrolment of PUF 3

B.2

ER-TC2: Key Reconstruction of PUF 3

B.3

BS-TC1: Key Reconstruction using PUF 2

B.4

BS-TC2: Key Reconstruction using PUF 3