Представлен OpenPubKey, протокол криптографической верификации объектов
Linux Foundation, BastionZero и Docker представили новый открытый проект OpenPubKey, развивающий одноимённый криптографический протокол для заверения цифровой подписью произвольных объектов. Технология разработана как совместный проект компаний BastionZero и Docker с целью упрощения заверения цифровыми подписями образов контейнеров Docker для исключения их подмены и подтверждения сборки заявленным создателем. Проект будет развиваться на нейтральной площадке под покровительством организации Linux Foundation, что исключит зависимость от отдельных коммерческих компаний и упростит совместную работу с привлечением сторонних участников. Эталонная реализация OpenPubKey написана на языке Go и распространяется под лицензией Apache 2.0.
Возможности OpenPubKey не ограничиваются только образами контейнеров и технология может применяться для подтверждения источника получения любого ресурса, предотвращения подмены зависимостей и повышения безопасности каналов распространения наборов данных. Например, технология применима для заверения сборок программ, отдельных сообщений и коммитов. Создателям подписи достаточно наличия учётной записи в сервисе, поддерживающем OpenID, а потребителям предоставляется возможность проверки прикреплённых подписей и подтверждения их связи с заявленным идентификатором OpenID.
По своему назначению OpenPubKey напоминает созданную в Google и ранее переданную в Linux Foundation систему Sigstore, но отличается от неё существенным упрощением внедрения, использования и сопровождения за счёт избавления от централизованных серверных компонентов, отвечающих за ведение публичного лога, подтверждающего подлинность изменений (transparency log), и обеспечение работы удостоверяющих центров (Certificate Authority).
Вместо развёртывания собственных удостоверяющих центров в OpenPubKey применяется аутентификация с использованием технологии OpenID и привязка созданных подписей к существующим провайдерам OpenID Connect. Иными словами, OpenPubkey позволяет привязать криптографические ключи к конкретным пользователям, используя провайдеры OpenID Connect (IdP) вместо удостоверяющих центров. Технология полностью совместима с существующими провайдерами OpenID, такими как GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak и Google, и не требует внесения изменений на их стороне (используется предоставляемый провайдером типовой ID Token, что позволяет реализовать OpenPubKey только через изменения на стороне клиента OpenID Connect).
Выданный провайдером OpenID токен трансформируется в сертификат, который криптографически привязывает идентификатор в OpenID Connect к отрытому ключу. Далее пользователь использует сгенерированный ключ для подписи любых данных и эти подписи могут в дальнейшем быть проверены на связь с идентификатором в OpenID Connect. В OpenPubKey применяются эфемерные ключи, время жизни которых ограничено — ключи генерируются во время входа при помощи OpenID и удаляются в время завершения сеанса с провайдером OpenID.
Примерный алгоритм создания подписи с использованием OpenPubKey:
- Вход с использованием провайдера OpenID (Google, GitHub, Microsoft и т.п.).
- Запрос идентификационного токена у провайдера OpenID.
Возврат токена, подписанного ключом провайдера и включающего поле «nonce» с произвольными данными, переданными при запросе (передаётся SHA3-хэш от открытого ключа).
Использование на стороне пользователя полученного токена как сертификата, включающего данные о ключе.
Прикрепление токена к подписи, по аналогии с сертификатом.
Верификация сводится к проверке, подписан ли прикреплённый токен провайдером OpenID, и проверке корректности цифровой подписи к ресурсу по открытому ключу, что позволяет удостовериться, что ресурс подписан с использованием идентификатора из сертификата и это подтверждено подписью провайдера OpenID. Например, создающий подпись может получить подписанный OpenID-провайдером Google токен с информацией, что он верифицирован как bob@gmail.com и использует открытый ключ 0×54A5…FF. Далее при получении сообщения, подписанного тем же ключом, получать может использовать подписанный провайдером токен для верификации того, что ключ bob@gmail.com — 0×54A5…FF и сообщение действительно подписал bob@gmail.com.
Упрощение архитектуры реализовано за счёт определённых компромиссов (например, зависимость от внешних провайдеров OpenID и отсутствие лога изменений с иерархическим хешированием), которые в каких-то ситуациях допустимы, а в каких-то нет. Для снижения зависимости от провайдеров OpenID, компрометация или действия персонала которых могут дискредитировать систему (например, взломавшие провайдера могут выдать фиктивный ключ третьему лицу) предлагается использовать дополнительное, но не обязательное, звено MFA-Cosigner (Multi-Factor Authentication Cosigner) для многофакторной аутентификации (токен должен быть подписан не только основным провайдером, но и независимым сервисом аутентификации, подтверждающим пользователя).
Из слабых сторон OpenPubKey также отмечается наличие у посторонних сведений, которые можно использовать для отслеживания активности в течение длительного времени и независимо от переименований (повторное применение идентифицирующего токена вместо нового сертификата). Прямая привязка к ключам OpenID Connect при верификации исключает серверную часть, но значительно усложняет реализацию на стороне клиента и оставляет больше пространства для манёвра при совершении атак (attack surface) на клиента, например, из-за того, что на клиента ложиться задача ротации ключей. Отсутствие лога изменений не позволяет клиенту отслеживать возможные утечки ключей.
Источник: http://www.opennet.ru/opennews/art.shtml? num=59888
© OpenNet
