GP规范中定义的四种SE访问控制架构

GP规范给人的感觉好像有点晦涩难懂，由于是规范，所以比较抽象，而且GP这个组织的专家们来自世界各地，大家都用英语文档交流，所以不同的文档风格不同，难免大家阅读起来有点拗口。

GP 组织早在2014年就制定了SE相关访问控制规范，目前基于手机盾TEE+SE架构设计，以及IFAA组织中TEE+SE的2.1版本的规范，以及FIDO+TEE+SE技术方案等等，都将TEE和SE进行了结合。因此SE访问规则就变得十分重要。

GP规范定义了用于安全元件访问控制的通用机制，可用于任何种类的安全元件（例如嵌入式SE，带有安全控制器的microSD卡，UICC等）。它支持多个实体的应用程序管理，并允许每个实体为其SE应用程序设置访问规则。

注：这里的实体是指安全元件服务提供商。

安全元件的访问控制数据存储在SE中，并由设备上的访问控制强制执行器（ Access Control Enforce）来使用。访问控制强制执行器从SE中检索访问规则，并应用这些规则来限制设备应用程序访问各种SE应用程序。

GP规范的最基本实现中，所有访问控制规则都由SE提供商（Secure Element Issuer ）定义并存储在安全域（ Issuer Security Domain ）中，如下图所示。SE的提供商为SE应用程序定义访问控制规则，并将这些规则提供给应用程序文件（ARA-M）(SE提供商可以将管理委托给可信服务管理平台TSM)。当设备应用程序尝试访问SE应用程序时，访问控制强制实施器应使用ARA-M提供的设备接口从SE检索访问规则（或者应参考其预先获得的全套规则），以及只有在规则表明可以接受时才允许进入。

注：ARA-M是一个普通的SE应用程序，可以通过GlobalPlatform定义的AID进行选择。

ARA-M应用程序是唯一的。虽然访问规则数据可以存储在SE内的不同位置，但ARA-M负责在设备上的访问控制强制实施器发出请求后检索所有可用的访问规则。

应用程序提供商可能希望为其安全域中的应用程序定义访问控制规则，并自行管理这些规则。为了支持由安全元件发布者和应用程序提供者定义的规则，规范的实现如下图所示。每个应用程序提供者可以为其安全域（SD）中的应用程序定义访问规则，并将这些规则提供给访问规则应用程序客户端（ARA-C）。（应用程序开发人员可以将管理权限委托给TSM。）

当设备应用程序试图访问SE应用程序时，访问控制执行器应从ARA-M请求相关规则。 ARA-M应提供适当的规则，无论它们存储在ARA-M还是ARA-C上。 （访问控制执行者可以事先获得全套规则。）访问控制执行者只有在规则表明其可接受时才允许访问。

由于本规范可以被任何种类的安全元件使用（例如嵌入式SE，带有安全控制器的microSD卡，UICC等）。对于一些现有的UICC实现，通过一组基本文件来控制对应用程序的访问，这些文件使用远程文件管理（RFM）而不是远程应用程序管理（RAM）进行更新。GP SE访问控制规范也支持该机制，如下图所示。

当设备应用程序试图访问SE应用程序时，访问控制执行器应从ARA-M请求相关规则。 ARA-M应提供适当的规则，无论它们是存储在ARA-M，ARA-C还是ARF上。 （如第2.1节所述，访问控制执行者可以事先获得全套规则。）访问控制执行者只有在规则表明其可接受时才允许访问。发行人可以选择决定ARA-M是否具有ARF读取能力。

对于UICC，应执行以下回退：如果ARA-M不存在，则访问控制强制实施器应从访问规则文件（ARF）中检索访问规则，如下图所示。

如果执行环境提供API给设备应用程序与安全元件上的应用程序进行交互，实施此规范可以防止未经授权的设备应用程序访问特定的SE应用程序。提供对安全元件的访问的设备API可以是REE中的SIMalliance Open Mobile API或者是可信执行环境（TEE）中的TEE Secure Element AP。

为了符合本规范，SE Access API应该是面向连接的，并应实现规范中定义的访问控制执行器。当设备应用程序请求打开与安全元件中的给定应用程序的连接（通常由其AID标识）时，SE Access API的实现应使用请求连接的设备应用程序的标识符和请求连接的SE应用程序的标识符调用访问控制Enforcer。然后，访问控制执行器负责检索相应的设备应用程序和SE应用程序的访问规则。如果授予访问权限，则应接受SE Access API连接请求，并允许设备应用程序与SE应用程序交换命令（即APDU）。如果访问未被授予，则SE Access API连接请求应被拒绝，并且设备应用程序将不能与SE应用程序交换命令（即APDU）。

（素材来源于《Secure Element Access Control 》第二章内容）。