有人知道PERM-AR-DO的详细信息吗?

3
根据https://source.android.com/devices/tech/config/uicc.html
AR-DO(E3)已扩展到包括PERM-AR-DO(DB),它是一个8字节的位掩码,表示64个单独的权限。
有人知道PERM-AR-DO的规范吗?
GlobalPlatform安全元素访问控制规范版本1.0和1.1不包含它。对于访问规则数据对象AR-DO(0xE3),只定义了标签0xD0和0xD1。
1个回答

4
数据对象PERM-AR-DO(标签0xDB)与UICC Carrier Privileges page上定义的其他数据对象(具有SHA-256和PKG-REF-DO的DeviceAppID-REF-DO),是谷歌对GP Secure Element Access Control规范的特定扩展。因此,在GP规范中找不到关于这些DO的任何内容。
你链接的页面实际上在FAQ部分提供了问题的答案:
“我们假设我们可以授予所有基于运营商的权限或进行更细粒度的控制。那么,什么将定义位掩码与实际权限之间的映射?每个类别一个权限?每个方法一个权限?64个单独的权限长期来看是否足够?”
答案是这是保留给未来的,并且我们欢迎建议。因此,尚未定义PERM-AR-DO的解释。这也反映在解析访问规则的Android源代码中(UiccCarrierPrivilegeRules.java第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 <b>permDo</b> = new TLV(TAG_PERM_AR_DO); //DB
        <b>permDo</b>.parse(arDo.value, true);
    } else  {

这段代码解析了AR-DO并提取了PERM-AR-DO,但是却舍弃了提取出来的值(permDo)。
类似地,生成的AccessRule对象包含一个名为accessType的值,该值始终设置为0:
    long accessType = <b>0</b>;
    <i>[...]</i>
    AccessRule accessRule = new AccessRule(IccUtils.hexStringToBytes(certificateHash),
                                           packageName, <b>accessType</b>);

此外,在AccessRule类中,除了字段accessType旁边有一条注释,指出该字段“目前未被使用”:
    public long accessType;   // <b>This bit is not currently used, but reserved for future use.</b>

我在ARA-M中创建了此规则: E2 22 (REF-AR-DO) E1 18 (REF-DO) 4F 00 C1 14 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 E3 06 D0 01 01 D10101,但测试应用程序(CtsCarrierApiTestCases.apk)显示异常:junit.framework.AssertionFailedError:此测试需要具有运营商特权规则的SIM卡。 证书哈希值:61ed377e85d386a8dfee6b864bd85b0bfaa5af81 - Andy Nullcouch
有什么想法吗?我唯一的想法是需要这个缺失的DB标签。 - Andy Nullcouch
@AndyNullcouch 我不确定我理解你的问题。如果61ed377e85d386a8dfee6b864bd85b0bfaa5af81是您的SHA-1证书哈希值(即通过MessageDigest.getInstance("SHA-1).digest(signature.toByteArray())获得的哈希值之一,其中一个签名在getPackageManager().getPackageInfo(getPackageName(), PackageManager.GET_SIGNATURES).signatures中),为什么您期望该规则(具有不同的哈希值)与您的包匹配呢? - Michael Roland
抱歉因为我的错误,在评论中我粘贴了错误的SHA-1到我的命令里。当然应该是匹配的SHA-1到这个异常(C1 14 61ED377E85D386A8DFEE6B864BD85B0BFAA5AF81)。我甚至能在SIM-ME跟踪中看到手机(尝试了两个不同的Android N手机)检索到了这个规则,但我仍然得到了这个异常。 - Andy Nullcouch
1
虽然有些晚,但仍然可能有用的信息:某些设备无法正常工作的原因是,由于运营商特权尝试在SmartcardService完成之前选择应用程序,因此ARA-M小程序未安装为多选。 (由于更多日志记录和不同的时间,这在调试HIGH模式下没有发生) 此外,我得到了一个解释,即对于ARF与我的SIM卡不起作用,因为Google使用硬编码值来代替在ARF中提到的文件ID的AC Main。 - Andy Nullcouch
显示剩余7条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接