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

Пример содержимого 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 имеет интерфейс с методом обратного вызова для уведомления вызывающего приложения об изменении зарегистрированных состояний:

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

SMSManager

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

CarrierConfigManager

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

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

Строить

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

Менеджер отчетов

Способ запуска отчета об ошибке подключения, который представляет собой специализированную версию отчета об ошибке, содержащую только информацию для отладки проблем, связанных с подключением: 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 со специальными флагами, чтобы позволить процессу службы оператора связи работать в специальном резервном сегменте приложения . Это освобождает приложение службы оператора связи от ограничений, связанных с простоем приложений, и повышает вероятность его стабильной работы при низком уровне памяти устройства. Однако, если приложение службы оператора связи по какой-либо причине аварийно завершает работу, оно теряет все вышеуказанные привилегии до перезапуска приложения и восстановления связи. Поэтому крайне важно поддерживать стабильность приложения службы оператора связи.

К методам класса CarrierService относятся:

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

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

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

Предложение по WifiNetwork

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

  • Метод для установки идентификатора подписки: setSubscriptionId
  • Способ настройки группы подписок: setSubscriptionGroup

платформа Android

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

Проверка

Для проверки реализации с помощью набора тестов совместимости (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 API оператора связи в Android 12 устройство должно использовать SIM-карту с правами CTS оператора связи, соответствующими требованиям, указанным в последней версии спецификации профиля тестирования GSMA TS.48 от стороннего разработчика с фиксированным ADM1, ключ = 55555555 / 0x3535353535353535 .

Ту же 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
      • Содержание: Запись 1: 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 для API оператора связи поддерживают токен устройства 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 для приложения, которое использует эти сертификаты?

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

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

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

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

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

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

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

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

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

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

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

Когда целесообразно проверять права оператора связи?

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

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

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

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

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

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

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

Что касается фильтрации SMS, основана ли функция onFilterSms на фильтрации по порту UDH для SMS? Или же приложения операторов связи имеют доступ ко ВСЕМ входящим 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 . Это сделано намеренно? Как ведет себя код, когда в REF-DO используется только PKG-REF-DO DO?

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

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

А: Это вопрос, который мы оставим на будущее, и мы будем рады вашим предложениям.

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

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