回答

3

UICC Carrier Privileges page(使用SHA-256和PKG-REF-DO的DeviceAppID-REF-DO)上定義的其他數據對象一樣,數據對象PERM-AR-DO(標記0xDB)是Google特定的擴展到GP安全元件訪問控制規範。因此,您不會在GP規範中找到關於這些DO的任何信息。

你鏈接的頁面實際上提供了一個答案在FAQ部分你的問題:

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. 
+0

嗨邁克爾,感謝您的回答。 我沒有提及帶有SHA-256和PKG-REF-DO的DeviceAppID-REF-DO,因爲它們似乎是可選的,我使用帶有SHA-1的DeviceAppID-REF-DO(也不推薦),並且省去了PKG- REF-DO。 –

+0

一個開放的問題:如果我正確解釋Android源代碼,PERM-AR-DO標記似乎被強制授予運營商權限。因此,如果在訪問規則中沒有此標記,則不能實現運營商權限。那是對的嗎?如果是的話,還有一個相當於在Access Rule Rule文件(ARF)PKCS#15文件中被識別爲 –

+0

@AndyNullcouch Android中的當前實現似乎授予訪問權限,無論是否存在PERM-AR-DO。關於PKCS#15 ARF:如果我正確地插入了實現,那麼目前沒有ARF的等價物。所有證書條目的'accessType'字段都設置爲0。 –

相關問題