4.1.1 Example Application

The application toggles an LED on a timeout basis and prints the LED toggling rate on the Serial Console, while the non-secure application requests the secure application to read the LED toggling rate, and prints on a serial terminal. Additionally, The Secure mode application reads the current room temperature from the temperature sensor on the I/O1 Xplained Pro Extension Kit every 500 milliseconds. Further, the application writes the temperature readings to the EEPROM and reads when a request is received from the non-secure mode application. A green LED (LED0) is toggled every time the temperature display request is received from the non-secure mode application. The periodicity of the temperature value reading can be changed to 1s, 2s, 4s, and back to 500 ms whenever the user presses the switch SW0 on the PIC32CM LS60 Curiosity Pro Evaluation Kit. The temperature readings are transferred to the non-secure mode application when it requests to secure the application through Non-Secure Callables (NSC).

The non-secure mode application requests the secure mode application temperature values and prints them on a serial console once it receives them from the secure mode application. Further, when it gets a request from the user (in the form of a key press on the serial console), it will request the secure mode application to retrieve the last five stored temperature values in the EEPROM. The non-secure application prints the last five stored temperature values on the console. A red LED (LED1) is toggled every time the temperature values are read from the EEPROM.

Design

The secure application toggles LED0 continuously at a 500 milliseconds rate, if there is a switch (SW0) press event, the toggling rate changes to 1s, 2s, 4s, and back to 500 ms with each subsequent switch press.

BL to SG branch helps the non-secure application to request secure application for its data with the help of NSCs.

With the help BXNS branch, the secure application can return back to the non-secure application to print the data on Serial Console.

Figure 4-1. Application State Switching

In the extended functionality of the application, the secure application reads the current room temperature from the temperature sensor on the I/O1 Xplained Pro Extension Kit and writes to the EEPROM.

The BL branch helps the non-secure application to request the Secure application for the temperature values with the help of the NSCs, and prints them on a serial console.

The secure application returns back to the non-secure application to retrieve the EEPROM data and print on a Serial Console.

Figure 4-2. Extended Application State Switch

In the example implementation, the secureAppEntry( ) is a secure API that is called from a non-secure application. After execution in the secure region, the secureAppEntry( ) returns back to the non-secure application. When a non-secure program calls a secure API using the NSC, the API completes its execution by returning to a non-secure state using a BXNS instruction.

Configuration

  1. The Nested Vector Interrupt Controller (NVIC):

    The NVIC is extended for security allowing secure and non-secure exceptions. According to the priority settings configured in the NVIC, the Secure code can interrupt the non-Secure code execution, and the non-secure code can interrupt the Secure code execution. The NVIC registers at the core level are duplicated. This allows two vector table definitions: one for secure, and another for non-secure.

    By default, on system startup, all interrupts are mapped by default to the secure world (secure vector table). Specific CMSIS functions accessible in the secure world, allocate each interrupt vector to a non-secure handler (declared in the non-secure vector table).

    Figure 4-3. MPLAB Code Configurator - NVIC Settings
  2. SysTick Module: Can be configured as secure or non-secure.
  3. The PIC32CM LS00/LS60 family of devices embed five mix-secure peripherals, which allow part of their internal resources to be shared between the secure and non-secure applications mix-secure peripherals: PORT, EIC, EVSYS, and NVMCTRL.
    • Peripheral Access Controller (PAC): Manages the peripherals' security attribution (secure or non-secure).
    • Non-Volatile Memory Controller (NVMCTRL): Handles the secure and non-secure Flash regions programming.
    • I/O Controller (PORT): Supports individual allocation of each I/O to the secure or non-secure applications.
    • External Interrupt Controller (EIC): Supports individual assignment of each external interrupt to the secure or non-secure applications.
    • Event System (EVSYS): Supports individual assignment of each event channel to the secure or non-secure applications.
    • Pin configuration: Pins can be configured as secure or non-secure as per the user's requirement.
  4. Peripheral Access Controller:

    Each peripheral can be configured as secure or non-secure using Peripheral Access Controller (PAC). When a peripheral is allocated to the secure world, only secure accesses to its registers are granted, and interrupt handling should be managed in the secure world only.

    1. Launch MCC and open the TrustZone Configuration Window.
    2. From the Plugins item list, select Peripheral Configuration for secure and non-secure regions of the application.
    3. Select the SERCOM3 and DMAC boxes as non-secure peripherals. Upon selection the box color will change from green to orange.
    Figure 4-4. MPLAB Code Configurator – Arm TrustZone for Armv8-M Peripheral Configuration
    Note: The SERCOM3 and DMA peripherals are configured as non-secure, and these obtain the LED toggling rate and temperature reading from the secure application through the NSCs (Non-Secure Callable) APIs to print the LED toggling rate on a Serial Console running on a PC.
  5. The memory can be configured as secure or non-secure as per the application requirement.
    1. Launch MCC, and open the TrustZone Configuration Window.
    2. From the Plugins item list, select Memory Configuration for secure and non-secure regions of the application.
      Figure 4-5. MCC – TrustZone for Armv8 - Memory Configuration

      The markers can be used to configure the memory as needed. The Flash region (consists of 512 KB) can be divided into these regions:

      AS: Region for secure application.

      ANS: Region for non-secure application.

      ANSC: Region for placing the Non-Secure Callables (functions that bridge communication between secure and non-secure applications).

Flowcharts

Figure 4-6. Secure Application Flowchart 1
Figure 4-7. Secure Application Flowchart 2
Figure 4-8. Secure Application Flowchart 3
Figure 4-9. Secure Application Flowchart 4
Figure 4-10. Non-Secure Application Flowchart

Implementation

The MCC provides pre-written code templates for both secure and non-secure project components. Within the secure project's TrustZone folder, the nonsecure_entry.c file contains implementations of the Non-Secure Callable (NSC) functions. These act as bridges, allowing the non-secure project to access data stored in the secure project. Cortex-M Security Extension (CMSE) attributes are used to identify these NSC functions within the secure project's code. In the secure project's main.c file, a function called secureApp() continuously manages LED toggling and temperature sensor readings. MCC likely places this function call within a loop for constant execution. The non-secure application relies on an NSC function named SecureApp_Entry(). This function's purpose is to access secure data. It achieves this by calling the secureApp()function from the secure project within its body. Finally, the non-secure application utilizes a DMA channel and SERCOM3 peripheral to print the retrieved data on a Serial Console connected to the PC.

Figure 4-11. NSC Function Prototype and Implementation

Analogy with Printers and Cartridge Use Case

The printer and cartridge use case can use the TrustZone technology to safeguard its firmware and critical operations. The printer stores sensitive information like authentication tokens and firmware code in a secure memory region. This secure zone is completely isolated and inaccessible to regular printing applications or any untrusted peripherals connected to the printer. Any attempt by unauthorized functions to access sensitive operations within the secure zone (like LED toggling or temperature reading) would trigger a security exception, similar to a HardFault exception, preventing unauthorized access.

Think of printer cartridges containing authentication data akin to firmware code. When a cartridge is inserted, it can only interact with the printer's firmware if it includes special Non-Secure Callable (NSC) functions. These NSC functions act as secure gateways, with the first instruction being a Secure Global (SG) instruction, allowing controlled communication between the non-secure cartridge and the secure printer firmware. A faulty cartridge lacking NSC functions could not interact with the secure zone, any attempt to bypass the NSC gateway would fail, preventing unauthorized access.

The TrustZone technology offers two key benefits: isolates sensitive data in secure memory and requires authentication through NSC functions. First, it acts as an anti-cloning measure, preventing unauthorized copying of the printer's firmware or bypassing security measures. Second, it ensures the safety of corporate data by controlling access to secure operations. Only authorized cartridges with valid NSC functions can interact with the printer, protecting critical information like printing jobs or network configurations from unauthorized access.

In essence, the analogy between a secure printer and TrustZone showcases how secure memory partitioning and controlled communication through NSC functions enhance device security.