Привилегии оператора UICC

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

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

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

Правила для UICC

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

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

В правилах 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) – восьмибайтную битовую маску, представляющую 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 сначала пытается выбрать идентификатор приложения (AID) правила доступа A00000015141434C00. Если AID не найден на UICC, используется ARF, для чего выбирается AID PKCS15 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

TelephonyCallback

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

SubscriptionManager

SmsManager

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

CarrierConfigManager

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

Инструкции приведены в статье Конфигурация оператора связи.

Сборка

Метод получения серийного номера оборудования (если доступен): getSerial

BugreportManager

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

NetworkStatsManager

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

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

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

CarrierMessagingService

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

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

CarrierService

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

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

В CarrierService доступны следующие методы:

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

Поставщик услуг телефонии

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

WifiNetworkSuggestion

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

платформа Android

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

Проверка

Чтобы проверить реализацию с помощью Compatibility Test Suite (CTS), используя CtsCarrierApiTestCases.apk, вам понадобится UICC разработчика с правилами UICC или поддержкой ARF. Попросите поставщика SIM-карт подготовить UICC для разработчиков с правильным ARF, как описано в этом разделе, и используйте эту 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.

Чтобы запустить тесты CTS carrier API в Android 12, на устройстве должна быть установлена SIM-карта с привилегиями CTS carrier, соответствующими требованиям, указанным в последней версии спецификации стороннего профиля тестирования GSMA TS.48 с фиксированным ADM1, key = 55555555 / 0x3535353535353535.

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

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

  1. Добавьте привилегии оператора CTS в ARA-M или ARF. Обе подписи должны быть закодированы в правилах привилегий оператора:
    1. Hash1(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 поддерживает токен устройства, который позволяет запускать тесты только на устройствах, настроенных с тем же токеном. Тесты Carrier API CTS поддерживают токен устройства sim-card-with-certs. Например, следующий токен устройства ограничивает тесты API оператора, чтобы они выполнялись только на устройстве abcd1234:

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

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

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

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

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

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

Да, это допустимо. Платформа автоматически отфильтрует их.

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

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

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

А. Платформа не ограничивает количество сертификатов, но из-за линейной проверки слишком большое количество правил может привести к задержке.

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

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

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

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

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

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

Взаимодействует ли эта технология с другими технологиями доступа к защищенному элементу, например SEEK?

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

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

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

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

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

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

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

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

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

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

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

Расширение DeviceAppID-REF-DO до 32 байт, по-видимому, несовместимо с текущей спецификацией GP (которая допускает только 0 или 20 байт), поэтому зачем вы вносите это изменение? Разве SHA-1 недостаточно надежен, чтобы избежать коллизий? Вы уже предложили это изменение Google Play? Оно может быть обратно несовместимо с существующими 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…