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

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

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

Операторы имеют полный контроль над UICC, поэтому этот механизм обеспечивает безопасный и гибкий способ управления приложениями от оператора мобильной сети (MNO), размещенными на общих каналах распространения приложений (таких как Google Play), сохраняя при этом особые привилегии на устройствах и без необходимости. для подписи приложений с помощью сертификата платформы для каждого устройства или предварительной установки в качестве системного приложения.

Правила на UICC

Хранение на UICC совместим с GlobalPlatform Secure спецификации элемента управления доступом . Идентификатор приложения (АИД) на карточке 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 платформы Первые попытки выбрать правило доступа апплет (ARA) идентификатор приложения (AID) A00000015141434C00 . Если он не находит AID на UICC, он возвращается к АСО, выбрав 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 является адресом ФАКК, который содержит сертификат хэш 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Приложениям, подписанным этим сертификатом, предоставляются привилегии оператора связи.

Включенные API

Android поддерживает следующие API.

TelephonyManager

SmsManager

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

CarrierConfigManager

Способ уведомления конфигурации изменен: notifyConfigChangedForSubId . Для получения инструкций см Конфигурация Carrier .

CarrierMessagingService

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

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

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

Платформа Android

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

Проверка

Для проверки реализации через Compatibility Test Suite (CTS) с помощью CtsCarrierApiTestCases.apk , вы должны иметь UICC разработчиков с правильными правилами UICC или поддержки АРФ. Вы можете попросить поставщика 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 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 .

Для запуска CTS испытаний несущей API в Android 12, устройство должно использовать SIM - карту с привилегиями носителя CTS отвечают требования , указанным в последней версии третьей стороны GSMA TS.48 испытание профиль спецификации.

Эту же SIM-карту можно использовать для версий до Android 12.

Изменение профиля SIM-карты CTS

  1. Добавить: Привилегая C Carrier в АРА-М или АСО. Обе подписи должны быть закодированы в правилах привилегий оператора связи:
    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
  1. Создание: ADF USIM ЭФ нет в 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
  2. Изменить: USIM Service Таблица: Включение служб п ° 47, п ° 48
    1. EF_UST (6F38)
      • Содержимое: 9EFFBF1DFFFE0083410310010400406E01
  3. Изменить: 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
  4. Изменить: Имя несущей строка должна быть Android CTS в соответствующих ЭФ , содержащих это обозначение:
    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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имеет ли setOperatorBrandOverride переопределить все другие формы строки имени оператора? Например, SE13, UICC SPN или сетевой NITZ?

A: Обратитесь к записи SPN в TelephonyManager

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

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

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

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

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

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

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