Kodetoken, smartkort eller FIDO-nøkkel: kva ein VPN godtek

Tre einingar med same kontakt og same nøkkelring deltek i tre urelaterte utvekslingar. Éin viser ein kode som ein tenar kontrollerer, éin signerer med ein nøkkel som aldri forlèt eininga, og éin godkjenner ei nettlesarinnlogging gjennom sin eigen protokoll. Difor samanliknar spørsmålet om eit VPN bør bruke sertifikat eller maskinvarebrikker eit format med ein einingklasse. Svaret avheng av kva av dei tre du faktisk kjøpte.

Namngje beviset før eininga

Ein eingongskodebrikke lagar ein verdi som ein autentiseringsteneste validerer gjennom sin eigen mekanisme. VPN-et kan nå den tenesta via RADIUS eller ein føderert identitetsleverandør, og brikka treng aldri å halde noko som høyrer til sjølve tunnelen. Det ho beviser, er at personen har eininga som genererer koden. Det beviser ingenting om maskinen koden vart skriven inn på.

Ei brikke i smartkortstil lagrar ein privat nøkkel og utfører signeringsoperasjonen på førespurnad, og det er slik ein sertifikatidentitet vert prova utan å eksportere nøkkelen. Sertifikatet ved sida av er offentleg materiale, og å gje ut det sertifikatet er ei heilt anna handling enn å gje ut nøkkelen.

Ein FIDO-nøkkel snakkar igjen ein tredje protokoll. Ei nettlesarinnlogging kan bruke han hos identitetsleverandøren, men suksess på den nettstaden tyder ikkje at den same nøkkelen vil dukke opp gjennom smartkortgrensesnittet til ein VPN-klient.

Nokre einingar implementerer fleire av desse applikasjonane side om side, og leverandørdokumentasjonen listar nettopp difor opp modusane kvar for seg. Det er ikkje bevis for at kvar nøkkel på marknaden støttar kvar modus.

Maskinvaren vernar nøkkelen, ikkje policyen

Ein PIN på ei sertifikatbasert eining autoriserer vanlegvis lokal bruk av nøkkelen, og han er ikkje passordet som VPN-kontosystemet kontrollerer. Retningslinjer som NIST sine retningslinjer om autentikatorar kallar den lokale inntastinga ein aktiveringsløyndom, skild frå autentikatoren sjølv. Tryggleiken kjem frå heile designet, ikkje frå talet på spørsmål på skjermen.

Registrering, fornying og fjerning vert verande hos identitetseigaren uansett. Nokon bestemmer framleis kven som kan registrerast, bind legitimasjonen til rett person og gjer utskifting mogleg når ei eining vert mista. Å kjøpe ein ny nøkkel kallar ikkje attende den gamle.

Skildre innloggingsseremonien før du vel maskinvare: skriv brukaren ein kode, låser opp ein signeringsnøkkel eller godkjenner ein nettlesarførespurnad? Kvart svar inneber ein annan klient, ei anna gateway-innstilling og eit anna manus for brukarstøtta.

Kvar flytane skil seg i praksis

Ei kodebrikke er enklast å rulle ut og svakast mot ei overtydande etterlikningsside, fordi ein inntasta kode kan vidaresendast i sanntid. Ein sertifikatbasert nøkkel motstår den åtaksklassen og kostar meir å drifte, sidan utgiving og tilbakekalling vert ein del av tenesta. Ein FIDO-nøkkel høyrer til nettinnlogginga og avheng heilt av om identitetsleverandøren støttar han for denne applikasjonen.

Blanda miljø er vanlege, og dei er ikkje automatisk feil: eit sertifikat for tunnelen pluss ei kodebrikke for administrasjonskonsollen er ei samanhengande deling, føresett at begge er registrerte mot same identitet. Det som bryt, er ei deling ingen har dokumentert, der brukarstøtta ikkje kan seie kva faktor ein brukar manglar.

Gjer avgjerda konkret

Skriv ned seremonien som ein sekvens av trinn ein ekte brukar utfører, og kontroller deretter at klienten, gatewayen og identitetsleverandøren alle støttar den sekvensen. Eit avvik viser seg vanlegvis i det siste trinnet, der klienten ikkje kan adressere eininga i det heile.

Stadfest deretter kva som skjer når eininga vert mista eller sertifikatet går ut. Viss svaret ikkje er skrive ned, har utrullinga eit hol som vil verte oppdaga ein måndag morgon.

pkcs11-tool --list-slots
pkcs11-tool --list-objects --type cert