Схема подписи APK v3

Android 9 поддерживает APK ключевого поворота , который дает приложению появится возможность изменить свой ключ подписи , как часть обновления APK. Чтобы ротация была практичной, APK-файлы должны указывать уровни доверия между новым и старым ключами подписи. Для поддержки поворота ключа, мы обновили схему подписи APK с v2 на v3 , чтобы новые и старые ключи , которые будут использоваться. V3 добавляет информацию о поддерживаемых версиях SDK и структуру доказательства ротации в блок подписи APK.

Блокировка подписи APK

Для обеспечения обратной совместимости с форматом APK v1, подписи APK v2 и v3 хранятся в блоке подписи APK, расположенном непосредственно перед центральным каталогом ZIP.

V3 АПК подпись формата блок является таким же , как v2 . Подпись v3 APK хранится как пара ID-значение с ID 0xf05368c0.

Схема подписи APK v3 Block

Схема v3 предназначена быть очень похожа на схему v2 . Она имеет тот же общий формат и поддерживает те же идентификаторы подписи алгоритма , основные размеры и кривые ЕС.

Однако схема v3 добавляет информацию о поддерживаемых версиях SDK и структуре доказательства ротации.

Формат

Подпись АПК Схема v3 Блок хранится внутри APK подписывающегося блока под ID 0xf05368c0 .

Формат схемы подписи APK v3 Block соответствует формату v2:

  • длина префикса последовательность длиной префикса signer :
    • длина префикса signed data :
      • длина префикса последовательность длиной префикса digests :
        • signature algorithm ID (4 байта)
        • digest (длина префикса)
      • длина префикса последовательность X.509 certificates :
        • Длина префикса Х.509 certificate (ASN.1 форма МЭД)
      • minSDK (uint32) - это подписавшийся должен быть проигнорирован , если платформа версии ниже этого числа.
      • maxSDK (uint32) - это подписавшийся должен быть проигнорирован , если платформа версии выше этого числа.
      • длина префикса последовательность длины префикса additional attributes :
        • ID (uint32)
        • value (переменная длина: длина дополнительного атрибута - 4 байта)
        • ID - 0x3ba06f8c
        • value - Доказательство-оф-вращения STRUCT
    • minSDK (uint32) - дубликат значения minSDK в подписанных секциях данных - используется для пропуска проверки этой подписи , если текущая платформа не находится в диапазоне. Должно соответствовать значению подписанных данных.
    • maxSDK (uint32) - дубликат значения maxSDK в разделе подписанных данных - используется для пропуска проверки этой подписи , если текущая платформа не находится в диапазоне. Должно соответствовать значению подписанных данных.
    • длина префикса последовательность длиной префикса signatures :
      • signature algorithm ID (uint32)
      • Длина префикса signature над signed data
    • Длина префикса public key (SubjectPublicKeyInfo, ASN.1 DER - форма)

Структуры подтверждения ротации и самонадежных старых сертификатов

Структура подтверждения ротации позволяет приложениям чередовать свои сертификаты подписи, не блокируя их в других приложениях, с которыми они взаимодействуют. Для этого подписи приложений содержат два новых фрагмента данных:

  • утверждение для третьих лиц, что сертификату подписи приложения можно доверять везде, где доверяют его предшественникам
  • старые сертификаты подписи приложения, которым само приложение все еще доверяет

Атрибут доказательства вращения в разделе подписанных данных состоит из односвязного списка, каждый узел которого содержит сертификат подписи, используемый для подписи предыдущих версий приложения. Этот атрибут предназначен для содержания структур данных концептуального доказательства вращения и самонадежных-старых сертификатов. Список упорядочен по версии, причем самый старый сертификат подписи соответствует корневому узлу. Структура данных доказательства ротации создается за счет того, что сертификат в каждом узле подписывает следующий в списке, и, таким образом, наполняет каждый новый ключ свидетельством того, что он должен быть таким же надежным, как и старый ключ (ключи).

Структура данных самонадежных-старых сертификатов создается путем добавления флагов к каждому узлу, указывающих его членство и свойства в наборе. Например, может присутствовать флаг, указывающий, что сертификат подписи на данном узле является доверенным для получения разрешений подписи Android. Этот флаг позволяет другим приложениям, подписанным старым сертификатом, по-прежнему предоставлять разрешение на подпись, определенное приложением, подписанным с новым сертификатом подписи. Поскольку весь атрибут пребывает корректуры из-вращения в секции подписанных данных v3 signer поля, она защищена ключом , используемым для подписания содержащего APK.

Этот формат не позволяет несколько ключей подписи и конвергенции различных сертификатов предок подписи к одному (нескольких исходных узлам к общей раковине).

Формат

Вращения доказательства правильности хранятся внутри APK подписи Схема v3 блока под ID 0x3ba06f8c . Его формат:

  • длина префикса последовательность длиной префикса levels :
    • длина префикса signed data (по предыдущим CERT - если существует)
      • Длина префикса Х.509 certificate (ASN.1 форма МЭД)
      • signature algorithm ID (uint32) - алгоритм , используемый CERT в предыдущем уровне
    • flags (UInt32) - флаги , указывающие , должна ли это быть серто в структурах самоуправления доверенного-старого-CERTS, и для которых операции.
    • signature algorithm ID (uint32) - должно соответствовать одному из раздела подписанных данных в следующем уровне.
    • Длина префикса signature за выше signed data

Несколько сертификатов

В настоящее время Android рассматривает APK, подписанный несколькими сертификатами, как имеющий уникальный идентификатор подписи, отдельный от входящих в него сертификатов. Таким образом, атрибут доказательства вращения в разделе подписанных данных формирует направленный ациклический граф, который лучше рассматривать как односвязный список, в котором каждый набор подписывающих лиц для данной версии представляет один узел. Это добавляет дополнительную сложность структуре доказательства ротации (версия с несколькими подписавшими ниже). В частности, проблема становится упорядоченной. Более того, больше невозможно подписывать APK-файлы независимо, потому что структура подтверждения ротации должна иметь старые подписывающие сертификаты, подписывающие новый набор сертификатов, а не подписывать их один за другим. Например, APK, подписанный ключом A, который желает быть подписанным двумя новыми ключами B и C, не может иметь подписывающего B, просто включающего подпись A или B, потому что это другой идентификатор подписи, чем B и C. означают, что подписывающие стороны должны координировать свои действия перед созданием такой структуры.

Атрибут подтверждения ротации нескольких подписывающих сторон

  • длина префикса последовательность длиной префикса sets :
    • signed data (по предыдущему набору - если существует)
      • длина префикса последовательность certificates
        • Длина префикса Х.509 certificate (ASN.1 форма МЭД)
      • Последовательность signature algorithm IDs (UInt32) - по одному для каждого сертификата из предыдущего набора, в том же порядке.
    • flags (UInt32) - флаги , указывающие или нет этого набор должен быть сертификаты в себя доверенный-старой-CERTS структуре, и для которых операции.
    • длина префикса последовательность длиной префикса signatures :
      • signature algorithm ID (uint32) - должно соответствовать одному из раздела подписанных данных
      • Длина префикса signature за выше signed data

Несколько предков в структуре доказательства вращения

Схема v3 также не обрабатывает два разных ключа, переходящих в один и тот же ключ подписи для одного и того же приложения. Это отличается от случая приобретения, когда приобретающая компания хотела бы переместить приобретенное приложение, чтобы использовать его ключ подписи для обмена разрешениями. Приобретение рассматривается как поддерживаемый вариант использования, поскольку новое приложение будет отличаться по имени пакета и может содержать собственную структуру доказательства вращения. Неподдерживаемый случай, когда одно и то же приложение имеет два разных пути для доступа к одному и тому же сертификату, нарушает многие предположения, сделанные в дизайне ротации ключей.

Проверка

В Android 9 и более поздних версиях APK-файлы можно проверять в соответствии со схемой подписи APK v3, схемой v2 или схемой v1. Старые платформы игнорируют подписи v3 и пытаются проверить подписи v2, затем v1.

Процесс проверки подписи APK

Рисунок процесс верификации подписи 1. АПК

Проверка схемы подписи APK v3

  1. Найдите блок подписи APK и убедитесь, что:
    1. Два поля размера блока подписи APK содержат одно и то же значение.
    2. За центральным каталогом ZIP сразу следует запись ZIP End of Central Directory.
    3. ZIP Конец центрального каталога не сопровождается дополнительными данными.
  2. Найдите первый блок схемы подписи APK v3 внутри блока подписи APK. Если v3 блок присутствует, переходите к шагу 3. В противном случае, падение обратно к проверке APK с использованием схемы v2 .
  3. Для каждого signer в APK Подписи Схема v3 блок с минимальным и максимальной версией SDK , которая находится в диапазоне от текущей платформы:
    1. Выберите самую сильную поддерживаются signature algorithm ID из signatures . Порядок прочности зависит от каждой реализации / версии платформы.
    2. Проверьте соответствующую signature от signatures против signed data с использованием public key . (Теперь можно безопасно разобрать signed data .)
    3. Проверьте мин и макс SDK версии в подписанных данных соответствуют данным для signer .
    4. Убедитесь в том, что упорядоченный список идентификаторов алгоритма подписи в digests и signatures идентичны. (Это необходимо для предотвращения удаления / добавления подписи.)
    5. Вычислить дайджест содержание APK , используя тот же алгоритм , как дайджест дайджест алгоритм , используемый алгоритмом подписи.
    6. Убедитесь , что вычисленная дайджеста идентична соответствующим digest из digests .
    7. Убедитесь в том, что SubjectPublicKeyInfo первого certificate о certificates идентичен public key .
    8. Если атрибут корректуры из-вращения существует для signer убедитесь , что структура является действительной , и это signer последним сертификат в списке.
  4. Проверка успешна , если точно один signer был найден в пределах текущей платформы и шага 3 удалось для этого signer .

Проверка

Для того, чтобы проверить , что ваш поддерживает устройство v3 правильно, запустите PkgInstallSignatureVerificationTest.java тесты CTS в cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .