Final Report on Prototype Testing

.. 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 reconfigurable 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 performed functional tests of the demonstrators and a summary of the achieved results. It includes testing of the implemented Error Correcting 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

. Contents 1 Introduction 5 1.1 Purpose.......................................... 5 1.2 Scope........................................... 5 1.3 Outline.......................................... 5 2 Testing of Error-Correcting Codes 6 2.1 Reed-Muller and Repetition Code............................ 7 3 Testing of Demonstrator I: Mutual Authentication 9 3.1 Mutual Authentication.................................. 9 3.2 Replay Attack....................................... 11 3.3 Fault Detection...................................... 13 3.4 Extended Test Case................................... 14 4 Testing of Demonstrator II: Key Generation 16 4.1 Enrolment and Reconstruction............................. 16 4.2 Binding String to PUF.................................. 17 4.3 Extended Test Case................................... 19 5 Conclusion 20 References 21 A Testing of Demonstartor I: Mutual Authentication 22 A.1 MA-TC1: Enrolment of PUF1............................. 22 A.2 MA-TC2: Mutual Authentication of PUF1...................... 23 A.3 MA-TC3: Mutual Authentication of PUF 2 using CRPs enrolled for PUF 1.... 24 A.4 RA-TC1: Successful Mutual Authentication of PUF 1 using Challenge # 8.... 25 A.5 RA-TC2: Detection of Replay Attack......................... 26 A.6 FD-TC1: Successful Mutual Authentication of PUF 1 using any CRP....... 27 A.7 FD-TC2: Manipulation of transmitted hash values a and b.............. 28 B Testing of Demonstartor II: Key Generation 29 B.1 ER-TC1: Successful Enrolment of PUF 3....................... 29 B.2 ER-TC2: Key Reconstruction of PUF 3........................ 30 B.3 BS-TC1: Key Reconstruction using PUF 2...................... 31 B.4 BS-TC2: Key Reconstruction using PUF 3...................... 32

List of Abbreviations ASIC BCH CRP FE Application Specific Integrated Circuit Bose-Chaudhuri-Hocquenghem (error-correcting codes) Challenge Response Pair Fuzzy Extractor FPGA Field-Programmable Gate Array HD MAC PUF RM RS Helper Data Message Authentication Code Physically Unclonable Function Reed-Muller (error-correcting codes) Reed-Solomon (error-correcting codes) SRAM Static Random Access Memory 3/32

List of Figures 1 Sequence diagram of Demonstrator I applying MACs to ensure integrity and authenticity 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 14 Screenshot of BS-TC2.................................. 32 4/32

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 in D1.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 deliverable D3.1 - Hybrid FPGA ASIC Prototype [4]. For each demonstrator test cases have been defined and carried out. Furthermore, for the implemented 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. 5/32

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 parameter K. 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 parameters, 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 15 32 = 480, thus covering radius at least 480 1 2 = 239. We use as decoding algorithms the Berlekamp-Massey decoder for BCH, and the Gao decoder for Reed-Solomon. Furthermore, inner 6/32

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 1 takes place as follows: 1. generate 50 uniform bitstrings of length 192 (message m); 2. encode each bitstring (obtaining a codeword c of length 1953 bits); 3. apply 50 bit-error patterns e provided by the SRAM PUF simulator: w = c e; 4. decode w and retrieve the original message m ; 5. if m = m then decoding has been successful. The error-correcting code BCH+RS has successfully passed this test. Test 2 takes place as follows: 1. generate 10 uniform bitstrings of length 192 (message m); 2. encode each bitstring (obtaining a codeword c of length 1953 bits); 3. apply 100 pseudorandom bit-error patterns e of given weight: w = c e; 4. decode w and retrieve the original message m ; 5. if m = m 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 repeating 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 1953 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 implemented in Demonstrator II: Key Generation. Similarly to the concatenation in the previous section, the resulting RM(16,5,8)+Rep(5,1,5) code is a linear binary code of length n = 16 5 = 80. 7/32

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 least t = 40 1 2 = 19. The decoding of the Reed-Muller code is performed using Reed s majority logic decoder, which interacts in a harddecision 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 P total, which indicates the probability that a given bit sequence is not decoded correctly, is calculated for the above mentioned concatenation. To derive P total we 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 of P total. In addition, we assume a bit error probability P bit of 8%, which is about the bit error probability of UNIQUE chips at room temperature. We use the following formulas for the calculation of P total [6]: P in = P total = n in i=t out+1 ( nin i i=t in+1 n out ( nout i ) P i bit (1 P bit ) nin i, ) P i in (1 P in ) nout i, where P in represents the probability that the inner code fails, n in and n out represent the length of the inner and the outer code respectively, t in and t out stand for the covering radius of the inner and the outer code respectively. For our parameter P bit, the failure probability of the concatenation equals P total 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 is t/n = 19 80 = 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 (m ) 5. if m = m 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. 8/32

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 Date August 24 th, 2014 Test status passed Michael Höberl 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 Actual Test Results Notes Message Monitor: Enrolment of PUF 1 successful: 10 CRPs have been created! 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. 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 Test Data, Input, Single Test Steps 3. Select Scenario: Mutual Authentication 4. Press Button: Start Scenario 5. Press Button: Next Step 6. Press Button: Next Step 9/32

Expected Test Results after Step 5: Message Monitor: PUF 1 was successfully authenticated, hash a from FPGA and calculated hash a of GUI are equal, form field FPGA authenticated is edged in green after Step 6: Message Monitor: GUI was successfully authenticated, hash b from GUI and calculated hash b of FPGA are equal, form field GUI authenticated is edged in green Actual Test Results Notes Test Case ID Dependencies, Pre-Conditions 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 Appendix A.2. Mutual Authentication of PUF 1 has to be successful in order to show in MA-TC3 that an unenrolled PUF cannot be authenticated MA-TC3: Mutual Authentication of PUF 2 using CRPs enrolled for PUF 1 successful execution of MA-TC1 + MA-TC2 1. Select PUF: PUF 2 2. Select CRP: #4 from PUF 1!!!! Test Data, Input, Single Test Steps 3. Select Scenario: Mutual Authentication 4. Press Button: Start Scenario 5. Press Button: Next Step 6. Press Button: Next Step Expected Test Results after Step 5: Message Monitor: Authentication of PUF 2 failed, hash a from FPGA and calculated hash a 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 b 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. Notes - 10/32

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 possibility to send the same challenge several times to the FPGA board. Test ID ReplayAttack (RA) Tester Michael Höberl Date August 21 st, 2014 Test status passed Test Case ID Dependencies, Pre-Conditions RA-TC1: Successful Mutual Authentication of PUF 1 using Challenge #8 PUF 1 has to be enrolled with at least 8 CRPs 1. Select PUF: PUF 1 2. Select CRP: #8 Test Data, Input, Single Test Steps 3. Select Scenario: Mutual Authentication 4. Press Button: Start Scenario 5. Press Button: Next Step 6. Press Button: Next Step Expected Test Results after Step 5: Message Monitor: PUF 1 was successfully authenticated, hash a from FPGA and calculated hash a of GUI are equal, form field FPGA authenticated is edged in green after Step 6: Message Monitor: GUI was successfully authenticated, Hash b from GUI and calculated hash b 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 ID Dependencies, Pre-Conditions 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 Appendix A.4. Test Case RA-TC2 can only be executed and replay can only be detected when test case RA-TC1 succeeded. RA-TC2: Detection of Replay Attack Test case RA-TC1 has to be executed successfully 11/32

1. Select PUF: PUF 1 Test Data, Input, Single Test Steps 2. Select CRP: #8 3. Select Scenario: Replay Attack 4. Press Button: Start Scenario Expected Test Results Actual Test Results The Message Monitor displays REPLAY DETECTED!!! and the protocol terminates. The replay attack was successfully detected and the protocol terminated. A detailed description of the test can be found in Appendix A.5. Notes - 12/32

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 (a and b), are manipulated. Test ID FaultDetection (FD) Tester Michael Höberl Date August 21 st, 2014 Test status passed Test Case ID FD-TC1: any CRP Successful Mutual Authentication of PUF 1 using Dependencies, Pre-Conditions PUF 1 has to be enrolled 1. Select PUF: PUF 1 2. Select any CRP Test Data, Input, Single Test Steps 3. Select Scenario: Mutual Authentication 4. Press Button: Start Scenario 5. Press Button: Next Step 6. Press Button: Next Step Expected Test Results after Step 5: Message Monitor: PUF 1 was successfully authenticated, hash a from FPGA and calculated hash a of GUI are equal, form field FPGA authenticated is edged in green after Step 6: Message Monitor: GUI was successfully authenticated, hash b from GUI and calculated hash b of FPGA are equal, form field GUI authenticated is edged in green Mutual Authentication of PUF 1 succeeded. Actual Test Results Notes Test Case ID Dependencies, Pre-Conditions 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 Appendix A.6. This test case should be carried out before FD-TC2 in order to show that the regular authentication mechanism works. FD-TC2: Manipulation of transmitted hash values a and b PUF 1 has to be enrolled and test case FD-TC1 executed successfully; do not use the same CRP as applied in FD-TC1 13/32

1. Select PUF: PUF 1 2. Select any CRP (except the one used in FD-TC1) Test Data, Input, Single Test Steps 3. Select Scenario: System Fault 4. Press Button: Start Scenario 5. Press Button: Next Step 6. Press Button: Next Step Expected Test Results after Step 5: Message Monitor: Authentication of PUF 1 failed, hash a from FPGA and calculated hash a 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 b 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 Notes A detailed description of the test can be found in Appendix A.7. An error vector is added to the hash values a and b to 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 functionality 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 value a and authentication of the FPGA would fail. Thus the manipulation of helper data should also be considered in a separate test scenario. Integrity and Authenticity Check. A real world product can implement a security functionality that provides an integrity and authenticity check of data transmitted between the PUF-based device and the verifier. This can be realized by applying Message Authentication Codes (MACs), 14/32

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) generate(hd) send(r) 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. 15/32

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 reconstructs the key, decrypts the string, returns it to the GUI and shows the string on the LCD display. Test ID Enrolment and Reconstruction (ER) Tester Date August 20 th, 2014 Test status passed Michael Höberl Test Case ID ER-TC1: Successful Enrolment of PUF 3 Dependencies, Pre-Conditions none 1. Select PUF: PUF 3 Test Data, Input, Single Test Steps 2. Select Scenario: Enrolment 3. Enter Initialization Text: DemoII 4. Press Button: Start Scenario Expected Test Results Actual Test Results Notes After step 4 the PUF is enrolled and the string is encrypted and stored on the FPGA board. The form field Enrolment indicates that enrolment has been performed by showing the string DONE. The message window returns the string Enrolment successful!. The enrolment finished successfully. A detailed description of the test can be found in Appendix B.1. 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 Test Data, Input, Single Test Steps 1. Select PUF: PUF 3 2. Select Scenario: Key Reconstruction 3. Press Button: Start Scenario 16/32

Form field Return value of SW displays the string entered in the enrolment 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) Expected Test Results R generated by ASIC (Enrolment) == R reconstructed by FPGA (Key Reconstruction) Code Word generated by FPGA (Enrolment) == Code Word generated by FPGA (Key Reconstruction) The form field Key Reconstruction indicates that key reconstruction has been performed by showing the string DONE. The message window returns the string Reconstruction successful!. Actual Test Results Notes The key reconstruction and decryption finished successfully. A detailed description of the test can be found in Appendix B.2. PUF 3 is successfully enrolled and the generated key can be reconstructed. 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öberl Date August 22 nd, 2014 Test status passed Test Case ID BS-TC1: Key Reconstruction using PUF 2 Dependencies, Pre-Conditions Test cases ER-TC1 and ER-TC2 must be successfully executed, d.h. PUF 3 is enrolled and the key can be reconstructed. Test Data, Input, Single Test Steps 1. Select PUF: PUF 2 2. Select Scenario: Key Reconstruction 3. Press Button: Start Scenario 17/32

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) Expected Test Results R generated by ASIC (Enrolment)!= R reconstructed by FPGA (Key Reconstruction) Code Word generated by FPGA (Enrolment)!= Code Word generated 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 Dependencies, Pre-Conditions Test cases ER-TC1 and ER-TC2 must be successfully executed, d.h. PUF 3 is enrolled and the key can be reconstructed. Test Data, Input, Single Test Steps 1. Select PUF: PUF 3 2. Select Scenario: Key Reconstruction 3. Press Button: Start Scenario Expected Test Results Actual Test Results Notes Key reconstruction succeeded and string DemoII was correctly decrypted see results of test case ER-TC2 The key reconstruction and decryption finished successfully. A detailed description of the test can be found in Appendix B.4. 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. 18/32

4.3 Extended Test Case Compared to Use Case Mutual Authentication, the main protocol of this application is performed 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 unauthorized 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. 19/32

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. 20/32

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üller, V. Brunner, M. Deutschmann, M. Höberl, D2.1: Report on suitable post-processing methods, CODES Project, March 2014. [4] M. Deutschmann, M. Höberl, C. Petschnigg, I. Schaumüller-Bichl, A. Kolberger, M. Mazzoli, C. Heuberger, D3.1: Hybrid FPGA ASIC prototype, CODES Project, July 2014. [5] I. Schaumüller-Bichl, A. Kolberger, M. Deutschmann, M. Höberl, C. Petschnigg, D4.2: Evaluation of developed functions with respect to criteria defined in D4.1, CODES Project, July 2014. [6] C. Bösch, 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, http://www.sagemath.org 21/32

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. Selecting Mutual Authentication as a scenario 3. Pressing the Enrolment button Figure 2: Screenshot of MA-TC1 22/32

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. Selecting Mutual Authentication as a scenario 4. Pressing the Start Scenario button 5. Pressing the Next Step button 6. Pressing again the Next Step button Figure 3: Screenshot of MA-TC2 23/32

A.3 MA-TC3: Mutual Authentication of PUF 2 using CRPs enrolled for PUF 1 This test consists of six steps (Figure 4): 1. Selecting PUF 2 2. Selecting an unused CRP 3. Selecting Mutual Authentication as a scenario 4. Pressing the Start Scenario button 5. Pressing the Next Step button 6. Pressing again the Next Step button Figure 4: Screenshot of MA-TC3 24/32

A.4 RA-TC1: Successful Mutual Authentication of PUF 1 using Challenge # 8 This test consists of six steps (Figure 5): 1. Selecting PUF 1 2. Selecting CRP # 8 3. Selecting Mutual Authentication as a scenario 4. Pressing the Start Scenario button 5. Pressing the Next Step button 6. Pressing again the Next Step button Figure 5: Screenshot of RA-TC1 25/32

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. Selecting Replay Attack as a scenario 4. Pressing the Start Scenario button Figure 6: Screenshot of RA-TC2 26/32

A.6 FD-TC1: Successful Mutual Authentication of PUF 1 using any CRP This test consists of six steps (Figure 7): 1. Selecting PUF 1 2. Selecting an unused CRP 3. Selecting Mutual Authentication as a scenario 4. Pressing the Start Scenario button 5. Pressing the Next Step button 6. Pressing again the Next Step button Figure 7: Screenshot of FD-TC1 27/32

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. Selecting System Fault as a scenario 4. Pressing the Start Scenario button 5. Pressing the Next Step button 6. Pressing again the Next Step button Figure 8: Screenshot of FD-TC2 28/32

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. Selecting Enrolment as a scenario 3. Enter an initialization text 4. Pressing the Start Scenario button Figure 9: Screenshot of ER-TC1 29/32

B.2 ER-TC2: Key Reconstruction of PUF 3 This test consists of three steps (Figure 10): 1. Selecting PUF 3 2. Selecting Key Reconstruction as a scenario 3. Pressing the Start Scenario button Figure 10: Screenshot of ER-TC2 Figure 11: LCD Display after ER-TC2 was successfully executed 30/32

B.3 BS-TC1: Key Reconstruction using PUF 2 This test consists of three steps (Figure 12): 1. Selecting PUF 2 2. Selecting Key Reconstruction as a scenario 3. Pressing the Start Scenario button Figure 12: Screenshot of BS-TC1 Figure 13: LCD Display after BS-TC1 was successfully executed 31/32

B.4 BS-TC2: Key Reconstruction using PUF 3 This test consists of three steps (Figure 14): 1. Selecting PUF 3 2. Selecting Key Reconstruction as a scenario 3. Pressing the Start Scenario button Figure 14: Screenshot of BS-TC2 32/32