Linux Foundation, BastionZero og Docker har pr\u00e6senteret et nyt \u00e5bent projekt OpenPubKey, som udvikler den samme kryptografiske protokol til at bekr\u00e6fte digitale signaturer af vilk\u00e5rlige objekter. Teknologien er udviklet som et f\u00e6lles projekt af virksomhederne BastionZero og Docker med det form\u00e5l at forenkle bekr\u00e6ftelsen af digitale signaturer af Docker-containerbilleder for at undg\u00e5 substitution og bekr\u00e6fte opbygning af det, der er angivet af skaberen. Projektet vil udvikle sig p\u00e5 en neutral platform under beskyttelse af Linux Foundation, hvilket vil eliminere afh\u00e6ngigheden af enkelte kommercielle virksomheder og forenkle samarbejdet med involvering af tredjepartsakt\u00f8rer. Referenceimplementeringen af OpenPubKey er skrevet i Go og distribueres under Apache 2.0-licensen. <\/p>\n
Mulighederne for OpenPubKey er ikke kun begr\u00e6nset til containerbilleder, og teknologien kan anvendes til at bekr\u00e6fte kilden til enhver ressource, forhindre substitution af afh\u00e6ngigheder og forbedre sikkerheden af distribueringskanaler for datas\u00e6t. For eksempel er teknologien anvendelig til at bekr\u00e6fte samlinger af software, individuelle meddelelser og commits. Skaberne af signaturen skal blot have en konto i en service, der underst\u00f8tter OpenID, mens forbrugerne f\u00e5r mulighed for at verificere vedh\u00e6ftede signaturer og bekr\u00e6fte deres forbindelse til den angivne OpenID-identifikation. <\/p>\n
M\u00e6ssigt 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\u00e6sentlig forenkling af implementering, brug og vedligeholdelse ved at undg\u00e5 centraliserede serverkomponenter, der er ansvarlige for at f\u00f8re en offentlig log, der bekr\u00e6fter \u00e6gtheden af \u00e6ndringer (transparency log), og tilvejebringe drift af certifikationsmyndigheder (Certificate Authority). <\/p>\n
I stedet for at implementere egne certifikatcentre anvender OpenPubKey autentificering ved hj\u00e6lp af OpenID-teknologi og knytter de oprettede signaturer til eksisterende OpenID Connect-udbydere. Med andre ord g\u00f8r OpenPubkey det muligt at knytte kryptografiske n\u00f8gler 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\u00e6ver ikke \u00e6ndringer fra deres side (den leverede udbyderens standard ID Token bruges, hvilket g\u00f8r det muligt at implementere OpenPubKey kun gennem \u00e6ndringer p\u00e5 OpenID Connect-klientsiden). <\/p>\n
Den udstedte OpenID-token fra udbyderen transformeres til et certifikat, der kryptografisk binder identifikatoren i OpenID Connect til den offentlige n\u00f8gle. Herefter kan brugeren anvende den genererede n\u00f8gle til at signere data, og disse signaturer kan senere verificeres i forbindelse med identifikatoren i OpenID Connect. I OpenPubKey anvendes ephemeral n\u00f8gler, hvis levetid er begr\u00e6nset \u2014 n\u00f8glerne genereres ved login via OpenID og slettes ved afslutning af sessionen med OpenID-udbyderen. <\/p>\n
Eksemplet p\u00e5 algoritmen til oprettelse af en signatur ved hj\u00e6lp af OpenPubKey: <\/p>\n
Verifikationen g\u00e5r ud p\u00e5 at kontrollere, om det vedh\u00e6ftede token er signeret af OpenID-udbyderen, og at den digitale signatur er korrekt i forhold til ressourcen med den offentlige n\u00f8gle, hvilket bekr\u00e6fter, at ressourcen er signeret med identifikatoren fra certifikatet og at dette er bekr\u00e6ftet af OpenID-udbyderens signatur. For eksempel kan den, der signer, f\u00e5 en token, der er signeret af OpenID-udbyderen Google med oplysninger om, at han er verificeret som bob@gmail.com, og anvender den offentlige n\u00f8gle 0x54A5\u2026FF. N\u00e5r han modtager en besked, der er signeret med den samme n\u00f8gle, kan han anvende den signerede token fra udbyderen til at verificere, at n\u00f8glen bob@gmail.com \u2014 0x54A5\u2026FF, faktisk er signeret af bob@gmail.com. <\/p>\n
Forenklingen af arkitekturen er realiseret gennem visse kompromisser (for eksempel afh\u00e6ngighed af eksterne OpenID-udbydere og mangel p\u00e5 en \u00e6ndringslog med hierarkisk hashing), som i nogle situationer kan v\u00e6re acceptable, og i andre ikke. For at reducere afh\u00e6ngigheden af OpenID-udbydere, hvis kompromittering eller handlinger fra personale kan diskreditere systemet (f.eks. en hacket udbyder kan udstede en falsk n\u00f8gle til en tredjepart), foresl\u00e5s det at anvende et ekstra, men ikke obligatorisk led MFA-Cosigner (Multi-Factor Authentication Cosigner) til multifaktorautentificering (tokenet skal ikke kun v\u00e6re signeret af den prim\u00e6re udbyder, men ogs\u00e5 af en uafh\u00e6ngig autentificeringstjeneste, der bekr\u00e6fter brugeren). <\/p>\n