领域知识 | 智能驾驶安全领域部分常见概论

Hi，早。

最近想买个新能源车，这个车吧相比于之前的内燃车，新能源车与外界的交互多了很多。比如娱乐的第三方应用，OTA升级等应用。

交互带来的便利越多，暴露的风险自然也就越大，相比于手机等消费者终端设备，车要是被黑客远程操控，这就玩大了。所以对于车规级的芯片和系统，从沙子开始就有相应得规范来保证安全。

作为一个曾经的安全领域的不知名靓仔，于是就在这里整理回忆了部分涉及到的概念和理论记录如下。

以前老是忘记给你们备注超链接，现在每个部分都及时记录，主打一个听劝，感动的话记得点赞！

保证一个系统的安全，需要从多个维度去考虑。网络、通信、系统、应用、硬件等多方面。

文章目录

硬件
- eFuse
- HSM
- TEE
软件
- 系统完整性
- - 安全启动
  - DM_verity
  - 应用签名
- 安全通信
- - TLS通信
  - 车内CAN总线安全通信
  - 远控E2E保护
- 数据机密性保护
- - 磁盘分区加密
  - AI模型加密
- 访问控制&隔离
- - DAC
  - Selinux
  - 沙箱隔离
- AI安全
- - GPS防欺骗
  - 多传感器校验
推荐阅读

硬件

eFuse

所有支持 Secure Boot 的 Soc 都会有一块很小的一次性编程储存模块，我们称之为 FUSE 或者 eFUSE，因为它的工作原理跟现实中的保险丝类似：CPU 在出厂后，这块 eFUSE 空间内所有的比特都是 1，如果向一个比特烧写 0，就会彻底烧死这个比特，再也无法改变它的值，也就是再也回不去 1 了。

一般 eFUSE 的大小在 1KB 左右，OEM 从 CPU 厂家购买了芯片，组装了产品后，一般都要焼写 eFUSE 的内容，包括产品的运行模式：测试、开发、生产等。面向终端消费者的产品都会被焼写为生产模式。这个模式下 bootROM 会禁用很多权限，更大面积地限制用户的能力。

另外一个很重要的焼写内容就是根密钥了，一般有两种根密钥：一个是加密解密用的对称密钥 Secure Boot Key，一般是 AES 128 的，每台设备都是随机生成不一样的；另一个是一个 Secure Boot Signing Key 公钥，一般用的 RSA 或 ECC，这个是每个 OEM 自己生成的，每台设备用的都一样，有些芯片会存公钥的 Hash 来减少 eFUSE 的空间使用。

**只有 Secure World（后面会介绍）才能访问 eFUSE 的寄存器。**除了读写 eFUSE 的基础寄存器之外，还有一些控制寄存器可以禁止别的程序访问 eFUSE，来保护其中的密钥。因此 eFUSE 中的根密钥以及 bootROM 将作为 Secure Boot 的根信任。

详情请阅：

【浅析安全启动】

来自：

HSM

硬件安全模块（英语：Hardware security module，缩写HSM）是一种用于保障和管理强认证系统所使用的数字密钥，并同时提供相关密码学操作的计算机硬件设备。

硬件安全模块一般通过扩展卡或外部设备的形式直接连接到电脑或网络服务器。

详细请阅读：【硬件安全】硬件安全模块—HSM

TEE

TEE不是一个具体的技术，而是一套完整的安全解决方案，包括但不仅限于：

• 安全启动技术（Secure Boot），用于防止系统镜像被篡改，保护安全系统、安全手机镜像等。

• 安全显示和触摸技术（TUI），提供安全输入保证，保护用户应用界面和键盘操作不被监控，防止恶意软件获取用户信息。

• 安全存储技术，包括安全文件系统（SFS）和rpmb，用于安全地存储数据。

• 安全加解密引擎，软件加解密算法达到同行业领先水平，包括RSA2028公私钥生成时间低于友商2倍以上。

• so on

包含正常世界状态的客户端应用（Client Application，CA）、安全世界状态的可信应用、可信硬件驱动（Secure Driver，SD）以及可信内核系统（Trusted Execution Environment Operation System，TEE OS）。

TEE的系统配置、内部逻辑、安全设备和安全资源的划分是与CPU的集成电路（Integrated Circuit，IC）设计紧密挂钩的，使用ARM架构设计的不同CPU，TEE的配置完全不一样。

详情请阅：

【TEE、可信计算、安全相关方向】
【硬件安全与硬件可信】

软件

系统完整性

安全启动

**安全启动的根本目的是为了防止消费者从软硬件层面对产品的部分关键系统进行读写、调试等高权限的操作。**以限制消费者的能力，来达到保护产品的商业机密、知识产权等厂家权益的目的。

当然，厂家是不会这样宣传 Secure Boot 的。他们的文案通常都是通过这项技术保护用户的隐私，防止恶意软件修改系统软硬件等等。

安全引导（Secure Boot）功能是指在系统的整个启动过程中，使用链式验证电子签名的方式来验证系统中重要镜像文件的可靠性，然后再加载镜像文件的引导过程。

安全引导功能可以保护二级厂商系统的独立性和完整性。在ARMv8架构中ARM提供了ARM可信固件（ATF）。

Bootloader、Linux内核、TEE OS的启动都由ATF来加载和引导。对于ARMv8, Bootloader、Linux内核和TEE OS镜像文件的验签工作都是在ATF中完成的。本文将介绍安全引导功能的原理以及ATF的启动过程。

详情请阅：

【万字长文：安全启动及ATF的启动过程（小白也能看懂！）】
【浅析安全启动（Secure Boot）】

DM_verity

dm-verity

1、能不能将多个硬盘，映射成一个逻辑的硬盘，那样我们程序就不用关心复杂的地址问题了，也不用关系是哪个device了？ DM-raid技术RAID全称为独立磁盘冗余阵列(Redundant Array of Independent Disks)
2、将某个地址段的数据进行加密，只有授权方式才可访问，比如FDE。 DM-crypt技术
3、访问存储介质上的数据时，校验下是否被篡改过。DM-verity技术。

DM就是Device-Mapper的缩写，也就说上述的想法都可以基于Device Mapper实现，Device Mapper可不仅仅实现了这些，还包括LVM2、DM-multipach等。

什么是Device Mapper?

dm-verity是内核子系统的Device Mapper中的一个子模块，所以在介绍dm-verity之前先要介绍一下Device Mapper的基础知识。

Device Mapper为Linux内核提供了一个从逻辑设备到物理设备的映射框架，通过它，用户可以定制资源的管理策略。当前Linux中的逻辑卷管理器如LVM2（Linux Volume Manager 2）、EVMS（Enterprise Volume Mageagement System）、dmraid等都是基于该机制实现的。（一堆陌生词汇，扫盲点安排上了）

Device Mapper有三个重要的概念：映射设备（Mapped Device）、映射表、目标设备（Target Device）；

映射设备是一个逻辑块设备，用户可以像使用其他块设备那样使用映射设备。映射设备通过映射表描述的映射关系和目标设备建立映射。对映射设备的读写操作最终要映射成对目标设备的操作。

而目标设备本身不一定是一个实际的物理设备，它可以是另一个映射设备，如此反复循环，理论上可以无限迭代下去。映射关系本质上就是表明映射设备中的地址对应到哪个目标设备的哪个地址。（无限套娃）

Device Mapper是一个灵活的架构，映射设备映射一个或多个目标设备，每个目标设备属于一个类型，类型不同，对I/O处理不同，构造目标设备的方法也不同。映射设备可以映射多个不同类型的目标设备。

Dm-verity规定只能有两个目标设备，一个是数据设备（Data Device），另一个是哈希设备（Hash Device）；

Device Mapper可参考IBM博客：https://www.ibm.com/developerworks/cn/linux/l-devmapper/

dm-verity简介

dm-verity是Device mapper架构下的一种目标设备类型，通过它来保障设备或设备分区的完整性，它的典型架构是如图一。

dm-verity类型的设备需要两个底层设备，一个是数据设备，顾名思义是用来存储数据，实际上就是要保障完整性的设备，另一个是哈希设备，用来存储哈希值，在校验数据设备完整性时需要。

图中映射设备和目标设备是一对一关系，对映射设备的读操作被映射成对目标设备的读操作，在目标设备中，dm-verity又将读操作映射为数据设备（Data Device）的读操作。

但是在读操作的结束处，dm-verity加了一个额外的校验操作，对读到的数据计算一个hash值，用这个哈希值和存储在哈希设备（Hash Device）中的值做比较，如果不同，则本次读操作被标记为错误。

假设数据设备和哈希设备中每块大小均为4KB，再假设使用hash算法SHA256，即每块数据的哈希值为32B（256bits），则哈希设备中的每块（4KB）存储有4096/32=128个哈希值。所以在layer0中一个哈希设备的块对应数据设备的128个块。到这里似乎完整了，数据设备中存储数据，哈希设备存储哈希值。

在读取数据时，dm-verity还要防备哈希设备中存储的哈希值被篡改的情况。

所以要加上layer1，在layer1中的每块数据对应layer0的128个块，layer1中的数据就是对layer0中的数据（hash设备和数据设备中的数据）计算hash值，如果layer1中只有一块，那么就此停止，否则继续增加layer，直到layer n只有一块。最后对layer n再计算hash值，称这个hash值为root hash。

这个root hash就可以反应数据设备和hash设备的变化。通过验证root hash 就可以校验数据是否被篡改。

简直是精妙啊！！！

2、哈希树（Merkletree）

我还以为hash树是hash-tree，哈哈哈哈

哈希树（hash tree；Merkle tree），在密码学及计算机科学中是一种树形数据结构，每个叶节点均以数据块的哈希作为标签，而除了叶节点以外的节点则以其子节点标签的加密哈希作为标签。

哈希树能够高效、安全地验证大型数据结构的内容。哈希树的概念由瑞夫·墨克于 1979 年申请专利，故亦称墨克树（Merkle tree）。

哈希树的顶部为顶部哈希（top hash），亦称根哈希（root hash）或主哈希（master hash）。只要任一叶节点有变化，根哈希都会变。在比特币区块里，所有交易都按照Merkle Tree的格式组织起来，再跟区块头里的hashMerkleTreeRoot对应起来，就可以保证本区块交易信息的不可篡改。

参考资料：

https://www.cnblogs.com/linhaostudy/p/7418289.html
https://www.cnblogs.com/linhaostudy/archive/2018/01/17/7418289.html

应用签名

通过应用签名，开发者可以标识应用创作者并更新其应用，而无需创建复杂的接口和权限。在 Android 平台上运行的每个应用都必须有开发者的签名。 Google Play 或 Android 设备上的软件包安装程序会拒绝没有获得签名就尝试安装的应用。

在 Google Play 上，应用签名可以将 Google 对开发者的信任和开发者对自己的应用的信任联系在一起。这样一来，开发者就知道自己的应用是以未经修改的形式提供给 Android 设备，并且可以对其应用的行为负责。

在 Android 上，应用签名是将应用放入其应用沙盒的第一步。已签名的应用证书定义了哪个用户 ID 与哪个应用相关联；不同的应用要以不同的用户 ID 运行。应用签名可确保一个应用无法访问任何其他应用的数据，通过明确定义的 IPC 进行访问时除外。

应用沙盒

Android 平台利用基于用户的 Linux 保护机制识别和隔离应用资源，可将不同的应用分隔开来，并保护应用和系统免受恶意应用的攻击。为此，Android 会为每个 Android 应用分配一个独一无二的用户 ID (UID)，并让应用在自己的进程中运行。

Android 会使用该 UID 设置一个内核级应用沙盒。内核会在进程级别利用标准的 Linux 机制（例如，分配给应用的用户 ID 和组 ID）实现应用和系统之间的安全防护。默认情况下，应用不能彼此交互，而且对操作系统的访问权限会受到限制。如果应用 A 尝试执行恶意操作（例如在没有权限的情况下读取应用 B 的数据或拨打电话），系统会阻止此类行为，因为应用 A 没有相应的默认用户权限。这一沙盒机制非常简单，可审核，并且基于已有数十年历史的 UNIX 风格的进程用户隔离和文件权限机制。

由于应用沙盒位于内核层面，因此该安全模型的保护范围扩展到了原生代码和操作系统应用。位于更高层面的所有软件（例如，操作系统库、应用框架、应用运行时环境和所有应用）都会在应用沙盒中运行。某些平台会限制开发者只能使用特定的开发框架、API 或语言。在 Android 上，并没有为了执行安全防护机制而限制开发者必须如何编写应用；在这方面，原生代码与解释型代码一样进行沙盒化。

当应用（APK 文件）安装到 Android 设备上时，软件包管理器会验证 APK 是否已经过适当签名（已使用 APK 中包含的证书签名）。如果该证书（或更准确地说，证书中的公钥）与设备上的任何其他 APK 使用的签名密钥一致，那么这个新 APK 就可以选择在清单中指定它将与其他以类似方式签名的 APK 共用一个 UID。

应用可以由第三方（OEM、运营商、其他应用市场）签名，也可以自行签名。Android 提供了使用自签名证书进行代码签名的功能，而开发者无需外部协助或许可即可生成自签名证书。应用并非必须由核心机构签名。Android 目前不对应用证书进行 CA 认证。

应用还可以在“签名”保护级别声明安全权限，以便只有使用同一个密钥签名的应用可以获得此仅限，同时让这些应用可以各自维持单独的 UID 和应用沙盒。通过共用 UID 功能，可以与共用的应用沙盒建立更紧密的联系，这是因为借助该功能，使用同一个开发者密钥签名的两个或更多应用可以在其清单中声明共用的 UID。

详情请阅：

【应用签名】

安全通信

TLS通信

传输层安全性（Transport Layer Security，TLS）是一种广泛采用的安全性协议，旨在促进互联网通信的私密性和数据安全性。TLS 的主要用例是对 web 应用程序和服务器之间的通信（例如，web 浏览器加载网站）进行加密。TLS 还可以用于加密其他通信，如电子邮件、消息传递和 IP 语音 (VoIP) 等。

TLS 和 SSL 之间有什么区别？

Netscape 开发了名为安全套接字层（Secure Socket Layer，SSL）的上一代加密协议，TLS 由此演变而来。TLS 1.0 版实际上最初作为 SSL 3.1 版开发，但在发布前更改了名称，以表明它不再与 Netscape 关联。由于这个历史原因，TLS 和 SSL 这两个术语有时会互换使用。

TLS 有什么作用？

TLS 协议实现的功能有三个主要组成部分：加密、认证和完整性。

加密：隐藏从第三方传输的数据。
身份验证：确保交换信息的各方是他们所声称的身份。
完整性：验证数据未被伪造或篡改。

TLS 如何工作？

TLS 连接是通过一个称为 TLS 握手的流程启动的。当用户导航到一个使用 TLS 的网站时，用户设备（也称为客户端设备）和 web 服务器之间开始 TLS 握手。

在 TLS 过程中，用户设备和 web 服务器：

指定将要使用的 TLS 版本（TLS 1.0、1.2、1.3 等）
决定将要使用哪些密码套件（见下文）
使用服务器的 TLS 证书验证服务器的身份
握手完成后，生成会话密钥用于加密两者之间的消息

TLS 握手为每个通信会话建立一个密码套件密码套件是一组算法，其中指定了一些细节，例如哪些共享加密密钥（即会话密钥）将用于该特定会话。TLS 也能在一个未加密的通道上设置匹配的会话密钥，这要归功于一种称为公钥加密的技术。

握手还处理身份验证，其中通常包括服务器向客户端证明其身份。这是通过使用公钥来完成的。公钥是使用单向加密的加密密钥，即任何拥有公钥的人都可以解读使用服务器私钥加密的数据，以确保其真实性，但只有源发送方才可以使用私钥加密数据。服务器的公钥是其 TLS 证书的一部分。

数据完成加密和验明身份后，使用消息身份验证码（MAC）进行签名。接收方然后可以验证 MAC 来确保数据的完整性。这有点像阿司匹林药瓶上的防篡改铝箔；消费者知道没人篡改过他们的药品，因为购买时铝箔完好无损。

详情请阅：

【TLS】

车内CAN总线安全通信

CAN总线（Controller Area Network）是一种广泛应用于汽车、工业控制和其他领域的串行通信协议。它最初由德国公司Bosch在1986年开发，并于1987年正式发布。

现在CAN总线广泛应用于汽车领域，用于车辆内部的多个电子控制单元（ECU）之间的通信，如引擎控制、刹车系统、仪表盘等。此外，它也被广泛应用于工业自动化、机器人技术、医疗设备等领域的分布式控制系统中。

类似于计算机里面的总线，在CAN问世之前，车载通信系统是通过点对点的布线系统实现的。随着车载电子元件越来越多，这种通信系统变得愈发笨重，而且维护费用非常昂贵。这时，CAN应运而生，并成为主流的车载通信系统

详情请阅：

【浅谈车辆CAN总线安全】
【汽车车内CAN总线网络安全分析及防御措施】

远控E2E保护

E2E（End-to-End）保护是一种端对端保护机制，举个例子：控制器中某个安全关键性功能模块的输出计算要依赖于内部某个非安全性的模块或其他安全等级要求不高的硬件通过总线传输过来的数据，因安全相关数据可能因通讯故障而丢失或篡改，那么如何保证数据交换的正确性呢？

此时就可借助E2E保护。从上面的例子，我们可大体知道，数据传输的链路主要存在如下三种：

1、不同控制器之间的数据传输，例如通过CAN、LIN、以太网、OTA等方式的数据传输。
2、控制器内部ASW与ASW之间的数据传输。
3、控制器内部ASW与BSW之间的数据传输。

E2E保护既可用于控制器内部功能模块之间的数据保护，也可用于不同控制器之间的数据保护。

通过采用 E2E 通信保护机制可以在运行时，实时检测到通信链中出现的错误，E2E 库提供了相关的保护验证机制来保证与功能安全相关的通信。

详情请阅：

【圈外人看E2E保护】

数据机密性保护

磁盘分区加密

移动存储的安全性至关重要，因为用户在其移动应用（如数码相机、智能手机和平板电脑）的闪存中存储更加敏感的数据。

联合电子设备工程委员会（JEDEC）为这些移动应用开发了两种存储接口标准：嵌入式多媒体控制器（eMMC）和通用闪存（UFS), 两者都可以使用内联加密来保护数据。

eMMC为主流移动应用的提供了高可靠性、吞吐量和快速启动支持，而UFS则为高端移动应用带来了显著的性能优势和功耗特性。

在智能手机中，eMMC或UFS 被划分为两个分区：

只读分区：系统使用此分区来存储Android操作系统，用户无法对此部分进行编程和修改，除非破坏掉手机的功能应用和数据分区：系统使用此分区来存储应用程序和用户数据，例如文档和多媒体文件

图1显示了32 GB的内部内存分区，其中25.23 GB可用于设备存储，剩下的则用于存储操作系统。

图1：Android设备的内部存储分区显示，大部分空间用于存储需保证安全的个人数据

在基于Android的移动应用中实现eMMC和UFS内联加密：https://www.synopsys.com/zh-cn/china/resources/dwtb/dwtb-cn-q1-2018-mobile-storage.html

详情请阅：

【Linux内核安全技术——磁盘加密技术概述和eCryptfs详解】

AI模型加密

AI服务提供商在本地完成模型训练和调优后，将模型部署到第三方外包平台上（如终端设备、边缘设备和云服务器）来提供推理服务。由于AI模型的设计和训练需要投入大量时间、数据和算力，如何保护模型的知识产权（包括模型结构和参数等信息），防止模型在部署过程中的传输、存储以及运行环节被窃取，已经成为服务/模型提供商最为关心的问题之一。

模型的安全保护可以分为静态保护和动态保护两个方面。静态保护指的是模型在传输和存储时的保护，目前业界普遍采用的是基于文件加密的模型保护方案，AI模型文件以密文形态传输和存储，执行推理前在内存中解密。

在整个推理过程中，模型在内存中始终是明文的，存在被敌手从内存中转储的风险。

动态保护指的是模型在运行时的保护，目前业界已有的模型运行时保护方案主要有以下三个技术路线：

一是基于TEE（Trusted Execution Environment）的模型保护方案，TEE通常指的是通过可信硬件隔离出来的一个“安全区”，AI模型文件在非安全区加密存储和传输，在安全区中解密运行。该方案在CPU上的推理时延较小，但依赖特定可信硬件，有一定的部署难度。此外，受硬件资源约束，难以保护大规模深度模型，且目前仍无法有效支持异构硬件加速。
二是基于密态计算的保护方案，该方案基于密码学方法（如同态加密、多方安全计算等），保证模型在传输、存储和运行过程中始终保持密文状态。该方案不依赖特定硬件，但面临非常大的计算或通信开销问题，且无法保护模型结构信息。
三是基于混淆的模型保护方案，该方案主要通过对模型的计算逻辑进行加扰，使得敌手即使能获取到模型也无法理解。与前两种技术路线相比，该方案仅带来较小的性能开销，且精度损失很低，同时，不依赖特定硬件，可支持大模型的保护。

详情请阅：

【模型的安全保护】

访问控制&隔离

DAC

DAC（Discretionary Access Control，自主访问控制）

① DAC是传统的Linux的访问控制方式，DAC可以对文件、文件夹、共享资源等进行访问控制。
② 在DAC这种模型中，文件客体的所有者（或者管理员）负责管理访问控制。
③ DAC使用了ACL（Access Control List，访问控制列表）来给非管理者用户提供不同的权限，而root用户对文件系统有完全自由的控制权。

MAC（Mandatory Access Control，强制访问控制）

① SELinux在内核中使用MAC检查操作是否允许。
② 在MAC这种模型中，系统管理员管理负责访问控制，用户不能直接改变强制访问控制属性。
③MAC可以定义所有的进程（称为主体）对系统的其他部分（文件、设备、socket、端口和其它进程等，称为客体）进行操作的权限或许可。

DAC和MAC的其它区别

① DAC的主体是真实有效的用户和组ID，MAC的主体是安全上下文，两者的UID是各自独立的。
② DAC的访问控制模式是rwxrwxrwx，MAC的访问控制模式是user:role:type。

详情请阅：

【Linux 权限管理与访问控制详解——基本概念和 DAC】
【linux的DAC和MAC】
【wiki】

Selinux

SELinux由NSA发布，之后，Red Hat、Network Associates、Secure Computing Corporation、Tresys Technology以及Trusted Computer Solutions等公司及研究团队都为SELinux的发展做出了重要的贡献。

**SELinux本质是一个Linux内核安全模块，**可在Linux系统中配置其状态。SELinux的状态分为3种，即disabled、permissive和enforcing。

（1）disabled状态：指在Linux系统中不启用SELinux模块的功能。
（2）permissive状态：指在Linux系统中，SELinux模块处于Debug模式，若操作违反策略系统将对违反内容进行记录，但不影响后续操作。
（3）enforcing状态：指在Linux系统中，SELinux模块有效，若操作违反策略，SELinux模块将无法继续工作。

详情请阅：

【内核安全-SElinux整体架构】
【内核安全-SElinux关键技术】

沙箱隔离

在计算机领域中，沙箱技术（Sandboxing）是一种用于隔离正在运行程序的安全机制，其目的是限制不可信进程或不可信代码运行时的访问权限。沙箱的名称来源于儿童所玩的沙盒游戏，在沙盒中，孩子们可以自由运用想象力搭建一个与外界隔绝的小世界，正如沙箱会为待执行的程序提供了一个虚拟环境。

这个虚拟环境中包含一些虚拟的硬件和软件资源，如文件系统、网络、操作系统等，使应用程序或进程可以在该环境中运行。在沙箱中运行的程序只能访问沙箱给它加载的资源，而不会影响到外部的应用、系统或平台，避免其对计算机中的其他程序或数据造成永久的更改。沙箱应用在网络安全领域，可以通过隔离沙箱中的病毒文件，以达到识别未知攻击的效果。

沙箱主要应用到了三类技术：虚拟化技术、访问控制技术与防躲避技术。

虚拟化技术

虚拟化技术（Virtualization）是一种资源管理技术。通过虚拟化，计算机的很多实体资源，包括CPU、内存、磁盘空间等，都会被抽象化后成为可供分割和重新组合的状态，让用户可以自己重新分配电脑硬件资源。

如图所示，在沙箱中会使用虚拟化技术为不可信的资源构建封闭的运行环境，在保证不可信资源功能正常运行的同时提供安全防护。

简而言之，即是沙箱中被隔离的可疑或待测程序会使用沙箱中的资源运行，以保证沙箱外资源的安全，不影响沙箱外其他程序的运行。

访问控制技术

当沙箱环境中的程序需要去访问一些沙箱外的、但对其运行有必要的资源时，就需要访问控制规则去限制程序的行为。沙箱的访问控制往往由程序监控器与访问控制规则引擎等部分组成。程序监控器监控沙箱内程序的运行，并将监控到的行为提交给访问规则控制引擎。访问规则控制引擎会根据规则，判断是否允许程序使用沙箱外的特定资源。