智能硬件满足 CRA“默认安全的 8 项硬件工程整改

为消除硬件层面的违规隐患，研发团队必须对现有的电路原理设计、PCB 布局布线、芯片一次性可编程区域（OTP/eFuse）配置策略、引导加载程序以及产线烧录工序实施全流程整改。1. 物理调试接口硬件级熔断与受控认证调试（Debug Port Lockdown & ADAC）在研发与小批量试制阶段，硬件工程师习惯在 PCB 表层放置标准的 2.54mm 或 1.27mm JTAG/SWD 间距排针，或在丝印层清晰标示 TX、RX、SWDIO、SWCLK 等测试焊盘。此类物理暴露使得任何接触到硬件的攻击者均能使用廉价的硬件工具重获系统的完全控制权。合规整改要求在 PCB 物理设计与半导体熔断两个层面实施闭环锁定。在 PCB 设计上，量产布线必须彻底去除所有专用的调试接插件，严禁在阻焊层打印任何指示调试信号的字符。调试走线应布置在 PCB 内层，仅在夹具治具所需的触点处保留无丝印的微型测试焊盘（Pogo Pin Pad），并在主板总装完成后通过点胶或共形覆层工艺进行物理覆盖。在硅片控制层面，生产工序必须通过高压烧写微控制器或主控 SoC 的专用 OTP/eFuse 寄存器，永久切断调试接口的物理使能通路（例如将 STM32 的读保护级别提升至 RDP Level 2，或烧断 NXP i.MX 系列的 JTAG SMODE 熔丝位）。针对高端网关、边缘服务器等需要在售后提供深度分析能力的复杂设备，工程实现应引入基于公钥密码学的受控调试机制，例如遵循 Arm CoreSight 认证调试访问控制（Authenticated Debug Access Control, ADAC）标准。在 ADAC 机制下，SoC 的调试外设在默认状态下处于硬件锁死状态。当售后团队尝试建立调试会话时，片上安全系统会生成高熵伪随机数挑战（Nonce），工程师必须使用受 HSM 保护的企业私钥签发带有设备唯一序列号与权限范围的调试证书，片内安全固件在离线验签通过后，才会在硬件层有限度地开启指定的非侵入式跟踪域，彻底杜绝了未经认证的后门访问。2. 硬件信任根（Hardware RoT）与公钥哈希 eFuse 固化传统未设防的嵌入式设计中，处理器的片上启动 ROM（BootROM）在上电复位后，直接从外挂的 SPI Flash、eMMC 或 SD 卡中拉取初始引导加载程序（SPL/FSBL）并在片内 SRAM 中无条件执行。攻击者通过芯片夹具重写外部存储颗粒中的固件，即可轻易完成代码注入。合规整改的核心是构建牢不可破的硬件信任根（Hardware Root of Trust, RoT）。芯片厂商出厂时掩膜在处理器内部的 BootROM 构成了信任链的起始不可变代码。研发团队在企业内部的高安全环境中生成非对称签名密钥对（如 RSA-3072/4096 或 ECC Ed25519/ECDSA P-256）。随后，计算 OEM 根公钥（或公钥证书链根项）的密码学摘要（SHA-256 或 SHA-512）。在工厂产线制造环节，通过专用烧写机台将该公钥摘要永久烧入 SoC 的安全 OTP/eFuse 阵列中（如 NXP 的 SRK Hash 熔丝区或 TI 的 MPK 区域）。最后，必须触发不可逆的“安全引导强制标志位”熔断操作（如闭合 High Assurance Boot / AHAB 标志位）。此后，BootROM 在每次冷热启动时，均被强制执行硬件逻辑：首先比对外部固件携带的根公钥哈希与内部 eFuse 存储的值是否绝对一致，再使用该公钥对引导程序签名的完整性进行密码学验签。一旦出现任何哈希不匹配或签名失效，处理器将立即终止引导，从底层消除了恶意替换代码的可能性。3. 全链路安全启动链与“先验后解”防解析注入部分设备虽然实现了 BootROM 对第一级 Bootloader 的验签，但后续的二级引导程序（如 U-Boot Proper）、Linux 内核、设备树（Device Tree Blob, DTB）以及根文件系统却未经过任何加密校验，信任链在此发生断裂。更为严重的工程隐患在于“先解析、后验证（Parse Before Verify）”的架构缺陷：系统在对固件容器签名进行数学计算前，先行调用了动态解析库读取容器头结构，导致解析器内部的缓冲区溢出漏洞（如历史上 U-Boot FIT 镜像解析中出现的内存破坏缺陷）被攻击者利用，反向绕过签名检验。工程整改必须建立覆盖启动全程的链式信任传递（Chain of Trust），具体流向如下：$$\text{BootROM} \longrightarrow \text{TF-A (BL2)} \longrightarrow \text{BL31/OP-TEE} \longrightarrow \text{U-Boot (BL33)} \longrightarrow \text{Linux FIT (Kernel+DTB+Initramfs)} \longrightarrow \text{dm-verity RootFS}$$各级镜像必须由前序受信任的组件执行强制签名校验。对于 RTOS 设备，则由轻量级的引导加载程序（如 MCUboot）负责在上电时逐级验证主应用分区镜像。在镜像容器格式的实现上，必须彻底重构验证逻辑，践行“先验后解”原则：固件包的数字签名必须覆盖包含全部元数据在内的连续原始二进制内存块。系统必须首先将整个待校验镜像读入经过受保护的物理内存（如安全 SRAM 或 TrustZone 预留内存），完整核验数字签名，确认数据完全未被篡改后，方可将数据指针传递给设备树或容器解析引擎。此外，启动失败策略必须配置为严格的“失效安全（Fail-Secure）”状态。任何一阶段校验失败，固件严禁退回至未受控的命令行调试环境（如 U-Boot Shell 或 BusyBox），必须强制触发硬件看门狗复位或直接切入经过强身份认证的安全恢复模式。4. 硬件级防版本回退机制（Anti-Rollback Protection）与单调计数器智能硬件即使部署了完善的安全签名机制，仍面临严重的固件版本降级攻击（Rollback Attack）。攻击者能够合法获取厂商早期发布但包含已知安全漏洞（如旧版 OpenSSL 远程执行漏洞）的历史固件，将其完整刷入设备的存储介质中。由于该历史固件携带厂商的合法数字签名，普通的安全启动流程会判定其合法并正常执行，使设备重新暴露在历史漏洞之中。为满足 CRA Annex I Part I (c) 针对已知漏洞修复与安全更新机制的规定，必须在硬件层面引入单调递增计数器（Monotonic Counter）。在固件编译与代码签名阶段，工程配置必须在固件的受保护头部嵌入不可篡改的安全版本号（Security Version Number, SVN）。在硬件底层，利用 SoC 内部专门划分的 Anti-Rollback eFuse 单调阵列，或外部独立安全芯片内部由硬件密码学引擎保护的只增计数器，保存当前设备所允许运行的最低版本基准。在系统引导时，引导程序提取固件头部声明的 SVN，并将其与硬件计数器数值进行强制逻辑比对：$$\text{SVN}_{\text{Firmware}} \ge \text{Counter}_{\text{Hardware}}$$若检测到新固件的 SVN 小于硬件记录的当前值，引导程序将判定该操作为恶意降级并拒绝执行。当系统成功完成更高安全版本固件的 OTA 升级并确认正常稳定运行后，系统特权固件将触发单向硬件操作，将 eFuse 单调阵列或安全单元内部的计数值永久提升至新的 SVN，使降级通道在物理上被不可逆地切断。5. 双区双备份安全 OTA 与原子化回滚保护传统的空中下载软件升级（OTA）通常采用原位单分区覆盖擦写机制。若在下载写入或固件校验过程中遭遇异常断电，设备极易损坏致瘫（“变砖”）；部分系统虽然保留了恢复机制，但在主固件失效后会盲目降级回退到未加固、包含出厂已知漏洞的救援镜像中，直接违背了 CRA 关于“故障后恢复至安全状态”的准则。高可靠的合规架构要求采用对等的 A/B 双分区存储布局（Symmetric A/B Partitioning）。新版本的固件数据只能被下载至当前非激活的闲置分区（Staging Slot），且升级包本身必须在传输层之上实施端到端的独立非对称签名校验（基于 ECDSA 或 Ed25519）。在引导逻辑中引入基于状态机的原子化切换机制。当升级固件校验完毕并写入非激活分区后，Bootloader 将下一次启动的候选分区标记指针翻转至该分区。新系统首次引导时，内核启动脚本必须强制启动硬件看门狗定时器；只有当全部核心网络服务与关键业务安全初始化完毕，应用层看门狗守护进程向底层寄存器写入“健康确认（Commit）”信号后，该分区才会被永久标记为活动分区。若在尝试启动过程中系统发生死锁崩溃、内核 Panic 或未能按时完成健康上报，硬件看门狗将触发系统冷复位，Bootloader 会在下一次启动时自动回退至先前已知正常工作的备用分区，确保设备在升级异常时不会丢失可用性，亦不会降级至未受控状态。6. 敏感资产硬件隔离：独立安全单元（SE）与片上安全引擎在大量低成本硬件方案中，设备的 TLS 客户端私钥、设备专属认证证书、云端连接凭据以及本地数据加解密主密钥被以明文字符串的形式保存在常规的外部 SPI NOR/NAND Flash 文件系统中。攻击者利用热风枪将 Flash 芯片吹焊脱落，或直接在总线上挂载逻辑分析仪，即可轻易批量提取设备核心密钥，甚至伪造大量虚假硬件接入企业云端平台。CRA Annex I Part I (e) 强制要求对敏感资产实施高强度的机密性与完整性保护。在具备足够 BOM 预算的系统架构中，应外挂经过安全认证的硬件安全单元（Secure Element, SE，如符合 CC EAL6+ 或 Common Criteria 认证的 NXP EdgeLock SE050、Microchip ATECC608 系列或独立 TPM 2.0 芯片）。系统必须践行“密钥不出芯（Keys Never Leave the Chip）”的设计铁律：设备私钥必须由安全单元内部的硬件真随机数发生器（TRNG）在芯片内部原位生成，任何物理或逻辑接口均无法读取私钥明文。所有 TLS 握手签名、数字证书协商与数据完整性校验，均通过安全的加密传输总线（如遵循 GlobalPlatform SCP03 安全通道协议的 I2C/SPI 总线）以协处理器指令的形式分发给 SE 内部的密码加速引擎执行。对于高度集成、未配置外置安全芯片的 SoC 平台，工程方案必须依托芯片内部的硬件唯一密钥（Hardware Unique Key, HUK，如 Arm CryptoCell 或 NXP CAAM 引擎）。HUK 在晶圆制造过程中直接烧入硅片内部，对外设寄存器与软件执行栈完全不可见。系统利用硬件密钥派生函数（HKDF），结合设备状态由硬件引擎在底层派生出磁盘加密（dm-crypt / LUKS）所需的临时会话密钥，确保即使外部 Flash 存储介质被脱焊逆向，提取出的镜像数据依然是不可破解的密文。7. 彻底废除通用默认凭证与设备唯一化出厂绑定为规避产线配置的复杂性，部分制造商在出厂固件的 /etc/shadow 或本地 Web 管理后端中预设通用的弱口令（如 admin/admin、root/password），寄希望于用户在阅读说明书后自行修改。在 CRA 的审查模型中，此类设计属于典型的结构性违规，直接判定为重大不合格项。工程整改要求在自动化构建流水线与生产烧录工站实施全方位的凭证治理。在固件源码与镜像打包脚本中，必须建立静态扫描检查规则，严禁包含任何硬编码凭据与静态私钥。在生产制造工段，必须建立针对每一台设备的单机唯一凭证（Per-Device Unique Credentials）分发机制。产线测试治具调用高安全性的真随机数发生源，为每一台设备独立生成高强度的出厂随机口令或一次性配网激活码（Token）。该凭据由安全烧录治具通过安全通道写入设备的受保护存储区，并同步传输至激光打标机，以明文或防伪二维码的形式直接蚀刻在产品物理铭牌或密封包装内的专属配置卡上。在固件启动逻辑中，新设备开机后必须默认处于“锁定未初始化”状态；初次访问管理接口时，固件强制拦截所有业务请求，校验物理铭牌上的唯一出厂口令，并强制用户立即建立符合现代密码学强度要求（包含长度、复杂度及暴力破解防御）的专属新凭据，完成配置前严禁开放任何特权操作端口。8. 最小化网络端口暴露与板级通信总线收敛大量量产固件在发布前未能完成环境收敛，开发环境中用于调试的后台守护进程（如 ADB over Wi-Fi、Telnet 服务、未经验证的轻量级 HTTP 监控服务器以及 UPnP 自动端口映射）在量产版本中依然处于自启动状态，为远程入侵提供了天然的渗透通道。同时，板上不同元器件之间的 I2C、SPI、UART、CAN 总线未设防，总线上的报文处于明文广播状态。依据 CRA 关于最小化暴露面与数据保护的规范，量产固件构建流程必须建立强制性的端口与协议裁决清单。所有调试专用的守护进程（Daemon）必须通过构建系统（如 Yocto 配方或 Buildroot 配置）从最终的生产镜像中剥除。设备的系统防火墙（如 Linux 的 nftables/iptables 或 RTOS 内部的网络过滤模块）必须确立严格的“默认丢弃（Default DROP）”策略，只允许业务逻辑绝对依赖的端口对外提供服务（如采用 TLS 加密的 MQTT 8883 端口或 HTTPS 443 端口）。所有明文传输协议（如 Telnet、TFTP、未加密 HTTP）必须被全面禁用。在板级硬件层面，连接核心传感器、执行器与微控制器的外设总线，在走线阶段应置于 PCB 中间层并辅以接地屏蔽层保护，增加物理探针搭接的攻破难度。对于承载关键业务逻辑与车控指令的总线（如 CAN 总线或跨板通信的 I2C/SPI 总线），通信协议栈必须引入基于密码学的消息认证码机制（如 AUTOSAR 规范中的 SecOC 机制），通过预共享密钥与新鲜度计数器（Freshness Counter）对传输的数据包添加报文签名（CMAC），杜绝物理挂接总线嗅探工具实施的虚假遥测与重放注入攻击。