Linux Ang Foundation, BastionZero, ug Docker nagpagawas ug bag-ong open source nga proyekto, ang OpenPubKey, nga nagpalambo sa eponymous cryptographic protocol para sa digital nga pagpirma sa mga butang nga walay klarong ngalan. Ang teknolohiya gihimo isip usa ka hiniusa nga proyekto tali sa BastionZero ug Docker aron pasimplehon ang digital nga pagpirma sa mga imahe sa Docker container aron malikayan ang pagpanghilabot ug mapamatud-an nga kini gihimo sa orihinal nga tiglalang. Ang proyekto pag-uswagon sa usa ka neyutral nga plataporma ubos sa pagdumala sa organisasyon. Linux Foundation, nga nagwagtang sa pagsalig sa indibidwal nga mga kompanya sa komersyo ug nagpasayon sa kolaborasyon sa mga third-party nga kontribyutor. Ang implementasyon sa reperensya sa OpenPubKey gisulat sa Go ug giapod-apod ubos sa lisensya sa Apache 2.0.
Ang mga kapabilidad sa OpenPubKey dili limitado sa mga imahe sa container; ang teknolohiya magamit aron mapamatud-an ang gigikanan sa bisan unsang kapanguhaan, mapugngan ang dependency spoofing, ug mapaayo ang seguridad sa mga channel sa pag-apod-apod sa datos. Pananglitan, ang teknolohiya magamit aron mapamatud-an ang mga software builds, indibidwal nga mga mensahe, ug mga commit. Ang mga tighimo og pirma kinahanglan ra og account nga adunay serbisyo nga gipagana sa OpenID, samtang ang mga konsumidor makapamatuod sa gilakip nga mga pirma ug makumpirma ang ilang kalambigitan sa gideklarar nga OpenID identifier.
Sa katuyoan niini, ang OpenPubKey susama sa gihimo sa Google ug kaniadto gibalhin sa Linux Ang Foundation susama sa sistema sa Sigstore, apan lahi niini tungod kay gipasimple niini ang implementasyon, paggamit, ug pagmentinar pinaagi sa pagtangtang sa mga sentralisadong sangkap sa server nga responsable sa pagmentinar sa usa ka publikong log nga nagpamatuod sa pagkatinuod sa mga pagbag-o (transparency log) ug pagsiguro sa operasyon sa mga awtoridad sa sertipikasyon (Certificate Authority).
Imbis nga mag-deploy og custom CAs, ang OpenPubKey mogamit og OpenID authentication ug mo-bind sa mga generated signatures ngadto sa kasamtangang OpenID Connect providers. Sa ato pa, ang OpenPubKey motugot kanimo sa pag-bind sa mga cryptographic key ngadto sa piho nga mga tiggamit gamit ang OpenID Connect providers (IdPs) imbes sa mga CA. Ang teknolohiya hingpit nga compatible sa kasamtangang OpenID providers, sama sa GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak, ug Google, ug wala magkinahanglan og mga pagbag-o sa maong mga providers (naggamit kini og standard ID Token nga gihatag sa provider, nga nagtugot sa OpenPubKey nga ipatuman lamang pinaagi sa mga pagbag-o sa OpenID Connect client).
Ang token nga gi-isyu sa OpenID provider gihimong sertipiko, nga cryptographically nga nagbugkos sa OpenID Connect identifier ngadto sa public key. Dayon gamiton sa user ang generated key aron pirmahan ang bisan unsang data, ug kini nga mga pirma mahimong mapamatud-an sa ulahi batok sa OpenID Connect identifier. Ang OpenPubKey naggamit ug ephemeral keys nga adunay limitado nga lifetime—ang mga key gihimo atol sa OpenID login ug gitangtang kung matapos ang session uban sa OpenID provider.
Usa ka gibanabana nga algorithm alang sa paghimo og pirma gamit ang OpenPubKey:
- Pag-login gamit ang usa ka OpenID provider (Google, GitHub, Microsoft, ug uban pa).
- Paghangyo og ID token gikan sa usa ka OpenID provider.
- Ibalik ang usa ka token nga gipirmahan gamit ang yawe sa provider ug lakip ang usa ka "nonce" nga field nga adunay arbitraryong datos nga gipadala atol sa hangyo (ang SHA3 hash sa public key gipadala).
- Paggamit sa nadawat nga token sa user side isip sertipiko nga naglakip sa importanteng impormasyon.
- Pagdugtong og token sa usa ka pirma, susama sa usa ka sertipiko.
Ang pag-verify naglakip sa pagsusi kung ang gilakip nga token gipirmahan ba sa OpenID provider ug pag-verify sa balido sa digital signature sa resource gamit ang public key. Kini nag-verify nga ang resource gipirmahan gamit ang identifier gikan sa certificate ug nga kini gikumpirma sa pirma sa OpenID provider. Pananglitan, ang usa ka signer mahimong makadawat og token nga gipirmahan sa Google OpenID provider nga nagpakita nga sila gi-verify isip bob@gmail.com ug naggamit sa public key nga 0x54A5...FF. Dayon, kung makadawat og mensahe nga gipirmahan sa parehas nga key, ang recipient mahimong mogamit sa token nga gipirmahan sa provider aron mapamatud-an nga ang key sa bob@gmail.com kay 0x54A5...FF ug nga ang mensahe gipirmahan gyud ni bob@gmail.com.
Ang pagpasimple sa arkitektura makab-ot pinaagi sa pipila ka mga tradeoff (sama sa pagsalig sa mga external nga OpenID provider ug ang kakulang sa change log nga adunay hierarchical hashing), nga madawat sa pipila ka mga sitwasyon ug dili sa uban. Aron makunhuran ang pagsalig sa mga OpenID provider, kansang kompromiso o mga aksyon sa ilang mga personahe mahimong makadaot sa sistema (pananglitan, kung ang usa ka hacker mokompromiso sa usa ka provider, mahimo silang mag-isyu og peke nga yawe sa usa ka ikatulo nga partido), gisugyot nga mogamit usa ka dugang, apan opsyonal, nga MFA-Cosigner (Multi-Factor Authentication Cosigner) alang sa multi-factor authentication (ang token kinahanglan nga pirmahan dili lamang sa panguna nga provider apan usab sa usa ka independente nga serbisyo sa authentication nga nag-verify sa tiggamit).
Laing kahuyang sa OpenPubKey mao ang presensya sa datos sa ikatulo nga partido nga magamit sa pagsubay sa kalihokan sa taas nga panahon, bisan pa sa pag-ilis sa ngalan (paggamit pag-usab sa usa ka identification token imbes nga usa ka bag-ong sertipiko). Ang direktang pagbugkos sa mga yawe sa OpenID Connect atol sa pag-verify nagwagtang sa panginahanglan alang sa usa ka server-side nga pagpatuman, apan labi nga nagpakomplikado sa pagpatuman sa client-side ug nagbilin ug dugang nga lugar alang sa maniobra kung moatake sa kliyente, pananglitan, tungod kay ang kliyente ang responsable sa pagtuyok sa yawe. Ang kakulang sa usa ka change log nagpugong sa kliyente sa pag-ila sa potensyal nga mga pagtulo sa yawe.
Source: opennet.ru
