Flipper Zero 固件内嵌 Mbed TLS 的安全策略与威胁模型全解析
【免费下载链接】flipperzero-firmwareFlipper Zero firmware source code项目地址: https://gitcode.com/GitHub_Trending/fl/flipperzero-firmware
导读
本文以 Flipper Zero 固件仓库中随 OpenThread 协议栈一并打包的 SECURITY.md 为骨架，完整梳理 Mbed TLS 的安全漏洞报告渠道、受支持分支策略，以及其官方威胁模型——包括远程攻击、计时侧信道、本地故障注入与物理攻击的分类与防护边界，并深入讲解文档重点警告的块密码计时侧信道风险及三条缓解路径。读完本文，你将掌握在嵌入式设备中评估与部署 TLS/加密组件时的安全边界判断方法，并能结合仓库源码（配置宏MBEDTLS_AESNI_C、MBEDTLS_PADLOCK_C与library/aes.c的硬件加速运行时检测）理解这些安全承诺在真实固件中的落地方式。
文档定位：随 OpenThread 打包的 Mbed TLS 安全说明
该文档位于 Flipper Zero 固件仓库的 OpenThread 组件目录中：
lib/stm32wb_copro/wpan/thread/openthread/stack/third_party/mbedtls/repo/从目录结构看，这是一份随上游 OpenThread 栈快照一并引入的 Mbed TLS 精简副本，包含 README.md、CONTRIBUTING.md、LICENSE、SUPPORT.md 以及include/（头文件）、library/（源码）等子目录。其中library/下可以看到aes.c、aesni.c、padlock.c、camellia.c、aria.c、des.c、chacha20.c、chachapoly.c、hmac_drbg.c、ctr_drbg.c、constant_time.c等实现文件——它们正好对应 SECURITY.md 中威胁模型与块密码章节反复提及的组件。
需要说明的是：固件仓库在 lib/mbedtls 下还维护了另一份供主固件使用的 Mbed TLS 源码树（含 mbedtls_config.h 配置头与完整library/实现），本文在讲解配置宏与源码实现时会同时引用这两处路径，作为安全策略落地的事实依据。
漏洞报告渠道与安全事件处理流程
SECURITY.md 明确规定了 Mbed TLS 的安全漏洞提交方式：若发现 Mbed TLS 安全漏洞，应向安全团队发送邮件至mbed-tls-security@lists.trustedfirmware.org。
其安全事件处理流程的目标非常直接——确保修复方案在漏洞公开之前就绪可部署。这意味着：
- 漏洞报告采用"先私密提交、后协同修复、再统一公开"的节奏；
- 上游的完整处理过程（包括披露时间表、受影响的维护分支、致谢名单等）以 Mbed TLS 官方安全中心为准。
对 Flipper Zero 这类把 Mbed TLS 以第三方库形式内嵌的固件而言，这条渠道是获取上游修复的第一入口：固件维护者需要持续跟踪该渠道发布的公告，才能把安全修复及时合入自家固件，而不是依赖"碰巧看到发行说明"。
维护分支策略：只有维护中的分支才获得安全修复
文档强调了一条硬性规则：
只有维护分支（maintained branches）才能获得安全修复，用户应始终使用维护分支的最新版本。
这意味着：
- 老旧的、已停止维护的分支不会收到补丁，继续使用旧版本等于主动暴露在已知漏洞之下；
- 即使在使用维护分支，也应持续升级到该分支的最新发布，而不是停留在某一历史版本。
原文档引用的BRANCHES.md（各分支维护状态清单）与docs/architecture/alternative-implementations.md（替代实现指南）属于上游仓库中的文档，本次随 OpenThread 快照打包的副本目录中并未包含这两个文件，如需查看应以 Mbed TLS 上游发行版为准。
威胁模型总览：按攻击者能力分类
SECURITY.md 的核心价值在于其显式声明的威胁模型（Threat Model）。它的分类基准是攻击者所具备的能力，而非攻击"发生在网络的哪一层"。完整分类如下：
| 攻击类别 | 攻击者能力假设 | Mbed TLS 的安全承诺 |
|---|---|---|
| 远程攻击（Remote） | 可观察/篡改网络传输数据，包括包内容、时序，可抑制、延迟、注入消息 | 完全防护（限于协议自身提供的安全保证） |
| 本地计时攻击（Local timing） | 可运行软件，通过共享硬件观察 Mbed TLS 执行时序（缓存、总线竞争、分支预测） | 有限防护，仅针对公开记载的攻击技术 |
| 本地非计时侧信道（Local non-timing） | 可访问平台传感器（如 ADC）采集 CPU 噪声等物理状态 | 不提供任何保证，需平台层缓解 |
| 本地故障注入（Local fault injection） | 可在同硬件上运行软件并诱发物理故障 | 不提供任何保证，需平台层缓解 |
| 物理攻击（Physical） | 可接触硬件物理信息或改变物理状态（功耗分析、射频发射、故障注入） | 不提供任何保证，需物理级对抗措施 |
这张表的实际用途是帮助集成方（也就是固件开发者）回答一个问题："我的用例威胁模型里到底有哪些攻击者？"只有先把攻击者画出来，才能决定安全投入应该花在协议层、平台层还是物理层。
远程攻击：协议能保证的才是安全的
远程攻击场景下，攻击者可以：
- 观察数据内容与单个数据包的时间特征；
- 抑制、延迟合法消息；
- 注入伪造消息。
Mbed TLS 的目标是对远程攻击提供完全防护，并让上层应用能够获得同样程度的防护——但这种防护被严格限定在所实现协议自身提供的安全保证范围之内。文档举了一个很直白的例子：TLS 协议本身并不保证消息无延迟到达，因此 Mbed TLS 也无法提供"消息按时到达"的保证，这不属于库的缺陷。
文档在此处给出了第一个醒目警告：
警告：块密码（block ciphers）目前尚不能对能以足够精度测量数据包时序的攻击者提供完全防护，详见"块密码"一节。
这说明即使目标只是"防住网络攻击者"，如果网络延迟测量精度足够高，计时侧信道仍可能被利用，因此块密码问题在远程攻击模型下同样需要关注。
本地攻击：计时、非计时侧信道与故障注入
计时攻击（Timing attacks）
本地计时攻击者通过与 Mbed TLS 共享硬件（典型攻击向量包括缓存时序、内存总线竞争、分支预测）来观察库执行指令的时序信息。
文档对此的定位非常务实：
- Mbed TLS 仅提供有限的计时攻击防护；
- 防护成本随测量粒度与环境噪声变化很大，因此只能"瞄准公开记载的攻击技术"提供防护；
- 项目正朝着完全时序不变（timing-invariant）代码的方向演进，但尚未达到这一目标。
文档还特别提醒：时序信息同样可能通过网络或物理侧信道被观测，这两类场景分别归入远程攻击与物理攻击章节处理。块密码的本地计时风险同样适用，且引用同一段警告。
本地非计时侧信道（Local non-timing side channels）
这类攻击假设攻击者代码所在平台拥有能采集硬件物理状态的传感器，例如位置碰巧能拾取 CPU 噪声的模数转换器（ADC）。
文档给出的结论是明确的：Mbed TLS 对本地非计时侧信道攻击不作出任何安全保证。如果这类攻击存在于用例或应用威胁模型中，必须由平台（硬件与系统层）负责缓解。
本地故障注入攻击（Local fault injection attacks）
运行在相同硬件上的软件可以影响设备物理状态并引入故障（fault）。
结论与上一条一致：Mbed TLS 对本地故障注入攻击不作出任何安全保证，若威胁模型中包含该类攻击，需平台层缓解。这提醒固件开发者：TLS 栈能保住的只是协议语义，供电毛刺、时钟毛刺这类故障手段必须靠硬件防护与运行时完整性校验来应对。
物理攻击：超出软件库能力边界
物理攻击者可以获取 Mbed TLS 运行所依赖硬件的物理信息，并能改变硬件物理状态，典型手段包括：
- 功耗分析（power analysis，如 SPA/DPA）；
- 射频发射分析；
- 故障注入（如激光、电磁干扰）。
文档立场毫不含糊：Mbed TLS 对物理攻击不作出任何安全保证，这类攻击必须由物理级对抗措施（屏蔽、加扰、防篡改封装等）来缓解。对 Flipper Zero 这类面向物理世界交互的硬件设备而言，这条边界尤其值得注意——设备本身的可接触性天然扩大了物理攻击面，安全模型不应把赌注押在软件库上。
边界说明：模型外的对抗措施不等于承诺
文档用一节专门澄清"范围外对抗措施"（Out-of-scope countermeasures）的语义：
- Mbed TLS 是长期自然演进的代码库，并非一直有明确定义的威胁模型，因此可能包含针对上述模型之外攻击的对抗措施；
- 这些措施的存在不代表Mbed TLS 能防御模型外的攻击类别；
- 这些措施失效也不被视为漏洞。
这一条款实质上是给"安全边界"划了一条法律意义上的线：集成方不能因为"库里有某个防御逻辑"就推断它能挡住某类攻击，判断依据只能是本文的威胁模型分类。
块密码的计时侧信道风险与三条缓解路径
这是全文技术含量最高的部分。目前 Mbed TLS 中包含四个块密码：AES、CAMELLIA、ARIA 和 DES。其纯软件实现依赖查表（lookup tables），而查表访问模式会随密钥与数据变化，因而对计时攻击敏感。
文档明确：这类计时攻击可以是物理的、本地的，甚至在某些网络延迟条件下是远程的，最坏情况可导致密钥恢复（key recovery）。对此，文档给出三条缓解路径：
- 开启 AES 硬件加速：仅在部分架构上受支持，目前仅适用于 AES。对应配置选项为
MBEDTLS_AESNI_C（x86 的 AES-NI 指令）与MBEDTLS_PADLOCK_C（VIA PadLock 引擎）。 - 为易受攻击的密码算法接入安全的替代实现（通常是硬件加速实现），详见上游的《Alternative Implementations Guide》。
- 改用不基于块密码的密码机制：
- 认证加密场景：用ChaCha20/Poly1305替代块密码模式；
- 随机数生成场景：用HMAC_DRBG替代CTR_DRBG（后者底层依赖 AES 块密码）。
三条路径分别对应"算法不变、加速执行""换实现""换算法"三个层次的取舍，集成方可按目标平台的硬件能力灵活选择。
源码印证：配置宏与硬件加速的运行时检测
配置宏定义
在主固件的 Mbed TLS 配置头 lib/mbedtls/include/mbedtls/mbedtls_config.h 中，两个文档提及的配置宏均有完整定义与说明：
MBEDTLS_AESNI_C（约 L2241-L2270）：启用 x86-64/x86-32 的 AES-NI 支持，对应模块library/aesni.c，调用方为library/aes.c。注释特别说明：非 x86 目标上该选项会被静默忽略；GCC/Clang 在目标未显式支持 AESNI 时需MBEDTLS_HAVE_ASM，或使用-msse2 -maes -mpclmul等编译选项。该宏在配置头中默认处于启用状态（L2270）。MBEDTLS_PADLOCK_C（约 L3032-L3043）：启用 VIA PadLock 硬件加密引擎支持，同样属于 x86 平台特性，默认启用（L3043）。
对 Flipper Zero 所采用的 STM32WB（Arm Cortex-M4）平台而言，这两项 x86 专属的硬件加速选项按上游文档说明并不适用——这恰好印证了 SECURITY.md"硬件加速仅部分架构支持、目前仅 AES"的表述，也说明在非 x86 目标上，块密码查表实现的计时风险需要格外重视。
运行时能力检测
在 lib/mbedtls/library/aes.c 中可以看到硬件加速并非"编译进去就用"，而是带运行时检测：
- L542、L1864：通过
mbedtls_padlock_has_support(MBEDTLS_PADLOCK_ACE)探测 PadLock AES 能力； - L550、L601、L711、L1038、L1859：通过
mbedtls_aesni_has_support(MBEDTLS_AESNI_AES)探测 AES-NI 指令支持。
也就是说，即使编译期开启了MBEDTLS_AESNI_C/MBEDTLS_PADLOCK_C，代码仍会在运行期确认 CPU 是否真正具备相应指令/引擎，再决定走硬件加速路径还是回退到（计时敏感的）查表软件实现。这为威胁模型中的"硬件加速是否真的生效"提供了可验证的判定点：集成方可以通过确认目标 CPU 特性来推断 AES 运算实际走哪条路径。
配置机制
随 OpenThread 打包的 Mbed TLS 副本采用标准的MBEDTLS_CONFIG_FILE覆盖机制，例如 aes.h：
#if !defined(MBEDTLS_CONFIG_FILE) #include "mbedtls/mbedtls_config.h" #else #include MBEDTLS_CONFIG_FILE #endif这意味着构建系统可以在编译期注入自定义配置头，为不同安全需求定制启用/禁用的模块集合——这是上文三条缓解路径得以"按平台配置"落地的基础设施。
对 Flipper Zero 集成场景的实践建议
综合 SECURITY.md 的威胁模型与仓库源码，内嵌 Mbed TLS 的固件在安全决策上应遵循以下顺序：
- 先画威胁模型：明确部署环境中是否存在远程攻击者（网络通信）、本地软件攻击者（计时/非计时侧信道/故障注入）、物理攻击者（功耗/射频/篡改）。文档已给出每类攻击者对应的防护承诺等级。
- 对照承诺定边界：远程攻击由协议保证；计时攻击只有"针对公开技术"的有限防护；非计时侧信道、故障注入与物理攻击一律不承诺——需要由平台（硬件隔离、抗故障设计、屏蔽封装）承担，不能指望 TLS 库。
- 处理块密码风险：优先寻找硬件加速或替代实现；否则在认证加密与 DRBG 场景切换到 ChaCha20/Poly1305 与 HMAC_DRBG。
- 跟进维护分支：仅维护中的 Mbed TLS 分支获得安全修复，固件应跟踪上游公告并及时升级，不能停留在快照版本上。
- 验证加速是否真生效：利用
mbedtls_aesni_has_support/mbedtls_padlock_has_support的运行时检测逻辑与编译配置，确认目标平台实际执行的密码路径，避免"以为开了加速、实际仍在查表"的误判。
结语
Mbed TLS 的 SECURITY.md 之所以值得固件开发者精读，在于它把"安全承诺"这件事讲得非常精确：承诺了什么（远程攻击、有限的计时防护）、不承诺什么（非计时侧信道、故障注入、物理攻击、模型外的偶然对抗措施）、以及已知短板在哪（块密码查表实现及其密钥恢复风险）。结合 Flipper Zero 仓库中 配置头 与 AES 实现 的源码印证，集成方完全可以把这份文档当作一份可执行的"安全验收清单"——逐条对照威胁模型、逐项验证缓解措施，从而在嵌入式 TLS 部署中避免对第三方库安全能力的不切实际期望。
【免费下载链接】flipperzero-firmwareFlipper Zero firmware source code项目地址: https://gitcode.com/GitHub_Trending/fl/flipperzero-firmware
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
