Linux Foundation, BastionZero și Docker au lansat un nou proiect deschis OpenPubKey, care dezvoltă protocolul criptografic omonim pentru certificarea digitală a obiectelor diverse. Tehnologia a fost dezvoltată ca un proiect comun între BastionZero și Docker, având ca scop simplificarea procesului de certificare a imaginilor containerelor Docker cu semnături digitale pentru a preveni înlocuirea acestora și a confirma construcția de către creatorul declarat. Proiectul va evolua pe o platformă neutră sub tutela organizației Linux Foundation, ceea ce va elimina dependența de companii comerciale și va facilita colaborarea cu participanți externi. Implementarea de referință OpenPubKey este scrisă în limbajul Go și este distribuită sub licența Apache 2.0.
Funcționalitățile OpenPubKey nu se limitează doar la imaginile containerelor, iar tehnologia poate fi utilizată pentru a confirma sursa oricărui tip de resursă, prevenind înlocuirea dependențelor și îmbunătățind securitatea canalelor de distribuire a seturilor de date. De exemplu, tehnologia este aplicabilă pentru certificarea construcțiilor de software, a mesajelor individuale și a commit-urilor. Creatorii de semnături au nevoie doar de un cont într-un serviciu care suportă OpenID, în timp ce consumatorii au posibilitatea de a verifica semnăturile atașate și de a confirma legătura acestora cu identificatorul OpenID declarat.
Din punct de vedere al funcției, OpenPubKey este similar cu sistemul Sigstore creat de Google și transferat anterior către Linux Foundation, dar se diferențiază prin simplificarea considerabilă a implementării, utilizării și întreținerii datorită eliminării componentelor serverului centralizat responsabile pentru gestionarea jurnalului public, care confirmă autenticitatea modificărilor (transparency log), și asigurarea funcționării autorităților de certificare (Certificate Authority).
În loc să implementeze centre de autorizare proprii, OpenPubKey utilizează autentificarea prin tehnologia OpenID și leagă semnăturile create de furnizorii existenți de OpenID Connect. Cu alte cuvinte, OpenPubKey permite asocierea cheilor criptografice cu utilizatori specifici prin intermediul furnizorilor OpenID Connect (IdP) în loc de centrele de autorizare. Tehnologia este complet compatibilă cu furnizorii OpenID existenți, cum ar fi GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak și Google, și nu necesită modificări din partea lor (folosind tipul de ID Token furnizat de furnizor, ceea ce permite implementarea OpenPubKey doar prin modificări pe partea clientului OpenID Connect).
Tokenul de identificare emis de furnizorul OpenID este transformat într-un certificat, care leagă criptografic identificatorul din OpenID Connect de cheia publică. Apoi, utilizatorul folosește cheia generată pentru a semna orice date, iar aceste semnături pot fi ulterior verificate în legătură cu identificatorul din OpenID Connect. OpenPubKey utilizează chei efemere, a căror durată de viață este limitată — cheile sunt generate în timpul autentificării prin OpenID și sunt șterse la finalizarea sesiunii cu furnizorul OpenID.
Algoritmul aproximativ pentru crearea unei semnături utilizând OpenPubKey:
- Autentificare folosind furnizorul OpenID (Google, GitHub, Microsoft etc.).
- Solicitarea unui token de identificare de la furnizorul OpenID.
- Returnarea tokenului, semnat cu cheia furnizorului și incluzând câmpul „nonce” cu date aleatorii transmise în cerere (se transmite hash-ul SHA3 al cheii publice).
- Utilizarea în partea utilizatorului a tokenului obținut ca certificat, incluzând date despre cheia respectivă.
- Atașarea tokenului la semnătură, similar cu un certificat.
Verificarea constă în verificarea dacă tokenul atașat a fost semnat de un furnizor OpenID și în verificarea corectitudinii semnăturii digitale asupra resursei prin cheia publică, ceea ce permite confirmarea că resursa a fost semnată folosind un identificator din certificat și că aceasta este validată prin semnătura furnizorului OpenID. De exemplu, cel care generează semnătura poate primi un token semnat de furnizorul OpenID Google cu informația că este confirmat ca bob@gmail.com și folosește cheia publică 0x54A5…FF. Apoi, la primirea unui mesaj semnat cu aceeași cheie, acesta poate folosi tokenul semnat de furnizor pentru a verifica că cheia bob@gmail.com este 0x54A5…FF și că mesajul a fost semnat cu adevărat de bob@gmail.com.
Simplificarea arhitecturii a fost realizată prin anumite compromisuri (de exemplu, dependența de furnizori OpenID externi și lipsa unui jurnal al modificărilor cu hash-uri ierarhice), care în anumite situații sunt acceptabile, iar în altele nu. Pentru a reduce dependența de furnizorii OpenID, compromiterea sau acțiunile personalului cărora le pot discredita sistemul (de exemplu, un furnizor spart poate emite o cheie falsă unei terțe părți), se propune utilizarea unui element suplimentar, dar opțional, MFA-Cosigner (Cosigner de Autentificare Multi-Factor), pentru autentificarea multi-factor (tokenul trebuie să fie semnat nu doar de furnizorul principal, ci și de un serviciu de autentificare independent, care confirmă utilizatorul).
Printre slăbiciunile OpenPubKey se numără prezența informațiilor externe, care pot fi utilizate pentru urmărirea activității pe o perioadă lungă de timp și independent de redenumiri (reutilizarea tokenului identificator în loc de un certificat nou). Legătura directă cu cheile OpenID Connect în timpul verificării exclude partea de server, dar complică semnificativ implementarea pe partea clientului și lasă mai mult spațiu de manevră pentru atacuri (suprafața de atac) asupra clientului, de exemplu, din cauza faptului că sarcina rotației cheilor revine clientului. Lipsa unui jurnal al modificărilor nu permite clientului să monitorizeze posibilele scurgeri de chei.
Sursa: opennet.ro
