PUF Encryption Decryption Demo Application

The PUF can now be used for encrypting and decrypting user data because the ZCU102 development board has been provisioned. Specifically, this section uses a reference design to show how to encrypt and decrypt user generated AES keys that are stored on an SD card.

1. To support the SD card storage the xilffs library has to be added to application BSP. Right-click on the platform.spr that is located under ZCU102_XAPP1333 platform in the Explorer view and click Open .

2. Select Board Support Package under standalone on psu_cortexa53_0 in the ZCU102_XAPP1333 platform view and click Modify BSP settings .

3. Select xilffs library in the Board Support Package Settings window.  Click on the xilffs library that appears on the left in Overview -> standalone and set the enable_exfat configuration parameter to true . Click OK.

These settings are shown in the following figure :

4. Right-click the ZCU102_XAPP1333 platform in the Explorer view, which is now marked as out-of-date, and click Build Project .

5. In Xilinx Vitis, click File > New > Application Project . If Create a New Application Project window appear click Next .

6. Select ZCU102_XAPP1333 platform in the Platform Window and click Next .

7. Type in ExternalKeyStorage in the Application project name:

8. Leave remaining parameters at their default value and click Next.

9. Leave the domain as standalone on psu_cortexa53_0 . These settings are shown in This Figure , This Figure , and This Figure .

10. Select Next .

11. Select Empty Application (C) .

12. Click Finish .

13. Expand the src folder in ExternalKeyStorage of the Project explorer window.

14. Right-click src and select Import Sources .

15. Click Browse in the File system window.

16. Navigate to the ExternalKeyStorage/src folder in the reference design file directory and check all “.c” and “.h” files and then click Finish as shown in This Figure .

17. Create a new file called ExternalKeyStorage.bif in the ExternalKeyStorage folder. This file is also included with the design files and can be copied into the project folder but the paths must be updated to point to the correct folders. Manual creation of the BIF file is necessary to use the Black Key during boot as the Create Boot Image tool within Xilinx Vitis does not currently support this feature. Future revisions of Xilinx Vitis may support this feature.

18. Update the contents of the file to the contents shown in the following figure using the correct paths.

19. Build the ExternalKeyStorage project in Xilinx Vitis.

20. From the command prompt in the ExternalKeyStorage folder run the following command: bootgen –p zcu9eg –arch zynqmp –image ExternalKeyStorage.bif –w –o BOOT.bin

21. Power off the ZCU102 board.

22. Copy BOOT.bin to a blank SD card.

23. Load the SD card into the J100 SD slot on the ZCU102 development board.

24. Connect a USB cable from the USB Serial port J83 on the ZCU102 board to a computer and make note of which COM port was enumerated with the Silicon Labs Quad CP2108 USB to UART Bridge: Interface 0.

25. Open a terminal program such as PuTTY or Tera Term and connect to the COM port listed above at 115,200 baud. Enable terminal logging and select a file name and location.

26. On the ZCU102 development board, set the dip switch SW6 to configure the board for SD boot mode as shown in the previous figure.

27. Load the SD card into the J100 SD slot on the ZCU102 development board.

28. Power on the ZCU102 board using switch SW1 .

In the terminal program, a menu appears as shown in the following figure:

29. Press 1 to encrypt a user key and to save the encrypted key to the external SD card and follow the prompts, as illustrated in This Figure .

a. Enter a 96-bit IV. Please note: Do not reuse IV. Per the AES-GCM standard the IV should be a new one per every use.

b. Enter an 8-bit key ID. Use an ID of 42 for this key. An ID of 0 is mapped to user eFUSE 0 bit 0, an ID of 1 is mapped to user eFUSE 0 bit 1, … , an ID of 255 is mapped to user eFUSE 7 bit 31.

c. Enter a 256-bit AES key.

d. Enter a file name including a file extension (for example, Key1.key) for the key up to 16 characters long and then press enter when complete.

30. After entering the file name, the program displays the unencrypted key blob which consists of the IV, Key’s ID, and the key itself. Afterwards, the ID and AES key are encrypted using the PUF’s device-unique KEK, the entire 61 byte encrypted key blob is displayed, and the entire encrypted key blob is written to the SD card.

31. Repeat the entire encryption process and encrypt another key and new IV (as per AES-GCM standard), using step 29 . However, select an ID that is equal to 0xFF and create a unique key file name (e.g., Key2.key).

32. Power off the ZCU102 board.

33. Remove the SD card and insert the card into a SD card reader on a computer.

34. Using a browser or the command line, display the contents of the SD card.

35. Make sure both key files generated in step 29 and step 31 appear on the SD card as shown in This Figure .

36. Open both keys in a hex editor and confirm that they match the encrypted key blobs displayed in the user application. KEY1.KEY is shown in the following figure and matches the output generated in This Figure .

37. Remove the SD card from the computer and insert the card into the ZCU102 development board.

38. Apply power to the ZCU102 development board. The menu shown in This Figure appears.

39. Press 2 to decrypt the data that is stored externally on the SD card.

40. Type in the name of the key file and the file extension used in step 29 (Key1.key).

a. The key is read from the SD card and placed into OCM for processing.

b. The encrypted key blob is displayed.

c. The decryption process of the key blob takes place and the decrypted information is displayed showing the IV, key ID, and key.

d. The decrypted GCM tag is compared to the GCM tag stored in the encrypted key blob and the software indicates if they match.

e. Lastly, the key ID is mapped to and compared to the associated bit stored in the user eFUSEs and the software indicates if the IDs match. In this case, the IDs match. An ID of 0 is mapped to user eFUSE 0 bit 0, an ID of 1 is mapped to user eFUSE 0 bit 1, … , an ID of 255 is mapped to user eFUSE 7 bit 31.

41. Repeat the process and decrypt the second key that was created in step 29 .

42. All of the same information from step 40 is displayed and the key is decrypted and passes authentication. However, the software simulates ID 255 being revoked and should not be used. When ID 255 is read from a decrypted key file, the software replaces the actual value read in from User eFUSE 7, 0x0000_0000, with a simulated value of 0x8000_0000. Since bit 31 of User eFUSE 7 is now set and appears to be burned, this simulates ID 255 as being revoked. Decrypting the two test keys is shown in the following figure.