3. 密码学基础回顾：对称加密（AES）、非对称加密（RSA/ECC）、哈希函数（SHA-256）在模型保护中的应用
好，咱们直接进入正题。做端侧AI模型保护，密码学是绕不开的基石。你想想看，模型文件本身就是一个巨大的数字资产，要把它安全地部署到用户的手机、IoT设备上，没有加密手段，那基本等于裸奔。
我个人习惯把密码学在模型保护中的角色分成三类：加密存储、安全传输、完整性校验。今天咱们就围绕这三个场景，把对称加密、非对称加密和哈希函数挨个捋一遍。
3.1 对称加密：AES，模型加密的主力军
对称加密，说白了就是加密和解密用同一把钥匙。速度快，适合处理大块数据。模型文件动辄几十上百MB，用对称加密是最实际的。
AES（Advanced Encryption Standard） 是目前最主流的对称加密算法。我建议你直接选 AES-256-GCM 模式。为什么？
- AES-256：密钥长度256位，暴力破解基本不可能。
- GCM（Galois/Counter Mode）：它自带认证功能，能检测数据是否被篡改。这在模型保护里特别重要——你不仅要防泄露，还要防别人偷偷改你的模型权重。
核心要点：模型加密时，密钥不能硬编码在代码里。密钥本身需要被保护，这就引出了下一节的内容。
我在项目中遇到过一个问题：用AES-ECB模式加密模型，结果发现相同的权重块加密后密文也相同。这给攻击者提供了分析模式的机会。所以，千万别用ECB模式，一定要用带IV（初始化向量）的模式，比如CBC或GCM。
下面是一个简单的AES-256-GCM加密模型文件的伪代码示例：
// 伪代码：使用AES-256-GCM加密模型文件
function encrypt_model(model_bytes, key_256bit):
iv = generate_random_iv(12 bytes) // GCM推荐12字节IV
cipher = AES_GCM_Encrypt(model_bytes, key_256bit, iv)
// 输出: iv + ciphertext + auth_tag
return iv || ciphertext || auth_tag
// 解密时
function decrypt_model(encrypted_data, key_256bit):
iv = encrypted_data[0:12]
auth_tag = encrypted_data[-16:] // 最后16字节是认证标签
ciphertext = encrypted_data[12:-16]
plaintext = AES_GCM_Decrypt(ciphertext, key_256bit, iv, auth_tag)
return plaintext避坑指南：我曾经在嵌入式设备上踩过坑——AES-GCM的认证标签验证失败。后来发现是设备的内存对齐问题导致数据被截断。所以，在端侧实现时，一定要确认数据长度和内存对齐。
3.2 非对称加密：RSA/ECC，解决密钥分发难题
对称加密快，但有个致命问题：密钥怎么安全地传给设备？你总不能把密钥明文写在代码里吧？
非对称加密就是来解决这个问题的。它有一对密钥：公钥公开，私钥保密。用公钥加密的数据，只有私钥能解开。
RSA 和 ECC（椭圆曲线加密） 是两种主流选择。
| 特性 | RSA | ECC |
|---|---|---|
| 安全性基础 | 大整数分解 | 椭圆曲线离散对数 |
| 同等安全强度密钥长度 | 2048位 | 256位 |
| 计算速度 | 较慢（尤其私钥操作） | 较快 |
| 端侧适用性 | 资源消耗大 | 更适合嵌入式设备 |
我个人习惯在端侧模型保护中使用 ECC（比如Curve25519）。原因很简单：密钥短、计算快、省电。你想想看，一个IoT设备电池就那么点，用RSA做一次密钥交换，CPU跑半天，用户早骂娘了。
实际应用中，非对称加密很少直接加密模型文件（太慢了）。它通常用来加密AES的密钥。这就是经典的 混合加密方案：
- 设备端生成一个随机的AES密钥（会话密钥）。
- 用服务器的公钥（RSA或ECC）加密这个AES密钥。
- 服务器收到后，用私钥解密得到AES密钥。
- 后续通信全部用AES对称加密。
注意：非对称加密不能防重放攻击。我曾经见过一个方案，攻击者截获了加密的AES密钥，然后重放给服务器。服务器解密后以为是新会话，结果密钥被复用。解决方案是加入时间戳或随机数（nonce）。
3.3 哈希函数：SHA-256，模型的数字指纹
哈希函数，说白了就是给数据算一个固定长度的摘要。它不可逆，而且输入稍微变一点，输出就天差地别。
SHA-256 是SHA-2家族的一员，输出256位（32字节）的哈希值。在模型保护中，它主要干三件事：
- 完整性校验：模型部署前算一个哈希值，部署后重新算一遍。如果不一样，说明模型被篡改了。
- 密码派生：用用户的密码或设备唯一ID，通过SHA-256派生出一个AES密钥。这样就不用存储密钥了。
- 数字签名的基础：先对模型算哈希，再对哈希值做签名。效率比直接签名整个模型高得多。
我记得有一次做固件升级，模型文件下载到设备后，校验SHA-256一直失败。排查了半天，发现是下载过程中HTTP响应被压缩了，解压后哈希才对。所以，哈希校验一定要在数据完全还原之后再做。
下面是一个简单的模型完整性校验流程：
// 伪代码：模型完整性校验
// 部署前
original_hash = SHA256(model_file.bin)
// 将 original_hash 安全存储（比如签名后存储）
// 设备端启动时
loaded_model = load_model("model_file.bin")
computed_hash = SHA256(loaded_model)
if computed_hash != original_hash:
// 模型被篡改，拒绝加载
return ERROR_MODEL_TAMPERED
else:
// 模型完整，继续加载
return SUCCESS小技巧：在端侧设备上，SHA-256的计算速度很快。我建议在模型加载的每个关键节点都做一次哈希校验——比如从Flash读取后、解密后、加载到内存前。多一次校验，多一分安全。
3.4 三者如何协同工作？一个完整的模型保护流程
光讲理论没意思，咱们看一个实际场景。假设你要把一个训练好的模型部署到用户的手机上：
- 服务器端：用AES-256-GCM加密模型文件，生成一个随机的AES密钥。
- 服务器端：用设备的公钥（ECC）加密这个AES密钥。
- 服务器端：对加密后的模型和密钥计算SHA-256哈希，然后用服务器的私钥对这个哈希签名。
- 设备端：收到数据包后，先用服务器的公钥验证签名，确保数据来源可信。
- 设备端：计算SHA-256，与签名中的哈希比对，确保数据完整。
- 设备端：用自己的私钥解密得到AES密钥。
- 设备端：用AES密钥解密模型文件，加载到内存中运行。
你看，对称加密、非对称加密、哈希函数，各司其职，缺一不可。
总结一下：
- AES：加密模型本体，速度快，适合大数据量。
- ECC/RSA：保护AES密钥，解决密钥分发问题。
- SHA-256：校验完整性，防止篡改。
三者结合，才能构建一个端到端的安全链路。
嗯，密码学基础这块就聊到这儿。下一节咱们会深入讲如何在嵌入式设备上高效实现这些算法——毕竟端侧资源有限，不能像服务器那样随便跑。到时候我会分享一些我在ARM Cortex-M系列芯片上的优化经验。