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

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

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

Платформа Android

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

Проверка

Для проверки реализации через Compatibility Test Suite (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.

Изменить профиль 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. Рек2-н: ФФ…ФФ
    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. ЭФ_УСТ (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: Используйте существующий механизм обновления карты по воздуху.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для фильтрации SMS, вызов 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 .