http://www.gkong.com 2026-07-31 09:42 来源:米尔电子
出海欧盟,安全已是准入门槛
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的安全体系不是单点功能的堆砌,而是一套分层设计、层层递进的纵深防御架构。从芯片硬件到应用层,每一层都有对应的安全机制守护:
下面我们逐层拆解这套安全方案的技术细节,以及它如何对应CRA与IEC 62443的合规要求。
硬件根信任:OTP筑牢信任起点
一切软件安全机制的前提,是有一个不可篡改的硬件信任根。RK3576芯片内置了丰富的硬件安全外设,为整个安全体系奠定基石。
公钥哈希、安全启动标志、OEM密钥全部写入OTP,一经烧录不可篡改,是信任链的根锚点。
RSA/ECDSA签名验证、AES/SM4加解密全硬件加速,性能远超软件实现。
基于物理噪声的真随机数源,为密钥生成提供高质量熵源。
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的硬件和软件资源划分为两个世界:
两个世界通过SMC指令进行切换,硬件级隔离,非安全世界的代码无法直接读写安全世界的内存。
KeyBox:密钥管理可信应用米尔SDK内置了KeyBox参考实现,这是一个运行在OP-TEE中的密钥管理可信应用(TA)。上层应用通过Client App(CA)调用KeyBox接口,安全地读写密钥。KeyBox支持两种存储后端:
防回滚设计:TA版本号机制
RK3576平台的TA支持版本号防回滚。开发者在TA的Makefile中定义CFGTAVERSION后,系统会禁止TA版本降级。即使攻击者拿到了旧版本有漏洞的TA,也无法在新版本设备上运行。
丰富的安全算法能力
对应合规价值: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安全能力 |
对应标准条款 |
|
安全设计 / Secure by Design |
OTP硬件根信任 + 硬件加密引擎 |
CRA Annex I Part A |
|
软件完整性保护 |
FIT安全启动 + dm-verity校验 |
CRA Annex I 1.1 |
|
访问控制与鉴权 |
TrustZone / OP-TEE硬件隔离 |
CRA Annex I 1.2 |
|
数据加密与保密 |
dm-crypt分区加密 + 硬件AES引擎 |
CRA Annex I 1.3 |
|
安全更新机制 |
CMS签名安全OTA + TA防回滚 |
CRA Annex I Part B |
|
密钥安全管理 |
KeyBox + RPMB + 只写不读密钥区 |
CRA Annex I 1.3 |
|
漏洞管理与响应 |
米尔长期SDK维护 + 安全更新支持 |
CRA Annex I Part B |
出海欧盟,从选对平台开始
选择MYC-LR3576核心板,意味着你获得的不只是硬件,更是一套经过验证的安全方案底座。它能帮助你的产品在CRA合规和IEC 62443认证的道路上,大幅减少底层安全研发投入,缩短合规准备周期,把更多精力聚焦在应用层业务功能上。
米尔电子:开箱即用的安全方案交付
安全功能的实现涉及硬件、Bootloader、内核、TEE、文件系统等多个层面,开发门槛高、调试周期长。选择MYC-LR3576核心板,意味着你获得的不仅是一块硬件,更是一套已经验证、可以直接落地的完整安全方案。
安全相关交付物
|
交付类别 |
具体内容 |
|
硬件平台 |
MYC-LR3576核心板,基于RK3576,板载eMMC,全硬件安全引擎支持 |
|
SDK |
Linux SDK(Buildroot/Yocto),安全功能以补丁形式提供,已验证可用 |
|
安全启动 |
FIT签名工具链 + 配置脚本,一键生成签名固件 |
|
OP-TEE |
OP-TEE OS + KeyBox TA + 测试工具,完整CA/TA示例 |
|
系统安全 |
dm-verity / dm-crypt配置,配置项已就绪,按需开关 |
|
安全OTA |
CMS签名工具 + update Engine,支持网络/本地升级 |
|
技术文档 |
《安全功能应用笔记》等完整文档,从原理到实操 |
|
技术支持 |
原厂工程师技术支持,协助安全方案落地 |
适用场景
PLC、工业网关、边缘计算终端,满足IEC 62443与CRA合规要求
车载中控、T-Box,满足车规级安全与防降级要求
POS机、自助终端,保护密钥和交易数据
智能NVR、门禁设备,防止设备被攻破
诊疗设备、医疗网关,保护患者数据隐私
5G/工业网关、边缘节点,保护通信密钥