Overview

This file illustrates encryption and decryption of user data using PUF KEY.

The key can be generated using either PUF registration or PUF on demand regeneration. To build this application, xilmailbox library must be included in BSP and xilsecure and xilpuf must be in client mode.

This example is supported for Versal and Versal Net devices.

 MODIFICATION HISTORY:

Ver Who Date Changes

1.0 kpt 01/04/22 Initial release kpt 01/13/22 Added support to run example on PL microblaze har 01/20/22 Removed inclusion of xil_mem.h har 03/04/22 Added comment to specify mode of libraries kpt 03/16/22 Removed IPI related code and added mailbox support har 03/31/22 Updated default data and data length kpt 04/08/22 Added comment on usage of shared memory 2.1 am 04/13/23 Fix PUF auxiliary convergence error 2.2 am 05/03/23 Added KAT before crypto usage vss 11/22/23 Added header file required for SDT flow

 Note

User configurable parameters for PUF

 #define XPUF_DATA                              "000000000000000000000000"
 Data to be encrypted by PUF KEY should be provided in string format.

 #define XPUF_DATA_LEN_IN_BYTES         (0U)
 Length of data to be encrypted should be provided in bytes, where number of
 bytes must be a multiple of 4.

 #define XPUF_IV                                "000000000000000000000000"
 IV should be provided in string format. It should be 24 characters long, valid
 characters are 0-9, a-f, A-F. Any other character is considered as invalid
 string. The value mentioned here will be converted to hex buffer. It is used
 with the AES-GCM cryptographic hardware in order to encrypt user data.

 #define XPUF_KEY_GENERATE_OPTION               (XPUF_REGISTRATION)
                                                        (or)
                                                (XPUF_REGEN_ON_DEMAND)
 PUF helper data can be generated by PUF registration or PUF on-demand
 regeneration. The user can configure XPUF_KEY_GENERATE_OPTION as either
 XPUF_REGISTRATION or XPUF_REGEN_ON_DEMAND to select the mode of PUF operation
 to generate helper data

 #define XPUF_READ_HD_OPTION                    (XPUF_READ_FROM_RAM)
                                                        (or)
                                                (XPUF_READ_FROM_EFUSE_CACHE)
 This selects the location from where the helper data must be read by the
 application. This option must be configured if XPUF_KEY_GENERATE_OPTION
 is configured as XPUF_REGEN_ON_DEMAND.

 #define XPUF_CHASH                             (0x00000000)
 The length of CHASH should be 24 bits. It is valid only for PUF regeneration
 and invalid for PUF registration. CHASH value should be supplied if
 XPUF_READ_HD_OPTION is configured as XPUF_READ_FROM_RAM.

 #define XPUF_AUX                               (0x00000000)
 The length of AUX should be 32 bits. It is valid only for PUF regeneration
 and invalid for PUF registration. AUX value should be supplied if
 XPUF_READ_HD_OPTION is configured as XPUF_READ_FROM_RAM.

 #define XPUF_SYN_DATA_ADDRESS          (0x00000000)
 Address of syndrome data should be supplied if XPUF_READ_HD_OPTION is
 configured as XPUF_READ_FROM_RAM.

 #define XPUF_GLBL_VAR_FLTR_OPTION      (TRUE)
 It is recommended to always enable this option to ensure entropy. It can
 be configured as FALSE to disable Global Variation Filter.

 This file illustrates encryption of red key using PUF KEY and
 programming the black key and helper data in a user specified location
 To build the application, xilsecure, xilnvm and xilpuf must be in client mode.

Procedure to link and compile the example for the default ddr less designs

 The default linker settings places a software stack, heap and data in DDR memory. For this example to work,
 any data shared between client running on A72/R5/PL and server running on PMC, should be placed in area
 which is acccessible to both client and server.

 Following is the procedure to compile the example on OCM or any memory region which can be accessed by server

           1. Open example linker script(lscript.ld) in Vitis project and section to memory mapping should
                   be updated to point all the required sections to shared memory(OCM or TCM)
                   using a memory region drop down selection

                                           OR

           1. In linker script(lscript.ld) user can add new memory section in source tab as shown below
                   .sharedmemory : {
                   . = ALIGN(4);
                   __sharedmemory_start = .;
                   *(.sharedmemory)
                   *(.sharedmemory.*)
                   *(.gnu.linkonce.d.*)
                   __sharedmemory_end = .;
                   } > versal_cips_0_pspmc_0_psv_ocm_ram_0_psv_ocm_ram_0

           2. In this example ".data" section elements that are passed by reference to the server-side should
              be stored in the above shared memory section. To make it happen in below example,
              replace ".data" in attribute section with ".sharedmemory". For example,
   static XPuf_DataAddr PufData __attribute__ ((aligned (64U)) __attribute__ ((section (".data.PufData")));
                                   should be changed to
   static XPuf_DataAddr PufData __attribute__ ((aligned (64U)) __attribute__ ((section (".sharedmemory.PufData")));

 To keep things simple, by default the cache is disabled for this example