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 і використовує відкритий ключ 0x54A5…FF. Далі при отриманні повідомлення, підписаного тим же ключем, отримувати може використовувати підписаний токен провайдером для верифікації того, що ключ bob@gmail.com - 0x54A5 ... FF і повідомлення дійсно підписав bob@gmail.com.
Спрощення архітектури реалізовано рахунок певних компромісів (наприклад, залежність від зовнішніх провайдерів OpenID і відсутність лога змін з ієрархічним хешированием), які у якихось ситуаціях допустимі, а якихось ні. Для зниження залежності від провайдерів OpenID, компрометація або дії персоналу яких можуть дискредитувати систему (наприклад, зламали провайдера можуть видати фіктивний ключ третій особі) пропонується використовувати додаткову, але не обов'язкову, ланку MFA-Cosigner (Multi-Factor Authentication Cosigner) для багатофакторної аутентифікації незалежним сервісом аутентифікації, який підтверджує користувача).
Зі слабких сторін OpenPubKey також відзначається наявність у сторонніх відомостей, які можна використовувати для відстеження активності протягом тривалого часу та незалежно від перейменувань (повторне застосування ідентифікуючого токена замість нового сертифіката). Пряма прив'язка до ключів OpenID Connect при верифікації виключає серверну частину, але значно ускладнює реалізацію на стороні клієнта та залишає більше простору для маневру під час атак (attack surface) на клієнта, наприклад, через те, що на клієнта лягатиме завдання ротації ключів. Відсутність лога змін не дозволяє клієнту відстежувати можливі витоку ключів.
Джерело: opennet.ru
