一种智能座舱车控系统的安全访问方法、设备及介质

本发明属于车控系统安全访问的技术领域，具体涉及一种智能座舱车控系统的安全访问方法、设备及介质。

目前市面各大汽车厂商智能座舱系统功能逐渐完善，车控功能作为极其重要的一部分，其安全性得到了极大重视。以Android为主流的智能座舱系统，应用通过CarService对汽车进行控制，但目前对于应用车控权限的把控不够严格，导致存在一定安全隐患。

针对存在的安全隐患，申请号为2021114342131的专利提供了一种安卓Treble架构下CarService代码配置生成方法，通过配置及代码生成提高了车辆服务CarService接口代码编写的效率和容错率，但是并没有解决当前的车控安全问题。申请号为201710328780提供了一种汽车功能接口安全授权访问方法，并具体公开到：应用程序审核模块对应用程序的安全性进行审核，并对通过审核的应用程序进行签名，经过签名的非内置应用程序被直接发送至智能车载终端，经过签名的内置应用程序通过应用及策略预置单元被预置于智能车载终端，实现了智能车载终端对不同类型汽车功能接口的安全授权访问；但其通过网络将签名的应用预置到车载终端，不是通过第三方应用商城下载，也不是通过U盘等方式离线安装，导致过度依赖于网络，实时性差；同时该方法仅是通过签名限制对车控接口的调用，对于三方应用不能确定其内部实际使用了哪些车控信号，所以无法达到精确限制到每一个车控信号。

本发明的主要目的在于克服现有技术的缺点与不足，本发明的目的在于为智能座舱车控系统打造安全可靠的调用环境，严格控制调用权限，为用户提供更好的体验；为此，本发明提供一种智能座舱车控系统的安全访问方法、设备及介质，本发明应用通过在车控开发平台上申请车控权限，获取CarPermissionKey加密文件后再通过SDK接口访问车控接口，检验通过后即可调用接口进行安全访问，避免了应用随意使用车控系统，提升了车控系统的安全性。

为了达到上述目的，本发明采用以下技术方案：

第一目的在于提供一种智能座舱车控系统的安全访问方法，包括下述步骤：

第三方应用提交申请信息在车控开发平台上申请车控权限，车控开发平台根据申请信息生成CarPermissionKey加密文件反馈给第三方应用；

第三方应用集成SDK，通过调用SDK中的接口访问车控系统；所述SDK提供设置车控信号、获取车控信号状态、监听车控信号状态，传输CarPermissionKey加密文件的接口；

在智能座舱车控系统上安装第三方应用，当安装的第三方应用通过SDK接口请求访问车控系统时，车控系统禁止第三方应用直接调用CarService服务接口，提供CarService代理服务接口允许第三方应用访问，访问步骤为：

CarService代理服务接口对安装的第三方应用的CarPermissionKey加密文件进行校验；

校验通过后，CarService代理服务接口根据安装的第三方应用的请求调用CarService车控接口；

CarService车控接口通过Vehicle车控接口下发车控信号到MCU；

MCU根据安装的第三方应用的请求下发车控信号到BCM；

检验不通过则禁止调用CarService车控接口。

作为优选的技术方案，所述申请信息包括车控信号ID集合、应用包名及通过车控开发平台根证书生成的appkey；

所述CarPermissionKey加密文件生成步骤为：

车控开发平台对第三方提交的车控信号ID集合、应用包名及通过车控开发平台根证书生成的appkey进行审核；

同时使用base64和MD5加密算法对车控信号ID集合及应用包名进行加密，并通过appkey和车控开发平台根证书进行MD5加盐，得到CarPermissionKey加密文件。

作为优选的技术方案，所述第三方应用集成SDK时，将得到的CarPermissionKey加密文件放置在第三方应用assets路径下。

作为优选的技术方案，所述第三方应用通过离线安装或网络下载安装在智能座舱车控系统上。

作为优选的技术方案，所述CarService代理服务接口提供车辆状态信号获取及车辆控制两大接口。

作为优选的技术方案，所述CarService代理服务接口对安装的第三方应用的CarPermissionKey加密文件进行校验，具体为：

当安装的第三方应用通过SDK接口请求访问车控系统时，车控系统首先通过本地根证书生成appkey，然后使用appkey逆向MD5解析调用接口时传递的CarPermissionKey加密文件；

若解析成功则获取安装的第三方应用的车控信号ID集合及应用包名，再使用原生接口获取该应用申请时的应用包名，并与解析出的应用包名进行对比，相同则检验通过，否则检验不通过，车控系统不响应安装的第三方应用的请求；

若解析不成功则校验不通过，车控系统禁止访问CarService车控接口。

作为优选的技术方案，所述CarService代理服务接口根据安装的第三方应用的请求调用CarService车控接口前，判断安装的第三方应用调用的车控信号ID是否包含在该应用已申请的车控信号ID集合中，若已包含则将安装的第三方应用发出的车控信号进行下发；

若未包含则拒绝安装的第三方应用调用CarService车控接口。

作为优选的技术方案，所述车控平台根证书和本地根证书相同。

第二目的在于，提供一种电子设备，所述电子设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的计算机程序指令，所述计算机程序

指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的一种智能座舱车控系统的安全访问方法。

第三目的在于，提供一种计算机可读存储介质，存储有程序，所述程序被处理器执行时，实现上述的一种智能座舱车控系统的安全访问方法。

本发明与现有技术相比，具有如下优点和有益效果：

目前智能座舱系统车控功能愈加丰富，车控安全性对车辆安全极其重要，稳定安全的车控系统是除车身安全外的又一重要安全性能指标，安全可靠的车控系统能对品牌形象产生较大的影响。

1、离线状态验证：对比现有技术，通过签名后，将签名后的应用推送到车机端进行安装使用，该推送操作需依赖与网络，在无网及网络差的情况无法正常使用；而本发明的应用通过在车控开发平台上申请车控权限，获取CarPermissionKey加密文件后再通过SDK接口访问车控接口，检验通过后即可调用接口获取车控信息，由于CarPermissionKey加密文件申请后存放于应用内部，整个接口权限验证过程不需要依赖于网络，所以即使完全处于离线环境、网络较差环境以及无网状态下的车机系统均可以正常的进行接口权限精确验证。

2、精准控制车控信号权限：对比现有技术，通过对应用签名的方式进行权限认证，无法精准控制具体车控信号；而本发明将申请的车控信号ID，通过加密后生成CarPermissionKey加密文件，保存在三方应用内，调用接口时用作参数传递，车端代理服务接口对应用使用的车控信号ID进行校验，判断是否包含在申请ID中，包含则通过校验，本发明对于车控信号能更精准的进行控制，更进一步提升车控安全性。

3、兼容性强：对比现有技术，由于需要通过对应用进行签名后推送到车机端，所以三方应用每次更新迭代都需要将应用重新进行签名，无法通过一次签名兼容后续迭代版本；本发明通过CarPermissionKey加密文件进行权限控制，只要将该文件保存在应用内部即可通过权限校验，一次申请即可兼容所有应用版本。

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一种智能座舱车控系统的安全访问方法的流程图；

图2为本发明实施例一种智能座舱车控系统的安全访问方法的结构流程图；

图3为本发明实施例中第三方应用访问车控系统的具体流程图；

图4为本发明实施例电子设备的结构图。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本申请所描述的实施例可以与其它实施例相结合。

请参阅图1和图2，在本申请的一个实施例中提供了一种智能座舱车控系统的安全访问方法，包括下述步骤：

A1、第三方应用app提交申请信息在车控开发平台上申请车控权限，车控开发平台根据申请信息生成CarPermissionKey加密文件反馈给第三方应用app；

具体的，第三方应用app提交的申请信息包括车控信号ID集合(如车窗信号、天窗信号等)、应用包名及通过车控开发平台根证书生成的appkey；

车控开发平台对车控信号ID集合及应用资质进行审核，生成CarPermissionKey加密文件，具体步骤为：

车控开发平台对第三方提交的车控信号ID集合、应用包名及通过车控开发平台根证书生成的appkey进行审核；

同时使用base64和MD5加密算法对车控信号ID集合及应用包名进行加密，并通过appkey和车控开发平台根证书进行MD5加盐，进一步提升加密复杂度，得到CarPermissionKey加密文件。

A2、第三方应用app集成SDK，通过调用SDK中的接口访问车控系统；

集成的SDK提供设置车控信号、获取车控信号状态、监听车控信号状态，传输CarPermissionKey加密文件等接口；

集成SDK时，将得到的CarPermissionKey加密文件放置在第三方应用assets路径下。

A3、在智能座舱车控系统上安装第三方应用，当安装的第三方应用通过SDK接口请求访问车控系统时，车控系统禁止第三方应用直接调用CarService服务接口(CarProxyService)，提供CarService代理服务接口(CarProxyService)允许第三方应用访问，如图3所示，访问步骤为：

CarService代理服务接口(CarProxyService)对安装的第三方应用的CarPermissionKey加密文件进行校验；

校验通过后，CarService代理服务接口(CarProxyService)根据安装的第三方应用的请求调用CarService车控接口；

CarService车控接口通过Vehicle车控接口下发车控信号到MCU(微控制单元，又称单片机)；

MCU根据安装的第三方应用的请求下发车控信号到BCM(车身控制模块)；

检验不通过则禁止调用CarService车控接口。

更具体的，第三方应用通过离线或者网络下载(如三方应用商城等)安装在智能座舱车控系统上。

为了严格控制车控信号的使用及控制，本发明禁止第三方应用直接调用CarService服务接口，提供CarService代理服务接口，允许第三方应用访问CarService代理服务接口提供的车辆状态信号获取及车辆控制两大接口。

为了保证应用访问的安全性，本发明的CarService代理服务接口需对安装的第三方应用的CarPermissionKey加密文件进行校验，具体为：

当安装的第三方应用app通过SDK接口请求访问车控系统时，车控系统首先通过本地根证书生成appkey，然后使用appkey逆向MD5解析调用接口时传递的CarPermissionKey加密文件；

若解析成功则获取安装的第三方应用的车控信号ID集合及应用包名，再使用原生接口获取该应用申请时的应用包名，并与解析出的应用包名进行对比，相同则检验通过，否则检验不通过，车控系统不响应安装的第三方应用的请求；

若解析不成功则校验不通过，车控系统禁止访问CarService车控接口。

更进一步的，在CarService代理服务接口根据安装的第三方应用的请求调用CarService车控接口前，判断安装的第三方应用调用的车控信号ID是否包含在该应用已申请的车控信号ID集合中，若已包含则将安装的第三方应用发出的车控信号进行下发；

若未包含则拒绝安装的第三方应用调用CarService车控接口。

更具体的，本发明中，车控平台根证书和本地根证书相同。

需要说明的是，对于前述的各方法实施例，为了简便描述，将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其它顺序或者同时进行。

请参阅图4，在一个实施例中，提供了一种实现智能座舱车控系统的安全访问方法的电子设备，所述电子设备可以包括第一处理器、第一存储器和总线，还可以包括存储在所述第一存储器中并可在所述第一处理器上运行的计算机程序，如智能座舱车控系统的安全访问程序。

其中，所述第一存储器至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、移动硬盘、多媒体卡、卡型存储器(例如：SD或DX存储器等)、磁性存储器、磁盘、光盘等。所述第一存储器在一些实施例中可以是电子设备的内部存储单元，例如该电子设备的移动硬盘。所述第一存储器在另一些实施例中也可以是电子设备的外部存储设备，例如电子设备上配备的插接式移动硬盘、智能存储卡(Smart Media Card，SMC)、安全数字(SecureDigital，SD)卡、闪存卡(Flash Card)等。进一步地，所述第一存储器还可以既包括电子设备的内部存储单元也包括外部存储设备。所述第一存储器不仅可以用于存储安装于电子设备的应用软件及各类数据，例如智能座舱车控系统的安全访问程序的代码等，还可以用于暂时地存储已经输出或者将要输出的数据。

所述第一处理器在一些实施例中可以由集成电路组成，例如可以由单个封装的集成电路所组成，也可以是由多个相同功能或不同功能封装的集成电路所组成，包括一个或者多个中央处理器(Central Processing unit，CPU)、微处理器、数字处理芯片、图形处理器及各种控制芯片的组合等。所述第一处理器是所述电子设备的控制核心(ControlUnit)，利用各种接口和线路连接整个电子设备的各个部件，通过运行或执行存储在所述第一存储器内的程序或者模块(例如智能座舱车控系统的安全访问程序等)，以及调用存储在所述第一存储器内的数据，以执行电子设备的各种功能和处理数据。

图4仅示出了具有部件的电子设备，本领域技术人员可以理解的是，图4示出的结构并不构成对所述电子设备的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

所述电子设备中的所述第一存储器存储的智能座舱车控系统的安全访问程序是多个指令的组合，在所述第一处理器中运行时，可以实现：

第三方应用提交申请信息在车控开发平台上申请车控权限，车控开发平台根据申请信息生成CarPermissionKey加密文件反馈给第三方应用；

第三方应用集成SDK，通过调用SDK中的接口访问车控系统；所述SDK提供设置车控信号、获取车控信号状态、监听车控信号状态，传输CarPermissionKey加密文件的接口；

在智能座舱车控系统上安装第三方应用，当安装的第三方应用通过SDK接口请求访问车控系统时，车控系统禁止第三方应用直接调用CarService服务接口，提供CarService代理服务接口允许第三方应用访问，访问步骤为：

CarService代理服务接口对安装的第三方应用的CarPermissionKey加密文件进行校验；

校验通过后，CarService代理服务接口根据安装的第三方应用的请求调用CarService车控接口；

CarService车控接口通过Vehicle车控接口下发车控信号到MCU；

MCU根据安装的第三方应用的请求下发车控信号到BCM；

检验不通过则禁止调用CarService车控接口。

进一步地，所述电子设备集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个非易失性计算机可读取存储介质中。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。