AC规则-1

本文主要参考规范 GPD_Secure Element Access Control_vxxx.pdf

OMA 架构

 

基本定义

GP(GlobalPlatform)定义了一套允许各应用提供方独立且安全地管理其在SE上的应用的安全框架，而AC(Access Control)，顾名思义，是对外部应用进行SE上应用访问权限控制的一套安全机制。

其中，SE全称为Secure Element，安全单元，是一类用以提供安全能力，如加解密运算，完整性校验，并能安全存储敏感数据的元件的总称，SE可以是终端内嵌的SE，即emmbedded SE(eSE)，也可以是UICC(如USIM)，智能SD卡等。

举个例子，一个银行或交通应用可以分成多个部分部署在各个环境中，比如可以将用户界面相关的，对运算资源需求较大的部分部署到REE(Rich Execution Environment)中，而将较为敏感的，对安全性要求较高的运算或校验环节(如指纹的校验)部署到TEE(Trusted Execution Environment)中，而将安全性要求更高的，或者涉及加解密运算等操作的元素，如私钥等，存放到SE上的对应应用中。

应用的各个部分分散在不同环境中，通过各自开放的API进行访问，其中，REE跟TEE可以对应到用户设备上，REE即为我们日常接触的手机终端的操作系统OS，如Android或Windows Phone environment等，TEE的定义也能在OS的文档中找到相关的定义，REE和TEE上的应用统称为设备应用，这些应用可以通过一些API，如Open Mobile API或GP TEE SE API实现对SE上应用的访问，SE可以是终端内置的eSE，也可以是UICC或SD卡。

在GP体系下，为避免外部应用未经授权即访问SE上的资源，防止拒绝服务攻击(denial of services attacks)，GP定义了一套安全访问机制，即，AC规则，该规则由SE进行保存与维护，外部应用在调用访问SE的API时，由此时API中的相关部件模块去获取这套规则，并判断是否被允许访问特定的资源或者应用。

AC架构

GlobalPlatform Device Technology Secure Element Access Control中定义了多套AC架构，涉及AC规则的存储，获取与管理，但这些架构都有一个共同点：access rule data，即AC规则被保存在SE中并由设备地Access Control Enforcer(访问控制器)来获取，并由Access Control Enforcer来执行这套权限控制规则。

典型的AC架构，AC规则数据由SE上专门的应用，Access Rule Application Master(ARA-M)进行管理，AC数据由该应用索引并返回给终端的Access Control Enforcer，当AC数据有所冲突或重复时，也由该应用进行冲突处理，并按优先级列出实际有效的AC规则，并返回给Access Control Enforcer。

这种情况下，ARA-M一般直接放置在SE的ISD(Issuer Security Domain，发行方安全域/主安全域)下，AC规则可以存储在SE中的任意位置，ARA-M负责索引并处理来自Access Control Enforcer的请求，ARA-M应用必须是唯一的。对应的AC架构如下图所示。

 

规范还定义了另一种形式的AC架构，这种架构引入了Access Rule Application Client(ARA-C)应用，一个ARA-C应用可以关联到一个应用提供商的安全域(即Application Provider Security Domain, APSD)，并管理APSD下的应用的AC规则，当Access Control Enforcer需要获取SE的AC时，仍旧访问ARA-M，并由ARA-M去ARA-C或SE的其他存储位置获取AC并完成整合及返回。对应的AC架构如下图所示。

 

AC数据能保存在SE的不同位置，如主安全域中的ARA-M或辅助安全域中，对于SE中的UICC，AC数据还能保存在文件中，这类文件称为Access Rule File(ARF)，即AC规则文件，Access Control Enforcer可以访问ARA-M来获取AC，也可以直接从ARF中读取。对应的AC架构如下图所示。

这些架构的共同点是，终端设备对AC规则的访问均通过ARA-M进行，区别仅是AC规则存储位置的不同，GP定义了多套AC架构，也意在适应不同SE的不同需求。

但ARA-M其实也不是必须的，AC规则数据可以只有卡上文件系统的ARF部分进行存储与维护，终端设备直接读取文件以获取AC规则。其架构如下图所示。

目前运营商的卡(即USIM)，其AC既有由ARA-M进行管理的，也有直接通过ARF进行管理的。

示例

 

附录 F

UICC 迁移方案

在本规范发布之前，GSMA 发布了一份文件 ([GSMA])，其中对 UICC 上的应用程序的访问由一组基本文件定义。 此解决方案与第 7 章中定义的 ARF 相同。GSMA 表示，长期解决方案将基于此 GlobalPlatform 规范。 为了保证与根据 [GSMA] 发布的 UICC 仅与 ARF 的兼容性，该规范强制要求访问控制执行器必须支持 UICC 回退到 ARF。 可以预期 UICC 的以下过渡场景： • 仅使用 ARF 部署的 UICC 可以通过无线加载和安装 ARA 小程序升级到本规范中的解决方案。 • UICC 发行者可能决定安装（在生产中或无线）能够评估ARF 规则的ARA-M 小程序。 这将允许使用（仅）RFM 来管理其 UICC 的网络运营商继续这样做并将其规则提供给 ARF 文件系统。 • 另一个 UICC 发行者可能决定安装（在生产中或无线）无法评估 ARF 规则的 ARA-M 小程序，将所有规则从 ARF 迁移到 ARA-M，并完全删除 ARF 。 

 

附件 G

访问规则解释

表 G-1 定义了在使用 GET DATA [All] 检索规则时，访问控制执行器应如何解释 ARA 访问规则策略

表 G-2 定义了当从 ARF 或具有 ARF 读取能力的 ARA-M 检索规则时，访问控制执行器应如何解释 ARF 访问规则策略。

注意：当多个规则应用于同一访问请求时，聚合和冲突解决应由访问控制执行器执行，使用第 3.4.1 节中定义的算法。 但是，该算法不考虑缺失的属性。 仅当规则冲突解决或组合的结果中缺少属性时，才应按表 G-1（从 ARA-M 读取的规则）或表 G-2（从 ARF 读取的规则）中定义的规则进行解释。