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

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

Строить

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

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 .

,

В 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

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

Строить

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

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 .

To run CTS carrier API tests in Android 12, the device needs to use a SIM with CTS carrier privileges meeting the requirements specified in the latest version of the third-party GSMA TS.48 Test Profile specification.

The same SIM can also be used for versions prior to Android 12.

Modify the CTS SIM profile

  1. Add: CTS carrier privileges in access rule app master (ARA-M) or ARF. Both signatures must be encoded in the carrier privilege rules:
    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. Create: ADF USIM elementary files (EFs) not present in TS.48 and needed for CTS:
    1. EF_MBDN (6FC7), record size: 28, record number: 4
      • Содержание
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), record size:13, record number: 1
      • Content: 00FF…FF
        1. EF_MBI (6FC9), record size: 4, record number: 1
      • Content: Rec1: 01010101
        1. EF_MWIS (6FCA), record size: 5, record number: 1
      • Content: 0000000000
  3. Modify: USIM service table: Enable services n°47, n°48
    1. EF_UST (6F38)
      • Content: 9EFFBF1DFFFE0083410310010400406E01
  4. Modify: DF-5GS and DF-SAIP files
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Content: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Content: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Content: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Content: A0020000FF…FF
  5. Modify: Use the carrier name string Android CTS in respective EFs containing this designation:
    1. EF_SPN (USIM/6F46)
      • Content: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Content: Rec1 430B83413759FE4E934143EA14FF..FF

Match the test profile structure

Download and match the latest version of the following generic test profile structures. These profiles won't have the CTS Carrier Privilege rule personalized or other modifications listed above.

Проведение тестов

For convenience, CTS supports a device token that restricts tests to run only on devices configured with the same token. Carrier API CTS tests support the device token sim-card-with-certs . For example, the following device token restricts carrier API tests to run only on device abcd1234 :

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

When running a test without using a device token, the test runs on all devices.

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

How can certificates be updated on the UICC?

A: Use the existing card OTA update mechanism.

Can UICC coexist with other rules?

A: It's fine to have other security rules on the UICC under the same AID; the platform filters them out automatically.

What happens when the UICC is removed for an app that relies on the certificates on it?

A: The app loses its privileges because the rules associated with the UICC are destroyed on UICC removal.

Is there a limit on the number of certificates on the UICC?

A: The platform doesn't limit the number of certificates; but because the check is linear, too many rules may incur a latency for check.

Is there a limit to the number of APIs that we can support with this method?

A: No, but we limit the scope to carrier-related APIs.

Are there some APIs prohibited from using this method? If so, how do you enforce them? (that is, do you have tests to validate which APIs are supported with this method?)

A: See the API Behavioral Compatibility section of the Android Compatibility Definition Document (CDD). We have some CTS tests to make sure that the permission model of the APIs isn't changed.

How does this work with the multi-SIM feature?

A: The default SIM specified by the user is used.

Does this in any way interact or overlap with other SE access technologies, for example, SEEK?

A: As an example, SEEK uses the same AID as on the UICC. So the rules coexist and are filtered by either SEEK or UiccCarrierPrivileges .

When is it a good time to check carrier privileges?

A: After the SIM state loaded broadcast.

Can OEMs disable part of carrier APIs?

A: No. We believe that the current APIs are the minimal set, and we plan to use the bit mask for finer granularity control in the future.

Does setOperatorBrandOverride override ALL other forms of operator name strings? For example, SE13, UICC SPN, or network-based NITZ?

Yes, the operator brand override has the highest priority. When it's set, it overrides ALL other forms of operator name strings.

What does the injectSmsPdu method call do?

A: This method facilitates SMS backup/restore in the cloud. The injectSmsPdu call enables the restore function.

For SMS filtering, is the onFilterSms call based on SMS UDH port filtering? Or do carrier apps have access to ALL incoming SMS?

A: Carriers have access to all SMS data.

The extension of DeviceAppID-REF-DO to support 32 bytes appears to be incompatible with the current GP spec (which allows 0 or 20 bytes only), so why are you introducing this change? Isn't SHA-1 sufficient to avoid collisions? Have you proposed this change to GP already, as this could be backward incompatible with existing ARA-M/ARF?

A: For providing future-proof security, this extension introduces SHA-256 for DeviceAppID-REF-DO in addition to SHA-1, which is currently the only option in the GP SEAC standard. We highly recommend using SHA-256.

If DeviceAppID is 0 (empty), do you apply the rule to all device apps not covered by a specific rule?

A: Carrier APIs require DeviceAppID-REF-DO be populated. Being empty is intended for test purposes and isn't recommended for operational deployments.

According to your spec, PKG-REF-DO used just by itself, without DeviceAppID-REF-DO , shouldn't be accepted. But it's still described in Table 6-4 of the specification as extending the definition of REF-DO . Is this on purpose? How does the code behave when only PKG-REF-DO is used in REF-DO ?

A: The option of having PKG-REF-DO as a single value item in REF-DO was removed in the latest version. PKG-REF-DO should occur only in combination with DeviceAppID-REF-DO .

We assume that we can grant access to all carrier-based permissions or have finer-grained control. If so, what defines the mapping between the bit mask and the actual permissions? One permission per class? One permission per method? Are 64 separate permissions enough in the long run?

A: This is reserved for the future, and we welcome suggestions.

Can you further define DeviceAppID for Android specifically? This is the SHA-1 (20 bytes) hash value of the Publisher certificate used to sign the given app, so shouldn't the name reflect that purpose? (The name could be confusing to many readers as the rule is then applicable to all apps signed with that same Publisher certificate.)

A: The DeviceAppID storing certificates is supported by the existing spec. We tried to minimize spec changes to lower the barrier for adoption. For details, see Rules on UICC .