AC规则-2
基于RAM的远程接口
安全元件的访问规则可以通过远程应用程序管理 (RAM) 更新命令进行管理。 因此，ARA-M 和 ARA-C 各自提供一个远程接口，允许在 ARA 中存储或删除访问规则。 访问控制数据的任何远程管理都应仅通过 [GP 卡规范] 定义的安全通道协议来完成。 每次在 SE 中更新某些访问规则（在 ARA-M 或 ARA-C 中）时，ARA-M 拥有的刷新标签将被更新。 如果刷新标签已更新，设备应更新先前通过 GET DATA [All] 命令检索的访问规则集。 所有更新操作必须是原子的：如果更新过程失败（例如，由于断电或通信错误），则 ARA 必须保持先前的状态，直到成功完成更新。 存储在 ARA-M 或 ARA-C 中的访问规则也可以通过 RAM 命令检索。 RAM 命令可以由 TSM 通过 OTA（使用 SCP80 或 SCP81，分别在 [GP Card Spec] 和 GlobalPlatform Remote Application Management over HTTP [GP Amd B] 中定义）或通过 Remote Admin Agent 完成 在设备上（如 GlobalPlatform 安全元素远程应用程序管理 [GP SE OTA] 中所定义）。 在某些情况下，也可以通过独立的设备应用程序（例如在 TEE 中）执行远程应用程序管理； 但是，这在 GlobalPlatform 中并未标准化。 如果设备应用程序用于将 RAM 命令转发到安全元件，则该设备应用程序对安全元件的这种访问应由已存储在安全元件中的访问规则明确授予。
设备接口
访问控制执行器应从安装在目标 SE 上的 ARA-M 检索 SE 访问规则。 因此，ARA-M 提供了一个用于检索访问规则的接口。 在此接口上，访问控制执行器可以请求特定访问规则（对应于特定 SE 应用程序和特定设备应用程序）[已弃用]，或存储在 SE 中的完整访问规则集。 ARA-M 应支持这两种选择。 每个 SE 的 ARA-M 和访问控制执行器应执行本节定义的 GET DATA 命令来管理访问规则。 对于 UICC，访问控制执行器还应实现以下机制：如果 ARA-M 不存在，它应从第 7 章定义的访问规则文件（ARF）中检索访问规则。访问控制执行器是 负责正确解释获取的访问规则，并根据这些规则过滤访问。 ARA-M 应支持多个逻辑通道供访问控制执行器检索规则。 但是，支持的逻辑信道数量可能有限。 如果所有支持的逻辑信道都已在使用中，则 ARA-M 必须在 GET DATA 上返回 SW '69 84'。 在这种情况下，访问控制执行器可能会稍后重试以选择 ARA-M。
存储数据命令
STORE DATA 命令用于为定义的安全元件应用程序（由 SE 应用程序的 AID 标识）和设备应用程序（由设备应用程序的 DeviceAppID 标识）存储对 ARA-M 或 ARA-C 的访问规则。 STORE DATA 命令也可用于检索存储在 ARA-M 或 ARA-C 中的访问规则。 注意：在SCP80的情况下，ARA中可以存储的REF-AR-DO的最大长度取决于SE的一些输入缓冲区的大小，访问规则的检索受限于缓冲区大小 这些。 使用标准的 GlobalPlatform INSTALL [用于个性化] 命令，可以将此命令直接发送到 ARA 或通过其安全域
发送到 ARA-M 以检索所有注册到 ARA-M 的 ARA-C 的 AID
发送到 ARA 以从此 ARA 检索剩余的访问规则。
发送到 ARA-M 以检索设备访问控制实施器的配置。
发送到 ARA-M 以从 SE 检索所有访问规则
发送到 ARA 以检索存储在此 ARA 中的访问规则
发送到 ARA-M 以注册由其 AID 标识的 ARA-C。
发送到 ARA 以更新由 ARA-M 管理的刷新标签
发送到 ARA 以从该 SE 的 ARA 中删除访问规则
发送到 ARA 以存储对 SE 的此 ARA 的访问规则
getdata
注意：以前命名为 Response-RefreshTag-DO。 GET DATA [Refresh tag] 命令应返回一个 Response-Refresh-Tag-DO，其中包含一个刷新标签，指示访问控制数据中是否发生了更改。 此刷新标签是 ARA-M 的一个属性（8 字节随机数），是在 ARA-M 检测到安全元件中的访问控制数据更新时新生成的。 ARA-M 应确保新值与先前值不同。
RefreshTag 是一个 8 字节的随机数。 新的 RefreshTag 值指示存储在 SE 中的访问控制数据的变化
响应-ARAM-配置-DO
GET DATA [Config] 命令应返回包含 ARA-M 配置的 Response-ARAM-Config-DO。 如果 GET DATA [Config] 命令返回错误 SW，访问控制执行器应认为 ARA-M 执行规范的 v1.0 版。 有关设备接口版本管理的详细信息，请参见第 4.4 节。
管理证书链
注意：本节仅适用于 REE 环境，其中多个证书可以与一个 REE 应用程序相关联。 不适用于使用UUID标识可信应用程序（TA）的TEE环境。 如第 3.3.2 节所述，如果设备应用程序使用链中的证书签名，并且如果该链的多个证书与访问控制规则相关联，则与证书相关联的规则在最低层级 具有关联规则（可能是最终实体证书）的链应适用。 证书链通常由应用程序提供商嵌入到设备应用程序的安装包（在某些 REE 系统中称为应用程序容器）中。
显示了当设备应用程序由链中的证书签名时，访问控制执行器如何从 ARA-M 查询规则。 在证书链的情况下，访问控制执行器应根据下面定义的算法通过检查与证书链的不同证书关联的规则来检索应应用的规则。 Access Control Enforcer 可能必须向 ARA-M 发出多个 GET DATA [Specific]（已弃用）命令，以确保检索到正确的规则。 在 4.2.3 节程序的步骤 A) 和 C) 中，访问控制执行器使用以下算法检索证书链中适当证书的访问规则。 A) 使用 AID 搜索特定于设备应用程序和 SE 应用程序的规则： 1. SearchRuleFor(EndEntityCertificate, AID) 如果存在规则，则应用该规则并停止规则搜索。 2. SearchRuleFor(IntermediateCertificate<1>, AID) 如果规则存在，则应用该规则并停止规则搜索。
. SearchRuleFor(IntermediateCertificate
存储在安全元件上的每个访问控制规则指定
• 针对特定的 SE 应用程序，或针对给定 SE 上的所有其他 SE 应用程序
• 给定的设备应用程序或所有其他设备应用程序有权访问：
o 所有 APDU、无 APDU 或选定的 APDU
o 所有 NFC 事件或无 NFC 事件
由于访问控制规则可能适用于单个应用程序或多个应用程序，并且由于可能在安全元件的不同位置（例如，在 ARA-M 和 ARA-C 中）定义了单独的规则，因此访问控制规则 可能重叠和冲突，必须定义一种方法来确定应用哪个规则。
设备应用标识符 (DeviceAppID)
访问控制执行器根据存储在安全元件上的访问规则拒绝或允许设备应用程序访问安全元件应用程序。 为了识别设备应用程序并关联设备应用程序和访问规则，访问控制执行器使用设备应用程序标识符（在本规范中称为 DeviceAppID）。 DeviceAppID 标识应用程序，取决于设备运行时，并包含在访问规则中。
AppID或UUID为DeviceAppID
对于可信执行环境 (TEE)，每个设备应用程序的 UUID 用作其 DeviceAppID。 对于富执行环境 (REE) Windows Phone 8，每个设备应用程序的 AppID 用作其 DeviceAppID。
3.1.2 Certificate as DeviceAppID
对于一些REE，比如Android，设备Application Provider的证书的SHA-1哈希值被用作DeviceAppID。 注意：在某些 REE 中，应用程序证书可能会在部署后更改。 这样的证书不适用于 SE 访问控制。 在这种情况下，第 3.1.1 节中定义的全球唯一且防篡改标识符应用作 SE 访问控制实施的 DeviceAppID。
当证书的哈希值用作 DeviceAppID 时，以下注意事项适用：
• 应用程序提供商证书可用于签署多个应用程序。 如果是这样，基于该证书的规则将适用于所有这些应用程序。
• 一个REE 应用程序可能包含多个DeviceAppID。 如果 REE 应用程序包含基于多个证书的多个签名，或者如果 REE 应用程序承载整个
证书链以及用于签署应用程序的子证书。 在这两种情况下，证书都在应用程序中可用，并且在确定应用程序的访问权限时必须考虑每个证书。
DeviceAppID Retrieval
Access Control Enforcer 检索 DeviceAppID（UUID、AppID 或证书的哈希值）的方式超出了本规范的范围，因为它特定于操作系统提供的运行时。 Access Control Enforcer 不对操作系统提供的 DeviceAppID 执行任何检查。