LAsset：一种用于片上系统（SoC）验证的LLM辅助安全资产识别框架

大家读完觉得有帮助记得关注和点赞！！！

摘要

现代片上系统（SoC）和IP设计的日益复杂使得安全保障变得越来越困难。硬件设计的前硅片安全验证的一个基本步骤是安全资产的识别，因为它深刻影响着下游的安全验证任务，例如威胁建模、安全属性生成和漏洞检测。传统上，资产由安全专家手动确定，需要大量的时间和专业知识。为了应对这一挑战，我们提出了LAsset，这是一个新颖的自动化框架，利用大型语言模型（LLM）从硬件设计规范和寄存器传输级（RTL）描述中识别安全资产。该框架执行结构和语义分析，以识别模块内的主要和次要资产，并推导模块间关系，从而在设计层面系统地表征安全依赖性。实验结果表明，所提出的框架实现了高分类准确率，在SoC设计中召回率高达90%，在IP设计中召回率高达93%。资产识别的这种自动化显著减少了手动开销，并为安全的硬件开发支持了一条可扩展的前进道路。

关键词：硬件安全，资产识别，大型语言模型，SoC验证，安全验证，LLM辅助设计

I 引言

现代片上系统（SoC）设计已发展成为高度复杂的系统，将处理器、内存、总线和各种外设集成到单个芯片上 [rowen2008engineering, Chakravarthi2023]。虽然这种高度集成提高了性能和成本效益，但同时也通过显著扩大攻击面引入了新的安全挑战 [8000621, kocher2011complexity]。与此同时，日益增长的市场压力常常迫使开发周期缩短，留给全面的前硅片安全验证的空间有限。因此，许多漏洞直到后硅片阶段才被发现 [9116483, pearce2023high]，而在该阶段进行缓解的资源消耗要大得多 [mitra2010post]。为确保强有力的保护，在设计周期中尽早解决安全问题至关重要 [arm2009arm]。早期识别安全关键组件不仅能降低后期流程中高昂修复成本的风险，还能建立对整体设计可信度的信心。

图1：硬件设计中的安全验证流程

在可靠和安全的硬件系统设计中，早期准确识别安全资产为后续任务（如图1所示的威胁建模、测试计划生成、安全验证和对策开发）奠定了基础 [portillo2016building, slpsk2023protects, contreras2017security, peeters2015soc]。正如电子设计集成安全注解（SA-EDI）标准 [b4] 所强调的，资产识别不仅是硬件系统中实现可持续安全保证的第一步，而且可以说是最重要的步骤。尽管其重要性得到广泛认可，但资产识别传统上仍然是基于行业专业知识的 manual 过程 [meza2023information, 7880823]，这不仅效率低下且容易出错，而且难以扩展到大型SoC设计。最近只有少数工作探索了资产识别，而且这些工作通常只在有限范围内考虑它。例如，SAIF工具 [farzana2021saif] 试图通过分析漏洞和威胁模型来识别硬件设计中的资产，而LASHED流程 [ahmad2025lashed] 则利用常见弱点枚举（CWE）漏洞来实现相同目的。然而，这两种方法都是在分析了设计漏洞之后才识别资产，而资产识别本应是安全验证流程中的首要步骤，如图1所示。类似地，[nath2025toward] 中的方法严重依赖RTL信号和寄存器命名约定，使用针对已知安全关键标识符的模式匹配；因此，它无法推广到不遵循此类约定的设计，并且无法为检测到的元素为何应被视为资产提供理由。

受当今资产识别方法中面临的挑战的启发，我们提出了以下研究问题（RQs）：

RQ 1：我们如何确定给定硬件设计架构中哪些元素被视为安全相关资产？

RQ 2：我们能否开发一种端到端的自动化方法，用于可靠地识别跨不同SoC和IP设计的安全资产？

RQ 3：我们如何验证一个被识别出的资产确实是资产？

图2：AES加密设计中的资产类型概述

在研究了上述问题的答案后，我们提出了LAsset，这是有史以来第一个LLM辅助的自动化框架，用于在SoC和IP设计中进行全面的安全资产识别，其动机是LLM辅助框架在硬件安全验证中的成功 [sahaaccess, saha2025sv, socurellm, 11022932, bugwhisperer, saha2024empowering]。LAsset利用SA-EDI标准和IEEE P3164指南，通过LLM进行资产的初步识别。它通过将资产列表与CWE漏洞数据库进行映射来进一步验证和优化资产列表，从而确保其可信度。总之，我们工作的关键贡献如下：

• 新颖性：在本文中，我们提出了LAsset，这是第一个利用LLM从SoC和IP设计中自动识别安全资产的框架。

• 鲁棒性和多功能性：LAsset可使用规范与RTL组合输入或仅RTL输入进行操作，支持Verilog、SystemVerilog和VHDL，并适用于IP和SoC设计，确保了广泛的适用性。

• 全面性：除了资产识别，LAsset还将每个资产与威胁建模细节和安全理由关联起来，为下游验证任务提供可操作的上下文。

• 可信度：一个优化阶段通过交叉引用CWE数据库和应用自一致性检查来验证每个资产，产生一个高保真度的资产列表，在实际设计上召回率高达93%。

本文的其余部分组织如下。第II节简要介绍了背景和基本原理。第III节描述了所提出的方法。实验结果和比较分析在第IV节中给出，最后在第V节总结全文。

II 背景

II-A 安全资产

根据定义，SoC中的安全资产是任何其保护对于维护系统机密性、完整性或可用性（CIA）至关重要的硬件组件或数据元素。安全资产可以根据两个标准进行分类：（i）抽象级别和（ii）依赖性。根据IEEE P3164 [b5]，根据设计的抽象级别，安全资产可以分为概念性资产和结构性资产。

• 概念性资产：概念性资产是与系统用例流程相关的高级信息元素。例如，如图2所示，在AES加密引擎中，加密密钥是一个概念性资产，因为无论其位于设计中的何处，都必须保护其机密性。

• 结构性资产：结构性资产是物理存储或承载概念性资产的硬件元素。这些包括处理或存储概念性资产所涉及的寄存器、缓冲区、锁存器或门电路。在同一个AES引擎中，密钥寄存器是一个结构性资产，因为它直接存储加密密钥值。

此外，根据其在潜在安全漏洞中的依赖作用，安全资产可以分为主要资产和次要资产 [farzana2021saif]。

• 主要资产：主要资产是作为攻击直接目标的组件。继续AES的例子，加密密钥本身是主要资产，因为攻击者试图直接破坏它。

• 次要资产：次要资产是与主要资产交互或促进主要资产暴露的组件。虽然它们不直接关键，但它们的破坏可能通过检索相关联的主要资产来削弱SoC的整体安全性。例如，系统总线、外设端口以及承载主要资产数据（全部或部分）的内部信号/寄存器。在AES中，诸如加密/解密引擎和输出缓冲区等元素符合次要资产的条件，因为尽管它们不是最终目标，但它们的破坏可能间接暴露加密密钥。

图3：SA-EDI IP包 [b4]

II-B 电子设计集成安全注解（SA-EDI）标准

图4：所提出的用于安全资产识别的LAsset框架概述

SA-EDI标准提供了在将硬件IP集成到SoC中时记录其安全相关问题的规范指南。如图3所示，安全相关信息——包括资产定义、安全弱点数据库、端口和参数相关元素以及攻击点安全目标（APSO）——与IP设计一起被捕获，并以JSON格式表示在SA-EDI对象中。该标准强调，第一步是识别设计中需要根据机密性、完整性和可用性（CIA）等安全目标进行保护的概念性资产，以及可能危害这些目标的相关结构性元素（例如，端口、参数）。为了支持这一过程，该标准参考了IEEE P3164白皮书 [b5]，该白皮书介绍了概念和结构分析（CSA）方法。CSA首先识别与CIA三要素相关的概念性资产，然后将它们映射到其相应的RTL表示，即传递给SA-EDI中下一个资产定义对象的结构性资产。该方法论强调了概念性资产——需要保护的"什么"，和结构性资产——体现该资产的设计中的"何处"之间的区别，确保IP开发者在将IP集成到更大的SoC设计之前全面记录安全关键资产。因此，为了解决第I节中的RQ1，我们基于SA-EDI指南中提供的见解进行构建。

III LAsset框架

识别第I节中提到的RQ1-RQ3所提出的安全资产需要一个具有几个关键特性的解决方案。遵循SA-EDI首先基于CIA目标定义概念性资产，然后将其映射到结构性设计元素的原则，它必须理解自然语言规范和RTL，以将概念性资产映射到其结构性对应物；推理设计语义、层次结构和模块间依赖性，以泛化到不同的SoC和IP设计；并提供可验证的、符合标准的理由以确保已识别资产的可信度。这样的任务需要语义理解、上下文推理、模块化任务分解和可解释的决策能力，这些是传统基于规则的方法所缺乏的。LLM天生提供这些特性：它们可以联合解释规范和RTL，从上下文而非命名启发式中推断安全相关性，被组织成专门的智能体用于子任务，如规范分析、RTL分析、资产映射和基于CWE的合理化，并生成人类可读的理由并进行自一致性检查。利用这些优势，我们将LAsset设计为一个由LLM驱动的智能体框架，能够执行自动化、可扩展且可靠的资产识别。

如图4所示，LAsset通过三个顺序执行的智能体进行操作：（i）输入预处理，解析可用的规范和RTL资源，并在基于SA-EDI的概念-结构资产模型下对齐它们；（ii）资产生成，专门的LLM分析预处理后的输入以识别候选概念性资产并将其映射到它们的结构性对应物；以及（iii）资产优化，通过交叉引用CWE数据库和自一致性检查来验证和合理化每个候选资产，产生最终的、符合标准的资产列表。这种模块化的智能体设计使LAsset能够跨不同的SoC和IP设计执行自动化、可扩展和可验证的安全资产识别。

III-A 输入预处理

在LAsset框架的两个输入之间，RTL库提供了内部功能以及信息流跟踪，而相应的规范（Spec.）主要概述了模块在更广泛SoC架构中的集成，以自然语言提供额外的设计见解和接口细节。因此，我们从设计的安全关注点角度预处理输入，以便LLM能更好地理解真实的安全上下文，而不会因token限制和受限的长上下文保留而产生幻觉。输入预处理智能体执行以下三个主要任务，如算法1（第3-4行）所示：

III-A1 设计模块提取

在此任务中，利用LLM的推理来（i）修剪不相关的模块和（ii）从RTL库中提取的模块名称中选择安全关键模块。例如，在NEORV32 SoC中，neorv32_application_imageIP模块不被视为安全关键模块，因此在此任务中被排除，而安全敏感的neorv32_cpu_pmpIP模块等被保留。此任务很重要，因为它通过在一开始就减少安全不相关的设计开销，使流程更加资源高效（成本和时间）。

III-A2 模块化规范摘要

此任务建立在基于检索增强生成（RAG）的上下文学习模型之上，其中SoC级设计规范被用作知识源。对于每个安全相关模块，用户引导的查询通过LLM增强提示以生成技术摘要，该摘要包含模块内部以及更广泛SoC上下文中跨模块的所有安全相关信息。总体而言，该摘要充当资产生成智能体相应模块的简明规范输入。

III-A3 模块化RTL解析

为了提取设计元素，我们实现了两个基于LLM的解析器：一个用于I/O端口，另一个用于内部信号/寄存器，以及它们在模块级别的类型和功能。这样做是为了确保LLM不会忽略任何已解析的设计元素用于资产决策，从而减少假阴性的机会。

III-B 资产生成

使用技术摘要和RTL作为输入，我们采用少样本上下文学习范式进行资产生成。我们定义了硬件安全上下文，并辅以与CIA安全目标相关的问答。为了进一步说明该任务，我们提供了几个案例研究，以广泛认可的硬件IP块为特色，例如AES、GPIO、高斯噪声生成器，每个都附有资产列表和相应的理由，解释为什么某些设计元素是安全资产而其他不是。通过这种逐步的方法，系统性地引导LLM学习并识别安全资产。

在此上下文学习之后，通过逐步推理和适当的约束方法，我们在模块级别识别概念性资产。然后，这些资产被系统地映射到它们相应的结构性RTL引用（源自解析的设计元素）——这些是模块级别的主要资产。此外，对于每个主要资产，我们找到影响/违反其安全目标的内部信号/寄存器——这些被称为模块级别的次要资产。资产生成步骤如算法1（第5-6行）所示。

III-C 资产优化

当应用于安全资产识别时，LLM通常倾向于列出大量可能的安全和非安全资产。这种倾向虽然在最大化覆盖范围方面有帮助，但也可能通过包含几乎不相关的设计元素而引入假阳性。出于这个原因，也是为了回答第I节中的RQ3，我们设计了一个严格的三阶段背靠背优化智能体，以过滤掉假阳性并验证剩余结果，确保模块级别的最终资产列表得到准确证实。优化智能体包括以下阶段，如算法1（第7-17行）所示：

III-C1 攻击场景分析

我们评估每个候选主要资产对七种硬件攻击类别的敏感性：侧信道、故障注入、安全到非安全信息泄漏、未经授权的访问、权限提升、硬件木马和拒绝服务。使用上下文训练，LLM为每个资产生成 plausible 攻击场景的高级抽象；没有此类场景的资产被排除。此分析向验证专家证明了资产包含的理由，并且通过LLM的零样本推理能力，超越了模块边界以捕获系统范围的安全影响。

III-C2 CWE映射

为了为生成的资产提供额外的上下文并进一步优化资产，我们分析MITRE数据库中的CWE是否可以映射到每个主要资产以及映射的程度 [b6]。鉴于数据库的规模庞大，分析被构造为一次检查每个安全目标下的CWE，确保没有CWE被遗漏。此外，我们只关注数据库中与安全资产相关的信息，以防止LLM在CWE映射过程中被无关信息淹没。严格的映射确保只有绝对关键的CWE（如果有）被映射到每个资产。最后，没有可映射CWE的资产被移除。

III-C3 自我批判修订

到目前为止在模块级别生成的资产注解受到自我批判提示的挑战并进一步修订。再次使用输入资源，我们重新检查资产相关性、RTL引用、安全目标正确性、攻击场景连贯性和CWE适当性，从而提高了准确性和可靠性。

III-C4 次要资产的影响度（DoI）计算

在枚举模块级别的资产之后，我们评估这些资产在设计内如何相互影响。由于模块资产跨边界交互，它们的相互依赖性决定了本地漏洞如何升级为更广泛的系统风险。RTL分析用于提取安全关键模块之间的层次链接。沿着每条路径，最易被篡改的资产被指定为主要资产，而其余资产被视为次要资产。然后分析比特级RTL连通性以量化主要资产和次要资产之间的关系，并将影响沿每条路径乘性地回溯以得出每个次要资产的最终DoI度量。

DoI = （连接到主要资产的次要资产的比特数 / 主要资产的总比特数） × 100%​ (1)

我们将DoI计算为一个经验度量，以量化已识别次要资产的"硬度"，这也可以指导该范围内的后续研究。

算法1 LAsset框架

（此处保留算法伪代码的格式，但内容为上述描述的总结，非直接逐行翻译）

IV 实验结果与评估

我们在NEORV32 RISC-V SoC和几个硬件IP块上进行了案例研究，在两种配置下进行，以证明LAsset工作流在跨不同架构识别安全资产方面的有效性和通用性。结果可在线获取。

图5：LAsset为NEORV32处理器输出的片段（规范 + RTL方法）

LAsset采用OpenAI的GPT-5模型进行基于上下文学习的资产识别。在模块化规范生成任务中，检索使用1000个字符的块和200个字符的重叠来保留上下文。嵌入使用OpenAI的text-embedding-ada-002模型生成，并使用FAISS进行相似性搜索，以检索每个查询的前20个相关块。

IV-A SoC：NEORV32 RISC-V 处理器

对于SoC案例研究，我们选择NEORV32 RISC-V处理器来评估LAsset框架。

在完整的LAsset运行之后，在NEORV IP中识别出资产，并且它们的互连产生了次要资产对其主要对应资产的影响度（DoI）。例如，主要资产neorv32_cpu中的csr_rdata连接到几个次要资产，包括neorv32_cpu_cp_fpu中的csr_we_i。该资产仅控制32个FPU CSR位中的8位（csr_fflags[4:0], csr_frm[2:0]），给出 8/32 = 25%。由于csr_o完全映射到csr_rdata，总体影响度保持为25%。相关的威胁包括故障注入、未经授权访问和硬件木马（CWE-1262, CWE-1247）。

为了验证输出，我们基于对硬件安全保证的了解，为每个NEORV32 IP手动创建了一个安全资产参考列表。我们进一步使用主流的LLM聊天机器人（即GPT、Gemini和Grok）交叉验证手动标注的资产。这样做是为了评估手动标注相对于真实情况的可靠性，同时引入了一个超出可能出错的人工评审的额外评估维度。我们将这些手动标注与LAsset的响应进行比较，其摘要如表III所示。由于LAsset基于已验证的主要和次要资产之间的关系确定性计算DoI，因此我们没有为此执行单独的验证。

IV-B IP：OpenTitan 和 OpenCores IPs

为了在IP级别验证LAsset的安全资产识别能力，我们从OpenTitan [b9]、OpenCores [b10] 和其他代码库中总共选择了21个开源加密IP、接口-GPIO IP和接口-外设IP。表II显示了128位AES架构的全面主要-次要分类资产列表。我们将我们的资产输出与Nath等人 [nath2025toward] 的输出进行了比较，如表III所示，因为他们的工具生成的主要资产列表和相同IP的基准数据集都是公开的 [b11]。

表I：跨IP代码库的规范+RTL方法与仅RTL方法的资产摘要比较

（此表包含大量数据，翻译格式复杂，此处省略具体数字的逐项翻译，保留表头说明）

代码库

IP

参考资产列表

总设计元素

规范+RTL方法 -> 初始资产数 / 优化后资产数 / 真正例 / 假反例 / 假正例

仅RTL方法 -> 初始资产数 / 优化后资产数 / 真正例 / 假反例 / 假正例

表II：AES-128设计的安全资产

（此表展示了资产分类和CWE映射的详细示例，格式复杂，此处省略具体条目翻译，保留结构说明）

主要资产

安全目标

次要资产（设计模块）

CWE-ID

IV-C 性能比较与分析

在本小节中，我们比较了LAsset的性能，如图6所示，以评估其是否符合预期行为，并分析任何观察到的差异的根本原因。通过比较资产输出与参考列表获得的详细、按IP分类的结果总结在表I中呈现。

IV-C1 SoC级别

从表III中，我们发现规范 + RTL方法在SoC级别产生的结果优于仅RTL方法。这表明RTL是主要贡献资源，因为RTL明确映射了所有必要的设计组件及其功能，LLM可以有效地解释这些信息。然而，规范中对操作行为和互连性的自然语言描述有助于LLM更好地理解设计，比单独使用RTL更好。因此，从这个分析中得出的结论是，虽然行业标准规范本身不足以识别设计中的安全资产，但它可以作为LAsset框架的补充因素。

图6：SoC和IP级别上RTL + Spec. 与 仅RTL方法的图形比较

IV-C2 IP级别

表III显示，在IP级别，规范+RTL方法的表现优于仅RTL方法。与Nath等人 [b11] 的工作相比，LAsset实现了更高的召回率93.21%，而他们的方法为83.33%。这些值是针对他们手动定制的黄金资产列表测量的。然而，在仔细审查此列表后，我们发现缺少了许多实际资产。例如，在SHA-3 IP块的情况下，轮常量rc1和rc2应被包括在内，因为对它们进行篡改会导致转换步骤出错并破坏算法的完整性。由于Nath等人 [b11] 的黄金列表忽略了大量此类关键资产，因此LAsset识别出的那些资产被错误地标记为假阳性，即使它们必须是真阳性。因此，直接比较LAsset和Nath等人 [b11] 之间的准确率和F1分数并不是一个有意义的评估；相反，召回率提供了更合适的比较指标。

表III：SoC级别和IP级别不同输入配置的比较

（此表包含SoC和IP级别下两种输入配置的性能数据，特别是召回率）

输入配置

实际类别

预测阳性

预测阴性

性能指标

IV-D 时间-成本-性能比较

尽管本文展示的LAsset结果采用了GPT-5模型，但我们考虑了框架的模型无关行为。为此，我们对五个样本IP块（即AES、SHA-3、GPIO、AXI-Adapter和AHB3LITE）执行了端到端流程，并比较了五种不同LLM模型在召回率（%）、运行时间和货币成本这三个方面的结果，如图7所示。

图7：LAsset不同LLM模型的性能-时间-成本比较

为了量化权衡，我们定义了一个模型无关效用（MAU），它在用户指定的优先级下聚合归一化指标：

MAU = α * ( (100 – R) / 100 ) + β * (T / T_max) + γ * (C / C_max)​ (2)

其中 α, β, γ ≥ 0, 且 α + β + γ = 1.

这里，T_max 和 C_max 表示一个设计观察到的最大时间和成本；R、T 和 C 分别表示相应LLM模型观察到的召回百分比、时间和成本；α、β 和 γ 表示选择偏好（例如，性能中心、延迟敏感或成本约束）。因此，较低的 MAU 对应更高效的模型。在我们的实验中，我们优先考虑性能 over 成本和时间，因此我们用 α = 0.6, β = 0.1, 和 γ = 0.3 来调整方程（2）。在此配置下，发现GPT-5-nano是具有最小MAU的最佳候选者。

V 结论

本文介绍了LAsset，一种自动化的AI辅助方法，用于识别硬件IP和SoC中的安全关键资产，利用了LLM的固有能力。LAsset不仅识别硬件设计中安全相关的主要和相应的次要资产，还将它们与相关的攻击向量和CWE以及每个次要资产的影响度关联起来，从而帮助设计和验证工程师在后续安全阶段更好地理解和利用这些资产。这一发展进一步规范了现有的IP和SoC设计流程，同时增强了整体硬件安全验证的前景。