根据https://source.android.com/devices/tech/config/uicc.html,
AR-DO (E3) is extended to include PERM-AR-DO (DB), which is an 8-byte bit mask representing 64 separate permissions.
有人知道PERM-AR-DO的规格吗?
GlobalPlatform安全元素访问控制规范版本1.0和1.1不包含它.对于访问规则数据对象AR-DO(0xE3),仅定义了标签0xD0和0xD1.
解决方法:
数据对象PERM-AR-DO(标签0xDB)与在UICC Carrier Privileges page上定义的其他数据对象(带有SHA-256和PKG-REF-DO的DeviceAppID-REF-DO)一样,是GP的Google专有扩展安全元素访问控制规范.因此,您不会在GP规范中找到有关这些DO的任何信息.
您链接的页面实际上在“常见问题”部分中提供了您问题的答案:
@H_502_22@We assume we can grant access to all carrIEr-based permissions or have a finer-grained control. What will define the mapPing between the bit mask and the actual permissions then? One permission per class? One permission per method specifically? Will 64 separate permissions be enough in the long run?
A: This is reserved for the future, and we welcome suggestions.
因此,答案是尚未定义PERM-AR-DO的解释.这也反映在解析访问规则的AndroID源代码中(在UiccCarrierPrivilegeRules.java on lines 591-601中):
} else if (rule.startsWith(TAG_AR_DO)) { TLV arDo = new TLV(TAG_AR_DO); //E3 rule = arDo.parse(rule, false); // Skip unrelated rules. if (!arDo.value.startsWith(TAG_PERM_AR_DO)) { return null; } TLV permDo = new TLV(TAG_PERM_AR_DO); //DB permDo.parse(arDo.value, true); } else {
此代码解析AR-DO并提取PERM-AR-DO,然后仅删除提取的值(permDo).
同样,生成的AccessRule对象包含一个值accesstype,该值始终设置为0:
long accesstype = 0; [...] AccessRule accessRule = new AccessRule(IccUtils.hexStringToBytes(certificateHash), packagename, accesstype);
此外,在类AccessRule中,除了字段accesstype之外还有一个注释,指示该字段“当前未使用”:
public long accesstype; // This bit is not currently used, but reserved for future use.
总结 以上是内存溢出为你收集整理的有人知道有关PERM-AR-DO的详细信息吗?全部内容,希望文章能够帮你解决有人知道有关PERM-AR-DO的详细信息吗?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)