AN221111  PSoC™ 6 MCU designing a custom secured system  

A security plan is how you define access to your device. You can split this into two types, external and internal.

Before continuing, you must understand some terms that will be used throughout this document. Many of these terms will be discussed in more detail in the following sections of this application note.

eFuses are simple devices but an integral part of security for the PSoC™ 6 devices. There are 1024 eFuse bits which default to “0” and can only be programmed to a “1”. Once programmed, they cannot be erased back to “0” ever, not even by Infineon.

eFuse bits are stored in the programming file (intel hex) using the address range 0x9070_0000 to 0x9070_03FF. This range is virtual and cannot be used for direct read or write operations. The eFuse library uses the offset value to read 8 bits of eFuse data at a time.

Table 4 identifies the usage areas of interest in the eFuse block including the user area. Note that there is some difference in the eFuse usage between 1^st generation and 2^nd generation devices. Table 1 defines which family of parts belong to the 1^st and 2^nd generations devices

The device lifecycle is a key aspect of the PSoC™ 6 MCU’s security. Lifecycle stages follow a strict irreversible progression dictated by programming eFuses bits (changing a fuse’s value from ‘0’ to ‘1’). This system is used to protect the internal device data and code at the level required by the customer. Lifecycle stages are governed by the LIFECYCLE_STAGE eFuses and can only be advanced to the next lifecycle state as shown in Figure 1. For example, once in the SECURE lifecycle stage, the device can never return to the NORMAL or VIRGIN state.

Protection state and Lifecycle stage are the same unless there is an error during the boot process or the device is in the RMA Lifecycle. If there is an error during boot, the device will be moved to the “DEAD” protection state. Access to the debug ports in the DEAD protection state is defined by the Dead Access Restrictions (DAR).

Only the CM0+ CPU is started after a reset. It is up to the OEM’s CM0+ code to enable the CM4 after the boot sequence, if the default CM0+ startup code is not used. The default CM0+ is a binary that is provided, if the user doesn’t need to use the CM0+. It is not recommended to use for a secure system. The boot sequence differs depending on which lifecycle stage the device is in. As expected, the SECURE lifecycle stage is the only boot sequence that maintains a Chain of Trust (CoT). Figure 3 shows the different paths of the four basic boot sequences.

1. NORMAL (no validation, no code security)
2. NORMAL with Validate (no code security)
3. SECURE_WITH_DEBUG (debug only, not intended for final product)
4. SECURE

At the beginning of the Chain of Trust, must be immutable code that cannot be altered. This first immutable code is referred to as the “Root of Trust” (RoT). The initial ROM code validates the Flash Boot code in SFlash to verify that it hasn’t been modified, prior to any code execution in SFlash.

Flash boot, trim constants, and the Table of Contents1 (TOC1) are located in SFlash (Supervisory Flash) and are restricted from being reprogrammed in either NORMAL or SECURE lifecycle stages.

The SFlash area is validated with a Factory_HASH value stored in the eFuse. The Factory_HASH code is not used during the boot sequence in NORMAL or SECURE lifecycle stages, but is used to validate the part before moving to the SECURE lifecycle stage. This ensures that the Flash boot code, trim values, and the TOC1 has not been tampered with after the MCU has left Infineon. If the Factory_HASH has been corrupted, Infineon should be contacted immediately. See Appendix F - Debug codes for failed boot sequences.

After the transition from NORMAL to SECURE lifecycle stage, all blocks in the SFlash, including the public key area and the TOC2, are validated with the Secure_HASH each time the device boots. This secure hash is stored in the eFuse and cannot be changed without detection. If an error is found while validating the SFlash, the device will abort the boot sequence and enter a DEAD state. Figure 4 shows the CoT from the perspective of data and code validation.

At this point, the entire SFlash is now trusted because its validation is based on the memory (eFuse) that cannot be modified without detection during SFlash validation in the ROM.

The (OEM) public key, which is locked into the SFlash, is secure and cannot be changed without being detected as well. It is used by Flash boot to validate the next step in the boot process. Flash boot validates the code in the user application block, which includes a digital signature at the end of the code block. Flash boot uses the SHA-256 hash function to calculate the digest of the user application. The digital signature attached to the user application is encrypted using a private key that is associated with the public key stored in the SFlash. The encrypted hash uses RSA 2048-bit encryption.

The calculated and the stored digest (decrypted digital signature) are then checked to see whether they match. If they match, the user application has been verified.

In the Chain of Trust (CoT) section, code verification was mentioned but with not much detail. In this section, we will dive into the process of signing a block of code so that it can be verified during runtime. Infineon supports the signing of application code using the CyMCUElfTool which is downloaded with ModusToolbox™ software.

The encryption method used is PKC (public key cryptography) that has a private and public key pair. You must ensure that the private key is kept in a secure location, so that it never gets into the public domain. If the private key is exposed, it will endanger your system’s security. Companies must create a method in which very limited access to the private key is allowed.

The public key, on the other hand, can be viewed by anyone. The only requirement is that the public key must be validated or locked in such a way that it cannot be changed, or so that any modification to the public key can be detected. In this example, the public key is stored in the SFlash and verified with the Secure_HASH as defined in the Chain of Trust (CoT) section. These private and public keys can be generated with common encryption libraries such as OpenSSL.

Do the following to transition a PSoC™ 62/63 device to the SECURE lifecycle stage and use code signing:

1. Fill in TOC2 and add the 16-bit CRC at the end of TOC2 (SFlash).
2. Fill in the RSA-2048 public key (SFlash).
3. Use standard CYPRESS™ application format (user flash) at the beginning of the application (See section 4.2 for definition).
4. Sign your application bundle and place the 256-byte (2048 bits) digital signature at the end of the code (user flash).
5. Enable NORMAL lifecycle code verification or move to SECURE lifecycle stage.

It is HIGHLY recommended to test the code verification in the NORMAL lifecycle stage before switching to the SECURE lifecycle stage. In the NORMAL lifecycle stage, if something is incorrect with the code signing process, you can reprogram the TOC2, public key, and update your application. Once you switch to the SECURE lifecycle stage, you cannot alter the TOC2 or update the public key. You may not be able to change your application with the programmer if you closed your debug ports and your bootloader is not yet implemented.

For more information on generating and using the private and public keys, see Appendix A - Code example of a security application template.

This section provides a brief description of how the protection units work and how to use them. For a more detailed description of protection units, read the “Protection Units” chapter in the PSoC™ 6 MCU Architecture TRM (Technical Reference Manual)for your device.

PSoC™ 6 has several bus masters that all share a single bus that interconnects the flash, SRAM, ROM, GPIOs, and peripheral control registers. The bus masters include the two CPUs (CM0+ and CM4), DMA controllers (Data Wire), crypto unit, and the test controller. Bus arbitration hardware keeps the bus masters from bumping into each other, but the protection units keep them from reading and writing into each other’s memory space.

Protection units can be programmed to allow only specific CPUs and other bus masters to access only predefined memory segments and peripherals. If a bus master attempts to use a section of memory not allowed by the protection unit, a bus fault will occur. Because the two CPUs (CM4 and CM0+) share the same memory space in the PSoC™ 6 MCUs, the protection units guarantee that one CPU cannot affect the memory or peripherals allocated to the other if needed. Not all memory or peripherals must be allocated to just one CPU; by default, the entire memory space is shared between the two CPUs and sections can remain that way if desired.

Protection units can also be used to isolate memory for different tasks that run concurrently in an RTOS. Different sections of a boot process may also be another example of securing sections of memory. For example, you may want your bootloader to have access to write to the flash in the user application area, but deny the user application from overwriting writing code that is executing. Protection units can be configured to do just that. Figure 7 shows how the different protection units (SMPU, MPU, PPU) are connected relative to the bus masters, peripherals and system bus (AHB).

PSoC™ 6 has four types protections units:

• SMPU – Shared memory protection units
• MPU (Arm®) – Memory protection unit that are part of the CPU IP
• MPU (Infineon) – Memory protection unit for test controller and crypto block
• PPU – Peripheral protection unit (fixed and programmable)

See Appendix C - Debug port access settings for register and bit level definitions.

TOC2 is used to point to the location of the first and second executable applications. It has a redundant copy (RTOC2), each with its own CRC for validation. Each copy of TOC2 is on a separate flash page so that if one is corrupted during writing, it is unlikely that the other is corrupted. Flash boot uses the first one with a valid CRC. If both fail CRC validation, Flash boot will remain in a loop, ready to be reprogrammed if in the NORMAL lifecycle stage, or in a DEAD state if in the SECURE lifecycle stage. See the code snippet below for the definition of the TOC2 structure.

/* Table of Content structure */
typedef struct{
    volatile uint32_t objSize;     /* Object size (Bytes) */
    volatile uint32_t magicNum;    /* TOC ID (magic number = 0x01211220 ) */
    volatile uint32_t userKeyAddr; /* Secure key address in user Flash (optional) */
    volatile uint32_t smifCfgAddr; /* SMIF configuration structure (optional) */
    volatile uint32_t appAddr1;    /* First user application object address */
    volatile uint32_t appFormat1;  /* First user application format */
    volatile uint32_t appAddr2;    /* Second user application object address (optional) */
    volatile uint32_t appFormat2;  /* Second user application format (optional) */
    volatile uint32_t shashObj;    /* Number of additional objects to be verified(Secure-HASH) */
    volatile uint32_t sigKeyAddr;  /* Signature verification key address */
    volatile uint32_t addObj[116]; /* Additional objects to include in Secure-HASH */
    volatile uint32_t tocFlags;    /* Flags in TOC to control Flash boot options */
    volatile uint32_t crc;         /* CRC16-CCITT */
}cy_stc_ps_toc_t;

For a faster boot sequence, you can change the following two parameters:

• Boot clock frequency parameter “IMO/FLL clock frequency”
• Debug parameter “Wait Window Time”

Once in production, setting the wait window to 0 will speed up the overall boot time. These two parameters and others are part of the “tocFlags” variable in the cy_stc_ps_toc_t structure. Table 9 and Table 10 defines each of the parameters than can be set with the tocFlags element of the structure for the 1^st generation and 2^nd generation parts respectively.

Place the following code snippet in your CM0+ code (main.c) to generate the TOC2. There is also a redundant copy of the TOC2 that is an exact copy, RTOC2. You may need to make changes to this section of code to match your application.

/* Flashboot parameters stored in TOC2 for PSOC6ABLE2 devices */
#if defined(CY_DEVICE_PSOC6ABLE2)
#define CY_PS_FLASHBOOT_FLAGS ((CY_PS_FLASHBOOT_VALIDATE_YES << CY_PS_TOC_FLAGS_APP_VERIFY_POS)  \
		| (CY_PS_FLASHBOOT_WAIT_20MS << CY_PS_TOC_FLAGS_DELAY_POS) \
		| (CY_PS_FLASHBOOT_CLK_25MHZ << CY_PS_TOC_FLAGS_CLOCKS_POS))
#endif

/* Flashboot parameters stored in TOC2 for PSOC6A2M / PSoC6A512K devices */
#if defined(CY_DEVICE_PSOC6A2M) || defined(CY_DEVICE_PSOC6A512K)
#define CY_PS_FLASHBOOT_FLAGS ((CY_PS_FLASHBOOT_VALIDATE_YES << CY_PS_TOC_FLAGS_APP_VERIFY_POS)  \
		| (CY_PS_FLASHBOOT_WAIT_20MS << CY_PS_TOC_FLAGS_DELAY_POS) \
		| (CY_PS_FLASHBOOT_CLK_25MHZ << CY_PS_TOC_FLAGS_CLOCKS_POS) \
		| (CY_PS_FLASHBOOT_SWJ_PINS_ENABLE << CY_PS_TOC_FLAGS_SWJ_ENABLE_POS))
#endif

/* TOC2 in SFlash */
CY_SECTION(".cy_toc_part2") __USED static const cy_stc_ps_toc_t cy_toc2 =
{
	.objSize     = sizeof(cy_stc_ps_toc_t) - sizeof(uint32_t),  /* Object Size (Bytes) excluding CRC */
	.magicNum    = CY_PS_TOC2_MAGICNUMBER,                      /* TOC2 ID (magic number) */
	.userKeyAddr = (uint32_t)&CySecureKeyStorage,               /* User key storage address */
	.smifCfgAddr = 0UL,                                         /* SMIF config list pointer */
	.appAddr1    = CY_START_OF_FLASH,                           /* App1 (MCUBoot) start address */
	.appFormat1  = CY_PS_APP_FORMAT_CYPRESS,                    /* App1 Format */
	.appAddr2    = 0,                                           /* App2 (User App) start address */
	.appFormat2  = 0,                                           /* App2 Format */
	.shashObj    = 1UL,                                         /* Include public key in the SECURE HASH */
	.sigKeyAddr  = (uint32_t)&SFLASH->PUBLIC_KEY,               /* Address of signature verification key */
	.tocFlags    = CY_PS_FLASHBOOT_FLAGS,                       /* Flash boot flags stored in TOC2 */
	.crc         = 0UL                                          /* CRC populated by cymcuelftool at build time */
};

/* RTOC2 in SFlash, this is a duplicate of TOC2 for redundancy */
CY_SECTION(".cy_rtoc_part2") __USED static const cy_stc_ps_toc_t cy_rtoc2 =
{
	.objSize     = sizeof(cy_stc_ps_toc_t) - sizeof(uint32_t),  /* Object Size (Bytes) excluding CRC */
	.magicNum    = CY_PS_TOC2_MAGICNUMBER,                      /* TOC2 ID (magic number) */
	.userKeyAddr = (uint32_t)&CySecureKeyStorage,               /* User key storage address */
	.smifCfgAddr = 0UL,                                         /* SMIF config list pointer */
	.appAddr1    = CY_START_OF_FLASH,                           /* App1 (MCUBoot) start address */
	.appFormat1  = CY_PS_APP_FORMAT_CYPRESS,                    /* App1 Format */
	.appAddr2    = 0,                                           /* App2 (User App) start address */
	.appFormat2  = 0,                                           /* App2 Format */
	.shashObj    = 1UL,                                         /* Include public key in the SECURE HASH */
	.sigKeyAddr  = (uint32_t)&SFLASH->PUBLIC_KEY,               /* Address of signature verification key */
	.tocFlags    = CY_PS_FLASHBOOT_FLAGS,                       /* Flash boot flags stored in TOC2 */
	.crc         = 0UL                                          /* CRC populated by cymcuelftool at build time */
};

The initial project that is executed after Flash boot must be validated with a public RSA crypto key. To do this, the application must use the CYPRESS™ standard application format that includes a digital signature. This allows Flash boot to perform the validation during the boot process before the application is executed. The application format encapsulates the application binary, application metadata, and an encrypted digital signature. The user application includes both the CM0+ and CM4, see Figure 11.

Table 11 provides the details of the header section. It defines the total size, the number of cores, the type of application, and the offset to each core application vector table.

To generate proper values for the application header, an instance of the cy_stc_appheader_t structure must be included in the project. An example of this structure can be seen in the code example at proj_btldr_cm0p/main.c source file. Although the header supports images for multiple CPU images, the bootloader in the example only includes an image for the CM0+.

/***************************************
 *   Application header and signature
 ***************************************/
#define CY_PS_VT_OFFSET     ((uint32_t)(&__Vectors[0]) - CY_START_OF_FLASH \
        - offsetof(cy_stc_ps_appheader_t, core0Vt)) /* CM0+ VT Offset */
#define CY_PS_CPUID         (0xC6000000UL)          /* CM0+ ARM CPUID[15:4] Reg shifted to [31:20] */
#define CY_PS_CORE_IDX      (0UL)                   /* Index ID of the CM0+ core */

/** Secure Application header */
CY_SECTION(".cy_app_header") __USED
        static const cy_stc_ps_appheader_t cy_ps_appHeader = {
                .objSize        = CY_BOOT_BOOTLOADER_SIZE - CY_PS_SECURE_DIGSIG_SIZE,
                .appId          = (CY_PS_APP_VERSION | CY_PS_APP_ID_SECUREIMG),
                .appAttributes  = 0UL,                          /* Reserved */
                .numCores       = 1UL,                          /* Only CM0+ */
                .core0Vt        = CY_PS_VT_OFFSET,              /* CM0+ VT offset */
                .core0Id        = CY_PS_CPUID | CY_PS_CORE_IDX, /* CM0+ core ID */
};

/* Secure Digital signature (Populated by cymcuelftool) */
CY_SECTION(".cy_app_signature") __USED CY_ALIGN(4)
static const uint8_t cy_ps_appSignature[CY_PS_SECURE_DIGSIG_SIZE] = {0u};

You should update the MAJOR and MINOR version constants in the cy_ps_config.h file (see code example) to the required value. The CY_USERAPP_ID is up to you; it should be between 0x0000 and 0x7FFF.

To generate the digital signature in the code, use the following. It will place the signature in the last 256 bytes of the user code area. For a complete example of creating and adding the public key, see Appendix B - Creating crypto key pairs.

/* Secure digital signature (Populated by cymcuelftool) */
CY_SECTION(".cy_app_signature") __USED CY_ALIGN(4)
static const uint8_t cy_ps_appSignature[CY_PS_SECURE_DIGSIG_SIZE] = {0u};

The SFlash region stores the public key. It is stored in a binary format, not the ASCII format generated by OpenSSL. The modulus, exponent, and three coefficients are pre-calculated to speed up the validation. Figure 12 shows the format.

The key is stored in three structures:

1. The first structure “Key” is stored as an object that can easily be included in the Secure_HASH calculation. The “Signature Scheme” defines the structure of the key.
   • This example uses RSASA-PKCS1-v1_5-2048. The “Object Size” contains the full size of the public key object, which contains the entire three structures.
2. The second structure contains the individual pieces of the public key: coefficients (K1, K2, K3), exponent (E), and modulus (N). These values must be stored in a little-endian list of bytes. OpenSSL generates these values in a big-endian format.
3. The third structure is a list of pointers to each piece of the public key, which is the format required for a call to the Crypto driver. The key is stored in this expanded to speed up the code verification process.

For the companion code example (CE234992), there is already a default key generated. This will work fine for development, but you should not use this for production. To generate a new custom key pair, see Appendix B - Creating crypto key pairs, section 8.1.

Code that is used to generate eFuse data can be found in companion code example (CE234992) at /proj_btldr_cm0p/source/cy_ps_efuse.c. This file contains the structures that compile and create the eFuse data. By default, no eFuse data will be generated, just in case the project is compiled and programmed by accident. To enable eFuse programming, a line in cy_ps_efuse.h must be changed from:

“#define CY_EFUSE_AVAILABLE (0)”

to

“#define CY_EFUSE_AVAILABLE (1)”.

A byte of data is required to program each bit of the eFuse. The following pattern is used to program, validate, or set as ‘don’t care’ each bit of eFuse.

/* EFUSE bit action macros */
#define CY_EFUSE_STATE_SET       (0x01U) /* Tell programmer to set the EFUSE bit */
#define CY_EFUSE_STATE_UNSET     (0x00U) /* Tell programmer to check that the EFUSE bit is not set */
#define CY_EFUSE_STATE_IGNORE    (0xffU) /* Tell programmer to ignore the EFUSE bit */

Find the section shown below in the file cy_ps_efuse.c. This is where you change the lifecycle to either SECURE_WITH_DEBUG or SECURE, you can only set one of these bits. If one of these two bits is already set, the programmer will not program the other. To program the SECURE or SECURE_WITH_DEBUG bit, change the constant CY_EFUSE_STATE_IGNORE to CY_EFUSE_STATE_SET. The NORMAL bit will already be set from the factory and should remain as “CY_EFUSE_STATE_IGNORE”.

    .LIFECYCLE_STAGE =
    {
        CY_EFUSE_STATE_IGNORE,        /* NORMAL lifecycle already set - ignore */
        CY_EFUSE_STATE_IGNORE,        /* SECURE_WITH_DEBUG lifecycle */
        CY_EFUSE_STATE_IGNORE,        /* SECURE life cycle */
        CY_EFUSE_STATE_IGNORE,        /* Infineon use only - ignore */
        CY_EFUSE_LIFECYCLE_RESERVED0  /* Reserved bits ignored */
    },

This flow assumes that the device has already been moved to the SECURE lifecycle stage.

1. CM0+ starts from reset.
2. CM0+ executes the internal ROM code that does the following:
   • Loads the trim values
   • Verifies that the second half of the boot code (Flash boot) and the user’s public key are intact
3. The Flash boot code verifies that the user’s bootloader (proj_btldr_cm0p) is signed by the owner of the public key (RSA-2048) and that the code has not been corrupted.
4. Jumps to the bootloader.

   
   

5. The bootloader configures the protection units to isolate CM0+ and CM4 projects.
   • Review the code in the /proj_btldr_cm0p/cy_ps_prot_units.c file to learn how the SMPUs and Protection Context registers are set up.
6. The code checks to see if there is a newer version of the user application bundle, which includes both the CM0+ and CM4 applications. If a newer version is available, the code does the following:
   1. Copies the new firmware image to the primary slot
   2. Validates the new firmware image with the ECC key
   3. If the image is verified, jumps to the user CM0+ project (proj_cm0p)
7. The CM0+ application enables CM4 and continues to execute its application.
   • In the associated code examples that is used to demonstrate the firmware flow, the CM0+ application is nothing more than a LED blink application. You can remove these two lines of code and replace it with your own application.
8. CM4 comes out of reset, and does the following:
   1. Configures the required hardware
   2. Initializes a few FreeRTOS tasks

One of these tasks is the DFU (device firmware upgrade), which listens on a serial port waiting for a command to start the download of a new version of the application bundle.

The following diagram illustrates the Chain of Trust for this project. Note that there are two different types of crypto keys used to validate the full application. The PSoC™ 62/63 MCU natively uses an RSA-2048 key; the bootloader based on MCUboot uses ECC by default.

The memory map for the example project is shown below. The diagrams also show the access of the memory by the protection context.

The flash memory is broken up into four major areas:

• Bootloader
• Protected memory
• Primary slot
• Secondary slot

The bootloader area is not intended to be updated in the field and therefore must be thoroughly tested before release. Most of the code in the bootloader area is a port from MCUboot, the industry standard bootloader infrastructure.

The protected memory region contains the sensitive data; only CM0+ has direct access to it. While some of this data could be preprogrammed from the factory, other parts could be used for dynamic storage.

The primary slot is the area in which the application code is executed. Both CM0+ and CM4 execute code in this region. Only CM0+ can write to this area while executing the bootloader; CM4 cannot write to this region.

The secondary slot is the area used to store an updated project. In most applications, it is up to CM4 to perform the operation because it is most likely to be the CPU communicating to the outside world via Wi-Fi, Bluetooth®, or DFU. If required, the CM0+ application code can update the code in the secondary slot.

The companion code example (CE234992) includes a default key that is already generated. This key is sufficient for development, but do not use this for production. These steps will generate a custom private/public key pair in the keys directory and generate a C-compatible public key, but you must manually copy the generated C code to the cy_ps_keystorage.c file.

Do the following to generate a new custom key pair:

1. Start the “modus-shell” application that is installed along with ModusToolbox™ software.
2. Navigate to mtb-psoc6-example-security/proj_btldr_cm0p directory.
3. Execute the command make rsa_keygen.
   • This command creates a file in the keys subdirectory called rsa_to_c_generated.txt.
4. Copy the following arrays from the rsa_to_c_generated.txt file and replace those in cy_ps_keystorage.c.
   • .moduleData[]
   • .expData[]
   • .barrettData[]
   • .inverseModuleData[]
   • .rBarData[]

Generating the ECC key pair required for the bootloader (MCUboot) is similar to the RSA key pair generation but simpler.

1. Start the modus-shell application.
2. Navigate to the mtb-psoc6-example-security/bootloader_cmp0 directory.
3. Execute the command make ecc_keygen.

This will create the following files in the keys folder:

• cypress-test-ec-p256.pem (private key)
• cypress-test-ec-p256.pub (public key in a C-like array)
• ecc-public-key-p256.h (public-key header file in C-like array)

The public key will automatically be incorporated into the MCUboot build, you do not need to edit the files.

The following is an example of the cy_ps_keystorage.c file. The sections shown in italics are areas that need to be replaced with the contents of the rsa_to_c_generated.txt file after running the make rsa_keygen command.

The final step to updating the public key in the secure image is to copy the code in the generated rsa_to_c_generated.txt file to the cy_keystorage.c source file, which is part of the secure image project.

An example of this file after being updated is shown below. The replacement code from the generated key data is shown below in italics.

/***************************************************************************//**
* \file cy_ps_keystorage.c
* \version 1.20
*
* \brief
* Secure key storage for application usage.
*
********************************************************************************
* \copyright
* Copyright 2017-2018, Cypress Semiconductor Corporation. All rights reserved.
* You may use this file only in accordance with the license, terms, conditions,
* disclaimers, and limitations in the end user license agreement accompanying
* the software package with which this file was provided.
*******************************************************************************/

#include <source/cy_ps_keystorage.h>

#if defined(__cplusplus)
extern "C" {
#endif

/* Secure Key Storage (Note: Ensure that the alignment matches the Protection unit configuration) */
CY_ALIGN(1024) __USED const uint8_t CySecureKeyStorage[CY_PS_SECURE_KEY_ARRAY_SIZE][CY_PS_SECURE_KEY_LENGTH] = {
    {0x00u}, /* Insert user key #1 values */
    {0x00u}, /* Insert user key #2 values */
    {0x00u}, /* Insert user key #3 values */
    {0x00u}  /* Insert user key #4 values */
};

/* Public key in SFlash */
CY_SECTION(".cy_sflash_public_key") __USED const cy_ps_stc_public_key_t cy_publicKey =
{
    .objSize = sizeof(cy_ps_stc_public_key_t),
    .signatureScheme = CY_PS_PUBLIC_KEY_RSA_2048,
    .publicKeyStruct =
    {
        .moduloAddr         = (uint32_t)&(SFLASH->PUBLIC_KEY) + offsetof(cy_ps_stc_public_key_t, moduloData),
        .moduloSize         = CY_PS_PUBLIC_KEY_SIZEOF_BYTE * CY_PS_PUBLIC_KEY_MODULOLENGTH,
        .expAddr            = (uint32_t)&(SFLASH->PUBLIC_KEY) + offsetof(cy_ps_stc_public_key_t, expData),
        .expSize            = CY_PS_PUBLIC_KEY_SIZEOF_BYTE * CY_PS_PUBLIC_KEY_EXPLENGTH,
        .barrettAddr        = (uint32_t)&(SFLASH->PUBLIC_KEY) + offsetof(cy_ps_stc_public_key_t, barrettData),
        .inverseModuloAddr  = (uint32_t)&(SFLASH->PUBLIC_KEY) + offsetof(cy_ps_stc_public_key_t, inverseModuloData),
        .rBarAddr           = (uint32_t)&(SFLASH->PUBLIC_KEY) + offsetof(cy_ps_stc_public_key_t, rBarData),
    },
    .moduloData =
    {
        0x33u, 0xF4u, 0x36u, 0x09u, 0x00u, 0x61u, 0x17u, 0xA1u,
        0xE6u, 0x42u, 0x42u, 0x97u, 0x76u, 0x2Au, 0xABu, 0xEFu,
        0xD3u, 0x27u, 0xA0u, 0x8Au, 0x5Bu, 0x1Au, 0x2Bu, 0x2Eu,
        0x8Au, 0x10u, 0xE8u, 0xCCu, 0xE4u, 0x57u, 0x77u, 0x54u,
        0x60u, 0x88u, 0xB0u, 0x01u, 0xFDu, 0x79u, 0x7Eu, 0xEAu,
        0x30u, 0x6Fu, 0x8Eu, 0x2Cu, 0x79u, 0x1Cu, 0xCBu, 0xDBu,
        0xC7u, 0x02u, 0xA0u, 0x4Cu, 0x1Eu, 0x75u, 0x00u, 0xCCu,
        0x49u, 0x1Eu, 0xBBu, 0x6Eu, 0x1Eu, 0x6Au, 0xFAu, 0x64u,
        0xDAu, 0xA0u, 0xB1u, 0x41u, 0x70u, 0xFDu, 0xA0u, 0x47u,
        0x82u, 0x27u, 0x9Au, 0xF2u, 0xF3u, 0x34u, 0xB7u, 0xEBu,
        0x92u, 0x33u, 0x5Eu, 0x2Cu, 0x37u, 0xDCu, 0x08u, 0x8Cu,
        0x70u, 0xB0u, 0x31u, 0x1Bu, 0xF1u, 0xE4u, 0x51u, 0x03u,
        0x4Eu, 0xC6u, 0xF9u, 0xBFu, 0xBEu, 0x33u, 0xF7u, 0xB8u,
        0x9Fu, 0x1Au, 0x83u, 0xD9u, 0x6Fu, 0xE0u, 0xE0u, 0x0Cu,
        0xC5u, 0x38u, 0x00u, 0xE4u, 0xB7u, 0x5Bu, 0x76u, 0x57u,
        0x64u, 0x80u, 0x1Fu, 0x31u, 0xE6u, 0x73u, 0x87u, 0x80u,
        0xC7u, 0x8Cu, 0xB0u, 0x44u, 0xC7u, 0x39u, 0x19u, 0xC6u,
        0x8Eu, 0x32u, 0x0Au, 0x82u, 0x2Au, 0xB9u, 0x4Cu, 0x0Cu,
        0xC5u, 0x3Du, 0x64u, 0xC9u, 0x91u, 0xCEu, 0x62u, 0x82u,
        0x21u, 0xFCu, 0xFAu, 0x2Cu, 0x1Eu, 0xB1u, 0xD0u, 0x54u,
        0x27u, 0x45u, 0x2Eu, 0x46u, 0x4Eu, 0xEFu, 0x4Au, 0x52u,
        0xC1u, 0x8Fu, 0xBBu, 0xAFu, 0xBDu, 0xFEu, 0xBEu, 0xDFu,
        0x15u, 0x26u, 0xDBu, 0x37u, 0x24u, 0x85u, 0x15u, 0x8Cu,
        0xFDu, 0xD9u, 0xEBu, 0x7Fu, 0x17u, 0x30u, 0x3Bu, 0x95u,
        0x15u, 0x59u, 0xEEu, 0xECu, 0xA1u, 0xEBu, 0x4Fu, 0xCAu,
        0xD1u, 0x60u, 0x21u, 0xE0u, 0x1Bu, 0xD6u, 0xB9u, 0x0Eu,
        0xADu, 0xF7u, 0x87u, 0x7Cu, 0x9Cu, 0x57u, 0x3Bu, 0x32u,
        0x79u, 0x51u, 0x3Bu, 0x05u, 0x80u, 0x21u, 0xB8u, 0x21u,
        0xCAu, 0x49u, 0x53u, 0x93u, 0xA2u, 0x22u, 0x9Bu, 0x10u,
        0x68u, 0xA1u, 0xE5u, 0x8Eu, 0xE8u, 0x02u, 0xE9u, 0x29u,
        0x62u, 0xCFu, 0x05u, 0xB1u, 0xBBu, 0xB9u, 0xCFu, 0x07u,
        0xF5u, 0x75u, 0x4Du, 0x16u, 0x07u, 0xA0u, 0xCCu, 0xB7u,
    },
    .expData =
    {
        0x01u, 0x00u, 0x01u, 0x00u,
    },
    .barrettData =
    {
        0xDCu, 0x40u, 0x33u, 0x8Au, 0x4Eu, 0xA6u, 0xF1u, 0x08u,
        0x2Au, 0x7Bu, 0x5Cu, 0x77u, 0xC9u, 0xB1u, 0x95u, 0x68u,
        0x94u, 0xF2u, 0x80u, 0x0Eu, 0xA7u, 0x99u, 0xE5u, 0xBDu,
        0x07u, 0x91u, 0x0Cu, 0x66u, 0x62u, 0x3Du, 0x1Eu, 0x02u,
        0x6Cu, 0x12u, 0x3Bu, 0x79u, 0xE0u, 0xB6u, 0x81u, 0xB4u,
        0xACu, 0x85u, 0x75u, 0x44u, 0x95u, 0x0Du, 0xC7u, 0xE9u,
        0x69u, 0x7Du, 0xD3u, 0x30u, 0x4Bu, 0x57u, 0x4Du, 0x2Fu,
        0x6Eu, 0x80u, 0x51u, 0xC0u, 0x72u, 0x4Bu, 0x23u, 0x76u,
        0x82u, 0x91u, 0x98u, 0x47u, 0xFEu, 0x4Fu, 0xBCu, 0xBFu,
        0xA5u, 0x84u, 0x26u, 0xF0u, 0x90u, 0x62u, 0xC1u, 0x0Fu,
        0xFAu, 0x81u, 0xBAu, 0x57u, 0xDFu, 0x98u, 0x00u, 0xE3u,
        0xC6u, 0xACu, 0x99u, 0x82u, 0xFAu, 0x29u, 0x61u, 0xF3u,
        0x37u, 0x7Au, 0x61u, 0x09u, 0x25u, 0x92u, 0xCFu, 0xDFu,
        0x17u, 0x20u, 0x46u, 0x8Du, 0xBFu, 0x88u, 0xE7u, 0x0Bu,
        0xB5u, 0xAFu, 0xCEu, 0x03u, 0x8Au, 0xEAu, 0x33u, 0xC4u,
        0x8Cu, 0x1Bu, 0x44u, 0x41u, 0xC6u, 0x9Au, 0xCDu, 0x57u,
        0x5Fu, 0x59u, 0x6Eu, 0x1Eu, 0x1Cu, 0xDBu, 0xD7u, 0x37u,
        0x38u, 0x98u, 0xF6u, 0x0Bu, 0x3Du, 0xCDu, 0x11u, 0xA5u,
        0xF0u, 0x1Fu, 0x13u, 0x3Eu, 0x46u, 0x0Bu, 0xADu, 0x07u,
        0xA3u, 0x6Fu, 0x8Fu, 0xD5u, 0xCEu, 0xD8u, 0xA6u, 0x36u,
        0x8Eu, 0x39u, 0xDCu, 0xDCu, 0x07u, 0x6Fu, 0xE8u, 0x3Au,
        0x64u, 0x71u, 0x10u, 0xE1u, 0xCDu, 0x20u, 0xDFu, 0x4Bu,
        0xC8u, 0xA3u, 0x1Bu, 0x89u, 0x20u, 0x35u, 0x51u, 0x8Fu,
        0xA6u, 0x48u, 0x1Au, 0xF5u, 0xD5u, 0xF2u, 0x65u, 0x8Fu,
        0x3Au, 0x55u, 0x3Fu, 0x7Eu, 0x4Bu, 0x44u, 0x7Fu, 0xBAu,
        0x27u, 0xF4u, 0x19u, 0x2Cu, 0x53u, 0x06u, 0x75u, 0xB8u,
        0xB8u, 0xC4u, 0x8Fu, 0xCBu, 0xC9u, 0xE5u, 0xFBu, 0x91u,
        0xAAu, 0x4Du, 0x3Bu, 0xD2u, 0xA3u, 0x2Au, 0x36u, 0x2Fu,
        0xC9u, 0xBFu, 0xCCu, 0x8Du, 0xF9u, 0x3Eu, 0x5Fu, 0x9Eu,
        0xEEu, 0x19u, 0xF0u, 0xD5u, 0x58u, 0xE0u, 0x07u, 0x1Bu,
        0xBDu, 0xF1u, 0x42u, 0xF9u, 0xB2u, 0xC9u, 0x07u, 0x3Cu,
        0x44u, 0x67u, 0xD5u, 0x32u, 0x00u, 0x14u, 0x90u, 0x64u,
        0x01u, 0x00u, 0x00u, 0x00u,
    },
    .inverseModuloData =
    {
        0x05u, 0xD9u, 0x5Au, 0x11u, 0xBDu, 0x82u, 0x6Au, 0x74u,
        0x24u, 0x61u, 0xBBu, 0x30u, 0x03u, 0x6Du, 0x5Bu, 0xEDu,
        0x61u, 0xCEu, 0x5Cu, 0x32u, 0xBBu, 0x1Du, 0x3Fu, 0x38u,
        0xB8u, 0x75u, 0x36u, 0x1Au, 0x6Cu, 0x2Du, 0x46u, 0x3Cu,
        0x1Au, 0x61u, 0xE1u, 0x63u, 0x2Cu, 0x8Fu, 0x49u, 0x80u,
        0xCAu, 0xFFu, 0x51u, 0x5Fu, 0xC6u, 0x2Au, 0x2Au, 0x38u,
        0xCFu, 0x6Du, 0x35u, 0x87u, 0xBCu, 0x74u, 0x47u, 0x2Fu,
        0xE5u, 0x7Fu, 0xC3u, 0x18u, 0x8Du, 0x9Au, 0x60u, 0xCAu,
        0xEFu, 0x84u, 0x2Eu, 0xF2u, 0x6Eu, 0x8Du, 0x88u, 0xC3u,
        0x13u, 0x9Du, 0x4Eu, 0x81u, 0x34u, 0xFDu, 0x21u, 0x18u,
        0xDDu, 0xE7u, 0xD3u, 0x71u, 0x51u, 0x49u, 0x6Eu, 0xF9u,
        0x24u, 0xAFu, 0x4Eu, 0x94u, 0x23u, 0xD8u, 0x05u, 0x64u,
        0x42u, 0x74u, 0x48u, 0x02u, 0x54u, 0x8Bu, 0xE4u, 0x7Bu,
        0xA9u, 0x69u, 0x3Du, 0x56u, 0xF0u, 0xD1u, 0xA0u, 0x39u,
        0x86u, 0x11u, 0x1Eu, 0xEFu, 0x0Bu, 0x64u, 0x60u, 0x7Du,
        0x32u, 0x8Fu, 0x4Bu, 0x01u, 0xC6u, 0x8Eu, 0x84u, 0x8Du,
        0xAFu, 0xD6u, 0x1Du, 0x0Fu, 0x1Cu, 0x38u, 0x15u, 0x4Bu,
        0xF3u, 0x8Cu, 0xB1u, 0xF0u, 0x05u, 0x96u, 0xFAu, 0x97u,
        0x22u, 0x4Eu, 0x2Du, 0x6Bu, 0xDBu, 0x7Du, 0x31u, 0x92u,
        0x8Eu, 0x3Bu, 0x33u, 0x5Bu, 0xA2u, 0xFDu, 0xF8u, 0x12u,
        0x55u, 0x15u, 0xD3u, 0x39u, 0xE3u, 0x83u, 0x48u, 0xA8u,
        0x02u, 0x46u, 0x40u, 0x17u, 0x92u, 0x4Du, 0x89u, 0x6Du,
        0x86u, 0xCCu, 0x40u, 0x07u, 0x16u, 0x82u, 0x68u, 0xE7u,
        0x28u, 0xB6u, 0xF9u, 0x52u, 0xFCu, 0x8Fu, 0x84u, 0x84u,
        0x4Bu, 0xBBu, 0x7Bu, 0x20u, 0xEEu, 0x3Du, 0x14u, 0x26u,
        0x5Eu, 0x17u, 0xC7u, 0xFFu, 0x4Eu, 0xBAu, 0xAEu, 0x81u,
        0x36u, 0x1Du, 0x10u, 0xE1u, 0x37u, 0x25u, 0xBEu, 0x02u,
        0x84u, 0x09u, 0x54u, 0xC8u, 0xD5u, 0x09u, 0x78u, 0xD4u,
        0x34u, 0x4Au, 0x03u, 0x5Bu, 0xA3u, 0x6Du, 0xEEu, 0x36u,
        0xACu, 0xF2u, 0xE9u, 0x3Eu, 0x67u, 0xF4u, 0xD0u, 0xA5u,
        0x1Cu, 0x32u, 0xDEu, 0x56u, 0x84u, 0x5Cu, 0xB6u, 0xA7u,
        0xE3u, 0x3Du, 0xF6u, 0xC2u, 0x44u, 0xFDu, 0xFAu, 0xC0u,
    },
    .rBarData =
    {
        0xCDu, 0x0Bu, 0xC9u, 0xF6u, 0xFFu, 0x9Eu, 0xE8u, 0x5Eu,
        0x19u, 0xBDu, 0xBDu, 0x68u, 0x89u, 0xD5u, 0x54u, 0x10u,
        0x2Cu, 0xD8u, 0x5Fu, 0x75u, 0xA4u, 0xE5u, 0xD4u, 0xD1u,
        0x75u, 0xEFu, 0x17u, 0x33u, 0x1Bu, 0xA8u, 0x88u, 0xABu,
        0x9Fu, 0x77u, 0x4Fu, 0xFEu, 0x02u, 0x86u, 0x81u, 0x15u,
        0xCFu, 0x90u, 0x71u, 0xD3u, 0x86u, 0xE3u, 0x34u, 0x24u,
        0x38u, 0xFDu, 0x5Fu, 0xB3u, 0xE1u, 0x8Au, 0xFFu, 0x33u,
        0xB6u, 0xE1u, 0x44u, 0x91u, 0xE1u, 0x95u, 0x05u, 0x9Bu,
        0x25u, 0x5Fu, 0x4Eu, 0xBEu, 0x8Fu, 0x02u, 0x5Fu, 0xB8u,
        0x7Du, 0xD8u, 0x65u, 0x0Du, 0x0Cu, 0xCBu, 0x48u, 0x14u,
        0x6Du, 0xCCu, 0xA1u, 0xD3u, 0xC8u, 0x23u, 0xF7u, 0x73u,
        0x8Fu, 0x4Fu, 0xCEu, 0xE4u, 0x0Eu, 0x1Bu, 0xAEu, 0xFCu,
        0xB1u, 0x39u, 0x06u, 0x40u, 0x41u, 0xCCu, 0x08u, 0x47u,
        0x60u, 0xE5u, 0x7Cu, 0x26u, 0x90u, 0x1Fu, 0x1Fu, 0xF3u,
        0x3Au, 0xC7u, 0xFFu, 0x1Bu, 0x48u, 0xA4u, 0x89u, 0xA8u,
        0x9Bu, 0x7Fu, 0xE0u, 0xCEu, 0x19u, 0x8Cu, 0x78u, 0x7Fu,
        0x38u, 0x73u, 0x4Fu, 0xBBu, 0x38u, 0xC6u, 0xE6u, 0x39u,
        0x71u, 0xCDu, 0xF5u, 0x7Du, 0xD5u, 0x46u, 0xB3u, 0xF3u,
        0x3Au, 0xC2u, 0x9Bu, 0x36u, 0x6Eu, 0x31u, 0x9Du, 0x7Du,
        0xDEu, 0x03u, 0x05u, 0xD3u, 0xE1u, 0x4Eu, 0x2Fu, 0xABu,
        0xD8u, 0xBAu, 0xD1u, 0xB9u, 0xB1u, 0x10u, 0xB5u, 0xADu,
        0x3Eu, 0x70u, 0x44u, 0x50u, 0x42u, 0x01u, 0x41u, 0x20u,
        0xEAu, 0xD9u, 0x24u, 0xC8u, 0xDBu, 0x7Au, 0xEAu, 0x73u,
        0x02u, 0x26u, 0x14u, 0x80u, 0xE8u, 0xCFu, 0xC4u, 0x6Au,
        0xEAu, 0xA6u, 0x11u, 0x13u, 0x5Eu, 0x14u, 0xB0u, 0x35u,
        0x2Eu, 0x9Fu, 0xDEu, 0x1Fu, 0xE4u, 0x29u, 0x46u, 0xF1u,
        0x52u, 0x08u, 0x78u, 0x83u, 0x63u, 0xA8u, 0xC4u, 0xCDu,
        0x86u, 0xAEu, 0xC4u, 0xFAu, 0x7Fu, 0xDEu, 0x47u, 0xDEu,
        0x35u, 0xB6u, 0xACu, 0x6Cu, 0x5Du, 0xDDu, 0x64u, 0xEFu,
        0x97u, 0x5Eu, 0x1Au, 0x71u, 0x17u, 0xFDu, 0x16u, 0xD6u,
        0x9Du, 0x30u, 0xFAu, 0x4Eu, 0x44u, 0x46u, 0x30u, 0xF8u,
        0x0Au, 0x8Au, 0xB2u, 0xE9u, 0xF8u, 0x5Fu, 0x33u, 0x48u,
    },
};

#if defined(__cplusplus)
}
#endif

The format for all three types of access restrictions (SECURE, DEAD, NORMAL) is the same, although stored in different locations. The default state of all debug access restrictions is zero, which means that all debug ports are open for full access.

This section defines the location and definition of each of those parameters. Figure 19 and Figure 20 represent the format for the 2-byte access restriction structure.

Table 14 Access restriction parameters.

If any of the three debug access ports (CM0+, CM4, SYS) are disabled in the SECURE life cycle stage, there is no way to connect to those ports. If any of the debug ports are not disabled in the SECURE life cycle stage, it is possible for the debug port to be opened either automatically or with firmware. You can disable any combination of the three access ports, and the ports not disabled may be connected to an external programmer/debugger. The 2^nd generation parts are slightly different than the 1^st generation parts as described in the following sections.

A byte of data is required to program each bit of the eFuse. The following pattern is used to program, validate, or set as ‘don’t care’ each bit of eFuse.

/* EFUSE bit action macros */
#define CY_EFUSE_STATE_SET       (0x01U) /* Tell programmer to set the EFUSE bit */
#define CY_EFUSE_STATE_UNSET     (0x00U) /* Tell programmer to check that the EFUSE bit is not set */
#define CY_EFUSE_STATE_IGNORE    (0xffU) /* Tell programmer to ignore the EFUSE bit */

The following code snippet is an example of how to set the SARs by programming the eFuse for the 1^st generation parts. The full source is available in the mtb-psoc6-example-security/proj_btldr_cm0p/source/cy_ps_efuse.c file. Note that this code snippet also sets the device to move to the SECURE lifecycle stage, be setting the SECURE bit toward the bottom of the structure.

/* EFuse configuration */
 CY_SECTION(".cy_efuse") __USED const cy_stc_efuse_data_t cy_efuseData =

{
    .RESERVED = CY_EFUSE_RESERVED0,                         /* Reserved bits ignored */

/* Dead access restrictions are set in this section */
/* CM40+ and CM4 debug are disabled, but SYS_AP is left open. */
.DEAD_ACCESS_RESTRICT0 =
    {
        .CM0_DISABLE       = CY_EFUSE_STATE_SET,              /* Disable CM0+ access port */
        .CM4_DISABLE       = CY_EFUSE_STATE_SET,              /* Disable CM4 access port */
        .SYS_DISABLE       = CY_EFUSE_STATE_SET,              /* Enable System access port */
        .SYS_AP_MPU_ENABLE = CY_EFUSE_STATE_UNSET,            /* Enable the system access port MPU */
        .SFLASH_ALLOWED    = CY_EFUSE_SFLASH_ALLOWED_ENTIRE,  /* SYS AP MPU protection of SFlash */
        .MMIO_ALLOWED      = CY_EFUSE_MMIO_ALLOWED_ENTIRE,    /* SYS AP MPU protection of MMIO */
    },
.DEAD_ACCESS_RESTRICT1 =
    {
        .FLASH_ALLOWED    = CY_EFUSE_FLASH_ALLOWED_ENTIRE,    /* SYS AP MPU protection of Flash */
        .SRAM_ALLOWED     = CY_EFUSE_SRAM_ALLOWED_ENTIRE,     /* SYS AP MPU protection of SRAM */
        .SMIF_XIP_ALLOWED = CY_EFUSE_SMIF_XIP_ALLOWED_ENTIRE, /* SYS AP MPU protection of SMIF XIP */
        .DIRECT_EXECUTE_DISABLE = CY_EFUSE_STATE_UNSET        /* Disable "direct execute" system call */
    },
/* Secure access restrictions are set in this section */
/* All debug ports are disabled here. */

.SECURE_ACCESS_RESTRICT0 =
    {
        .CM0_DISABLE       = CY_EFUSE_STATE_SET,              /* Disable CM0+ access port */
        .CM4_DISABLE       = CY_EFUSE_STATE_SET,              /* Disable CM4 access port */
        .SYS_DISABLE       = CY_EFUSE_STATE_SET,              /* Enable System access port */
        .SYS_AP_MPU_ENABLE = CY_EFUSE_STATE_UNSET,            /* Enable the system access port MPU */
        .SFLASH_ALLOWED    = CY_EFUSE_SFLASH_ALLOWED_ENTIRE,  /* SYS AP MPU protection of SFlash */
        .MMIO_ALLOWED      = CY_EFUSE_MMIO_ALLOWED_ENTIRE,    /* SYS AP MPU protection of MMIO */
    },
.SECURE_ACCESS_RESTRICT1 =
    {
        .FLASH_ALLOWED    = CY_EFUSE_FLASH_ALLOWED_ENTIRE,    /* SYS AP MPU protection of Flash */
        .SRAM_ALLOWED     = CY_EFUSE_SRAM_ALLOWED_ENTIRE,     /* SYS AP MPU protection of SRAM */
        .SMIF_XIP_ALLOWED = CY_EFUSE_SMIF_XIP_ALLOWED_ENTIRE, /* SYS AP MPU protection of SMIF XIP */
        .DIRECT_EXECUTE_DISABLE = CY_EFUSE_STATE_UNSET        /* Disable "direct execute" system call */
    },

/* This section sets the Life cycle to SECURE  */
/* You can only set either the “SECURE_WITH_DEBUG” or the “SECURE” bit but not both */
.LIFE CYCLE_STAGE =
    {
        .NORMAL            = CY_EFUSE_STATE_IGNORE, /* Normal life cycle already set - ignore */
        .SECURE_WITH_DEBUG = CY_EFUSE_STATE_IGNORE, /* Secure with Debug life cycle - Ignore */
        .SECURE            = CY_EFUSE_STATE_SET,    /* Transition to SECURE */
        .RMA               = CY_EFUSE_STATE_IGNORE, /* Transition to RMA - Ignore */
        .RESERVED   = CY_EFUSE_LIFE CYCLE_RESERVED0 /* Reserved bits ignored */
    },
    .RESERVED1 = CY_EFUSE_RESERVED1,                /* Reserved bits ignored */
    .CUSTOMER_DATA =
    {
        CY_EFUSE_CUSTOMER_IGNORE512                 /* All user EFUSE data ignored */
    }
};

When you are ready to advance to the SECURE lifecycle stage, the device must be in the NORMAL lifecycle stage. This is because it is not possible to move from the SECURE_WITH_DEBUG lifecycle stage to the SECURE lifecycle stage.

1. Change the line “.SECURE = CY_EFUSE_STATE_IGNORE” to “.SECURE = CY_FUSE_STATE_SET” to set the SECURE bit.
2. Set CY_EFUSE_AVAILABLE to 1 in mtb-example-psoc6-security/proj_btldr_cm0p/source/cy_ps_efuse.h
   • #define CY_EFUSE_AVAILABLE 1.
3. Rebuild the project and program the part. Ensure that the device VDDIO0 pin must be at 2.5 V.

This is an example how the SMPUs are configured in the example project for the 1 M flash device.

To maximize security, ensure the following order for programming the protection units. By default, both CM0+ and CM4 are set to PC=0.

1. Make all protection unit configuration changes while CM0+ is still in PC=0 mode.
2. After configuring the protection units, change CM0+ PC value to a non-zero value.
3. Set the protection context (PC) mask values for CM0+ and CM4. The mask values determine the PC values that each of these bus masters can switch to. Note that the mask value does not set the current PC value.
4. Set the CM4 protection context to a non-zero value. In this example, it is set to PC=4.
5. Configure the SMPU slave protection unit structures and enable them. Create a structure for each SMPU. Use the Cy_Prot_ConfigSmpuSlaveStruct() function to configure the SMPU, and the Cy_Prot_EnableSmpuSlaveStruct() function to enable it.
6. Configure the master protection unit structures with the Cy_Prot_ConfigSmpuMasterStruct() function for all SMPUs. Enable the master structs with the Cy_Prot_EnableSmpuMasterStruct() function.
7. Program the protection units slave structures to be owned by PC=0.
8. Protect the MS_CTL registers so that the bus master PC masks cannot be altered.
9. Use PPUs to secure the bus master registers (both master and slave), and enable them.
10. Change the protection context for CM0+ to a non-zero value; in this example PC=1.

Some protection units are configured during the boot process and must not be reconfigured. These protection units are vital to providing a secure system and providing a reliable access to system call functions.

It is important to note that if the protection context of any bus master, especially CM0+ and CM4, is left at 0 (PC=0), that bus master will have full access to all memory and registers no matter how the protection units are configured.

To achieve the best security, do not run any bus master at PC=0 after the configuration process is complete. This should be done before CM4 is enabled by CM0+ and right after all protection-associated registers are configured.

Table 17 lists the protection units that must not be reconfigured by the user. These settings make sure that any modifications to eFuse or flash must go through system calls to provide proper security.