Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob

PSoC™ 6 Security Features: Overview for Embedded System Security

PSoC™ 6 Security Features: Overview for Embedded System Security

MarkH_61
Employee
Employee
25 likes received 50 replies posted 25 replies posted

As everyday electronic products from toothbrushes to Cellphones become more sophisticated and connected, it is imperative that these devices include some level of security.  Exactly how much security is up to the developer, so it is important for a developer to understand what security features are available.

The PSoC 6 family of Infineon processors include a number of security features.  These features can be configured together to provide a custom security system to meet the needs for a wide range of applications. This series of five articles provides an overview of these important security features in the PSoC 61, 62, and 63 family devices.  The five PSoC 6 security articles are listed below.

  • PSoC 6 Lifecycle stage and protection state
  • PSoC 6 Debug Port Configuration
  • PSoC 6 Signing Your Code
  • PSoC 6 Protection Units and Protection Context
  • PSoC 6 Boot options (Table of Contents 2 )

Each article provides a high-level view of that topic. For more information on each subject, refer to Infineon Application note AN221111 – PSoC™ 6 MCU: Designing a secured system.

PSoC 6 Lifecycle stage and Protection state

PSoC 6 devices have been designed to allow the designer to customize how much security is required for a given application.  One of the key factors of the security system is the internal lifecycle stage.  It provides a means to define specific security levels for each stage of a product. 

There are two basic stages of a product, development and production.  PSoC 6 provides an additional two lifecycle stages to assist in debugging and possible failure analysis if a product failure occurs.   The lifecycle stages supported in the PSoC 61/62/63 are as follows:

  • NORMAL  (Development)
  • SECURE w/Debug (Development)
  • SECURE    (Production)
  • RMA (Return Merchandise Authorization)

Each part is shipped from Infineon to the customer in the Normal lifecycle stage.  By default, all debug ports are open allowing debug of the CM0+ and CM4 cores as well as access to all internal flash memory for device programming.

1shi.PNG

One very important fact to remember about PSoC 6 lifecycle stages, once you advance from one stage to the next you CANNOT GO BACK.  For example, if you move from Normal to Secure, you can NEVER go back to Normal.

The main reason for advancing a part from Normal to the Secure lifecycle stage is to lock down resources such as debug ports, internal boot firmware, user public key used to authenticate code, etc.  This advance to the Secure stage would be performed prior to the OEM shipping the product that include a PSoC 6.  In cases where security is not an issue, the OEM has the option to leave the part in the Normal stage.

The Normal lifecycle stage is primarily used for the development phase of a project.  In this stage the debug ports are fully open so that the developer has full access to all chip resources including both CPU cores (CM4 and CM0+), flash memory, SRAM, and all registers (MMIO).  The boot flow in the Normal lifecycle is rather simple, in that once the CM0+ loads all trim values and configures clocks and hardware for basic operation, the CM0+ jumps to the user’s CM0+ project.  If security is not a concern for a given application, the designer has the option to leave the device in the Normal lifecycle stage when shipping the product.  In this stage, it may be possible for anyone to view the binary code loaded into the device or alter the contents.

The Secure lifecycle is used once development is complete and prior to the product shipped to the end customer.  Once in the Secure lifecycle stage, a chain of trust is created between the immutable ROM code to the first user code.   This adds a few more steps in the boot process over the Normal lifecycle.  These extra steps validate all system code and data that isn’t stored in ROM but instead Secure Flash. A hash is calculated over several items which includes the system trim values, Flashboot code (2nd half of boot code) and the user’s public key used to validate user code.  The same hash was calculated and stored in non-volitile eFuse when the device was moved to the Secure lifecycle stage. The calculated hash is then compared to the stored hash to verify that none of the code or data has been altered after the device was moved into the Secure lifecycle.  In the final step of the boot process, the user’s code is validated with the stored public key and if validated, the CM0+ will jump to the user’s project.  The user code needs to be signed with the user’s private key after the build process.  The diagram below illustrates the difference between the Normal and Secure lifecycle boot process.

2shi.PNGThe SECURE_with_Debug lifecycle flow is the same as the Secure flow, but the debug restrictions are the same as the Normal lifecycle.  This allows you to debug issues if there is an error during the boot process and you have closed all the debug ports in the Secure lifecycle.  It is important to remember that you cannot advance to the Secure or revert back to the Normal lifecycle stage once you have advanced to this lifecycle stage.

The RMA lifecycle is used to allow Infineon to evaluate a part that a customer feels has a defect.  The customer would normally erase all critical data prior to putting the device into the RMA lifecycle stage.  After the device is in the RMA lifecycle and returned to Infineon, it will be evaluated to determine if the part is in fact defective and determine a root cause. 

Lifecycle stage and protection state are basically the same thing unless an error condition occurs during the boot process.  For NORMAL, SECURE, and RMA there is a direct correlation between lifecycle stage and protection state.  If no error occurs during boot, the device’s protection state will be the same as it’s lifecycle stage.  If an error does occur, the device will enter the DEAD protection state.  The DEAD protection state has its own access restrictions “DAR” (Dead Access Restrictions) that are configured by the developer and cannot be altered once the device enters the SECURE stage.  The main issues that may cause a boot error, is during the validation stage.  If the user code was signed incorrectly or changed after written into Flash, the boot process will halt and enter the Dead state.  (Refer to the diagram above) Access restrictions are how the debug ports are configured in any given protection state and will be covered in detail in an upcoming article. 

3shi.PNG

The flow described here has been simplified to help the reader understand the basic concepts.  For a more detailed description of the boot flow, boot options, how to advance the device from one lifecycle to the next, refer to Infineon Application note AN221111 – PSoC™ 6 MCU: Designing a secured system.

0 Likes
378 Views
Authors