В Android 17 (уровень API 37) представлена схема подписи APK версии 3.2, гибридная схема подписи, разработанная для поддержки перехода экосистемы Android к постквантовой криптографии (PQC).
Поскольку отрасль внедряет алгоритмы квантовой криптографии (PQC) в больших масштабах, схема версии 3.2 обеспечивает многоуровневую защиту. Она требует подписи APK-файлов как классическим алгоритмом, таким как RSA или ECDSA, так и алгоритмом PQC. Этот гибридный подход использует классическую криптографию для защиты вашего APK-файла, одновременно защищая его от угроз со стороны квантовых компьютеров.
Цель и подробности
Схема v3.2 работает как стандартный, соответствующий отраслевым стандартам переходный механизм. Благодаря этому гибридному подходу вы получаете преимущества квантовой устойчивости PQC, продолжая при этом полагаться на проверенную безопасность классических алгоритмов подписи. Как только новые стандартизированные алгоритмы PQC достигнут операционной зрелости в масштабах, вы сможете перейти от этой гибридной конфигурации к единому ключу подписи PQC. Поддержка схемы подписи v3.2 начинается с Android 17. Более ранние версии Android пропускают блокировку v3.2 и используют предыдущие схемы для проверки подписи.
Для обеспечения безопасности и предотвращения атак с понижением версии во время этого перехода, схема v3.2 предусматривает следующие правила поведения:
- Новый ключевой материал: Переход к гибридному блоку требует генерации новых классических ключей и ключей PQC. Не используйте повторно ключевой материал между гибридными и негибридными конфигурациями.
- Неявная ротация: платформа рассматривает гибридный блок как неявную ротацию ключа. Платформа добавляет новый классический ключ к существующей цепочке подписи приложения в качестве предпоследнего ключа и рассматривает новый ключ PQC как текущий идентификатор подписи приложения.
- Общая родословная: Для успешного выполнения неявной ротации как новый классический ключ, так и новый ключ PQC в гибридном блоке должны иметь одинаковую историю подписи. Необходимо продублировать существующую историю подписи приложения — будь то один исходный ключ или родословная ранее ротированных ключей — для обоих новых гибридных подписантов. Платформа использует эту общую родословную для проверки того, что организация, переводящая приложение на гибридную схему, является законным владельцем текущего идентификатора подписи приложения.
- Ограничение PQC для одного подписанта: на начальном этапе внедрения PQC Android явно ограничивает использование алгоритмов PQC гибридным блоком версии 3.2. Платформа не проверяет конфигурацию PQC с одним подписантом, используя предыдущие схемы подписи, такие как версии 2, 3.0 или 3.1.
- Возврат к исходному состоянию: При переходе от гибридного блока версии 3.2 обратно к блоку с одним подписантом — будь то классический подписант или подписант PQC (если поддержка будет реализована в будущих версиях) — платформа проверяет наличие как классического, так и PQC-ключей из гибридного блока в новой цепочке подписи и подтверждает наличие нового единственного подписанта.
Передовые методы перехода
Для обеспечения совместимости с более старыми версиями Android и безопасного обновления при переходе к подписи PQC, APK-файлы должны по-прежнему включать стандартный блок подписи версии 3.0 или 3.1, подписанный одним классическим ключом. Поскольку только Android 17 (уровень API 37) и выше поддерживают гибридную схему 3.2, это требование позволяет устройствам с более старыми версиями проверять и устанавливать приложение.
Классическая резервная конфигурация
Для обеспечения оперативной безопасности во время перехода к контролю качества продукции следует внедрить классическую резервную конфигурацию.
- Существующие приложения: В качестве естественной основы для этого резервного варианта используется текущий ключ подписи приложения, K0.
- Новые приложения: генерируется базовый классический ключ подписи K0, а также новые гибридные ключи C_K1 и PQC_K1 для установления первоначальной идентификации.
В обоих сценариях APK-файл должен включать стандартный блок подписи версии 3.0 или 3.1, подписанный классическим ключом K0, а также гибридный блок версии 3.2, подписанный новыми гибридными ключами C_K1 и PQC_K1.
В ходе первоначального развертывания схемы версии 3.2, в цепочке подписи гибридного блока должна быть предусмотрена возможность ROLLBACK для K0. В случае возникновения проблем с развертыванием, эта возможность позволяет приложению вернуться к классической подписи без нарушения обновлений пользователей. После того, как достаточные данные во время выполнения подтвердят стабильность гибридного развертывания, мы рекомендуем удалить возможность ROLLBACK в последующих обновлениях, чтобы обеспечить полную безопасность ваших новых ключей.
Долгосрочные требования к конфигурации
Необходимо поддерживать эту гибридную конфигурацию подписи до тех пор, пока ваше приложение ориентировано на платформу, которая поддерживает исключительно гибридную схему. Даже если версия платформы поддерживает ключи PQC с одним подписантом, необходимо подписывать любой APK-файл, ориентированный на версию, требующую гибридного блока v3.2, обоими ключами.
Схема подписи APK v3.2 блок
Блок подписи APK хранит блок подписи версии 3.2 вместе с любыми блоками подписи версий 2, 3.0 и 3.1.
Структура блока v3.2 аналогична v3.0, но использует новый идентификатор блока, 0x70e1c89f , для обозначения того, что это гибридный блок. Действительный блок v3.2 должен содержать ровно двух подписантов.
Поддерживаемые алгоритмы
В версии 3.2 изначально поддерживаются следующие алгоритмы подписи PQC:
- ML-DSA-65
- ML-DSA-87
Они объединяются со стандартными классическими алгоритмами подписи, такими как те, которые поддерживаются в версиях 3.0 и 3.1, образуя гибридный блок.
Формат
Блок подписи APK хранит блок схемы подписи APK версии 3.2 под идентификатором 0x70e1c89f .
Формат блока v3.2 идентичен формату v3.0, но последовательность элементов подписывающего регистратора верхнего уровня должна содержать ровно две записи, ориентированные на одну и ту же версию SDK:
- Последовательность подписантов с префиксом длины:
- Подписывающий с префиксом длины (классический)
- Подписывающий с префиксом длины (PQC)
Каждый подписант использует стандартный формат v3:
- Знаковые данные с префиксом длины:
- Последовательность дайджестов с префиксом длины:
- Идентификатор алгоритма подписи (4 байта)
- дайджест (с префиксом длины)
- Последовательность сертификатов с префиксом длины:
- Сертификат X.509 с префиксом длины (форма ASN.1 DER)
- minSDK (uint32)
- maxSDK (uint32)
- Последовательность дополнительных атрибутов с префиксом длины:
- ID (uint32)
- значение (переменная длина: длина дополнительного атрибута - 4 байта)
- minSDK (uint32)
- maxSDK (uint32)
- Последовательность подписей, каждая из которых начинается с префикса длины:
- Идентификатор алгоритма подписи (4 байта)
- подпись с префиксом длины над подписанными данными
- Открытый ключ с префиксом длины (
SubjectPublicKeyInfo, формат ASN.1 DER)
Проверка
В Android 17 (уровень API 37) и выше для проверки подписи версии 3.2 платформа проверяет как классический, так и PQC-подписывающий механизм, подтверждает их совместимость и проверяет неявную цепочку ротации. В Android 16 (уровень API 36) и более ранних версиях платформа не обрабатывает этот гибридный блок подписи и использует вместо него предыдущие схемы.
Весь процесс выглядит следующим образом:
- Найдите блок схемы подписи APK версии 3.2 (ID 0x70e1c89f).
- Убедитесь, что блок содержит ровно двух подписантов. Если их меньше или больше двух, проверка не пройдена.
- Убедитесь, что один из подписантов использует классический алгоритм подписи, а другой — алгоритм PQC. Если оба используют классический алгоритм или оба используют алгоритм PQC, проверка не пройдена.
- Убедитесь, что оба подписывающих устройства используют один и тот же диапазон версий SDK (
minSdkVersionиmaxSdkVersion). - Для каждого из двух подписантов выполните стандартную проверку версии 3:
- Выберите из списка подписей идентификатор алгоритма подписи с наивысшей поддержкой.
- Проверьте соответствующую подпись из числа подписей на соответствие подписанным данным, используя открытый ключ.
- Убедитесь, что значения
minSdkVersionиmaxSdkVersionв подписанных данных совпадают со значениямиminSdkVersionиmaxSdkVersionв неподписанных данных. - Проанализируйте сертификаты и убедитесь, что первый сертификат соответствует открытому ключу.
- Для извлечения структур подтверждения вращения необходимо проанализировать дополнительные атрибуты.
- Проверьте историю подписания контрактов (подтверждение ротации):
- Убедитесь, что у обоих подписантов одинаковая история предыдущих подписаний.
- Длина родословной должна совпадать, и все сертификаты и флаги возможностей, ведущие к текущим подписантам, должны быть идентичными.
- Если истории совпадают, объедините родословные: рассматривайте сертификат классического подписанта как предшественника сертификата подписанта PQC, назначив подписанта PQC текущим конечным узлом.
- Проверка дайджестов контента:
- Пройдите по карте дайджестов для обоих подписантов.
- Убедитесь, что для всех совпадающих алгоритмов дайджеста вычисленные значения дайджеста идентичны как для классического, так и для PQC-подписывающего механизма.
- Используйте совпадающие дайджесты от проверенных подписантов для проверки целостности содержимого APK (аналогично версиям v2 и v3).
- Если приложение уже установлено, проверьте историю обновлений пакета:
- Обновление с одного подписанта: если установленное приложение было подписано одним классическим ключом, этот ключ должен присутствовать в цепочке подписей нового гибридного блока в качестве предшественника гибридных подписантов.
- Обновление с гибридного подписанта для продолжения использования гибридного: Если установленное приложение было подписано гибридным блоком версии 3.2, то как предыдущий классический ключ, так и ключ PQC должны либо оставаться текущими активными подписантами в блоке версии 3.2 обновленного APK, либо оба должны присутствовать в новой цепочке подписи, подтверждающей использование новых гибридных ключей.
- Переход от гибридного подписанта: Если установленное приложение было подписано гибридным блоком версии 3.2, а обновление APK возвращается к одному подписанту (либо PQC, либо классическому), оба предыдущих гибридных подписанта должны присутствовать в цепочке подписи обновления APK и подтверждать новый единый ключ подписи.
- Недопустимые пути обновления: если разработчик попытается обновить приложение с гибридной подписью, используя только один из гибридных ключей в качестве единственного подписывающего лица без надлежащей ротации, обновление завершится неудачей. Для предотвращения атак с понижением версии необходимо явное участие обоих ключей в любом процессе обновления.
- Если какой-либо этап завершится неудачей, проверка также завершится неудачей.
Снятие защиты
Для предотвращения атак с использованием более слабых схем подписи, схема версии 3.2 включает в себя удаление атрибутов защиты, аналогичных тем, что использовались в предыдущих версиях схемы.
Инструмент подписи записывает два специфических атрибута защиты от гибридного удаления данных в дополнительные атрибуты блоков подписи версий 3.0 и 3.1. Эти атрибуты определяют точные границы версий SDK, в рамках которых должен присутствовать и проверяться гибридный блок версии 3.2:
- Атрибут минимальной версии SDK (ID
0xbf940529): значение этого атрибута определяет минимальную версию SDK, поддерживаемую блоком гибридной подписи. - Атрибут максимальной версии SDK (ID
0x9f06b79c): значение этого атрибута определяет максимальную версию SDK, поддерживаемую гибридным блоком подписи. Этот атрибут позволяет перейти к конфигурации с одним подписантом, когда более новые версии платформы не требуют гибридной подписи.
Если платформа пропускает проверку версии 3.2 из-за отсутствия блока или несоответствия диапазона SDK данному устройству, платформа проверяет APK-файл на соответствие следующему присутствующему блоку. Если этот более ранний блок содержит атрибуты защиты от удаления данных, платформа применяет следующие проверки:
- Проверка наличия и диапазона: Если блок подписи версии 3.0 или 3.1 содержит либо атрибут минимального SDK (ID
0xbf940529, значение X ), либо атрибут максимального SDK (ID0x9f06b79c, значение Y ), платформа требует наличия гибридного блока версии 3.2 в APK-файле. Платформа считывает гибридный блок, чтобы проверить, соответствует ли целевой диапазон SDK границам, указанным в этих атрибутах. Если блок версии 3.2 отсутствует или если его внутренние целевые значения минимального и максимального SDK не равны X и Y , платформа отклоняет установку. - Проверка в пределах допустимого диапазона: Если версия SDK устройства находится в допустимом диапазоне, указанном этими атрибутами (который больше или равен X , и меньше или равен Y, если указан максимальный атрибут), платформа строго требует наличия гибридного блока v3.2 для проверки подписи. Если платформа проверяет блок v3.0 или v3.1 на устройстве в пределах этого целевого диапазона SDK, платформа отклоняет установку, поскольку блок v3.2 был злонамеренно обойден или удален.
Устанавливая эти ограничения, платформа определяет, когда APK-файл должен содержать блок версии 3.2. Если блок удален, платформа отклоняет установку, чтобы предотвратить атаку с понижением версии.
Проверьте правильность вашей реализации.
Для проверки вашей реализации схемы подписи версии 3.2 запустите тесты CTS HybridSignatureVerificationTest.java , расположенные в cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .
Эти тесты охватывают полный набор сценариев, включая успешную установку, обновления с версий, использующих только классический подход, откат с использованием функции ROLLBACK , а также проверку мер по смягчению последствий атаки с удалением данных.