CN111506899A

CN111506899A - 一种安全系统的权限管理方法和权限管理架构

Info

Publication number: CN111506899A
Application number: CN202010295553.XA
Authority: CN
Inventors: 罗春雷
Original assignee: Beijing Qianchuan Technology Co ltd
Current assignee: Ningbo Qianchuan Technology Co ltd
Priority date: 2020-04-15
Filing date: 2020-04-15
Publication date: 2020-08-07
Anticipated expiration: 2040-04-15
Also published as: CN111506899B

Abstract

本申请公开了一种安全系统的权限管理方法和权限管理架构，权限管理方法包括：在安全协议中设置安全应用的权限；安全系统根据安全协议的权限设置获取安全应用的权限；若启动安全应用，安全系统根据安全应用的唯一标识获取相应的安全应用权限并根据安全应用权限控制安全应用访问系统调用和安全服务。本申请通过安全协议用系统调用、安全服务等更加底层的、细粒度的安全权限来限制安全应用安全域，使得不同的安全应用和不同的安全域具有不同的权限。

Description

一种安全系统的权限管理方法和权限管理架构

技术领域

本申请涉及移动通信技术领域，具体涉及一种安全系统的权限管理方法和权限管理架构。

背景技术

可信执行环境(Trusted Execution Environment，TEE)是目前移动设备终端上与富执行环境(Rich Execution Environment，REE)配合的安全执行系统，是运行在手机等硬件上的一个操作系统。它和REE系统相当于同时运行在硬件上的双操作系统，可以交互。因为TEE系统运行在更安全的硬件上，所以具有比REE更高的安全等级，所以REE就会将安全要求高的操作交给TEE中的安全应用(Trusted application，TA)去执行。

目前，移动终端上比较常见的TEE系统有OPTEE(Open Portable TrustedExecution Environment)和Trusty。OPTEE是一个开源的TEE项目，目前由Linaro组织维护，此系统基于GPTEE(GlobalPlatform’s TEE)规范和接口实现。此标准下的接口对所有的安全应用都一视同仁，其将视为安全资产的资源，比如通信、加密、存储、时间等，提供给每个TA。

Trusty系统是google公司开发的TEE系统，也是开源的，但是接口和规范不遵循GPTEE，而是提供一套自己的接口。Trusty系统接口对所有的安全应用也都一视同仁，其将视为安全资产的资源，比如通信、加密、存储、时间等，提供给每个TA。

无论Trusty还是OPTEE，都存在以下几个问题：

1、编写安全应用时，需要用到很多的功能，多是更细粒度的安全资源，比如创建子进程、大内存栈等资源申请等，现有的TEE规范提供的安全服务(service)和系统调用(syscall)是无法完全满足的。在常见TEE系统中要么不允许扩充，要么允许扩充，但是不提供安全权限限制，安全应用可以随便调用这些安全资源。

2、两个系统的服务中如果想赋予不同安全应用以不同的权限，大部分是根据安全应用的唯一标识符(Universally Unique Identifier，UUID)进行识别，通过写代码的方式来区分不同安全应用的不同的权限，这种方法很难统一设置和实现。

3、两个系统在开发安全应用时，都是预先在移动设备出厂时就预制好的，没有安装、升级、卸载安全应用的功能，无法在运行或者不更改整体镜像情况下修改安全应用，更无法修改安全应用的权限。

发明内容

本申请的目的在于提供一种安全系统的权限管理方法和权限管理架构，实现更加细粒度的权限控制。

本申请提供了一种安全系统的权限管理方法，包括：在安全协议中设置安全应用的权限；安全系统根据安全协议的权限设置获取安全应用的权限；若启动安全应用，安全系统根据安全应用的唯一标识获取相应的安全应用权限并根据安全应用权限控制安全应用访问系统调用和安全服务。

其中，优选地，还包括在安全协议中设置安全域的权限；并且，若启动安全应用，安全系统根据安全应用的唯一标识获取相应的安全应用权限和安全应用所在的安全域的安全域权限，并依据安全域权限是域内安全应用权限的最大权限原则计算安全应用的实际权限。

其中，优选地，安装和更新安全应用和/或安全域时，在安全协议中设置和更新安全应用权限和/或安全域权限。

其中，优选地，通过将安全应用权限对应的句柄转交给安全应用来控制安全应用访问系统调用和安全服务。

其中，优选地，依据安装和更新安全应用和/或安全域时，根据安全应用提供商和安全域提供商的权限设置在安全协议中设置安全应用权限和安全域的权限。

其中，优选地，安全应用提供商和安全域提供商通过安全系统提供的编辑器进行权限设置。

其中，优选地，安全应用权限包括共用权限，共用权限允许安全应用之间共用系统调用和安全服务。

本申请还提供一种安全系统的权限管理架构，包括安全应用提供商、安全域提供商、安全协议以及安全系统；其中，安全协议根据安全应用提供商和安全域提供商的权限设置来设置安全应用的权限和安全域的权限；安全系统从安全协议中获取安全应用权限和安全域权限，并在启动安全应用时根据安全应用权限和安全域权限控制安全应用访问系统调用和安全服务。

其中，优选地，安全系统通过将安全应用权限对应的句柄转交给安全应用来控制安全应用访问系统调用和安全服务。

本申请的技术效果如下：

1、本申请通过安全协议用系统调用、安全服务等更加底层的、细粒度的安全权限来限制安全应用安全域，使得不同的安全应用和不同的安全域具有不同的权限。

2、本申请通过安全系统提供的编辑器允许安全应用提供商和安全域提供商在运行时添加和更改权限，为他们提供了更多的能力控制每个安全应用和安全域的权限，避免通过编写代码区分权限带来的不统一。同时，本申请也为安全应用提供商和安全域提供商提供更加细粒度和更灵活的方式来设定安全权限。

3、本申请对OTrP协议进行了扩展，借助于OTrP协议的安全和可靠性，使得安全应用和安全域具有更多功能的同时保持安全性和可靠性。

附图说明

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

图1是本申请实施例提供的安全系统的权限管理方法的流程图；

图2是安全系统的权限管理架构的结构图。

具体实施方式

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

实施例一

图1是本申请实施例提供的安全系统的权限管理方法的流程图。如图1所示，权限管理方法包括如下步骤：

S110：安全应用提供商通过编辑器设置安全应用(TA)的权限，安全域提供商通过编辑器设置安全域(Security Domain，SD)的权限。

具体地，本申请中，编辑器是安全系统(TEE系统)提供的统一的编辑器，安全应用提供商和安全域提供商可以在编辑器上查看和编辑需要安装的安全应用或安全域的权限设置。

优选地，利用编辑器编辑权限可以用Json格式来编写，比如：

{

"NBL_APP_TUI":"1",

"NBL_APP_NEW_PROCESS":"1"

}

其中，Key是权限的名字；Value可以是1或0(如允许为1，不允许为0)，也可以是具体的值。

S120：根据安全应用提供商和安全域提供商的权限设置在安全协议中设置安全应用TA和安全域SD的权限。

其中，作为一个实施例，安全协议为OTrP协议。本申请对OTrP协议的功能进行了扩展，增加了安全应用TA和安全域SD的安全权限，可以设置和更新权限。

作为一个实施例，在OTrP协议中，“安装TA”协议(InstallTATBSRequest)和/或“更新TA”协议(UpdateTATBSRequest)中增加了安全应用TA的权限设置和权限更新的字段。

具体地，作为一个实例，在InstallTATBSRequest和/或UpdateTATBSRequest的Json数据中增加了ciphertadata字段的数据部分内容，请见如下数据片段：

"encrypted_ta":{

"key":"<JWE enveloped data of a 256-bit symmetric key by therecipient’s TEEspaik public key>",

"iv":"<hex of 16random bytes>",

"alg":"<encryption algoritm.AESCBC by default.",

"ciphertadata":"<BASE64 encoded encrypted TA binary data>",

"cipherpdata":"<BASE64 encoded encrypted TA personalization data>"

}

在该实例中，“ciphertadata”字段是现有的OTrP协议中的字段，其保存加密后的安全应用镜像。本申请中，在此字段的数据前加入了加密后的安全权限设定。

作为另一个实施例，在OTrP协议中，“创建SD”协议(CreateSDTBSRequest)和/或“更新SD”协议(UpdateSDTBSRequest)中增加了安全域SD的权限设置和权限更新的字段。

具体地，作为一个实例，在CreateSDTBSRequest和/或UpdateSDTBSRequest的Json数据中增加“nbl_privilege”字段。以如下的创建SD的数据片段来示例：

在安全应用TA和安全域SD对权限进行设置和更新后，安全协议中也相应地对安全应用TA和安全域SD的权限进行了设置。

S 130：安全系统根据安全协议的权限设置获取安全应用和安全域的权限并存储。

安全协议将其安全应用TA和安全域SD的权限传输给安全系统，安全系统更新和存储安全应用TA和安全域SD的权限。

具体地，安全系统为TEE系统，例如Trusty系统、OPTEE系统。

S140：判断是否需要启动安全应用。若是，则执行S150。

S150：安全系统根据安全应用的唯一标识查询相应的安全应用权限和安全域权限。

在启动安全应用时，安全系统根据该安全应用的唯一标识UUID从存储器中查询该安全应用的权限以及其所属的安全域的权限，以确定该安全应用的权限。

具体地，安全域权限和安全应用权限产生冲突时，依据安全域权限是域内安全应用权限的最大权限原则，即安全应用的权限不能超出安全域的权限，计算出安全应用应该拥有的权限，作为安全应用的实际权限。

S160：安全系统根据安全应用权限和安全域权限形成句柄Handle。

Handle是安全系统的底层概念，安全应用对安全系统的系统调用和安全服务的访问都必须通过Handle来使用，安全应用只有具有某资源的Handle才能使用该资源。

例如，对某资源的权限为禁止写入，则该资源的Handle中加入禁止写入的限制，安全应用只能读取该资源，无法修改和操控该资源。例如，对某系统程序的权限为禁止创建子进程，则该程序的Handle加入了禁止创建子进程的限制，安全应用不能够调用创建子进程的系统调用。例如，对某项安全服务的权限为禁止调用“TUI”(Trust User Interface)服务，那么就不允许安全应用获取TUI的handle。

S170：安全系统将handle转交给安全应用，通过handle控制安全应用访问系统调用和安全服务。

优选地，安全应用权限包括共用权限，即允许安全应用之间共用系统调用和安全服务。若某安全应用具有某种资源的权限和共用权限，则该资源的handle可以从该安全应用转交给其他安全应用，允许其他安全应用共用安全服务和系统调用。

实施例二

本申请还提供了一种与上述权限管理方法匹配的安全系统的权限管理架构。

图2是安全系统的权限管理架构的结构图。如图2所示，权限管理架构包括安全应用提供商(Service Provider，SP)、安全域提供商(Trusted Service Manager，TSM)、安全协议及安全系统，其中，安全系统包括安全应用管理模块、启动器、安全域、系统调用和安全服务。

具体地，安全系统为TEE系统，例如Trusty系统、OPTEE系统。作为一个实施例，如图2所示，安全系统包括两个安全域，安全域1和安全域2，其中，安全域1中安装安全应用1和安全应用2，安全域2中安装安全应用3。

安全应用提供商SP为安全应用的开发商，其提供安全应用，并通过安全系统提供的编辑器查看和编辑安全应用的权限。安全应用提供商将其安全应用提供给安全域提供商。

安全域提供商TSM是安全域的设定者，一般是移动设备的提供商或者总软件承包商。TSM设置安全域中安装的安全应用，并通过安全系统提供的编辑器查看和编辑安全域的权限。

安全协议中根据安全应用和安全域设定安全应用和安全域的权限，并传输给安全系统。其中，作为一个实施例，安全协议为OTrP协议。

安全应用管理模块从安全协议获取安全应用和安全域的权限并存储。

启动器用于启动安全应用。在启动安全应用时，启动器根据该安全应用的唯一标识UUID从存储器中查询该安全应用的权限以及其所属的安全域的权限，以确定该安全应用的权限，并根据权限形成相应的句柄handle转交给该安全应用。

安全应用通过handle访问系统调用和安全服务的内容。

本申请的技术效果如下：

2、本申请通过安全系统提供的编辑器允许安全应用提供商和安全域提供商在运行时设置和更新权限，为他们提供了更多的能力控制每个安全应用和安全域的权限，避免通过编写代码区分权限带来的不统一。同时，本申请也为安全应用提供商和安全域提供商提供更加细粒度和更灵活的方式来设定安全权限。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims

1.一种安全系统的权限管理方法，其特征在于，包括：

在安全协议中设置安全应用的权限；

安全系统根据所述安全协议的权限设置获取安全应用的权限；

若启动安全应用，安全系统根据所述安全应用的唯一标识获取相应的安全应用权限并根据所述安全应用权限控制所述安全应用访问系统调用和安全服务。

2.如权利要求1所述的权限管理方法，其特征在于，还包括在安全协议中设置安全域的权限；并且，

若启动安全应用，安全系统根据所述安全应用的唯一标识获取相应的安全应用权限和所述安全应用所在的安全域的安全域权限，并依据安全域权限是域内安全应用权限的最大权限原则计算所述安全应用的实际权限。

3.如权利要求1或2所述的权限管理方法，其特征在于，安装和更新安全应用和/或安全域时，在安全协议中设置和更新安全应用权限和/或安全域权限。

4.如权利要求3所述的权限管理方法，其特征在于，通过将安全应用权限对应的句柄转交给所述安全应用来控制所述安全应用访问系统调用和安全服务。

5.如权利要求3所述的权限管理方法，其特征在于，依据安装和更新安全应用和/或安全域时，根据安全应用提供商和安全域提供商的权限设置在安全协议中设置安全应用权限和安全域的权限。

6.如权利要求5所述的权限管理方法，其特征在于，所述安全应用提供商和安全域提供商通过安全系统提供的编辑器进行权限设置。

7.如权利要求4所述的权限管理方法，其特征在于，所述安全应用权限包括共用权限，所述共用权限允许安全应用之间共用系统调用和安全服务。

8.一种安全系统的权限管理架构，其特征在于，包括安全应用提供商、安全域提供商、安全协议以及安全系统；

其中，所述安全协议根据所述安全应用提供商和所述安全域提供商的权限设置来设置安全应用的权限和安全域的权限；

所述安全系统从所述安全协议中获取安全应用权限和安全域权限，并在启动安全应用时根据所述安全应用权限和所述安全域权限控制所述安全应用访问系统调用和安全服务。

9.如权利要求8所述的权限管理架构，其特征在于，所述安全系统通过将安全应用权限对应的句柄转交给所述安全应用来控制所述安全应用访问系统调用和安全服务。

10.如权利要求8或9所述的权限管理架构，其特征在于，所述安全应用提供商和所述安全域提供商通过安全系统提供的编辑器进行权限设置。