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 Access Control . Идентификатор приложения (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) апплета правил доступа (ARA) 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?

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

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

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

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

О: См. Раздел «Поведенческая совместимость 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 ?

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

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

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

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

A: Для обеспечения безопасности будущего это расширение вводит 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 ?

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

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

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

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

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