Linux Foundation, BastionZero e Docker hanno presentato un nuovo progetto open source chiamato OpenPubKey, che sviluppa un protocollo crittografico omonimo per la certificazione digitale di oggetti vari. La tecnologia \u00e8 stata sviluppata come progetto congiunto tra BastionZero e Docker con l'obiettivo di semplificare la certificazione firmata digitalmente delle immagini dei container Docker, per escludere eventuali sostituzioni e confermare la costruzione da parte del creatore dichiarato. Il progetto si svilupper\u00e0 su una piattaforma neutrale sotto l'egida della Linux Foundation, evitando dipendenze da singole aziende commerciali e semplificando la collaborazione con partecipanti esterni. L'implementazione di riferimento di OpenPubKey \u00e8 scritta in Go e distribuita con licenza Apache 2.0. <\/p>\n
Le capacit\u00e0 di OpenPubKey non si limitano solo alle immagini dei container e la tecnologia pu\u00f2 essere applicata per confermare la fonte di qualsiasi risorsa, prevenire la sostituzione delle dipendenze e migliorare la sicurezza dei canali di distribuzione dei dataset. Ad esempio, la tecnologia \u00e8 applicabile alla certificazione delle build software, a singoli messaggi e ai commit. I creatori delle firme hanno bisogno solo di un account su un servizio che supporta OpenID, mentre i consumatori possono verificare le firme allegate e confermarne il legame con l'ID OpenID dichiarato. <\/p>\n
Per sua natura, OpenPubKey \u00e8 simile al sistema Sigstore creato da Google e precedentemente trasferito alla Linux Foundation, ma si differenzia per la notevole semplificazione dell'implementazione, dell'uso e della manutenzione, eliminando componenti server centrali responsabili della gestione di un registro pubblico che certifica l'autenticit\u00e0 delle modifiche (transparency log) e garantisce il funzionamento delle autorit\u00e0 di certificazione (Certificate Authority). <\/p>\n
Invece di implementare propri centri di autenticazione, OpenPubKey utilizza l'autenticazione basata sulla tecnologia OpenID e collauda le firme create con i fornitori esistenti di OpenID Connect. In altre parole, OpenPubKey permette di associare chiavi crittografiche a specifici utenti, utilizzando i fornitori di OpenID Connect (IdP) invece di centri di autenticazione. La tecnologia \u00e8 completamente compatibile con i fornitori di OpenID esistenti, come GitHub, Azure\/Microsoft, Okta, OneLogin, Keycloak e Google, e non richiede modifiche da parte loro (si utilizza il tipo standard di ID Token fornito dal provider, consentendo l'implementazione di OpenPubKey solo attraverso modifiche sul lato client di OpenID Connect). <\/p>\n
Il token OpenID rilasciato dal provider viene trasformato in un certificato che associa in modo crittografico l'identificativo nell'OpenID Connect alla chiave pubblica. Successivamente, l'utente utilizza la chiave generata per firmare qualsiasi dato e queste firme possono essere successivamente verificate in relazione all'identificativo nell'OpenID Connect. In OpenPubKey vengono utilizzate chiavi effimere, la cui durata \u00e8 limitata: le chiavi vengono generate durante il login tramite OpenID e vengono eliminate al termine della sessione con il provider OpenID. <\/p>\n
Algoritmo esemplificativo per la creazione di una firma utilizzando OpenPubKey: <\/p>\n
La verifica consiste nel controllare se il token allegato \u00e8 stato firmato dal provider OpenID e nella convalida della correttezza della firma digitale sul risorsa con la chiave pubblica, consentendo di accertare che la risorsa \u00e8 stata firmata utilizzando l'identificativo del certificato ed \u00e8 confermata dalla firma del provider OpenID. Ad esempio, chi crea la firma pu\u00f2 ricevere un token firmato dal provider OpenID di Google con informazioni che lo certificano come bob@gmail.com e utilizza la chiave pubblica 0x54A5\u2026FF. Successivamente, quando riceve un messaggio firmato dalla stessa chiave, pu\u00f2 utilizzare il token firmato dal provider per verificare che la chiave bob@gmail.com sia 0x54A5\u2026FF e che il messaggio sia stato effettivamente firmato da bob@gmail.com. <\/p>\n
La semplificazione dell'architettura \u00e8 stata realizzata a causa di determinati compromessi (ad esempio, la dipendenza dai provider esterni OpenID e l'assenza di un registro delle modifiche con hash gerarchici), che sono accettabili in alcune situazioni ma non in altre. Per ridurre la dipendenza dai provider OpenID, la compromissione o le azioni del personale che potrebbero sminuire il sistema (ad esempio, un provider compromesso potrebbe emettere una chiave falsa a un terzo) si propone di utilizzare un ulteriore ma non obbligatorio, anello MFA-Cosigner (Cosigner di Autenticazione Multi-Fattore) per l'autenticazione multi-fattore (il token deve essere firmato non solo dal provider principale, ma anche da un servizio di autenticazione indipendente che convalida l'utente). <\/p>\n