技术领域
[0001] 本申请属于信息处理技术领域，尤其涉及一种舱驾融合系统、安全保障方法及相关设备。
相关背景技术
[0002] 随着汽车电子技术及芯片技术的发展，以及人们对汽车的要求也越来越高，近几年出现了大量的技术创新及跨界应用。舱驾融合是其中一个，舱驾融合将座舱域和智能驾驶域进行跨域融合，形成一个统一的域控制器。
[0003] 舱驾融合的趋势有助于提高用户体验和整车性能，但也面临一些功能安全和信息安全的风险。
[0004] 因此，如何提升舱驾融合系统的安全性是一个亟待解决的问题。
具体实施方式
[0027] 下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本申请，并不被配置为限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。
[0028] 需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0029] 首先，对于本申请实施例涉及的技术术语进行介绍。
[0030] 舱驾融合，指以降低硬件成本为目的，将原车载智能座舱(娱乐、导航系统及仪表)与自动驾驶功能的软件部分(分属于不同的硬件)，部署到同一个硬件系统中，以节约使用的芯片、电路板及物理总线的数量。
[0031] 可信执行环境，可信执行环境是一种安全的计算环境，旨在保护敏感数据和执行关键任务时的计算过程免受恶意软件和攻击的影响。它是一个硬件和软件的组合，提供了一种隔离和保护计算环境的方式，可信执行环境具体可以包括：
[0032] 可信执行环境(Trusted Execution Environment，TEE)，是一种安全的计算环境，它提供了一种可信的安全环境，确保敏感数据和代码的安全性和隐私性。TEE通常是由硬件和软件组成的，可以在普通的操作系统之上运行，提供一种安全的运行环境，使得恶意软件无法获取或篡改TEE中的数据和代码。
[0033] 硬件安全模块(Hardware Security Module，HSM)是一种用于保护和管理强认证系统所使用的密钥，并同时提供相关密码学操作的计算机硬件设备。硬件安全模块一般通过扩展卡或外部设备的形式直接连接到电脑或网络服务器。
[0034] 安全芯片(Secure Hardware Extension，SHE)。安全芯片就是可信任平台模块，是一个可独立进行密钥生成、加解密的装置，内部拥有独立的处理器和存储单元，可存储密钥和特征数据，提供加密和安全认证服务。用安全芯片进行加密，密钥被存储在硬件中，被窃的数据无法解密，从而保护商业隐私和数据安全。
[0035] 可信平台模块(Trusted Platform Module，TPM)，是一种植于计算机内部为计算机提供可信根的芯片。该芯片的规格由可信计算组来制定。
[0036] 应用程序域(AppDomain)，也称应用域，它由公共语言运行库围绕同一应用程序范围内创建的对象建立。即，从应用程序入口点开始，沿着对象激活的序列的任何位置。应用程序域有助于将在一个应用程序中创建的对象与在其他应用程序中创建的对象隔离，以使运行时行为可以预知。在一个单独的进程中可以存在多个应用程序域。
[0037] 密钥，密钥是完成加解密所必需的参数。它在密码学中扮演关键角色，用于保护数据的安全性和完整性。分为对称密钥和非对称密钥。
[0038] 数据完整性，数据完整性可以确保数据反映实际情况，避免错误、虚假或误导性的信息影响决策和业务的正确性。
[0039] 数据私密性，数据私密性指是指保护个人数据，使不应访问数据之人无法访问，以及个人能够决定谁可以访问其个人信息。
[0040] 车载电子功能安全，汽车功能安全是指实施保护措施，以消除或减轻由车辆级系统的故障或意外行为引起的危险。功能安全的定义如下：
[0041] 不存在由电子电气系统的故障行为导致的危险所造成的不合理的风险。
[0042] 风险的度量综合考虑了伤害发生的可能性和伤害程度。
[0043] 不合理的风险是根据有效的社会道德观念，在特定情况下被判定为不可接受的风险。
[0044] 功能安全讨论的伤害是对人身健康及生命造成的伤害，而不包括机械问题带来的风险。
[0045] 车载电子信息安全，更加类似于传统行业中的保护系统、网络、软件安全的概念，但相比于传统行业中的信息安全(Information Security，企业经常用到的ISO 27001信息安全管理体系ISMS)，汽车信息安全范围更小，更加偏向于来自网络的外部攻击、恶意操作等的管理。
[0046] 冗余设计，又称余度设计技术，是一种在关键系统或设备中增加备份组件或通道的策略。其核心理念在于，当系统中的某一部分出现故障时，冗余部分能够立即接管其功能，从而确保系统或设备的正常运行，减少故障概率，提高整体可靠性。
[0047] 随机硬件失效，随机硬件失效是指在硬件中，由一种或几种可能的退化机理而产生的，在随机时间出现的失效。这类失效主要是由硬件元器件引起的，其产生原因较为复杂，包括内因和外因。内因主要来自于元器件的材料缺陷、加工工艺问题等；外因则主要涉及元器件的应用环境，例如电气过载、机械应力和温度。
[0048] 功能安全目标，功能安全目标是最高层级的安全需求，旨在避免危害事件的不合理风险。它不是技术解决方案，而是表示功能目的，功能安全目标是整个功能安全开发的基础，确保系统在各种情况下都能安全运行。
[0049] 攻击面攻击车载ECU，可以获得非法访问权限，从中获取数据、控制或影响其运行。这些攻击可能涉及应用程序、数据传输、物理接口等多个层面，如网络接口、Flash、USB，Wifi，Bt等。
[0050] 单点失效，单点失效是指由单点故障引起并直接导致违背安全目标的失效。这意味着某个功能元素的诊断覆盖率为0，即无法被安全机制探测到，而其残余失效会直接影响安全目标。
[0051] 状态寄存器又名条件码寄存器，它是计算机系统的核心部件——运算器的一部分，状态寄存器用来存放两类信息：一类是体现当前指令执行结果的各种状态信息；另一类是存放控制信息。
[0052] 微控制单元(Microcontroller Unit，MCU)，是把中央处理器(Central Process Unit，CPU)的频率与规格做适当缩减，并将内存(memory)、计数器(Timer)等周边接口都整合在单一芯片上，形成芯片级的计算机，为不同的应用场合做不同组合控制。
[0053] 系统级芯片(System on Chip，SoC)，意指它是一个产品，是一个有专用目标的集成电路，其中包含完整系统并有嵌入软件的全部内容。
[0054] 安全岛(Safety Island，SAIL)，基于SoC内置安全芯片的概念，在SoC内放置一颗运行实时系统的芯片，并且可以对SoC内部软硬件故障进行精细的监控并引导系统进入安全状态。
[0055] 高级驾驶辅助系统(Advanced Driving Assistance System，ADAS)是利用安装在车上的各式各样传感器(毫米波雷达、激光雷达、单\双目摄像头以及卫星导航)，在汽车行驶过程中随时来感应周围的环境，收集数据，进行静态、动态物体的辨识、侦测与追踪，并结合导航地图数据，进行系统的运算与分析，从而预先让驾驶者察觉到可能发生的危险，有效增加汽车驾驶的舒适性和安全性。
[0056] 车载信息娱乐(In‑Vehicle Infotainment，IVI)系统，是采用车载专用中央处理器，基于车身总线系统和互联网服务，形成的车载综合信息处理系统。
[0057] 串行外设接口(Serial Peripheral Interface，Spi)是一种同步外设接口，它可以使单片机与各种外围设备以串行方式进行通信以交换信息。
[0058] 千兆多媒体串行链路(Gigabit Multimedia Serial Links，GMSL)，一种高速串行接口，适用于音频,视频和控制信号的传输。
[0059] 控制器局域网总线(CAN，Controller Area Network)是一种用于实时应用的串行通讯协议总线，它可以使用双绞线来传输信号，是世界上应用最广泛的现场总线之一。CAN协议用于汽车中各种不同元件之间的通信，以此取代昂贵而笨重的配电线束。
[0060] 可变速率CAN(CAN with Flexible Data rate，CAN FD)继承了CAN总线的主要特性，CAN FD总线弥补了CAN总线带宽和数据场长度的制约。
[0061] 液晶显示器(Liquid Crystal Display，LCD)，为平面超薄的显示设备。
[0062] 本申请实施例提供的舱驾融合系统至少可以应用于下述应用场景中，下面进行说明。
[0063] 随着汽车电子技术及芯片技术的发展，以及人们对汽车的要求也越来越高，近几年出现了大量的技术创新及跨界应用。舱驾融合是一个在智能汽车领域逐渐崭露头角的概念。
[0064] 舱驾融合是将座舱域(智能座舱)和智能驾驶域进行跨域融合，形成一个统一的域控制器。具体地，它将座舱内的功能(例如人机交互、沉浸式体验等)与智能驾驶的各项功能深度结合，从而提升用户的安全感和舒适感，增强对智能汽车的使用体验。
[0065] 舱驾融合系统的重要性体现在以下几个方面：
[0066] 涉及用户体验方面，舱驾融合可以改善驾驶员和乘客的体验，使智能座舱和智能驾驶之间更加无缝地互动。涉及成本效益方面，通过融合，可以降低软硬件成本，简化设计，并提高应用的灵活性。涉及技术发展方面，随着智能驾驶技术的发展，舱驾融合将成为未来的发展趋势。
[0067] 舱驾融合在技术实现上主要体现在以下两个方面：
[0068] 在硬件上，舱驾融合可以通过将座舱和智能驾驶功能部署在同一颗SoC芯片上来实现。这样的设计可以降低成本并提高性能。
[0069] 在软件上，舱驾融合需要考虑如何改变整体软件架构，使其更适用于舱驾融合系统。引入面向服务的设计理念和工具可以帮助实现这一目标。
[0070] 典型的舱驾融合系统的系统框图如图1所示：
[0071] 舱驾融合系统，应用于域控制器，系统包括：系统级芯片SoC和微控制单元MCU，SoC包括主计算单元和安全岛单元，具体如下所示：
[0072] 主计算单元的软件运行环境基于实时操作系统QNX虚拟化技术，被划分为主环境与客户虚拟机；
[0073] 主环境，用于运行仪表系统和自动驾驶系统；
[0074] 客户虚拟机，用于运行车载信息娱乐系统；
[0075] 安全岛单元，用于根据获取到的故障信息输出控制信息，控制信息用于控制域控制器进入安全状态。
[0076] 舱驾融合系统的信号输入部分，包括，毫米波雷达(CANFD总线)，超声波雷达(SPI总线)，高清摄像头(前置GMSL2，车身GMSL)，无线网络信号，蓝牙信号，USB外设输入及其它车辆网络信号(CANFD网络，以太网，Lin网络及硬线信号等)；
[0077] 数据处理部分，包括：MCU硬件及部分软件组件，SoC内置安全岛硬件及部分软件组件，SoC主环境硬件及部分软件组件；
[0078] 数据输出部分，包括仪表系统的显示输出、导航娱乐的显示输出、副驾驶位的显示输出，驾驶位的抬头显示输出，Speaker输出，Wifi/Bt输出，自动驾驶车控信号输出等。
[0079] 舱驾融合的趋势有助于提高用户体验和整车性能，但也面临一些功能安全和信息安全的风险。下面列举一些可能的功能安全和信息安全风险：
[0080] 涉及功能安全方面，存在以下风险：
[0081] 将座舱和智能驾驶功能整合到同一芯片或板上可能导致硬件故障或不稳定性，即存在硬件融合层面的风险。
[0082] 在软件层面整合功能时，需要确保不同功能之间的交互不会导致系统崩溃或功能失效，即存在软件融合层面的风险。
[0083] 确保座舱和智能驾驶功能之间的数据隔离，以防止恶意攻击或故障传播，即存在安全隔离层面的风险。
[0084] 涉及信息安全方面，存在以下风险：
[0085] 跨域融合可能导致座舱和智能驾驶之间的数据共享，这可能增加信息泄露或未经授权的访问的风险，即存在数据共享层面的风险。
[0086] 连接到外部网络的系统容易受到黑客攻击，因此需要强化网络安全措施，即存在网络连接层面的风险。
[0087] 整合的软件可能存在漏洞，这可能导致信息泄露或功能失效，即存在软件漏洞层面的风险。
[0088] 传统的功能安全使用端到端(E2e)保护机制来保障车内网络信号在传递过程中，不被随机硬件失效破坏数据的完整性，例如，网络总线的故障导致数据随机的Bit位反转，导致仪表不能正确的亮起或者熄灭，从而影响功能安全目标。
[0089] 从检测硬件随机失效的角度看，E2e实施的保护机制可以满足功能安全的要求，但由于车载电子架构大规模融合的现状下，以往与外界隔离的系统(自动驾驶系统)由于与座舱域ECU的融合，导致信息安全的攻击面大大增加，如出现了以往在自驾系统上不存在的Wifi、Bt、USB、屏幕(人机交互)等等。
[0090] 这些攻击面的增加，导致了威胁总线上的数据完整性的风险不再只有硬件随机失效，更多及严重的风险来自于网络上恶意攻击。传统E2e采用的CRC，连续计数等方式，在信息安全攻击手段下，很容易就会被破解。
[0091] 在信息安全领域，保障数据完整性的机制更多的是基于密码学机制，对数据进行采样(Hash，含连续计数，并在整车网络同步)并对Hash值加密的形式，来确保数据没有被恶意篡改。由于攻击者没有加密用的密钥，所以也就无法对数据进行篡改和仿冒了。
[0092] 虽然基于信息安全的数据完整性保护提升传统的保护机制的可靠性，却又引入了新的问题。基于密码学的完整性保护依赖于密钥的安全性与计算过程的硬件加速。如图2所示，计算单元200，运行有：
[0093] 应用程序210、密钥管理组件220、密码学引擎230、硬件抽象层240和可信执行环境250。
[0094] 其中，密钥保存在由可信执行环境，如TEE，HSM，SHE或TPM管理的存储区中，这部分数据的访问与应用域(包括操作系统及Hypervisor在内)在硬件上隔离的，来保障数据安全。
[0095] 加解密等操作也是由应用域的密码学引擎将数据传递到可信执行环境中，在可信执行环境中利用硬件完成加解密后返回到应用域中，在这个过程中，密钥是不会离开可信执行环境的。
[0096] 但正如信息安全领域的风险影响功能安全目标的达成一样，功能安全中的一些风险也会影响到信息安全机制的实现：在这个场景中，可信执行环境也是基于硬件实现，因此就存在硬件随机失效的风险，而且由于计算芯片内，通常只配置一个可信执行环境，一旦出现硬件故障，导致密钥无法访问或者加解密引擎不能正常工作，则成为功能安全领域的单点失效，这会直接影响高功能安全等级需求(如自驾系统)的实现。
[0097] 因此，有必要设计一种机制在信息安全与功能安全风险同时存在的情况下，满足舱驾融合系统高安全等级要求。
[0098] 基于上述应用场景，下面对本申请实施例提供的舱驾融合系统进行详细说明。
[0099] 本申请实施例提供的舱驾融合系统应用于域控制器，具体可以应用于基于高性能计算(High Performance Computing，HPC)系统的域控制器，其中，HPC系统是利用超级计算机实现并行计算的理论、方法、技术以及应用的一种软件系统。
[0100] 车载域控制器(In‑vehicle Domain Controller，IVDC)，是指安装在汽车中的一种电子控制单元。它负责集成和管理车辆内各个子系统的功能和数据，如发动机控制、车身电控、座舱电控等。车载域控制器的作用是实现车辆内部的各种功能的协调和控制，并提供车辆内部系统之间的通信和数据交换。IVDC也可简称为域控制器。
[0101] 如图3所示，系统包括：计算单元200和外置安全芯片280；计算单元200运行有：可信执行环境250、外置安全芯片驱动270及可信执行环境的状态管理组件260；外置安全芯片280提供可信执行环境250的硬件备份；其中，
[0102] 可信执行环境的状态管理组件260，用于接收计算单元中200运行的应用程序发送的调用请求，调用请求用于请求执行涉密操作；以及，在检测到可信执行环境250存在异常的情况下，通过外置安全芯片驱动270将调用请求传输至外置安全芯片280；
[0103] 其中，应用程序可以为操作系统中的应用程序，操作系统，包括：
[0104] 仪表系统、自动驾驶系统和车载信息娱乐IVI系统。
[0105] 应用程序发送的调用请求，具体可以为：操作系统中的软件组件发送的调用请求。
[0106] 涉密操作，包括下述中的至少一项：
[0107] 加密操作、解密操作，哈希操作，密钥派生操作和随机数生成操作。可信执行环境250存在异常的情况，包括下述中的至少一项：状态寄存器值异常；
[0108] 内部进程间通信性能异常
[0109] 可信执行环境中软件完整性错误；
[0110] 可信执行环境中的应用返回值错误。
[0111] 这里，由于系统中的涉密操作，应该基于计算单元200中内置的可信执行环境250进行，在检测到可信执行环境250存在异常的情况下，则认为计算单元200内可信执行环境出现故障，需要使用备份的外置安全芯片280来保障车辆的通信安全。
[0112] 外置安全芯片驱动270，用于接收可信执行环境的状态管理组件260发送的调用请求；以及，将调用请求传输至外置安全芯片280；
[0113] 外置安全芯片驱动270，会在可信执行环境250存在异常的情况下，接收到可信执行环境的状态管理组件260发送的调用请求，此时，为了保障车辆的通信安全，将调用请求传输至外置安全芯片280，以用于外置安全芯片280执行调用请求所请求的涉密操作。
[0114] 外置安全芯片280，用于在接收到调用请求的情况下，执行调用请求所请求的涉密操作。
[0115] 由于外置安全芯片的通信性能的原因，比较适合做小数据量的加解密操作，因此，系统内的密码学引擎发起的加解密，Hash，密钥派生，随机数生成等涉密操作的调用请求与数据通信，将通过可信执行环境状态管理组件，重定向到外置安全芯片中进行。
[0116] 下面从硬件和软件的角度分别说明：
[0117] 相对于传统的信息安全解决方案，依赖于单可信执行环境，本申请的实施例在硬件上增加外置信息安全芯片，通过硬件总线(I2c，Spi，Uart等)与计算单元(MCU或者SoC)连接，提供可信执行环境的硬件备份。
[0118] 在软件上，本申请的实施例增加外置安全芯片驱动及可信执行环境状态管理组件，外置安全芯片驱动负责在特定的操作系统中(如，Linux，Android，QNX，AUTOSAR CPOS，FreeRTOS或者SafeRTOS等)建立应用域与外置安全芯片的通信连接。
[0119] 其中，计算单元可以包括：MCU与SoC，下面分别进行说明：
[0120] 由于MCU与SoC所使用的通信密钥不同，因此分别在MCU与SoC上外接外置安全芯片，并在MCU与SoC上部署密钥管理组件，密码学引擎，可信执行环境状态管理组件与外置安全芯片驱动。
[0121] 如图4所示，MCU300用于运行：
[0122] 密钥管理组件320，密码学引擎330，可信执行环境的状态管理组件360与外置安全芯片驱动370，以及可信执行环境350。
[0123] MCU300外接有外置安全芯片380。
[0124] 在计算单元为SoC400的情况下，计算单元的软件运行环境，包括：主环境与客户虚拟机。
[0125] SoC400外接有外置安全芯片480。
[0126] 其中，客户虚拟机410用于运行IVI系统、IVI系统对应的第一密钥管理组件411和IVI系统对应的密码学引擎412。
[0127] 主环境也称SoC主计算单元，SoC主计算单元420，用于运行：
[0128] 仪表系统430、自动驾驶系统440、第二密钥管理组件421、密码学引擎422、可信执行环境的状态管理组件460、外置安全芯片驱动470。
[0129] 下面对主环境与客户虚拟机分别进行说明：
[0130] 在一种可能的实施例中，计算单元的软件运行环境，包括：主环境与客户虚拟机；
[0131] 客户虚拟机，用于运行车载信息娱乐IVI系统；
[0132] 主环境，用于运行仪表系统、自动驾驶系统、外置安全芯片驱动和可信执行环境的状态管理组件。
[0133] 由于车载信息娱乐系统与具有功能安全需求的软硬件系统集成在同一平台上，需要进行隔离，避免娱乐信息系统的故障影响到其它系统，从而导致人身伤害的风险。
[0134] 因此需要将SoC内的主计算单元的软件运行环境分为两个部分：主环境与客户虚拟机。如图3所示，在主环境中，运行高功能安全等级要求的仪表系统和自动驾驶系统；在客户虚拟机中，运行低功能安全等级的车载信息娱乐系统。
[0135] 由于车载信息娱乐系统需要基于无线网络或者蓝牙进行数据传输，以及使用串行总线(Universal Serial Bus，USB)接口与以太网(Ethemet)同外界通信，可以仅分配车载信息娱乐系统需要的无线网络设备或者蓝牙设备，USB外设(含OTG)及以太网设备到娱乐信息系统。
[0136] 这样娱乐信息系统中的服务与进程仅能访问暴露出来的设备，从而避免低功能安全等级的车载信息娱乐系统破坏高功能安全等级的仪表系统中的数据完整性。提升舱驾融合系统的安全性。
[0137] 如图4所示，在IVI系统中，IVI系统与可信执行环境的通信都是基于虚拟化环境进行，与可信执行环境和外置安全芯片的通信都是基于虚拟化环境进行，因此只需要部署密钥管理组件与密码学引擎即可。
[0138] 在主环境中，需要部署：仪表系统430、自动驾驶系统440、第二密钥管理组件421、密码学引擎422、可信执行环境的状态管理组件460、外置安全芯片驱动470。
[0139] 由此，可以将车载信息娱乐系统与具有功能安全需求的软硬件系统进行隔离，并在主环境中部署外置安全芯片驱动和可信执行环境的状态管理组件，以便于保障计算单元的整体安全性。
[0140] 在一种可能的实施例中，客户虚拟机，用于运行第一密钥管理组件；
[0141] 主环境，用于运行第二密钥管理组件；
[0142] 可信执行环境的状态管理组件，还用于接收第二密钥管理组件发送的IVI系统的调用请求；IVI系统的调用请求是由第一密钥管理组件发送至第二密钥管理组件的。
[0143] 在IVI系统中的软件组件存在执行涉密操作的需求时，IVI系统中的软件组件向第一密钥管理组件发送调用请求；
[0144] 第一密钥管理组件在接收到IVI系统中的软件组件发送的调用请求的情况下，通过内部通信的方式将调用请求传输至第二密钥管理组件；
[0145] 第二密钥管理组件在接收到第一密钥管理组件发送的IVI系统的调用请求的情况下，将调用请求传输至可信执行环境的状态管理组件，以用于第二密钥管理组件在检测到可信执行环境存在异常的情况下，通过外置安全芯片驱动270将调用请求传输至外置安全芯片280。
[0146] 由此，可以保障IVI系统的调用请求也可以被安全和及时的响应。
[0147] 在一种可能的实施例中，外置安全芯片，还用于在接收到调用请求的情况下，执行下述中的至少一项：
[0148] 对密钥的注入操作、对密钥的更新操作和对密钥的销毁操作；
[0149] 其中，密钥为涉密操作中使用的密钥。
[0150] 为了支持加解密，Hash，密钥派生，随机数生成等操作的重定向，密钥管理组件也要进行相应的功能变更。
[0151] 由于增加了外置安全芯片的备份，需要同步将对密钥的注入操作、对密钥的更新操作和对密钥的销毁操作在外置安全芯片上执行一遍，确保可信执行环境与外置安全芯片中存储的密钥信息一致。
[0152] 由此，外置安全芯片通过在接收到调用请求的情况下，执行对密钥的注入操作、对密钥的更新操作和对密钥的销毁操作，能够保障可信执行环境与外置安全芯片中存储的密钥信息一致。
[0153] 在一种可能的实施例中，可信执行环境状态管理组件，还用于实时监控可信执行环境的硬件状态信息；以及，
[0154] 根据可信执行环境的硬件状态信息，检测可信执行环境是否存在异常。
[0155] 可信执行环境状态管理组件在系统运行过程中，实时监控可信执行环境的硬件状态信息。
[0156] 硬件状态信息，包括：状态寄存器值、内部进程间通信性能、可信执行环境中软件完整性和可信执行环境中的应用返回值。
[0157] 根据可信执行环境的硬件状态信息，检测可信执行环境是否存在异常，具体可以包括：
[0158] 判断状态寄存器值是否正确；
[0159] 内部进程间通信性能是否无异常；
[0160] 可信执行环境中软件完整性是否正确；
[0161] 可信执行环境中的应用返回值是否正确。
[0162] 由此，根据可信执行环境的硬件状态信息，可以快速准确地检测可信执行环境是否存在异常。
[0163] 在一种可能的实施例中，外置安全芯片驱动，还用于建立应用程序的应用域，以用于应用域中的软件组件通过外置安全芯片驱动与外置安全芯片建立通信连接。
[0164] 应用程序的应用域，可以包括：
[0165] 仪表系统的应用域、自动驾驶系统的应用域和车载信息娱乐IVI系统的应用域。
[0166] 建立应用程序的应用域的目的是，使应用域中的软件组件通过外置安全芯片驱动与外置安全芯片建立通信连接。
[0167] 在一种可能的实施例中，系统还包括：外置安全芯片的检测单元；
[0168] 检测单元，用于在预设时间周期内，对外置安全芯片进行芯片检测操作，得到芯片检测结果；以及，
[0169] 在芯片检测结果为异常结果的情况下，输出芯片异常提示信息。
[0170] 预设时间周期可以为系统的上电周期。
[0171] 为了保证备份的外置安全芯片的正确性，系统在一个上电周期内，还需要至少对外置安全芯片的正确性进行一次检测。
[0172] 例如，在系统启动时，系统正常工作时或者系统下电时，对外置安全芯片进行芯片检测操作，得到芯片检测结果。
[0173] 芯片检测结果，包括：异常结果和正常结果。
[0174] 由此，芯片检测结果为异常结果的情况下，输出芯片异常提示信息，以便于提示此时外置安全芯片出现异常。
[0175] 在一种可能的实施例中，芯片检测操作，包括：
[0176] 读取外置安全芯片的状态寄存器值；
[0177] 根据状态寄存器值，确定芯片检测结果；或者，
[0178] 读取外置安全芯片生成的测试随机数；
[0179] 根据测试随机数，确定芯片检测结果；或者，
[0180] 读取外置安全芯片使用测试密钥对测试数据进行加密的第一加密结果，和可信执行环境使用测试密钥对测试数据进行加密的第二解密结果；
[0181] 根据第一加密结果和第二加密结果，确定芯片检测结果。
[0182] 对外置安全芯片进行芯片检测操作的方法包括：
[0183] 第一种，读取外置安全芯片的状态寄存器值，根据状态寄存器值，确定判断外置安全芯片是否存在异常，以确定芯片检测结果。
[0184] 第二种，使外置安全芯片进行随机数生成操作，读取外置安全芯片生成的测试随机数，根据测试随机数，确定芯片检测结果。
[0185] 具体地，在随机数存在非随机的情况下，确定芯片检测结果为异常结果；或者，在多次生成的随机数相同的情况下，确定芯片检测结果为异常结果；或者，多次生成的随机数为规律性的重复数字的情况下，确定芯片检测结果为异常结果。
[0186] 第三种，读取外置安全芯片使用测试密钥对测试数据进行加密的第一加密结果，和可信执行环境使用测试密钥对测试数据进行加密的第二解密结果；也就是说，使用同一个测试密钥，在可信执行环境中与外置安全芯片中，针对相同的测试数据进行加密操作，判断加密后的加密结果是否一致。由此，可以根据第一加密结果和第二加密结果，确定芯片检测结果。
[0187] 因此，通过对外置安全芯片进行芯片检测操作，得到芯片检测结果，便于及时掌握外置安全芯片的安全情况。
[0188] 本申请实施例提供的舱驾融合系统，应用于域控制器，系统包括：计算单元和外置安全芯片；计算单元运行有：可信执行环境、外置安全芯片驱动及可信执行环境的状态管理组件。其中，可信执行环境的状态管理组件，用于接收计算单元中运行的应用程序发送的调用请求，调用请求用于请求执行涉密操作；以及，在检测到可信执行环境存在异常的情况下，通过外置安全芯片驱动将调用请求传输至外置安全芯片，这里，在检测到可信执行环境存在异常的情况下，也就是说，在由于可信执行环境存在异常，可能会导致出现功能安全问题的情况下，通过外置安全芯片驱动将调用请求传输至外置安全芯片，以用于外置安全芯片在接收到调用请求的情况下，执行调用请求所请求的涉密操作。也就是说，本申请的实施例，无需存在异常的可信执行环境执行调用请求所请求的涉密操作，而是由外置安全芯片执行调用请求所请求的涉密操作。由此，能够解决目前由于硬件故障导致的可信执行环境存在异常，从而影响舱驾融合系统的功能安全的问题，能够提升舱驾融合系统的安全性。
[0189] 基于上述舱驾融合系统，下面对本申请实施例提供的安全保障方法进行详细说明。
[0190] 图5为本申请实施例提供的一种安全保障方法的流程图。
[0191] 该安全保障方法可以包括步骤510‑步骤540，应用于域控制器，域控制器中部署的舱驾融合系统包括：计算单元和外置安全芯片，计算单元运行有：可信执行环境和外置安全芯片驱动，具体如下所示：
[0192] 步骤510，接收计算单元中运行的应用程序发送的调用请求，调用请求用于请求执行涉密操作；
[0193] 步骤520，在检测到可信执行环境存在异常的情况下，通过外置安全芯片驱动将调用请求传输至外置安全芯片，以用于外置安全芯片执行调用请求所请求的涉密操作。
[0194] 本申请实施例，通过接收计算单元中运行的应用程序发送的调用请求，调用请求用于请求执行涉密操作；以及，在检测到可信执行环境存在异常的情况下，通过外置安全芯片驱动将调用请求传输至外置安全芯片，这里，在由于可信执行环境存在异常，可能会导致出现功能安全问题的情况下，通过外置安全芯片驱动将调用请求传输至外置安全芯片，以用于外置安全芯片在接收到调用请求的情况下，执行调用请求所请求的涉密操作。也就是说，本申请的实施例，无需存在异常的可信执行环境执行调用请求所请求的涉密操作，而是由外置安全芯片执行调用请求所请求的涉密操作。由此，能够解决目前由于硬件故障导致的可信执行环境存在异常，从而影响舱驾融合系统的功能安全的问题，能够提升舱驾融合系统的安全性。
[0195] 基于上述图5所示的安全保障方法，本申请实施例还提供一种安全保障装置，应用于域控制器，域控制器中部署的舱驾融合系统包括：计算单元和外置安全芯片，计算单元运行有：可信执行环境和外置安全芯片驱动，如图6所示，该装置600可以包括：
[0196] 接收模块610，用于接收计算单元中运行的应用程序发送的调用请求，调用请求用于请求执行涉密操作；
[0197] 传输模块620，用在检测到可信执行环境存在异常的情况下，通过外置安全芯片驱动将调用请求传输至外置安全芯片，以用于外置安全芯片执行调用请求所请求的涉密操作。
[0198] 本申请实施例，通过接收计算单元中运行的应用程序发送的调用请求，调用请求用于请求执行涉密操作；以及，在检测到可信执行环境存在异常的情况下，通过外置安全芯片驱动将调用请求传输至外置安全芯片，这里，在由于可信执行环境存在异常，可能会导致出现功能安全问题的情况下，通过外置安全芯片驱动将调用请求传输至外置安全芯片，以用于外置安全芯片在接收到调用请求的情况下，执行调用请求所请求的涉密操作。也就是说，本申请的实施例，无需存在异常的可信执行环境执行调用请求所请求的涉密操作，而是由外置安全芯片执行调用请求所请求的涉密操作。由此，能够解决目前由于硬件故障导致的可信执行环境存在异常，从而影响舱驾融合系统的功能安全的问题，能够提升舱驾融合系统的安全性。
[0199] 图7示出了本申请实施例提供的一种域控制器的硬件结构示意图。
[0200] 在域控制器可以包括处理器701以及存储有计算机程序指令的存储器702。
[0201] 具体地，上述处理器701可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。
[0202] 存储器702可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器702可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器702可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器702可在综合网关容灾设备的内部或外部。在特定实施例中，存储器702是非易失性固态存储器。在特定实施例中，存储器702包括只读存储器(ROM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(PROM)、可擦除PROM(EPROM)、电可擦除PROM(EEPROM)、电可改写ROM(EAROM)或闪存或者两个或更多个以上这些的组合。
[0203] 处理器701通过读取并执行存储器702中存储的计算机程序指令，以实现图所示实施例中的任意一种安全保障方法。
[0204] 在一个示例中，域控制器还可包括通信接口703和总线710。其中，如图7所示，处理器701、存储器702、通信接口703通过总线710连接并完成相互间的通信。
[0205] 通信接口703，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。
[0206] 总线710包括硬件、软件或两者，将域控制器的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI‑Express(PCI‑X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线710可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。
[0207] 该域控制器可以执行本申请实施例中的安全保障方法，从而实现结合图6描述的安全保障方法。
[0208] 另外，结合上述实施例中的安全保障方法，本申请实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现图6中的安全保障方法。
[0209] 需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。
[0210] 以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD‑ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。
[0211] 还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。
[0212] 以上所述，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。
