Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

UICC Перевозчик Привилегии

В Android 5.1 появился механизм предоставления специальных привилегий для API, относящихся к владельцам приложений универсальных интегральных плат (UICC). Платформа Android загружает сертификаты, хранящиеся в UICC, и предоставляет разрешения приложениям, подписанным этими сертификатами, для вызова нескольких специальных API.

Android 7.0 расширил эту функцию, чтобы поддерживать другие источники хранения для правил привилегий операторов UICC, значительно увеличивая количество операторов, которые могут использовать API. Для получения справки по API см. CarrierConfigManager ; для получения инструкций см. Конфигурация несущей .

Операторы имеют полный контроль над UICC, поэтому этот механизм обеспечивает безопасный и гибкий способ управления приложениями от оператора мобильной сети (MNO), размещенными на общих каналах распространения приложений (таких как Google Play), сохраняя при этом специальные привилегии на устройствах и без необходимости подписывать приложения с помощью сертификата платформы для каждого устройства или предварительно установить как системное приложение.

Правила UICC

Хранилище на UICC совместимо со спецификацией контроля доступа GlobalPlatform Secure Element . Идентификатор приложения (AID) на карте - A00000015141434C00 , и стандартная команда GET DATA используется для извлечения правил, хранящихся на карте. Вы можете обновить эти правила с помощью обновлений по беспроводной связи (OTA).

Иерархия данных

Правила UICC используют следующую иерархию данных (двухбуквенная комбинация букв и цифр в скобках является тегом объекта). Каждое правило является REF-AR-DO ( E2 ) и состоит из объединения REF-DO и AR-DO :

  • REF-DO ( E1 ) содержит DeviceAppID-REF-DO или объединение DeviceAppID-REF-DO и PKG-REF-DO .
    • DeviceAppID-REF-DO ( C1 ) хранит подпись сертификата SHA-1 (20 байтов) или SHA-256 (32 байта).
    • PKG-REF-DO ( CA ) - это строка полного имени пакета, определенная в манифесте в кодировке ASCII, максимальная длина 127 байтов.
  • AR-DO ( E3 ) расширен, чтобы включить PERM-AR-DO ( DB ), который является 8-байтовой битовой маской, представляющей 64 отдельных разрешения.

Если PKG-REF-DO отсутствует, доступ предоставляется любому приложению, подписанному сертификатом; в противном случае и сертификат, и имя пакета должны совпадать.

Пример правила

Имя приложения - com.google.android.apps.myapp а сертификат SHA-1 в шестнадцатеричной строке:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

Правило UICC в шестнадцатеричной строке:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

Поддержка файла правил доступа (ARF)

В Android 7.0 добавлена ​​поддержка чтения правил привилегий оператора из файла правил доступа (ARF).

Платформа Android сначала пытается выбрать идентификатор приложения апплета правила доступа (AID) A00000015141434C00 . Если он не находит AID на UICC, он возвращается к ARF, выбрав PKCS15 AID A000000063504B43532D3135 . Android затем читает файл правил управления доступом (ACRF) в 0x4300 и ищет записи с AID FFFFFFFFFFFF . Записи с разными AID игнорируются, поэтому правила для других вариантов использования могут сосуществовать.

Пример содержания ACRF в шестнадцатеричной строке:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

Пример содержимого файла условий контроля доступа (ACCF):

30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

В приведенном выше примере 0x4310 - это адрес для ACCF, который содержит хэш сертификата 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Приложениям, подписанным этим сертификатом, предоставляются операторские права.

Включенные API

Android поддерживает следующие API.

TelephonyManager

SMSManager

Способ, позволяющий абоненту создавать новые входящие SMS-сообщения: injectSmsPdu .

CarrierConfigManager

Метод уведомления конфигурации изменен: notifyConfigChangedForSubId . Для инструкций см. Конфигурация несущей .

CarrierMessagingService

Услуга, которая принимает звонки из системы при отправке или получении новых SMS и MMS. Чтобы расширить этот класс, объявите службу в файле манифеста с разрешением android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE и android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE фильтр намерений с действием #SERVICE_INTERFACE . Методы включают в себя:

Телефонный провайдер

API контент-провайдера, позволяющие вносить изменения (вставка, удаление, обновление, запрос) в базу данных телефонии. Поля значений определены в Telephony.Carriers ; за более подробной информацией обращайтесь к справочнику по API телефонии на developer.android.com.

Платформа Android

На обнаруженном UICC платформа создает внутренние объекты UICC, которые включают в себя правила привилегий оператора как часть UICC. UiccCarrierPrivilegeRules.java загружает правила, анализирует их с карты UICC и кэширует их в памяти. Когда требуется проверка привилегий, UiccCarrierPrivilegeRules сравнивает сертификат вызывающего абонента с его собственными правилами одно за другим. Если UICC удаляется, правила уничтожаются вместе с объектом UICC.

Проверка

Набор тестов совместимости (CTS) включает в себя тесты для API операторов в CtsCarrierApiTestCases.apk . Поскольку эта функция зависит от сертификатов UICC, необходимо подготовить UICC для прохождения этих тестов.

Подготовка UICC

По умолчанию CtsCarrierApiTestCases.apk подписывается ключом разработчика Android со значением хеш-функции 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Тесты также распечатывают ожидаемый хэш сертификата, если сертификаты на UICC не совпадают.

Пример вывода:

junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.
Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81

Чтобы проверить реализацию через CTS с использованием CtsCarrierApiTestCases.apk , у вас должен быть UICC разработчика с правильными правилами UICC или поддержкой ARF. Вы можете попросить поставщика SIM-карты по вашему выбору подготовить UICC для разработчика с правильным ARF, как описано в этом разделе, и использовать этот UICC для запуска тестов. UICC не требует активной сотовой связи для прохождения тестов CTS.

Запуск тестов

Для удобства CTS поддерживает токен устройства, который ограничивает выполнение тестов только на устройствах, настроенных с таким же токеном. Тесты Carrier API CTS поддерживают маркер устройства sim-card-with-certs . Например, следующий токен устройства ограничивает выполнение тестов API оператора связи только на устройстве abcd1234 :

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

При запуске теста без использования токена устройства, тест выполняется на всех устройствах.

Вопросы-Ответы

Как можно обновить сертификаты на UICC?

A: Используйте существующий механизм обновления OTA карты.

Может ли UICC сосуществовать с другими правилами?

A: Хорошо иметь другие правила безопасности на UICC под тем же AID; платформа отфильтровывает их автоматически.

Что происходит, когда UICC удаляется для приложения, которое использует сертификаты?

A: Приложение теряет свои привилегии, потому что правила, связанные с UICC, уничтожаются при удалении UICC.

Есть ли ограничение на количество сертификатов на UICC?

A: Платформа не ограничивает количество сертификатов; но поскольку проверка является линейной, слишком много правил может повлечь задержку проверки.

Есть ли ограничение на количество API, которые мы можем поддерживать этим методом?

A: Нет, но мы ограничиваем область действия API-интерфейсами, связанными с оператором.

Есть ли какие-либо API, запрещающие использование этого метода? Если так, как вы их применяете? (то есть, есть ли у вас тесты для проверки того, какие API поддерживаются этим методом?)

A: См. Раздел «Поведенческая совместимость API» в документе «Определение совместимости Android» (CDD) . У нас есть несколько тестов CTS, чтобы убедиться, что модель разрешений API не изменилась.

Как это работает с функцией мульти-SIM?

О: SIM-карта по умолчанию, указанная пользователем, используется.

Это как-то взаимодействует или пересекается с другими технологиями доступа SE, например, SEEK?

A: В качестве примера, SEEK использует тот же AID, что и в UICC. Таким образом, правила сосуществуют и фильтруются либо SEEK, либо UiccCarrierPrivileges .

Когда лучше проверять привилегии оператора?

A: После состояния SIM-карты загружена трансляция.

Могут ли OEM-производители отключить часть API операторов?

A: Нет. Мы считаем, что текущие API являются минимальным набором, и мы планируем использовать битовую маску для более точного контроля гранулярности в будущем.

Переопределяет ли setOperatorBrandOverride ВСЕ другие формы строк имен операторов? Например, SE13, UICC SPN или сетевой NITZ?

A: Обратитесь к записи SPN в TelephonyManager.

Что делает injectSmsPdu метода injectSmsPdu ?

A: Этот метод облегчает резервное копирование / восстановление SMS в облаке. injectSmsPdu включает функцию восстановления.

Для фильтрации SMS, является onFilterSms вызов onFilterSms основанным на фильтрации порта SMS UDH? Или приложения-операторы имеют доступ ко ВСЕМ входящим SMS?

A: Операторы имеют доступ ко всем данным SMS.

Расширение DeviceAppID-REF-DO для поддержки 32 байт кажется несовместимым с текущей спецификацией GP (которая допускает только 0 или 20 байт), так почему вы вводите это изменение? Разве SHA-1 не достаточно, чтобы избежать столкновений? Вы уже предлагали это изменение в GP, поскольку это может быть обратно несовместимо с существующим ARA-M / ARF?

О: Для обеспечения безопасности на будущее это расширение представляет SHA-256 для DeviceAppID-REF-DO в дополнение к SHA-1, который в настоящее время является единственным вариантом в стандарте GP SEAC. Мы настоятельно рекомендуем использовать SHA-256.

Если DeviceAppID равен 0 (пусто), применяете ли вы правило ко всем приложениям для устройств, на которые не распространяется определенное правило?

A: API-интерфейсы несущей требуют DeviceAppID-REF-DO . Быть пустым предназначено для целей тестирования и не рекомендуется для оперативного развертывания.

Согласно вашей спецификации, PKG-REF-DO используемый сам по себе, без DeviceAppID-REF-DO , не должен приниматься. Но это все еще описано в Таблице 6-4 как расширение определения REF-DO . Это специально? Как ведет себя код, когда в PKG-REF-DO используется только PKG-REF-DO REF-DO ?

A: Возможность иметь PKG-REF-DO в качестве одного элемента значения в REF-DO была удалена в последней версии. PKG-REF-DO должен появляться только в сочетании с DeviceAppID-REF-DO .

Мы предполагаем, что мы можем предоставить доступ ко всем разрешениям на основе носителя или иметь более точный контроль. Если да, что определяет соответствие между битовой маской и фактическими разрешениями? Одно разрешение на класс? Одно разрешение на метод? Достаточно ли 64 отдельных разрешений в долгосрочной перспективе?

A: Это зарезервировано на будущее, и мы приветствуем предложения.

Можете ли вы дополнительно определить DeviceAppID для Android? Это хеш-значение SHA-1 (20 байт) сертификата издателя, используемого для подписи данного приложения, поэтому не должно ли название отражать эту цель? (Это имя может вводить в заблуждение многих читателей, поскольку правило применяется ко всем приложениям, подписанным тем же сертификатом Publisher.)

О: DeviceAppID хранения DeviceAppID поддерживаются существующей спецификацией. Мы попытались минимизировать изменения в спецификациях, чтобы снизить барьер для принятия. Для получения дополнительной информации см. Правила UICC .