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 è 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à 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 è scritta in Go e distribuita con licenza Apache 2.0.
Le capacità di OpenPubKey non si limitano solo alle immagini dei container e la tecnologia può 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 è 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.
Per sua natura, OpenPubKey è 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à delle modifiche (transparency log) e garantisce il funzionamento delle autorità di certificazione (Certificate Authority).
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 è 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).
Il token emesso dal fornitore OpenID viene trasformato in un certificato, che associa crittograficamente l'identificatore in OpenID Connect alla chiave pubblica. Successivamente, l'utente utilizza la chiave generata per firmare qualsiasi dato e queste firme possono successivamente essere verificate in relazione all'identificatore in OpenID Connect. In OpenPubKey vengono utilizzate chiavi effimere, la cui vita è limitata: le chiavi vengono generate al momento del login tramite OpenID e vengono eliminate al termine della sessione con il fornitore OpenID.
Algoritmo esemplificativo per la creazione di una firma utilizzando OpenPubKey:
- Accesso tramite fornitore OpenID (Google, GitHub, Microsoft, ecc.).
- Richiesta del token di identificazione dal fornitore OpenID.
- Restituzione del token, firmato con la chiave del fornitore e contenente il campo «nonce» con dati casuali forniti nella richiesta (viene passato l'hash SHA3 della chiave pubblica).
- Utilizzo sul lato utente del token ricevuto come certificato, che include i dati sulla chiave.
- Allegare il token alla firma, analogamente a un certificato.
La verifica consiste nel controllare se il token allegato è stato firmato dal provider OpenID e di verificare la correttezza della firma digitale sul risorsa tramite la chiave pubblica, il che consente di accertare che la risorsa sia firmata utilizzando l'identificatore del certificato e che ciò sia confermato dalla firma del provider OpenID. Ad esempio, chi crea la firma può ottenere un token firmato dal provider OpenID di Google con informazioni che indicano che è stato verificato come bob@gmail.com e utilizza la chiave pubblica 0x54A5…FF. Successivamente, al ricevimento di un messaggio firmato con la stessa chiave, si può utilizzare il token firmato dal provider per verificare che la chiave bob@gmail.com sia 0x54A5…FF e che il messaggio sia stato effettivamente firmato da bob@gmail.com.
La semplificazione dell'architettura è stata realizzata attraverso determinati compromessi (ad esempio, la dipendenza da provider OpenID esterni e l'assenza di un registro delle modifiche con hash gerarchico), che sono accettabili in alcune situazioni e inaccettabili in altre. Per ridurre la dipendenza dai provider OpenID, la compromissione o le azioni del personale dei quali possono screditare il sistema (ad esempio, un provider compromesso può emettere una chiave falsa a terzi) si propone di utilizzare un ulteriore ma non obbligatorio anello MFA-Cosigner (Multi-Factor Authentication Cosigner) per l'autenticazione multifattoriale (il token deve essere firmato non solo dal provider principale, ma anche da un servizio di autenticazione indipendente che autentica l'utente).
Tra i punti deboli di OpenPubKey si segnala anche la disponibilità di informazioni da fonti esterne, che possono essere utilizzate per monitorare l'attività nel tempo e indipendentemente dai cambiamenti di nome (riutilizzo di un token identificativo anziché un nuovo certificato). Il legame diretto con le chiavi OpenID Connect durante la verifica esclude la parte server, ma complica notevolmente l'implementazione lato client e lascia maggiore margine di manovra in caso di attacchi (attack surface) al client, ad esempio, poiché spetta al client la rotazione delle chiavi. L'assenza di un registro delle modifiche non consente al client di monitorare eventuali fughe di chiavi.
Fonte: opennet.ru
