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

SubscriptionManager

СмсМенеджер

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

CarrierConfigManager

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

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

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

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

NetworkStatsManager

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

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

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

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

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

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

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

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

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

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

WifiСетьПредложение

При создании объекта 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. 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. 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. ЭФ_УСТ (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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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