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)