#android #specifications #access-control #sim-card #globalplatform
#Android #технические характеристики #управление доступом #sim-карта #globalplatform
Вопрос:
Согласно 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:
Объект данных PERM-AR-DO (тег 0xDB), как и другие объекты данных, определенные на странице привилегий оператора UICC (DeviceAppID-REF-DO с SHA-256 и PKG-REF-DO), является специфичным для Google расширением спецификации управления доступом к защищенному элементу GP. Следовательно, вы ничего не найдете об этих DOS в спецификациях GP.
Страница, на которую вы ссылались, фактически дает ответ на ваш вопрос в разделе часто задаваемых вопросов:
Мы предполагаем, что можем предоставить доступ ко всем разрешениям на основе оператора или иметь более детальный контроль. Что тогда будет определять сопоставление между битовой маской и фактическими разрешениями? Одно разрешение на класс? Конкретно одно разрешение для каждого метода? Будет ли достаточно 64 отдельных разрешений в долгосрочной перспективе?
О: Это зарезервировано на будущее, и мы приветствуем предложения.
Итак, ответ заключается в том, что интерпретация PERM-AR-DO еще не определена. Это также отражено в исходном коде Android, который анализирует правила доступа (в uiccarrierprivilegerules.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 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.
Комментарии:
1. Привет, Майкл, спасибо за ваш ответ. Я не упомянул DeviceAppID-REF-DO с SHA-256 и PKG-REF-DO, поскольку они кажутся необязательными, и я использовал DeviceAppID-REF-DO с SHA-1 (также это не рекомендуется) и исключил PKG-REF-DO.
2. Один открытый вопрос: тег PERM-AR-DO, по-видимому, является обязательным для предоставления привилегий оператора, если я правильно интерпретирую исходный код Android. Таким образом, без этого тега в правиле доступа привилегии оператора не могут быть достигнуты. Это правильно? И если да, существует ли эквивалент, который будет распознан как таковой в файлах правил доступа (ARF) PKCS # 15 на основе файлов
3. @AndyNullcouch Текущая реализация в Android, похоже, предоставляет доступ независимо от существования PERM-AR-DO. Что касается ARF PKCS # 15: если я правильно интерпретировал реализацию, то в настоящее время для ARF нет эквивалента.
accessType
Поле просто устанавливается равным 0 для всех записей сертификата.4. Я создал это правило в 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
5. Поздняя, но, тем не менее, некоторая, возможно, полезная информация: причина, по которой она не работала на некоторых устройствах, заключается в том, что апплет ARA-M не был установлен с возможностью множественного выбора из-за того, что CarrierPrivileges пытается выбрать апплет до завершения SmartcardService. (Этого не произошло в режиме высокой отладки из-за большего количества протоколирования и другого времени) Также я получил объяснение, что для ARF, не работающего с моими симами, поскольку Google использует жестко заданные значения для AC Main вместо использования идентификаторов файлов, указанных в ARF.