实时操作系统端侧智能的权限边界

封面信息图

RTOS 设备接入模型、向量库和本地检索后,除了固件本身,还要保护模型制品、数据索引、密钥和更新链路。外置存储、调试接口和启动过程都应纳入威胁建模。安全设计重点是把密钥与非安全任务分离、校验制品完整性,并让异常访问可被检测与恢复。

+-----------------------------------------------------------------------+
|                    ARM TrustZone-M 双域安全隔离架构                   |
+-----------------------------------------------------------------------+
                                    |
                                    v
+-----------------------------+          +-----------------------------+
|    Non-Secure World (NS)    |          |      Secure World (S)       |
|                             |          |                             |
|  * FreeRTOS Task Scheduling |  NSC Call|  * Hardware AES-256 Engine  |
|  * Vector RAG Search Engine | -------->|  * PUF Key Generator        |
|  * NN Model Inference Ops   |          |  * ECDSA Boot Verifier      |
+-----------------------------+          +-----------------------------+
               |                                        |
               v                                        v
+-----------------------------+          +-----------------------------+
|  Non-Secure SRAM (0x2000...) |          |   Secure SRAM (0x3000...)   |
+-----------------------------+          +-----------------------------+

1. 内存隔离防线:基于 ARM TrustZone-M 的安全域与非安全域拆分

ARMv8-M 架构(如 Cortex-M33/M55)引入了硬件级 TrustZone-M 机制,将芯片的物理内存、外设和执行上下文硬性划分为安全域(Secure World)与非安全域(Non-Secure World)。

很多团队习惯将 FreeRTOS、AI 推理引擎和密钥全放在同一个内存空间运行,这是一种极度危险的反模式。正确的架构设计必须遵循最小权限原则:

  • Non-Secure 域:运行 FreeRTOS 调度器、音视频采集驱动、神经网络算子计算库(如 CMSIS-NN)以及 RAG 上下文编排逻辑。
  • Secure 域:独占 HW Crypto 加密硬件、OTP/PUF 密钥生成器、Flash 签名校验算法,以及敏感向量特征库的解密句柄。

通过系统安全地址单元(SAU)和内存保护控制器(MPC),显式隔绝两域地址:

#include "ARMCM55.h"

// 在 Secure Boot 初始化阶段配置 SAU (Security Attribution Unit)
void Configure_SAU(void) {
    // 禁用 SAU 以进行安全配置
    SAU->CTRL = 0;

    // Region 0: 非安全代码 Flash 区域 (0x08040000 - 0x08100000)
    SAU->RNR  = 0;
    SAU->RBAR = (0x08040000C & SAU_RBAR_BADDR_Msk);
    SAU->RLAR = (0x08100000C & SAU_RLAR_LADDR_Msk) | SAU_RLAR_ENABLE_Msk; // NSC = 0

    // Region 1: 安全门非安全可调用区域 NSC (0x0803E000 - 0x0803FFFF)
    SAU->RNR  = 1;
    SAU->RBAR = (0x0803E000C & SAU_RBAR_BADDR_Msk);
    SAU->RLAR = (0x0803FFFFC & SAU_RLAR_LADDR_Msk) | SAU_RLAR_ENABLE_Msk | SAU_RLAR_NSC_Msk;

    // 启用 SAU 保护
    SAU->CTRL = SAU_CTRL_ENABLE_Msk | SAU_CTRL_ALLNS_Msk;
}

任何 Non-Secure 域中的 AI 推理任务想要解密数据,必须通过位于 NSC(Non-Secure Callable)区域的系统代理门(Secure Gateway, SG 指令)向 Secure 域发起请求,禁止直接访问密钥指针。

2. 密钥与模型保护:结合物理不可克隆功能 PUF 与硬件解密引擎

静态硬编码秘钥在逆向工程面前形同虚设。即使将秘钥存放在内部 Flash,使用 JTAG 调试器或侧信道攻击(SPA/DPA)也能将其轻易提取。

坚固的秘钥安全体系应当引入物理不可克隆功能(PUF - Physical Unclonable Function)。PUF 利用芯片硅片制造过程中产生的微观随机工艺差异生成独特的“DNA”指纹,该指纹在芯片断电后完全消失,不会静态保存在任何存储介质中。

嵌入式 Linux / RTOS 端侧设备在调试时,可以使用 OpenOCD 连接目标板查看芯片的安全锁定状态(ROP Level):

openocd -f interface/cmsis-dap.cfg -f target/stm32u5x.cfg -c "init; stm32u5x lock info; shutdown"

控制台输出会明确显示 Flash 读保护等级与 JTAG 锁死状态:

Info : stm32u5x.cpu: hardware has 8 breakpoints, 4 watchpoints
STM32U5 ROP Level: 2 (Option Bytes Locked, Debug Access Permanently Disabled)
Secure Boot Status: Enabled, TrustZone hardware enforces SRAM isolation.

在 C 语言代码层,位于 Secure 域的向量解密服务通过硬件 AES-GCM 模块动态解密内存片区,拒绝在 RAM 中留存解密后的完整明文模型:

#include <stdint.h>
#include "secure_crypto_hw.h"

// 声明为 NSC (Non-Secure Callable) 的安全入口函数
__attribute__((cmse_nonsecure_entry))
int32_t SECURE_Decrypt_Vector_Chunk(const uint8_t* cipher_text, 
                                     uint32_t length, 
                                     uint8_t* plain_out_ns_buffer) {
    // 校验 Non-Secure 传入的指针是否合法落在 NS SRAM 空间,防止利用 Secure 堆栈溢出攻击
    if (cmse_check_address_range((void*)plain_out_ns_buffer, length, CMSE_NONSECURE | CMSE_MPU_UNPRIV) == NULL) {
        return -1; // 非法地址越界尝试,拒绝执行
    }

    // 调用硬件 AES-256-GCM 引擎,使用 PUF 动态生成的 Session Key 进行片段解密
    int status = hw_aes_gcm_decrypt_with_puf_key(cipher_text, length, plain_out_ns_buffer);
    
    return (status == HW_SUCCESS) ? 0 : -2;
}

3. 供应链风险防线:防篡改 Secure Boot 与固件完整性校验

端侧 AI 系统的另一个巨大威胁来自于供应链篡改。如果攻击者替换了外部 SPI Flash 中的向量数据库镜像,往知识库里注入恶意的语音控制指令,设备在执行本地 RAG 时就会产生危险的操作指令。

防范此类攻击的关键在于建立从片上 ROM 到 AI 权重镜像的完整信任链(Chain of Trust):

  1. BootROM 固化:芯片出厂时在 Secure ROM 中固化根证书公钥 Hash(Root of Trust)。
  2. 安全启动 Stage 1:BootROM 校验 Secure Bootloader 的 ECDSA-P256 签名,通过后方可执行。
  3. 模型与知识库验签:Secure Bootloader 在装载外置 Flash 中的 AI 神经网络权重和向量表前,使用 RSA-4096 / ECDSA-256 算法校验镜像文件末尾的签名块。

只要签名校验失败,硬件系统立即断开外设电源并触发安全擦除(Zeroization):

// 伪代码:Secure Bootloader 校验 AI 镜像块完整性
int verify_ai_model_integrity(const uint8_t* model_flash_addr, uint32_t model_size, const uint8_t* signature) {
    uint8_t calculated_hash[32];

    // 硬件 SHA-256 引擎计算 Flash 中模型的 Hash
    hw_sha256_compute(model_flash_addr, model_size, calculated_hash);

    // 使用固化的 OTP 公钥验证签名
    int is_valid = hw_ecdsa_verify(OTP_PUBLIC_KEY, calculated_hash, signature);

    if (!is_valid) {
        // 发现被篡改,擦除 Secure SRAM 并复位
        memset((void*)SECURE_SRAM_BASE, 0, SECURE_SRAM_SIZE);
        NVIC_SystemReset();
    }

    return 0;
}

划清 RTOS 与端侧 AI 的安全边界,绝不是加个简单的密码锁,而是利用 TrustZone 硬件隔离、PUF 动态秘钥派生和完整签名链,在物理层和内存层同时筑起防御墙。

Logo

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐