Ano ang talagang pinoprotektahan ng passphrase sa isang private key ng VPN

Ang prompt na lumalabas kapag nagsimula ang isang VPN client ay madaling mabasa nang mali. Hindi ito ang password ng VPN account, hindi ito ang password ng tunnel, at ang paglalagay nito ay hindi nagpapatunay na secure ang koneksyon. Binubuksan nito ang isang naka-store na representasyon ng isang private key para mabasa ng client ang key material at magamit ito sa authentication. Ang lahat ng nangyayari pagkatapos ay ibang tanong.

Sa practice, nagkakamali ang sagot sa mga gilid: inaakala ng mga tao na pinoprotektahan ng passphrase ang tumatakbong tunnel, o na ang pagpapalit nito ay nagre-revoke ng kopya ng key na tumagas na. Parehong mali ang assumptions, at parehong nagkakamali sa paraang nag-iiwan ng credential na nakalantad habang iniisip ng operator na naayos na ito.

Isang dialog, ilang magkaibang secret

Ang passphrase ng private key ay nagde-decrypt ng file. Ang password ng account ay nagpapatunay sa iyo sa isang serbisyo. Ang password ng PKCS#12 import ay nagde-decrypt ng bundle na naglalaman ng key at certificate nito, at maaaring hindi ito ang parehong string ng passphrase ng key mismo. Ang mga prompt na ito ay maaaring halos magkapareho, at ang paghula kung aling secret ang pupunta saan ang dahilan kung bakit napupunta ang mga key sa maling field.

Ang encryption ng tunnel mismo ay ikaapat na bagay. Gumagamit ang data channel ng session keys na napagkasunduan sa handshake; walang papel ang passphrase ng private key sa pagprotekta sa mga indibidwal na packet. Kung may makabasa ng key file, maaari siyang magtangkang hulaan ang passphrase offline, pero kung makabasa siya ng packet, walang kinalaman ang passphrase.

Ano ang sakop ng encryption sa disk

Ang naka-encrypt na PEM key ay may dalawang anyo, at sinasabi ng header kung alin ang mayroon ka. Ang modernong PKCS#8 form ay nagsisimula sa -----BEGIN ENCRYPTED PRIVATE KEY-----; ang lumang PEM form, na karaniwan pa rin sa mas lumang OpenVPN setup, ay nagsisimula sa -----BEGIN RSA PRIVATE KEY----- at may Proc-Type: 4,ENCRYPTED at isang linya ng DEK-Info sa ilalim nito. Ang file ay naglalaman ng private key na naka-encrypt sa ilalim ng key na hinango sa iyong passphrase, karaniwang sa pamamagitan ng password-based KDF na may nakasaad na bilang ng iteration o work factor. Sinasaklaw ng dokumentasyon ng OpenSSL pkey ang mga format at opsyon sa passphrase na naaangkop kapag nagbabasa.

Dalawang kahihinatnan ang sumusunod. Ang mahinang passphrase ay maaaring atakihin offline sa bilis na pinapayagan ng KDF, kaya mahalaga pa rin ang mga permiso ng file at access sa backup kahit naka-encrypt ang file. At ang attacker na nakakuha lamang ng file nang walang passphrase ay kailangang maghula; ang nakakuha ng file at passphrase ay may key, na parang hindi ito na-encrypt kailanman.

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

head -3 ay nagpapakita ng header at, sa lumang file, ang mga linyang Proc-Type at DEK-Info na nagpapatunay ng encryption; ang isang linya lamang ay hindi ebidensya sa alinmang direksyon. Ang linyang pkey ay humihingi ng passphrase at nagpi-print lamang ng public half, na nagpapatunay na gumagana ang file at passphrase nang hindi inilalantad ang private key. Huwag gamitin ang -text para sa check na iyon: nagpi-print ito ng mga private component, privateExponent, prime1, prime2 at iba pa, at ang output na iyon ay hindi dapat i-paste kahit saan, hindi sa ticket, chat o log. Sinasabi rin ng PKCS#12 command kung may hiwalay na MAC o encryption password ang bundle, na dapat mong malaman bago ibigay ito sa isang kasamahan.

Ano ang tinatanggihan nitong protektahan kapag na-load na ang key

Ang pag-unlock ay isang one-way na pangyayari para sa prosesong iyon. Hinihingi ng client ang key sa KDF, dine-decrypt ang file, at pinapanatili ang private key sa memory hangga't kailangan. Mula sa sandaling iyon, wala nang pinoprotektahan ang passphrase sa tumatakbong session: hindi ang memory ng proseso, hindi ang core dump, hindi ang debugging session na nakakabit sa client, at hindi ang backup ng machine na kinuha habang ginagamit ang key.

Ito ang parehong hangganan ng isang SSH key na may passphrase, o ng naka-unlock na vault ng password manager. Pinapataas nito ang gastos ng pagnanakaw ng file habang nakapahinga at wala itong ginagawa laban sa malware na tumatakbo bilang iyong user, isang authorized application na humihingi sa client na mag-sign, o isang administrator na makabasa ng memory. Ituring itong isang layer, hindi ang control na nagpapasiguro na safe iwanan ang key.

Bakit bumabalik ang prompt

Ang client na muling nagtatanong sa bawat reconnect ay hindi laging sira. Ang ilang client ay nag-ca-cache ng passphrase para sa session, ang iba ay nag-iimbak nito sa keychain ng OS, at ang iba ay maaaring ituro sa isang helper na nagbibigay nito, kaya ang behavior na makukuha mo ay nakadepende sa client at sa configuration nito, hindi sa key file.

Kung ang paulit-ulit na prompt ang tunay na reklamo, suriin ang caching at authentication options ng client bago tanggalin ang encryption sa key. Ang pag-alis ng passphrase ay ginagawang plaintext key ang protektadong file, at tatahimik ang reconnect kapalit ng tanging at-rest control na mayroon ka. Ang mas mabuting sagot ay karaniwang isang suportadong credential store na may parehong file permissions na gagamitin mo rin naman.

Ang pagkawala at paglantad ay hindi parehong pag-aayos

Ang nawalang passphrase ay hindi maibabalik mula sa certificate. Ang certificate ay public material na nag-uugnay ng pangalan sa isang key; wala itong daan pabalik sa private key at walang palatandaan tungkol sa passphrase. Ang praktikal na opsyon ay isang awtorisadong backup ng key, o isang bagong identity na inisyu sa normal na proseso ng operator. Sinumang nag-aalok na 'i-recover' ang passphrase ay nag-aalok na hulaan ito.

Ang paglantad ay nangangailangan ng ibang tugon. Ang muling pag-encrypt ng parehong key gamit ang bagong passphrase ay hindi binabago ang key material, kaya gumagana pa rin ang kopyang na-unlock na sa ibang lugar. Ang pag-aayos ay i-revoke o palitan ang credential: mag-isyu ng bagong key at certificate, ipamahagi, at i-retire ang luma sa peer. Hanggang mangyari iyon, ang pagpapalit ng file password ay housekeeping, hindi containment. Itago ang lumang file sa labas ng backup pagkatapos lamang kumpirmahing gumagana ang bagong identity, at itala kung aling serial o fingerprint ang pumalit dito.