CN114844672B - 一种应用可信身份的确认方法、管理单元及设备 - Google Patents

Abstract

本申请实施例公开了一种应用可信身份的确认方法、管理单元及设备，可应用于车领域，包括：事先构建的用户态软件(即中间件可信基)首先与目标应用(如第一应用、第二应用等)之间的身份连接，并通过第一身份通道接收第一应用发送的“请求与第二应用进行通信”，中间件可信基根据在第一请求中注入第一应用的身份信息得到第二请求，并通过第二身份通道将第二请求向第二应用发送，以使得第二应用基于第二请求中身份信息决定是否与第一应用建立第一通信通道。本申请实施例完全基于用户态软件的中间件可信基构建与各应用的身份连接，对内核依赖少，更灵活；此外，基于构建的身份连接，通信数据可以和身份数据融合，节省了通信次数，提升了设备性能。

Description

一种应用可信身份的确认方法、管理单元及设备

技术领域

本申请涉及数据安全领域，尤其涉及一种应用可信身份的确认方法、管理单元及设备。

背景技术

随着互联网的高速发展，数据安全问题日益凸显。例如，相比于传统燃油汽车，智能网联汽车需要面对来自整个互联网的攻击者，因此，在自动驾驶领域，汽车软件从业者需要应对智能化带来的新的安全课题，只有解决数字安全问题，自动驾驶平台才能保证终端用户的安全驾驶。而一辆完整的智能网联汽车通常会涉及十几个甚至数十个电子控制单元(electronic control unit，ECU)，每个ECU根据其电子器件架构复杂度要求，部署了不同的软件栈。作为智能网联车的核心运算中心，智能驾驶平台的核心操作系统通常会有各种各样的原子服务部署于其上。这些服务与服务之间，客户端与服务之间，均需要进行通信，以完成汽车行驶的功能。在这些通信中，往往会涉及到用户隐私等数据安全问题。部分关键通信还会影响车辆的行驶安全。在这种情况下，如何才能保证汽车行驶所涉及的通信安全，就变得至关重要。

当前在互联网应用中使用比较广泛的是基于SSL/TLS/HTTPS的身份认证机制，以TLS为例，一次双向证书认证的过程需要经历四次握手流程。在一次完整TLS双向认证的握手流程中，服务端验证了来自客户端的证书，客户端验证了来自服务端的证书，从而建立基于密码学的信任机制。在完成双向认证后，服务端和客户端基于协商出来的密钥进行加密的安全通信。

上述这种基于证书的认证机制的过程需要可信任的第三方机构参与，例如证书颁发机构(certificate authority，CA)。并且CA需要为通信两端均颁发证书。这将引入证书颁发成本、证书存储成本以及证书的维护成本，是一种复杂的解决方案。另外，TLS在建链时，需要基于证书认证引入握手机制，而握手机制中需要完成多次证书校验流程，比较耗时。因此在车内，一些对时延敏感性高的场景，不适合使用基于TLS的认证通信方式。

发明内容

本申请实施例提供了一种应用可信身份的确认方法、管理单元及设备，用于完全基于用户态软件的中间件可信基构建与目标应用的身份连接，对内核无依赖，更灵活；此外，基于构建的身份连接，通信数据可以和身份数据融合，节省了通信次数，提升了设备性能。

基于此，本申请实施例提供以下技术方案：

第一方面，本申请实施例首先提供一种应用可信身份的确认方法，可用于数据安全领域中，尤其可以应用于智能网联汽车领域中，该方法包括：首先，中间件可信基建立与目标应用之间的身份连接，该中间件可信基为事先构建好的用户态软件，该目标应用至少包括第一应用和第二应用，在建立好与目标应用之间的身份连接后，中间件可信基再通过第一身份通道接收第一应用发送的第一请求，该第一请求也可以称为通信初始化请求，用于表征第一应用请求与第二应用进行通信，该第一身份通道为与第一应用对应的身份通道。之后，中间件可信基可以基于该第一请求得到第二请求，其中，该第二请求中就包括该第一应用的身份信息，中间件可信基会通过在建立身份连接时建立的第二身份通道将该第二请求向第二应用发送。需要注意的是，该第二身份通道是与第二应用对应的身份通道。第二应用在接收到中间件可信基发送的第二请求后，会从第二请求的数据报文中获得第一应用的身份信息，并根据该身份信息决定是否与第一应用建立通信通道，该通信通道可称为第一通信通道(即安全通道)。

在本申请上述实施方式中，本申请实施例是基于构建的中间件可信基建立与各应用进程之间的身份连接，更加灵活；并且进程在通信初始化阶段，是由中间件可信基在通信初始化请求中加入发起端进程的身份信息，来使得接收端进程识别该发起端进程是否为可靠应用进程，从而无需额外的身份传输过程，节约了通信次数，提升了通信性能；此外，该中间件可信基完全为用户态软件，对内核无依赖，更具普适性。

在一种可能的实现方式中，中间件可信基建立与目标应用之间的身份连接可以是：中间件可信基借助执行管理建立与目标应用之间的身份连接。

在一种可能的实现方式中，中间件可信基建立与目标应用之间的身份连接也可以是：中间件可信基借助目标应用的配置文件建立与所述目标应用之间的身份连接。

在一种可能的实现方式中，中间件可信基根据第一请求得到第二请求的实现方式可以是：中间件可信基在第一请求中注入第一应用的身份信息，从而得到包含有第一应用的身份信息的第二请求，使得通信数据与身份数据进行了融合，从而无需额外的身份传输过程，节约了通信次数，提升了通信性能。

在一种可能的实现方式中，第一身份通道的访问权限受到第一限制，第一限制至少包括如下任意一种：不能创建或访问第三应用与中间件可信基之间的身份连接，其中，第三应用与第一应用为不同的应用；或，不能访问第二通信通道上传递的数据，其中，第二通信通道为与所述第一通信通道不同的通信通道。

在一种可能的实现方式中，第二身份通道的访问权限受到第二限制，第二限制至少包括如下任意一种：不能创建或访问第四应用与中间件可信基之间的身份连接，其中，该第四应用与第二应用为不同的应用；或，不能访问第二通信通道上传递的数据，其中，该第二通信通道为与第一通信通道不同的通信通道。

在一种可能的实现方式中，第一通信通道的访问权限受到第三限制，第三限制至少包括如下任意一种：不能创建或访问目标应用与中间件可信基之间的身份连接；或，不能访问第二通信通道上传递的数据，其中，该第二通信通道为与第一通信通道不同的通信通道。

在本申请上述实施方式中，为了避免恶意进程在通信过程中，对身份连接发起攻击，例如试图创建他人的身份连接以发起仿冒攻击，或者在通信过程中恶意篡改中间件可信基注入的身份信息等。上述所涉及的通道(如，第一身份通道、第二身份通道、第一通信通道等)访问权限均受到了操作系统内核的限制，从而提高了数据安全性。

在一种可能的实现方式中，第一应用以及第二应用属于同一操作系统内的应用程序。

本申请实施例第二方面提供一种管理单元，该管理单元具有实现上述第一方面或第一方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本申请实施例第三方面提供一种设备，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第一方面或第一方面任意一种可能实现方式的方法。

本申请实施例第四方面提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第一方面或第一方面任意一种可能实现方式的方法。

本申请实施例第五方面提供了一种计算机程序，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面任意一种可能实现方式的方法。

本申请实施例第六方面提供了一种芯片，该芯片包括至少一个处理器和至少一个接口电路，该接口电路和该处理器耦合，至少一个接口电路用于执行收发功能，并将指令发送给至少一个处理器，至少一个处理器用于运行计算机程序或指令，其具有实现如上述第一方面或第一方面任意一种可能实现方式的方法的功能，该功能可以通过硬件实现，也可以通过软件实现，还可以通过硬件和软件组合实现，该硬件或软件包括一个或多个与上述功能相对应的模块。此外，该接口电路用于与该芯片之外的其它模块进行通信。

附图说明

图1为本申请实施例提供的应用可信身份的确认方法一个流程示意图；

图2为本申请实施例提供的中间件可信基建立身份连接的一个示意图；

图3为本申请实施例提供的中间件可信基借助执行管理建立身份连接的一个示意图；

图4为本申请实施例提供的中间件可信基借助配置文件建立身份连接的一个示意图；

图5为本申请实施例提供的中间件可信基中转身份信息的一个流程示意图；

图6为本申请实施例提供的车载系统访问开工至总体架构图；

图7为本申请实施例提供的管理单元的一个结构示意图；

图8为本申请实施例提供的设备的一个结构示意图。

具体实施方式

本申请实施例提供了一种应用可信身份的确认方法、管理单元及设备，用于完全基于用户态软件的中间件可信基构建与目标应用(application，APP)的身份连接，对内核无依赖，更灵活；此外，基于构建的身份连接，通信数据可以和身份数据融合，节省了通信次数，提升了设备性能。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。

为便于理解本申请方案，在介绍本申请实施例之前，先对本领域中通常采用的身份认证机制进行简单说明：

(1)基于SSL/TLS/HTTPS的身份认证机制

当前在互联网应用中使用比较广泛的是基于SSL/TLS/HTTPS的身份认证机制，其中，SSL是TLS的前身，全称为secure sockets layer，现在已不再更新；TLS的全称是transport layer security，是一种对基于网络的传输的加密协议，可以在受信任的第三方公证基础上做双方的身份认证；HTTPS的全称是hyper text transfer protocol oversecure socket layer，是以安全为目标的HTTP通道，在HTTP的基础上通过传输加密和身份认证保证传输过程的安全性。

以TLS为例，一次双向证书认证的过程需要经历四次握手流程，而证书是一种基于非对称加解密的认证机制。在一次完整TLS双向认证的握手流程中，服务端验证了来自客户端的证书，客户端验证了来自服务端的证书，从而建立基于密码学的信任机制。在完成双向认证后，服务端和客户端基于协商出来的密钥进行加密的安全通信。

基于证书的认证机制的过程需要可信任的第三方机构参与，例如CA。并且CA需要为通信两端均颁发证书。使用该方案进行身份认证，需要引入证书，以及证书生命周期的维护，增加了成本。另外，TLS在建链时，需要基于证书认证引入握手机制，而握手机制中需要完成多次证书校验流程。校验次数至少需要两次，而通常工作证书并非根证书，所以证书校验时通常要引入证书链校验，则证书校验次数可能远远超过2次，每次证书校验均需要通过云端的公开密钥基础设施(public key infrastructure，PKI)查询证书有效性，并且完成非对称加解密算法流程，每一步均为比较耗时的操作。所以在车内一些对时延敏感性很高的场景，不适合使用基于TLS的认证通信方式。

(2)基于Linux UDS SCM_CREDENTIALS获取UID/GID/PID进行身份认证

Family属性配置为AF_UNIX的socket被称为unix domain socket，简称UDS，为Linux内核提供的一种进程间通信方式，用于实现同一主机上的进程间通信(interprocess communication，IPC)，UDS可以用作系统内部高效的进程间通信。UDS提供了进程间传递身份的方式。当发送端进程指明发送的消息类型是SCM_CREDENTIALS时，接收端进程即可以通过Linux的C库函数，获取到发起端进程的UID/GID/PID。从而进一步获取到发起端进程的身份。需要说明的是，UDS的SCM_CREDENTIALS机制是通过内核的socket实现的，即由Linux内核在两个进程间传递发起端进程的UID/GID/PID信息。

然而，UDS虽然可以完成基本的身份传递功能，该功能只要是Linux系统即可以使用，通用性很强。但随之而来的是，UDS仍然不能解决一些业务相关的问题，包括：

a、UDS还有一种方式是使用SO_PEERCRED机制，可以融合身份和数据传递，但需要额外增加一次系统调用来获取身份，这会造成通信性能的损失，从而降低了通信效率；

b、身份信息只能是UID/GID/PID，需要业务代码进行映射才可以实现业务需要的逻辑；

c、信息传递在内核实现，需要额外的系统调用来传递身份信息，降低了IPC通信的确定性。

(3)基于binder驱动传递身份信息

由于通用的UDS传递身份引入的问题，Linux主线引入了基于binder驱动的进程间通信方式。该通信方式在安卓(Android)系统中使用广泛。binder提供了一种通用的IPC框架，起初由open binder引入，并由Google定制广泛使用于安卓中的IPC场景。binder于Linux 3.19合入主线。Android将binder封装成java本地接口(java native interface，JNI)给上层应用使用。JNI接口会使用驱动层接口，即/dev/binder。binder驱动在内核将调用者身份信息注入到IPC数据中。该方案解决了上述第二种方式中的问题a。基于binder的通信方式合并了数据报文和发起端身份信息，接收端可以通过get calling UID类接口访问到对端的身份信息。

但binder方案仍然无法处理上述第二种方式中提及的问题b和问题c，即：binder仍然只能传输UID/GID/PID类操作系统提供的逻辑概念信息。安卓在使用时为每个进程均赋予了独一无二的UID来解决了该问题。但此类解决方案并非一个通用解决方案，并不适用于车载操作系统；binder的身份信息获取逻辑在内核，增加了内核处理时间，对性能仍然不够友好。由于binder已合并入内核主线，所以可维护性得以缓解，但要再向内核推入类似的功能困难较大。

综上所述，现有的一些身份认证机制的方案多基于内核获取对端进程的UID/GID/PID信息，通常会引入以下问题：1)无法和业务通信融合，需要额外的通信从内核获取对应进程的信息；2)只能传递操作系统已有的逻辑概念，例如UID/GID/PID，无法实现与业务紧密结合，在身份使用时，仍然需要一次查表映射；3)身份认证过程在内核实现，引入多次系统调用，降低性能，且引入内核修改，维护较困难。

基于此，本申请实施例提供了一种应用可信身份的确认方法、管理单元及设备，可以解决以上三个问题，具体地，本申请实施例完全基于用户态软件的中间件可信基构建与目标应用的身份连接，对内核无依赖，更灵活；此外，基于构建的身份连接，通信数据可以和身份数据融合，节省了通信次数，提升了设备性能。

下面结合附图，对本申请的实施例进行描述。本领域普通技术人员可知，随着技术的发展和新场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

具体请参阅图1，图1为本申请实施例提供的应用可信身份的确认方法一个流程示意图，具体可以包括如下步骤：

101、中间件可信基建立与目标应用之间的身份连接，中间件可信基为事先构建的用户态软件，目标应用至少包括第一应用和第二应用。

首先，本申请实施例会事先构建一个中间件可信基，该中间件可信基也可称为identity manager，为一种用户态软件，该中间件可信基本身是可信的。

在本申请实施例中，一个操作系统对应构建有一个中间件可信基，在构建好中间件可信基之后，中间件可信基就可以建立与相关应用(可称为目标应用、目标进程等，为便于阐述，均以应用为例进行说明)之间的身份连接。在本申请实施例中，该目标应用至少包括两个不同的应用，可称为第一应用和第二应用。具体地，在本申请的一些实施方式中，目标应用可以是指属于同一操作系统中的任意一个或多个应用(例如，可以是所有应用)，在这种情况下，第一应用和第二应用也就是指属于同一操作系统内的应用程序。

具体地，中间件可信基在启动时，会与属于该操作系统内的所有应用的进程建立用于标记身份的通信通道，如图2所示，该通信通道可称为身份通道，在本申请实施例中，建立身份连接的方式有多种，包括但不限于：

(1)中间件可信基借助执行管理建立与目标应用之间的身份连接。

在这种建立身份连接的方式下，中间件可信基可以借助执行管理(执行管理是一个服务进程)来建立与目标应用之间的身份连接。例如，执行管理可以通知中间件可信基有哪些APP进程启动了，然后中间件可信基再主动发起身份连接。

为便于理解上述过程，下面以车载平台软件业务为例对借助执行管理建立身份连接进行说明，具体的过程可以是：车载平台软件业务进程均由执行管理拉起。执行管理的角色类似于Android的zygote进程，执行管理通过fork-exec系统调用，最终拉起业务进程。在拉起APP进程的过程当中，执行管理协助建立起身份通道。具体请参阅图3，其创建流程如下：

①执行管理调用fork系统调用创建子进程，此时仍是执行管理的代码在运行；

②执行管理子进程打开该APP进程的身份连接通道；

③该子进程向中间件可信基发起IPC通信，通知中间件可信基将要拉起某个APP进程；

④中间件可信基尝试打开该APP进程的身份连接通道。

(2)中间件可信基借助目标应用的配置文件建立与目标应用之间的身份连接。

在这种建立身份连接的方式下，中间件可信基可以借助配置文件来建立与目标应用之间的身份连接。例如，中间件可信基可以静态获取当前平台需要启动的APP进程信息，进而发起身份连接。

为便于理解上述过程，下面以车载平台软件业务为例对借助执行管理建立身份连接进行说明，具体过程可以是：

车载平台软件业务进程具备各自的配置文件。该配置文件由软件打包集成时，安装在车载平台的根文件系统中，该文件处于只读文件系统中，且启动时，会随整系统校验确保其完整性。中间件可信基和APP进程均可以基于此配置文件，获取APP进程身份连接的信息。由于操作系统的强制访问控制(mandatory access control，MAC)策略规定了APP进程只能访问对应其身份的身份连接通道，所以本申请实施例创建的身份连接也是安全可信的，具体可参阅图4，其创建流程如下：

①启动时，中间件可信基遍历同一操作系统下所有APP进程的配置文件，并为每个APP进程打开其身份连接通道，尝试与APP建立身份连接；

②APP进程首次通信时，通过读取配置文件中的身份连接信息，打开其自身的身份连接通道，从而与中间件可信基建立可信的安全身份通道。

需要说明的是，一旦中间件可信基与同一操作系统下的所有应用进程建立了身份连接之后，则内核可信基提供的身份信息就可以转移到该中间件可信基中。

102、中间件可信基通过第一身份通道接收第一应用发送的第一请求，第一请求用于表征第一应用请求与第二应用进行通信。

中间件可信基在建立好与目标应用之间的身份连接之后，整个操作系统就可经由中间件可信基来中转各个应用的身份信息。在本申请实施例中，当一个应用进程(可称为第一应用，即APP1，也可称为发起端进程)要同另外一个应用进程(可称为第二应用，即APP2，也可称为接收端进程)发生通信时，接收端进程需要能够判断发起端进程的身份，如果发起端进程是身份不明的进程，为了通信安全，接收端进程则会拒绝与其通信。因此，在通信初始化时，发起端进程并不能直接与接收端进程通信。如果发起端试图直接访问，则会被接收端直接拒绝通信。此时就要求，发起端进程的身份能够安全的传输到接收端进程。但又不能直接通过两个应用进程之间的通信通道载荷来传输，因为如果采用这种传递方式，则一个不可信的进程或者一个恶意进程可以额任意地调整通信载荷来仿冒其他的应用进程，从而会使得接收端进程无法做出正确、可靠的判断。因此，在通信初始化时，第一应用需要与中间件可信基进行通信，以经由该中间件可信基尝试与第二应用建立通信通道。

具体地，中间件可信基可以通过在建立身份连接时建立的第一身份通道接收第一应用发送的第一请求，该第一请求也可以称为通信初始化请求，用于表征第一应用请求与第二应用进行通信。需要注意的是，该第一身份通道是与第一应用对应的身份通道。

103、中间件可信基根据第一请求得到第二请求，第二请求中包括第一应用的身份信息。

中间件可信基在接收到第一应用发送的第一请求(即通信初始化请求)之后，会进一步根据该第一请求得到第二请求，该第二请求中包括有第一应用的身份信息。

需要说明的是，在本申请的一些实施方式中，中间件可信基基于第一请求得到第二请求的方式可以是：中间件可信基在第一请求中注入第一应用的身份信息，从而得到包含有第一应用的身份信息的第二请求。

104、中间件可信基通过第二身份通道将第二请求向第二应用发送。

之后，中间件可信基会通过在建立身份连接时建立的第二身份通道将该第二请求向第二应用发送。需要注意的是，该第二身份通道是与第二应用对应的身份通道。在本申请的一些实施方式中，中间件可信基可以基于自身维护的APP ID来确定第二应用具体是哪个应用，如图5所示。

105、第二应用基于第二请求中的身份信息决定是否与第一应用建立第一通信通道。

第二应用在接收到中间件可信基发送的第二请求后，会从第二请求的数据报文中获得第一应用的身份信息，并根据该身份信息决定是否与第一应用建立通信通道，该通信通道可称为第一通信通道(即安全通道)。

这里需要注意的是，由于该中间件可信基本身是可信的，这推导出经由该中间件可信基转发的请求中的身份信息也是可信的。所以第二应用可以基于第一应用的身份信息进行判断。另外，中间件可信基与通信两端进程之间的第一通信通道是初始化时由系统执行管理与中间件可信基共同建立的。由于系统的执行管理与本申请所述的中间件可信基属于同一安全级别，所以经由这两个通道发送的数据请求也是可信的。

由上述步骤可知，本申请实施例提供的应用可信身份的确认方法是基于构建的中间件可信基建立与各应用进程之间的身份连接，更加灵活；并且进程在通信初始化阶段，是由中间件可信基在通信初始化请求中注入发起端进程的身份信息(即通信数据与身份数据进行了融合)，来使得接收端进程识别该发起端进程是否为可靠应用进程，从而无需额外的身份传输过程，节约了通信次数，提升了通信性能；此外，该中间件可信基完全为用户态软件，对内核依赖少，更具普适性。

需要说明的是，在本申请的一些实施方式中，为了避免恶意进程在通信过程中，对身份连接发起攻击，例如试图创建他人的身份连接以发起仿冒攻击，或者在通信过程中恶意篡改中间件可信基注入的身份信息等。上述所涉及的通道(如，第一身份通道、第二身份通道、第一通信通道等)访问权限必须受到限制，具体地，第一身份通道的访问权限受到第一限制，该第一限制至少包括如下任意一种：不能创建或访问第三应用与中间件可信基之间的身份连接，其中，第三应用与第一应用为不同的应用；或，不能访问第二通信通道上传递的数据，其中，第二通信通道为与所述第一通信通道不同的通信通道。类似地，第二身份通道的访问权限受到第二限制，该第二限制至少包括如下任意一种：不能创建或访问第四应用与中间件可信基之间的身份连接，其中，该第四应用与第二应用为不同的应用；或，不能访问第二通信通道上传递的数据，其中，该第二通信通道为与第一通信通道不同的通信通道。第一通信通道的访问权限受到第三限制，第三限制至少包括如下任意一种：不能创建或访问目标应用与中间件可信基之间的身份连接；或，不能访问第二通信通道上传递的数据，其中，该第二通信通道为与第一通信通道不同的通信通道。

也就是说，上述所述的各个通道不能创建或访问其他进程与中间件可信基之间的身份连接，确保身份机制安全可信；此外，各个通道也不能访问其他进程之间的通信数据，确保安全通信通道内的数据安全，避免篡改和信息泄露。在本申请的一些实施方式中，为了达到以上目的，本申请实施例可以采用Linux内核提供的访问控制机制，对所有的通信通道实施保护，包括但不限于：

a、采用内核的MAC机制，例如安全增强型Linux(security-enhanced Linux，SELinux)，对应用进程的行为加以限制。只允许其访问与自身有关的通道(如，管道、UDS、共享内存等)，包括与Identity Manager的身份连接、与其他进程建立的安全通信通道等。

b、采用自主访问控制(discretionary access control，DAC)的方式，例如构建APP沙盒，每个APP采用不同的用户运行，达到隔离的效果。从而能保证每个进程只能访问与自身有关的通道。

综上所述，本申请实施例综合考虑到了现有方法的不足，提出的基于中间件可信基进行应用可信身份的确认方法可以与通信框架整合，实现数据通信和身份传递的融合；并且，基于纯用户态的中间件可信基，避免过多、过久地陷入内核操作，提升了通信性能和确定性；最后，本申请实施例完全贴合业务的ID体系，避免直接使用UID等操作系统逻辑概念，更具灵活性。

由于智慧城市、智能驾驶等领域中都可以用到本申请实施例中的所述的应用可信身份的确定方法来保证数据安全，下面对一个典型的落地到产品的应用场景进行介绍。

在数字安全领域，访问控制可以作为避免恶意入侵的重要手段。在入侵发生时，也能作为控制入侵者获取更高级别资源的韧性手段。所以，针对软件系统中需要使用到的关键资源进行访问控制是安全领域一项非常重要的技术。而访问控制必须基于可信的身份机制，才可以有效实施。在互联网领域，可信身份通常是基于证书体系以及密码学来实现。但是在车载软件这类对可靠性实时性要求非常高的场景，完全基于证书体系或密码学的身份机制并不完全适用。本发明针对车载软件的特征，基于用户态实现了完整的可信身份机制。本发明的应用系统框架如图6所示，本申请实施例提供的应用可信身份的确认方法可在图6中的IAM模块中实现。

需要说明的是，本申请涉及的技术不仅仅局限于自动驾驶平台，还包括一切在用户态可信基构建访问控制场景，包括但不限于工业控制、铁路、航空等各类对数字安全有高规格要求的系统和方案，属于一种通用型的用户态安全身份传递机制。几乎可以适用于任何场景，具备很好的可定制型和可扩展性。

在上述实施例的基础上，为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关单元。具体参阅图7，图7为本申请实施例提供的管理单元的一个结构示意图，该管理单元700具体可以包括：建立模块701、第一发送模块702、获取模块703以及第二发送模块704，其中，建立模块701，用于建立与目标应用之间的身份连接，该目标应用至少包括第一应用和第二应用；第一发送模块702，用于通过第一身份通道接收该第一应用发送的第一请求，该第一请求用于表征该第一应用请求与第二应用进行通信，该第一身份通道与该第一应用对应；获取模块703，用于根据该第一请求得到第二请求，该第二请求中包括该第一应用的身份信息；第二发送模块704，用于通过第二身份通道将该第二请求向该第二应用发送，以使得该第二应用基于该第二请求中该身份信息决定是否与该第一应用建立第一通信通道，该第二身份通道与该第二应用对应。

在一种可能的设计中，建立模块701，具体用于：借助执行管理建立与该目标应用之间的身份连接。

在一种可能的设计中，建立模块701，具体用于：借助该目标应用的配置文件建立与该目标应用之间的身份连接。

在一种可能的设计中，获取模块703，具体用于：在该第一请求中注入该第一应用的身份信息，得到该第二请求。

在一种可能的设计中，第一身份通道的访问权限受到第一限制，该第一限制至少包括如下任意一种：不能创建或访问第三应用与该中间件可信基之间的身份连接，该第三应用与该第一应用为不同的应用；或，不能访问第二通信通道上传递的数据，该第二通信通道为与该第一通信通道不同的通信通道。

在一种可能的设计中，第二身份通道的访问权限受到第二限制，该第二限制至少包括如下任意一种：不能创建或访问第四应用与该中间件可信基之间的身份连接，该第四应用与该第二应用为不同的应用；或，不能访问第二通信通道上传递的数据，该第二通信通道为与该第一通信通道不同的通信通道。

在一种可能的设计中，第一通信通道的访问权限受到第三限制，该第三限制至少包括如下任意一种：不能创建或访问该目标应用与该中间件可信基之间的身份连接；或，不能访问第二通信通道上传递的数据，该第二通信通道为与该第一通信通道不同的通信通道。

在一种可能的设计中，第一应用以及该第二应用属于同一操作系统内的应用程序。

需要说明的是，管理单元700中各模块/单元之间的信息交互、执行过程等内容，与本申请中图1对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

接下来介绍本申请实施例提供的一种设备，请参阅图8，图8为本申请实施例提供的设备的一种结构示意图，设备800上可以部署有图7对应实施例中所描述的管理单元700，用于实现图7对应实施例中管理单元700的功能，具体的，设备800由一个或多个服务器实现，设备800可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)822和存储器832，一个或一个以上存储应用程序842或数据844的存储介质830(例如一个或一个以上海量存储设备)。其中，存储器832和存储介质830可以是短暂存储或持久存储。存储在存储介质830的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对设备800中的一系列指令操作。更进一步地，中央处理器822可以设置为与存储介质830通信，在设备800上执行存储介质830中的一系列指令操作。

设备800还可以包括一个或一个以上电源826，一个或一个以上有线或无线网络接口850，一个或一个以上输入输出接口858，和/或，一个或一个以上操作系统841，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。

本申请实施例中，中央处理器822，用于执行图1对应实施例中应用可信身份的确认方法，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

需要说明的是，中央处理器822执行上述各个步骤的具体方式，与本申请中图1对应的方法实施例基于同一构思，其带来的技术效果也与本申请上述实施例相同，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有用于进行信号处理的程序，当其在计算机上运行时，使得计算机执行如前述图1所示实施例描述的中间件可信基所执行的步骤。

本申请实施例提供的设备具体可以为芯片，芯片包括：处理单元和通信单元，所述处理单元例如可以是处理器，所述通信单元例如可以是输入/输出接口、管脚或电路等。该处理单元可执行存储单元存储的计算机执行指令，以使设备内的芯片执行上述图1所示实施例描述的中间件可信基所执行的步骤。

可选地，所述存储单元为所述芯片内的存储单元，如寄存器、缓存等，所述存储单元还可以是所述无线接入设备端内的位于所述芯片外部的存储单元，如只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)等。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、ROM、RAM、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机或者网络设备等)执行本申请各个实施例所述的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

Claims (19)

1.一种应用可信身份的确认方法，其特征在于，包括：

中间件可信基建立与目标应用之间的身份连接，所述中间件可信基为事先构建的用户态软件，所述目标应用至少包括第一应用和第二应用；

所述中间件可信基通过第一身份通道接收所述第一应用发送的第一请求，所述第一请求用于表征所述第一应用请求与第二应用进行通信，所述第一身份通道与所述第一应用对应；

所述中间件可信基根据所述第一请求得到第二请求，所述第二请求中包括所述第一应用的身份信息；

所述中间件可信基通过第二身份通道将所述第二请求向所述第二应用发送，以使得所述第二应用基于所述第二请求中所述身份信息决定是否与所述第一应用建立第一通信通道，所述第二身份通道与所述第二应用对应。

2.根据权利要求1所述的方法，其特征在于，所述中间件可信基建立与目标应用之间的身份连接包括：

所述中间件可信基借助执行管理建立与所述目标应用之间的身份连接。

3.根据权利要求1所述的方法，其特征在于，所述中间件可信基建立与目标应用之间的身份连接包括：

所述中间件可信基借助所述目标应用的配置文件建立与所述目标应用之间的身份连接。

4.根据权利要求1-3中任一项所述的方法，其特征在于，所述中间件可信基根据所述第一请求得到第二请求包括：

所述中间件可信基在所述第一请求中注入所述第一应用的身份信息，得到所述第二请求。

5.根据权利要求1-3中任一项所述的方法，其特征在于，所述第一身份通道的访问权限受到第一限制，所述第一限制至少包括如下任意一种：

不能创建或访问第三应用与所述中间件可信基之间的身份连接，所述第三应用与所述第一应用为不同的应用；

或，

不能访问第二通信通道上传递的数据，所述第二通信通道为与所述第一通信通道不同的通信通道。

6.根据权利要求1-3中任一项所述的方法，其特征在于，所述第二身份通道的访问权限受到第二限制，所述第二限制至少包括如下任意一种：

不能创建或访问第四应用与所述中间件可信基之间的身份连接，所述第四应用与所述第二应用为不同的应用；

或，

不能访问第二通信通道上传递的数据，所述第二通信通道为与所述第一通信通道不同的通信通道。

7.根据权利要求1-3中任一项所述的方法，其特征在于，所述第一通信通道的访问权限受到第三限制，所述第三限制至少包括如下任意一种：

不能创建或访问所述目标应用与所述中间件可信基之间的身份连接；

或，

不能访问第二通信通道上传递的数据，所述第二通信通道为与所述第一通信通道不同的通信通道。

8.根据权利要求1-3中任一项所述的方法，其特征在于，

所述第一应用以及所述第二应用属于同一操作系统内的应用程序。

9.一种管理单元，其特征在于，包括：

建立模块，用于建立与目标应用之间的身份连接，所述目标应用至少包括第一应用和第二应用；

第一发送模块，用于通过第一身份通道接收所述第一应用发送的第一请求，所述第一请求用于表征所述第一应用请求与第二应用进行通信，所述第一身份通道与所述第一应用对应；

获取模块，用于根据所述第一请求得到第二请求，所述第二请求中包括所述第一应用的身份信息；

第二发送模块，用于通过第二身份通道将所述第二请求向所述第二应用发送，以使得所述第二应用基于所述第二请求中所述身份信息决定是否与所述第一应用建立第一通信通道，所述第二身份通道与所述第二应用对应。

10.根据权利要求9所述的管理单元，其特征在于，所述建立模块，具体用于：

借助执行管理建立与所述目标应用之间的身份连接。

11.根据权利要求9所述的管理单元，其特征在于，所述建立模块，具体用于：

借助所述目标应用的配置文件建立与所述目标应用之间的身份连接。

12.根据权利要求9-11中任一项所述的管理单元，其特征在于，所述获取模块，具体用于：

在所述第一请求中注入所述第一应用的身份信息，得到所述第二请求。

13.根据权利要求9-11中任一项所述的管理单元，其特征在于，所述第一身份通道的访问权限受到第一限制，所述第一限制至少包括如下任意一种：

不能创建或访问第三应用与所述管理单元之间的身份连接，所述第三应用与所述第一应用为不同的应用；

或，

不能访问第二通信通道上传递的数据，所述第二通信通道为与所述第一通信通道不同的通信通道。

14.根据权利要求9-11中任一项所述的管理单元，其特征在于，所述第二身份通道的访问权限受到第二限制，所述第二限制至少包括如下任意一种：

不能创建或访问第四应用与所述管理单元之间的身份连接，所述第四应用与所述第二应用为不同的应用；

或，

不能访问第二通信通道上传递的数据，所述第二通信通道为与所述第一通信通道不同的通信通道。

15.根据权利要求9-11中任一项所述的管理单元，其特征在于，所述第一通信通道的访问权限受到第三限制，所述第三限制至少包括如下任意一种：

不能创建或访问所述目标应用与所述管理单元之间的身份连接；

或，

不能访问第二通信通道上传递的数据，所述第二通信通道为与所述第一通信通道不同的通信通道。

16.根据权利要求9-11中任一项所述的管理单元，其特征在于，所述第一应用以及所述第二应用属于同一操作系统内的应用程序。

17.一种设备，包括处理器和存储器，所述处理器与所述存储器耦合，其特征在于，

所述存储器，用于存储程序；

所述处理器，用于执行所述存储器中的程序，使得所述设备执行如权利要求1-8中任一项所述的方法。

18.一种计算机可读存储介质，包括程序，当其在计算机上运行时，使得计算机执行如权利要求1-8中任一项所述的方法。

19.一种芯片，所述芯片包括处理器与数据接口，所述处理器通过所述数据接口读取存储器上存储的指令，执行如权利要求1-8中任一项所述的方法。