Kva ein passfrase på ein privat VPN-nøkkel faktisk vernar

Ledeteksta som kjem når ein VPN-klient startar, er lett å lese feil. Det er ikkje passordet til VPN-kontoen, det er ikkje passordet for tunnelen, og å skrive det inn beviser ikkje at sambandet er trygt. Ho låser opp éin lagra representasjon av ein privatnøkkel slik at klienten kan lese nøkkelmaterialet og bruke det til autentisering. Alt som skjer etterpå, er eit anna spørsmål.

I praksis går svaret gale i kantane: folk trur passfråsa vernar den køyrande tunnelen, eller at endring av ho kallar tilbake ein kopi av nøkkelen som alt er lekt. Begge føresetnadene sviktar, og begge sviktar på måtar som lèt ein legitimasjon liggje open medan operatøren trur han er handsama.

Éin dialog, fleire ulike løyndomar

Ei passfråse for ein privatnøkkel dekrypterer ei fil. Eit kontopassord autentiserer deg mot ei teneste. Eit PKCS#12-importpassord dekrypterer ein pakke som inneheld ein nøkkel og sertifikatet hans, og det er kanskje ikkje same strengen som passfråsa til nøkkelen sjølv. Desse ledetekstene kan sjå nesten identiske ut, og å gjette kva løyndom som høyrer kvar er korleis nøklar endar opp limte inn i feil felt.

Krypteringa av sjølve tunnelen er ein fjerde ting. Datakanalen brukar sesjonsnøklar som blir forhandla under handtrykket; passfråsa til privatnøkkelen spelar inga rolle for å verne enkeltpakkar. Viss nokon kan lese nøkkelfila, kan dei prøve å gjette passfråsa offline, men viss dei kan lese pakkar, er passfråsa irrelevant.

Kva krypteringa på disken dekkjer

Ein kryptert PEM-nøkkel kjem i to former, og headeren fortel deg kva du har. Den moderne PKCS#8-forma byrjar med -----BEGIN ENCRYPTED PRIVATE KEY-----; den eldre PEM-forma, framleis vanleg i eldre OpenVPN-oppsett, byrjar med -----BEGIN RSA PRIVATE KEY----- og ber Proc-Type: 4,ENCRYPTED og ei DEK-Info-linje rett under. Fila held privatnøkkelen kryptert under ein nøkkel som er utleia frå passfråsa di, vanlegvis via ein passordbasert KDF med eit oppgitt tal på iterasjonar eller arbeidsfaktor. OpenSSL pkey-dokumentasjonen dekkjer formata og passfråsevala som gjeld når du les ein.

To følgjer kjem av dette. Ei svak passfråse kan angripast offline med den farten KDF-en tillèt, så filrettar og tilgang til tryggleikskopiar er framleis viktige sjølv når fila er kryptert. Og ein angripar som berre får fila utan passfråsa, må gjette; den som får både fila og passfråsa, har nøkkelen, akkurat som om han aldri hadde vore kryptert.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 viser headeren og, på ei eldre fil, linjene Proc-Type og DEK-Info som beviser kryptering; éi linje åleine er ikkje bevis i noka retning. Linja pkey spør etter passfråsa og skriv berre ut den offentlege halvdelen, noko som beviser at fila og passfråsa fungerer utan å avsløre privatnøkkelen. Ikkje bruk -text til den kontrollen: han skriv ut dei private komponentane, privateExponent, prime1, prime2 og resten, og den utskrifta må aldri limast inn nokon stad, verken i ein sak, ein chat eller ein logg. PKCS#12-kommandoen fortel deg òg om pakken har eit separat MAC- eller krypteringspassord, noko det er greitt å vite før du gir han til ein kollega.

Kva han sluttar å verne når nøkkelen er lasta

Opplåsing er ei einvegshending for den prosessen. Klienten ber KDF-en om nøkkelen, dekrypterer fila og held privatnøkkelen i minnet så lenge han treng han. Frå det augeblikket vernar passfråsa ingenting ved den køyrande sesjonen: ikkje prosessminnet, ikkje ein kjernedump, ikkje ein feilsøkingssesjon knytt til klienten, og ikkje ein tryggleikskopi av maskinen teken medan nøkkelen var i bruk.

Dette er same grensa som ein SSH-nøkkel med passfråse, eller eit opplåst kvelv i ein passordhandsamar. Det aukar kostnaden ved å stele fila i ro og gjer ingenting mot skadeleg programvare som køyrer som brukaren din, ein autorisert applikasjon som ber klienten signere, eller ein administrator som kan lese minne. Handsame det som eitt lag, ikkje som kontrollen som gjer ein nøkkel trygg å la liggje.

Kvifor ledeteksta fortset å kome tilbake

Ein klient som spør igjen ved kvar gjenoppkopling er ikkje nødvendigvis øydelagd. Nokre klientar bufrer passfråsa for sesjonen, nokre lagrar ho i OS-nøkkelringen, og nokre kan peikast på ein hjelpar som leverer ho, så kva åtferd du får, avheng av klienten og konfigurasjonen hans, ikkje av nøkkelfila.

Viss den gjentatte ledeteksta er den eigenlege klaga, undersøk bufrings- og autentiseringsvala til klienten før du fjernar krypteringa frå nøkkelen. Å fjerne passfråsa gjer ei verna fil om til ein klartekstnøkkel, og gjenoppkoplinga blir stille på kostnad av den einaste ro-kontrollen du hadde. Eit betre svar er vanlegvis eit støtta legitimasjonslager med dei same filrettane du uansett ville brukt.

Tap og eksponering er ikkje same reparasjon

Ei tapt passfråse kan ikkje gjenopprettast frå sertifikatet. Sertifikatet er offentleg materiale som bind eit namn til ein nøkkel; det inneheld ingen veg tilbake til privatnøkkelen og inga antyding om passfråsa. Dei praktiske alternativa er ein autorisert tryggleikskopi av nøkkelen, eller ein ny identitet utstedt gjennom den normale prosessen til operatøren. Alle som tilbyr å 'gjenopprette' passfråsa, tilbyr å gjette ho.

Eksponering krev eit anna svar. Å kryptere den same nøkkelen på nytt med ei ny passfråse lèt nøkkelmaterialet vere uendra, så ein kopi som alt er låst opp ein annan stad, fungerer framleis. Reparasjonen er å kalle tilbake eller erstatte legitimasjonen: utsted ein ny nøkkel og eit nytt sertifikat, distribuer dei, og pensjoner den gamle hos motparten. Inntil det skjer, er endring av filpassordet husarbeid, ikkje inndemming. Hald den gamle fila ute av tryggleikskopiar berre etter at den nye identiteten er stadfesta å fungere, og noter kva serienummer eller fingeravtrykk som erstatta han.