CN117421722A - 车辆权限管理方法、装置、系统、车辆及存储介质 - Google Patents

Abstract

本申请涉及一种车辆权限管理方法、装置、系统、车辆及存储介质。该车辆权限管理方法，包括：在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID；将所述获取的应用程序ID与存储的应用程序ID进行校验，其中所述存储的应用程序ID是由云端在所述应用程序完成注册授权后根据所述应用程序的设定信息预先生成并下发到车端；在校验出所述获取的应用程序ID与存储的应用程序ID一致后，确认所述应用程序符合第一权限要求。本申请提供的方案，能够更好实现车辆应用程序的权限管理，降低车辆安全隐患，提高车辆使用安全。

Description

车辆权限管理方法、装置、系统、车辆及存储介质

技术领域

本申请涉及电动汽车技术领域，尤其涉及一种车辆权限管理方法、装置、系统、车辆及存储介质。

背景技术

目前，电动车辆可以支持应用程序的安装和运行。相关技术中，车辆对车载应用程序的sdk(Software Development Kit，软件开发工具包)权限是基于对应用程序的分组或分类进行管理，或者基于用户的权限对车载应用程序的sdk权限进行管理。

但是，上述权限管理方法，可能导致未经授权的应用程序申请权限或应用程序在实现其功能时申请超出其业务范围的整车通信的原子接口进行使用，这样会存在安全漏洞，从而对车辆造成安全隐患，可能影响车辆使用安全。

发明内容

为解决或部分解决相关技术中存在的问题，本申请提供一种车辆权限管理方法、装置、系统、车辆及存储介质，能够更好实现车辆应用程序的权限管理，避免安全漏洞，降低车辆安全隐患，提高车辆使用安全。

本申请第一方面提供一种车辆权限管理方法，包括：

在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID；

将所述获取的应用程序ID与存储的应用程序ID进行校验，其中所述存储的应用程序ID是由云端在所述应用程序完成注册授权后根据所述应用程序的设定信息预先生成并下发到车端；

在校验出所述获取的应用程序ID与存储的应用程序ID一致后，确认所述应用程序符合第一权限要求。

在一实施方式中，所述将所述获取的应用程序ID与存储的应用程序ID进行校验之前，还包括：利用预设方式校验所述应用程序是否被篡改；

所述将所述获取的应用程序ID与存储的应用程序ID进行校验，包括：在校验出所述应用程序未被篡改后，将所述获取的应用程序ID与存储的应用程序ID进行校验。

在一实施方式中，所述确认所述应用程序符合第一权限要求之后，还包括：

获取应用程序申请的车辆接口权限清单；

将所述获取的车辆接口权限清单与存储的车辆接口权限清单进行校验，其中所述存储的车辆接口权限清单是由云端生成所述应用程序ID之后，为所述应用程序ID对应预先配置并下发到车端；

在校验出所述获取的车辆接口权限清单与存储的车辆接口权限清单一致后，确认所述应用程序符合第二权限要求。

在一实施方式中，所述存储的应用程序ID是根据所述应用程序的设定信息预先生成，包括：

所述存储的应用程序ID是根据所述应用程序的Keystore信息、包名信息预先生成；或，

所述存储的应用程序ID是根据所述应用程序的Keystore信息、包名信息和自定义salt信息预先生成。

在一实施方式中，所述利用预设方式校验所述应用程序是否被篡改，包括：

根据所述应用程序的Keystore信息对所述应用程序的文件进行哈希计算得到摘要信息；

根据所述计算得到的摘要信息与所述应用程序包含的摘要信息一致，确定所述应用程序未被篡改。

在一实施方式中，所述进行哈希计算包括利用sha1哈希算法进行计算，得到sha1值；或，利用sha256哈希算法进行计算，得到sha256值。

本申请第二方面提供一种车辆权限管理装置，包括：

第一获取模块，用于在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID；

第一校验模块，用于将所述获取的应用程序ID与存储的应用程序ID进行校验，其中所述存储的应用程序ID是由云端在所述应用程序完成注册授权后根据所述应用程序的设定信息预先生成并下发到车端；

第一权限管理模块，用于在所述第一校验模块校验出所述获取的应用程序ID与存储的应用程序ID一致后，确认所述应用程序符合第一权限要求。

在一实施方式中，所述装置还包括：

第二获取模块，用于获取应用程序申请的车辆接口权限清单；

第二校验模块，用于将所述获取的车辆接口权限清单与存储的车辆接口权限清单进行校验，其中所述存储的车辆接口权限清单是由云端生成所述应用程序ID之后，为所述应用程序ID对应预先配置并下发到车端；

第二权限管理模块，用于在所述第二校验模块校验出所述获取的车辆接口权限清单与存储的车辆接口权限清单一致后，确认所述应用程序符合第二权限要求。

在一实施方式中，所述装置还包括：

程序篡改校验模块，用于利用预设方式校验所述应用程序是否被篡改；

所述第一校验模块在所述程序篡改校验模块校验出所述应用程序未被篡改后，将所述获取的应用程序ID与存储的应用程序ID进行校验。

本申请第三方面提供一种车辆权限管理系统，包括：

云端，用于在应用程序完成注册授权后根据所述应用程序的设定信息预先生成应用程序ID并下发到车端；

车端，用于在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID；将所述获取的应用程序ID与存储的应用程序ID进行校验；在校验出所述获取的应用程序ID与存储的应用程序ID一致后，确认所述应用程序符合第一权限要求；

应用程序端，用于向车端发起应用程序的权限请求。

本申请第四方面提供一种车辆，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如上所述的方法。

本申请第五方面提供一种计算机可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如上所述的方法。

本申请提供的技术方案可以包括以下有益效果：

本申请的技术方案，在所述应用程序完成注册授权后根据应用程序的设定信息预先生成应用程序ID并下发到车端，当车端接收到应用程序发起的权限请求后，可以获取应用程序包含的应用程序ID，然后将所述获取的应用程序ID与存储的应用程序ID进行校验，在校验出所述获取的应用程序ID与存储的应用程序ID一致后，确认所述应用程序符合第一权限要求。通过上述处理方式，可以通过预先设置并存储的应用程序ID来校验发起权限请求的应用程序是否符合权限要求，从而可以控制在车辆安装的应用程序的权限，避免不符合权限要求的应用程序在车辆的安装，从而能够更好实现车辆应用程序的权限管理，降低车辆安全隐患，提高车辆使用安全。

进一步的，本申请方案确认所述应用程序符合第一权限要求之后，还可以包括：获取应用程序申请的车辆接口权限清单；将所述获取的车辆接口权限清单与存储的车辆接口权限清单进行校验，其中所述存储的车辆接口权限清单是由云端生成所述应用程序ID之后，为所述应用程序ID对应预先配置并下发到车端；在校验出所述获取的车辆接口权限清单与存储的车辆接口权限清单一致后，确认所述应用程序符合第二权限要求。通过预先为生成的应用程序ID对应配置车辆接口权限清单，这样当获取到应用程序申请的车辆接口权限清单后，就可以将所述获取的车辆接口权限清单与存储的车辆接口权限清单进行校验，在校验出一致后再确认所述应用程序符合第二权限要求，从而可以利用预先配置的车辆接口权限清单识别应用程序是否可以使用整车通信的原子接口，避免应用程序申请超出业务范围的接口而导致的安全风险。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

通过结合附图对本申请示例性实施方式进行更详细地描述，本申请的上述以及其它目的、特征和优势将变得更加明显，其中，在本申请示例性实施方式中，相同的参考标号通常代表相同部件。

图1是本申请示出的车辆权限管理方法的第一流程示意图；

图2是本申请示出的车辆权限管理方法的第二流程示意图；

图3是本申请示出的车辆权限管理方法的应用示意图；

图4是本申请示出的车辆权限管理装置的结构示意图；

图5是本申请示出的车辆权限管理系统的结构示意图；

图6是本申请示出的车辆的结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的实施方式。虽然附图中显示了本申请的实施方式，然而应该理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本申请更加透彻和完整，并且能够将本申请的范围完整地传达给本领域的技术人员。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语“第一”、“第二”、“第三”等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

相关技术中的车辆权限管理方法，可能可能导致未经授权的应用程序申请权限或应用程序在实现其功能时申请超出其业务范围的整车通信的原子接口进行使用，这样会存在安全漏洞，从而对车辆造成安全隐患，可能影响车辆使用安全。针对上述问题，本申请提供一种车辆预警处理方法，能够更好实现车辆应用程序的权限管理，避免安全漏洞，降低车辆安全隐患，提高车辆使用安全。

以下结合附图详细描述本申请的技术方案。

图1是本申请示出的车辆权限管理方法的第一流程示意图。该方法可以应用于车辆。

参见图1，该方法包括：

S101、在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID。

其中，应用程序包含的应用程序ID，可以是由云端在应用程序完成注册授权后根据应用程序的设定信息预先生成并下发到应用程序端。应用程序端在完成应用程序的调试后，在正式版本中可以包含该应用程序ID。应用程序在准备安装到车端时，可以向车端发起权限请求，请求安装。

S102、将获取的应用程序ID与存储的应用程序ID进行校验，其中存储的应用程序ID是由云端在应用程序完成注册授权后根据应用程序的设定信息预先生成并下发到车端。

其中，云端在应用程序完成注册授权后根据应用程序的设定信息预先生成应用程序ID，并下发到车端和应用程序端供存储使用。车端可以将获取的应用程序ID与存储的应用程序ID进行校验。

S103、在校验出获取的应用程序ID与存储的应用程序ID一致后，确认应用程序符合第一权限要求。

如果校验出从应用程序获取的应用程序ID与存储的应用程序ID一致，说明该应用程序与注册授权的应用程序是一致的，符合车辆对应用程序的权限管理的第一权限要求，从而避免不符合权限要求的应用程序在车辆的安装。

从该示例可知，本申请的技术方案，在应用程序完成注册授权后根据应用程序的设定信息预先生成应用程序ID并下发到车端，当车端接收到应用程序发起的权限请求后，可以获取应用程序包含的应用程序ID，然后将获取的应用程序ID与存储的应用程序ID进行校验，在校验出获取的应用程序ID与存储的应用程序ID一致后，确认应用程序符合第一权限要求。通过上述处理方式，可以通过预先设置并存储的应用程序ID来校验发起权限请求的应用程序是否符合权限要求，从而可以控制在车辆安装的应用程序的权限，避免不符合权限要求的应用程序在车辆的安装，从而能够更好实现车辆应用程序的权限管理，降低车辆安全隐患，提高车辆使用安全。

图2是本申请示出的车辆车辆权限管理方法的第二流程示意图；图3是本申请示出的车辆权限管理方法的应用示意图。

参见图2，该方法包括：

S201、由云端预先根据应用程序的设定信息预先生成应用程序ID，并为应用程序ID预先配置车辆接口权限清单，将应用程序ID和车辆接口权限清单下发给车端和应用程序端。

应用程序端在调试或准备发布应用程序时，可以将应用程序向云端提交相关信息以进行注册授权，获得相关权限。应用程序向云端提交的相关信息可以包括Keystore信息、包名信息(packageName)、车辆接口权限清单等。其中Keystore信息可以包括利用sha1哈希算法进行计算得到的sha1值或利用sha256哈希算法进行计算得到的sha256值等。

云端可以根据应用程序提交的相关信息对应用程序进行注册授权，在应用程序完成注册授权后，根据应用程序的设定信息预先生成唯一的应用程序ID。其中，可以根据应用程序的Keystore信息、包名信息(packageName)预先生成应用程序ID。或者，为了进一步提高安全性，使应用程序ID更难被破解，可以根据应用程序的Keystore信息、包名信息(packageName)和自定义salt(盐值)信息预先生成应用程序ID。其中，生成应用程序ID时，可以通过对称加密算法和非对称加密算法等算法但不局限于此。

其中，salt值属于随机值，一般是系统用来和密码进行组合而生成的随机数值，称作salt值，通称为加盐值。通过添加salt值，使得加密得到的密文更加冷僻，不容易被查询。salt值是随机生成的一组字符串，可以包括随机的大小写字母、数字、字符，位数可以根据要求而不一样。在密码学中，是指在散列之前将散列内容(例如：密码)的任意固定位置插入特定的字符串。这个在散列中加入字符串的方式称为“加盐”，其作用是让加盐后的散列结果和没有加盐的结果不相同，在不同的应用情景中，这个处理可以增加额外的安全性。

在生成应用程序ID之后，进一步为应用程序ID对应预先配置可授权的车辆接口权限清单，应用程序ID与配置的车辆接口权限清单具有唯一映射关系。其中，车辆接口权限清单可以对车辆接口粒度进一步细分，不再按照分组接口或分类接口划分权限，而是细分到各原子接口的权限，从而对接口权限实现更精细控制。例如，可以分为控制座舱音乐的原子接口、控制座椅的原子接口、控制空调系统的原子接口、控制语音系统的原子接口等。

然后，云端可以将生成的应用程序ID和为应用程序ID配置的车辆接口权限清单分别下发到车端和应用程序端进行存储。另外，还可以将授权的证书信息分别下发到车端和应用程序端进行存储。

S202、车端在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID。

应用程序在准备安装到车端时，可以向车端发起权限请求，请求安装到车端。车端在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID。

需说明的是，车端在接收应用程序发起的权限请求，可以先判断应用程序的类型，如果应用程序是系统自带程序，例如是root/system等程序类型，或者应用程序是厂商自研程序，例如车辆智能座舱音乐程序等，则可以快速通过权限认证。如果应用程序是第三方程序，则需要执行比较全面的权限校验过程。

因此，在车端在接收应用程序发起的权限请求后，可以在判断出应用程序是第三方应用程序后，获取应用程序包含的应用程序ID。

S203、车端利用预设方式校验应用程序是否被篡改。

该步骤中，可以根据应用程序的Keystore信息对应用程序的文件进行哈希计算得到摘要信息；判断摘要信息与应用程序包含的摘要信息是否一致，根据计算得到的摘要信息与应用程序包含的摘要信息一致，则确定应用程序未被篡改，根据计算得到的摘要信息与应用程序包含的摘要信息不一致，则确定应用程序被篡改，权限校验不通过。

应用程序一般带有摘要信息，该摘要信息一般利用应用程序的Keystore的私钥生成，可以利用应用程序的Keystore的公钥对应用程序的文件利用哈希算法计算得到摘要信息。其中，进行哈希计算包括利用sha1哈希算法进行计算，得到sha1值；或，利用sha256哈希算法进行计算，得到sha256值。

其中，Keystore是一个用于保存应用程序代码签名信息和加密秘钥的文件，通常用于Android(安卓)应用程序的数字证书管理。Keystore主要有两种类型：用户级别的Keystore和系统级别的Keystore。系统级别的Keystore通常安装在系统目录下的/system/etc/security目录中，它是由系统管理员管理的，由于该证书在系统级别处于顶层，因此系统级别的Keystore可以被所有应用程序所共享访问。利用Keystore存储应用程序所使用的加密秘钥，能够有效的保护加密数据不被恶意攻击者获取。

其中，sha1是一种密码散列函数，可以生成一个被称为消息摘要的160位(20字节)散列值，散列值通常的呈现形式为40个十六进制数。该算法输入报文的长度不限，产生的输出是一个160位的报文摘要。sha256是一种密码散列函数，也可以说是哈希函数。对于任意长度的消息，sha256都会产生一个256bit长度的散列值，称为消息摘要，可以用一个长度为64的十六进制字符串表示。

该步骤中，将计算得到的摘要信息与应用程序包含的摘要信息进行比较，如果一致，判断出应用程序没有被篡改，继续执行后续步骤；如果不一致，判断出应用程序被篡改，可以不再继续执行后续步骤。

S204、在校验出应用程序未被篡改后，将获取的应用程序ID与存储的应用程序ID进行校验。

车端在校验出应用程序未被篡改后，将从应用程序获取的应用程序ID与存储的应用程序ID进行校验。

S205、在校验出获取的应用程序ID与存储的应用程序ID一致后，确认应用程序符合第一权限要求。

如果校验出从应用程序获取的应用程序ID与存储的应用程序ID一致，说明该应用程序与注册授权的应用程序是一致的，符合车辆对应用程序的权限管理的第一权限要求，从而避免不符合权限要求的应用程序在车辆的安装。

S206、获取应用程序申请的车辆接口权限清单。

进一步的，在校验出获取的应用程序ID与存储的应用程序ID一致后，车端获取应用程序申请的车辆接口权限清单。

S207、将获取的车辆接口权限清单与存储的车辆接口权限清单进行校验。

车端将获取的车辆接口权限清单与存储的车辆接口权限清单进行校验。

S208、在校验出获取的车辆接口权限清单与存储的车辆接口权限清单一致后，确认应用程序符合第二权限要求。

车端判断从应用程序获取的车辆接口权限清单与存储的车辆接口权限清单是否一致，如果一致，表明应用程序具有使用整车通信的某个或某些原子接口的权限，则允许应用程序使用整车通信的某个原子接口或某些原子接口；如果不一致，表明应用程序不具有使用整车通信的某个或某些原子接口的权限，则拒绝应用程序使用整车通信的某个原子接口或某些原子接口。

本申请实施例提供的方案，车辆对应用程序的权限管理不再基于应用程序的分组或分类进行管理，也不是基于用户的权限对应用程序权限进行管理，而是根据应用程序的Keystore信息、包名信息等计算出全球唯一的应用程序ID即appId，并配置该appId使用的车辆接口权限清单来识别该应用程序是否可以使用整车通信的原子接口。其中车辆接口权限清单对车辆接口粒度进一步细分，不再按照分组接口或分类接口划分权限，而是细分到各原子接口的权限，从而对接口权限实现更精细控制，因此可以避免应用程序申请超出业务范围的接口导致安全风险，从而提高整车通信安全，降低风险漏洞。

与前述应用功能实现方法实施例相对应，本申请还提供了一种车辆权限管理装置、车辆权限管理系统及车辆。

图4是本申请示出的车辆权限管理装置的结构示意图。

参见图4，本申请实施例提供的一种车辆权限管理装置40，包括：第一获取模块41、第一校验模块42、第一权限管理模块43。

第一获取模块41，用于在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID。其中，应用程序包含的应用程序ID，可以是由云端在应用程序完成注册授权后根据应用程序的设定信息预先生成并下发到应用程序端。

第一校验模块42，用于将获取的应用程序ID与存储的应用程序ID进行校验，其中存储的应用程序ID是由云端在应用程序完成注册授权后根据应用程序的设定信息预先生成并下发到车端。其中，云端在应用程序完成注册授权后根据应用程序的设定信息预先生成应用程序ID，并下发到车端和应用程序端供存储使用。第一校验模块42可以将获取的应用程序ID与存储的应用程序ID进行校验。

第一权限管理模块43，用于在第一校验模块42校验出获取的应用程序ID与存储的应用程序ID一致后，确认应用程序符合第一权限要求。

车辆权限管理装置40还可以包括：第二获取模块44、第二校验模块45、第二权限管理模块46。

第二获取模块44，用于获取应用程序申请的车辆接口权限清单。

第二校验模块45，用于将获取的车辆接口权限清单与存储的车辆接口权限清单进行校验，其中存储的车辆接口权限清单是由云端生成应用程序ID之后，为应用程序ID对应预先配置并下发到车端。云端在生成应用程序ID之后，为应用程序ID对应预先配置可授权的车辆接口权限清单，应用程序ID与配置的车辆接口权限清单具有唯一映射关系。其中，车辆接口权限清单可以对车辆接口粒度进一步细分，不再按照分组接口或分类接口划分权限，而是细分到各原子接口的权限，从而对接口权限实现更精细控制。

第二权限管理模块46，用于在第二校验模块45校验出获取的车辆接口权限清单与存储的车辆接口权限清单一致后，确认应用程序符合第二权限要求。判断从应用程序获取的车辆接口权限清单与存储的车辆接口权限清单是否一致，如果一致，表明应用程序具有使用整车通信的某个或某些原子接口的权限，则允许应用程序使用整车通信的某个原子接口或某些原子接口；如果不一致，表明应用程序不具有使用整车通信的某个或某些原子接口的权限，则拒绝应用程序使用整车通信的某个原子接口或某些原子接口。

车辆权限管理装置40还可以包括：程序篡改校验模块47。

程序篡改校验模块47，用于利用预设方式校验应用程序是否被篡改。程序篡改校验模块47可以根据应用程序的Keystore信息对应用程序的文件进行哈希计算得到摘要信息；判断摘要信息与应用程序包含的摘要信息是否一致，根据计算得到的摘要信息与应用程序包含的摘要信息一致，则确定应用程序未被篡改，根据计算得到的摘要信息与应用程序包含的摘要信息不一致，则确定应用程序被篡改，权限校验不通过。

第一校验模块42在程序篡改校验模块47校验出应用程序未被篡改后，将获取的应用程序ID与存储的应用程序ID进行校验。

本申请提供的装置，可以通过预先设置并存储的应用程序ID来校验发起权限请求的应用程序是否符合权限要求，从而可以控制在车辆安装的应用程序的权限，避免不符合权限要求的应用程序在车辆的安装，从而能够更好实现车辆应用程序的权限管理，降低车辆安全隐患，提高车辆使用安全。进一步的，通过预先为生成的应用程序ID对应配置车辆接口权限清单，这样当获取到应用程序申请的车辆接口权限清单后，就可以将获取的车辆接口权限清单与存储的车辆接口权限清单进行校验，在校验出一致后再确认应用程序符合第二权限要求，从而可以利用预先配置的车辆接口权限清单识别应用程序是否可以使用整车通信的原子接口，避免应用程序申请超出业务范围的接口而导致的安全风险。

图5是本申请示出的车辆权限管理系统的结构示意图。

参见图5，本申请实施例提供的车辆权限管理系统50，包括：云端51、车端52、应用程序端53。

云端51，用于在应用程序完成注册授权后根据应用程序的设定信息预先生成应用程序ID并下发到车端52；

车端52，用于在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID；将获取的应用程序ID与存储的应用程序ID进行校验；在校验出获取的应用程序ID与存储的应用程序ID一致后，确认应用程序符合第一权限要求；

应用程序端53，用于向车端52发起应用程序的权限请求。

车端52确认应用程序符合第一权限要求之后，还用于获取应用程序申请的车辆接口权限清单；将获取的车辆接口权限清单与存储的车辆接口权限清单进行校验，其中存储的车辆接口权限清单是由云端51生成应用程序ID之后，为应用程序ID对应预先配置并下发到车端52；在校验出获取的车辆接口权限清单与存储的车辆接口权限清单一致后，确认应用程序符合第二权限要求。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不再做详细阐述说明。

图6是本申请示出的车辆的结构示意图。

参见图6，车辆1000包括存储器1010和处理器1020。

处理器1020可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器1010可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)和永久存储装置。其中，ROM可以存储处理器1020或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器1010可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(例如DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器1010可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等)、磁性软盘等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器1010上存储有可执行代码，当可执行代码被处理器1020处理时，可以使处理器1020执行上文述及的方法中的部分或全部。

此外，根据本申请的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本申请的上述方法中部分或全部步骤的计算机程序代码指令。

或者，本申请还可以实施为一种计算机可读存储介质(或非暂时性机器可读存储介质或机器可读存储介质)，其上存储有可执行代码(或计算机程序或计算机指令代码)，当可执行代码(或计算机程序或计算机指令代码)被电子设备(或服务器等)的处理器执行时，使处理器执行根据本申请的上述方法的各个步骤的部分或全部。

以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其他普通技术人员能理解本文披露的各实施例。

Claims (12)

1.一种车辆权限管理方法，其特征在于，包括：

在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID；

将所述获取的应用程序ID与存储的应用程序ID进行校验，其中所述存储的应用程序ID是由云端在所述应用程序完成注册授权后根据所述应用程序的设定信息预先生成并下发到车端；

在校验出所述获取的应用程序ID与存储的应用程序ID一致后，确认所述应用程序符合第一权限要求。

2.根据权利要求1所述的方法，其特征在于：

所述将所述获取的应用程序ID与存储的应用程序ID进行校验之前，还包括：利用预设方式校验所述应用程序是否被篡改；

所述将所述获取的应用程序ID与存储的应用程序ID进行校验，包括：在校验出所述应用程序未被篡改后，将所述获取的应用程序ID与存储的应用程序ID进行校验。

3.根据权利要求1所述的方法，其特征在于，所述确认所述应用程序符合第一权限要求之后，还包括：

获取应用程序申请的车辆接口权限清单；

将所述获取的车辆接口权限清单与存储的车辆接口权限清单进行校验，其中所述存储的车辆接口权限清单是由云端生成所述应用程序ID之后，为所述应用程序ID对应预先配置并下发到车端；

在校验出所述获取的车辆接口权限清单与存储的车辆接口权限清单一致后，确认所述应用程序符合第二权限要求。

4.根据权利要求1所述的方法，其特征在于，所述存储的应用程序ID是根据所述应用程序的设定信息预先生成，包括：

所述存储的应用程序ID是根据所述应用程序的Keystore信息、包名信息预先生成；或，

所述存储的应用程序ID是根据所述应用程序的Keystore信息、包名信息和自定义salt信息预先生成。

5.根据权利要求2所述的方法，其特征在于，所述利用预设方式校验所述应用程序是否被篡改，包括：

根据所述应用程序的Keystore信息对所述应用程序的文件进行哈希计算得到摘要信息；

根据所述计算得到的摘要信息与所述应用程序包含的摘要信息一致，确定所述应用程序未被篡改。

6.根据权利要求5所述的方法，其特征在于：

所述进行哈希计算包括利用sha1哈希算法进行计算，得到sha1值；或，利用sha256哈希算法进行计算，得到sha256值。

7.一种车辆权限管理装置，其特征在于，包括：

第一获取模块，用于在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID；

第一校验模块，用于将所述获取的应用程序ID与存储的应用程序ID进行校验，其中所述存储的应用程序ID是由云端在所述应用程序完成注册授权后根据所述应用程序的设定信息预先生成并下发到车端；

第一权限管理模块，用于在所述第一校验模块校验出所述获取的应用程序ID与存储的应用程序ID一致后，确认所述应用程序符合第一权限要求。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

第二获取模块，用于获取应用程序申请的车辆接口权限清单；

第二校验模块，用于将所述获取的车辆接口权限清单与存储的车辆接口权限清单进行校验，其中所述存储的车辆接口权限清单是由云端生成所述应用程序ID之后，为所述应用程序ID对应预先配置并下发到车端；

第二权限管理模块，用于在所述第二校验模块校验出所述获取的车辆接口权限清单与存储的车辆接口权限清单一致后，确认所述应用程序符合第二权限要求。

9.根据权利要求7或8所述的装置，其特征在于，所述装置还包括：

程序篡改校验模块，用于利用预设方式校验所述应用程序是否被篡改；

所述第一校验模块在所述程序篡改校验模块校验出所述应用程序未被篡改后，将所述获取的应用程序ID与存储的应用程序ID进行校验。

10.一种车辆权限管理系统，其特征在于，包括：

云端，用于在应用程序完成注册授权后根据所述应用程序的设定信息预先生成应用程序ID并下发到车端；

车端，用于在接收应用程序发起的权限请求后，获取应用程序包含的应用程序ID；将所述获取的应用程序ID与存储的应用程序ID进行校验；在校验出所述获取的应用程序ID与存储的应用程序ID一致后，确认所述应用程序符合第一权限要求；

应用程序端，用于向车端发起应用程序的权限请求。

11.一种车辆，其特征在于，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1-6中任一项所述的方法。

12.一种计算机可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1-6中任一项所述的方法。