Чтобы повысить доверие к приложениям и продуктам Google, мы обязуемся публиковать информацию о каждом пакете продуктов Google в нашем журнале прозрачности. Мы опубликовали журнал прозрачности , чтобы публично подтвердить заявления, которые мы делаем в отношении этих пакетов (APK и APEX).
Модель угроз
Системы прозрачности могут использоваться для обнаружения и, следовательно, предотвращения атак на цепочки поставок. Проиллюстрируем это несколькими примерами.
Предположим, злоумышленник вносит вредоносные изменения в приложение или продукт Google и даже умудряется подписать его ключом подписи, используемым для распространения через Google Play. С помощью журнала бинарной прозрачности любой, кто получит сомнительный пакет (APK или APEX), сможет использовать его в качестве дополнительного проверяемого источника достоверной информации для подтверждения подлинности пакета. Он обнаружит, что Google не добавил соответствующие метаданные пакета в журнал, и поймет, что скомпрометированному пакету нельзя доверять.
Поскольку публикация в журнале — это отдельный процесс от процесса выпуска с подписыванием (как показано на диаграмме экосистемы ), это повышает планку для злоумышленника, выходя за рамки простого взлома ключа.
Хотя мы планируем также интегрировать этот журнал в общедоступную сеть свидетелей, используя стандартный протокол свидетелей , мы призываем внешние независимые стороны контролировать целостность этого общедоступного журнала. Эти стороны могут подтвердить свойство журнала «только добавление» и сообщить о любых попытках его изменения.
Наличие такой системы прозрачности и дополнительная возможность обнаружения атак препятствуют вредоносной деятельности. Если пакет скомпрометирован, но пользователи доверяют только тем данным, которые содержатся в журнале, скомпрометированный пакет необходимо будет публично раскрыть. Это повышает вероятность обнаружения существования скомпрометированного пакета и принятия мер по его удалению.
Модель заявителя
Модель заявителя — это структура, используемая для определения ролей и артефактов в проверяемой системе. В случае с Google Product Application Transparency мы заявляем, что хеш файла пакета, записанный в этом журнале, представляет собой конкретную версию официального продукта Google, предназначенного для публичного использования.
- Утверждаю, что GoogleApp : (Я, Google, утверждаю, что
$hashAppпредназначен для$googleApp), где:-
$hashApp— это криптографический хеш (например, SHA256) файла пакета (включая разделенные APK-файлы и пакеты APEX ) определенной версии$googleApp. -
$googleApp— это пакет Android ( APK или APEX ), из которого состоит приложение или продукт, созданный и распространяемый компанией Google.
-
Любой, у кого есть копия $googleApp может проверить это утверждение, и мы подробно описываем этот процесс на странице проверки .
Содержимое журнала
Когда Google выпускает новую версию APK-файла или APEX-пакета, она добавляет соответствующую запись в журнал прозрачности продуктов Google .
Каждая запись в этом журнале содержит четыре элемента метаданных:
- Хэш APK- файла или APEX- файла пакета, подписанного Google. Это шестнадцатеричная строка дайджеста SHA256 всего файла.
- Описание типа предыдущего хеша. Это строка.
- Название пакета. Это строка.
- Номер версии ( versionCode ) пакета. Это ненулевое целое число.
Формат записи в журнале представляет собой объединение четырех элементов информации символом новой строки ( \n ), как показано ниже:
hash\nhash_description\npackage_name\npackage_version\n
Поскольку продукт Google может распространяться в виде APK-файла или APEX-файла, хеш-описание устанавливается либо на SHA256(APK) , либо SHA256(APEX) . Это обеспечивает полное покрытие содержимого каждого файла и упрощает пользователям получение этого показателя.
Диаграмма экосистемы

Чтобы повысить доверие к приложениям и продуктам Google, мы обязуемся публиковать информацию о каждом пакете продуктов Google в нашем журнале прозрачности. Мы опубликовали журнал прозрачности , чтобы публично подтвердить заявления, которые мы делаем в отношении этих пакетов (APK и APEX).
Модель угроз
Системы прозрачности могут использоваться для обнаружения и, следовательно, предотвращения атак на цепочки поставок. Проиллюстрируем это несколькими примерами.
Предположим, злоумышленник вносит вредоносные изменения в приложение или продукт Google и даже умудряется подписать его ключом подписи, используемым для распространения через Google Play. С помощью журнала бинарной прозрачности любой, кто получит сомнительный пакет (APK или APEX), сможет использовать его в качестве дополнительного проверяемого источника достоверной информации для подтверждения подлинности пакета. Он обнаружит, что Google не добавил соответствующие метаданные пакета в журнал, и поймет, что скомпрометированному пакету нельзя доверять.
Поскольку публикация в журнале — это отдельный процесс от процесса выпуска с подписыванием (как показано на диаграмме экосистемы ), это повышает планку для злоумышленника, выходя за рамки простого взлома ключа.
Хотя мы планируем также интегрировать этот журнал в общедоступную сеть свидетелей, используя стандартный протокол свидетелей , мы призываем внешние независимые стороны контролировать целостность этого общедоступного журнала. Эти стороны могут подтвердить свойство журнала «только добавление» и сообщить о любых попытках его изменения.
Наличие такой системы прозрачности и дополнительная возможность обнаружения атак препятствуют вредоносной деятельности. Если пакет скомпрометирован, но пользователи доверяют только тем данным, которые содержатся в журнале, скомпрометированный пакет необходимо будет публично раскрыть. Это повышает вероятность обнаружения существования скомпрометированного пакета и принятия мер по его удалению.
Модель заявителя
Модель заявителя — это структура, используемая для определения ролей и артефактов в проверяемой системе. В случае с Google Product Application Transparency мы заявляем, что хеш файла пакета, записанный в этом журнале, представляет собой конкретную версию официального продукта Google, предназначенного для публичного использования.
- Утверждаю, что GoogleApp : (Я, Google, утверждаю, что
$hashAppпредназначен для$googleApp), где:-
$hashAppis a cryptographic hash (eg SHA256) of the package file (including split APKs and APEX packages ) of a specific version of$googleApp. -
$googleApp— это пакет Android ( APK или APEX ), из которого состоит приложение или продукт, созданный и распространяемый компанией Google.
-
Любой, у кого есть копия $googleApp может проверить это утверждение, и мы подробно описываем этот процесс на странице проверки .
Содержимое журнала
Когда Google выпускает новую версию APK-файла или APEX-пакета, она добавляет соответствующую запись в журнал прозрачности продуктов Google .
Каждая запись в этом журнале содержит четыре элемента метаданных:
- Хэш APK- файла или APEX- файла пакета, подписанного Google. Это шестнадцатеричная строка дайджеста SHA256 всего файла.
- Описание типа предыдущего хеша. Это строка.
- Название пакета. Это строка.
- Номер версии ( versionCode ) пакета. Это ненулевое целое число.
Формат записи в журнале представляет собой объединение четырех элементов информации символом новой строки ( \n ), как показано ниже:
hash\nhash_description\npackage_name\npackage_version\n
Поскольку продукт Google может распространяться в виде APK-файла или APEX-файла, хеш-описание устанавливается либо на SHA256(APK) , либо SHA256(APEX) . Это обеспечивает полное покрытие содержимого каждого файла и упрощает пользователям получение этого показателя.
Диаграмма экосистемы

Чтобы повысить доверие к приложениям и продуктам Google, мы обязуемся публиковать информацию о каждом пакете продуктов Google в нашем журнале прозрачности. Мы опубликовали журнал прозрачности , чтобы публично подтвердить заявления, которые мы делаем в отношении этих пакетов (APK и APEX).
Модель угроз
Системы прозрачности могут использоваться для обнаружения и, следовательно, предотвращения атак на цепочки поставок. Проиллюстрируем это несколькими примерами.
Предположим, злоумышленник вносит вредоносные изменения в приложение или продукт Google и даже умудряется подписать его ключом подписи, используемым для распространения через Google Play. С помощью журнала бинарной прозрачности любой, кто получит сомнительный пакет (APK или APEX), сможет использовать его в качестве дополнительного проверяемого источника достоверной информации для подтверждения подлинности пакета. Он обнаружит, что Google не добавил соответствующие метаданные пакета в журнал, и поймет, что скомпрометированному пакету нельзя доверять.
Поскольку публикация в журнале — это отдельный процесс от процесса выпуска с подписыванием (как показано на диаграмме экосистемы ), это повышает планку для злоумышленника, выходя за рамки простого взлома ключа.
Хотя мы планируем также интегрировать этот журнал в общедоступную сеть свидетелей, используя стандартный протокол свидетелей , мы призываем внешние независимые стороны контролировать целостность этого общедоступного журнала. Эти стороны могут подтвердить свойство журнала «только добавление» и сообщить о любых попытках его изменения.
Наличие такой системы прозрачности и дополнительная возможность обнаружения атак препятствуют вредоносной деятельности. Если пакет скомпрометирован, но пользователи доверяют только тем данным, которые содержатся в журнале, скомпрометированный пакет необходимо будет публично раскрыть. Это повышает вероятность обнаружения существования скомпрометированного пакета и принятия мер по его удалению.
Модель заявителя
Модель заявителя — это структура, используемая для определения ролей и артефактов в проверяемой системе. В случае с Google Product Application Transparency мы заявляем, что хеш файла пакета, записанный в этом журнале, представляет собой конкретную версию официального продукта Google, предназначенного для публичного использования.
- Утверждаю, что GoogleApp : (Я, Google, утверждаю, что
$hashAppпредназначен для$googleApp), где:-
$hashApp— это криптографический хеш (например, SHA256) файла пакета (включая разделенные APK-файлы и пакеты APEX ) определенной версии$googleApp. -
$googleApp— это пакет Android ( APK или APEX ), из которого состоит приложение или продукт, созданный и распространяемый компанией Google.
-
Любой, у кого есть копия $googleApp может проверить это утверждение, и мы подробно описываем этот процесс на странице проверки .
Содержимое журнала
Когда Google выпускает новую версию APK-файла или APEX-пакета, она добавляет соответствующую запись в журнал прозрачности продуктов Google .
Каждая запись в этом журнале содержит четыре элемента метаданных:
- Хэш APK- файла или APEX- файла пакета, подписанного Google. Это шестнадцатеричная строка дайджеста SHA256 всего файла.
- Описание типа предыдущего хеша. Это строка.
- Название пакета. Это строка.
- Номер версии ( versionCode ) пакета. Это ненулевое целое число.
Формат записи в журнале представляет собой объединение четырех элементов информации символом новой строки ( \n ), как показано ниже:
hash\nhash_description\npackage_name\npackage_version\n
Поскольку продукт Google может распространяться в виде APK-файла или APEX-файла, хеш-описание устанавливается либо на SHA256(APK) , либо SHA256(APEX) . Это обеспечивает полное покрытие содержимого каждого файла и упрощает пользователям получение этого показателя.
Диаграмма экосистемы

Чтобы повысить доверие к приложениям и продуктам Google, мы обязуемся публиковать информацию о каждом пакете продуктов Google в нашем журнале прозрачности. Мы опубликовали журнал прозрачности , чтобы публично подтвердить заявления, которые мы делаем в отношении этих пакетов (APK и APEX).
Модель угроз
Системы прозрачности могут использоваться для обнаружения и, следовательно, предотвращения атак на цепочки поставок. Проиллюстрируем это несколькими примерами.
Предположим, злоумышленник вносит вредоносные изменения в приложение или продукт Google и даже умудряется подписать его ключом подписи, используемым для распространения через Google Play. С помощью журнала бинарной прозрачности любой, кто получит сомнительный пакет (APK или APEX), сможет использовать его в качестве дополнительного проверяемого источника достоверной информации для подтверждения подлинности пакета. Он обнаружит, что Google не добавил соответствующие метаданные пакета в журнал, и поймет, что скомпрометированному пакету нельзя доверять.
Поскольку публикация в журнале — это отдельный процесс от процесса выпуска с подписыванием (как показано на диаграмме экосистемы ), это повышает планку для злоумышленника, выходя за рамки простого взлома ключа.
Хотя мы планируем также интегрировать этот журнал в общедоступную сеть свидетелей, используя стандартный протокол свидетелей , мы призываем внешние независимые стороны контролировать целостность этого общедоступного журнала. Эти стороны могут подтвердить свойство журнала «только добавление» и сообщить о любых попытках его изменения.
Наличие такой системы прозрачности и дополнительная возможность обнаружения атак препятствуют вредоносной деятельности. Если пакет скомпрометирован, но пользователи доверяют только тем данным, которые содержатся в журнале, скомпрометированный пакет необходимо будет публично раскрыть. Это повышает вероятность обнаружения существования скомпрометированного пакета и принятия мер по его удалению.
Модель заявителя
Модель заявителя — это структура, используемая для определения ролей и артефактов в проверяемой системе. В случае с Google Product Application Transparency мы заявляем, что хеш файла пакета, записанный в этом журнале, представляет собой конкретную версию официального продукта Google, предназначенного для публичного использования.
- Утверждаю, что GoogleApp : (Я, Google, утверждаю, что
$hashAppпредназначен для$googleApp), где:-
$hashApp— это криптографический хеш (например, SHA256) файла пакета (включая разделенные APK-файлы и пакеты APEX ) определенной версии$googleApp. -
$googleApp— это пакет Android ( APK или APEX ), из которого состоит приложение или продукт, созданный и распространяемый компанией Google.
-
Любой, у кого есть копия $googleApp может проверить это утверждение, и мы подробно описываем этот процесс на странице проверки .
Содержимое журнала
Когда Google выпускает новую версию APK-файла или APEX-пакета, она добавляет соответствующую запись в журнал прозрачности продуктов Google .
Каждая запись в этом журнале содержит четыре элемента метаданных:
- Хэш APK- файла или APEX- файла пакета, подписанного Google. Это шестнадцатеричная строка дайджеста SHA256 всего файла.
- Описание типа предыдущего хеша. Это строка.
- Название пакета. Это строка.
- Номер версии ( versionCode ) пакета. Это ненулевое целое число.
Формат записи в журнале представляет собой объединение четырех элементов информации символом новой строки ( \n ), как показано ниже:
hash\nhash_description\npackage_name\npackage_version\n
Поскольку продукт Google может распространяться в виде APK-файла или APEX-файла, хеш-описание устанавливается либо на SHA256(APK) , либо SHA256(APEX) . Это обеспечивает полное покрытие содержимого каждого файла и упрощает пользователям получение этого показателя.
Диаграмма экосистемы
