网络安全已成为汽车行业的一个关键挑战。在现阶段，ISO/SAE 21434描述的框架不足以导出供应商级别安全汽车网络嵌入式系统设计的具体方法。本文介绍了一个案例研究，其中包含设计安全系统的可操作步骤，并系统地提出了可追溯的网络安全需求，以弥补这一差距。该案例研究与ISO/SAE 21434标准相一致，可为将网络安全工程集成到公司特定流程和实践规范中提供基础。

01.简介

车辆正在从孤立的、主要是电子机械系统变为带轮子的互联计算机。这一趋势是由汽车行业希望提供创新的移动服务以及向部分和完全自动化车辆的进一步发展所驱动。这些目标很可能只有通过合作和自动化车辆才能实现。然而，为了实现安全、自动化和互动的车辆，需要进一步改进网络安全。

最近的评估和披露表明，在当前车辆中几乎所有连接元素都存在多个漏洞，以下例子可以说明这一点：如今，汽车制造商充当本地互联网注册机构(LIR)并维护IP地址、证书和证书管理系统集群，以确保车队中的车辆能安全远程访问外部基础设施和服务。为此，现代车辆使用基于Linux的网关服务器来实现对外部服务的远程访问。每辆车的网关服务器在生产线末端(EOL)生产过程中都配置有单独的密钥材料和证书。除了网关服务器，车辆还提供各种其他协议来访问车载功能，例如车载诊断(OBD)接口和服务、WLAN、蓝牙和专用Vehicle2X通信协议。这些连接功能扩大了现代车辆的攻击面，使它们容易受到外部攻击。

图1：针对联网车辆的多层远程网络安全攻击示例

图1展示了一次成功对市场上出售的车辆上进行的的远程网络安全攻击。在这种多层攻击中，通过利用远程接口中的漏洞来获得车辆车载功能的访问权限，最终导致不必要的车辆转向。所描述的攻击包括以下步骤：

1.信息泄露：在第一步中，攻击者使用相同型号的车型进行攻击准备。通过OBD接口嗅探车辆总线消息，攻击者可以了解总线通信的细节（即消息目录的部分内容）。此外，还可以识别车辆制造商使用的IP地址集群。为了进行后续攻击，通过嗅探目标车辆与车主智能手机之间的通信，可以获得受攻击车辆的具体IP地址。

2. 权限提升：在下一步中，利用Linux网关防火墙的已知漏洞来获取root权限，从而使攻击者能够访问车辆的内部网络。在此阶段，可以使用网关从远程设备向车辆内部网络发送恶意命令，并在网关上部署恶意软件。

3. 仿冒攻击：在最后一步中，通过执行先前部署在网关上的脚本对车辆进行攻击。该脚本向车辆内部网络发送包含恶意但适当组装的转向控制命令和车速信息的消息。消息结构在第一步攻击中被识别，并且现在用于所谓的仿冒攻击，以模拟其他总线参与者的行为/消息。在具体示例中，模拟的车速信息（即车辆以低于5km/h的速度行驶）欺骗了转向控制单元（SCU）接受来自停车辅助控制单元（PACU）的转向命令，即使在高速行驶的情况下。最后，使攻击者能够远程操控车辆。

1.1问题陈述

如今，只有少数网关服务器开发公司与原始设备制造商（OEM）密切合作，共同设计车辆的电气/电子（E/E）架构和车队安全服务架构（SSA）。因此，大多数汽车开发仍然与交付电子控制的网络嵌入式车辆功能有关，这些功能实现了例如车辆转向、加速和制动等。

这些功能需要以安全的方式集成到SSA和E/E架构中，以缓解新出现的安全威胁。因此，网络安全正成为汽车工业成功的基石，与可靠性和安全性并列。这一事实反映在最近的网络安全法规中，这些法规要求在将车型引入市场时提供网络安全证明（即联合国欧洲经济委员会（UNECE）批准，特别是UNECE WP.29/R155和UNECE WP.29/R.156）。

在这方面，汽车行业已经利用其他行业的经验，在发展和实施安全连接车辆方面取得了进展。然而，该行业仍面临几个特定的挑战。因此，迫切需要制定行业标准，以解决网络安全工程的问题，保护现代互联车辆和移动基础设施免受网络攻击。

虽然这些标准没有提供关于网络安全开发和实施的细节，但它们提供了一个提供一般指导的框架。而道路车辆网络安全工程标准ISO/SAE 21434是在认识到网络安全过程活动的大部分缺乏成熟的最新技术的基础上制定的。因此，标准中只能给出一个框架。这个框架未来需要补充完善，以提供具体指导，建立一个安全的开发过程。

1.2目的

本文旨在提出与汽车领域标准和适用于电子控制网络车辆功能安全设计的法规相一致的可操作步骤和方法。这些步骤应补充这些标准，并为工程师提供有关开发安全车辆功能的实用指导。本工作的重点是工程方面，包括风险驱动的系统设计和系统性的引出需求，以解决汽车开发工作流程不同阶段识别出的网络安全风险。涉及的工作流程步骤包括系统和架构设计阶段、硬件/软件设计阶段以及硬件/软件详细设计阶段，如图2所示。案例研究旨在展示如何应用安全驱动的分析方法来创建必要的证据（即工作产品），以引出由坚实的基于证据的和标准一致的论证支持的网络安全需求。

图2：网络安全开发工作流程和支持工作产品

1.3案例研究

该案例研究聚焦于负责控制车辆转向的转向控制单元(SCU)的开发。在图3中，SCU被突出显示，该图例说明了典型汽车一级供应商项目的范围，该项目针对特定车辆功能的开发。从安全角度来看，SCU应被设计为安全地集成到给定的E/E架构中。

如图3所示，正如第1节开头所介绍的，现代网联车辆使用网关服务器来建立与例如路边基础设施和其他车辆的远程连接。当今的车辆E/E架构将车载通信网络分成不同的子网域，以将安全关键的网络车辆功能与次要或非关键的娱乐和通信功能分开。然而，为了确保整车的正常运行，负责控制和协调整车行为的各个电子控制单元(ECU)必须互连。为此，网关服务器和子网域控制器通过实时以太网、CAN FD或两者互连。特定网络域内的各个ECU仍然依赖CAN FD通信，以保证较短的启动时间和毫秒级时间框架内的实时控制。

图3：典型供应商集成到安全服务架构(SSA)中

将不同的网络域进行清晰划分，为防御网络攻击提供了额外的防护层。这也允许使用已经建立的汽车开发流程和工具，来工程化安全关键的电子控制车辆功能。然而，在汽车领域内，尚无确立的最佳实践指南或安全工程流程与安全系统设计。因此，汽车供应商必须调整其开发生命周期，以将网络安全工程方面集成到其流程环境中。

在本工作的剩余部分，将描述提出的安全驱动工程步骤和方法，以进行此类适应。这些步骤和方法符合ISO/SAE 21434标准。该标准要求的主要规范活动包括项目定义以及威胁分析和风险评估（TARA）。

图4显示了电动助力转向系统的项目定义，它定义了项目范围和案例研究范围。此外，它在概念层面描述了正在开发的系统（SUD）的系统组件以及内部和外部接口。从安全角度来看，项目定义可以支持系统识别关键资产。根据ISO/SAE 21434，资产被定义为SUD的一个元素，其网络安全属性的妥协可能会损害项目的利益相关者，即受损害影响的个人或组织。因此，项目定义中的元素通常被识别为需要保护的资产，因为对它们的成功攻击通常会显著影响车辆的功能性、安全性或网络安全。

图4：转向控制单元（SCU）的项目定义

案例研究的示例基于两个并联运行的三相电机，每个电机都安装在转向架上。两个主/从处理单元用于控制三相电机，这两个单元都根据ASIL D（汽车安全完整性级别）的约束进行开发。这些处理单元连接到车辆总线，用于与其他ECU交换信息。给定项目定义中的网络安全关键系统资产标记为Axx，并被分组。呈现的系统架构旨在满足现代高度自动化车辆的安全和故障运行要求。

02.系统级网络安全工程

网络安全工程中的一般策略与每个可访问的系统接口都会增加潜在攻击面这一事实有关。因此，对系统接口及其相关的网络安全威胁的更好理解，越能适当地处理网络安全风险，并在受到攻击时保护系统。此外，从接口级别开始分析潜在的攻击路径有助于理解和评估对利益相关者的风险和攻击影响。

2.1 TARA准备

威胁分析和风险评估(TARA)的目标是识别SUD的潜在网络安全威胁，以及对识别威胁相关的风险进行后续评估。在进行TARA之前，应执行一些预分析步骤，包括：(a)上一节中描述的网络安全项定义，(b)关键功能块分析的衍生信息，该分析描述主要系统功能，(c)对正在使用的技术堆栈分析，详细说明了实现特定网络安全机制的硬件和软件构建模块，以及(d)威胁建模，以表示每个网络（物理）系统固有的对抗性网络威胁。

这些预分析步骤有助于更全面地了解系统、其潜在的攻击接口，以及攻击者可能需要达成其目标的所需知识和技术技能。此外，可以更适当地详细阐述系统资产及与网络安全相关的风险，这也有助于正确定义网络安全目标和选择缓解措施。

简而言之，在进行TARA之前，首先应使用（半）结构化方法（a）至（d）来识别系统资产。下面解释这些方法的结果。

图5显示了通过网络安全项定义、关键功能分析和技术栈分析识别的资产摘录。得出的系统级资产清单包括，例如接口、固件、配置数据、加密密钥材料、功能块、传感器和执行器等。资产分析是后续TARA的主要输入。

图5：资产清单摘录

系统级威胁模型（0级威胁模型）有助于开发SUD固有的对抗性威胁的表示。因此，系统级威胁模型是结构化和指导资产识别过程的宝贵工具。此外，威胁模型促进了与模型中每个元素相关的潜在威胁的系统性（和自动化）推导。因此，目的是开发系统级威胁模型，以表示在之前的头脑风暴等步骤中识别的系统级资产（例如，数据存储、数据流、服务、人员和功能），并添加缺失的元素/资产。

SCU的系统级威胁模型如图6所示。它反映了项目定义的系统结构，包括先前识别的资产组。所描述的威胁模型基于STRIDE方法，并且仅允许有限的一组模型元素，这减少了模型复杂性，并能够自动推导与代表潜在系统资产的每个模型元素相关的威胁。

图6：转向控制系统0级威胁模型

STRIDE方法最初用于IT系统威胁分析，现已用于汽车应用。表1概述了STRIDE威胁、受特定威胁影响的网络安全特性，以及每个威胁组的汽车特定示例。使用STRIDE方法，可以（自动）识别适用于系统级威胁模型中包含的特定元素/资产的威胁。与每种威胁相关的风险在随后的TARA中进行分析。

表1：STRIDE威胁及其受影响的安全属性

2.2 TARA执行

威胁分析和风险评估(TARA)应基于已识别的资产和相关威胁进行。应使用模式对威胁进行分类，并对威胁风险进行适当地估计和分类。由于ISO/SAE 21434没有提供风险评估的规范性分类方案，因此可以采用Heavens或SAHARA等方法。在这项工作中，TARA步骤是基于Heavens方法的。TARA执行的各个步骤和工作产品如图7至图11所示。

图7显示了资产描述的摘录、适用于资产的STRIDE威胁以及特定威胁场景的描述。对于每项资产，可能适用多种STRIDE威胁。合理的威胁场景应从系统级威胁模型中得出，并针对每个适用的威胁进行描述。

在图7所示的特定示例中，ADAS域控制器通过车辆总线传输的转向角请求描述了要分析的资产。该资产在图6中建模为数据流元素，是资产组A01的一部分。根据STRIDE方法，以下三种威胁适用于数据流（即要分析的资产）：篡改、信息泄露和拒绝服务(TID)。图7描述了两种威胁场景，一种用于篡改威胁，另一种用于信息泄露威胁。一般来说，威胁场景描述不应包含预期攻击的（技术）细节。相反，威胁场景应是对预期威胁的高级描述，应使用创建的威胁模型检查其合理性。

图7：威胁场景描述

应针对利益相关者的特定威胁情景的影响（即影响级别（IL））以及成功攻击的可能性（即威胁级别（TL））应对每个威胁情景进行估算。这两个获得的评级合并为一个风险值（即安全级别 (SecL)），用于对特定威胁场景及其关联的资产（即与特定资产和威胁对相关的风险）进行分类。

为了适当估算特定威胁场景对利益相关者的影响，建议定义潜在的损害场景，描述对系统的预期损害以及对利益相关者的影响。示例如图8所示。

图 8：影响分析的潜在损害场景描述

Heavens方法使用四个分类参数来估算不同利益相关者的损坏场景的影响和预期损失：(a)对系统安全的影响，(b)财务影响，(c)对车辆运行/行为/功能的影响，以及(d)隐私和立法影响。这些影响使用从“无影响”到“高影响”的定性等级进行评估，然后合并为最终影响级别评级。图9显示了“意外转向/车辆行为”损坏场景的示例分类（包括理由）。

图9：损坏场景影响级别的分类

一般来说，已识别的损害场景可以映射到多个资产/威胁对及其相关的威胁场景。损坏/影响分析仅考虑最严重的损坏情况。因此，将最高影响级别评级分配给特定的威胁场景，如图10所示。

图10：潜在损害场景与威胁场景的链接

除了影响等级外，还应估计成功攻击的可能性，这由威胁级别（TL）评级表示。该评级基于以下四个参数的估计：(a)攻击者所需的专业知识，(b)攻击者对目标系统的知识，(c)给定的发动攻击的机会窗口，以及 (d)发起攻击所需的设备和工具。系统级威胁模型应作为支持工具，用于估计和证明威胁等级分类。

图11：威胁级别评级的分类以及由此产生的安全级别

图11的左侧部分显示了与ADAS转向角请求消息（即资产）相关的篡改威胁的威胁等级评定及其理由。图11的右侧部分显示了安全等级评定的结果，这是威胁级别和影响级别的组合。安全级别评级描述了与给定资产/威胁对相关的网络安全风险。对于每种适用的威胁，应定义一个网络安全目标。该网络安全目标定义了为降低已识别威胁的风险而应实施的高级网络安全属性。安全级别和网络安全目标的配对，可视为与汽车安全工程中已知的ASIL评级和安全目标配对类似的概念。

网络安全目标可以转化为旨在通过预防潜在威胁的利用来降低网络安全风险的高级网络安全要求。应注意的是，对多个资产/威胁对的评估可能会导致定义类似的网络安全目标。从这些网络安全目标衍生的网络安全需求，应继承与这些网络安全目标相关的最高确定的网络安全级别。

03.网络安全需求获取和可追溯性

网络安全需求源自网络安全目标和客户需求，例如宝马集团标准GS 95014或大众KGAS标准对网络安全（和功能安全）工程的需求。这些需求可以包括功能性和非功能性需求，也可以与特定的开发流程相关联，例如以确保与汽车（网络安全）标准的合规性。这些需求应整合到项目的需求管理系统中，作为网络安全客户需求。

TARA中识别的网络安全目标是在项目开始时特别重要的，用于在客户和供应商之间建立网络安全的共同理解。因此，网络安全目标应与客户和随后的管理层一致，就像客户需求一样。为了确保需求和设计决策之间的可追溯性，网络安全客户需求应与网络安全目标和用于支持TARA流程的中间工作产品相关联。在符合ASPICE的开发过程中，通常会使用需求规范模板。该模板应扩展为包括相关的网络安全属性，例如网络安全目标标识符和安全级别。这些属性可以支持优先考虑网络安全相关的开发活动，并可用于展示网络安全要求的覆盖范围，例如在认证评估期间。

图12举例说明了链接/可追溯性模型。该模型显示了系统分析期间创建的工作产品与从分析结果（即工作产品）衍生的需求之间的追溯链接。绿色圆圈中的数字表示网络安全工程工作流程步骤。红线表示步骤之间的链接和可追溯性标识符。前四个步骤在第2节中进行说明。其余步骤将在下面进行说明。在此之前，给出了需求提出工作流程步骤的总结：

1.应使用头脑风暴和系统建模来识别资产，如第2.1节所述。

2.应使用威胁建模技术来识别和分析资产威胁。此外，应评估与这些威胁相关的风险，如第2.1节和第2.2节所述。

3.网络安全目标应源自TARA（即步骤1和2），如第2.2节所述。

4. 应从网络安全目标和客户的需求规范中衍生客户网络安全需求，如第3节所述。

5.网络安全客户需求应细化/转化为（技术）网络安全系统需求。

6.应识别影响系统网络安全的硬件/软件功能（例如，从总线发送/接收数据、加密算法）。这些功能随后被称为安全关键功能（SCF）。

7.每个功能的目的是处理信息/数据。假设SCF处理的信息/数据影响系统网络安全，例如加密材料、配置数据和总线消息。在这种情况下，该信息/数据应被视为安全关键数据/信息(SCD)并链接到正在处理SCD的SCF。

8. 每个SCD应与处理SCD的SCF互相关联，反之亦然。

9. 应将网络安全目标分配给SCF和SCD元素。通过将分配的网络安全目标，与由TARA过程中识别的网络安全目标确定的SUD网络安全属性进行比较，可以用于识别系统及其设计中的弱点。识别的弱点应推动系统设计的改进和硬件/软件需求的提出。

10.应识别和整合适当的安全设计模式和缓解技术到系统设计中，以解决已识别的弱点。这些模式和技术应记录为硬件/软件需求，并与应实施特定模式所实现的网络安全属性的相应SCD和SCF元素相关联。

11.攻击模式描述了已知网络安全攻击中使用的策略和技术。这些攻击模式可用于支持适当设计模式和缓解技术的衍生，以防止已知攻击。

12.网络安全设计模式和攻击模式，可用于基于针对SUD及其实施的缓解技术的已知攻击和漏洞的系统性安全测试衍生。

图12：链接/可追溯性模型，包括网络安全需求和网络安全分析的工作产品

在接下来的内容中，我们继续探讨SCU示例中的工作流程步骤5，即将网络安全客户需求细化为（技术）网络安全系统需求。在此阶段，已经定义了网络安全目标并将其与资产相关联。此外，这些目标已作为网络安全客户需求整合到需求管理系统中。这些步骤与表2中第1到4项相关，表2提供了相关工作产品和需求的摘录。

在给出的示例中，ADAS转向角请求被归类为高风险资产。定义高级安全目标SecG_01来应对这一风险。接下来，安全目标被分解为两个客户需求及其对应的系统需求Sys_01和Sys_02。按照工作流程步骤7至10，接下来应识别SCF和SCD元素。SCF和SCD元素旨在支持系统分析和需求获取过程。因此，这些元素不一定是描述特定机制实现的需求。相反，这些元素也可以是高级概念、功能、技术和信息，可用于构建设计决策的结构化论证。基于此类论证，应开发（详细的）硬件/软件设计，并得出相应的需求，即步骤9和10。这些步骤将在以下段落中更明确地解释。

表2指出从车辆总线读取消息被识别为安全关键功能SCF_01。为了满足Sys_01，必须以安全的方式认证关键车辆总线消息，这导致定义了软件需求SW_Req_01，即应使用标准AUTOSAR接口进行消息认证。此外，还定义了硬件需求一和二，以确保在硬件级别上适当支持加密算法（例如，安全消息认证算法）的实现。

采用类似的方法来衍生出实施系统需求Sys_02的硬件/软件需求，该需求规定车辆总线消息应安全地记录，以确保不可否认性（即SCF_02）。为此，每个车辆总线消息（即SCD_01）被嵌入到日志条目中（即SCD_02），应写入内存中的先进先出（FIFO）队列（即SW_Req_02）。这个FIFO队列只应在每次系统关闭时存储到安全闪存中，以防止由于频繁使用而导致闪存的损坏（即SW_Req_03）。为了确保即使在恶劣条件下（例如断电），FIFO队列的内容也被写入闪存，硬件安全模块（HSM）应提供加速写入闪存的硬件支持（即HW_Req_03）。

表2：相关分析结果和需求示例。通过下划线突出显示要实现的网络安全属性

上述示例旨在展示如何使用上述定义的工作流程来构建可追溯的论证来支持设计决策，并以结构化的方式提出相关需求。工作流程步骤9至12旨在通过提供识别设计弱点和选择适当的网络安全措施和技术来解决这些弱点的指导，以支持需求提出过程，从而满足所需的系统网络安全属性（即安全目标）。

为了识别设计弱点（即步骤9），首先应识别当前系统设计提供的网络安全属性，并将其分配给SCF和SCD元素。建议使用系统和威胁模型来识别这些属性。其次，网络安全目标（即所需的系统网络安全属性）应分配给SCF和SCD要素。比较分配的所需和提供的属性，以识别系统设计中的差距/弱点。

到目前为止，已经讨论了如何使用网络安全属性来系统地和可追溯地识别设计缺陷。在步骤10中，网络安全属性用于通过基于系统应满足的网络安全属性系统地选择安全设计模式来提高系统安全性。这种方法中选择模式来实现特定的网络安全属性。表3显示了这样的安全设计模式（即高级安全控制）的摘录，这些模式可用于在特定系统级别上实现特定的网络安全属性。其中一些安全控制已在上文中讨论，例如控制流完整性（即Sys_01和相关需求）、安全存储和静态数据加密（即Sys_02和相关需求）。

综上所述，通过选择合适的安全设计模式和缓解机制，可以提高SUD的安全性。此外，这些模式可以支持以结构化和可追溯的方式引导合适的的硬件/软件安全需求和安全测试场景的提出（参见图12）。

表3：适用于各个系统级别的安全设计模式和安全控制示例

04.硬件和软件网络安全前景

上一节讨论了系统网络安全系统和需求工程的流程，其中包括衍生适当的网络安全控制措施以满足特定的网络安全目标。本节简要讨论如何将网络安全控制（例如表3中提供的控制措施）整合到通常用于汽车嵌入式系统的典型AUTOSAR的基础系统栈中。

图13显示了这样的系统堆栈，它被结构化为多个层次。底层由用于代码执行、数据存储和连接的硬件元件组成。硬件安全模块（HSM）也位于此层。HSM提供硬件支持用于安全地存储和访问私钥材料，这对于充分实现各种高级安全控制至关重要。此外，HSM还可能提供硬件加速的加密算法，即使需要对毫秒和亚毫秒范围内安全保护循环通信，也能满足汽车网络系统的严格实时要求。

图13：基于AUTOSAR的分层硬件/软件堆栈

与其他硬件组件一样，HSM可以通过位于微控制器抽象层(MCAL)的驱动程序集成到软件堆栈中。在图13中，该驱动程序表示为虚拟HSM(vHSM)。假设没有专用的硬件HSM，HSM功能可以通过软件模拟。因此，vHSM可以将服务请求转发到位于复杂驱动程序层的基于软件的HSM实现。值得注意的是，基于软件的HSM方法不如使用专用HSM安全。

应用程序（例如app1）可以通过运行时环境(RTE)层访问HSM的专用加密服务，RTE指定了与加密服务管理器（CSM）的接口。RTE将应用程序的服务请求转发到位于AUTOSAR核心操作系统(OS)层的系统服务和CSM。除了通过RTE直接访问HSM之外，还可以配置位于AUTOSAR OS层的通信服务，以管理HSM服务的使用，以建立安全的车载通信(SecOC)会话。在这种情况下，SecOC服务被配置为检查和确保特定消息的真实性，使基于HSM的安全机制对应用层透明。

除了HSM之外，还利用几个其他组件和安全控制来确保系统安全。例如，实施安全启动过程应确保整个软件系统的完整性，包括系统固件和持久数据。为此目的，在EoL生产过程中可以建立所谓的信任锚（另请参见第1节），例如通过将主引导程序的公钥哈希(PKH)存储在微控制器的OTP熔丝内。每次系统启动时，微控制器首先使用PKH来验证引导加载程序的完整性。只有在可以验证引导加载程序的完整性（即引导程序未被篡改）时，引导过程才会继续。在随后的启动阶段，可以通过检查固件和数据的签名的有效性来验证它们，例如使用EoL生产过程中存储在HSM内的密钥材料。

05.结论

目前，将网络安全集成到汽车行业的开发流程中仍处于早期阶段，尚无普遍接受的最新技术。ISO/SAE 21434标准是朝这个方向迈出的重要一步。然而，在现阶段，ISO/SAE 21434仅提供了关于如何设计此类开发流程的粗略指导。因此，本文旨在提供可操作的步骤和方法，帮助工程师将安全系统设计技术和系统性网络安全需求提出方法集成到他们已建立的开发流程中。本工作使用案例研究来演示在电动助力转向系统示例中应用所提出的步骤和方法。所呈现的案例研究和工作流程是根据实际专家知识和前期研究结果结合汽车系统工程领域的需求而衍生出来的。我们未来的工作包括在更多项目中验证和完善所呈现的方法，并将结果和见解反馈给不同的标准化工作组中。此外，我们旨在开发一个通用的安全驱动开发生命周期模型，用于当前和未来汽车电子系统和架构的开发。