MSP432™ MCUs Training Part 7: Security AES256 JTAG/SWD Lock IP Protection Firmware Update Welcome to part seven of the MSP432 MCU Training series. In this section we will cover the security features of the MSP432. We will take a look at the AES256 encryption engine provided by the MSP432, we will also take a look at different mechanisms to lock the JTAG access to the device, we will also cover the IP protection feature as well as how to securely update the firmware of the device when the applications is deployed in the field.

Security | AES256 Benefits Hardware acceleration for AES (Advanced Encryption Standard – FIPS PUB 197) Accelerates AES en- and decryption by one to two orders of magnitude (compared to software) Lower power (compared to software) Off-loads CPU Performance 128-bit of data are en- or decrypted with a 128-bit key within 167 MCLK cycles, 256-bit encryption in 234 cycles Features supporting 128-, 192-, and 256-bit key lengths On-the-fly key expansion Off-line key generation for decryption Shadow registers for initial key 128 bit truly random seed to generate the random key Block mode with DMA: OFB, ECB, etc. Applications include Securing of communication channels like RF links, UART communications, etc. The MSP432 uses the same AES256 encryption engine that is known to the MSP430 family. This engine is capable of driving 256-bit AES encryption. The hardware engine does not require any CPU activity, so once you load the key as well as the data payload into the engine, the AES can go off and operate in parallel in CPU programming. The AES 256 module supports 128, 192 as well as 256-bit key lengths. It allows for on the fly key generation as well as offline key generation. The AES256 can also be used in block modes, such as OFB, ECB, as well as CBC together in conjunction with DMA. This allows the users to configure a data signal chain for example to receive the data through SPI, transfer it over to DMA, transfer over to AES, o perform a decryption or encryption and then transfer back to another serial communication interface. There are two main benefits for using the hardware engine of AES256. First is the CPU offload. Since the hardware engine runs in parallel to CPU, you could create an autonomous task as mentioned before, such as running AES 256 together with DMA. The second benefit is the accelerated performance compared to software implementation. As an example, a 128-bit encryption normally would take seven thousand cycles in CPU when using software implementation, it is now reduced to 190 clock cycles when using the hardware engine in AES. In AES engine is crucial to any security sensitive applications that requires communications, such as RF, UART communications or even for field firmware update, the AES is heavily used by multiple internal engines of the MSP432, such as the DSL or the security features that we will cover on the next slide.

Security | Device Security Overview Full chip security: JTAG Protection Device is fully secure from debug accesses. Regional security: IP Protection Up to 4 regional secure zones of memories can be configured in flash These zones are non-intrusive to debug (JTAG/debugger) and code outside this region. Regular debug allowed outside these regional secure zones. Combination of regional and full-chip security This is a combination of the above two where: Debug accesses are blocked for the entire device Code/Data access restrictions and protections apply for the secure regions. From the security standpoint the MSP432, provides two types of security, the JTAG protection as well as the IP Protection. The JTAG protection is the way to block the device completely from any future JTAG access. After locking the JTAG, the user could no longer debug the device and establish a JTAG connection to the device. On the other hand, IP Protection is a mechanism that allows software IP vendors to securely lock away a region in the memory with the unique software IP. So this locked region can no longer allow users for read access. However, users could still execute code from this region. Think of this as a black box solution that you want to provide software vendors. The MSP432 can also combine the two types of security to provide both JTAG protection and IP Protection.

Security | JTAG security Free memory Code Memory (Flash) Customer’s Code to be Secured Debugger Similar to MSP430 JTAG security control Code is developed and loaded into Flash by customer Device is then completely locked from external accesses (full chip secure) All memory areas within the device can be accessed by the customer’s code. First let’s take a look at JTAG security on MSP432 MCU. So the JTAG security or the JTAG lock, from a user’s standpoint, is very similar to the MSP430 JTAG control, where once you lock away the JTAG, no longer debug access is available to the customer. So first off when a code is developed and loaded into the flash, you can then invoke this JTAG lock mechanism to prevent further debug access. The device Is then locked away from external access while the application code could still access any memory areas within the device. The only way to regain access to a device that is blocked from JTAG access is to go through a mass erase or factory reset. This is a procedure where the entire flash memory of the device is wiped out before the access is reopened to the device. This ensures that any sensitive software or application code is completely wiped out and prevented access. So developers can actually use this factory reset feature by going through the IDE option as well as one of the examples that we provide below. For a device that is locked from further JTAG access, the firmware of the device can still be updated in the field using a BSL. At this point the user has the option to use a secured update as well as a non-secure update and we will cover this on the next slide when covering the BSL portion of the security.

Security | IP Protection Configure up to 4 regionally secured zones to protect IP from read/write access Facilitate securing protected IP code from vendors Prevent access during IP code execution by stalling JTAG until end of code execution Regionally secured zones can be updated via BSL Ease of use: Use CCS & other IDEs to configure and secure zones Moving on to IP Protection, as mentioned earlier, IP Protection is a method that allows software IP vendors to securely provide the unique black box solution, preventing the end users from reading out the secret IP but still allowing the customers to executing IPs. This is done so by preventing further read access to the debugger or read access from the customers application code itself. However, customers could still simply invoke the function within the IP protected zone. The MSP432 supports up to four IP protected regions. So think of a scenario where there are four software IP vendors, where the first one programs and locks away their first IP protected zone and delivers to the second IP vendor. The second IP vendor could execute from the first protected zone but cannot read out the content. They can then program the second IP protected zone, at the end, the end customer or end user can execute any of the functions that are provided within these four IP protected zones, but they can no longer read out any of the content. Similar to the JTAG lock, the MSP432 also enables a mechanism that allows customers to update these individual IP protected zones out in the field, without compromising the content of the firmware that is being updated.

Security | Device security setup Start Security setup Mailbox structure: CMD – Command () JTAG/SWD Lock IP Protection Setup (Zone 0-3) BSL Configuration Update device Firmware Update IP Protection Firmware PARAMS – security parameters ENABLE START_ADDR LENGTH AES_INIT_VECTOR AES_DECRYPTION_KEYS UPGRADE PASSWORD ENCRYPTED_UPDATE_EN DATA_ACCESS_EN Program code to be secured into device flash Setup flash mailbox for secure region/full chip security setup Perform reboot-reset on the device Success (ACK=0xACE)? So this is how the device security is setup on the MSP432 and this works for both JTAG and software lock configuration, or IP protection setup. You can also use the same mechanism for BSL configuration as well as to update the firmware. The mechanism is called boot override, what it does is that there is a special region in the memory that is called Flash Mailbox, where one way communication can be transferred from the user or the application code to the boot code. And once the message, in this case the configuration message is being programmed into this flash mailbox, the user can issue a device reboot/reset and then the boot code can take over, read out the content of this message and perform the necessary task, either lock the device from further JTAG access or to configure the IP protect zone, with or without a password. Once this operation is completed, the boot code will program back into the memory with the status operation, whether success or failure. Once that is done, the device is now locked away from JTAG access, IP Protection zone is completely protected from further reading access and BSL is configured to the way the customer prefers. The same mechanism could also be used for updating the firmware in the field. Again, in this case, since JTAG is no longer possible this flash mailbox could still be programmed by the BSL as a way to transfer secured messages from the BSL host to the device to the boot code, to program the new firmware into the memory. No Yes Security setup done.

Security | Device firmware update Password-protected BSL can be used to update a device’s firmware When locking JTAG/SWD, option to provide an encryption key Key is only shared at the time of initial firmware programming During field-update, BSL payload can be encrypted with the same key Invoke boot override to decrypt the payload and program the new firmware IP Protection also requires an encryption key Key is only shared at the time of IP protected zone programming BSL payload is encrypted with the same key No-one other than original IP provide has access to the key There are multiple layers of security that are embedded into the firmware update mechanism of the MSP432 devices. At the first level, the boot strap loader BSL is already protected by a specific password, so in order to gain BSL access to the device, whether the device is secured with JTAG or IP Protection or not, a password must be provided by the BSL Host. When the device is locked from JTAG and SWD access, the user has access to provide an encryption key. This encryption key will allow the BSL to encrypt the payload before programming and transferring the data over to the device. So the key is only shared at the time of initial firmware programming and the BSL host must encrypt the payload with the same key so that the BSL communication can be secured and protected from any snooping on the BSL line. Once the encrypted payload is transferred over to the device, the BSL must then invoke the boot override using the flash mailbox as we just talked about. So this boot override can then read out the messages from the BSL and decrypt the payload with a pre-aligned encryption key and program the decrypted image of the firmware to the device flash memory. Once this is complete, the device can then reboot with a new firmware. The IP Protected zones could also be updated given that an encryption key is provided. It is very crucial because this allows for IP vendors to securely provide the field firmware updates with allowing their customer access to the actual content of their firmware. So again, the encryption key must be share at the beginning of time when the IP protected zone is being programmed initially. The IP vendor can then provide the payload that is already encrypted with the key to the end user. The end user will then use BSL to access the device and then transfer the encrypted payload over the device. Again the same boot override using the flash mailbox can be invoked, and then the boot code can securely decrypt the payload with the same encryption key preprogrammed in the IP protection zone. Throughout the entire process, no one other than the IP vendor has access to the key. After the operation is done, the device can go to a reset routine, and now the new IP protected firmware can be used.

Security | More Resources Application Notes & SW examples Software IP Protection Configuring Security features Available in MSPWare Device security as well as IP protection are really complex topics. After going through the high level overview of the security features of the MSP432 MCU here in this video today, we highly recommend you to research further by going to different application notes and software examples made specifically to demonstrate how to enable software security on MSP432 as well as how to configure the security updates or BSL programming on MSP432. All of these resources are available on MSPWare. Below is a screenshot of where you can find the relevant application notes as well as software examples inside MSPWare. With that we have concluded the part number 7 of the MSP432 Online Training Series. Thanks for Watching!