De Linux Foundation, BastionZero en Docker hebben een nieuw open project OpenPubKey ge\u00efntroduceerd, dat het gelijknamige cryptografische protocol ontwikkelt voor het bevestigen van digitale handtekeningen van willekeurige objecten. De technologie is ontwikkeld als een gezamenlijk project van BastionZero en Docker, met als doel het vereenvoudigen van het ondertekenen van Docker-containerimages met digitale handtekeningen om vervalsing te voorkomen en de bouw door de opgegeven maker te bevestigen. Het project zal worden ontwikkeld op een neutraal platform onder de bescherming van de Linux Foundation, waardoor afhankelijkheid van specifieke commerci\u00eble bedrijven wordt ge\u00eblimineerd en samenwerking met externe deelnemers wordt vergemakkelijkt. De referentie-implementatie van OpenPubKey is geschreven in de programmeertaal Go en wordt verspreid onder de Apache 2.0-licentie. <\/p>\n
De mogelijkheden van OpenPubKey beperken zich niet alleen tot containerimages; de technologie kan ook worden toegepast voor het bevestigen van de bron van elke resource, het voorkomen van vervalsing van afhankelijkheden en het verhogen van de veiligheid van distributiekanalen voor datasets. Bijvoorbeeld, de technologie is toepasbaar voor het ondertekenen van software-builds, afzonderlijke berichten en commits. Handtekeningmakers hoeven alleen een account te hebben bij een dienst die OpenID ondersteunt, terwijl consumenten de mogelijkheid krijgen om bijgevoegde handtekeningen te verifi\u00ebren en hun verbinding met de opgegeven OpenID-identificatie te bevestigen. <\/p>\n
Qua functionaliteit lijkt OpenPubKey op het systeem Sigstore dat door Google is ontwikkeld en eerder is overgedragen aan de Linux Foundation, maar het verschilt van dat systeem door de aanzienlijke vereenvoudiging van implementatie, gebruik en onderhoud, doordat het geen gecentraliseerde servercomponenten bevat die verantwoordelijk zijn voor het bijhouden van een openbaar logboek, dat de authenticiteit van wijzigingen bevestigt (transparency log), en het functioneren van certificeringsinstellingen (Certificate Authority) verzekert. <\/p>\n
In plaats van het opzetten van eigen certificeringsinstanties, maakt OpenPubKey gebruik van authenticatie met behulp van technologie\u00ebn zoals OpenID en koppelt het de gegenereerde handtekeningen aan bestaande OpenID Connect-providers. Met andere woorden, OpenPubKey maakt het mogelijk om cryptografische sleutels aan specifieke gebruikers te koppelen, met behulp van OpenID Connect-providers (IdP) in plaats van certificeringsinstanties. De technologie is volledig compatibel met bestaande OpenID-providers zoals GitHub, Azure\/Microsoft, Okta, OneLogin, Keycloak en Google, en vereist geen wijzigingen aan hun kant (de niet-veranderde ID Token die door de provider wordt verstrekt, maakt het mogelijk om OpenPubKey uitsluitend via wijzigingen aan de kant van de OpenID Connect-cli\u00ebnt te implementeren). <\/p>\n
De door de provider uitgegeven OpenID-token wordt omgezet in een certificaat dat de identificatie in OpenID Connect cryptografisch koppelt aan de openbare sleutel. Vervolgens gebruikt de gebruiker de gegenereerde sleutel om gegevens te ondertekenen, en deze handtekeningen kunnen later worden gecontroleerd op hun verband met de identificatie in OpenID Connect. In OpenPubKey worden ephemerale sleutels toegepast, wiens levensduur beperkt is \u2014 sleutels worden gegenereerd tijdens de inlogprocedure met OpenID en worden verwijderd na het be\u00ebindigen van de sessie met de OpenID-provider. <\/p>\n
Een voorbeeldalgoritme voor het maken van een handtekening met OpenPubKey: <\/p>\n
De verificatie beperkt zich tot het controleren of het bijgevoegde token door de OpenID-provider is ondertekend en het controleren van de geldigheid van de digitale handtekening van de bron met de openbare sleutel, wat bevestigt dat de bron is ondertekend met behulp van de identificatie uit het certificaat en dat dit is bevestigd door de handtekening van de OpenID-provider. Bijvoorbeeld, de ondertekenaar kan een door de OpenID-provider Google ondertekend token krijgen met de informatie dat hij wordt geverifieerd als bob@gmail.com en gebruikt de openbare sleutel 0x54A5\u2026FF. Bij het ontvangen van een bericht dat met dezelfde sleutel is ondertekend, kan de ontvanger het door de provider ondertekende token gebruiken om te verifi\u00ebren dat de sleutel bob@gmail.com \u2014 0x54A5\u2026FF is en dat het bericht daadwerkelijk is ondertekend door bob@gmail.com. <\/p>\n
Vereenvoudiging van de architectuur is gerealiseerd door bepaalde compromissen (bijvoorbeeld afhankelijkheid van externe OpenID-providers en het ontbreken van een log van wijzigingen met hi\u00ebrarchische hashing), die in bepaalde situaties acceptabel zijn, terwijl ze in andere niet zijn. Om de afhankelijkheid van OpenID-providers te verminderen, van wie de compromittering of acties het systeem kunnen ondermijnen (bijvoorbeeld een gehackte provider kan een valse sleutel aan een derde partij geven), wordt voorgesteld om een extra, maar niet verplicht, schakel MFA-Cosigner (Multi-Factor Authentication Cosigner) te gebruiken voor multi-factor authenticatie (het token moet niet alleen door de hoofdprovider worden ondertekend, maar ook door een onafhankelijke authenticatieservice die de gebruiker bevestigt). <\/p>\n