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

Фондация Linux, BastionZero и Docker представиха нов проект с отворен код, OpenPubKey, който разработва криптографския протокол със същото име за цифрово подписване на произволни обекти. Технологията е разработена като съвместен проект между BastionZero и Docker, за да се опрости цифровото подписване на изображения на контейнери на Docker, предотвратявайки неправилно редактиране и потвърждавайки, че компилацията е създадена от оригиналния създател. Проектът ще бъде разработен на неутрална платформа под егидата на Фондация Linux, елиминирайки зависимостта от отделни търговски компании и улеснявайки сътрудничеството с трети страни. Референтната имплементация на OpenPubKey е написана на Go и е лицензирана под лиценза Apache 2.0.

Възможностите на OpenPubKey не се ограничават до изображения на контейнери; технологията може да се използва за проверка на източника на всеки ресурс, предотвратяване на подправяне на зависимости и подобряване на сигурността на каналите за разпространение на данни. Например, технологията може да се използва за проверка на софтуерни компилации, отделни съобщения и коммити. Създателите на подписи се нуждаят само от акаунт в услуга, активирана за OpenID, докато потребителите могат да проверяват прикачените подписи и да потвърждават връзката си с декларирания OpenID идентификатор.

По своето предназначение OpenPubKey е подобна на системата Sigstore, създадена от Google и преди това прехвърлена на Linux Foundation, но се различава от нея по това, че значително опростява внедряването, използването и поддръжката, като елиминира централизираните сървърни компоненти, отговорни за поддържането на публичен дневник, потвърждаващ автентичността на промените (дневник на прозрачността), и осигуряващ работата на сертифициращите органи (Certificate Authority).

Вместо да внедрява персонализирани CA, OpenPubKey използва OpenID удостоверяване и обвързва генерираните подписи със съществуващи OpenID Connect доставчици. С други думи, OpenPubKey ви позволява да обвързвате криптографски ключове с конкретни потребители, използвайки OpenID Connect доставчици (IdP) вместо CA. Технологията е напълно съвместима със съществуващи 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 и др.).
• Заявете ID токен от доставчик на OpenID.
• Връща токен, подписан с ключа на доставчика и включващ поле "nonce" с произволни данни, предадени по време на заявката (предава се SHA3 хешът на публичния ключ).
• Използване на получения токен от страна на потребителя като сертификат, който включва ключова информация.
• Прикачване на токен към подпис, подобно на сертификат.

Проверката включва проверка дали прикаченият токен е подписан от доставчика на OpenID и проверка на валидността на цифровия подпис върху ресурса, използвайки публичния ключ. Това проверява дали ресурсът е подписан с помощта на идентификатора от сертификата и дали това е потвърдено от подписа на доставчика на OpenID. Например, подписващ може да получи токен, подписан от доставчика на Google OpenID, показващ, че е проверен като bob@gmail.com и използва публичния ключ 0x54A5...FF. След това, когато получи съобщение, подписано със същия ключ, получателят може да използва подписания от доставчика токен, за да провери дали ключът на bob@gmail.com е 0x54A5...FF и че съобщението наистина е подписано от bob@gmail.com.

Опростяването на архитектурата се постига чрез определени компромиси (като зависимост от външни доставчици на OpenID и липсата на дневник на промените с йерархично хеширане), които са приемливи в някои ситуации, а в други не. За да се намали зависимостта от доставчици на OpenID, чието компрометиране или действия от страна на техния персонал биха могли да дискредитират системата (например, ако хакер компрометира доставчик, той може да издаде фалшив ключ на трета страна), се предлага използването на допълнителен, но опционален, MFA-Cosigner (Multi-Factor Authentication Cosigner) за многофакторно удостоверяване (токенът трябва да бъде подписан не само от основния доставчик, но и от независима услуга за удостоверяване, която проверява потребителя).

Друга слабост на OpenPubKey е наличието на данни от трети страни, които могат да се използват за проследяване на активността за дълги периоди от време, независимо от преименуването (повторно използване на идентификационен токен вместо нов сертификат). Директното обвързване с ключове на OpenID Connect по време на проверка елиминира необходимостта от сървърна имплементация, но значително усложнява клиентската имплементация и оставя повече място за маневриране при атака срещу клиента, например, защото клиентът е отговорен за ротацията на ключовете. Липсата на дневник на промените пречи на клиента да открие потенциални течове на ключове.

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