Ce protejează de fapt o frază de acces pe o cheie privată VPN

Promptul care apare la pornirea unui client VPN este ușor de citit greșit. Nu este parola contului VPN, nu este parola tunelului, iar introducerea ei nu dovedește că conexiunea este sigură. Acesta deblochează o reprezentare stocată a unei chei private pentru ca clientul să poată citi materialul cheii și să îl folosească pentru autentificare. Tot ce se întâmplă după aceea este o altă întrebare.

În practică, răspunsul se strică la margini: oamenii presupun că fraza de acces protejează tunelul care rulează sau că schimbarea ei revocă o copie a cheii care s-a scurs deja. Ambele presupuneri eșuează, și eșuează în așa fel încât o acreditare rămâne expusă în timp ce operatorul crede că a fost rezolvată.

Un dialog, mai multe secrete diferite

O frază de acces a cheii private descifrează un fișier. O parolă de cont vă autentifică la un serviciu. O parolă de import PKCS#12 descifrează un pachet care conține o cheie și certificatul ei, și poate să nu fie același șir ca fraza de acces a cheii. Aceste prompturi pot arăta aproape identic, iar ghicirea secretului care merge unde este modul în care cheile ajung lipite în câmpul greșit.

Criptarea tunelului în sine este un al patrulea lucru. Canalul de date folosește chei de sesiune negociate în timpul strângerii de mână; fraza de acces a cheii private nu are niciun rol în protejarea pachetelor individuale. Dacă cineva poate citi fișierul cheii, poate încerca să ghicească fraza offline, dar dacă poate citi pachete, fraza este irelevantă.

Ce acoperă criptarea pe disc

O cheie PEM criptată are două forme, iar antetul vă spune care este. Forma modernă PKCS#8 începe cu -----BEGIN ENCRYPTED PRIVATE KEY-----; forma PEM veche, încă obișnuită în instalările OpenVPN mai vechi, începe cu -----BEGIN RSA PRIVATE KEY----- și poartă Proc-Type: 4,ENCRYPTED și o linie DEK-Info imediat dedesubt. Fișierul păstrează cheia privată criptată sub o cheie derivată din fraza dumneavoastră, de obicei printr-un KDF bazat pe parolă cu un număr de iterații sau un factor de muncă declarat. Documentația OpenSSL pkey acoperă formatele și opțiunile de frază care se aplică la citire.

Urmează două consecințe. O frază slabă poate fi atacată offline la viteza pe care o permite KDF, așa că permisiunile fișierului și accesul la copiile de siguranță rămân importante chiar și când fișierul este criptat. Iar un atacator care obține doar fișierul fără frază trebuie să ghicească; cel care obține fișierul și fraza are cheia, exact ca și cum nu ar fi fost niciodată criptată.

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

head -3 arată antetul și, pe un fișier vechi, liniile Proc-Type și DEK-Info care dovedesc criptarea; o singură linie nu este dovadă în niciun sens. Linia pkey cere fraza și tipărește doar jumătatea publică, ceea ce dovedește că fișierul și fraza funcționează fără a expune cheia privată. Nu folosiți -text pentru acea verificare: tipărește componentele private, privateExponent, prime1, prime2 și restul, iar acea ieșire nu trebuie lipită niciodată nicăieri, nici într-un tichet, nici într-un chat, nici într-un jurnal. Comanda PKCS#12 vă spune și dacă pachetul are o parolă MAC sau de criptare separată, ceea ce merită știut înainte de a-l da unui coleg.

Ce nu mai protejează după ce cheia este încărcată

Deblocarea este un eveniment unidirecțional pentru acel proces. Clientul cere cheia de la KDF, descifrează fișierul și păstrează cheia privată în memorie atât timp cât are nevoie. Din acel moment fraza nu mai protejează nimic din sesiunea care rulează: nici memoria procesului, nici un dump de nucleu, nici o sesiune de depanare atașată clientului, nici o copie de siguranță a mașinii făcută în timp ce cheia era în uz.

Aceasta este aceeași limită ca o cheie SSH cu frază sau seiful deblocat al unui manager de parole. Crește costul furtului fișierului în repaus și nu face nimic împotriva programelor răuvoitoare care rulează ca utilizatorul dumneavoastră, a unei aplicații autorizate care cere clientului să semneze, sau a unui administrator care poate citi memoria. Tratați-o ca un strat, nu ca mecanismul care face o cheie sigură de lăsat în jur.

De ce promptul revine mereu

Un client care întreabă din nou la fiecare reconectare nu este neapărat stricat. Unii clienți memorează fraza pentru sesiune, alții o stochează în brelocul cu chei al sistemului de operare, iar alții pot fi îndreptați către un ajutor care o livrează, așa că comportamentul depinde de client și de configurația sa, nu de fișierul cheii.

Dacă promptul repetat este reclamația reală, verificați opțiunile de memorare și autentificare ale clientului înainte de a elimina criptarea din cheie. Eliminarea frazei transformă un fișier protejat într-o cheie în text simplu, iar reconectarea devine silențioasă cu costul singurului control în repaus pe care îl aveați. Un răspuns mai bun este de obicei un depozit de acreditări acceptat, cu aceleași permisiuni de fișier pe care le-ați fi folosit oricum.

Pierderea și expunerea nu sunt aceeași reparație

O frază pierdută nu poate fi recuperată din certificat. Certificatul este material public care leagă un nume de o cheie; nu conține nicio cale înapoi la cheia privată și niciun indiciu despre frază. Opțiunile practice sunt o copie de siguranță autorizată a cheii sau o identitate nouă emisă prin procesul normal al operatorului. Oricine oferă să 'recupereze' fraza oferă să o ghicească.

Expunerea necesită un alt răspuns. Recríptarea aceleiași chei cu o frază nouă lasă materialul cheii neschimbat, așa că o copie care a fost deja deblocată în altă parte funcționează în continuare. Reparația este revocarea sau înlocuirea acreditării: emiteți o cheie și un certificat noi, distribuiți-le și retrageți-o pe cea veche la partener. Până atunci, schimbarea parolei fișierului este treabă casnică, nu izolare. Țineți fișierul vechi în afara copiilor de siguranță doar după confirmarea că noua identitate funcționează, și notați ce număr de serie sau amprentă a înlocuit-o.