Linux Foundation, BastionZero a Docker představily nový otevřený projekt OpenPubKey, který vyvíjí stejnojmenný kryptografický protokol pro ověření digitálními podpisy libovolných objektů. Technologie byla vyvinuta jako společný projekt společností BastionZero a Docker s cílem zjednodušit ověřování digitálních podpisů obrazů kontejnerů Docker, aby se předešlo jejich záměně a potvrdila se sestava od deklarovaného tvůrce. Projekt se bude rozvíjet na neutrální platformě pod patronací organizace Linux Foundation, což vylučuje závislost na jednotlivých komerčních společnostech a usnadňuje spolupráci s účastníky třetích stran. Referenční implementace OpenPubKey je napsaná v jazyce Go a šíří se pod licencí Apache 2.0.
Možnosti OpenPubKey se neomezují pouze na obrazy kontejnerů a technologie může být použita k potvrzení zdroje jakéhokoli zdroje, prevenci záměny závislostí a zvýšení bezpečnosti kanálů distribuce datových sad. Například technologie je použitelná k ověření sestavení programů, jednotlivých zpráv a commitů. Tvůrcům podpisu stačí mít účet v službě podporující OpenID, zatímco spotřebitelům je poskytnuta možnost ověřit připojené podpisy a potvrdit jejich vztah s deklarovaným identifikátorem OpenID.
Svým určením připomíná OpenPubKey v Googlu vytvořený a dříve předaný Linux Foundation systém Sigstore, ale liší se od něj podstatným zjednodušením implementace, použití a údržby díky odstranění centralizovaných serverových komponent, které zajišťují vedení veřejného logu potvrzujícího pravost změn (transparency log) a zajištění činnosti certifikačních autorit (Certificate Authority).
Místo nasazení vlastních certifikačních center používá OpenPubKey autentizaci pomocí technologie OpenID a přiřazení vytvořených podpisů k existujícím poskytovatelům OpenID Connect. Jinými slovy, OpenPubKey umožňuje propojení kryptografických klíčů s konkrétními uživateli pomocí poskytovatelů OpenID Connect (IdP) namísto certifikačních center. Technologie je plně kompatibilní s existujícími poskytovateli OpenID, jako jsou GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak a Google, a nevyžaduje žádné změny na jejich straně (používá se poskytovatelem dodávaný typový ID Token, což umožňuje implementaci OpenPubKey pouze prostřednictvím změn na straně klienta OpenID Connect).
Token vydaný poskytovatelem OpenID se transformuje na certifikát, který kryptograficky propojuje identifikátor v OpenID Connect s veřejným klíčem. Dále uživatel používá vygenerovaný klíč k podepisování jakýchkoli dat a tyto podpisy mohou být dále ověřeny na základě vztahu k identifikátoru v OpenID Connect. V OpenPubKey se používají efemérní klíče, jejichž životnost je omezená — klíče se generují při přihlášení pomocí OpenID a jsou odstraněny na konci relace s poskytovatelem OpenID.
Přibližný algoritmus pro vytvoření podpisu pomocí OpenPubKey:
- Přihlášení prostřednictvím poskytovatele OpenID (Google, GitHub, Microsoft atd.).
- Žádost o identifikační token od poskytovatele OpenID.
- Vrátí token podepsaný klíčem poskytovatele a zahrnující pole „nonce“ s libovolnými údaji, které byly předány při žádosti (předává se SHA3-hash od veřejného klíče).
- Použití tokenu získaného na straně uživatele jako certifikátu, který obsahuje informace o klíči.
- Připojení tokenu k podpisu, obdobně jako k certifikátu.
Verifikace se zaměřuje na kontrolu, zda je přiložený token podepsán poskytovatelem OpenID, a na ověření správnosti digitálního podpisu k prostředku podle veřejného klíče, což umožňuje ujistit se, že zdroj je podepsán pomocí identifikátoru z certifikátu a to je potvrzeno podpisem poskytovatele OpenID. Například subjekt vytvářející podpis může získat podepsaný token od poskytovatele OpenID Google s informací, že je ověřen jako bob@gmail.com a používá veřejný klíč 0x54A5…FF. Dále, při přijímání zprávy podepsané stejným klíčem, může subjekt použít podepsaný token od poskytovatele k ověření toho, že klíč bob@gmail.com — 0x54A5…FF a zprávu skutečně podepsal bob@gmail.com.
Zjednodušení architektury bylo realizováno na základě určitých kompromisů (například závislost na externích poskytovatelích OpenID a absence logu změn s hierarchickým hashováním), které jsou v některých situacích přijatelné, a v jiných ne. Pro snížení závislosti na poskytovatelích OpenID, jejichž kompromitace nebo činnosti personálu mohou diskreditovat systém (například hacknutí poskytovatele může vést k vydání falešného klíče třetí straně), se navrhuje použít dodatečný, ale nepovinný prvek MFA-Cosigner (Multi-Factor Authentication Cosigner) pro vícestupňovou autentizaci (token by měl být podepsán nejen hlavním poskytovatelem, ale i nezávislou autentizační službou, která potvrzuje uživatele).
Mezi slabé stránky OpenPubKey patří také existence externích informací, které lze využít pro sledování aktivity po delší dobu a nezávisle na přejmenováních (opakované použití identifikujícího tokenu namísto nového certifikátu). Přímá vazba na klíče OpenID Connect při verifikaci vylučuje serverovou část, ale výrazně ztěžuje implementaci na straně klienta a zanechává více prostoru pro manévrování při provádění útoků (attack surface) na klienta, například kvůli tomu, že úkolem klienta je rotační správa klíčů. Absence logu změn neumožňuje klientovi sledovat možné úniky klíčů.
Zdroj: opennet.ru
