blog
blog copied to clipboard
carloscn
My blog
# 1. SECURITY ARCHITECTURE Architecture: Functional Blocks: # 2. Memory Architecture For HSE # 3. HSE Boot Artifacts (IVT/HSE FW) The secure boot flow involves multiple software bootloaders – this...
# [S32K344] Boot And Reset Sequence This document describes the boot and reset sequence on the S32K344 hardware platform. In this section, we need to understand many mechanisms, the state...
在ls104x上，pkcs11是通过NXP开发的libsecure_obj来加载的。  完成openssl engine pkcs11的支持，需要配置两个地方： * OpenSC提供了libp11，这个开源库提供了一个higher-level层级的接口用于访问PKCS11的object。OpenSSL直接和这一层进行交互； * pkcs11 engine plugin，是NXP提供的插件，是libp11调用的一层，由NXP开发；可以在NXP的sdk找到； # OpenSC的libp11库交叉编译 交叉编译 libp11的库需要提前准备好，交叉编译的openssl的输出。 ```bash rm -rf libp11 git clone https://github.com/OpenSC/libp11 cd libp11 && ./bootstrap && \ ./configure --host=aarch64-linux-gnu...
## 1. 引言 S32K344启动Secure Boot之后。HSE要生成/存储密钥，对IMAGE进行签名，当Key catalog和SMR以及BOOT_SEQ等位通过刷写被清空之后，还能输入新的固件。换句话说，当攻击者通过JTAG或者OTA方式清空了芯片身上的key catalog和SMR区域等之后刷入自己的固件，HSE将对攻击者的固件进行签名，并存储攻击者的固件密钥，整个芯片视攻击者的固件为可信固件。因此要阻止该事情的发生，启动Secure Debug以及Secure OTA，同Secure Boot形成互补的安全应用闭环。 以下为攻击者可以刷写自己固件的路径： * 通过JTAG路径，重置HSE状态，清空原始Key Catalog，清除SMR区域； * 通过OTA路径（对于使能A/B分区的设备），使用串口、CAN、网口等外部接口刷写Flash （Secure boot的A/B分区模式可以防止这种情况）  对于OTA路径，由于Secure Boot可以Cover，本文暂时不去解释。本文主要应对与JTAG路径。对于启动JTAG的设备，需要采取相应地安全措施，防止攻击者通过JTAG路径强刷固件，致使HSE状态重置，防止清空原始Key Catalog，以及阻止清除SMR区域。 ## 2. 原理 参考： https://www.pemicro.com/blog/index.cfm?post_id=216 NXP的S32K3xx设备系列包含一种高级的安全调试机制，通过密钥保护用户应用程序。在启用安全调试功能后，调试器必须经过密码认证或挑战响应认证才能进行调试。 NXP的S32K3xx设备在标准的S32DS调试会话开始时，可能需要用户执行密码认证或挑战响应认证。这些安全调试模式通过要求正确的凭证来认证调试器，从而防止未经授权的调试访问。每次进行破坏性复位或上电复位后，均需重新进行认证。 -...
# [S32K344] Secure Boot Application ## 1. Overall 本文来捋顺以下，Secure Boot如何使能。和其他MCU的Secure Boot不同，S32K344的固件需要SoC之上的HSE进行密钥管理和固件签名，而其他的MCU控制器通常是在编译固件的时候进行签名，接着使用烧录器烧录到芯片的NVM中。 对于一般的Secure Boot和S32K3系列的Secure Boot做以下对比： | | 一般MCU | S32K344 | |--------------------------|-----------------------------|----------------------------| | **代码编译** | HOST |HOST | | **RSA私钥存储** |...