Ensure embedded system security using DSCs and MCUs supported by dedicated security ICs
With migration to the Internet of Things (IoT), security has moved well beyond an optional feature in embedded applications. To respond to a growing array of security specifications, developers require solutions that not only match application requirements for low power or high performance but can also deliver hardware-based security capabilities.
Rolf Horn, Applications Engineer, DigiKey further explores.
Embedded security builds upon four principles
Besides facing continued consumer demand for system-level cybersecurity, developers increasingly need to address security specifications from national and regional organisations. Two of the most influential specifications, Europe’s ETSI EN 303 645 and the United States’ NIST IR 8259, suggest cybersecurity practices depend upon four key principles:
- Unique passwords
- Secure storage on the device for sensitive security parameters
- Secure communication through mutual authentication and encrypted communication
- Ensuring firmware integrity and authenticity through secure boot and secure firmware update
Delivering systems based on these core principles requires use of a trusted platform that prevents hackers from injecting compromised code. Trusted platforms help ensure security by building system-level security from the ground up using immutable hardware-based security mechanisms. By using Microchip Technology’s high-performance dsPIC33C DSCs and low-power PIC24F MCUs, in combination with Microchip’s companion security devices, developers can more easily implement embedded designs that ensure system-level security.
Meeting performance and power requirements
Designed to support a wide range of use cases, devices in Microchip’s dsPIC33C DSC and PIC24F MCU families each combine robust execution platforms with application-specific capabilities, including an extensive complement of integrated analog, waveform control, and communications peripherals. An example is the use of the DSPIC33CK512MP608 single-core DSC to implement an offline uninterruptible power supply (UPS) design (Figure 1).
Figure 1: The DSPIC33CK512MP608 single-core DSC integrates comprehensive set of peripherals, simplifying design of complex systems such as offline UPS shown. (Image source: Microchip)
For applications requiring both real-time control capabilities and digital signal processing, dsPIC33C DSCs combine the capabilities of an MCU and a DSC. For safety-critical designs, dsPIC33C DSCs are IEC 60730 functional safety ready and ISO 26262-compliant, providing multiple hardware features designed to simplify functional safety certification for Automotive Safety Integrity Level B (ASIL-B), and SIL-2 automotive and industrial safety-critical applications.
While dsPIC33C DSCs are designed for applications where performance is paramount, PIC24F MCUs provide a balance between performance and power efficiency for applications that require control and connectivity, but do not need DSP capabilities. As with dsPIC33C DSCs, PIC24F MCUs are IEC 60730 functional safety ready devices with Class B safety diagnostic libraries for building household applications.
As noted, firmware integrity is a core principle of embedded cybersecurity. To help developers ensure firmware integrity and overall code protection, Microchip provides Flash one-time programmable (OTP) by in-circuit serial programming (ICSP) Write Inhibit and CodeGuard Flash security in dsPIC33C DSC devices, such as the DSPIC33CK512MP608 single-core DSC and the DSPIC33CH512MP508 dual-core DSC, as well as PIC24F MCU devices such as the PIC24FJ512GU405 MCU, among others configured with different sets of application-specific peripherals.
Protecting device firmware
Flash OTP by ICSP Write Inhibit enables developers to configure portions of Flash memory as OTP memory, and to read/write protect the Flash memory. Microchip’s proprietary ICSP capability permits these devices to be serially programmed through a pair of pins while running in the end application. With this capability, manufacturers can complete programming on production boards. While ICSP requires use of an external programming device to control the Flash OTP process, Enhanced ICSP allows an on-board bootloader to control the Flash OTP process. These devices also support run-time self-programming (RTSP), which allows the Flash user application code to update itself during run time.
After programming their production device, developers can activate ICSP Write Inhibit, which prevents any further ICSP programming or erasure. Nevertheless, RTSP Flash erase and programming operations can proceed even when ICSP Write Inhibit is activated if appropriate Flash-update code is programmed into device prior to its activation. As a result, developers can use a trusted bootloader to alter Flash even when ICSP Write Inhibit is activated, allowing them to securely update firmware while still mitigating external attempts to update Flash in production systems.
CodeGuard Flash security provides fine-grain protection of program Flash through the use of separate boot and general segments. Developers define the size of these segments by setting address of boot segment (BS) limit (BSLIM) in the device’s BSLIM register; the general segment (GS) occupies remaining memory. To further protect sensitive information, each segment contains additional partitions: the BS contains the interrupt vector table (IVT), the optional alternate interrupt vector table (AIVT), and additional instruction word (IW) space; the configuration segment (CS), containing critical device user-configuration data, lies within user address space in the GS (Figure 2).
Figure 2: dsPIC33C DSC and PIC24F MCU families support code protection in separate partitions, like BS and GS. (Image source: Microchip)
After setting segment partitions, developers can use the device’s firmware security (FSEC) register to optionally enable write protection and set required code protection level for each segment. During runtime, the device prevents code contained in a segment with a lower code-protection level from accessing code contained in a segment with higher code-protection level. In a typical system, developers would write protect the BS and set its code protection to a high level, mitigating external attempts to alter the BS, including the bootloader.
Implementing secure over-the-air firmware update
Software developers are inevitably faced with the need to update software in response to the combination of newly discovered/emerging competitive enhancements, bugs, and/or security threats. Unlike mobile-app updates, performing secure updates to firmware in embedded systems risks interfering with currently running applications at best, or ‘bricking’ the system at worst. Microchip’s dsPIC33C DSCs and low-power PIC24F MCUs families provide a dual-partition mechanism designed to help developers avoid these problems.
In standard operating mode, these devices use all available physical memory as a continuous, single-partition memory space (Figure 3, left) that can be configured into separate BSs and GSs. In dual-partition mode, developers split physical memory into separate active and inactive partitions (Figure 3, right).
Figure 3: Developers can operate the dsPIC33C DSC and PIC24F MCU families in default single-partition mode or in dual-partition mode. (Image source: Microchip)
Operating in dual-partition mode, these devices can continue executing application code in the active partition while programming the inactive partition. After programming has been completed, execution of the boot swap (BOOTSWP) runtime instruction causes the device to switch the boot target to the updated partition. If the code in the updated partition fails or is otherwise found deficient, a device reset will automatically cause the device to boot into the original partition (Figure 4).
Figure 4: In dual-partition mode, the dsPIC33C DSCs and PIC24F MCUs can load application code in one partition while continuing to execute application code in the other partition. (Image source: Microchip)
After success of the updated partition is assured, the flash boot sequence (FBTSEQ) of the updated partition can be set to a lower value than the original partition. On subsequent device resets, the device will boot into the updated partition with the lower FBTSEQ value (Figure 5).
Figure 5: Dual-partition mode allows developers to specify boot sequence into the desired partition following device reset. (Image source: Microchip)
Flash OTP by ICSP Write Inhibit and CodeGuard Flash security provides critical support for static and runtime code security, but comprehensive embedded security requires additional mechanisms, including secure key storage, code authentication, and secure communications.
Using companion security devices to ensure embedded system security
By combining dsPIC33C DSCs and PIC24F microcontrollers with Microchips’ ATECC608 CryptoAuthentication or the TrustAnchor100 (TA100) CryptoAutomotive security IC, developers can more easily deploy the full complement of hardware-based security capabilities.
These security ICs provide hardware-based tamper-resistant security mechanisms, including secure storage, hardware-accelerated cryptography engines, true random number generators, and other mechanisms required by cryptographic algorithms. Designed specifically as companion devices, ICs can be easily added to DSC or MCU system designs to complete implementation of full embedded systems security (Figure 6).
Figure 6: Security ICs such as the ATECC608 or TA100 complement security features of dsPIC33C DSCs and PIC24F MCUs. (Image source: Microchip)
Execution of a critical operation like secure firmware update illustrates the complementary security features of dsPIC33C DSCs and PIC24F microcontrollers in conjunction with these companion security ICs. Developers use code-signing techniques to verify authenticity and integrity of code prior to completion of firmware update operations. Developers use their development systems to create an update package containing code, code metadata, and signature used for verification (Figure 7).
Figure 7: Code signing provides a vital protocol routinely used to verify the authenticity and integrity of code prior to update on a target system. (Image source: Microchip)
On the target system, hardware-based signature verification eliminates risk of compromised verification protocols possible with software-based signature verification used in the past. Instead, a companion security IC, such as Microchip’s ATECC608 and TA100, rapidly and securely performs signature verification operations without risk of compromise (Figure 8).
Figure 8: In a target system, hardware-based verification provided by security ICs, such as the ATECC608 or TA100, is essential for ensuring verification of code prior to bootloader firmware updates. (Image source: Microchip)
To accelerate implementation of secure systems, Microchip provides a combination of software and hardware development tools.
Speed software and hardware development
While the MPLAB X integrated development environment (IDE) provides developers with a full software development environment, the MPLAB XC C compiler provides development support for existing tool chains. To speed development in either environment, the Microchip MPLAB Code Configurator (MCC) lets developers use a graphic interface to automatically generate initializers, build drivers, allocate pins, implement libraries, and help speed many of the critical low-level setup procedures/processes.
To speed implementation of a suitable secure bootloader, Microchip’s Bootloader for dsPIC33 DSCs and PIC24 MCUs provides a graphical interface that helps developers quickly configure/generate custom bootloaders required for their application.
For hardware development, Microchip provides several associated development boards for building systems based on dsPIC33C DSCs or PIC24F MCUs. Microchip’s PIC-IoT Board EV54Y39A and PIC-IoT Board AC164164 (Figure 9) integrate security ICs that are pre-provisioned with security credentials for Amazon Web Services (AWS) and Google Cloud, respectively.
Figure 9: Boards such as PIC-IoT Board AC164164 help accelerate embedded security development by integrating security ICs, pre-provisioned with credentials for AWS or Google Cloud. (Image source: Microchip)
For custom designs, Microchip offers a dsPIC33CH Curiosity development board (DM330028-2) based on dsPIC33CH512MP508 dual-core DSC. Alternatively, developers can attach Microchip’s dsPIC33CH128MP508-based plug-in module (MA330040) to a Microchip Explorer Embedded Evaluation Board (DM240001-2) to speed development of secure embedded systems.
Conclusion
Embedded system security relies on availability of hardware-based mechanisms, able to support core cybersecurity principles including firmware integrity, authentication, encryption, and secure storage. While Microchip’s dsPIC33C DSCs and PIC24F MCUs simplify code protection, its ATECC608 and TA100 security ICs provide additional security mechanisms required in an effective security platform.
The original article can be found on the DigiKey website.