Deeptrust for PCI security architecture  SPEC98T17 rev E
Specification of Deeptrust, the Security Architecture for Cortex-M.
Security Guidelines

This section explains how to maintain PCI PTS POI 5.0 compliance of the Deeptrust for PCI security architecture.

The Deeptrust for PCI security architecture has been pre-evaluated and the associated report is provided. In order to guarantee the preservation of the pre-evaluation results, the good practices exposed here must be applied.

Note: this document in only a set of guidelines that does not replace the applicable PCI PTS POI security Requirements.

Key Management

Keys are needed for different purposes in the scope of PCI PTS.

Deeptrust for PCI's keys

The Deeptrust for PCI software uses the following keys:

Key name/purpose Key Algorithm/length Public part location Sec/Priv. part location Integrity protection
MRK / Maxim root key (CRK signing key) ECDSA Secp256r1 w/ SHA256 In MAX325xx ROM In HSM at Maxim Checked by CRC
CRK / Core firmware signing key ECDSA Secp256r1 w/ SHA256 In MAX325xx OTP Memory In HSM signature verified by MRK
Kfw / Box signing key w/ FW privilege ECDSA Secp256r1 w/ SHA256 In Core firmware In HSM signature verified by CRK
Ktrusted / Box signing key w/ TRUSTED privilege ECDSA Secp256r1 w/ SHA256 In Core firmware In HSM signature verified by CRK
Kother / Box signing key w/ OTHER privilege ECDSA Secp256r1 w/ SHA256 In Core firmware In HSM signature verified by CRK
DUKPT IPEK (example) - not verified, tamper response w/ processor package
DUKPT Current/Future keys (example - not verified, tamper response w/ processor package

According to [REFXXXX], the MRK's public part is stored in the MAX325xx's ROM. The private counterpart is stored in a HSM controlled by Maxim. The purpose of the MRK is to allow loading a CRK previously signed. Maxim customers generate their CRK key pair and send the public part to Maxim. Maxim signs the CRK using the MRK stored in the HSM (signature operation is allowed to a restricted list of personnel). The signed CRK is returned to the customer who can install it into the MAX325xx. During installation, the CRK is transferred to the MAX325xx OTP memory after its signature has been verified by the MRK public key present in the ROM.

After this CRK loading operation, the customer can download a new firmware signed by the private part of the CRK. Upon boot the MAX325xx verifies this firmware signature using the public part of the CRK present in the MAX325xx OTP memory.

Once the core firmware is booted (if successfully verified by the CRK), it will check the signature of boxes using the appropriate Box signing public keys it contains (those keys are verified at the same time as the core firmware.

If all boxes signatures are correct, the software will execute normally.

Additional keys

Additional keys may be added while enhancing and customizing the Deeptrust for PCI software.

  • Asymmetric Signing/Encryption keys must be at least 2048-bit long for RSA or 256-bit long for EC based algorithms
  • Symmetric keys must be at least 128-bit long for AES or 256-bit long for EC based algorithms
  • Signing/Encryption keys stored out of the MAX325xx must be stored inside a Hardware Security Module (HSM). Access to the HSM must be gated by Smart Cards, protected by PIN codes. Vital keys must be protected by a sufficient quorum depending on the purpose of the key (e.g. firmware signing keys) The HSM should be stored in a safety deposit box when not used, and operated in a room with access control when in use.
  • It is the responsibility of the customer to handle additional keys according to the following PCI requirements:
    • Generate your own private keys using certified products (hardware or software). Do not use the test keys provided in the SDK for deployment. Maxim Integrated provides PCI compliant tools for production.

Keep your private key really private, and have strict access control to that key.

  • Export the public key into a “UCL” compliant format as exposed in this user manual.

Storing keys inside the MAX325xx

The MAX325xx contains a battery-backed, tamper-reactive, non-volatile RAM (NVSRAM). This RAM is internal to the MAX325xx SoC, and its content is encrypted by a random symmetric key using AES.

Tamper detectors and battery presence are continuously monitored. If a tamper detector is triggered or the battery is removed or drained, the NVSRAM is instantly wiped.

Therefore it is strongly advised to store private or secret keys directly in the NVSRAM. If more space is needed for key storage, then store the above keys ENCRYPTED in another memory location, and keep the key encryption key in the NVSRAM.

Device Provisioning

The Deeptrust for PCI software does not provide any platform provisioning service such as initial key loading or sensor activation. Such tasks should be performed during manufacturing. Maxim can provide detailed recommendations. The principle relies on the usage of the Secure Boot ROM's SCP protocol to download an authenticated temporary RAM application that performs the provisioning and sensor initialisation.

The Deeptrust for PCI software does not provide any key injection service.

The Deeptrust for PCI software does not provide any separate secure box update/loading in this release..

Software development

Beyond the good practices applied by Maxim Integrated in the scope of the development of Deeptrust for PCI, the following recommendations apply to customers:

Software layout

The software is split in three major parts

  • Secure boot ROM
  • The core firmware
  • Additional boxes

The secure boot ROM is part of the MAX325xx SoC. It verifies the digital signature of the core firmware.

The core firmware contains the lightweight hypervisor, mbed-os (drivers and RTOS), startup code, C and C++ runtime libraries. It verifies the signatures of the additional boxes and prepares them for execution.

Additional boxes are:

  • Secure Sandbox Services (a set of generic purpose secure services)
  • PCI security services (a set of services dedicated to PIN management)
  • An example demo (leveraging the two above boxes)

Additional boxes are compiled and linked simultaneously to the core firmware. However, their location in flash memory is clearly separated from each other. As a result, the overall layout of software image is the following:

Flash Address Item
bottom
Core FW header
Core FW image
Core FW signature
Box#1 header+signature
Box#1 configuration
Box#1 FW image
Box#2 header+signature
Box#2 configuration
Box#2 FW image
...
Box::n header+signature
Box::n configuration
Box::n FW image
Additional data storage
Top

This layout is defined in the file ./mbed-os/target/TARGET_Maxim/common/max325xx.ld.inc. The Makefile defines the build process:

  • compilation and link of the whole software
  • injection of the boxes signature verification keys into the core firmware
  • signature of the core firwmare using the CRK
  • signature of additional boxes using specific signing keys

Adding new boxes

In order to add a new box (every instance of box_NAME below must be replaced), the following rules apply:

  1. create a new folder box_NAME in ./sources (or in a sub folder located under ./sources).
  2. create a file sourcefile.cpp containing:
    #include "uvisor-lib/uvisor-lib.h"
    #include "mbed.h"
    #include <errors.h>
    #include <stdint.h>
    #include <string.h>
    static const UvisorBoxAclItem my_acl[] = {
    //Put list of ACLs here
    };
    #define BOX_NAME box_NAME
    // Box Main Thread
    static void box_appli_main(const void *);
    typedef struct {
    // Declare globals going to the box's private heap here
    } box_context;
    // Configure the box.
    UVISOR_BOX_HEAPSIZE(0x1000);
    UVISOR_BOX_MAIN(box_appli_main, osPriorityNormal, 0x800);
    UVISOR_BOX_CONFIG(BOX_NAME, my_acl, 1024, box_context, SIGNING_KEY_XXXXX);
    void box_appli_main(const void *) {
    while (1) {
    }
    }
  3. in the above, replace SIGNING_KEY_XXXXX by the appropriate signing key identifier (one of SIGNING_KEY_FW, SIGNING_KEY_TRUSTED, SIGNING_KEY_OTHER)
  4. extend the file ./mbed-os/target/TARGET_Maxim/common/max325xx.ld.inc
  5. below the marker "SECURE BOXES", add this set of definitions:
    .text.box_NAME_cfg :
    {
    *path/to/box_NAME*(.keep.addmodules*)
    }> FLASH_MOD
    .text.box_NAME_code :
    {
    __start_box_NAME = .;
    *path/to/box_NAME*(.text* .rodata*)
    FILL(0xab)
    . = ALIGN(4);
    } > FLASH_MOD
    .data.box_NAME_datainit :
    {
    KEEP(*path/to/box_NAME*(.data*))
    FILL(0xab)
    . = ALIGN(4);
    } > RAM AT > FLASH_MOD = 0xcc
    __start_box_NAME_data_src = LOADADDR(.data.box_NAME_datainit);
    __start_box_NAME_data_dest = ADDR(.data.box_NAME_datainit);
    __end_box_NAME = LOADADDR(.data.box_NAME_datainit)+SIZEOF(.data.box_NAME_datainit);
  6. Modify the top Makefile: in the target %.elf.signed: %.elf Makefile, add an additional line:
    $(call signmodule,box_NAME,$(SIGNINGKEY_XXX_PEM),$(TEMPDIR)${<F}.temp)
    Replace SIGNINGKEY_XXX_PEM by the appropriate file name that contains the private signing key.

Firmware signature

As explained above, different software parts have to be signed using different keys.

Item Signing key
Core FW CRK
Box#1 Kfw/Ktrusted/Kother
Box#2 Kfw/Ktrusted/Kother
...
Box::n Kfw/Ktrusted/Kother

The CRK protects the core firmware, which is firmware in the PCI terminology.

The boxes signature keys protect the boxes executable code and their configuration (ACLs). The signing key also define their privileges, via the implementation of the function "check_acl" which is part of the core firmware, and via the access control performed during RPC calls (See Code partitioning: Core firmware and Secure containers (aka "boxes")).

Failure to verify any signature leads to a reset of the platform.

Software modularity

In a further evolution, it will be possible to independently load/update boxes. To achieve this goal:

  • boxes must use no global variables. Dynamic memory must be used instead. The lightweight hypervisor ensures that dynamically allocated memory is kept private to the box.
  • boxes must be built using position independent code so that they can be loaded at unknown addresses in memory
  • core firmware symbols must be available to allow linking boxes with the core
  • references between boxes (achieved via RPC)

Secure boxes code review

Secure boxes must all be signed. Depending on the signing key, they will be granted various privileges. The Deeptrust for PCI architecture guarantees that the ACLs requested by the box cannot go beyond what is allowed by the use of the function check_acl, and also that boxes that provide RPC services can filter out calls based on the name and/or signing key of the caller.

Therefore, the signature key used for signing a box must be in accordance with the purpose of the box (least privilege principle). The check_acl function must not grant access to sensitive peripherals or memory area to boxes that do not need them.

Developer guidance on how to correctly configure and review Deeptrust implementations to ensure that they are correctly isolating non-security code:

Before using a signing key to approve a box for being added to the software or firmware, the developer must ensure that:

  • the check_acl function correctly limits the ACLs of boxes
  • even if allowed by check_acl for the selected signing key,
  • the code must be manually reviewed and tested to make sure that:
    • their sensitive data is kept in secure memory and not leaked in the public memory (use the private heap of the box)
    • the access control to their services offered via RPC is correctly implemented and tested
    • the ACLs of the box are restricted to what as strictly needed (minimum privilege, even if enforced by check_acl)
    • no bug may lead to leaking sensitive data
    • no bug may lead to a crash of the platform
    • the secure box does not monopolize the CPU resources

The use of static analysis is strongly recommended together with a manual code review.

The lightweight hypervisor provides some runtime checks of memory corruptions and overflows, in addition to GCC's stack protector feature used for the core firmware and additional boxes. This somehow mitigates the effect of bugs.

Mitigation of fuzzing is also implemented:

  • A reset counter in NVSRAM is incremented at every platform reset
  • It is automatically erased after a while so that no more than 1 reset per 30sec period is allowed
  • If the reset occurs too frequently, a time penalty of 60 seconds is added

Minimal configuration

The provided solution ensures the minimal software configuration through the use of GCC's options:

  • -fdata-sections -ffunction-sections for compiling
  • -Wl,–gc-section for linking

The above options eliminates dead code. Hence, by definition, only the strictly useful code is embedded in the final binary.

Cryptographic services

Encryption/decryption: The Deeptrust for PCI offers APIs [REFXXXX] that do not allow arbitrary encryption/decryption or signature. It uses 3DES for encryption of PIN.

Digital signature: It uses ECC digital signature for verification of integrity and authenticity of firmware and application images. It may use RSA/ECC digital signature for verification of smart card certificates (not included in this release).

Other services: An additional cryptographic library (UCL) is delivered and allows arbitrary cryptographic operations using any key (encryption / decryption, signature/verification, using AES, 3DES, ECDSA, RSA).

An additional key manager and wrapper above the UCL will provide strictly controlled cryptographic services isolated within a secure box.

PIN and cardholder data management

The provided Deeptrust for PCI uses DUKPT based PIN encryption only using ISO Format 0. The PIN is captured upon request using the PCI security services box that has exclusive access to display and keypad at that time. The PIN is read from keypad or touchscreen and stored in a buffer for 60s. From here, it can be encrypted w/ 3DES using DUKPT current key, or submitted to a smart card for verification.

PIN is erased from memory:

  • if the 60s timer expires
  • if the platform is reset (whatever the reset source)
  • if the PIN is used (with DUKPT in uvisor_ctx->resetcount or submitted to card in __pci_verify_offline_pin)

NOTE: AES for ISO format 4 PIN blocks will be supported in a further release

Prompt management

In the current release, prompts are hard coded in the Secure Sandbox Services box, and RPC clients can request displaying prompts via an identifier.

Customers may relax this constraint using the new separate box signing feature:

  • Boxes signed with Kfw are considered PCI firmware and can display arbitrary prompts
  • Other boxes can not display arbitrary prompts

Self Tests

The Deeptrust for PCI provides an automatic 24-h reboot

Customer integration

Adaptation of the Deeptrust for PCI to a new platform requires the following steps:

  • Development of the Board Support Package within mbed-os/target:
    • Adapt to the actual (touch)screen and pinpad
    • Adapt the board level power management (battery charging, PMIC, etc)
  • Customization of the Deeptrust API services:
    • Customize or adapt the APIs provided by the boxes Secure sandbox services PCI security services
  • Adapt the data processing required for the target application: The default provided PCI security services box is able to perform EMV Level 2 PIN transaction with a smart card, and DUKPT based PIN encryption for online submission
    • Add more PIN block formats
    • Implement remote communication link for online transactions
  • Development of the client application(s) leveraging the PCI security services and secure sandbox services
  • Integration of other third party applications