Linux Foundation, BastionZero og Docker presenterte et nytt åpent prosjekt OpenPubKey, som utvikler den kryptografiske protokollen med samme navn for digital signering av vilkårlige objekter. Teknologien ble utviklet som et felles prosjekt av BastionZero og Docker med mål om å forenkle den digitale signaturen til Docker-beholderbilder for å forhindre erstatning og bekrefte byggingen av den erklærte skaperen. Prosjektet skal utvikles på en nøytral plattform i regi av Linux Foundation, som vil eliminere avhengighet av enkeltstående kommersielle selskaper og forenkle samarbeid med involvering av tredjeparter. Referanseimplementeringen av OpenPubKey er skrevet i Go og distribuert under Apache 2.0-lisensen.
OpenPubKeys muligheter er ikke begrenset til containerbilder, og teknologien kan brukes til å bekrefte kilden til enhver ressurs, forhindre substitusjon av avhengighet og forbedre sikkerheten til datasettdistribusjonskanaler. For eksempel kan teknologien brukes til å verifisere programsammenstillinger, individuelle meldinger og forpliktelser. Signaturskapere trenger kun å ha en konto i en tjeneste som støtter OpenID, og forbrukere får mulighet til å verifisere vedlagte signaturer og bekrefte koblingen med den deklarerte OpenID-identifikatoren.
Når det gjelder formålet, ligner OpenPubKey Sigstore-systemet opprettet hos Google og tidligere overført til Linux Foundation, men skiller seg fra det ved å forenkle implementering, bruk og vedlikehold betydelig ved å kvitte seg med sentraliserte serverkomponenter som er ansvarlige for å opprettholde en offentlig logg som bekrefter autentisiteten. av endringer (transparenslogg), og sikre driften av sertifiseringsmyndigheter (Certificate Authority).
I stedet for å distribuere dine egne sertifiseringsinstanser, bruker OpenPubKey OpenID-autentiseringsteknologi og kobler de opprettede signaturene til eksisterende OpenID Connect-leverandører. Med andre ord lar OpenPubkey deg binde kryptografiske nøkler til spesifikke brukere ved å bruke OpenID Connect-leverandører (IdPs) i stedet for sertifikatmyndigheter. Teknologien er fullt kompatibel med eksisterende OpenID-leverandører, som GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak og Google, og krever ikke endringer på deres side (standard ID-token fra leverandøren brukes, som lar deg implementere OpenPubKey kun gjennom endringer på klientsiden OpenID Connect).
Tokenet utstedt av OpenID-leverandøren omdannes til et sertifikat som kryptografisk binder identifikatoren i OpenID Connect til den offentlige nøkkelen. Brukeren bruker deretter den genererte nøkkelen til å signere eventuelle data, og disse signaturene kan deretter verifiseres mot identifikatoren i OpenID Connect. OpenPubKey bruker flyktige nøkler som har en begrenset levetid – nøklene genereres under OpenID-pålogging og slettes når økten med OpenID-leverandøren avsluttes.
Et eksempel på algoritme for å lage en signatur ved hjelp av OpenPubKey:
- Logg på med en OpenID-leverandør (Google, GitHub, Microsoft, etc.).
- Be om et ID-token fra OpenID-leverandøren.
- Returnerer et token signert av leverandørnøkkelen og inkluderer et "nonce"-felt med vilkårlige data overført under forespørselen (SHA3-hashen til den offentlige nøkkelen overføres).
- Bruk på brukersiden av det mottatte tokenet som et sertifikat, inkludert nøkkeldata.
- Feste et token til en signatur, som ligner på et sertifikat.
Verifisering koker ned til å sjekke om det vedlagte tokenet er signert av OpenID-leverandøren og sjekke riktigheten av den digitale signaturen til ressursen ved hjelp av den offentlige nøkkelen, som lar deg forsikre deg om at ressursen er signert med identifikatoren fra sertifikatet, og at dette bekreftes av signaturen til OpenID-leverandøren. For eksempel kan skaperen av signaturen motta et token signert av Google OpenID-leverandøren med informasjon om at den er bekreftet som bob@gmail.com og bruker den offentlige nøkkelen 0x54A5…FF. Når mottakeren deretter mottar en melding signert med samme nøkkel, kan vedkommende bruke tokenet signert av leverandøren for å bekrefte at nøkkelen bob@gmail.com er 0x54A5…FF, og at meldingen faktisk ble signert av bob@gmail.com.
Forenkling av arkitekturen oppnås gjennom visse kompromisser (for eksempel avhengighet av eksterne OpenID-leverandører og fravær av endringslogg med hierarkisk hashing), som er akseptable i noen situasjoner, men ikke i andre. For å redusere avhengigheten av OpenID-leverandører, kompromiss eller handlinger til hvis personell kan diskreditere systemet (for eksempel kan hackede leverandører utstede en fiktiv nøkkel til en tredjepart), foreslås det å bruke en ekstra, men ikke obligatorisk, MFA-Cosigner (Multi-Factor Authentication Cosigner) lenke for multi-faktor autentisering (tokenet må signeres ikke bare av hovedleverandøren, men også av en uavhengig autentiseringstjeneste som bekrefter brukeren).
En av svakhetene til OpenPubKey er også tilstedeværelsen av uvedkommende informasjon som kan brukes til å spore aktivitet over lang tid og uavhengig av omdøping (gjenbruk av et identifikasjonstoken i stedet for et nytt sertifikat). Direkte binding til OpenID Connect-nøkler under verifisering eliminerer serverdelen, men kompliserer implementeringen på klientsiden betydelig og gir større handlingsrom når man utfører angrep (angrepsflate) på klienten, for eksempel på grunn av at oppgaven med nøkkelrotasjon faller på klienten. Fraværet av en endringslogg tillater ikke klienten å spore mulige nøkkellekkasjer.
Kilde: opennet.ru
