1. 受限设备概述：什么是受限设备
咱们先聊聊什么是受限设备。说白了，就是那些资源捉襟见肘的小家伙们——IoT 传感器、智能卡、嵌入式控制器。它们不像你桌上的电脑或者云服务器那样财大气粗，CPU 主频低、内存小、功耗还得精打细算。
我刚开始接触这个领域时，接手过一个智能电表项目。那设备用的是一颗主频 48MHz 的 Cortex-M0 芯片，RAM 只有 16KB，Flash 256KB。你想想看，要在这么点资源上跑 TLS 握手，还要保证实时抄表不丢包——嗯，那会儿我才真正理解什么叫“受限”。
1.1 什么是受限设备
受限设备，通常指计算能力、存储空间或能源供应受到严格约束的嵌入式系统。它们广泛分布在 IoT、工业控制、汽车电子、智能卡等领域。
根据 RFC 7228 的分类，受限设备可以按资源等级划分：
| 类别 | 典型设备 | CPU 主频 | RAM | Flash/ROM |
|---|---|---|---|---|
| Class 0 | 传感器节点、RFID 标签 | < 10 MHz | < 10 KB | < 100 KB |
| Class 1 | 智能电表、门锁 | 10–50 MHz | 10–50 KB | 100–500 KB |
| Class 2 | 网关、摄像头 | 50–200 MHz | 50–250 KB | 500 KB–2 MB |
关键认知：Class 0 设备通常无法直接运行标准 TLS/DTLS 协议栈，需要专用密码套件或代理方案。Class 1 是当前 IoT 密码学优化的主战场。
1.2 资源限制对密码学的影响
资源限制不是一句空话，它会实实在在地影响密码算法的选择、实现方式和运行效率。我把它拆成三个维度来讲。
1.2.1 CPU 限制
受限设备的 CPU 通常没有硬件加速单元，比如 AES-NI、RSA 协处理器。所有密码运算都得靠软件逐字节算。
- 对称加密：AES-128 在 48MHz 的 Cortex-M0 上，纯软件实现大约需要 200–300 周期/字节。一个 1500 字节的包，光加解密就要 3–5ms。
- 非对称加密：RSA-2048 签名验证，在同样平台上可能耗时 1–3 秒。你想想看，设备每隔几秒就要上报一次数据，握手阶段花掉好几秒，这谁受得了？
- 哈希运算：SHA-256 相对轻量，但连续计算大块数据时，CPU 占用率会飙升。
我的经验：在选型阶段，我习惯先拿目标芯片跑一遍密码基准测试。别信数据手册上的理论值，实际跑出来的结果往往差 2–3 倍。我曾经被一份“优化后 AES 仅需 150 周期”的宣传资料坑过，结果移植后实测 400 多周期。
1.2.2 内存限制
内存是受限设备最硬的瓶颈。RAM 小意味着：
- 缓冲区不能大：TLS 记录层默认 16KB 的缓冲区，在 16KB RAM 的设备上根本放不下。你得把缓冲区砍到 2KB 甚至 512 字节。
- 栈空间紧张：密码运算的临时变量、上下文结构体，稍不注意就会栈溢出。我见过一个项目，因为 RSA 私钥操作分配了 2KB 栈空间，直接把系统栈撑爆了。
- 代码体积受限：Flash 里要塞协议栈、驱动、应用逻辑，留给密码库的空间可能只有几十 KB。你不能把 OpenSSL 整个搬上去，得用 mbedTLS 或者自己裁剪。
避坑指南：我曾经在移植 mbedTLS 时，默认配置打开了所有密码套件，结果编译出来的固件超过 300KB，Flash 直接爆了。后来我手动裁剪到只保留 AES-CCM、ECDHE、SHA-256，体积降到 80KB 左右。记住：用多少，裁多少。
1.2.3 功耗限制
电池供电的设备，功耗是命门。密码运算会显著拉高功耗：
- 计算功耗：CPU 全速跑密码运算时，电流可能从待机的 10μA 飙升到 50mA。一次 TLS 握手消耗的电量，可能抵得上设备几小时的待机功耗。
- 通信功耗：密码套件决定了握手消息的大小和轮次。比如 ECDHE 握手比 PSK 握手多 2–3 轮消息交换，每次收发都要唤醒射频模块，而射频模块的功耗通常是 CPU 的 5–10 倍。
- 权衡策略：很多设备会采用“会话复用”或“预共享密钥”来减少握手次数。我做过一个温湿度传感器，每 10 分钟上报一次数据，如果每次都用完整握手，电池撑不过 3 个月；改成 PSK 模式后，电池寿命延长到 2 年以上。
1.3 受限设备密码学的核心挑战
把上面这些限制综合起来，你会发现密码套件选择变成了一个多目标优化问题：
- 安全性不能降级：不能用弱算法来换性能，128 位安全强度是底线。
- 性能要够用：握手延迟不能超过应用容忍阈值，比如工业控制要求 < 100ms。
- 内存要省着用：代码体积和运行时内存都要精打细算。
- 功耗要可控：不能因为加密把电池寿命砍半。
下面这张图概括了受限设备密码学设计的核心逻辑：
1.4 一个真实的权衡案例
我参与过一个智能门锁项目，主控是 ESP32（240MHz 双核，520KB SRAM，4MB Flash）。需求是：每次开锁指令必须经过双向认证和加密，延迟不能超过 500ms。
一开始我们选了 ECDHE + AES-128-GCM 套件。结果发现：
- ECDHE 密钥协商需要 2 轮握手，每轮都要做椭圆曲线点乘运算，耗时约 200ms。
- 加上 AES-GCM 加解密和消息验证，总延迟接近 600ms，超了。
后来我们改成 PSK + AES-128-CCM-8：
- PSK 模式省掉了密钥协商，握手只需 1 轮。
- CCM-8 的认证标签只有 8 字节，比 GCM 的 16 字节少一半，传输量更小。
- 总延迟降到 300ms 以内，电池寿命还延长了 20%。
教训：别迷信“最强套件”。在受限设备上，够用且高效才是王道。PSK + CCM 的组合虽然不像 ECDHE + GCM 那样提供前向安全性，但对于门锁这种场景，密钥定期更换就能满足安全需求。
1.5 本章小结
受限设备不是“小一号的电脑”，它们有自己独特的资源约束和设计哲学。CPU 慢、内存小、功耗敏感，这三个限制会直接影响密码套件的选择。记住：
- 先搞清楚你的设备属于哪个 Class，再决定能跑什么套件。
- 内存和功耗往往比 CPU 更致命，优先优化这两个维度。
- 不要照搬桌面端的密码学方案，要针对目标平台做裁剪和测试。