Kodtoken, smartkort eller FIDO-nyckel: vad en VPN accepterar

Tre enheter med samma kontakt och samma nyckelring deltar i tre orelaterade utbyten. En visar en kod som en server kontrollerar, en signerar med en nyckel som aldrig lämnar enheten, och en godkänner en webbläsarinloggning via ett eget protokoll. Därför jämför frågan om en VPN ska använda certifikat eller hårdvarutoken ett format med en enhetsklass. Svaret beror på vilken av de tre du faktiskt köpte.

Namnge beviset före enheten

En engångskodtoken skapar ett värde som en autentiseringstjänst validerar genom sin egen mekanism. VPN kan nå den tjänsten via RADIUS eller en federerad identitetsleverantör, och token behöver aldrig innehålla något som tillhör själva tunneln. Det den bevisar är att personen har enheten som genererar koden. Det bevisar ingenting om maskinen som koden skrevs in på.

En token i smartkortsstil lagrar en privat nyckel och utför signeringsoperationen på begäran, och det är så en certifikatidentitet bevisas utan att nyckeln exporteras. Certifikatet bredvid är offentligt material, och att lämna ut det certifikatet är en helt annan handling än att lämna ut nyckeln.

En FIDO-nyckel talar återigen ett tredje protokoll. En webbläsarinloggning kan använda den hos identitetsleverantören, men framgång på den webbplatsen betyder inte att samma nyckel dyker upp via smartkortsgränssnittet i en VPN-klient.

Vissa enheter implementerar flera av dessa applikationer sida vid sida, och leverantörens dokumentation listar lägena separat just därför. Det är inte bevis för att varje nyckel på marknaden stöder varje läge.

Hårdvaran skyddar nyckeln, inte policyn

En PIN-kod på en certifikatbaserad enhet auktoriserar vanligtvis lokal användning av nyckeln, och det är inte lösenordet som VPN-kontosystemet kontrollerar. Riktlinjer som NIST:s riktlinjer om autentiserare kallar den lokala inmatningen en aktiveringshemlighet, skild från autentiseraren själv. Tryggheten kommer från hela designen, inte från antalet frågor på skärmen.

Registrering, förnyelse och borttagning stannar hos identitetsägaren oavsett. Någon avgör fortfarande vem som får registrera sig, binder legitimationen till rätt person och gör utbyte möjligt när en enhet tappas bort. Att köpa en ny nyckel återkallar inte den gamla.

Beskriv inloggningsceremonin innan du väljer hårdvara: skriver användaren en kod, låser upp en signeringsnyckel eller godkänner en webbläsarfråga? Varje svar innebär en annan klient, en annan gateway-inställning och ett annat manus för supporten.

Var flödena skiljs åt i praktiken

En kodtoken är enklast att rulla ut och svagast mot en övertygande förfalskad sida, eftersom en inskriven kod kan vidarebefordras i realtid. En certifikatbaserad nyckel står emot den attackklassen och kostar mer att driva, eftersom utfärdande och återkallelse blir en del av tjänsten. En FIDO-nyckel hör till webbinloggningen och beror helt på om identitetsleverantören stöder den för den här applikationen.

Blandade miljöer är vanliga och inte automatiskt fel: ett certifikat för tunneln plus en kodtoken för administratörskonsolen är en sammanhängande uppdelning, förutsatt att båda är registrerade mot samma identitet. Det som brister är en uppdelning som ingen dokumenterat, där supporten inte kan säga vilken faktor en användare saknar.

Gör beslutet konkret

Skriv ned ceremonin som en sekvens av steg som en riktig användare utför, och kontrollera sedan att klienten, gatewayen och identitetsleverantören alla stöder den sekvensen. En avvikelse visar sig oftast i det sista steget, där klienten inte alls kan adressera enheten.

Bekräfta sedan vad som händer när enheten tappas bort eller certifikatet löper ut. Om svaret inte är nedskrivet har utrullningen en lucka som upptäcks en måndagsmorgon.

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