Google 致力于为黑人社区推动种族平等。查看具体举措
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

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

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

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

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

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

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

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

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

Формат

Блок схемы подписи APK v3 хранится внутри блока 0xf05368c0 APK под идентификатором 0xf05368c0 .

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

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

Структуры доказательства ротации и самонадежных старых сертификатов

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

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

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

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

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

Формат

Доказательство ротации хранится в блоке схемы подписи APK v3 под идентификатором 0x3ba06f8c . Его формат:

  • последовательность levels префиксом длины:
    • signed data префиксом длины (предыдущим сертификатом - если существует)
      • certificate X.509 с префиксом длины (форма ASN.1 DER)
      • signature algorithm ID (uint32) - алгоритм, используемый сертификатом на предыдущем уровне
    • flags (uint32) - флаги, указывающие, должен ли этот сертификат быть в структуре self-trust-old-certs, и для каких операций.
    • signature algorithm ID (uint32) - должен совпадать с signature algorithm ID из раздела подписанных данных на следующем уровне.
    • signature префиксом длины поверх указанных выше signed data

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

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

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

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

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

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

Проверка

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

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

Рисунок 1. Процесс проверки подписи APK

Проверка схемы подписи 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 из 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 PkgInstallSignatureVerificationTest.java в cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .