IoT 物理攻击：侧信道读出秘密，故障注入改变安全判断
一颗芯片正确实现了密码算法，并不意味着其物理行为不会泄露信息；一段程序正常情况下会拒绝错误签名，也不意味着异常供电下始终执行同样判断。物理安全研究需要分别评估观察设备和干扰设备的能力。
实操准备：真实轨迹与指定硬件是分析输入
侧信道和故障注入依赖具体芯片与板卡。开始前需要明确修订、目标运算、触发条件、探头或注入连接，以及可独立验证的结果。
使用真实采集数据，而不是生成带答案的轨迹
没有采集硬件时，可以使用 ANSSI 公开的 ASCAD 固定密钥采集数据。这是 ATmega8515 上掩码 AES 的实际采集，原始数据与分析所用片段分开提供；带 desync 的版本另加了人工失同步，不能混为未经处理的测量。
在独立研究目录执行以下上游下载流程。压缩包约 4.2 GB，解压数据约 7.3 GB，先预留空间：
git clone https://github.com/ANSSI-FR/ASCAD.git
cd ASCAD/ATMEGA_AES_v1/ATM_AES_v1_fixed_key
curl -fL https://www.data.gouv.fr/api/1/datasets/r/e7ab6f9e-79bf-431f-a5ed-faf0ebe9b08e -o ASCAD_data.zip
shasum -a 256 ASCAD_data.zip
unzip ASCAD_data.zip
摘要应与上游说明中的 a6884faf97133f9397aeb1af247dc71ab7616f3c181190f127ea4c474a0ad72c 一致。使用 HDFView 打开解压后的 ASCAD.h5，查看 profiling 与 attack 的轨迹和元数据，确认采样点、输入标签与目标字节；训练和攻击数据不能混用。运行原仓库模型评估前，按其依赖与参数文件配置历史研究环境，不假定当前 TensorFlow/Keras 能无修改加载旧模型。本文核对了数据入口与说明，未下载整套数据或执行模型评估。
从数据文件走到上游模型评估
将原仓库根目录作为工作目录，先打开固定密钥目录下的 example_test_models_params，逐项核对 ascad_database、model_file 与 num_traces。当前参数示例引用 ASCAD_fixed.h5，而上述历史下载说明列的是 ASCAD.h5；复制参数文件后把路径改为实际解压的文件，不能直接把文件缺失解释成数据损坏。上游参数文件
在仓库根目录、上游兼容的 TensorFlow 研究环境中执行：
cp ATMEGA_AES_v1/ATM_AES_v1_fixed_key/example_test_models_params params-local.txt
编辑 params-local.txt，确认数据与模型存在，将 save_file 设为自己的输出图片路径；然后调用原项目评估入口：
python ASCAD_test_models.py params-local.txt
评估脚本默认评估目标字节 2，使用攻击集轨迹与元数据计算真实候选密钥的排名，输出轨迹数量与 rank 的关系；rank 为 0 表示该字节的正确候选排在首位。它评估已有模型，并未完成整把未知密钥的独立恢复。参数文件在该版本中会被求值，只使用自己核对过的本地参数。
文件不存在先检查当前目录与路径；模型不能加载先核对历史 TensorFlow/Keras 和模型格式；rank 无改善再核对目标字节、预处理与数据集是否和模型匹配。这里已核对上游参数与调用代码，未执行模型推理，不预填成功曲线或所需轨迹数。
有自己的样机时，先记录正常加密输入与输出，再连接匹配的采集设备和触发线。执行一次采集，检查是否削顶、触发是否稳定、同一输入的轨迹能否对齐；修正这些问题后再批量采集。原始数据、采集配置和后续分析数据分开保存。
分析时选择对应实现的中间值模型，以部分轨迹求候选，以保留轨迹验证稳定性；最终用独立明密文对验证整个密钥。某一字节在同一批数据中相关性最高，只能算分析线索。ChipWhisperer 的 Analyzer API提供轨迹项目与 CPA 接口，使用前核对项目格式、目标实现与泄漏模型。
针对真实产品复现故障注入：先核对公开工程
Starlink 研究公开了 KULeuven-COSIC/Starlink-FI 工程，包含特定用户终端所需的硬件、固件与连接说明。先取得工程并保存版本：
git clone https://github.com/KULeuven-COSIC/Starlink-FI.git
cd Starlink-FI
git rev-parse HEAD
按仓库说明核对终端版本、modchip PCB、元件和测试点；手中板卡与研究对象不一致时，先分析电源轨、复位和启动信号，不能照抄焊点与时序。这个路径需要真实终端、制板与焊接条件，不是下载一个脚本就能远程复现。
复现时先保存未连接扰动时的串口启动基线，再按工程步骤部署 modchip 并采集扰动后的启动记录。分别统计正常启动、复位、超时与未经批准代码实际执行。只有最后一项对应启动边界被突破；设备重启或日志消失不算成功。物理连接和操作依原始工程执行，本仓库未持有对应样机，未验证成功率与参数。
把采集、突破和系统权限接起来
对自己的产品，先在同型号可恢复样机上完成测量，再检查所得身份在后台的权限与撤销情况。真实功耗分析缺少输入标签、故障注入缺少恢复方案、板卡版本不匹配时，应把缺失条件写进研究记录；不要用另一块教学板上的结果补成目标产品结论。
成立前提与能力变化
被动侧信道需要能够采集与目标运算相关的物理量，并有足以验证推断的模型或输入条件；故障注入还需要影响设备运行环境。可拆机、可反复触发运算、可重启和可改写存储是不同能力，应按实际条件记录。真正的终点是秘密或等价能力被验证，或安全判断确实被绕过。
侧信道观察，故障注入干预
侧信道利用功耗、电磁、时间或其他可观测量与内部数据之间的关系。故障注入则主动改变运行条件，使处理器、存储或外设出现异常，再观察错误如何影响安全流程。两者可能组合，但根因和验证方式不同。
功耗波形出现变化，不等于已经恢复密钥；设备在毛刺下重启，也不等于绕过了安全启动。研究必须继续证明相关性对应什么秘密，或者异常发生后设备接受了什么本应拒绝的行为。
攻击条件应具体到物理距离、是否拆机、能否反复重启、是否可控制输入，以及是否掌握相同型号样机。不能把需要焊接附加电路的实验，描述成无线远程攻击。
相关功耗分析需要模型与数据共同成立
以 AES 的教学性分析为例，研究者可针对候选密钥建立中间值的泄漏假设，比较预测与实际采集的多条功耗轨迹。相关性较强的候选提供线索，最终还需要用独立数据验证密钥或其等价能力。
ChipWhisperer 的 Analyzer API 提供 CPA 分析与泄漏模型接口，说明这类工作需要轨迹、已知输入及明确假设，而不是找到一条“尖峰”就得出结论。不同实现、测量点、噪声与防护会显著改变实验条件。ChipWhisperer Analyzer 文档
固定执行时间有助于减少特定时间泄漏，但不自动消除功耗或电磁泄漏；增加随机延迟也可能只增加对齐成本。掩码、隐藏和硬件防护的有效性，需要针对实现和攻击模型验证。
故障注入瞄准的是控制流与状态
电压或时钟扰动可能导致错误计算、异常读写或控制流偏离；电磁故障注入可影响局部电路行为。具体效果取决于芯片、板级设计和扰动条件，不能概括为“毛刺总能跳过某条指令”。
对安全启动，一种目标是让验签失败未能导致拒绝执行；对读保护，一种目标是让访问控制状态被错误处理。需要检查的安全不变量是：即使出现可检测异常，设备也不能把未知状态当作验证成功。
软件重复检查只有在故障模型下足够独立时才有意义。同一次扰动可能同时影响重复判断，或者使程序跳过整个检查区段，因此“比较两次”不构成普适保证。
Starlink 案例的突破与影响边界
SpaceX 在回应 Lennert Wouters 的 2022 年研究时，确认攻击需要拆开 Starlink 用户终端、连接额外组件，并在启动时干扰电源轨，从而绕过安全启动。回应明确区分了本地终端代码执行与远程利用，也说明该条件不直接适用于在轨卫星。SpaceX 原始回应
这个案例的架构价值在于：物理防护被突破后，终端仍不应自动取得整个网络的管理权限。把设备身份限制在必要资源与操作范围内，可以约束单设备失陷后的扩散；这不能恢复本机机密性，但能够改变后续影响。
什么才算一次有效的故障注入结果
对于启动验签，可信判据应是未经批准的测试镜像被实际执行，并且能够排除镜像原本已经被合法信任、调试配置允许执行或测量工具误判。设备没有输出错误日志，只能提供线索，不能独立证明校验被跳过。
对于密钥提取，判据应是恢复结果能够在独立输入上产生正确的密码结果，或者能够完成等价的身份操作。仅某个候选在同一组轨迹上得分最高，可能仍受噪声、模型偏差或过拟合影响。
对传感器信号欺骗，则要证明外部物理输入怎样变成设备接受的错误测量，并影响哪个业务动作。这种攻击与密码侧信道的目标不同，应分别记录传感器类型、环境条件、算法过滤与最终控制结果。
上述判据也影响防护评估。异常检测能让设备安全复位，可能成功阻断一次绕过，却同时引入持续拒绝服务的残余风险；评估应同时观察秘密保护、错误执行与服务恢复，避免只选对某一项有利的结果。
把异常现象、实际突破和系统影响分别记录
下面是实验判定示例，不包含实际测量或某型号的注入参数：
| 观测 | 还不能据此断言 | 需要补充的证据 |
|---|---|---|
| 扰动后设备复位 | 已绕过安全启动 | 未授权测试镜像是否被执行 |
| 候选密钥相关性最高 | 已恢复正确密钥 | 独立输入上的密码结果验证 |
| 普通内存测试标记可读 | 安全区秘密同样可读 | 对应区域的真实访问与权限 |
| 本机能够产生有效身份证明 | 已控制其他设备 | 云端资源与管理权限的实际结果 |
记录中应能区分基线运行、扰动事件、目标状态和最终判据，并保存可复核的失败结果。若一次实验只在开放调试配置下成功，应先排除调试权限本身的影响；如果把防护关闭后才得到结果，就不能据此评价量产配置。
为了验证防护，也应观察异常后设备进入哪条恢复路径、身份是否仍可被使用，以及反复异常是否造成持续拒绝服务。把这些结果接到具体控制点，才有助于决定该加固硬件、调整错误处理，还是收紧设备的系统权限。
防护同时作用于测量、异常与身份
可评估的第一层方案是加强秘密运算和安全判断：使用适合威胁模型的受保护实现，监测供电与时钟异常，对关键状态进行一致性校验，并在异常时进入经过设计的安全路径。安全路径本身不能打开无认证恢复服务。
第二层方案是约束设备失陷后的身份能力：每设备独立秘密、有限云权限、可撤销身份，以及与高权限服务隔离。这样即使本地签名接口被借用，攻击者也不应因此控制其他设备。
两层方案有不同成本。芯片与板级防护会影响选型、功耗和制造成本；身份约束依赖云端策略、轮换与运维能力。对低成本传感器与高价值门禁，不应使用未经论证的统一防护强度。
实验结果如何避免夸大
测试报告应记录样机型号、芯片修订、固件、安全配置、实验条件和成功判据，并分别统计崩溃、复位、错误输出与实际绕过。跨样机复现和独立验证，比单次成功更能说明影响范围。
没有观察到绕过，只能说明在已测试条件下未成功。若没有覆盖足够攻击条件，不应据此宣称硬件不可攻破；反之，拿到一台样机的执行权限，也需要继续验证其云端能力后才能判断系统性影响。