La Linux Foundation, BastionZero e Docker hanno presentato un nuovo progetto open-source, OpenPubKey, che sviluppa un protocollo crittografico omonimo per la certificazione digitale di oggetti arbitrari. La tecnologia è stata sviluppata come progetto congiunto tra BastionZero e Docker, con l'obiettivo di semplificare la certificazione delle immagini dei container Docker tramite firme digitali, per evitare manomissioni e confermare la costruzione da parte del creatore dichiarato. Il progetto si svilupperà su una piattaforma neutrale sotto l'egida della Linux Foundation, il che eliminerà la dipendenza da singole aziende commerciali e faciliterà la collaborazione con la partecipazione di terze parti. 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 utilizzata per convalidare l'origine di qualsiasi risorsa, prevenire la sostituzione delle dipendenze e aumentare la sicurezza dei canali di distribuzione dei set di dati. Ad esempio, la tecnologia è applicabile a garantire le versioni del software, singoli messaggi e commit. Per i creatori di firme è sufficiente avere un account su un servizio che supporta OpenID, mentre ai consumatori viene fornita la possibilità di verificare le firme allegate e confermare la loro afferenza all'identificatore OpenID dichiarato.
Per sua funzione, OpenPubKey ricorda il sistema Sigstore creato da Google e successivamente trasferito alla Linux Foundation, ma si differenzia notevolmente per la semplificazione dell'implementazione, dell'uso e della manutenzione, eliminando componenti server centralizzati responsabili della gestione di un registro pubblico che conferma l'autenticità delle modifiche (transparency log) e dell'operatività delle autorità di certificazione (Certificate Authority).
Invece di implementare i propri centri di certificazione, OpenPubKey utilizza l'autenticazione tramite la tecnologia OpenID e l'associazione delle firme create con i fornitori esistenti di OpenID Connect. In altre parole, OpenPubKey consente di associare chiavi crittografiche a utenti specifici, utilizzando fornitori OpenID Connect (IdP) al posto dei centri di certificazione. La tecnologia è completamente compatibile con i fornitori esistenti di OpenID, come GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak e Google, e non richiede modifiche da parte loro (viene utilizzato il Token ID standard fornito dal provider, il che consente di implementare OpenPubKey solo con modifiche sul lato client di OpenID Connect).
Il token OpenID emesso dal provider viene trasformato in un certificato, che associa crittograficamente l'identificatore in OpenID Connect alla chiave pubblica. L'utente utilizza quindi la chiave generata per firmare qualsiasi dato, e queste firme possono essere verificate in seguito rispetto all'identificatore in OpenID Connect. In OpenPubKey vengono utilizzate chiavi effimere, la cui durata è limitata: le chiavi vengono generate al momento del login tramite OpenID e vengono eliminate al termine della sessione con il provider OpenID.
Algoritmo indicativo per la creazione di una firma utilizzando OpenPubKey:
- Accesso tramite un provider OpenID (Google, GitHub, Microsoft, ecc.).
- Richiesta di un token di identificazione dal provider OpenID.
- Restituzione del token, firmato dalla chiave del provider e contenente un campo 'nonce' con dati casuali forniti nella richiesta (viene fornito l'hash SHA3 della chiave pubblica).
- Utilizzo, da parte dell'utente, del token ottenuto come certificato che include informazioni sulla chiave.
- Allegare il token alla firma, analogamente a un certificato.
La verifica consiste nel controllare se il token allegato è firmato dal provider OpenID e nell'accertare la validità della firma digitale rispetto alle risorse tramite la chiave pubblica. Questo consente di assicurarsi che la risorsa sia firmata utilizzando l'identificatore presente nel certificato, confermato dalla firma del provider OpenID. Ad esempio, chi crea la firma può ricevere un token firmato dal provider OpenID di Google, con informazioni che attestano la verifica come bob@gmail.com, e utilizza la chiave pubblica 0x54A5…FF. Successivamente, quando riceve un messaggio firmato dalla stessa chiave, può usare il token firmato dal provider per verificare che la chiave bob@gmail.com corrisponda a 0x54A5…FF e che il messaggio sia effettivamente stato firmato da bob@gmail.com.
La semplificazione dell'architettura è stata realizzata attraverso determinati compromessi (ad esempio, dipendenza da fornitori esterni OpenID e mancanza di un registro delle modifiche con hash gerarchico), che in alcune situazioni sono accettabili, mentre in altre no. Per ridurre la dipendenza dai fornitori OpenID, la compromissione o le azioni del personale dei quali possono screditare il sistema (ad esempio, un fornitore compromesso potrebbe 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 fornitore principale, ma anche da un servizio di autenticazione indipendente che confermi l'utente).
Tra gli svantaggi di OpenPubKey c'è la presenza di informazioni esterne che possono essere utilizzate per monitorare le attività nel lungo termine, indipendentemente dai rinominamenti (riutilizzando un token identificativo invece di 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 più spazio per attacchi (attack surface) al client, ad esempio, a causa del compito di rotazione delle chiavi che ricade sul cliente. L'assenza di un registro delle modifiche non consente al cliente di monitorare le possibili perdite di chiavi.
Fonte: opennet.ru
