[论文解读] Taking a Look into Execute-Only Memory
本文表明,执行仅限内存(XOM)——一种旨在防止多方微控制器开发中代码读出的基于硬件的固件保护机制——在根本上是不安全的。通过利用CPU状态和SRAM等共享硬件资源,作者开发了一种自动方法,通过侧信道分析和基于小工具的代码提取,成功恢复了XOM保护的固件,对包括NXP和德州仪器在内的多家厂商设备实施了实际攻击。
The development process of microcontroller firmware often involves multiple parties. In such a scenario, the Intellectual Property (IP) is not protected against adversarial developers which have unrestricted access to the firmware binary. For this reason, microcontroller manufacturers integrate eXecute-Only Memory (XOM) which shall prevent an unauthorized read-out of third-party firmware during development. The concept allows execution of code but disallows any read access to it. Our security analysis shows that this concept is insufficient for firmware protection due to the use of shared resources such as the CPU and SRAM. We present a method to infer instructions from observed state transitions in shared hardware. We demonstrate our method via an automatic recovery of protected firmware. We successfully performed experiments on devices from different manufacturers to confirm the practicability of our attack. Our research also reveals implementation flaws in some of the analyzed devices which enables an adversary to bypass the read-out restrictions. Altogether, the paper shows the insufficient security of the XOM concept as well as several implementations.
研究动机与目标
- 评估执行仅限内存(XOM)作为防护机制在防范具有物理和特权访问权限的攻击者时的安全有效性。
- 研究是否可通过共享硬件资源(如CPU寄存器和SRAM)的侧信道分析恢复XOM保护的固件。
- 开发并验证一种利用可观测状态转换和代码小工具利用的自动方法,以恢复XOM保护的固件。
- 识别并利用XOM启用微控制器中的实现缺陷,绕过读出限制。
- 评估多方嵌入式开发中固件安全的更广泛影响,并倡导采用TEE等更强隔离机制。
提出的方法
- 作者在受控执行环境下分析XOM保护微控制器的行为,通过观察指令执行期间的CPU寄存器状态和SRAM内容,推断出秘密代码。
- 他们识别并利用了‘小工具’——特定指令序列,可实现受控内存访问——通过重用CMSIS等库中的现有代码模式。
- 应用基于时间的侧信道攻击,检测指令级状态转换,从而重建可观测状态变化中的代码。
- 通过中断驱动执行实现方法自动化,以触发并观察XOM保护区域内的状态变化。
- 通过在NXP Kinetis和德州仪器MSP432P4等多个微控制器平台上的实验,验证了该方法,构建并执行自定义小工具以提取受保护代码。
- 通过分析调试和跟踪功能(如数据观察与跟踪,DWT组件)进一步加速代码提取过程。
实验结果
研究问题
- RQ1是否可通过共享硬件状态转换的侧信道分析恢复XOM保护的固件?
- RQ2哪些特定指令序列(小工具)可在硬件强制读保护下实现对XOM保护内存的未授权访问?
- RQ3XOM启用微控制器中的实现缺陷是否允许绕过预期的读出限制?
- RQ4此类攻击在不同微控制器架构和厂商之间,自动化代码恢复的实现程度如何?
- RQ5在真实嵌入式系统中,此类攻击的实际限制和成功率如何?
主要发现
- XOM概念从根本上不安全,因为它未能通过共享CPU和SRAM资源隔离执行与侧信道泄露。
- 作者成功利用单条非加载指令后接一条加载指令作为功能小工具,在NXP Kinetis设备上恢复了XOM保护的固件。
- 在MSP432P4设备上,使用两条指令的小工具(存储后接加载)解锁XOM区域并提取代码,利用了解锁机制重锁行为中的漏洞。
- 在多个设备中发现实现缺陷,允许绕过XOM保护,包括代码退出后过早锁定访问权限。
- 恢复过程已实现自动化,并在多个厂商和架构上成功演示,证明了在真实攻击条件下完整固件提取的可行性。
- 研究结论认为,仅靠XOM不足以保护多方开发中的固件安全,必须采用TEE等硬件支持的隔离机制才能实现充分安全。
更好的研究,从现在开始
从论文设计到论文写作,大幅缩短您的研究时间。
无需绑定信用卡
本解读由 AI 生成,并经人工编辑审核。