3.3 Introduction to Access Control Rule Conflict Resolution
 

3.3 访问控制规则冲突解决简介

本节从高层次讨论访问控制规则冲突解决。 本文档稍后会提供更多详细信息。 规则的优先级不是基于它在其他规则中的阅读顺序。 管理冲突规则的策略基于三个基本原则（按顺序）：
1、具体规则优先。
2. 与终端实体证书关联的规则具有优先权（在证书链的情况下）。
3.限制性规则优先

3.3.1 具体规则优先

特定规则是关联以下内容的规则：
• 一个安全元件应用程序，通过指定其 AID 或通过指定隐式选择的应用程序和
• 通过指定其 DeviceAppID 的设备应用程序

所有其他规则都被视为通用规则。 通用规则是适用于：
• 安全元件应用程序，通过指定其 AID 或通过为未明确指定的设备应用程序指定隐式选择的应用程序（即规则中未指定 DeviceAppID）或
• 设备应用程序通过为未明确指定的安全元件应用程序指定其 DeviceAppID（即规则中未指定 AID）或
• 具有未定义设备应用程序的未定义安全元件应用程序（即，当 AID 和 DeviceAppID 都不存在于任何其他规则中时，将应用此规则）

注意：一般情况下，在考虑规则时，隐式选择的应用程序被视为“具有未知 AID 的特定应用程序”。 安全警告：在支持每个逻辑通道隐式选择不同应用程序概念的 GlobalPlatform 2.2 安全元件上，无论逻辑通道如何，“隐式选择的应用程序”都将适用。 规则按表 3-1 中定义的最具体到最不具体进行评估。

明确引用了安全元素应用程序？

明确引用了设备应用程序？

3.3.2 终端实体证书优先

如果设备应用程序使用证书链中的证书进行签名，则在搜索最具体的规则时，搜索首先基于用于对应用程序进行签名的证书（最终实体证书），然后是下一个证书 链，依此类推，直到找到具有适当特定级别的证书，或者确定链中没有证书具有该级别。 只有这样，搜索才会继续进行到下一个较低的特异性级别。

3.3.3 限制性规则优先

最严格的规则是那些禁止访问设备应用程序以访问 SE 应用程序的规则。 限制较少的规则允许访问，但仅限于使用特定 APDU 时。 限制最少的规则总是允许设备应用程序访问 SE 应用程序。 最严格的规则优先

 3.4 访问控制规则组合与冲突解决

 

当多个规则应用于同一访问请求时，聚合和冲突解决应由 ARA-M 或访问控制执行器执行：
• 如果访问控制执行器使用GET DATA [All] 从安全元件获取所有规则，则访问控制执行器负责合并和解决冲突（如果有）。
  • 如果访问控制执行器使用GET DATA [Specific]（不推荐）获取特定访问请求的访问规则，则ARA-M 有责任合并并解决潜在的冲突。 ARA-M 应确定是否存在适用于定义的引用（由特定或通用设备应用程序标识符和特定或通用 SE 应用程序标识符组成）的多个规则（例如，在 SE 内的不同存储位置）。 然后 ARA-M 将解决冲突（如果有的话），并返回如下所述合并的访问规则数据。

可能会发生规则冲突，尤其是当规则存储在不同位置（ARA-C、ARA-M 或 ARF）时。 ARA 实施应尽可能避免潜在的冲突：
如果同一目标（AID 和 DeviceAppID）的规则已经存在于 SE 的另一个 ARA 中，则任何 ARA 都应拒绝提供规则。 服务提供商将被告知专用状态字“6A 89”。
ARA 将无法检测到与 ARF 中存储的规则的冲突。

但是，在以下情况下，SE 中可能存在适用于同一目标（AID 和 DeviceAppID）的规则：
• 如果规则预先安装在ARA 中并且在ARA 实例化或注册到ARA-M 之后立即可用。
注意：在 ARA 中预先安装访问规则未在本规范中指定，并且可能不会由 ARA 实施。
• 如果ARA-M 从ARF 读取规则。
注意：ARA-M 从 ARF 读取访问规则是一项可选功能。
• 如果ARA-C 被锁定并稍后再次解锁，同时更新了ARA-M 或另一个ARA-C。

如果 ARA-M/ARA-C 实现保证同一目标（AID、DeviceAppID）在 SE 中只存在一个规则，那么 ARA-M 不需要考虑以下算法来解决冲突或合并规则。

如第 3.3.1 节所述，特定规则优先于通用规则。 这种严格的优先级应由访问控制执行器强制执行。 因此，访问控制执行器应首先查找适用于目标 SE 应用程序和目标设备应用程序的规则，并且仅当未找到特定规则时才查找通用规则。2 如果多个规则适用于同一目标（即相同的 REF-DO)，然后这些规则被聚合并且更严格的规则优先于更宽松的规则。 如果多个规则适用于同一目标，则应适用以下逻辑：

• 如果访问规则发生冲突，则根据以下优先级顺序，仅应用具有最高优先级的规则：
从不 (APDU) > APDU 过滤器 > 总是 (APDU)
从不（NFC）> 总是（NFC）
• 如果访问规则属于不同类型（即 NFC 许可、APDU 许可），则两个规则组合在一起，因此两个规则都适用。
• 如果多个访问规则包含APDU 过滤器，那么这些应该在每个OR 操作中组合。 这意味着如果以下过滤器之一匹配，则允许 APDU：

AR1-APDU filter || AR2-APDU filter || AR3-APDU filter || AR4-APDU filte
 

表 3-2 总结了当两个规则（R1、R2）发生冲突时应用哪个规则。 另见附件 D，其中提供了详细示例。 在此表中，“R1+R2”指的是两个规则的组合，其中合并了 APDU 策略（从不允许、APDU 过滤器或始终允许）和 NFC 事件策略（从不允许、始终允许）。

如果规则适用于特定 SE 应用程序，则应应用以下逻辑： • 如果仅存在一个将设备应用程序的 DeviceAppID 与特定 SE 应用程序的 AID 相关联的规则，则拒绝从所有其他设备应用程序访问该 SE 应用程序 .(1vs1)

• 如果存在多个特定规则，每个规则都将不同设备应用程序的 DeviceAppID 与同一 SE 应用程序的 AID 相关联，则拒绝不存在此类规则的所有设备应用程序访问该 SE 应用程序(多对1)