Объект данных PERM-AR-DO (тег 0xDB), как и другие объекты данных, определенные на UICC Carrier Privileges page (DeviceAppID-REF-DO с SHA-256 и PKG-REF-DO), является специфичным для Google расширение до спецификации контроля доступа к защищенным элементам GP. Следовательно, вы не найдете ничего об этих ДО в спецификациях GP.
Страница, которую вы связаны на самом деле дает ответ на свой вопрос в разделе 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.
Таким образом, ответ в том, что интерпретация ПЕРМЬ-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.
Привет, Майкл, спасибо за ваш ответ. Я не упоминал DeviceAppID-REF-DO с SHA-256 и PKG-REF-DO, поскольку они кажутся необязательными, и я использовал DeviceAppID-REF-DO с SHA-1 (также это не рекомендуется) и не учитывает PKG- REF-DO. –
Один открытый вопрос: Тег PERM-AR-DO кажется обязательным для предоставления привилегий операторам, если я правильно интерпретирую исходный код Android. Таким образом, без этого тега в правиле доступа не могут быть достигнуты привилегии Carrier. Это верно? И если это так, то эквивалент, который должен быть признан таковым в файлах файлов правил доступа (ARF) PKCS # 15 на основе –
@AndyNullcouch Текущая реализация на Android, похоже, предоставляет доступ, независимо от наличия PERM-AR-DO. Что касается ARK PKCS # 15: если я правильно интерпретировал реализацию, то в настоящее время нет эквивалента для ARF. Поле 'accessType' просто устанавливается равным 0 для всех записей сертификатов. –