Deeptrust for PCI security architecture  SPEC98T17 rev E
Specification of Deeptrust, the Security Architecture for Cortex-M.
Deeptrust for PCI security architecture Documentation
Author
Maxim Integrated
Date
2016-2017

Reference

        SPEC98T17

Copyright Notice

/*****************************************************************************
* Copyright (C) 2016-2017 Maxim Integrated Products, Inc., All rights Reserved.
* This software is protected by copyright laws of the United States and
* of foreign countries. This material may also be protected by patent laws
* and technology transfer regulations of the United States and of foreign
* countries. This software is furnished under a license agreement and/or a
* nondisclosure agreement and may only be used or reproduced in accordance
* with the terms of those agreements. Dissemination of this information to
* any party or parties not specified in the license agreement and/or
* nondisclosure agreement is expressly prohibited.
*
* The above copyright notice and this permission notice shall be included
* in all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
* OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
* IN NO EVENT SHALL MAXIM INTEGRATED BE LIABLE FOR ANY CLAIM, DAMAGES
* OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*
* Except as contained in this notice, the name of Maxim Integrated
* Products, Inc. shall not be used except as stated in the Maxim Integrated
* Products, Inc. Branding Policy.
*
* The mere transfer of this software does not imply any licenses
* of trade secrets, proprietary technology, copyrights, patents,
* trademarks, maskwork rights, or any other form of intellectual
* property whatsoever. Maxim Integrated Products, Inc. retains all
* ownership rights.
******************************************************************************/

Trademarks

  • ARM is a registered trademark and registered service mark and Cortex is a registered trademark of ARM Limited.
  • mbed is a registered trademark of ARM Limited.
  • All trademarks not mentioned here that appear on this web site are the property of their respective owners.

Introduction

This document describes the Deeptrust architecture and API.

Deeptrust is a security architecture designed by Maxim Integrated. This architecture allows software isolation and privilege limitation of software running on a System-on-Chip (SoC) (aka microcontroller) with an ARM® Cortex®-M3/4 core. This security design prevents applications hosted on the same platform from accessing sensitive data, peripherals, executable code.

Deeptrust has been designed to pass the Payment Card Industries – Pin Transaction Security 5.0 certification. This architecture aims to be approved as conforming to those requirements, so the customer will only need to build a conforming terminal (which must be evaluated) and have their changes to Deeptrust approved. The coverage of the requirements is exposed in the section Security Guidelines.

Software running in the platform is split into secure containers in order to:

  • reduce the scope of the software validation
  • reduce the scope of the PCI evaluation, and exclude non related code that can be modified more easily without undergoing a new evaluation
  • improve the overall robustness of the running software by preventing the propagation of a bug or vulnerability

The Deeptrust offering contains the following:

  • A Secure Boot ROM, embedded in MAX325xx ICs from Maxim Integrated
  • Software sources and/or binary libraries that implement the security architecture mentioned above:
  • Maxim software libraries sources and/or binaries that provide base services for customers to implement EMV-Level 2 and payment applications:
    • Secure Smart Card communication, display, user entry
    • Secure PIN handling (offline verification, DUKPT for online verification)
    • Mag Stripe reading
    • Secure cryptographic algorithms and key management
    • Secure memory allocation
    • Platform integrity management, error and security event handling
    • Secure firmware update
  • General purpose software:
  • Maxim PC Tools for Secure Boot ROM management:
    • generation of signed firmware images
    • secure update protocol
  • Documentation:
    • The present user guide, including a description of the coverage of the PCI PTS POI 5.0 requirements
    • Secure Boot ROM documentation
    • PCI PTS Security Evaluation report to be reused for the final certification
  • Demonstration and example code
  • Technical support

Security Architecture Presentation

Deeptrust relies on the following elements of architecture:

  • Hypervisor-based software isolation
  • Chain-of-Trust, firmware integrity and authenticity verification
  • Hardware enforced security
  • Secure API

Note to the reader: the security architecture presented here is composed of elements closely tight together and heavily depending on each other. Therefore it is advised to read this twice.

Primer on Cortex-M security mechanisms

Let's introduce some essential concepts now for the sake of understanding this document. These concepts will be further explained later though.

The architecture of Cortex-M3/4 cores provides the following security mechanisms:

  • Two-level execution privilege: "Thread user" and "Handler privileged". The core always boots in Handler privileged mode. Switching to Thread user mode is done via a dedicated instruction. Switching back to Handler privileged mode is achieved through Interrupts and exceptions (including the SVC software exception). Both modes can have separate stacks. Thread user also has limited access to core registers (MPU configuration, stack pointers, NVIC interrupt controller configuration, etc)
  • Memory protection unit (MPU): this component is optional regarding the Cortex-M core instantiation, but mandatory for the security architecture presented here. The Maxim Integrated's MAX325xx SoCs do have an MPU implemented. The MPU allows to define access rules to any memory range (Flash, RAM, peripherals) for code running in Thread user mode. The MPU can be configured only from the Handler privileged mode of operation of the Cortex-M core.

Hypervisor-based software isolation

Software isolation is achieved by a lightweight security hypervisor (also simply called hypervisor below) that leverages the Cortex-M security mechanisms.

The lightweight security hypervisor in use is ARM® mbed uVisor (see [DOC1]). Software isolation means that the various software components run inside secure containers (aka "boxes") isolated from each other, and also from the hypervisor itself.

In this security architecture, the hypervisor is the only code running in Handler privileged mode of execution, and hence is fully and exclusively controlling the MPU.

Code partitioning: Core firmware and Secure containers (aka "boxes")

In this architecture, we distinguish the Core firmware from the Secure boxes.

  • Core firmware: the core firmware contains the trusted executable code and is signed using the firmware signing key of the secure boot ROM aka CRK (see ), i.e.:

    • SoC Startup code
    • Hypervisor
    • mbed-OS (high level API, RTOS) and Maxim driver libraries
    • Other Maxim software libraries, C runtime library
    • Related constant data and variable initialization values
    • Store of Secure boxes verification keys

    The core firmware integrity and authenticity is verified and executed by the secure boot ROM (see Hypervisor initialization). This component is part of the PCI firmware perimeter.

  • Secure boxes: Boxes contain application-level code. As seen above, secure boxes can be invoked by other boxes through the RPC mechanism. No direct call is allowed.
    • PCI Secure Services and Secure Sandbox Services boxes
    • Payment application box
    • Other secure boxes

Secure boxes are software containers enforced by the hypervisor. Thanks to the hypervisor, each box has:

  • its own private stack
  • its own private RAM
  • its own private flash data section
  • access to the smallest subset of peripherals possible as defined by access control lists (ACLs). ACLs are used to deny/grant physical access to peripherals.
  • an ID and a namespace that can be trusted. Those IDs are used for granting or denying access during RPC calls (described later).
  • no access to forbidden peripherals, memory ranges, exception vectors, NVIC configuration, MPU configuration

This way, even if all are running with unprivileged permissions, different boxes can protect their own secrets and execute critical code securely.

Note that the hypervisor allows the existence of a "Public box". In this design, the public box is part of the "Core firmware" and is actually not executing code. It is not at the same level as Secure Boxes described below.

memory_layout.png
Figure - Platform memory layout

There are three levels of secure box privilege levels:

  • "Box firmware": the secure box is part of the PCI firmware perimeter; it has full access to peripherals and memory(*)
  • "Box trusted": the secure box is trusted, which grants some direct access to peripherals and memory
  • "Box other": the secure box is not trusted, which grants no direct access to hardware and limited visibility of memory

(*) the hypervisor still has protected memory that is not visible from Thread/user mode, hence from no box whatever the box privileges are.

The box privilege is granted at box loading time based on the signing key of the box. If the signing key was K_fw and the signature verification of the box is successful, the the "Box firmware" privilege is granted.

This box privilege level defines two kinds of privileges:

  • The allowed ACLs
  • The allowed services

The box privilege policy can be customized:

  • from the core firmware, it is possible to define which ACLs are acceptable for each box privilege level. The ACLs of secure boxes cannot be arbitrary and must correspond to what is really allowed by the core firmware. Therefore the hypervisor is in charge of controling the validity of the ACLs to make sure that memory regions that need to be always protected are not claimed by the secure box.This specification defines a sample ACL policy, but it can be adapted. This policy is implemented in the core firmware, thus cannot be tampered with by additional software. The ACL policy is enforced at boot time when secure boxes are loaded by the hypervisor. It cannot be modified at runtime, as for the ACLs themselves.
  • from boxes that offer services through RPC. The hypervisor offers a service to be used by RPC servers that allows to get the privilege level of the caller box in order to implement an access policy based on the caller's privilege. For instance, access to the "PIN entry" service can be declined to non trusted boxes. In addition, the box name can be used to further refine the policy (e.g. service is allowed to trusted boxes which name is box_aaaaa and box_bbbbb, but declined in all other cases). The box name can also be asked by the RPC server, similarly to the privilege level of the caller.

Box access control list

For secure boxes, unprivileged access to selected hardware peripherals and memories must be explicitly granted through Access Control Lists (ACLs). ACLs are managed by the hypervisor. ACLs are defined at boot time and cannot be modified at runtime. When running out of a secure box, access to memories and peripherals is the most restrictive: access that are not explicitly granted are denied by default.

Software running in a box can access only the memory ranges it has been allowed to (through the Access Control Lists, ACLs), with the access type enforced (RWX, RO, etc...) for each range. The definition of the privileges of a box is done at compilation and remains static, i.e. cannot be modified at runtime.

In addition, the secure box binary code, constant data and variable initialiation values and its ACL are signed as a whole (single binary image) using a private signing key. As the whole image signature is verified upon boot, the box privileges and ACLs are protected against modification. The application's box privileges are read by the hypervisor during the early initialization of the SoC (see Hypervisor initialization) and stored into the hypervisor protected memory so they cannot be modified from the application's box.

Box isolation enforcement

Let's explain how the hypervisor implements the isolation of secure boxes. The hypervisor is the only software running in Handler privileged mode. All other software runs in Thread User mode (see Cortex-M mechanisms: MPU, privileges, NVIC), even the core firmware's unprivileged code.

The hypervisor is therefore the only software component allowed to control the MPU (initial configuration, reconfiguration during context switches, secure interrupt handling) and catch the exceptions and interrupts. This is verified as:

  • the hypervisor executable image is verified by the Secure Boot ROM (see Secure Boot firmware and verification key are in immutable memories with integrity check), hence it cannot be modified arbitrarily.
  • the hypervisor is initialized early in the boot process (see Hypervisor initialization), before any other Secure Box can run. During its initialization, the hypervisor:
    • registers the exception vectors, and prevents access to the vector table and to the vector table location
    • sets the core in Thread User mode of execution before relinquishing the CPU to the applications.

The only way to jump back to Handler privileged mode is through exceptions (interrupts and exception, SVC instruction). As exception vectors belong to the hypervisor, the hypervisor keeps the monopoly of execution in Handler Privileged mode.

The hypervisor relies on the two hardware mechanisms described hereafter (see Cortex-M mechanisms: MPU, privileges, NVIC).

Instantiation of secure boxes and code signing

Secure boxes cannot be instantiated at runtime. Instantiation is done at compilation time, as the definition of the ACLs, using the hypervisor API. Once compiled, the binary resulting of the build process contains the application executable image, containing the ACLs. This image must be signed so it can be part of the 2nd level application.

The file sources/deeptrust_api/box_example/example.cpp illustrates this instantiation.

In the first version of this specification, the compilation of the whole embedded software must be done in a single operation. In the resulting binary image, the core firmware binary is separated and signed separately using the ROM secure boot signing key. Other secure boxes code is also separated from each other and signed with different signing keys. However the software binary image remains monolithic and must be loaded entirely in a single operation. Secure boxes are stored in a contiguous memory area.

In the next release, it will be possible to compile secure boxes separately, and load them separately from each other.

Secure boxes have the following structure in memory:

  • Header with:
    • 4-byte magic
    • Box name (must be unique, update fails if box name already exists)
    • Box image length
    • Box verification key ID
    • Box ACLs, RPC list
    • Signature of the above fields and the "Secure box executable image" below, using the verification key "ID" as mentioned in the header.
  • Secure box executable image:
    • Executable code (.text section)
    • Constants and initialization data (.rodata and .data sections)

Note: The box name must be unique. Note: The above is signed using a dedicated key that is different from the CRK core firmware signing key. This scheme allows to consider secure boxes as separate from the core firmware.

The verification key ID defines the box privileges. If one posseses the K_fw signing key, he can write code having the "box firmware" privilege. The K_trusted shall be distributed

Even if no unsigned code can be executed (this leads to a platform reset), any code must be carefully reviewed before being signed and loaded into the platform.

Let's precise that the code signing key management is left at the discretion of users of Deeptrust. The foreseen usage is:

  • The terminal vendor owns the CRK and the K_fw keys that allow writing code within the "PCI perimeter"
  • The terminal vendor or a contractor owns the K_trusted key that allows writing "Banking applications" allowed to somehow interact with smart cards and magnetic stripe (through usage of the PCI secure services)
  • Other parties may own the K_other key to be able to provide low privilege applications (advertisement, loyalty...). The K_other key is designed to give the least privilege in the platform.

This scheme can be further extended with more keys, and customized by reworking the uvisor_check_acl function. Ultimately the vendor is in charge of managing the code verification keys present in the platform, and how to distribute/update them.

The Makefile present at the root of the project is in charge of signing secure boxes according to this 3-level privilege design.

Notes:

  • There's no 1 to 1 mapping between boxes and threads: a box can run several threads, all running with the parent box privileges.
  • The program entry point "main()" runs outside of a secure box (All the code running in Thread User mode, that is not protected in a secure box, is referred to as the public box). this public box is part of the "core firmware" and cannot be customized unless one posseses the ROM secure boot signing key.

Hypervisor initialization

During the boot of the SoC, the Secure Boot ROM starts running in "Handler/Privileged" mode (the Cortex-M boots in that mode). It verifies the digital signature of the "2nd level application" stored in flash memory, and, if successful, jumps into the entry point (aka startup) of the latter, also in "Handler/Privileged" mode.

The "2nd level application" is a term used in the Secure Boot ROM documentation. It designates the binary executable image that sits in a flash memory and that is verified by the Secure Boot ROM. In our design, the "2nd level application" is the "core firmware" described above.

The "core firmware" execution begins by the initialization of the hypervisor itself, which also runs in Handler/Privileged mode. During this initialization phase, the hypervisor sets up a protected environment using the MPU: the MPU is configured so that the hypervisor keeps ownership of its own memories and the security-critical peripherals, in order to keep them protected from the unprivileged code. The hypervisor secures two main memory blocks, in flash and SRAM respectively (it places its own constants, data and stack in secured areas of memory, separated from the unprivileged code). In both cases, it protects its own data and the data of the secure boxes it manages from the unprivileged code.

This initialization step makes some peripherals impossible to access to the unprivileged code whatever the ACLs are. Therefore accessing to some security-critical peripherals (like DMA) requires SVCall-based APIs for the unprivileged code. The MPU configuration, the vector table, the NVIC configuration are also made inaccessible from the unprivileged code.

The hypervisor initialization is as follows:

  1. Several sanity checks are performed, to verify integrity of the memory structure as expected by the hypervisor.
  2. The hypervisor ".bss" section is zeroized, the data section initialized.
  3. The Memory Protection Unit (MPU) is configured
    • The hypervisor takes ownership of the vector table
    • The hypervisor protects some RAM and some flash so they are reserved to Handler privileged mode
  4. Secure boxes are loaded:
    • Secure boxes digital signatures are verified one by one using the appropriate verification key
    • It is verified that names of secure boxes are unique
    • Each box's .bss section is zeroed
    • Each box's .data section is initialized
    • Access Control Lists (ACLs) are registered and checked against validity. Additional boxes cannot be granted arbitrary access to any memory region (the ACL policy described earlier is enforced)
    • Stacks are initialized, a private box context is initialized, if required by the box.
  5. Handler privileged and Thread user modes stack pointers are initialized.
  6. Execution switched to Thread user mode and handed over to the unprivileged code.
boot_diag.png
Figure - Boot sequence

Context switches

The hypervisor prevents CPU registers leakage when switching execution between Handler privileged and Thread user code and between mutually untrusted unprivileged boxes. It also remaps the stack and modifies the MPU according to the destination context.

During a context switch, the hypervisor stores the state of the previous context and then:

  • It re-configures the stack pointer and the box context pointer.
  • It re-configures the MPU and the peripherals protection.
  • It hands the execution to the target context.
  • A context switch is triggered automatically every time the target of a function call or exception handling routine (interrupts) belongs to a different secure box. This applies to user interrupt service routines, threads and direct function calls.

Memory map varies according to context. The diagram below shows the modification of the memory map when switching from a Box A to a box B

memorymap.png

Initial jump to Thread user mode

All the code that is not explicitly part of the hypervisor is generally referred to as unprivileged code. The unprivileged code is the code that runs in Thread/User mode, and that is therefore unable to modify neither the configuration of the MPU (privileged access required) nor its own access privileges.

The "main()" function of the 2nd level application, called from the startup file, after the initialization of the hypervisor and the C/C++ runtime, is such unprivileged code. Indeed, after initialization, the hypervisor starts executing the "main()" after having switched into the Thread/User mode of execution.

Unprivileged code runs with the following capabilities:

  • runs in Thread/User mode
  • has direct memory access to unrestricted unprivileged peripherals (as defined by the Cortex-M)
  • can require exclusive access to memories and peripherals
  • can register for unprivileged interrupts
  • cannot access privileged memories and peripherals (doing so makes the MPU trigger a CPU fault)

Interrupts and exceptions

Exceptions/interrupts make the Cortex-M switch to Handler privileged mode. Therefore the hypervisor must catch the exception, switch to Thread/User mode and call the registered unprivileged handler.

To this end, interrupt vectors are relocated to the SRAM but protected by the hypervisor. Access to them is made through specific APIs: the unprivileged code can register for unprivileged interrupts. Therefore the hypervisor needs to catch, forward and de-privilege interrupts to the unprivileged handler that has been registered for them.

A context switch is triggered automatically every time an exception handling routine (interrupts) belongs to a different secure box.

Cortex-M Privilege escalation

Interaction from the Thread user code to the Handler privileged code is achieved by exposing SVCall-based APIs. As exception vectors are handled exclusively by the hypervisor, SVC exceptions are caught by this one exclusively, as all the other forms of exceptions (and interrupts).

RPC mechanism

The hypervisor allows inter-box communication through RPCs (Remote Procedure Calls). The callee box can check the origin of the call using the box ID of the caller (and hence it's unique name), and also the box privilege of the caller, in order to determine whether the requested action is legitimate or not. RPC calls trigger context switches.

Definitions:

  • Context A: all applications (boxes) Their ACLs prevent direct access (hardware registers) to sensitive peripherals
  • Context B: PCI box, Secure services box Their ACLs allow direct access to sensitive peripherals

Security context switch (from Box A context to box B context) is done via RPC calls

  1. SVC instruction triggers exception caught by the hypervisor
  2. RPC is managed by the hypervisor
    1. Box A calls RPC (ARM SVC instruction)
    2. Exception triggered by SVC: enters into Handler privileged mode and enters the hypervisor’s “software exception” handler
    3. the hypervisor: Gets caller box (A) ID, target box (B) ID
    4. the hypervisor reconfigures the MPU with context B ACLs
    5. the hypervisor: exits Handler privileged mode, dispatches call to target box
    6. Box B: executes called function

On return, inverse process is applied.

Context switches can also be triggered by interrupts also handled by the hypervisor, the same way. An interrupt makes the Cortex-M enter the Handler privileged mode. However exception vectors are protected by the hypervisor hence the hypervisor catches the interrupt. The execution mode of the Cortex-M is set back to unprivileged by the hypervisor and it then calls the registered interrupt handler.

Summary of MPU protection effects

mpu_control.png

Chain-of-Trust, firmware integrity and authenticity

Secure Boot firmware and verification key are in immutable memories with integrity check

The secure Boot ROM is a trusted immutable code in read-only memory that allows booting the SoC. The use of a Read-Only Memory guarantees de-facto the integrity and authenticity of the Secure Boot firmware itself, as modification of the ROM on an IC die is assumed too costly and highly technical. Integrity of the ROM is verified by a CRC verification before boot: the hardware initialization state machine verifies the CRC before releasing the CPU upon each reset. The CPU will start executing the code only if the ROM CRC is correct.

The Secure Boot ROM guarantees that the firmware that gets executed next is genuine and not modified (authenticity and integrity verification). This is mandated for building trust in the system. The Secure Boot ROM is the Root of Trust.

The secure Boot ROM is designed to launch a 2nd level application from the internal flash memory of the SoC. It requires that the 2nd level application’s digital signature is correct and has been performed with the correct CRK_sign signing key, otherwise it refuses to start it. This digital signature is verified using a public key (Customer Root Key, CRK_verif) stored in a write once memory (OTP, one-time programmable memory) of the SoC.

The CRK_verif integrity is also verified before use. Indeed the MAX325xx contains a public key in ROM (the MRK, Maxim Root Key), owned by Maxim Integrated. The MRK allows verifying the signature of the customer public key (CRK_verif) before it is used. Therefore, customers must submit their public key CRK_verif to Maxim beforehand. Maxim signs this public key with the MRK private counterpart, and returns this signed CRK_verif to the customer. The customer then has to download this signed CRK_verif through the above-mentioned SCP protocol (SCP packets are pre-generated offline in a secure environment using a private key see [DOC11])

As the secure boot ROM firmware and the CRK_verif and MRK verification keys cannot be replaced, the integrity and authenticity of the booted 2nd level application is guaranteed.

chain_of_trust.png
Figure - Chain of trust

No code loading/injection is possible except through a secure loader

The below items guarantee that only trusted code can be loaded into the platform.

Signature verification of downloaded code

The default ACL policy does not grant write access to the internal flash to store executable code and therefore does not allow code updates. However the Secure Boot ROM is capable of updating applications through a serial protocol called SCP. It can securely download new applications into the platform’s non-volatile memory through a serial port or a USB port.

Note: The SCP protocol also allows configuration, life-cycle management and key management. See [DOC11]

Loading and Update of additional secure boxes

In the second version of this specification, a partial update service will be offered, where secure boxes can be independently loaded and/or updated. Those secure boxes must be signed, and the verification will be performed during the uploading (in addition to theit boot time verification already described). An alternate loading service will be provided too, in order to second the SCP offered by the ROM.

To allow partial build, the core firmware will publish the location of symbols so that additional boxes can refer to those symbols (e.g peripheral drivers entry points, C library functions). In order to be able to update the core firmware without breaking the compatibility of the additional boxes already present in the platform's flash memory, those adresses must be kept the same. Some indirect calls can be used to make the preservation of constant adresses easier. Note that an update of the core firmware will most of the time require a recompilation and an update of all secure boxes. Otherwise, secure boxes will possibly be modified, built and loaded separately without any impact on the rest of the software.

Secure boxes will have to be built using position independent code so that they can be stored at random locations. The volatile memory needed by them will also have to be dynamically allocated, because the precense of other secure boxes using potentially the same otherwise static volatile memory adresses may conflict.

Interfacing secure boxes

Secure boxes cannot contain general purpose code accessible through direct call. As a matter of fact, existing secure boxes are usually not aware of newly added boxes and therefore cannot really use them. The boxes can however publish services in a jump table. Those services are RPC functions. Additional boxes can use services by other boxes already present in the platform's flash memory. They can refer to these services knowing the targeted box's name and service ID.

Summary of software items, keys and their protection

Software item PCI Perimeter? Execution privilege Signing key Verification key Location of verification key Verification of verification key by: Verification of software item by:
ROM secure boot Yes Handler privileged None n/a n/a Hardware state machine performs CRC-32 of ROM
Core firmware - privileged (hypervisor) Yes Handler privileged CRK_sign CRK_verif OTP memory ROM secure boot, using a hard-coded MRK public key in ROM ROM secure boot
Secure box - "box firmware" privilege Yes Thread user K_fw K_fw_verif In core firmware binary image ROM secure boot, together with the Core firmware image Core firmware's hypervisor
Secure box - "box trusted" privilege No Thread user K_trusted K_trusted_verif In core firmware binary image ROM secure boot, together with the Core firmware image Core firmware's hypervisor
Secure box - "box other" privilege No Thread user K_other K_otehr_verif In core firmware binary image ROM secure boot, together with the Core firmware image Core firmware's hypervisor

Additional considerations

The following paragraphs give additional justifications to the consistence of the above, security-wise

Absence of backdoors

All MAX325xx SoCs released in the field have no JTAG interface enabled. Therefore it is not possible to bypass or perturbate the executed firmware (in particular the secure boot ROM), or to inject arbitrary code for execution by the platform through a debug interface.

No test mode can be activated after manufacturing operations at Maxim Integrated therefore no possibility to bypass security is provided.

No intentional backdoors for re-enabling the JTAG or any test mode are existing.

The Secure Boot ROM is always executed after reset. It cannot be skipped.

Execution from internal memories

The platform software can be executed from internal flash and optionally internal RAM, and the runtime data are stored in internal RAM. Long term data may be stored in internal flash. Access to the SoC internal memories is a costly attack defeated by the presence of a die shield and is assumed impossible in the present context.

Protection of external memories

The platform software executed from external flash and the related data are protected by the on-the-fly integrity and encryption, and the external flash is protected from physical tampering/replacement throught the SoC intrusion sensors that prevent intrusions in the enclosure. Therefore the external flash memory is protected against manipulation logically. There's is no need for an additional physical protection to protect the external memory ICs and the communication path to the main SoC.

Therefore, the only means to load executable code into the platform is through the Secure Update provided by the Secure Boot ROM.

Early execution the Secure Boot ROM and of the isolation mechanism

The SoC always boots the Secure Boot ROM in any circumstances and starts the 2nd level application (if valid, as discussed above).

The 2nd level application begins by the early initialization of the SoC, the initialization of the security sensors of the SoC and then the initialization of the the lightweight security hypervisor.

The hypervisor is initialized right after device start-up and takes ownership of its most critical assets, like privileged peripherals, the vector table and memory management.

From this moment on, the operating system/application runs in Thread user mode and in the default context, which is the one of the main box.

The next step consists in the creation of the various boxes, the registration of their ACLs and the beginning of the execution of the OS Scheduler that will execute the various threads (a box may contain one or more threads). The overall code is covered by the Secure Boot ROM integrity and authenticity verification and can therefore be trusted.

Additional firmware independent components can be verified and launched by the initial trusted firmware already verified above.

Hardware enforced security

The following hardware features are leveraged by the software described above.

Cortex-M mechanisms: MPU, privileges, NVIC

The Cortex-M3/4's Memory Protection Unit and the Execution mode/Privilege level (Thread/Handler modes of execution, Privileged/User Access) are used to support the software isolation.

1. The Cortex-M's Memory Protection Unit (MPU)

The Cortex-M MPU is used to grant/deny access to regions of the memory map to the unprivileged code (i.e. all the code except the hypervisor)

The MPU could also restrict access even to the privileged code (without the possibility for the privileged code to modify the access) but this feature is not used currently, in the security architecture presented here.

2. The Cortex-M's 2-level execution model

The Cortex-M's 2-level execution mode (Handler, Thread) combined with the 2-level privilege system (Privileged, User) prevents code running in Thread/User mode from breaking the MPU configuration that requires Privileged access. This hardware feature is leveraged by the lightweight security hypervisor. Return to the Privileged/Thread mode can be done only via a SVCall-based API (see http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s02s07.html), i.e. a software triggered exception that can be cached only by the Privileged Handler actually implemented by the Lightweight security hypervisor and that cannot be modified by/re-routed to unprivileged code.

cortex_m3_operationModes.jpg

3. The Cortex-M's NVIC

The interrupt controller is exclusively controlled by the hypervisor, hence no other unprivileged code can register exception handlers. This is vital since the Cortex-M executes exception handlers in Privileged/Handler mode.

NVSRAM - Battery backed non volatile RAM

Sensitive data can be stored in the MAX325xx’s battery backed RAM which gets immediately erased in case of tampering detection (physical tampering, environmental perturbations). The NVSRAM is leveraged by the Key Manager to store long-term secret/private keys that get erased whenever the device is under attack.

Sensors

Environment perturbations (temperature, glitches, die shield, external dynamic sensors,...) lead to the generation of a non maskable interrupt that stops the execution of the platform's software and thus prevents running away into a non secure mode. Sensors are activated before the security hypervisor initialization in order to guarantee the physical integrity of the platform before running further code.

Read-Only Memory, One-Time programmable memory

The Secure Boot ROM is non modifiable and thus inherently trusted, and its configuration or the code verification keys are in a write-once memory (OTP) and cannot be changed. The ROM and the OTP memory areas integrity is verified (Checksum) before use.

Note: hardware security mechanisms are evaluated in a separate report. See report [DOC12].

Secure API

Access to PCI PTS POI sensitive services via API with security policy.

The services offered by the Maxim software library are contained in 3 boxes and can be invoked via RPC calls as described above.

The API entry points are implemented following this behaviour:

  • get the ID of the calling context
  • get box privilege of the calling context
  • grant/deny access to the service depending on the caller's ID, the box privilege, and the context

3 boxes are offered:

  • PCI Security Services boxes (In certification scope)
  • Secure Sandbox Services (In certification scope)
  • Security Monitor Services (In certification scope)

Additional services such as OPEN protocols would also fit into the Secure Sandbox Services.

The API can be found further in this document, see Reference Guide

Maxim Integrated development process

Source code control

The source code of the whole Deeptrust software offer is stored on a secure server at Maxim Integrated. This server features access control:

  • only well-known project stakeholders can read the source code
  • only software developers and push additional code to the source code repository
  • only the software integrator can merge-in new code from software developers
  • only the software integrator can publish new releases after review

The list of stakeholders is controlled by the project manager and can be also modified by some IT administrators. All are personel with a high level of confidence. Roles are:

  • simple stakeholder: read-only access
  • developer: read access, write access to separate branches, cannot merge code into main trunk
  • validator: read access
  • integrator: read/write access + publication rights
  • project manager: read/write access + stakeholder list definition

The source control is implemented using GIT, more precisely a self-hosted Gitlab server. The server is located on Maxim's internal network with all the usual protections applied to corporate level servers that contain company vital data.

Bug tracking

Bugs are tracked using Gitlab's bug tracker. Bugs can be reported by any stakeholder. They can be closed by the integrator or the project manager.

Code review

The following code review process is applied:

  • The third party code and proprietary code are carefully reviewed by software security experts at Maxim, and submitted to an external lab for audit.
  • Issue fixes are reviewed before merging in the main trunk of the code
  • The integrator and project manager are in charge of ensuring reviews are done.

Source code control

The public repositories containing the third party source code included in Deeptrust offer is checked weekly for security bugs and vulnerabilities, in addition to a subscription to the bug trackers:

Such issues are reported in Maxim's internal Bug tracking system for immediate analysis and correction if they are found exploitable. In case of exploitable vulnerabilities, new software releases are published to customers as fast as possible together with the notice describing the issue.

Developer's guidelines

In order to prevent the introduction of vulnerabilites, Maxim Software developers follow company rules for secure coding. These rules can be provided upon request.

In addition, static analysis is performed on the source code to detect potential security issues (RATS, CPPCheck, Visual Code Grepper are all used).

A thorough validation is also performed using the following strategy:

  • development and review of a software test plan
  • functional validation
  • security validation: focus on detection of buffer and integer overflows, fuzzing of the APIs presented in this document, logical security bugs
  • other validation (performance, documentation accuracy)
  • delivery of a software test report The whole code provided in the Deeptrust offer undergoes the above rules.

Firmware versioning and management

The firmware is versioned following this scheme: vX_Y_Z

  • X: is the revision major, currently "1" to match this specification. The mentionned version 2 of this specification will lead to an incrementation of this number.
  • Y: is the revision minor. It is incremented every time new functionalities or bug fixes are done, leading to possible backward compatilibity issues may arise.
  • Z: is the patch number. It is incremented every time a release is done. It usually corresponds to bug fixes or minor functional additions without compatibility issues.

The firmware is developed internally at Maxim using the source control, bug tracking and development guidelines described above. Reviews are performed and recorded on a regular basis, at least before each customer delivery. Validation is performed and recorded, at least before each customer delivery.

Firmware deliveries are tagged and documented (description of the list of changes), together with the review and validation records.

Firmware is released to customers using a public GIT server owned by Maxim, with strict read-only access and access control: Only customers being granted access can read the source code. The hypervisor is released in binary format only. The binary hypervisor is released in the mbed-os source tree, and included into the final software during the mbed-os build step.

Conclusion

The above architecture provides a strong isolation of the sensitive data from regular applications. Sensitive data are handled within Secure Boxes only. Other boxes cannot get access to the data manipulated by these boxes as well as to some peripherals of the platform.

Isolation is enforced by the lightweight security hypervisor, which code and configuration data are protected by the MPU and the execution mode/privilege level system of the Cortex-M core and verified by the ROM based secure boot. the lightweight security hypervisor is executed early in the startup sequence before any user code, and no debug/test/executable code loading exist in the platform.

Therefore the software isolation mechanism cannot be bypassed.

Architecture diagram, PCI firmware perimeter

The overall architecture relies on the following elements

  • Application/other boxes (Out of PCI Certification)
  • PCI Security Services boxes (In certification scope)
  • Secure Sandbox Services (In certification scope)
  • Security Monitor Services (In certification scope)
  • Operating System (In certification scope)
  • Lightweight Security Hypervisor (In certification scope)
  • Secure BOOT ROM (In certification scope)

The architecture enforces the least privilege principle.

pci_cortex.png