Кто-нибудь знает подробности о PERM-AR-DO?

#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.