Привилегии оператора 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

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

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

Платформа Android сначала пытается выбрать приложение правила доступа (ARA) 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.

Менеджер по телефонии

ТелефонияОбратный звонок

TelephonyCallback имеет интерфейсы с методом обратного вызова для уведомления вызывающего приложения при изменении зарегистрированных состояний:

Менеджер подписки

СмсМенеджер

  • Метод, позволяющий вызывающему абоненту создавать новые входящие SMS-сообщения: injectSmsPdu .
  • Метод отправки текстового SMS-сообщения без записи в поставщика SMS: sendTextMessageWithoutPersisting

CarrierConfigManager

  • Метод уведомления об изменении конфигурации: notifyConfigChangedForSubId .
  • Метод получения конфигурации оператора связи для подписки по умолчанию: getConfig
  • Метод получения конфигурации оператора связи для указанной подписки: getConfigForSubId

Инструкции см. в разделе «Конфигурация оператора связи» .

Менеджер отчетов об ошибках

Метод для запуска отчета об ошибках подключения, который представляет собой специализированную версию отчета об ошибках, включающую только информацию для отладки проблем, связанных с подключением: startConnectivityBugreport

Диспетчер сетевой статистики

  • Метод запроса сводки об использовании сети: querySummary
  • Метод запроса истории использования сети: queryDetails
  • Способы регистрации или отмены регистрации обратного вызова использования сети:

ИмсМмТелМенеджер

ИмсРксМенеджер

Диспетчер обеспечения

EuiccМенеджер

Метод переключения (включения) данной подписки: switchToSubscription

Оператор обмена сообщениямиСервис

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

  • Метод фильтрации входящих SMS-сообщений: onFilterSms
  • Метод перехвата текстовых SMS-сообщений, отправленных с устройства: onSendTextSms
  • Метод перехвата двоичных SMS-сообщений, отправленных с устройства: onSendDataSms
  • Метод перехвата длинных SMS-сообщений, отправленных с устройства: onSendMultipartTextSms
  • Метод перехвата MMS-сообщений, отправленных с устройства: onSendMms
  • Метод загрузки полученных MMS-сообщений: onDownloadMms

ПеревозчикСервис

Служба, предоставляющая системе функции, специфичные для оператора связи. Чтобы расширить этот класс, объявите службу в файле манифеста приложения с разрешением android.Manifest.permission#BIND_CARRIER_SERVICES и включите фильтр намерений с действием CARRIER_SERVICE_INTERFACE . Если у службы есть долговременная привязка, установите для android.service.carrier.LONG_LIVED_BINDING значение true в метаданных службы.

Платформа связывает CarrierService со специальными флагами, чтобы позволить процессу обслуживания оператора выполняться в специальном резервном сегменте приложения . Это освобождает приложение службы оператора связи от ограничения простоя приложения и повышает вероятность его продолжения работы, когда памяти устройства недостаточно. Однако если приложение службы оператора связи по какой-либо причине выйдет из строя, оно потеряет все вышеперечисленные привилегии до тех пор, пока приложение не перезапустится и привязка не будет восстановлена. Поэтому очень важно поддерживать стабильность приложения службы оператора связи.

Методы в CarrierService включают:

  • Чтобы переопределить и установить конфигурации, специфичные для оператора связи: onLoadConfig
  • Чтобы сообщить системе о предстоящем изменении сети оператора связи с помощью приложения оператора связи: notifyCarrierNetworkChange

провайдер телефонии

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

Wi-FiСетьПредложение

При создании объекта WifiNetworkSuggestion используйте следующие методы, чтобы задать идентификатор подписки или группу подписки:

Платформа Android

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

Валидация

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

Подготовьте UICC

Для Android 11 и более ранних версий CtsCarrierApiTestCases.apk подписывается aosp-testkey с хеш-значением 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 .

Начиная с Android 12, CtsCarrierApiTestCases.apk подписывается cts-uicc-2021-testkey , хеш-значением CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0 .

Для запуска тестов API оператора связи CTS в Android 12 устройству необходимо использовать SIM-карту с привилегиями оператора связи CTS, соответствующую требованиям, указанным в последней версии сторонней спецификации тестового профиля GSMA TS.48 .

Эту же SIM-карту можно использовать и для версий до Android 12.

Изменить профиль SIM-карты CTS

  1. Добавлено: привилегии оператора CTS в мастере приложения правил доступа (ARA-M) или ARF. Обе подписи должны быть закодированы в правилах привилегий оператора связи:
    1. Хэш1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Hash2(SHA256): CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
  2. Создайте: элементарные файлы ADF USIM (EF), которых нет в TS.48 и которые необходимы для CTS:
    1. EF_MBDN (6FC7), размер записи: 28, номер записи: 4
      • Содержание
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), размер записи: 13, номер записи: 1
      • Содержимое: 00FF…FF
        1. EF_MBI (6FC9), размер записи: 4, номер записи: 1
      • Содержимое: Rec1: 01010101.
        1. EF_MWIS (6FCA), размер записи: 5, номер записи: 1
      • Содержание: 0000000000
  3. Изменить: Таблица служб USIM: Включить службы № 47, № 48.
    1. EF_UST (6F38)
      • Содержимое: 9EFFBF1DFFFE0083410310010400406E01
  4. Изменить: файлы DF-5GS и DF-SAIP.
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Содержимое: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Содержимое: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Содержимое: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Содержимое: A0020000FF…FF
  5. Изменить: используйте строку имени оператора связи Android CTS в соответствующих EF, содержащих это обозначение:
    1. EF_SPN (USIM/6F46)
      • Содержимое: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Содержимое: Rec1 430B83413759FE4E934143EA14FF..FF

Сопоставьте структуру тестового профиля

Загрузите и сопоставьте последнюю версию следующих структур общего профиля тестирования. В этих профилях не будет персонализированного правила CTS Carrier Privilege или других изменений, перечисленных выше.

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

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

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

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

Часто задаваемые вопросы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, переопределение бренда оператора имеет высший приоритет. Когда он установлен, он переопределяет ВСЕ другие формы строк имен операторов.

Что делает вызов метода injectSmsPdu ?

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

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

О: Операторы связи имеют доступ ко всем данным 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 (пусто), применяется ли правило ко всем приложениям устройства, на которые не распространяется конкретное правило?

О. Для API оператора связи необходимо указать DeviceAppID-REF-DO . Пустое значение предназначено для целей тестирования и не рекомендуется для оперативного развертывания.

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

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

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

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

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

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