Linux Foundation, BastionZero и Docker представиха новия отворен проект OpenPubKey, който развива едноименния криптографски протокол за заверка на цифрови подписи на произволни обекти. Технологията е разработена като съвместен проект на компаниите BastionZero и Docker с цел опростяване на заверката на цифрови подписи на Docker образи, за да се избегне тяхната подмяна и да се потвърди сборката от обявения създател. Проектът ще се развива на неутрална платформа под покровителството на организацията Linux Foundation, което ще избегне зависимостта от отделни търговски компании и ще опрости съвместната работа с привлечени трети участници. Еталонната реализация на OpenPubKey е написана на езика Go и се разпространява под лицензия Apache 2.0.
Възможностите на OpenPubKey не се ограничават само до образи на контейнери и технологията може да се прилага за потвърждаване на източника на всякакъв ресурс, предотвратяване на подмяна на зависимости и повишаване на сигурността на каналите за разпространение на набори от данни. Например, технологията е приложима за заверка на сборки на програми, отделни съобщения и комити. На създателите на подписите им е необходимо само да имат акаунт в услуга, поддържаща OpenID, а потребителите получават възможност да проверяват прикачените подписи и да потвърдят тяхната свързаност с обявения идентификатор OpenID.
По своето предназначение OpenPubKey наподобява системата Sigstore, разработена в Google и по-рано предадена на Linux Foundation, но се различава от нея с възможността за значително опростяване на внедряването, използването и поддръжката чрез освобождаването от централизирани сървърни компоненти, отговорни за воденето на публичен регистър, удостоверяващ автентичността на промените (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 и използва публичен ключ 0x54A5…FF. По-късно, при получаване на съобщение, подписано със същия ключ, получателят може да използва подписания токен на доставчика, за да верифицира, че ключът bob@gmail.com — 0x54A5…FF и съобщението наистина е подписано от bob@gmail.com.
Опрощаването на архитектурата е осъществено чрез определени компромиси (например, зависимост от външни доставчици на OpenID и липса на лог на промените с йерархично хеширане), които в някои ситуации са допустими, а в други — не. За да се намали зависимостта от доставчиците на OpenID, компрометирането или действията на персони, които могат да дискредитират системата (например, хакер на доставчика може да издаде фалшив ключ на трето лице), се предлага използването на допълнителен, но не задължителен елемент MFA-Cosigner (многофакторна удостоверителна информация) за многофакторна аутентификация (токенът трябва да бъде подписан не само от основния доставчик, но и от независим удостоверителен сервиз, потвърдител на потребителя).
От слабите страни на OpenPubKey се отбелязва също наличието на външна информация, която може да бъде използвана за проследяване на активността за дълъг период от време и независимо от преименуваня (повторното използване на идентифициращ токен вместо нов сертификат). Пряката зависимост от ключовете на OpenID Connect при верификацията изключва сървърната част, но значително усложнява реализацията от страна на клиента и оставя повече пространство за маневри за атаки (attack surface) на клиента, например, защото на клиента се налага да извършва ротация на ключовете. Липсата на лог на промените не позволява на клиента да проследява възможни изтичания на ключове.
Източник: opennet.ru
