Apa yang sebenarnya dilindungi frasa sandi pada kunci privat VPN

Prompt yang muncul saat klien VPN mulai mudah salah dibaca. Itu bukan kata sandi akun VPN, bukan kata sandi untuk tunnel, dan memasukkannya tidak membuktikan koneksi aman. Itu membuka satu representasi tersimpan dari kunci privat agar klien dapat membaca materi kunci dan memakainya untuk autentikasi. Semua yang terjadi setelahnya adalah pertanyaan lain.

Dalam praktik, jawabannya salah di tepi: orang menganggap frasa sandi melindungi tunnel yang berjalan, atau bahwa mengubahnya mencabut salinan kunci yang sudah bocor. Kedua anggapan gagal, dan keduanya gagal dengan cara yang membiarkan kredensial terbuka sementara operator percaya itu sudah ditangani.

Satu dialog, beberapa rahasia berbeda

Frasa sandi kunci privat mendekripsi file. Kata sandi akun mengautentikasi Anda ke layanan. Kata sandi impor PKCS#12 mendekripsi bundel yang berisi kunci dan sertifikatnya, dan mungkin bukan string yang sama dengan frasa sandi kunci itu sendiri. Prompt ini bisa terlihat hampir identik, dan menebak rahasia mana ke mana adalah cara kunci berakhir ditempel di kolom yang salah.

Enkripsi tunnel itu sendiri adalah hal keempat. Kanal data memakai kunci sesi yang dinegosiasikan selama handshake; frasa sandi kunci privat tidak berperan dalam melindungi paket individual. Jika seseorang dapat membaca file kunci, ia dapat mencoba menebak frasa sandi secara offline, tetapi jika ia dapat membaca paket, frasa sandi itu tidak relevan.

Apa yang dicakup enkripsi di disk

Kunci PEM terenkripsi hadir dalam dua bentuk, dan header memberi tahu Anda yang mana. Bentuk PKCS#8 modern dimulai dengan -----BEGIN ENCRYPTED PRIVATE KEY-----; bentuk PEM lama, masih umum di penyiapan OpenVPN lama, dimulai dengan -----BEGIN RSA PRIVATE KEY----- dan membawa Proc-Type: 4,ENCRYPTED dan baris DEK-Info tepat di bawahnya. File menyimpan kunci privat terenkripsi di bawah kunci yang diturunkan dari frasa sandi Anda, biasanya melalui KDF berbasis kata sandi dengan jumlah iterasi atau faktor kerja yang dinyatakan. Dokumentasi OpenSSL pkey mencakup format dan opsi frasa sandi yang berlaku saat membacanya.

Dua konsekuensi mengikuti. Frasa sandi lemah dapat diserang secara offline pada laju yang diizinkan KDF, jadi izin file dan akses cadangan tetap penting bahkan saat file terenkripsi. Dan penyerang yang hanya memperoleh file tanpa frasa sandi harus menebak; siapa pun yang memperoleh file dan frasa sandi memiliki kuncinya, persis seperti jika file itu tidak pernah dienkripsi.

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

head -3 menampilkan header dan, pada file lama, baris Proc-Type dan DEK-Info yang membuktikan enkripsi; satu baris saja bukan bukti ke arah mana pun. Baris pkey meminta frasa sandi dan hanya mencetak separuh publik, yang membuktikan file dan frasa sandi berfungsi tanpa mengekspos kunci privat. Jangan gunakan -text untuk pemeriksaan itu: perintah itu mencetak komponen privat, privateExponent, prime1, prime2 dan sisanya, dan keluaran itu tidak boleh pernah ditempel di mana pun, tidak di tiket, obrolan, atau log. Perintah PKCS#12 juga memberi tahu apakah bundel memiliki kata sandi MAC atau enkripsi terpisah, yang perlu diketahui sebelum Anda memberikannya kepada kolega.

Apa yang berhenti dilindungi setelah kunci dimuat

Membuka kunci adalah peristiwa satu arah bagi proses itu. Klien meminta kunci ke KDF, mendekripsi file, dan menyimpan kunci privat di memori selama diperlukan. Sejak saat itu frasa sandi tidak melindungi apa pun tentang sesi yang berjalan: bukan memori proses, bukan core dump, bukan sesi debugging yang terpasang ke klien, dan bukan cadangan mesin yang diambil saat kunci digunakan.

Ini adalah batas yang sama dengan kunci SSH berfrasa sandi, atau brankas pengelola kata sandi yang terbuka. Ini menaikkan biaya mencuri file dalam keadaan diam dan tidak melakukan apa pun terhadap malware yang berjalan sebagai pengguna Anda, aplikasi berwenang yang meminta klien menandatangani, atau administrator yang dapat membaca memori. Perlakukan ini sebagai satu lapisan, bukan sebagai kontrol yang membuat kunci aman ditinggalkan begitu saja.

Mengapa prompt terus kembali

Klien yang bertanya lagi pada setiap sambungan ulang belum tentu rusak. Beberapa klien menyimpan frasa sandi di cache untuk sesi, beberapa menyimpannya di keychain OS, dan beberapa dapat diarahkan ke helper yang menyediakannya, jadi perilaku yang Anda dapatkan bergantung pada klien dan konfigurasinya, bukan pada file kunci.

Jika prompt berulang adalah keluhan sebenarnya, periksa opsi caching dan autentikasi klien sebelum menghapus enkripsi dari kunci. Menghapus frasa sandi mengubah file yang dilindungi menjadi kunci teks biasa, dan sambungan ulang menjadi tenang dengan mengorbankan satu-satunya kontrol saat diam yang Anda miliki. Jawaban yang lebih baik biasanya adalah penyimpanan kredensial yang didukung dengan izin file yang sama seperti yang akan Anda gunakan.

Kehilangan dan paparan bukan perbaikan yang sama

Frasa sandi yang hilang tidak dapat dipulihkan dari sertifikat. Sertifikat adalah materi publik yang mengikat nama ke kunci; tidak ada jalur kembali ke kunci privat dan tidak ada petunjuk tentang frasa sandi. Pilihan praktisnya adalah cadangan kunci yang sah, atau identitas baru yang diterbitkan melalui proses normal operator. Siapa pun yang menawarkan 'memulihkan' frasa sandi menawarkan untuk menebaknya.

Paparan membutuhkan respons berbeda. Mengenkripsi ulang kunci yang sama dengan frasa sandi baru membiarkan materi kunci tidak berubah, jadi salinan yang sudah dibuka di tempat lain masih berfungsi. Perbaikannya adalah mencabut atau mengganti kredensial: terbitkan kunci dan sertifikat baru, distribusikan, dan pensiunkan yang lama di peer. Sampai itu terjadi, mengubah kata sandi file adalah pekerjaan rumah, bukan penahanan. Simpan file lama di luar cadangan hanya setelah identitas baru dipastikan berfungsi, dan catat nomor seri atau sidik jari mana yang menggantikannya.