全链路安全方案，助力CRA合规与IEC 62443认证-米尔RK3576核心板

出海欧盟，安全已是准入门槛
2024年12月，欧盟《网络弹性法案》（Cyber Resilience Act，简称CRA）正式生效。这项法规为所有含数字元素的产品设定了强制性网络安全要求——安全不再是锦上添花的功能，而是进入欧盟市场的硬性准入条件。

CRA覆盖范围极广，工业控制器、边缘计算设备、智能网关等嵌入式产品均在其列。不合规的后果同样严厉：最高可达全球年营业额2.5%或1500万欧元的罚款，以及产品禁售、召回等强制措施。法案将于2027年12月全面实施，留给企业的准备时间已经不多。
IEC 62443：工业网络安全的"黄金标准"

IEC 62443是工业自动化与控制系统（IACS）网络安全领域全球公认的权威标准体系，也是CRA合规路径中最核心的技术参考框架。CRA的协调标准EN 40000系列直接引用了EN IEC 62443，两者在安全设计、漏洞管理、安全更新等核心要求上高度一致。获得IEC 62443认证，是企业证明CRA合规能力的最有效路径之一。

对于嵌入式设备厂商而言，CRA和IEC 62443对产品提出了多维度的安全要求：硬件层面需要安全启动、加密引擎、可信执行环境；软件层面需要系统完整性保护、安全更新机制；流程层面需要漏洞管理、安全开发生命周期。选择一款安全能力完善的核心板平台，是产品快速满足合规要求的关键一步。米尔电子基于瑞芯微RK3576推出的MYC-LR3576核心板，提供从硬件根信任到OTA安全升级的全链路安全方案，为工业设备的CRA合规与IEC 62443认证提供坚实的底层支撑。

七层安全架构，构建纵深防御体系
MYC-LR3576的安全体系不是单点功能的堆砌，而是一套分层设计、层层递进的纵深防御架构。从芯片硬件到应用层，每一层都有对应的安全机制守护：

1. 硬件根信任层 — OTP一次性可编程存储器 + 硬件加密引擎 + TRNG真随机数
2. 安全启动层 — FIT签名方案，从BootROM到Kernel的完整信任链
3. 可信执行环境层 — ARM TrustZone + OP-TEE OS，密钥与安全运算隔离运行
4. 系统完整性层 — dm-verity只读分区校验 + dm-crypt分区透明加密
5. 安全存储层 — KeyBox密钥管理 + RPMB防重放存储
6. 安全升级层 — CMS签名OTA，确保升级包来源可信、完整未篡改
7. 安全等级配置 — Level 0/1/2三档可选，按需匹配安全强度

下面我们逐层拆解这套安全方案的技术细节，以及它如何对应CRA与IEC 62443的合规要求。
 

硬件根信任：OTP筑牢信任起点
一切软件安全机制的前提，是有一个不可篡改的硬件信任根。RK3576芯片内置了丰富的硬件安全外设，为整个安全体系奠定基石。

• ?? OTP可编程存储

公钥哈希、安全启动标志、OEM密钥全部写入OTP，一经烧录不可篡改，是信任链的根锚点。

• ? 硬件加密引擎

RSA/ECDSA签名验证、AES/SM4加解密全硬件加速，性能远超软件实现。

• ?? TRNG真随机数

基于物理噪声的真随机数源，为密钥生成提供高质量熵源。

• ?? RPMB安全存储

eMMC内置防重放安全存储块，配合硬件密钥机制，确保数据只能本设备读写。
OTP分区：安全的保险箱RK3576的OTP分为非安全区和安全区。非安全世界（Linux/U-Boot）可直接读取非安全区，但安全区只有OP-TEE等安全世界代码才能访问。Secure OTP中的OEM Zone包含：公钥哈希、安全启动使能标志、安全等级配置、OEM硬件唯一密钥（一机一密）、仅TA可访问的受保护区域、以及4组只写不读的加密密钥区。

关键设计：OEM Cipher Key 只写不读

客户将密钥烧入Cipher Key区域后，系统只提供加密/解密的算法调用接口，不提供密钥读取接口。即使Linux系统被完全攻破，攻击者也无法获取密钥明文——密钥永远留在硬件内部。

对应合规价值：硬件根信任是IEC 62443-4-2中"Identification & Authentication Control"（标识与鉴权控制）和"Use Control"（使用控制）的基础，也是CRA"安全设计（Secure by Design）"要求的核心体现。硬件级别的密钥保护，为产品的技术文档提供了最坚实的安全证据。
 

安全启动：构建不可绕过的信任链
安全启动（Secure Boot）是设备安全的第一道防线，它确保设备只运行经过授权的固件，从根本上杜绝恶意固件的加载。

完整的信任链MYC-LR3576采用FIT（Flattened Image Tree）签名方案，构建了一条从BootROM到系统的完整信任链：

BootROM（芯片出厂固化，不可修改）

   ↓ 验证Loader签名（读取OTP中的公钥Hash）

Loader / SPL

   ↓ 验证OP-TEE OS签名

OP-TEE OS（安全世界初始化）

   ↓ 验证U-Boot签名

U-Boot（正常世界引导加载器）

   ↓ 验证boot.img（Kernel + DTB + Ramdisk）签名

Kernel（已验证）

   ↓ 通过OP-TEE驱动与安全世界通信

System（dm-verity/dm-crypt保护系统分区）

   ↓ 应用程序（通过CA调用TA实现安全功能）

这条信任链的根是芯片BootROM中固化的代码——它在芯片出厂时就已经写死，任何人都无法修改。BootROM通过OTP中的公钥哈希建立对Loader的信任，Loader再验证下一级，环环相扣，一级不通过就无法继续启动。开启安全启动后，任何未经签名的固件都无法启动，从物理层面杜绝了固件篡改和克隆的风险。对应合规价值：安全启动直接对应IEC 62443-4-2的"Software Integrity & Hardening"（软件完整性与加固）要求，也是CRA Annex I中"防止未授权访问和权限提升"要求的关键实现手段。它确保设备启动过程的每一步都经过验证，有效防御固件篡改和降级攻击。

可信执行环境：密钥永远不离开安全世界
ARM TrustZone技术将SoC的硬件和软件资源划分为两个世界：

• 非安全世界（Normal World）：运行Linux操作系统和用户应用。即使被攻破，也无法访问安全世界的数据

• 安全世界（Secure World）：运行OP-TEE OS和可信应用（TA），处理密钥、加解密、安全存储等敏感操作

两个世界通过SMC指令进行切换，硬件级隔离，非安全世界的代码无法直接读写安全世界的内存。

KeyBox：密钥管理可信应用米尔SDK内置了KeyBox参考实现，这是一个运行在OP-TEE中的密钥管理可信应用（TA）。上层应用通过Client App（CA）调用KeyBox接口，安全地读写密钥。KeyBox支持两种存储后端：

• RPMB：eMMC内部、硬件防重放、防回滚，空间约512KB

• Security分区：eMMC用户分区、空间更大（1MB+），通过TEE加密保护

防回滚设计：TA版本号机制

RK3576平台的TA支持版本号防回滚。开发者在TA的Makefile中定义CFGTAVERSION后，系统会禁止TA版本降级。即使攻击者拿到了旧版本有漏洞的TA，也无法在新版本设备上运行。
丰富的安全算法能力

• SHA摘要算法：SHA-1/SHA-256/SHA-512，数据完整性校验

• AES对称加密：AES-128/256，ECB/CBC/CTR等多种模式

• RSA非对称加密：RSA2048/4096，加解密、签名验签
• TRNG真随机数：硬件级随机数生成，用于密钥派生

对应合规价值：OP-TEE可信执行环境对应IEC 62443-4-2的"Cryptographic Support"（密码学支持）和"Data Confidentiality"（数据保密性）要求。密钥在隔离环境中运算，符合CRA对"适当加密级别"和"访问控制机制"的要求，是高安全等级产品的必备能力。
 

系统完整性：dm-verity与dm-crypt双重保护
安全启动保证的是"启动时"的信任，但系统运行后的完整性同样需要保护。MYC-LR3576基于Linux内核的Device Mapper机制，提供两种系统级保护方案。

dm-verity：只读分区完整性校验dm-verity为只读的system分区提供块级别的完整性校验。它将系统分区按4KB切块，对每个数据块计算哈希，构建多级哈希树，并将根哈希（Root-Hash）打包进boot.img的Ramdisk中。运行时，Kernel对每次I/O访问的4K数据块实时进行哈希校验，与哈希树比对。一旦校验失败，直接返回I/O错误——即使攻击者修改了system分区的某个字节，dm-verity也能检测到并阻止读取。

dm-crypt：分区透明加密对于有更高数据安全要求的场景，MYC-LR3576支持dm-crypt系统加密方案。数据写入分区时自动加密，读取时自动解密，对上层应用完全透明。加密密钥存储在RPMB或Security分区中，通过KeyBox/OP-TEE保护。密钥永远不会以明文形式出现在非安全世界的内存中。对应合规价值：系统完整性保护直接满足IEC 62443-4-2的"Software Integrity & Hardening"（软件完整性与加固）和"Data Confidentiality"（数据保密性）要求。dm-crypt的透明加密能力，也符合CRA对产品数据保护的要求，特别是涉及敏感数据的工业控制场景。
 

安全OTA：CMS签名确保固件可信
设备交付后，固件升级是必然需求。但如果OTA升级通道不安全，攻击者就可能通过中间人攻击注入恶意固件，让之前所有的安全措施功亏一篑。CRA明确要求制造商必须提供安全更新机制，并且在产品支持期内持续提供安全修复。安全更新能力，是CRA合规的核心要求之一。

CMS签名机制MYC-LR3576的安全OTA采用CMS（Cryptographic Message Syntax）签名机制，基于RFC 5652标准，确保升级包的：

• 完整性：数据没有被篡改

• 来源真实性：数据确实来自持有私钥的官方

• 不可抵赖性：事后不能否认签名行为

验证流程如下：

设备端执行updateEngine --signed_image_url=...

   ↓ 检测到signed_image_url → 进入签名验证流程

   ↓ 解析镜像，提取CMS签名和MD5校验值

   ↓ MD5校验 → 验证数据完整性

   ↓ 加载公钥 → CMS签名验签

   ↓ 验签通过 → 重新拼接镜像和MD5 → 正常OTA升级

   ↓ 验签失败 → 升级终止，拒绝写入

签名OTA镜像与安全启动使用同一组密钥，密钥管理统一，降低运维复杂度。编译时执行一条命令即可生成签名后的升级镜像。对应合规价值：安全OTA是CRA"安全更新（Security Updates）"要求的直接实现，也是IEC 62443-4-2中"Patch & Update Management"（补丁与更新管理）要求的核心组件。签名验证机制确保升级过程不会引入恶意固件，满足CRA对固件完整性和真实性的要求。

三级安全等级：按需配置，灵活平衡
不同应用场景对安全强度的需求不同。RK3576支持三档TEE安全等级，客户可根据产品定位和合规需求灵活选择。

L2 强安全方案主控与eMMC强绑定，更换主控必须同步更换eMMC和擦除安全存储。基于芯片出厂Device Root Key派生密钥，一机一密，不可复制。适用于金融、车载等最高安全需求场景。
L1 中安全方案主控与eMMC弱绑定，OEM自定义HUK派生密钥。更换主控后可通过烧录相同OEM HUK复用eMMC，兼顾安全性和量产便利性。适用于工业控制、智能网关等场景。
L0 基础方案主控与eMMC不绑定，使用芯片统一Soft HUK。适用于安全要求较低、成本敏感的场景，SDK默认配置。
注意：安全等级只能配置一次
芯片的安全等级是一次性写入OTP的，配置后无法修改。请在产品设计阶段就确定安全等级，米尔可提供技术咨询协助选型。

一张图看懂：安全能力如何对应合规要求
MYC-LR3576的全链路安全能力，从硬件到软件全面覆盖CRA与IEC 62443的核心技术要求。以下是关键对应关系：

出海欧盟，从选对平台开始

选择MYC-LR3576核心板，意味着你获得的不只是硬件，更是一套经过验证的安全方案底座。它能帮助你的产品在CRA合规和IEC 62443认证的道路上，大幅减少底层安全研发投入，缩短合规准备周期，把更多精力聚焦在应用层业务功能上。

米尔电子：开箱即用的安全方案交付
安全功能的实现涉及硬件、Bootloader、内核、TEE、文件系统等多个层面，开发门槛高、调试周期长。选择MYC-LR3576核心板，意味着你获得的不仅是一块硬件，更是一套已经验证、可以直接落地的完整安全方案。

安全相关交付物

适用场景

• ?? 工业控制

PLC、工业网关、边缘计算终端，满足IEC 62443与CRA合规要求

• ?? 车载终端

车载中控、T-Box，满足车规级安全与防降级要求

• ?? 金融终端

POS机、自助终端，保护密钥和交易数据

• ?? 安防监控

智能NVR、门禁设备，防止设备被攻破

• ?? 医疗设备

诊疗设备、医疗网关，保护患者数据隐私

• ?? 智能网关

5G/工业网关、边缘节点，保护通信密钥