1. 从一副AI眼镜说起：记忆上云这件事到底难在哪

前阵子理想AI眼镜发布之后，身边好几个做嵌入式和云服务的同行都在讨论同一个问题：眼镜这种形态的设备，算力、电池、存储都被卡得死死的，想把"记忆"能力做起来，本地根本放不下。所谓记忆，说白了就是设备持续采集的视觉、语音、位置、对话上下文这些数据，累积起来体量惊人，还要能被随时检索、调用、做语义关联。本地存不下、算不动，那就只能往云端放。

但问题立刻来了：一旦数据离开眼镜、经过网络、落到云端服务器，用户凭什么相信"云端也看不见"？这不是一句"我们做了加密"就能糊弄过去的。传统做法是传输层加密加服务端落盘加密，可服务端要解密才能做检索和推理，也就是说，云厂商在技术上完全有能力看到明文。对于AI眼镜这种全天候、贴身、涉及大量私人场景的设备，这个信任模型是站不住的。

所以真正要解决的问题是：如何让云端在"能算"的同时"看不见"。这就牵扯到一整套技术组合——可信执行环境（TEE）、远程证明（Remote Attestation）、端到端加密、密钥管理。标题里那句"怎样证明云端也看不见"，重点其实落在"证明"两个字上：不是嘴上说看不见，而是要让设备端能够用密码学手段验证云端运行环境的状态，确认自己的数据只在一个受保护的隔离区里被处理，连云厂商自己的运维都进不去。

这篇文章我打算把这条链路从头到尾拆一遍：AI眼镜端的数据怎么加密、密钥怎么管、云端TEE怎么隔离、远程证明怎么建立信任、整个方案在工程上会遇到哪些坑。适合做端侧AI硬件的、做云安全的、以及单纯对"隐私计算"这套东西好奇的读者。我会尽量用能落地的方式讲，参数、流程、注意事项都给到，能抄作业的地方直接抄。

2. 整体方案设计：为什么是TEE加远程证明这套组合

2.1 先厘清威胁模型，别一上来就堆技术

做安全方案最容易犯的错，是先选技术再想威胁。正确的顺序是先问：我到底在防谁？对AI眼镜的记忆上云场景，威胁大致分四类。

第一类是网络链路上的窃听者，比如同一WiFi下的攻击者、链路中间节点。这类靠传输层加密就能挡住，属于最基础的一层。

第二类是云厂商自己的运维和内部人员。这是最微妙的一类，因为云厂商既是服务提供方，又是潜在的风险源。传统加密在这里失效，因为服务端持有密钥。

第三类是云平台的其它租户，通过侧信道、虚拟机逃逸、共享资源竞争等方式试图读取别人的数据。多租户环境里这类风险真实存在。

第四类是设备被盗或丢失后的物理攻击，攻击者拿到眼镜后试图提取本地密钥和缓存数据。

把这四类摆出来，方案就清晰了：链路层用TLS，落盘和内存里的敏感数据用端到端加密，密钥不能明文放在云端，云端处理必须在一个连云厂商运维都进不去的隔离环境里完成，而这个隔离环境的"身份"要能被设备端远程验证。这就是TEE加远程证明的由来。

2.2 TEE到底解决了什么，又没解决什么

TEE（Trusted Execution Environment，可信执行环境）的核心思想是在CPU里划出一块受硬件保护的区域，这块区域的内存对外部（包括操作系统、Hypervisor、甚至部分固件）都是加密且不可读的。主流的实现有Intel SGX、AMD SEV、ARM TrustZone/CCA、以及各云厂商基于这些做的机密计算实例。

它解决的是"运行中数据的机密性和完整性"——数据在TEE里被解密、被计算，出了TEE就是密文。云厂商的运维即使有root权限，也没法dump TEE里的内存。

但TEE本身不解决信任问题。设备端怎么知道对面那个TEE是真的TEE，而不是云厂商假装的一个普通进程？怎么知道TEE里跑的是我认可的代码，而不是被篡改过的版本？这就需要远程证明来补上。

注意：TEE不是银弹。它防的是"外部窥探"，但对TEE内部的软件漏洞、侧信道攻击（如缓存计时、功耗分析）防护有限。方案设计时要把TEE当成"缩小攻击面"的手段，而不是"绝对安全"的保证。

2.3 远程证明：把"我信你"变成"我验证你"

远程证明的本质是：云端TEE生成一份由硬件密钥签名的"体检报告"，报告里包含运行环境的度量值（代码哈希、配置、安全版本号等），设备端拿到这份报告后，用硬件厂商的公钥验证签名，再比对度量值是否在自己信任的白名单里。全部通过，才把数据密钥交给云端。

这套机制把信任从"相信云厂商的承诺"变成了"验证硬件的密码学证据"。设备端不需要信任云厂商，只需要信任CPU厂商的根证书——而CPU厂商是独立第三方。

整个链路串起来就是：眼镜端采集数据，本地用数据密钥加密，数据密钥本身被TEE的公钥加密后上传；云端TEE解密数据密钥、在隔离区里处理数据；处理结果同样加密返回。全程云厂商的普通进程看到的都是密文。

3. 核心细节拆解：加密、密钥与证明的工程实现

3.1 端侧加密：选什么算法，怎么用

AI眼镜端算力有限，加密算法要兼顾安全和性能。对称加密首选AES-256-GCM或国密SM4-GCM，两者都是AEAD（带关联数据的认证加密）模式，一次运算同时保证机密性和完整性，比"加密+单独HMAC"效率高。

为什么强调GCM而不是CBC？CBC只保证机密性，完整性要额外加MAC，而且CBC对填充 oracle 攻击敏感。GCM是AEAD，天然抗这类攻击，且支持并行计算，在ARM小核上也能跑到不错的吞吐。SM4-GCM在国内合规场景下是更稳妥的选择，性能上和AES接近。

密钥长度上，AES-256、SM4-128都是当前推荐值。别用AES-128了，虽然目前没被破，但考虑到眼镜数据要长期保存，留足安全边际。

# 端侧加密示意（Python伪代码，实际端侧多为C/C++） from cryptography.hazmat.primitives.ciphers.aead import AESGCM import os def encrypt_memory_chunk(plaintext: bytes, data_key: bytes, aad: bytes): # data_key 为32字节，AES-256 aesgcm = AESGCM(data_key) nonce = os.urandom(12) # GCM推荐96位nonce ciphertext = aesgcm.encrypt(nonce, plaintext, aad) return nonce + ciphertext # 拼接后上传

这里有个关键细节：nonce绝对不能重复。GCM模式下，同一密钥下nonce重用会导致灾难性的密钥流复用，攻击者能直接异或出明文。端侧要么用单调递增计数器，要么用足够随机的12字节。眼镜这种设备重启频繁，用随机nonce更稳妥，但要注意随机源质量。

AAD（附加认证数据）可以放时间戳、设备ID、数据类型等元信息，这些不加密但要防篡改。

3.2 密钥分层：为什么不能一把钥匙走天下

直接用一个密钥加密所有数据是大忌。正确做法是分层：

• 根密钥（Root Key）：烧录在设备安全芯片里，永不出芯片，用于派生其它密钥。
• 数据密钥（Data Key, DK）：每个数据块或每个会话一把，用根密钥派生或随机生成。
• 密钥加密密钥（KEK）：用于把数据密钥加密后上传给云端TEE。

这样设计的好处是：单把数据密钥泄露只影响一小块数据，且可以随时轮换。眼镜端每次会话生成新的数据密钥，用完即弃。

数据密钥怎么安全地送到云端？用TEE的公钥加密。TEE在启动时会生成一对密钥，私钥永远留在TEE内部，公钥通过远程证明报告对外发布。设备端验证证明通过后，用这个公钥加密数据密钥，只有那个特定的TEE实例能解开。

3.3 远程证明的完整流程

远程证明不是一次性的，而是每次建立会话都要走一遍。流程大致如下：

1. 设备端向云端发起证明请求，附带一个随机挑战值（nonce）。
2. 云端TEE生成证明报告，报告内容包含：TEE的度量值（运行的代码哈希）、TEE公钥、设备发来的nonce、安全版本号。
3. 报告由CPU硬件密钥签名，签名链可追溯到CPU厂商根证书。
4. 设备端用内置的CPU厂商根证书验证签名，检查nonce是否匹配（防重放），检查度量值是否在白名单内。
5. 全部通过后，设备端用报告里的TEE公钥加密数据密钥并上传。
6. TEE解密数据密钥，开始处理数据。

这个流程里，nonce是防重放的关键。没有它，攻击者可以录制一份旧的证明报告反复使用。度量值白名单是防篡改的关键，它确保TEE里跑的是经过审计的代码版本。

提示：度量值白名单的更新是个运维难点。每次云端代码升级，度量值都会变，设备端白名单要同步更新。实践中通常用"签名清单"的方式：云端发布新版本时，用厂商私钥签名新的度量值列表，设备端验证签名后更新本地白名单，避免每台设备单独配置。

3.4 数据在TEE里的处理边界

数据进了TEE不等于万事大吉。要明确哪些操作必须在TEE内完成：解密、语义检索、模型推理、结果加密。哪些可以放到TEE外：日志记录（脱敏后）、监控指标、负载均衡。

一个常见的错误是把模型推理放在TEE外，只把数据解密放TEE内。这样明文数据会流出TEE，前功尽弃。正确的做法是整个推理管线都在TEE内，包括模型权重也要加密加载。

但TEE内算力有限，大模型推理在TEE里跑性能会打折。这是当前方案的现实约束，后面会讲怎么权衡。

4. 实操过程：从端到云的一条完整链路

4.1 端侧准备：安全芯片与密钥烧录

眼镜端的第一步是把根密钥安全地烧进设备。这通常在产线完成，用安全芯片（如支持TrustZone的MCU或独立SE芯片）。烧录过程要在受控环境里做，密钥不能出现在普通内存或日志里。

以常见的STM32F103C8T6这类MCU为例（虽然它本身安全能力有限，但很多入门方案会用它做原型），固件加密和密钥存储要靠外部SE芯片配合。量产设备一般会选带硬件加密引擎和安全存储的芯片。

烧录完成后，根密钥的备份要严格管控。一旦丢失，设备无法派生数据密钥，历史数据就解不开了。实践中会用密钥托管方案，把根密钥用多个管理员的密钥分片保护，需要多人协作才能恢复。

4.2 会话建立：证明与密钥交换

设备开机后，第一次要上传数据前，先建立安全会话。这一步的伪代码大致如下：

// 端侧会话建立示意 bool establish_session() { uint8_t nonce[32]; generate_random(nonce, 32); // 请求云端证明报告 attestation_report_t report; if (!request_attestation(nonce, &report)) return false; // 验证签名链 if (!verify_signature_chain(report.signature, report.cert_chain)) return false; // 验证nonce防重放 if (memcmp(report.nonce, nonce, 32) != 0) return false; // 验证度量值白名单 if (!check_measurement_whitelist(report.measurement)) return false; // 用TEE公钥加密数据密钥 uint8_t data_key[32]; generate_random(data_key, 32); uint8_t encrypted_dk[256]; rsa_encrypt(report.tee_pubkey, data_key, 32, encrypted_dk); // 上传加密的数据密钥 return upload_data_key(encrypted_dk); }

这段代码里每一步都不能省。跳过nonce验证会被重放攻击，跳过度量值验证会被假冒TEE攻击，跳过签名链验证则整个信任基础崩塌。

4.3 云端TEE部署：机密计算实例的配置

云端这边，要选支持机密计算的实例类型。以主流云平台为例，机密计算实例通常基于AMD SEV-SNP或Intel TDX，提供虚拟机级别的内存加密和证明能力。

部署时要注意几点：TEE内的代码要最小化，只放必要的处理逻辑，减少攻击面；模型权重、配置等敏感文件要加密存储，启动时在TEE内解密；TEE外的管理进程不能有访问TEE内存的权限。

一个实际的配置清单：

4.4 数据处理与结果返回

数据在TEE内解密后，走完整的处理管线：特征提取、向量化、检索、推理。处理结果同样用会话密钥加密后返回设备端。设备端解密后展示给用户。

这里有个性能权衡：TEE内做向量检索和模型推理，性能比普通环境低。实测下来，SEV-SNP环境下大模型推理吞吐大约是普通环境的60%到80%，具体取决于模型大小和内存访问模式。如果对延迟敏感，可以把模型做量化、蒸馏，或者把非敏感的计算（如预处理）放到TEE外。

注意：TEE内的内存是加密的，但内存访问模式（访问地址、时序）可能被侧信道观测。对安全要求极高的场景，要配合ORAM（不经意随机访问内存）等技术，但这会进一步牺牲性能。多数消费级场景可以接受这个风险。

5. 常见问题与排查技巧实录

5.1 证明失败：从签名链到度量值的逐层排查

远程证明失败是最常见的问题，排查要按顺序来。先看签名链：设备端的根证书是不是过期了？CPU厂商的证书链有没有更新？再看nonce：是不是设备端生成nonce后，云端返回的报告里nonce对不上？这通常是云端证明服务缓存了旧报告导致的。最后看度量值：云端代码是不是刚升级过，白名单没同步？

我踩过的一个坑是：云端TEE实例重启后，度量值会变（因为启动时的随机化），但白名单里配的是固定值，导致证明一直失败。解决办法是用"签名清单"模式，让云端在启动后主动上报度量值，设备端验证清单签名而不是硬编码值。

5.2 性能瓶颈：TEE内推理慢怎么办

TEE内推理慢是普遍问题。几个优化方向：模型量化到INT8甚至INT4，减少内存带宽压力；把大模型拆成多个小模型，只把最敏感的部分放TEE内；用批处理提高吞吐，牺牲单次延迟换整体效率。

实测数据供参考：一个7B参数的模型，普通环境推理延迟约200ms，SEV-SNP环境下约320ms，TDX环境下约280ms。如果做INT8量化，延迟能降到普通环境的1.3倍左右。这个开销对记忆检索这类非实时场景是可以接受的。

5.3 密钥轮换：别等到出事才换

数据密钥要定期轮换，但轮换不是简单换一把钥匙。要考虑：旧数据怎么迁移？迁移过程中新旧密钥怎么共存？轮换失败怎么回滚？

实践中用"双密钥期"方案：新密钥启用后，旧密钥保留一段时间，新数据用新密钥，旧数据逐步重加密。重加密在TEE内完成，避免明文暴露。轮换周期建议按数据敏感度定，高敏感数据可以每次会话都换。

5.4 常见问题速查表

5.5 几个容易被忽略的细节

第一，时间同步。证明报告里通常带时间戳，设备端和云端时间偏差太大会导致验证失败。眼镜端要支持NTP或从云端同步时间。

第二，固件更新。眼镜固件升级后，本地的根证书、白名单可能都要更新。更新包本身要签名验证，防止被替换。

第三，降级攻击。攻击者可能诱导设备使用旧版本的安全策略。方案里要加"最低安全版本号"检查，低于这个版本的证明一律拒绝。

第四，侧信道防护。TEE内的代码要避免数据相关的分支和内存访问模式，减少被侧信道分析的风险。这对加密库的实现要求很高，建议直接用经过审计的库，别自己写。

6. 我对这套方案的一点实际体会

做端云隐私方案这几年，我最大的感受是：技术从来不是最难的部分，信任模型的设计才是。TEE和远程证明这套东西，原理讲清楚不难，难的是让整个链路在工程上真正闭环——设备端的随机源要可靠、云端的证明服务要高可用、白名单更新要自动化、密钥轮换要不影响业务。任何一个环节掉链子，整套方案就形同虚设。

还有一个体会是，别追求"绝对安全"。AI眼镜这种消费级设备，用户要的是"我的私人数据不会被随便看到"，而不是"对抗国家级攻击"。方案设计要在安全、性能、成本之间找平衡点。把威胁模型定清楚，把最关键的几类威胁防住，比堆一堆用不上的安全机制更实际。

最后分享一个小技巧：做远程证明联调时，先在本地用软件模拟的TEE环境跑通全流程，再上真实硬件。软件模拟环境虽然不安全，但调试效率高得多，能快速定位是逻辑问题还是硬件问题。等逻辑跑通了，再切到真实TEE上验证，能省下大量排查时间。