- Crypto Acceleration: Not only for speed, but code protection
- True Random-Number Generators
- Memory Encryption: No leak from external bus!
- Secure Boot
- Trusted Execution Environment: RISC-V PMP IOPMP / Virtual Zone
- Tamper Pins Detection: Detect unauthorized opening or tampering
- Bus Monitors: Advanced hardware security
- hsm Hardware Secure Modules
secure boot
Chain of Trust:
- bootrom (ZSBL)
- spl (FSBL)
- opensbi
- u-boot
- kernel
- rootfs
- system
bootrom spl opensbi u-boot kernel rootfs 之间形成链式校验
spl opensbi u-boot kernel rootfs 需要进行加密并加签, 在启动过程中需要解密并验签
system 采用dm-verity 校验.
之间可以引入hsm 进行算法加密和校验请求
The main services and features of the secure boot code are:
• Provides a Root of Trust for the SoC
• Initiates a Chain of Trust for the SoC
• Performs the First-Stage Boot Loader (FSBL) digital signature validation
• Supports Device Identifier Composition Engine (DICE)
• Guarantees Post-Quantum Cryptography (PQC) crypto-agility
• Proposes a secure exchange protocol for code/data programming, tests, and key provi-sioning services
• Proposes a secure boot code secure patch mechanism
• Considers domestic cryptographic requirements
• Complies with good practices and security standards
• Provides high flexibility in the proposed options above (enable/disable)
Hardware Mechanisms and Requirements
Requirements:
• The secure boot code MUST be stored in the SoC internal ROM
• The secure boot code MUST boot the FSBL in less than boot-time ms
• The size for the ROM containing the secure boot code MUST be at least 64KB
• The secure boot code MUST be ready for PQC crypto-agility
• The public keys MUST be stored in the OTP
• The OTP size MUST be at least 2KB (for ECDSA, more if RSA) for the secure boot code
• The OTP size MUST be at least 4KB for crypto-agility
• The OTP controller MUST be able to grant/revoke read-and-write access privileges
◦ For all or parts of the OTP
◦ The DICE UDS read access MUST be deactivable by the secure boot code
◦ The DICE UDS write access MUST be disabled
• The OTP read/write access privileges MUST be based on time condition
◦ For all or parts of the OTP
• The OTP read/write access privileges MAY be based on authentication conditions
◦ For all or parts of the OTP
• The secure boot code MUST support the ECDSA p384/SHA384 digital signature algo-
rithm
• The secure boot code MUST support the SM2/SM3 digital signature algorithm
• The secure boot code MUST support the FALCON digital signature algorithm
• The secure boot code MAY support the ECDSA p256/SHA256 digital signature algorithm
• The secure hash SHA-384 implementation MUST be a hardware block (for performance
requirements)
◦ This hardware block MUST be accessible from the core executing the secure boot
code
• The secure hash SM3 implementation MUST be a hardware block (for performance
requirements)
◦ This hardware block MUST be accessible from the core executing the secure boot
code
• The ECDSA and SM2 algorithms MUST have hardware support for performance (e.g.,
modular multiplication)
◦ This hardware block MUST be accessible from the core executing the secure boot
code
• A communication interface MUST be available to the secure boot code, usually a UART
◦ This interface is used for initial and recovery programming
• A GPIO MUST be available for triggering the secure communication session
• The internal RAM size MUST be at least 64KB
◦ It depends on the size of the applets (a feature used in the communication protocol to
extend commands; it’s very helpful to simplify the secure boot code)
• The NVM where the FSBL is located MUST be available to the secure boot code in read
(for execution) and write (for programming) modes
• The debug availability policy MUST be specified
◦ If available, the secure boot code MAY be in charge of enabling it
• The secure boot code MUST contain anti-fault mechanisms during sensitive computations
◦ Note: The other subsequent parts of the secure boot process, too
• The secure boot code software validation MUST assess the robustness against faults
(and not be only a functional validation)
• The [rng] (for secure provisioning service) MUST be accessible by the secure boot code
• A [hash-function] hardware block and a managing FSM MUST be available for secure
boot code verification before start
• The secure boot code MUST be in charge of the DICE CDI computation for the FSBL
using the UDS from the OTP
◦ The UDS read access MUST be disabled after CDI computation
◦ The debug interface MUST NOT be available before UDS read access disabling
• The secure boot code MUST be written using good practices for secure coding, including
those presented in: https://www.ssi.gouv.fr/uploads/2020/05/anssi-guide-regles_de_pro-
grammation_pour_le_developpement_securise_de_logiciels_en_langage_c-v1.1.pdf
• The secure boot code MUST clean any sensitive information contained in the volatile
memory after its use
• The secure boot code MUST support GPT parsing for FSBL image booting
• The secure boot code MUST implement an anti-rollback protection mechanism
◦ The anti-rollback mechanism MUST support at least 32 versions
▪ It requires 128 bytes for version storage
◦ The anti-rollback mechanism MUST use the internal OTP
DCIE
DICE是一个用于设备身份、证明和数据加密的行业标准。它要求使用一些加密原语（哈希、HMAC）和每个SoC唯一的256位秘密，命名为UDS。这个UDS必须得到严格的保护，以防止嵌入式软件的任何读取访问。其原理是将一个独特的、可重复的秘钥与设备上运行的每个软件阶段层联系起来。最初的秘钥，也就是与FSBL绑定的秘钥，又称第0层，是由安全启动码使用FSBL的哈希值计算出来的。FSBL可以通过计算下一个CDI，对应于下一个软件阶段（如U-boot）来重现相同的方案，以此类推，直到达到最后一个应用阶段。然后，任何一层都有自己的秘钥（公钥对也可以从CDI中得到）。
Key Management
