CANN SiP 安全推理保护机制概念拆解：深入理解可信执行环境中模型加密与密钥管理体系设计原理全析

xiaoqi922

19人浏览 · 2026-06-18 23:34:01

xiaoqi922 · 2026-06-18 23:34:01 发布

前言

大模型时代，训练一个商业级模型的算力成本已经高达数百万美元。当模型所有者把推理服务部署到边缘服务器或者租用的云端算力节点时（昇腾NPU的推理场景），一个让人不安的问题浮出水面：模型权重本身是加密的，可一旦推理请求进来、系统需要把模型加载到内存中执行，那个内存里的模型就是明文了。任何掌握了服务器root权限的人，都可以通过内存读取工具把整套模型权重捞出来。这不是理论风险，是真实发生过的case。医疗影像模型、金融风控模型、核心推荐系统——这些模型一旦被竞争对手复制，商业护城河瞬间瓦解。

所以推理阶段的安全保护，绝不是锦上添花，而是生产部署的必备条件。昇腾NPU作为核心计算硬件，CANN作为其上层的昇腾异构计算架构，自然不会在这个问题上缺席。在昇腾NPU的软件栈里，推理安全涉及多个层次的协同：硬件提供的可信根、驱动层的内存隔离、上层框架的模型加密，以及远程证明机制对推理环境的完整性校验。这些能力组合在一起，形成了一套被称作SiP的安全推理保护体系。这个名字里的SiP对应的英文是Secure Inference Protection，而非信号处理——两者在CANF仓库里共享同一个名字，但技术内涵完全不同，文中讨论的是前者。

理解这套机制的关键，在于把它拆解成几个相互咬合的齿轮：模型加密解决"模型躺在磁盘上时怎么防"，密钥管理解决"谁有资格解开模型"，安全执行解决"模型在内存里跑的时候怎么防被偷"，远程证明解决"我怎么相信这整个环境真的安全而不是被伪造的"。把这四个问题搞清楚，你对SiP的理解就建立起来了。

一、SiP解决的核心问题：模型IP保护的需求场景与TEE基础

1.1 模型IP保护的现实压力

AI模型的知识产权保护长期处于一个尴尬的位置。训练阶段的安全措施相对成熟，数据加密、访问控制、审计日志这些手段在云服务商的训练集群里已经成为标准配置。但推理阶段的安全防护一直被忽视，部分原因是推理过程对实时性要求极高，安全检查一旦增加延迟用户体验就会下降；另一部分原因是很多人存在一个误解——模型权重只要在磁盘上加密就足够了，内存里的明文是"运行时的必要之恶"。

这种想法的危险在于它把安全边界设得太窄。磁盘上的加密模型当然安全，传输过程中的加密模型也安全，但一旦模型被加载到NPU的内存执行，它就处于一种"明文可见但物理不可控"的状态。攻击面包括：操作系统内核的内存读取权限、虚拟化hypervisor的内存映射能力、PCIe总线的 DMA 访问，甚至通过冷启动攻击（cold boot attack）从断电后的内存残留中提取数据。在多租户云环境里，这个问题更加突出——你租用的那个虚机跟其他租户的虚机共处同一台物理机，尽管hypervisor做了隔离，但硬件层面的攻击仍然有机可乘。

SiP要解决的正是这个问题：让模型在整个推理生命周期中都保持加密状态，即使攻击者拿到了运行时的内存快照，也无法拼凑出可用的模型权重。

1.2 可信执行环境的基本原理

要理解SiP的设计思路，必须先搞清楚可信执行环境（Trusted Execution Environment，简称TEE）是什么。TEE并不是一个软件概念，而是一套硬件+软件协同的安全架构。其核心思想是：在同一颗SoC上划分出两个区域——一个是普通世界（Rich Execution Environment，REE），运行常规的操作系统和应用；另一个是安全世界（Secure World），运行经过签名验证的Trusted OS和受信任的应用。两套环境通过硬件隔离来保证安全世界的代码和数据不会被普通世界的软件访问到。

具体到昇腾NPU上，达芬奇架构的片上系统内置了安全隔离机制。安全世界的内存区域被硬件MMU标记为"仅安全访问"，普通世界的操作系统即使有root权限也看不到这片内存。当一段代码被加载到安全世界执行时，硬件会验证这段代码的签名——只有经过可信根签发的二进制才能进入安全世界。这就从物理层面堵住了通过软件漏洞提权来访问安全内存的可能。

安全世界的典型用途包括：密钥存储、数字版权管理（DRM）、安全支付，以及——这里就是SiP要利用的地方——模型推理。模型权重在安全世界里解密后，直接在隔离内存中参与计算，计算结果输出到普通世界可见的缓冲区，而权重本身永远不会出现在普通世界可见的内存范围内。

1.3 为什么推理也需要安全护栏

一个自然的疑问是：训练那么贵都熬过来了，推理阶段还需要专门加一套安全机制，是不是过度设计了？这个问题需要从商业和技术两个维度来回答。

从商业角度看，模型的商业价值往往在推理阶段才最大化释放。一家公司的核心竞争力可能体现在特定的模型架构设计、超参数调优策略、或者是大量清洗和标注后的训练数据集，这些信息被编码在模型权重里。一旦模型被竞争对手通过内存读取获取，即使对方不能直接逆向出完整的训练数据集，也能通过模型蒸馏（knowledge distillation）快速复制出一个近似能力的副本，整个研发投入就在一夜之间打了水漂。

从技术角度看，推理阶段的攻击比训练阶段更容易实施。训练集群通常部署在企业自建的高安全等级数据中心，有完整的物理安全和网络安全防护。而推理服务可能部署在客户现场的边缘设备上，或者是按需租用的公有云实例，这些环境的物理安全和访问控制都无法与训练环境相比。攻击者只需要拿到一个有效的root shell，不需要穿透多层防火墙和零信任网络，在某些场景下甚至可以通过物理接触设备完成攻击。

所以推理安全不是过度设计，而是模型部署链条中最薄弱的一环必须被加固。SiP通过把模型加密、密钥管理和安全执行三者绑定在一起，让模型在推理全流程中始终处于加密保护之下，即使在不可信的运行环境中部署也不用担心模型资产泄露。

二、模型加密流程：从训练产物到加密存储的全链路

2.1 加密前的模型形态

讨论模型加密之前，先看看训练完成的模型长什么样。在昇腾NPU的生态里，训练产物通常以OM（Offline Model）格式存储，这是经过昇腾图编译器（Graph Compiler）优化后的离线模型文件。OM文件包含了计算图结构、算子调度信息，以及权重数据的二进制块。一个中等规模的Transformer模型，OM文件大小通常在数百MB到数GB之间。

在加密之前，这套文件集是明文存储的。OM文件可以被昇腾的推理引擎直接加载并执行——这个过程涉及把权重数据从存储介质读入NPU的片上SRAM或外部DRAM，接下来由计算单元执行矩阵乘、激活等算子操作。在这个阶段，如果攻击者能够访问到存储介质（磁盘镜像、NFS挂载卷），或者能够读取到运行时的内存页，就能直接获取模型权重。

加密流程的设计目标是把"权重数据"这层拿走，让存储介质上只有密文，只有在TEE内部、经过密钥验证之后，才能把密文还原成可执行的权重。

2.2 加密算法的选择：对称加密的实战考量

模型加密使用的是对称加密算法，原因很直接：对称加密的加解密速度远快于非对称加密，而模型推理的特点是高吞吐、低延迟，加解密操作必须足够快才不会成为瓶颈。

CANN生态中常见的两套加密方案分别对应不同的场景需求。一套是基于AES-GCM的方案，AES是业界最广泛使用的分组密码，GCM是Galois/Counter Mode，提供了加密和认证双重保护——不仅让攻击者看不懂密文，还能检测出密文是否被篡改过。AES-256-GCM在昇腾NPU的硬件密码学单元中有专门加速，实测加解密吞吐可以贴近硬件内存带宽的理论上限。

另一套方案是基于国密SM4的加密。SM4是我国自主设计的分组密码标准，跟AES一样是128位分组、128位密钥，在安全强度上与AES-128持平。对于需要在国产化环境中部署的场景，使用SM4是合规要求而非可选项。昇腾NPU的硬件密码学单元同样对SM4提供了硬件加速支持，使得SM4加密模型的推理性能损耗控制在可接受范围内。

选择加密算法时有个关键权衡需要考虑：分组密码的工作模式。GCM模式因为提供了认证功能，所以每个加密块都会产生一个认证标签（authentication tag），这个标签占用额外的存储空间。对于权重数据量巨大的模型来说，所有块累积下来的标签体积是相当可观的。相比之下，ECB或CBC模式没有认证开销，但失去了篡改检测能力——攻击者可以修改密文的任意字节，解密出来的权重会变成垃圾数据，虽然不会泄露明文，但会导致推理结果出错或者程序崩溃，引入一种"拒绝服务"式攻击。实际部署中，大多数场景会优先选择GCM模式以获得认证保护，宁可多占用一点存储空间。

2.3 加密模型的文件结构

加密后的模型文件不再是单一的OM文件，而是一组文件的集合。这组文件包括加密后的权重数据、加密元数据、以及验证信息。

加密权重数据是主体部分，对应原始OM文件中的权重二进制块，按照加密算法和选定的工作模式逐块加密。每个密文块后面附加的认证标签（如果是GCM模式）通常与密文数据存储在一起，构成完整的加密存储单元。

加密元数据包含了帮助解密的信息：密钥标识符（Key ID，用于在密钥管理系统中查找对应的密钥材料）、加密算法标识、工作模式标识、IV（初始化向量）或者nonce值。元数据本身不需要加密，但需要防篡改——通常通过HMAC或者签名来保护元数据的完整性，确保攻击者无法通过修改元数据来诱导解密过程使用错误的密钥或参数。

验证信息用于完整性校验，通常是模型权重或者计算图结构的哈希值。推理引擎在成功解密并加载模型之后，会计算权重数据的实际哈希与预存的哈希进行比对，确认模型在传输或存储过程中没有被损坏。这个步骤非常重要，因为密文传输中的位翻转会导致解密结果全部出错，没有完整性校验的话很难定位是加密问题还是传输问题。

下面是一段示意性的模型加载流程代码，反映了加密模型从磁盘到NPU内存的路径：

# 模型加密工具的简化逻辑（示意）
import json

def encrypt_model_om(input_path, output_dir, key_id):
    # 读取原始OM文件的权重数据段
    om_data = open(input_path, "rb").read()
    header = om_data[:HEADER_SIZE]
    weights = om_data[HEADER_SIZE:]

    # 生成随机nonce（每个模型文件唯一）
    nonce = os.urandom(12)  # AES-GCM推荐12字节nonce

    # 使用模型密钥加密权重
    model_key = key_manager.derive_model_key(key_id)
    encrypted_weights, tag = aes_gcm_encrypt(model_key, nonce, weights)

    # 构造加密包：nonce + 密文 + 认证标签
    encrypted_package = nonce + encrypted_weights + tag

    # 写入元数据（Key ID用于解密时查找密钥）
    meta = {"key_id": key_id, "nonce": b64(nonce), "tag_len": len(tag)}
    with open(f"{output_dir}/meta.json", "w") as f:
        json.dump(meta, f)

    # 写入加密后的权重文件
    with open(f"{output_dir}/weights.enc", "wb") as f:
        f.write(encrypted_package)
    # 只加密权重，保留计算图结构（供图编译器解析算子拓扑）
    with open(f"{output_dir}/graph.struct", "wb") as f:
        f.write(header)

# 加密权重时每个文件使用不同的nonce，防止"密文模式泄露"攻击
# 如果多个文件的nonce相同且内容有相似性，攻击者可能通过比较密文推断出部分明文

Keeping nonce values unique per encrypted file prevents ciphertext pattern analysis attacks; when the same key encrypts similar content with identical nonces, attackers can exploit correlations between ciphertexts to recover partial plaintext. Using random per-file nonces ensures each encryption context is independent.

代码中用12字节的随机nonce是AES-GCM模式的推荐实践。nonce不需要保密，但必须全局唯一——同一个密钥对不同消息使用相同的nonce会破坏认证加密的安全性。具体到模型加密场景，每个模型的权重文件都应该生成独立的nonce，而不是复用同一个值。

三、密钥管理体系：从硬件根密钥到模型密钥的派生链路

3.1 硬件根密钥：整个安全体系的起点

密钥管理体系是一座金字塔，塔尖是硬件根密钥（Hardware Root Key，简称HRK），所有其他密钥都由它直接或间接派生出来。根密钥的生成和存储是整个系统最关键的设计决策。

根密钥的生成策略通常有两种。一种是利用物理不可克隆功能（Physically Unclonable Function，PUF）从芯片制造过程中引入的随机差异来生成密钥。每一颗芯片在制造时都会因为光刻工艺的微小波动产生独一无二的物理特征，PUF利用这些特征来生成唯一的密钥。这种方式的优点是密钥从来不离开硬件——不需要在工厂烧录密钥，也不用担心供应链泄露。缺点是PUF的输出有噪声，需要纠错电路来保证每次从同一颗芯片提取的密钥是一致的。

另一种策略是在芯片出厂前通过安全烧录方式写入根密钥。烧录过程在安全工厂环境中进行，密钥由硬件安全模块（HSM）生成后直接写入芯片的一次性可编程（OTP）存储区域。OTP存储的特点是一旦写入就无法修改、无法读取——软件层面没有任何接口可以导出根密钥，只有硬件层面的物理探针在极端条件下才有可能接触到。这是一种"化不可能为可能"的安全假设，即假设攻击者的能力边界不会延伸到芯片级别。

昇腾NPU根据不同产品线选择了不同的根密钥策略，有的型号使用PUF，有的型号使用OTP烧录，具体实现对上层软件透明。上层软件看到的只是一个不可读取、仅供加密引擎使用的根密钥句柄。

3.2 密钥派生：从根密钥到模型密钥

直接用根密钥加密所有模型是不现实的。根密钥只有一个，如果用它加密所有模型，一旦根密钥泄露，所有模型同时沦陷；如果用它解密所有模型，每次解密操作都需要访问根密钥，根密钥的使用频率过高会增加泄露风险，而且无法实现细粒度的权限管理。

所以实践中会采用两级派生结构。根密钥用来派生一组中间密钥（Intermediate Key），中间密钥再派生具体的模型密钥（Model Encryption Key，MEK）。这个派生过程使用的是密钥派生函数（Key Derivation Function，KDF），常见的选择包括HKDF（基于HMAC的KDF）和PBKDF2。

模型密钥派生链路

硬件根密钥(HRK)
     │
     ▼ KDF(HRK, "intermediate", version)
中间密钥(Intermediate Key)
     │
     ├──► KDF(中间密钥, "model-a", model_id) ──► 模型A的MEK
     ├──► KDF(中间密钥, "model-b", model_id) ──► 模型B的MEK
     └──► KDF(中间密钥, "model-c", model_id) ──► 模型C的MEK

Chain-style key derivation enables hierarchical revocation: if an intermediate key is compromised, only that derivation branch is invalidated while the hardware root key remains intact. This avoids the costly full re-encryption that would be required if the root key itself needed rotation.

这种链式派生的好处是层次化的撤销能力。如果某个中间密钥泄露，只需要让根密钥派生出新的中间密钥版本，所有由旧中间密钥派生的模型密钥自动失效。模型所有者不需要重新加密所有模型，只需要更新中间密钥的版本号，触发一次新的派生流程即可。相比之下，如果根密钥直接派生每个模型密钥，一旦根密钥轮转，所有模型都要重新加密，工作量巨大。

3.3 密钥的生命周期管理

密钥从生成到销毁有一条完整的生命周期曲线，不同阶段对应不同的安全要求和操作规范。

生成阶段在安全边界内完成。根密钥由硬件在芯片初始化时生成或从工厂烧录，中间密钥由密钥管理服务（KMS）在安全认证模块内派生，模型密钥由工具在加密模型时派生。所有密钥的生成过程都不应该在普通世界有日志输出或调试接口。

激活阶段指密钥被正式用于加解密操作。这个阶段通常对应模型所有者首次部署加密模型——模型密钥通过安全通道从KMS传递给TEE，并在TEE内部的安全密钥存储中注册。激活时间戳会被记录，用于后续的审计追溯。

使用阶段是密钥被反复调用的时期。模型密钥的使用频率取决于推理请求量，每个推理批次都可能触发一次模型权重的解密操作。这里需要特别注意：解密后的明文权重在TEE内存中停留的时间窗口要尽可能短，用完立即清零（zeroize），不给攻击者留下趁虚而入的机会。

轮转阶段是定期或按需更新密钥的操作。密钥轮转的原因包括：计划性轮转（每90天或180天更新一次密钥）、事件性轮转（检测到疑似泄露迹象后立即触发）、以及密钥版本升级（新芯片支持更强的派生算法）。轮转过程中，新旧密钥通常会有一段共存期，保证已经在传输中的加密模型可以继续解密，新加密的模型使用新密钥。

销毁阶段是密钥生命周期的终点。对于模型密钥，销毁只需要删除TEE内部的密钥句柄，物理存储介质上的密文不受影响。对于中间密钥和根密钥，销毁意味着对应的派生树全部失效，所有由它们加密的模型在逻辑上永久不可解密。这个阶段是单向的，没有后悔药。

四、安全推理执行：加密模型在TEE中的解密与执行

4.1 加密模型的加载流程

当一个推理请求到达部署了SiP的系统时，加密模型的加载过程比普通模型多出几个关键步骤。普通模型的加载是：读取OM文件 → 解析计算图 → 分配NPU内存 → 加载权重 → 执行推理。加密模型的加载则在权重加载环节插入了一个安全桥梁：

推理请求到达
     │
     ▼ 检查模型是否已在TEE中加载
模型未加载
     │
     ▼ 向KMS请求模型密钥句柄
     │  （请求携带Key ID + 推理上下文）
     ▼ KMS验证请求者身份（证书、平台状态）
     ▼ KMS在TEE内派生模型密钥
     ▼ 读取加密权重文件
     ▼ 在TEE内解密权重（硬件加速）
     ▼ 完整性校验（哈希比对）
     ▼ 将明文权重写入安全内存区域
     ▼ 销毁解密过程中的临时明文副本
     ▼ 加载计算图结构
     ▼ 进入推理执行阶段

Separating the encrypted weights from the plaintext graph structure allows the graph compiler to perform static optimizations before the model is even decrypted. Decrypting only the weights and leaving graph metadata in plaintext avoids forcing expensive graph parsing operations into the TEE, which would otherwise become a bottleneck.

这个流程中有个细节值得注意：计算图结构（graph.struct）通常不需要加密。计算图只描述了算子的拓扑关系和调度信息，不包含模型权重——就算攻击者拿到了计算图也不知道每层的权重参数是什么。保留计算图的明文存储有几个好处：图编译器可以在加载前做静态优化、算子融合可以提前规划、安全世界不需要承担复杂的图解析负载。把加密粒度聚焦在权重数据上，是性能和安全的合理折中。

4.2 内存隔离机制：安全世界的物理边界

模型权重解密后存在于TEE的安全内存中，这片内存对普通世界完全不可见。内存隔离的实现依赖硬件MMU（内存管理单元）的安全扩展。

在达芬奇架构的MMU中，每个内存页都有安全（Secure）和非安全（Non-Secure）两种标记。当一段代码运行在安全世界时，它发起的内存访问请求会带上安全标记，MMU只允许访问标记为安全（Secure）的物理页面。普通世界的操作系统和驱动即使持有这些物理页面的虚拟地址，也无法构造出有效的安全世界访问请求——硬件层面直接把请求拒绝了，软件层面不存在绕过路径。

这个机制保证了即使攻击者通过内核漏洞获得了任意地址读写的内核态代码执行能力，他也无法访问安全世界的内存。内核代码发出的内存访问请求一律带上非安全标记，安全MMU直接拒绝这类访问请求。这是从硬件层面堵死的攻击路径，软件安全补丁再多也无法弥补硬件隔离被穿透的风险——所以TEE的设计哲学是：把最关键的资产放在硬件隔离的安全世界里，而不是依赖软件层面的访问控制。

内存隔离还延伸到DMA（直接内存访问）通道。NPU在执行推理计算时，数据直接从主存通过DMA传输到计算单元，不需要CPU参与。普通世界的驱动无法配置带有安全标记的DMA通道，所以即使NPU在物理上读写了安全内存页，这个访问路径也只有安全世界的软件才能建立。

4.3 计算过程中的数据保护

模型在安全世界中执行推理时，输入数据（推理请求中的原始数据）和输出数据（推理结果）需要在普通世界和安全世界之间穿梭。输入数据来自客户端的推理请求，必然经过普通世界才能到达NPU；输出数据需要返回给客户端，同样要经过普通世界中转。

这个穿墙过程需要精心设计，不能让中间数据在普通世界可见。最常见的方案是使用安全通道（Secure Channel）：输入数据在普通世界加密传输，到达TEE后解密使用；输出数据在TEE内加密，发送到普通世界后再由客户端或服务端解密。整个加解密过程由TEE内部的会话密钥保护，而会话密钥通过前面提到的密钥派生链获得。

对于实时性要求极高的在线推理场景，安全通道的额外加解密开销会成为延迟瓶颈。一个常见的优化策略是：输入数据在普通世界直接写入NPU的安全DMA缓冲区（绕过CPU和普通世界内存），TEE内的推理代码直接从安全缓冲区读取输入，在安全内存内完成计算，再把结果写入另一个安全DMA缓冲区供普通世界读取。这种零拷贝（zero-copy）路径跳过了普通世界内存中转，减少了两次内存拷贝的延迟。代价是软件栈需要支持安全DMA缓冲区的分配和映射接口，开发复杂度更高。

// 简化的高安全推理调用流程（示意）
aclrtContext secure_ctx;
aclrtStream secure_stream;

// 申请安全内存缓冲区（普通世界无法访问）
void* secure_input = nullptr;
aclrtMallocSecure(&secure_input, input_size, ACL_MEM_MALLOC_HUGE_FIRST);
// 普通世界的malloc和free对此指针无效，硬件保证隔离

// 从加密权重构建推理句柄（发生在TEE初始化阶段）
SipHandle sip_handle;
SipLoadEncryptedModel(sip_handle, "model.enc", "meta.json");
// 模型在TEE内解密并常驻安全内存，无需每次推理重新解密

// 执行推理（数据全程不离开安全内存）
SipInfer(sip_handle, secure_input, secure_output);

aclrtFree(secure_input);  // 安全内存释放，原有数据被清零

Using dedicated secure memory allocation APIs instead of wrapping ordinary malloc creates an explicit hardware-enforced isolation boundary; the MMU, secure world hardware and DMA controller all cooperatively reject any attempt from the REE to access these pages, which cannot be achieved by simply tagging ordinary allocations.

代码里用安全内存分配的接口替代了普通内存分配接口。aclrtMallocSecure分配的内存页带有安全标记，从普通世界看这片内存的行为就像未映射的地址——读写都会触发硬件异常。这种设计让开发者不需要关心底层的MMU配置细节，只需要调用安全内存分配接口就能获得隔离保证。

五、远程证明机制：向验证方证明推理环境的可信性

5.1 远程证明要回答什么问题

模型所有者把加密模型部署到客户的边缘设备上之后，怎么才能相信这台设备真的在用TEE跑推理，而不是在伪造一个假的推理环境来骗取模型的使用权？设备上运行的可能是一个经过修改的操作系统，它假装把模型加载到了安全世界，但实际情况是把模型权重复制到了普通世界的内存里供外部读取。

远程证明（Remote Attestation）就是用来解决这个"信任传递"问题的。它让部署在远端的推理环境向模型所有者证明：我这台设备上的TEE是真实的、我加载的模型是加密的、我的推理代码是签名验证通过的。模型所有者在收到这些证明之后，才决定是否授权这台设备使用模型。

5.2 证明的载体：Quote与证书链

远程证明的核心证据是一个叫做Quote的结构。Quote由TEE内部的可信软件（TEE OS或Trusted Application）生成，包含以下关键信息：

第一，报告数据（Report Data）字段，包含了推理环境的特征信息。这部分数据由TEE直接写入，外界无法伪造。报告数据通常包含：模型哈希（加载的加密模型的哈希值，确保推理使用的是正确的模型）、运行时状态标识（安全世界软件版本号、安全启动状态的快照）、以及自定义数据字段（模型所有者可以在这个字段里放一个nonce，由验证方在发起证明请求时提供，用于防止重放攻击）。

第二，测量信息（Measurement）字段，记录了安全世界软件的度量值。类似于可信计算的启动度量（PCR），每次安全世界的代码加载都会追加度量值，形成一条只增不减的度量链。如果攻击者试图替换安全世界的二进制文件，度量值就会改变，验证方能立即发现。

第三，签名部分，由TEE内部的签名引擎使用硬件根密钥对报告数据和测量信息进行签名。这个签名无法被伪造——因为签名操作发生在TEE内部，签名私钥从来没有出现在普通世界的内存中。

生成Quote的设备需要向验证方证明Quote的签名来自真实的TEE。验证流程依赖证书链。TEE的制造商持有根证书（Root CA），根证书签发平台证书（Platform Certificate），平台证书签发TEE证书（TEE Certificate），TEE证书签发Quote。这种层层签发、层层验证的结构叫做信任链（Chain of Trust）。验证方从自己信任的根证书出发，逐级向下验证：根证书验平台证书的签名、平台证书验TEE证书的签名、TEE证书验Quote的签名。任何一层验证失败，整个证明链条就断了，验证方拒绝信任这台设备。

5.3 证书链验证的完整流程

远程证明的完整交互分为三个阶段：挑战阶段、证明阶段、验证阶段。

挑战阶段由验证方（模型所有者）发起。验证方在这一步生成一个随机nonce——一个用完即弃的随机数。把这个nonce放进远程证明请求里发给部署了加密模型的那台设备。nonce的作用是防止重放攻击：如果没有nonce，攻击者可以截获之前合法的Quote并重复使用；有了nonce，每次证明请求的nonce不同，旧的Quote无法通过验证。

证明阶段由设备上的TEE处理。TEE收到包含nonce的证明请求后，把nonce嵌入报告数据字段，接下来生成Quote。Quote的内容包括：嵌入nonce的报告数据、安全世界的度量值、以及由TEE硬件根密钥签发的签名。这个Quote被发送给验证方。注意：在整个证明阶段，普通世界的操作系统和应用程序无法参与——Quote的生成和签名发生在TEE内部，普通世界只是一个数据搬运工，负责把Quote从TEE传递给网络对端。

验证阶段在验证方一侧完成。验证方收到Quote后，执行完整的证书链验证：从Quote中提取签名公钥，从公钥追溯到TEE证书，从TEE证书追溯到平台证书，再追溯到根证书。每一级验证都检查签名是否正确、证书是否过期、证书是否被撤销（CRL检查）。证书链验证通过之后，验证方从报告数据中提取之前发出去的nonce，确认其与原始nonce匹配。nonce匹配则证明Quote是新鲜的、不是重放的。紧接着，验证方从报告数据中提取模型哈希，与预期值比对，确认设备上运行的确实是指定的加密模型。

整个流程中任何一个环节出错都会导致验证失败：证书链断了、签名不对、nonce不匹配、模型哈希对不上——验证方都会判定这台设备不可信，拒绝授权使用加密模型。

六、性能与安全的平衡：加密推理的性能开销评估

6.1 加密推理的性能损耗来自哪里

安全推理的核心代价是性能。天下没有免费的午餐——加密模型在TEE中解密、多出来的内存拷贝、认证标签的校验、远程证明的交互，这些操作都需要消耗计算资源和时间。理解这些开销来自哪里，才能有针对性地做优化。

解密开销是第一层代价。AES-GCM和SM4的硬件加速单元在昇腾NPU上已经很快，但解密大模型的数GB权重仍然需要可观的时间。具体开销取决于模型规模和解密策略。如果采用"首次推理前全量解密驻留"策略（一次性解密整个模型，之后一直在安全内存中使用），解密时间就是启动延迟的一部分，通常在数秒到数十秒之间，在离线推理场景里可以接受。如果采用"每次推理前按需解密"策略（只解密当前批次需要的权重分片），解密开销分摊到每个推理请求上，但实现复杂度更高。

认证校验开销来自GCM模式中每个密文块后面附加的认证标签。在解密过程中，硬件不仅要把密文还原成明文，还要重新计算认证标签并与存储的标签比对。如果密文有任何字节被篡改，解密会失败并抛出认证错误。这部分校验由硬件密码学单元并行完成，开销通常不到解密本身的十分之一，但对于极致低延迟场景来说仍然不可忽略。

内存隔离的开销体现在额外的内存分配和安全DMA通道的管理上。安全内存是有限的资源池，不能无限扩张。如果模型规模接近安全内存的上限，就需要频繁的换入换出，这会导致推理延迟急剧增加。一个实用的设计原则是：安全内存至少要容纳下一个完整的大权重层（Transformer中的大型矩阵乘层的权重），否则分片加载会把解密延迟叠加到每次算子执行上，体验很差。

远程证明的开销是"一次性"的——在建立会话时进行一次完整的Quote生成、传输和验证流程，之后的推理请求不再需要重复证明。Session建立的成本取决于证书链的长度和网络延迟，通常在百毫秒到秒级。对于长连接的高频推理场景，这个成本可以摊销到大量推理请求中，单次推理的平均证明开销可以忽略不计。对于每次请求都重新建立连接的短连接场景，远程证明的开销就变得非常显著。

6.2 效率对比：启用SiP前后的系统行为差异

加密推理对系统各维度的影响程度不一，有些方面几乎没有感知，有些方面则需要权衡。下面的对比表格从不同维度概括了启用SiP前后系统行为的典型差异：

维度	启用SiP前	启用SiP后	差异来源
模型存储安全	权重明文存储在磁盘，可直接读取	权重以密文形式存储，无密钥无法解读	全量对称加密（AES-GCM/SM4）保护
运行时权重暴露风险	模型加载后权重在普通内存中可见	权重解密后仅存在于安全隔离内存	TEE内存隔离，硬件MMU安全扩展
首次推理延迟	直接加载OM文件执行推理	需要解密模型、建立安全会话、执行远程证明	解密计算、会话建立、证书链验证
内存占用	普通DRAM全量可用	安全内存池受限，总可用推理内存减少	安全内存与普通内存物理隔离
多租户场景安全性	依赖虚拟化隔离，理论上有攻击面	硬件级别隔离，无法通过软件漏洞穿透	TEE安全世界vs普通世界的硬件边界
部署灵活性	明文模型可在任意设备运行	加密模型需要目标设备支持TEE和密钥服务	硬件安全能力依赖
远程验证能力	无远程验证机制，模型使用授权依赖网络层	可通过远程证明验证推理环境完整性	Quote生成、证书链验证流程

从上表可以清楚地看到，SiP的核心收益集中在安全维度——模型IP保护和运行时内存隔离都获得了质的提升。但代价主要体现在性能和部署灵活性上：首次推理延迟增加、安全内存受限、部署环境需要TEE支持。对于离线推理（批处理、非实时）、对安全性要求极高的商业场景（医疗、金融、核心算法），这些代价完全值得。对于追求极致低延迟的实时推理场景（在线广告、搜索排序），需要评估加密开销是否在可接受范围内，或者考虑混合方案。

6.3 哪些场景适合启用SiP

判断是否启用SiP，从根本上看是在问：模型资产的价值是否高到值得承受这些性能和部署约束？

适合启用的场景至少满足以下一个条件。模型本身是核心商业资产，投入了大量研发成本训练，泄露后直接导致竞争优势损失。部署环境不可控，可能在客户现场、多租户云、或物理安全级别不高的数据中心。合规要求，特定行业（金融、医疗、政府）的数据安全法规要求对AI模型实施加密保护。输出的推理结果需要防篡改，认证加密不仅保护隐私还保证了推理结果的完整性。

不太适合启用的场景也有明显的边界。模型规模极大，安全内存容纳不下完整的模型权重，导致需要频繁换入换出。推理延迟要求极低，每次推理在毫秒级，额外的解密延迟会突破服务等级协议（SLA）。部署环境没有TEE能力，老旧的NPU型号或者裁剪版的CANN软件栈可能不支持安全内存分配接口。

对于处于中间地带的场景，一个务实的做法是"分层安全"。将模型分成两部分：对安全最敏感的核心层（embedding表、关键attention层）启用加密和TEE执行，对延迟最敏感的普通层使用常规推理路径。核心层权重经过加密处理，推理过程中核心层计算结果以安全通道传输，普通层直接处理。这样在可接受的开销范围内给最关键的模型资产加上了保护。

结尾

SiP安全推理保护机制并不是一个单一的技术点，而是一套环环相扣的安全体系。模型加密把权重变成密文，让存储介质上的模型资产无法被直接读取；密钥管理提供了从硬件根密钥到模型密钥的层次化派生链，支撑了细粒度的权限控制和密钥轮转；TEE内的安全执行通过硬件MMU的隔离机制保证了解密后的权重永远不会出现在普通世界可访问的内存中；远程证明则在模型所有者和推理部署环境之间建立了一条可验证的信任通道。

仓库地址：https://atomgit.com/cann/sip