基于ESP32的硬件密钥用于软件应用程序保护 亚历山德鲁-伊昂·波波维奇（Alexandru-Ion Popovici）和弗洛林-丹尼尔·安东（Florin-Daniel Anton）

《Applied Sciences》：ESP32-Based Hardware Key for Software Application Protection Alexandru-Ion Popovici and Florin-Daniel Anton

　　**特色应用：低成本硬件密钥**
该硬件密钥专为保护在面临逆向工程、仿真和重放攻击场景下的授权软件应用程序而设计，通过将敏感决策和加密操作移至嵌入式适配器来实现保护。

**摘要**
在当前环境下，仅基于主机应用程序检查的经典软件许可和保护机制可能会被用户可控环境中的补丁攻击、仿真攻击和重放攻击所绕过。本文介绍了一种在ESP32-S3平台上实现的自适应硬件密钥，该密钥将敏感决策和加密操作从主机应用程序中分离到专用设备中。该解决方案结合了设备级信任根（安全启动和闪存加密）、PKI可验证的身份（X.509公钥基础设施证书和数字签名作为所有权证明）、分层密钥派生（以避免使用静态密钥），以及为所有关键数据交换建立经过身份验证的加密会话。用户访问受到三因素认证（PIN码、TOTP随机密码和USB物理存在验证）以及“适配器内代码”机制的约束，其中重要逻辑在适配器上运行，而应用程序接收的是有效期有限的令牌。实验验证表明，该方案能够实现正确的配置、安全会话建立、抗暴力攻击，并通过带防回滚功能的OTA（无线更新）提供加密备份和恢复。构建报告显示闪存分配合理，DIRAM（数据/指令RAM）空间充足，而IRAM（指令RAM）饱和度（99.99%）反映了ESP32-S3统一内存模型的正常行为，而非容量限制。

**1. 引言**
近年来，软件应用程序的分发和经济效益开发主要沿着两个方向进行：许可模式的扩展（订阅、按设备/用户许可）以及向云和物联网生态系统的迁移。与此同时，在日益面临网络安全风险的数字环境中，保护软件知识产权变得尤为重要，尤其是在依赖授权应用程序、工业解决方案或专有算法的行业。在这一领域，软件盗版、许可证克隆以及对硬件保护设备的物理攻击仍在全球范围内造成重大经济损失。为应对这些挑战，常用的解决方案之一是硬件适配器（物理密钥），它们实现了认证机制和/或加密密钥存储，以确保应用程序仅在设备存在的情况下才能运行。

然而，当前的技术发展（虚拟化、容器化、分布式执行、多因素认证和零信任架构的采用）使得基于传统适配器的解决方案在现代环境中越来越难以集成和管理[1,2]。此外，用户追求最简单的使用体验，而开发者则需要可扩展、易于维护的机制，尤其是在运营层面。
相关文献强调了这些设备集成程度的差异：在某些实现中，适配器仅作为物理存在验证元素（持有令牌）使用，不具备扩展的加密处理能力、高级认证或执行保护机制；而在其他实现中，适配器被视为安全协议和应用程序保护架构的主动组件。
在对确保信息传输和信息服务安全的相关研究进行彻底分析后，注意到采用对称密钥密码系统与公钥密钥系统相结合的方法来保护数据文件，并用于安全传输会话密钥，从而明确划分了处理会话密钥管理和用户权限的硬件密钥与处理数据处理的计算机之间的角色[3,4]。

另一个重要方向是针对认证和完整性的保护，通过软件-设备相互认证、使用会话随机数、动态密码和完整性代码（MAC）以及通信加密；这些方法表现出良好的抗重放、伪造和数据篡改能力，并对性能影响最小[5,6,7,8]。这些机制的扩展使适配器的作用超越了应用程序级别的验证，扩展到系统启动时或操作系统加载之前的权限验证，包括采用生物特征认证和BIOS级验证的解决方案，结果表明通过将访问控制提前到启动过程早期可以增强安全性[9]。

当前技术领域的另一个相关方向是应用程序在执行过程中的保护以及抵抗分析/逆向工程的能力。在这一领域，提出了结合静态保护（压缩、加密、代码混淆）与动态保护（运行时监控、时间戳、反调试过程）的解决方案，并引入了软件与物理密钥之间的双向认证。研究结果表明，这些机制提供了高水平的保护，但也会带来性能成本，尤其是在文件大小增大时解密时间显著增加[9]。同时，实验研究表明，仅检查适配器的存在并不足以提供坚实的保护；仅基于适配器API调用的实现可以通过识别并删除这些调用来绕过，而采用模糊化或封装软件的技术虽然增加了分析难度，但并未完全消除风险[10,11]。这些观察结果突出了将适配器作为简单存在验证设备与作为主动加密元素使用之间的区别，后者直接集成到认证和执行保护协议中。

另有研究[12,13,14]提出了使用先进的非线性动态系统（包括具有双忆阻器的3D立方体映射、忆阻Rulkov神经元和非退化3D超混沌系统）来保护多媒体数据的方法。研究表明，这些数学模型能够生成高熵序列，为图像和视频片段的加密提供高效且稳健的算法。
文献还介绍了安全组密钥分发、云环境和工业HMI/SCADA应用中的安全数据访问扩展。在组通信中，将USB安全与Shamir秘密共享和Lagrange插值结合使用，提高了会话密钥的保护能力和对内部及外部攻击的抵抗力[15]。在云环境中，数字签名、PIN码和失败尝试后的锁定机制的集成已被证明对认证和灵活的访问管理有效[16]。在工业环境中，基于硬件密钥、双因素认证和自动化凭证管理的解决方案显示出更强的抗攻击能力和减少人为错误的效果[17]。

基于这些结果，人们需要一种结合信任根优势与现代管理要求、安全更新、恢复机制和自适应安全策略的硬件保护方案[18]。实际上，向分布式服务和基础设施的过渡也改变了信任的授予方式。应用程序不再只需在本地检查简单的许可条件，因为环境可能被复制、分析或虚拟化。在零信任范式中，不对用户、设备或网络进行隐含信任；相反，访问受到反复验证和明确定义的策略的约束[19]。多因素认证已成为减少静态密码相关风险的常用机制，通过结合多种类型的因素（知识、持有和适当的时间因素）。

在软件保护项目中，持有因素可以由物理设备表示，但它必须集成到一个包括用户认证、设备验证和完整性验证的连贯流程中，以确保解决方案能够抵御现代攻击、克隆或仿真场景。另一个限制是应用与适配器之间的协议如果可预测性强到足以被复制，则可能导致问题。即使挑战-响应协议使用了加密技术，如果签名数据定义不明确、缺少强设备身份证明、缺乏防重放保护，以及未能将操作绑定到经过身份验证的会话中，也可能使仿真、重放或虚拟环境中的入侵成为可能。实际上，虚拟化和远程执行使得适配器集成更加困难，一些商业解决方案专门针对这些风险进行了设计[20]。

此外，保护方案的生命周期并不在安装时结束。长期来看，会出现诸如固件更新、防止降级到脆弱版本以及在发生错误或入侵尝试后恢复的能力等运营需求。指南如NIST SP 800-193[18]讨论了固件弹性原则，指出系统应能够防止损坏、检测损坏并以受控方式恢复。在硬件密钥中，这些需求转化为安全启动、闪存内容保护、回滚策略和明确的恢复程序等机制。

因此，本项目旨在基于ESP32-S3开发一种硬件密钥，该密钥能够支持通过涵盖设备认证和用户认证的完整流程来保护软件应用程序，并维护安全会话。在功能层面，系统必须能够建立加密和经过身份验证的通信通道（例如，使用AES-GCM等AEAD模式），强制实施多因素用户认证，并为应用程序提供可验证的结果（令牌）以解锁受保护的功能。从密码学和身份管理的角度来看，目标是设备具有可验证的身份，通过基于X.509证书的PKI基础设施和CRL进行的撤销来实现，以便失效或被移除的适配器可以被视为无效[21]。此外，该项目旨在通过使用分层密钥派生（HKDF/HMAC）根据用途分离密钥，减少潜在暴露的影响[22]。用户认证基于知识因素（PIN码）、时间因素（TOTP）和持有因素（通过USB的物理存在），符合TOTP标准的原则[23]。

**2. 材料与方法**
**2.1. 概述和威胁模型**
所提出的解决方案构建为一个分布式系统，其中应用程序受保护功能的访问决策不再仅由PC上的软件决定，而是由基于ESP32-S3的专用硬件设备（适配器）执行。该架构旨在尽可能清晰地划分职责：PC应用程序管理用户界面并使用安全结果（令牌），而适配器管理加密身份、密钥派生、会话通道建立以及不应在应用程序内部暴露的敏感逻辑的执行。这样，即使应用程序被攻击者修改，也必须与设备进行加密对话才能生成有效结果。换句话说，该架构将验证从易于绕过的本地检查转移到一种机制，该机制强制应用程序从 designed to resist cloning and emulation 的外部元素反复请求证明和响应。此外，由于系统会协商会话，因此结果不是固定值，而是与时间和会话上下文（随机数、计数器、过期时间）相关联，这大大降低了重放攻击的效果。

概念上，该架构结合了三个相互补充的主要思想。第一个是设备上存在信任根，通过安全启动机制和闪存内容保护来支持，确保适配器上的固件是真实的且无法被读取或修改。对于ESP32-S3，安全启动v2使用RSA-PSS对引导加载程序和应用程序进行加密验证[24]，而闪存加密则保护闪存内容，使物理读取闪存不足以恢复代码和数据[25]。通过这种组合，固件成为可信组件：只有在真实的情况下才能启动（完整性+真实性），并在现实存储攻击条件下保持机密性。

第二个思想是基于公钥基础设施建立设备身份，通过数字证书实现。这样，应用程序可以区分真实适配器和仿真适配器，并可以使用RFC 5280中定义的X.509证书模板和CRL证书撤销列表撤销所有被破坏的设备。实际上，设备拥有自己的私钥，并在建立握手时生成一个签名，证明其拥有该密钥。然后主机使用证书中的公钥检查签名，并借助受信任的认证机构进行验证。此外，证书可以在不需要生成新的密钥对的情况下进行更新，因此私钥将保留在加密设备上而不会被替换。第三个想法是从简单的硬件设备存在验证转向更强的访问机制，例如三因素用户认证（PIN码、一次性密码生成器和物理存在性），并应用基于用户行为的自适应策略。为了保护通信的保密性和完整性，整个流程通过使用NIST SP 800-38D [21]推荐的AES-GCM算法加密的会话通道进行。图1显示了系统的总体架构，分为四个部分：运行应用程序的用户计算机、运行AHSK（自适应硬件安全密钥）固件的ESP32 S3-GEEK加密设备、公钥基础设施区域以及设备管理区域。

2.2. 实施中使用的硬件设备及其选择理由
在本研究中，使用了Waveshare ESP32-S3-GEEK开发板（图2），因为它以紧凑的形态提供了足够的资源来实现具有加密功能的硬件密钥和设备级安全机制。该开发板基于ESP32-S3微控制器构建，这是一种适合需要处理性能以及支持安全特性和与主机系统通信的应用程序的现代SoC。ESP32-S3-GEEK包括外部存储器（Flash和PSRAM），这使得认证逻辑、通信协议和日志记录机制能够在没有资源限制的情况下运行，而集成的USB接口便于将设备直接连接到PC上使用。从安全角度来看，ESP32-S3系列非常适合用作加密设备，因为它通过Secure Boot v2支持信任根机制，该机制使用签名方案（RSA-PSS）验证引导加载程序和应用程序，从而减少了运行被修改或未签名固件的风险。可以使用两种开发工具对其进行编程：Arduino和MicroPython v1.28或ESP-IDF开发框架。使用Arduino或MicroPython进行开发具有灵活性且易于操作，但会限制对设备的控制程度，这可能使其无法充分发挥其能力。此外，该平台允许高度定制，因为开发者可以完全控制硬件方面（固件和安全机制配置）和软件方面（主机应用程序和通信协议），这与通常预定义了功能和安全策略的封闭商业解决方案不同。

固件是用C/C++语言开发的，并最大限度地集成了平台的安全机制以及ESP-IDF生态系统中可用的加密库（mbedTLS及相关组件）。在接下来的章节中，将逐步介绍实现过程，以清晰地展示平台的安全机制与系统操作流程之间的关系。

2.3. 系统实现
2.3.1. 第一阶段——信任根、PKI身份和密钥层次结构
系统的运行基于这样一个理念：加密设备必须是一个可信的元素，只能运行授权的固件，并且能够以抵御克隆或提取尝试的方式保护秘密。在实现过程中（图3），ESP32-S3设备的引导过程受到平台硬件机制的保护。每次启动时，都会运行固件验证过程，以确保之前被修改的版本无法在未被检测到的情况下执行。如果固件通过验证，接下来的步骤是对闪存进行加密，这意味着如果有人试图直接读取内存的内容，所获得的数据既不能被解释也不能被重新使用。当首次使用加密设备时，它会进入一种受控的配置模式，在此模式下创建其加密身份。该设备已经具有一个唯一的硬件指纹，由存储在eFuse中的MAC（媒体访问控制）地址表示。此信息用作基础标识符，使得设备在系统中能够唯一关联。在配置过程中，加密设备在secp256r1曲线上使用硬件随机数生成器内部生成一个ECC（椭圆曲线密码学）密钥对[26,27]。生成的私钥成为设备的身份密钥，并保存在受闪存加密保护的内部存储器中；公钥用于颁发数字证书。为了向PC应用程序证明设备的真实性，加密设备会生成一个包含公钥和识别元数据（如从MAC派生的序列号）的CSR（证书签名请求）。CSR被传输到制造商的配置环境中，由制造商控制的认证机构对其进行签名。结果，设备的X.509证书（称为“Cert_dev”）被获得并安装在加密设备上。证书本身不是秘密，可以在需要时传输给主机，但关联的私钥仅保留在加密设备上，永远不会离开设备。

在确定身份后，系统解决了密钥管理的关键问题，即避免将静态密钥存储在内存中。实现基于一种密钥派生机制，该机制从一个存储在eFuse中的可信密钥开始，该密钥无法被提取，只能通过HMAC（键控哈希消息认证码）哈希函数访问。派生过程继续集成经过验证的固件和存储在eFuse中的防回滚计数器，以确保密钥的保护也依赖于固件的状态。因此，如果固件被恶意修改，派生的密钥将不再有效，任何尝试执行敏感操作的行为都将被阻止。同时，系统根据密钥的用途对其进行分类，以避免将同一密钥用于所有操作。另一个非常重要的方面是，在启动新会话时，会根据当时创建的新随机值生成临时会话密钥。这样，即使会话被破坏，当设备重新启动或密钥过期时，这些密钥也不能被重新使用。

2.3.2. 第二阶段——三因素认证（3FA）
在完成设备识别阶段后，系统还需要验证用户身份；因此构建了三因素认证阶段（图4）：PIN码验证、TOTP代码验证以及通过通用串行总线接口确认设备的物理存在性。第一要素是只有用户知道的PIN码。在初始配置过程中，PIN码与存储在安全位置的盐值一起通过密钥派生函数算法进行处理。随后，当用户希望进行认证时，他输入最初选择的PIN码，处理后的结果与之前存储的值进行比较，从而减少侧信道攻击的风险。如果输入的PIN码不正确，失败计数器会增加，并应用渐进式延迟，以防止重复连接尝试。失败次数越多，风险评分越高，系统状态将从正常状态转变为SUSPECT或LOCKDOWN状态。如果输入的PIN码有效，系统将继续进行第二因素认证——TOTP验证。TOTP代码是基于专用密钥和设备内部RTC（实时时钟）提供的当前时间或可能通过NTP（网络时间协议）同步计算得出的。

第三要素是通过物理USB连接确认ESP32 S3-GEEK设备的物理存在性，这代表了拥有权。加密设备确认它确实连接到计算机，并且数据交换是通过预定的通道进行的，从而减少了模拟远程通信被接受的可能性。

2.3.3. 第三阶段——加密设备中的代码和令牌获取
图5所示的第三阶段是所提出架构的核心，因为它将关键的执行和决策元素移至加密设备中，从而消除了绕过或修改应用程序功能的尝试。与信息保护领域的研究工作中应用程序在本地决定是否可以启动的解决方案不同，在本研究工作中，应用程序更像是根据ESP32 S3-GEEK设备的决策来启动的客户端。

2.3.4. 第四阶段——异常检测
为了避免系统仅对成功/失败做出反应而未注意到重复的可疑行为，系统包含了一个风险评分引擎和一套自适应策略（如图6所示）。加密设备持续收集相关操作信号，如失败认证尝试次数、OTP请求频率、执行请求速率以及主机上下文的变化。这些信号通过基于标准化特征的二元逻辑回归评分函数转换为风险评分。因此，系统可以判断操作是否在正常参数范围内，或者是否需要采取相应措施。只要三因素认证有效且受保护的会话处于活动状态，加密设备就会保持NORMAL操作状态。如果发生多次失败认证尝试，风险评分超过中间阈值，设备将切换到SUSPECT操作状态。SUSPECT状态涉及应用受控的限制措施，通过引入额外的等待时间来减少认证尝试的频率。这样，自动攻击的可能性被最小化。如果即使在SUSPECT状态下连接尝试次数增加，风险评分也会达到最大阈值，设备将切换到LOCKDOWN状态。在LOCKDOWN状态下，执行操作被拒绝，并且设备可以擦除临时会话密钥以限制任何重用尝试。向用户显示明确的状态信息，恢复到正常操作的唯一方法是触发恢复流程。

2.3.5. 第五阶段——混合管理：NTP、加密备份和签名OTA更新
最后阶段（图7）为系统配备了长期运行和现实世界场景所需的机制。首先，TOTP依赖于时间，而内部时钟可能会发生漂移。因此，加密设备会在连接可用时定期使用NTP同步其时钟。在无互联网连接的情况下，系统继续基于RTC运行，一旦连接恢复，再进行同步。其次，通过加密备份机制解决了设备丢失的问题。ESP32-S3-GEEK创建一个blob文件，其中存储了在设备丢失或被盗情况下恢复设备所需的信息。该解决方案在本地进行了加密处理，以确保内容无法被访问，然后才能被发送到本地服务器或MQTT（消息队列遥测传输）代理。如果用户丢失了设备，他们可以收到一个新的设备，在完成三因素认证后，存储在微存储设备（blob）中的信息会被下载并恢复到新设备上。这样，即使硬件设备丢失，也不会导致许可证的永久丢失，从而在安全性和可用性之间保持了平衡。为了最小化漏洞风险并进行改进，会定期执行固件更新。更新通过OTA（空中下载）方式进行分发，并且每个固件版本都使用数字签名进行验证。如果签名有效，新的固件版本将成功安装，并且防回滚计数器也会更新，以防止恢复到可能存在漏洞的旧固件版本。相反，如果签名被确认无效，固件版本将不会被接受。这一步加强了密钥与固件指纹之间的关联，确保了长期的安全性。

3. 项目的开发过程遵循一系列明确定义的阶段，每个阶段都会确认获得的结果足够稳定，可以继续进行下一步。如图8所示，首先定义需求，然后逐步实现功能。接下来进入“构建”阶段，验证项目是否正确编译。如果构建成功，下一步是“刷新”（Flash），即将固件上传到ESP32上，刷新成功后进入测试阶段以验证其正常运行。图8显示了在ESP-IDF开发环境中的系统开发过程。

3.1. 主机应用程序集成与安全会话初始化
图9显示了ESP32-S3上的加密操作处理时间以及从应用程序请求解锁到dongle返回令牌的端到端延迟。所有加密操作都在53毫秒以内完成，低于Jakob Nielsen在《可用性工程》[28]中设定的0.1秒的人类感知阈值。整个会话中最大的延迟是用户获取并输入TOTP代码所需的时间（大约五到十秒），这与硬件平台无关。从主机应用程序的角度来看，每个dongle的响应都在一个视频帧内（<60毫秒），确保了无缝集成且没有可感知的延迟。AES-128-GCM通道加密每次往返命令仅增加0.7毫秒的开销，与USB串行传输的延迟相比可以忽略不计。图9显示了ESP32-S3上的加密操作延迟。执行时间是在ESP32-S3 GEEK开发板上使用“esp_timer_get_time()”函数直接测量的。每个操作重复进行了30次，每次都在一个新的测量会话中，显示的值代表这些测量结果的平均值。所有操作的标准偏差都非常小，均低于平均值的2%，表明在稳定操作条件下的变化很小。测试中没有任何异常值超过平均值±3σ。

测试是在运行Windows 11（第13代Intel Core i9处理器和16 GB RAM）的主机上进行的，通过USB串行连接以115200波特率连接到ESP32-S3 GEEK。固件是在Release模式下编译的（CONFIGCompiler_OPTIMIZATION=y），使用ESP-IDF v5.3，ESP32-S3以240 MHz运行，并启用了AES和SHA硬件加速器。端到端延迟是使用Python 3.14.4中的“time.perf_counter()”函数从发送命令到处理响应期间测量的。

3.2. TOTP配置与成功的三因素认证（3FA）
生成第三认证因素的TOTP密钥及其与Google Authenticator的集成可以在图10中通过专用配置窗口观察到。用户会收到一个从otpauth类型URI生成的QR码，以及Base32格式的密钥，因此可以通过扫描或手动输入来进行注册。这一步仅在执行首次使用时进行一次。图10显示了TOTP注册步骤：使用otpauth URI（QR）和Base32表示法配置新密钥。配置完成后界面转换——密码区域的文本从“输入初始密码（配置中）”变为“输入先前设置的密码”（图11）——确认应用程序检测到了设备状态并自动调整了显示给用户的消息，表明密码已经设置好，现在将作为固定的认证因素使用。日志显示了消息序列，指示了密钥生成、设置窗口的显示、密码验证，以及基于TOTP的认证完成，最终显示“UNLOCK OK (3FA)”的成功消息。图11显示了配置完成后的界面转换和成功的认证（PASS + TOTP），以“UNLOCK OK (3FA)”结束。

3.3. 负面测试：防暴力攻击和锁定行为
图12展示了负面测试场景以及系统在面对多次不成功尝试时的行为，无论是错误输入的密码还是错误的OTP。可以看出，当密码或OTP代码被连续错误输入时，设备会运行锁定策略一段时间，从而防止暴力攻击。触发此过程后，任何后续尝试验证密码或OTP代码的尝试都会被拒绝，中断了认证流程，减少了攻击者的继续尝试次数。图12显示了防暴力攻击行为，以及随着风险评分增加的延迟。风险是使用二元逻辑线性回归计算的。

选择这种解决方案考虑了特定于所提出的硬件配置的约束，即缺乏实施机器学习模型所需的训练数据集以及ESP32-S3的计算预算有限。权重值是通过专家知识手动分配的，使用了一种满足约束的过程。因此，定义了四条操作规则：(C1) 完全认证的合法用户的风险必须<0.25；(C2) 连续三次认证失败必须导致分数超过怀疑阈值（0.60）；(C3) 短时间内大量命令，特别是脚本自动化产生的命令，至少应标记为可疑；(C4) 在认证过程中不应将pass_pending状态分类为可疑，以避免合法使用情况下的误报。调整权重直到同时满足所有四条规则，然后通过表1中的十个代表性场景进行验证。表1列出了风险评估场景。每个RBLS决策可以通过利用八个特征（表2）来进行审计，这些特征涵盖了威胁模型中可能的攻击向量：暴力猜测密码（fail_norm）、脚本自动执行的动作（cmd_rate）、重复的滥用行为（abuse）、可能被泄露的会话（pass_pend）以及定义设备操作和有效状态的指标（provisioned、time_set和uptime）。表2显示了不同验证场景下的特征权重和值。与特征相关的权重设置如下：unlock = ?1.40，provisioned = ?1.10，time_set = ?1.10，fail_norm = +1.80，pass_pend = +0.80，cmd_rate = +2.20，abuse = +2.80，uptime = +0.10。最高的正权重被分配给了abuse变量，因为它能够捕捉随时间重复出现的可疑行为。相比之下，uptime的权重较低，因为它在风险评估中的相关性较低。

3.4. 资源占用：Flash/DIRAM/IRAM利用率
关于内存消耗，表3显示所提出的解决方案的实现符合平台的硬件限制，并在其范围内正常运行。无论是代码还是常量数据，Flash的使用都保持平衡，而在DIRAM级别有足够的余地用于未来的扩展，表明从资源角度来看，实现的功能是以合理的方式集成的。同时，分析表明IRAM几乎被完全利用。ESP-IDF报告的99.99% IRAM利用率并不是内存不足，而是ESP32-S3架构的正常行为。与原始ESP32不同，ESP32-S3没有独立于数据内存的专用IRAM银行，所有内部SRAM都是统一的，可以用于数据和可执行代码。idf.py报告的IRAM段并不是一个固定的内存区域，而是由链接器根据需要从RAM中运行的代码量自动计算的，例如IRAM_ATTR函数和中断例程。因此，这个区域通常几乎完全被占用。

在AHSK固件中，应用程序仅通过uptime_sec()和usb_write()函数占用该段的48字节。剩余的15,308字节来自ESP-IDF的强制组件，如FreeRTOS调度器、HAL、中断层和Xtensa异常向量，这些组件不能移动到闪存而不影响操作安全性。此外，某些可选的设备功能可以被禁用以进一步减少内存消耗，而不影响当前实现的功能。

4. 讨论
所实现的解决方案基于“深度防御”的原则，从现代攻击可以针对“信任链”中的多个环节这一理念出发。解决方案不仅仅依赖于单一的保护屏障，而是整合了一组相关的控制措施，以解决特定的漏洞——从主机环境的不稳定性和通信渠道对重放攻击的暴露，到嵌入式设备上的二进制完整性和数据保密性。这种分层的方法提高了系统的弹性，确保单个组件的漏洞不会导致整个安全机制的崩溃。

以现实世界中的威胁为参考，该架构展示了攻击在实践中的表现形式。通过基于PKI的身份证明和拥有证明签名，减轻了dongle模拟（欺骗）的影响，因此简单的协议模拟器在没有设备私钥的情况下无法复制有效的加密证明。通过将敏感的授权逻辑移到设备中（Code-in-Dongle概念），解决了主机打补丁/绕过（篡改）的问题：主机不再基于可拦截的检查“本地决策”，而是请求一个受保护的计算并接收一个与认证上下文和策略相关联的受限结果（令牌）。通过具有显式防重放逻辑的AEAD-保护（带关联数据的认证加密）会话（例如，序列/TTL），减轻了重放和消息注入的风险。通过结合3FA、速率限制和锁定行为，减轻了对PIN/TOTP的在线猜测和滥用（DoS）的攻击。通过消除静态密钥并使用基于设备信任的密钥分级机制，减少了通过闪存读出泄露秘密的风险。通过安全启动和抗回滚使用eFuse计数器，减轻了固件降级的风险。最后，通过使用RTC时钟和NTP同步以及±1步的余量，解决了时间操控问题，因为TOTP机制直接依赖于设备的内部时钟，从 ??测试阶段开始，时间就是一个挑战。在没有自动同步的情况下，正确的OTP代码会被自动拒绝。为了解决这个问题，引入了SETTIME命令来自动设置时间，基于主机系统时间，从而稳定了认证过程并消除了不合理的拒绝。尽管依赖于可能被操控的主机系统时钟，系统存在一定的弱点，但通过多因素认证，这个问题得到了缓解。

除了安全机制外，系统的开发还包括解决硬件和软件集成之间的技术问题，以及选定平台带来的限制。最困难的方面之一是稳定串行通信，以及正确同步应用程序的内部进程和配置等待时间限制。随着新功能的逐步集成，出现了Espressif IoT开发框架环境特有的挑战，重点是分区表和分配给不同部分的内存大小。新增组件的加入导致二进制文件的大小和存储需求增加，因此需要多次重新配置分区表，以避免编译错误，并确保所有实现的功能都有足够的存储空间。同时，这也暴露了一些在后续开发中需要考虑的限制因素。构建阶段的结果表明，尽管几乎被完全使用的IRAM（内部随机存取存储器）目前不会影响系统运行，属于正常现象，但当需要从RAM执行新功能时，这可能会成为一个问题。因此，未来版本将需要对某些非必需的设备功能进行优化或禁用（例如，减少指令缓存）。需要注意的是，本文中呈现的评估结果仅代表了原型级别的验证，并非针对真实攻击者的全面安全评估。对于高级物理攻击（包括侧信道分析、差分功耗分析、电磁辐射分析、错误注入以及芯片级数据提取）的抵御能力，目前尚未通过实验进行验证，这些仍然是未来的研究方向。