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

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

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

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

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

SmsManager

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

CarrierConfigManager

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

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

BugreportManager

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

NetworkStatsManager

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

ImsMmTelManager

ImsRcsManager

Менеджер по обеспечению

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

Предложение по сети Wi-Fi

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

Платформа Android

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

Проверка

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

Подготовьте карту 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.

Изменить профиль CTS SIM

  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. Запись 1: 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 поддерживает токен устройства, который ограничивает запуск тестов только на устройствах, настроенных с тем же токеном. Тесты 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 из приложения, которое использует имеющиеся на ней сертификаты?

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

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

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

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

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

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

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

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

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

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

A: Например, SEEK использует тот же AID, что и на UICC. Поэтому правила существуют одновременно и фильтруются либо по SEEK, либо UiccCarrierPrivileges .

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

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

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

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

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

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

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

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

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

A: Операторы имеют доступ ко всем данным 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 PKG-REF-DO REF-DO ?

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

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

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

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

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