Private Key Adalah: Fungsi, Cara Kerja & Cara Menjaganya

Hampir semua sistem yang kita pakai sehari-hari mengandalkan password. Satu rahasia, diketahui dua pihak, lalu dicocokkan setiap kali Anda masuk. Cara ini bekerja selama rahasia tersebut tidak pernah bocor di perjalanan. Persoalan muncul ketika dua pihak belum pernah bertemu, tetapi harus menyepakati rahasia lewat jaringan yang bisa disadap siapa saja.

Kriptografi kunci publik menyelesaikan persoalan itu dengan cara yang berbeda. Alih-alih satu rahasia bersama, setiap pihak memegang sepasang kunci yang saling terkait secara matematis. Satu kunci boleh disebar sebebas-bebasnya, satunya lagi disimpan rapat dan tidak pernah dikirim ke mana pun. Private key adalah kunci kedua tersebut — dan seluruh keamanan sertifikat SSL, akses server, sampai dompet kripto Anda bertumpu padanya.

Apa Itu Private Key?

Private key adalah bilangan rahasia berukuran sangat besar yang dihasilkan secara acak, dan menjadi pasangan tak terpisahkan dari sebuah public key (kunci publik). Keduanya lahir bersamaan dalam satu proses, lalu berpisah peran: kunci publik dibagikan ke siapa saja, sementara private key tidak pernah meninggalkan perangkat pemiliknya.

Dalam bahasa Indonesia, istilah ini sering diterjemahkan menjadi kunci privat, kunci pribadi, atau kunci rahasia. Sebagian dokumentasi berbahasa Inggris juga menyebutnya secret key. Semuanya merujuk pada benda yang sama, jadi Anda tidak perlu bingung saat menemui variasi penamaannya.

Yang membuat pasangan ini berguna adalah sifat satu arahnya. Menurunkan kunci publik dari private key hanya butuh sepersekian detik. Menghitung arah sebaliknya membutuhkan waktu yang secara praktis tidak terjangkau. Sifat inilah yang membuat kunci publik aman dipajang di mana pun.

Konsep kunci berpasangan ini adalah bagian dari enkripsi asimetris. Lawannya adalah enkripsi simetris, yang memakai satu kunci sama untuk mengunci dan membuka.

Cara Kerja Sepasang Kunci yang Hanya Bisa Searah

Pasangan kunci punya dua mode kerja, dan keduanya hanya berjalan satu arah. Mode pertama adalah untuk kerahasiaan. Siapa pun yang punya kunci publik Anda bisa mengunci sebuah pesan, tetapi hanya private key Anda yang bisa membukanya kembali.

Pesan dikunci memakai kunci publik penerima, melintas dalam keadaan teracak, lalu dibuka oleh private key penerima.

Perhatikan bahwa pengirim tidak pernah membutuhkan private key siapa pun. Ia cukup memegang kunci publik tujuan, dan itulah sebabnya dua pihak yang belum pernah bertukar rahasia tetap bisa berkomunikasi dengan aman.

Mode kedua berjalan berlawanan arah, dan tujuannya bukan kerahasiaan melainkan pembuktian identitas. Anda memakai private key untuk membubuhkan digital signature (tanda tangan digital) pada sepotong data. Siapa pun kemudian bisa memeriksa tanda tangan itu memakai kunci publik Anda.

Data ditandatangani private key pengirim, lalu diperiksa memakai kunci publik untuk membuktikan identitas pengirim.

Hasil pemeriksaan ini memberi dua kepastian sekaligus. Pertama, data benar-benar berasal dari pemegang private key tersebut. Kedua, isinya tidak berubah sedikit pun sejak ditandatangani, karena perubahan satu karakter saja membuat tanda tangannya gagal cocok.

Fungsi Private Key: Membuka Kiriman dan Menandatangani Identitas

Dari dua mode kerja di atas, fungsi private key bisa diringkas menjadi dua kalimat. Ia membuka kiriman yang dikunci dengan kunci publik pasangannya, dan ia membuat tanda tangan digital yang membuktikan bahwa Anda memang Anda.

Di sinilah satu kekeliruan yang sering beredar perlu diluruskan. Banyak penjelasan menyebut private key berfungsi "mengenkripsi data". Kenyataannya terbalik: yang mengunci adalah kunci publik, dan private key yang membuka. Menandatangani memang secara matematis mirip mengenkripsi, tetapi hasilnya bukan kerahasiaan — siapa pun bisa membaca data yang ditandatangani.

Perbedaan ini bukan soal istilah semata. Kalau Anda mengira private key bertugas mengunci data keluar, Anda akan salah menduga akibat kebocorannya. Kunci yang bocor tidak membuat kiriman lama Anda otomatis terbaca. Yang jauh lebih berbahaya, orang lain kini bisa menyamar sebagai Anda dan menandatangani apa pun atas nama Anda.

Fungsi penandatanganan ini bekerja lebih luas daripada yang biasanya disadari. Sertifikat SSL memakainya untuk membuktikan identitas server, DKIM untuk membuktikan asal email, dan blockchain untuk membuktikan siapa yang berhak memindahkan aset.

Di HTTPS modern, kunci privat server tidak membuka apa pun

Contoh paling jelas ada di HTTPS. Pada TLS versi lama, browser mengunci sebuah bahan kunci memakai kunci publik server, lalu server membukanya dengan private key. Di sana private key memang bertugas mendekripsi.

Perilaku itu sudah dihapus. Spesifikasi TLS 1.3 membuang seluruh cipher suite berbasis static RSA dan Diffie-Hellman. Semua mekanisme pertukaran kunci kini wajib memberikan forward secrecy, yaitu kerahasiaan yang tetap terjaga meski kunci server bocor di kemudian hari. Kunci sesi dihitung dari pertukaran sementara antara kedua pihak, bukan dikirim dalam keadaan terkunci.

Akibatnya, private key server hari ini hanya punya satu pekerjaan di dalam handshake TLS: menandatangani seluruh percakapan pembuka lewat pesan CertificateVerify. Ia tidak menyentuh data pengunjung sama sekali. Server membuktikan identitas, bukan membuka amplop.

Tiga Tempat Anda Akan Bertemu Private Key

Private key kerap terasa seperti tiga benda berbeda karena muncul di tiga dunia dengan kosakata yang berlainan. Padahal aturan matematisnya identik; yang berbeda hanya apa yang ditandatangani dan seberapa fatal akibatnya bila hilang.

Dua baris pertama adalah wilayah pemilik website. Saat Anda memesan sertifikat SSL, private key lahir di server Anda dan tidak pernah dikirim ke penerbit sertifikat. Saat Anda mengatur akses SSH, private key tinggal di laptop Anda dan hanya kunci publiknya yang diunggah ke server.

Tiga kartu sejajar: ikon sertifikat bergembok, jendela terminal, dan dompet, sebagai tiga tempat private key dipakai.

Baris ketiga bekerja dengan prinsip sama, hanya dibungkus istilah berbeda. Frasa 12 atau 24 kata yang diminta dompet kripto bukan password, melainkan bahan untuk menurunkan private key Anda. Kunci Bitcoin sendiri hanyalah bilangan bulat 256 bit antara 1 dan hampir 2 pangkat 256. Itu sekitar 10 pangkat 77 kemungkinan, angka yang membuat penebakan acak sia-sia belaka.

Perbedaan terpenting antar ketiganya ada di kolom terakhir. Kunci SSL dan SSH bisa dibuat ulang kapan saja, sebab identitas Anda dijamin pihak lain — penerbit sertifikat dan penyedia server. Kunci dompet kripto tidak punya penjamin semacam itu, sehingga kehilangannya bersifat mutlak.

Mengenali Berkas Private Key dari Baris Pertamanya

Private key hampir selalu disimpan sebagai berkas teks biasa. Ekstensinya beragam dan tidak konsisten — Anda akan menemui .key, .pem, .ppk, atau bahkan tanpa ekstensi sama sekali seperti id_ed25519. Karena itu, cara paling andal mengenalinya bukan dari nama berkas, melainkan dari baris pertama isinya.

Satu hal yang sering membuat bingung: perintah yang sama bisa memberi label berbeda tergantung versi alatnya. Pada OpenSSL 1.x, openssl genrsa menghasilkan berkas berlabel BEGIN RSA PRIVATE KEY. Pada OpenSSL 3.x, perintah yang persis sama menghasilkan BEGIN PRIVATE KEY. Isinya tetap kunci RSA yang valid, hanya pembungkusnya yang berpindah ke PKCS#8.

Jadi kalau berkas Anda tidak berlabel sama dengan tutorial yang sedang diikuti, jangan buru-buru menganggapnya rusak. Penjelasan lebih dalam soal struktur berkas ini dan cara mengonversinya ada di pembahasan format PEM.

Di mana berkasnya tersimpan

Lokasinya cukup baku, sehingga Anda tidak perlu menyisir seluruh server:

Baris terakhir perlu perhatian khusus bagi pengguna Windows. PuTTY memakai format kuncinya sendiri berekstensi .ppk, yang tidak bisa langsung dipakai server Linux dan sebaliknya. Konversinya dilakukan lewat PuTTYgen, dan langkahnya kami uraikan di pembahasan PuTTY.

Berapa Panjang Private Key yang Dianggap Aman

Pertanyaan ini paling sering muncul saat seseorang harus mengisi kolom "key size" dan tidak tahu harus memilih apa. Jawabannya bukan "semakin besar semakin baik", karena kunci yang lebih panjang membebani setiap koneksi baru.

NIST mengukur kekuatan kunci dalam satuan security bits, bukan panjang kunci mentahnya. Ukuran inilah yang membuat kunci dari algoritma berbeda bisa dibandingkan secara adil.

Perhatikan bahwa RSA 3072 dan Ed25519 sama-sama memberi 128 bit kekuatan, tetapi ukuran berkasnya berbeda jauh. Kami mengukurnya sendiri dengan ssh-keygen pada OpenSSH 10.3:

Ukuran berkas kunci SSH: Ed25519 432 byte dan RSA 4096 3.401 byte, padahal kekuatannya sama-sama 128 bit.

Selisih Ed25519 dan RSA 4096 mencapai sekitar delapan kali lipat, untuk kekuatan yang tidak lebih tinggi secara berarti. Perhatikan juga baris RSA 2048: berkasnya empat kali lebih besar daripada Ed25519, tetapi kekuatannya justru paling rendah di antara semuanya.

Rekomendasi konkretnya: untuk kunci SSH baru, pakai Ed25519. Untuk sertifikat SSL, pakai RSA 2048 kalau Anda masih melayani perangkat lama, atau ECDSA P-256 kalau seluruh pengunjung Anda memakai browser modern. Angka 4096 hanya masuk akal bila kebijakan internal organisasi Anda memang mensyaratkannya.

NIST sedang menyiapkan peralihan ke kriptografi tahan komputer kuantum lewat draf NIST IR 8547. Dokumennya masih berstatus rancangan publik, jadi belum perlu Anda jadikan dasar keputusan hari ini.

Cara Membuat Private Key Sendiri

Ada dua jalur yang akan Anda temui, dan keduanya memakai alat berbeda. Jalur pertama untuk akses server, jalur kedua untuk sertifikat.

Langkah #1: Membuat kunci SSH dengan ssh-keygen

Perintah berikut membuat sepasang kunci Ed25519 sekaligus menyisipkan komentar penanda agar mudah dikenali di daftar kunci server:

ssh-keygen -t ed25519 -C "admin@contoh.com"

Hasilnya dua berkas: id_ed25519 yang merupakan private key dan wajib Anda simpan, serta id_ed25519.pub yang boleh diunggah ke server. Sejak OpenSSH 9.5 yang rilis Oktober 2023, menjalankan ssh-keygen tanpa opsi -t pun sudah menghasilkan Ed25519, bukan RSA seperti pada versi sebelumnya.

Kunci publiknya kemudian didaftarkan ke server tujuan, misalnya ke VPS Indonesia yang Anda kelola sendiri. Langkah pendaftarannya kami bahas terpisah di panduan cara memasang SSH key.

Langkah #2: Membuat kunci sertifikat bersamaan dengan CSR

Untuk sertifikat SSL, private key biasanya dibuat berbarengan dengan CSR (Certificate Signing Request, berkas permohonan yang dikirim ke penerbit sertifikat). Satu perintah menghasilkan keduanya:

openssl req -newkey rsa:2048 -nodes -keyout private.key -out permohonan.csr

Perintah ini menanyakan data pemilik satu per satu, dan yang benar-benar menentukan adalah isian Common Name — tempat Anda mengetikkan nama domain yang hendak diamankan. Berkas private.key tetap di server, sedangkan permohonan.csr yang dikirim saat memesan sertifikat SSL. Lewat panel hosting, langkah ini tersedia dalam antarmuka grafis seperti pada panduan instalasi SSL certificate di cPanel.

Langkah #3: Memastikan kunci dan sertifikat benar-benar berpasangan

Kesalahan paling umum saat memasang sertifikat adalah tertukar berkas antar domain. Cara memastikannya adalah membandingkan modulus (bilangan inti yang sama-sama dimiliki kunci dan sertifikat):

openssl rsa -in private.key -noout -modulus | openssl md5
openssl x509 -in sertifikat.crt -noout -modulus | openssl md5

Kedua perintah harus mengeluarkan hash yang identik. Bila berbeda, berkas Anda bukan sepasang dan pemasangannya pasti gagal. Perintah kedua bisa diganti openssl req -in permohonan.csr -noout -modulus | openssl md5 bila yang ingin Anda cocokkan adalah CSR.

Cara di atas hanya berlaku untuk kunci RSA. Pada kunci ECDSA, openssl rsa justru menjawab Not an RSA key. Perbandingan berikut bekerja untuk semua jenis kunci karena membandingkan kunci publik yang diturunkan dari keduanya:

openssl pkey -in private.key -pubout -outform der | openssl sha256
openssl x509 -in sertifikat.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl sha256

Menjaga Private Key: Izin Berkas 600 dan Passphrase

Private key hanyalah berkas teks. Siapa pun yang bisa membacanya, memilikinya. Karena itu lapis pengaman pertama bukan kriptografi, melainkan izin berkas sistem operasi.

Kunci SSH harus hanya bisa dibaca oleh pemiliknya, yang dalam notasi numerik berarti 600:

chmod 600 ~/.ssh/id_ed25519

Angka 600 berarti pemilik boleh membaca dan menulis, sementara grup dan pengguna lain tidak mendapat akses apa pun. Arti tiap digitnya kami uraikan di pembahasan chmod.

Bila izinnya terlampau longgar, OpenSSH akan menolak memakai kunci tersebut dengan pesan yang cukup tegas:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

Satu catatan yang perlu diperhatikan: peringatan ini baru muncul saat berkas privat benar-benar dibaca. Pada proses login, klien SSH menawarkan kunci publik lebih dulu dan hanya membuka berkas privat bila server menerima tawaran tersebut. Jadi izin yang longgar bisa lolos tanpa keluhan pada percobaan yang memang ditolak server, lalu tiba-tiba menggagalkan login yang seharusnya berhasil.

Lapis kedua adalah passphrase, yaitu kata sandi yang mengenkripsi isi berkas kunci. Dengan passphrase terpasang, berkas kunci yang tercuri masih belum langsung bisa dipakai. Konsekuensinya, Anda perlu mengetiknya setiap kali memakai kunci — kecuali menitipkannya ke ssh-agent selama sesi berlangsung.

Sisi Berat Private Key: Bocor, Hilang, dan Tidak Bisa Direset

Model keamanan ini memindahkan seluruh tanggung jawab ke pundak Anda. Tidak ada tombol "lupa private key", dan tidak ada tim dukungan yang bisa mengirimkan ulang kunci Anda. Mereka memang tidak pernah memilikinya.

Kebocoran lebih sering terjadi daripada yang dibayangkan, dan penyebabnya biasanya sederhana. Berkas kunci ikut terbawa ke repositori kode, tersalin ke folder publik, atau tertinggal di laptop lama. GitHub melaporkan menemukan 39 juta secret — mencakup kunci privat, token, dan kredensial lain — yang bocor di platform mereka sepanjang 2024 saja.

Bila kunci sertifikat yang bocor, konsekuensinya berjalan otomatis. CA/Browser Forum mewajibkan penerbit mencabut sertifikat dengan kunci yang terbukti bocor dalam 24 jam, dan melarang penerbitan ulang memakai kunci yang sama. Website Anda bisa mendadak menampilkan peringatan keamanan sebelum sempat bersiap.

Untuk kunci dompet kripto, hitungannya lebih keras. Tidak ada pencabutan dan tidak ada pemulihan. Kunci yang bocor berarti aset bisa dipindahkan siapa pun yang memegangnya, dan kunci yang hilang berarti aset terkunci selamanya.

Pertimbangan praktisnya ada tiga. Pertama, cadangkan kunci sertifikat di tempat terpisah dari servernya. Kedua, pakai kunci berbeda untuk setiap server dan setiap layanan, supaya satu kebocoran tidak menjatuhkan semuanya. Ketiga, ganti kunci secara berkala — sekali setahun sudah memadai untuk sebagian besar kebutuhan.

Pertanyaan yang Sering Diajukan

Apa contoh private key? Yang paling mudah ditemui adalah berkas id_ed25519 di folder .ssh komputer Anda, atau privkey.pem yang dibuat Let's Encrypt di server. Isinya blok teks acak yang diapit baris -----BEGIN PRIVATE KEY----- dan -----END PRIVATE KEY-----. Di dunia kripto, contohnya frasa 12 kata yang diminta dompet saat Anda membuat akun.

Public key itu apa? Public key adalah pasangan terbuka dari private key, dan boleh dibagikan ke siapa pun tanpa risiko. Tugasnya mengunci pesan serta memeriksa tanda tangan. Kunci inilah yang Anda unggah ke server saat mengatur akses SSH, dan yang dimuat di dalam sertifikat SSL sebuah website.

Private key jenis apa yang paling banyak digunakan? Untuk sertifikat website, RSA 2048 bit masih paling umum karena kompatibilitasnya terluas. Untuk akses server, Ed25519 kini menjadi pilihan bawaan OpenSSH sekaligus yang paling banyak dipakai untuk kunci baru.

Bisakah private key dihitung ulang dari public key? Secara teori bisa, secara praktik tidak. Perhitungannya jauh melampaui usia alam semesta dengan komputer yang ada sekarang. Arah sebaliknya justru mudah: kunci publik bisa diturunkan ulang kapan saja dengan openssl rsa -in private.key -pubout.

Apakah private key boleh dipakai ulang untuk sertifikat berikutnya? Boleh selama kunci itu belum pernah bocor, dan banyak orang melakukannya agar tidak perlu memasang ulang konfigurasi. Tetapi bila kunci pernah terekspos, penerbit sertifikat justru dilarang menerbitkan ulang dengan kunci yang sama. Membuat kunci baru setiap kali memperpanjang sertifikat adalah kebiasaan yang lebih aman.

Kesimpulan

Private key adalah satu bilangan rahasia dengan dua tugas: membuka kiriman yang dikunci kunci publik pasangannya, dan menandatangani data untuk membuktikan identitas Anda. Benda yang sama ini muncul di sertifikat SSL, akses SSH, dan dompet kripto. Aturan matematisnya persis serupa; yang berbeda hanya seberapa fatal akibat kehilangannya.

Untuk kebutuhan sehari-hari, tiga keputusan sudah cukup mengantar Anda. Pakai Ed25519 untuk kunci SSH baru dan RSA 2048 untuk sertifikat website. Kunci izin berkasnya di 600, lalu simpan cadangannya terpisah dari server. Sisanya biarkan panel hosting yang mengurus, selama Anda tahu di mana kuncinya berada.

Semoga artikel ini membantu.