![]() |
Deeptrust for PCI security architecture
SPEC98T17 rev E
Specification of Deeptrust, the Security Architecture for Cortex-M.
|
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.
Keys are needed for different purposes in the scope of PCI PTS.
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 may be added while enhancing and customizing the Deeptrust for PCI software.
Keep your private key really private, and have strict access control to that key.
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.
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..
Beyond the good practices applied by Maxim Integrated in the scope of the development of Deeptrust for PCI, the following recommendations apply to customers:
The software is split in three major parts
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:
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:
In order to add a new box (every instance of box_NAME below must be replaced), the following rules apply:
%.elf.signed: %.elf Makefile
, add an additional line: 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.
In a further evolution, it will be possible to independently load/update boxes. To achieve this goal:
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 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:
The provided solution ensures the minimal software configuration through the use of GCC's options:
The above options eliminates dead code. Hence, by definition, only the strictly useful code is embedded in the final binary.
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.
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:
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
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:
The Deeptrust for PCI provides an automatic 24-h reboot
Adaptation of the Deeptrust for PCI to a new platform requires the following steps: