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

Поддержка файла правил доступа (ARF)

В Android 7.0 добавлена ​​поддержка чтения правил привилегий оператора связи из файла правил доступа (ARF).

Платформа Android сначала пытается выбрать идентификатор приложения (AID) апплета правил доступа (ARA) 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.

ТелефонияМенеджер

• Метод, позволяющий приложению оператора запрашивать у UICC запрос/ответ: getIccAuthentication .
• Метод проверки того, предоставлены ли вызывающему приложению привилегии оператора: hasCarrierPrivileges .
• Методы переопределения бренда и номера:
  • setOperatorBrandOverride
  • setLine1NumberForDisplay
  • setVoiceMailNumber
• Способы прямой связи UICC:
  • iccOpenLogicalChannel
  • iccCloseLogicalChannel
  • iccExchangeSimIO
  • iccTransmitApduLogicalChannel
  • iccTransmitApduBasicChannel
  • sendEnvelopeWithStatus
• Методы установки глобального режима устройства: setPreferredNetworkTypeToGlobal .

СмсМенеджер

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

CarrierConfigManager

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

CarrierMessagingService

Услуга, принимающая вызовы из системы при отправке или получении новых SMS и MMS. Чтобы расширить этот класс, объявите службу в файле манифеста с разрешением android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE и включите фильтр намерений с действием #SERVICE_INTERFACE . Методы включают в себя:

• onFilterSms
• onSendTextSms
• onSendDataSms
• onSendMultipartTextSms
• onSendMms
• onDownloadMms

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

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

Платформа 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. Хэш1 (SHA1): 61: ED: 37: 7E: 85: D3: 86: A8: DF: EE: 6B: 86: 4B: D8: 5B: 0B: FA: A5: AF: 81
   2. Хэш2 (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
      • Содержание: 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 или других модификаций, перечисленных выше.

• Структура общего профиля теста GSMA TS.48
• Пример профиля TS.48 в формате eSIM DER

Запуск тестов

Для удобства 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 сосуществовать с другими правилами?

A: Можно использовать другие правила безопасности на 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?

О. Обратитесь к записи имени участника-службы в TelephonyManager .

Что делает вызов метода 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 . Это специально? Как ведет себя код, когда в PKG-REF-DO REF-DO ?

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

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

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

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

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