Представен е OpenPubKey, протокол за криптографска верификация на обекти

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 токен, което позволява реализация на OpenPubKey само чрез изменения от страна на клиента на OpenID Connect).

Издаденият от доставчика на OpenID токен се трансформира в сертификат, който криптографски свързва идентификатора в OpenID Connect с отворения ключ. След това потребителят използва генерирания ключ за подписване на всякакви данни, а тези подписи могат да бъдат проверявани по-късно за свързаност с идентификатора в OpenID Connect. В OpenPubKey се прилагат ефемерни ключове, чието време на живот е ограничено — ключовете се генерират при входа чрез OpenID и се изтриват в момента на завършване на сесията с доставчика на OpenID.

Примерен алгоритъм за създаване на подпис с помощта на OpenPubKey:

• Вход с използване на доставчик на OpenID (Google, GitHub, Microsoft и т.н.).
• Зап/request на идентификационния токен от доставчика на 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 при верификацията изключва сървърната част, но значително усложнява реализацията от страна на клиента и оставя повече пространство за маневриране при извършване на атаки (атакуваща повърхност) на клиента, например, поради факта, че на клиента лежи задачата за ротация на ключовете. Липсата на лог на промените не позволява на клиента да проследява възможни изтичания на ключове.

Източник: opennet.ru