Linux Foundation, BastionZero og Docker har præsenteret et nyt åbent projekt OpenPubKey, som udvikler den samme kryptografiske protokol til at bekræfte digitale signaturer af vilkårlige objekter. Teknologien er udviklet som et fælles projekt af virksomhederne BastionZero og Docker med det formål at forenkle bekræftelsen af digitale signaturer af Docker-containerbilleder for at undgå substitution og bekræfte opbygning af det, der er angivet af skaberen. Projektet vil udvikle sig på en neutral platform under beskyttelse af Linux Foundation, hvilket vil eliminere afhængigheden af enkelte kommercielle virksomheder og forenkle samarbejdet med involvering af tredjepartsaktører. Referenceimplementeringen af OpenPubKey er skrevet i Go og distribueres under Apache 2.0-licensen.
Mulighederne for OpenPubKey er ikke kun begrænset til containerbilleder, og teknologien kan anvendes til at bekræfte kilden til enhver ressource, forhindre substitution af afhængigheder og forbedre sikkerheden af distribueringskanaler for datasæt. For eksempel er teknologien anvendelig til at bekræfte samlinger af software, individuelle meddelelser og commits. Skaberne af signaturen skal blot have en konto i en service, der understøtter OpenID, mens forbrugerne får mulighed for at verificere vedhæftede signaturer og bekræfte deres forbindelse til den angivne OpenID-identifikation.
Mæssigt minder OpenPubKey om det system, som Google har skabt og tidligere har overdraget til Linux Foundation, kaldet Sigstore, men adskiller sig fra det med en væsentlig forenkling af implementering, brug og vedligeholdelse ved at undgå centraliserede serverkomponenter, der er ansvarlige for at føre en offentlig log, der bekræfter ægtheden af ændringer (transparency log), og tilvejebringe drift af certifikationsmyndigheder (Certificate Authority).
I stedet for at implementere egne certifikatcentre anvender OpenPubKey autentificering ved hjælp af OpenID-teknologi og knytter de oprettede signaturer til eksisterende OpenID Connect-udbydere. Med andre ord gør OpenPubkey det muligt at knytte kryptografiske nøgler til specifikke brugere ved at bruge OpenID Connect-udbydere (IdP) i stedet for certifikatcentre. Teknologien er helt kompatibel med eksisterende OpenID-udbydere som GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak og Google, og kræver ikke ændringer fra deres side (den leverede udbyderens standard ID Token bruges, hvilket gør det muligt at implementere OpenPubKey kun gennem ændringer på OpenID Connect-klientsiden).
Den udstedte OpenID-token omdannes til et certifikat, der kryptografisk knytter identifikatoren i OpenID Connect til den offentlige nøgle. Derefter bruger brugeren den genererede nøgle til at signere data, og disse signaturer kan efterfølgende verificeres i forhold til identifikatoren i OpenID Connect. OpenPubKey anvender ephemeral nøgler, hvis levetid er begrænset — nøglerne genereres under login via OpenID og slettes ved afslutningen af sessionen med OpenID-udbyderen.
Eksemplet på algoritmen til oprettelse af en signatur ved hjælp af OpenPubKey:
- Login ved hjælp af OpenID-udbyderen (Google, GitHub, Microsoft osv.).
- Anmodning om identifikationstoken fra OpenID-udbyderen.
- Tilbageførsel af token, der er underskrevet med udbyderens nøgle og inkluderer feltet "nonce" med vilkårlige data, der blev sendt ved anmodningen (SHA3-hash af den offentlige nøgle overføres).
- Brug på brugerens side af den modtagne token som et certifikat, der inkluderer oplysninger om nøglen.
- Vedhæftning af token til signaturen, på samme måde som med certifikatet.
Verifikationen går ud på at kontrollere, om den vedhæftede token er underskrevet af OpenID-udbyderen og kontrollere korrektheden af den digitale signatur til ressourcen ved hjælp af den offentlige nøgle, hvilket gør det muligt at sikre, at ressourcen er underskrevet med identifikatoren fra certifikatet, og dette bekræftes af signaturen fra OpenID-udbyderen. For eksempel kan den, der laver signaturen, få en token underskrevet af Google som OpenID-udbyder med oplysninger om, at han er verificeret som bob@gmail.com og bruger den offentlige nøgle 0x54A5…FF. Herefter, når der modtages en besked, der er underskrevet med samme nøgle, kan den signeret token fra udbyderen bruges til at verificere, at nøglen bob@gmail.com - 0x54A5…FF, og at beskeden rent faktisk er underskrevet af bob@gmail.com.
Forenklingen af arkitekturen er opnået gennem visse kompromiser (for eksempel afhængighed af eksterne OpenID-udbydere og mangel på log for ændringer med hierarkisk hashing), som i visse situationer er acceptable, mens de i andre ikke er. For at reducere afhængigheden af OpenID-udbydere, hvis kompromittering eller handlinger fra personale kan diskreditere systemet (for eksempel kan en hacker af en udbyder udstede en falsk nøgle til en tredjepart), foreslås det at bruge et ekstra, men ikke obligatorisk, led MFA-Cosigner (Multi-Factor Authentication Cosigner) til multifaktorautentificering (tokenet skal være underskrevet ikke kun af den primære udbyder, men også af en uafhængig autentificeringstjeneste, der bekræfter brugeren).
Blandt de svage sider ved OpenPubKey er der også oplysninger fra tredjepart, som kan bruges til at spore aktiviteter over længere tid uafhængigt af navneskift (genbrug af identificerende token i stedet for et nyt certifikat). Den direkte binding til OpenID Connect-nøglerne ved verifikation udelukker serverdelen, men komplicerer implementeringen på klientsiden betydeligt og efterlader mere plads til angreb (attack surface) på klienten, for eksempel fordi klienten skal håndtere nøglerotation. Manglen på log over ændringer hindrer klienten i at spore mulige nøglelækager.
Kilde: opennet.ru
