Pertanyaan dan konteks
Sebuah perusahaan memiliki klien mobile, web, perangkat, dan API pihak ketiga yang masih menggunakan RSA atau kriptografi kurva eliptik. Rancang rencana migrasi ke kriptografi pasca-kuantum dan jelaskan kompatibilitas, performa, rotasi kunci, serta rollback.
NIST telah menerbitkan FIPS 203, 204, dan 205 untuk ML-KEM, ML-DSA, dan SLH-DSA. Wawancara ini bukanlah latihan menghafal nama: ini menguji apakah Anda dapat mengubah kerahasiaan jangka panjang, siklus hidup klien, dan risiko operasional menjadi keputusan-keputusan bertahap. Draf TLS hibrida dari IETF masih berstatus draf, sehingga ini bukan jaminan kompatibilitas universal.
Apa yang sedang diuji oleh pewawancara
Pewawancara ingin melihat inventarisasi aset kriptografi yang nyata, pembedaan antara pembentukan kunci (key establishment) dan tanda tangan digital (signatures), penjelasan tentang risiko panen-sekarang-dekripsi-nanti (harvest-now-decrypt-later), rancangan untuk agilitas kripto (crypto agility), serta batasan terukur (gates) untuk kompatibilitas, tingkat kegagalan, dan performa. Anda juga harus mengidentifikasi keputusan yang memerlukan tinjauan dari tim keamanan, kepatuhan (compliance), vendor, dan produk.
Pertanyaan klarifikasi awal
- Data mana yang harus tetap rahasia selama sepuluh tahun atau lebih, dan tanda tangan mana yang memerlukan verifikasi jangka panjang?
- Bagaimana distribusi versi klien, jalur pembaruan firmware, periode offline, dan dependensi pihak ketiga?
- Di mana lokasi call sites untuk RSA, ECDH, dan ECDSA, rantai sertifikat (certificate chains), HSM, dan cadangan (backups)?
- Apakah kunci transport, data-at-rest, code-signing, dan token-signing memiliki siklus hidup yang terpisah?
- Berapa batas anggaran (budget) untuk latensi handshake, ukuran pesan, CPU, memori, dan tingkat kegagalan?
- Bisakah algoritma lama tetap dipertahankan dalam jangka waktu tertentu, dan siapa yang menyetujui downgrade serta rollback darurat?
Jawaban 30 detik
"Saya akan menginventarisasi aset kriptografi dan masa berlaku kerahasiaan terlebih dahulu, lalu memeringkatnya berdasarkan paparan risiko, kesulitan penggantian, dan kemampuan pembaruan klien. Saya akan memisahkan pembentukan kunci dari tanda tangan digital dan menggunakan suite algoritma berversi dengan deteksi kapabilitas untuk mode klasik, pasca-kuantum, atau hibrida; downgrade tanpa pemberitahuan (silent downgrade) tidak akan diizinkan. Saya akan menerapkan uji coba canary pada layanan yang dapat dikontrol dan klien baru sambil mengukur keberhasilan handshake, ukuran respons, CPU, fallback, dan metrik rotasi kunci. Saya hanya akan memperluas cakupan setelah gerbang kompatibilitas, performa, audit, dan rollback terpenuhi, sembari mempertahankan kunci verifikasi lama tanpa menerbitkan kredensial format lama yang baru."
Jawaban mendalam langkah demi langkah
Langkah 1: Inventarisasi algoritma dan masa berlaku data
Pindai TLS, VPN, RPC antar-layanan, enkripsi basis data, cadangan, tanda tangan digital, sertifikat, firmware, dan titik panggilan (call sites) SDK vendor. Untuk setiap aset, catat algoritma, ukuran kunci, tujuan, pemilik, metode rotasi, versi klien, dan masa berlaku kerahasiaan. Prioritaskan lalu lintas yang mungkin dikumpulkan sekarang dan membutuhkan kerahasiaan jangka panjang, kemudian tanda tangan digital yang harus diverifikasi selama bertahun-tahun.
Langkah 2: Buat tingkatan risiko dan baseline target
Beri skor pada kekritisan aset, kelayakan serangan, jendela migrasi, proporsi klien yang tidak dapat diperbarui, dan biaya penggantian. Baseline harus menyatakan koneksi baru mana yang memerlukan perlindungan pasca-kuantum atau hibrida dan koneksi lama mana yang hanya boleh dilanjutkan dalam jendela kompatibilitas yang disetujui, singkat, dan dipantau. Jangan jadikan tanggal kehadiran komputer kuantum praktis sebagai satu-satunya variabel keputusan.
Langkah 3: Ubah kriptografi menjadi kapabilitas yang dapat diganti
Jaga agar kode bisnis tetap independen dari pustaka kripto melalui suite algoritma berversi, jenis kunci, dan kebijakan sertifikat. Server dapat mengevaluasi deklarasi kapabilitas, tetapi klien tidak boleh memilih algoritma yang lemah; layanan kebijakan harus dapat menjeda suatu suite, mengganti penyedia, dan mencatat cakupan. Metadata ciphertext dan tanda tangan digital harus memuat versi agar format historis tetap dapat diidentifikasi.
Langkah 4: Pilih jalur pembentukan kunci dan tanda tangan digital
ML-KEM digunakan untuk enkapsulasi kunci, sedangkan ML-DSA dan SLH-DSA adalah standar tanda tangan digital; kunci, sertifikat, dan performanya berbeda. Untuk TLS, evaluasi handshake hibrida klasik ditambah ML-KEM hanya setelah memeriksa implementasi, status draf, gateway, dan dukungan endpoint. Validasi ukuran rantai sertifikat, biaya verifikasi, dan persyaratan pengarsipan secara terpisah untuk tanda tangan digital.
Langkah 5: Tentukan batasan kompatibilitas dan rollback
Biarkan klien baru memilih suite melalui deteksi kapabilitas dan tempatkan klien lama dalam pool kompatibilitas eksplisit. Downgrade harus dapat dipantau, memiliki batas waktu, dan disetujui per penyewa (tenant) atau perangkat; handshake yang gagal tidak boleh memicu fallback tanpa batas. Rollback harus menarik kembali titik masuk lalu lintas baru tanpa menghapus kunci publik lama yang masih diperlukan untuk verifikasi. Catat alasan, cakupan, dan kriteria pengaktifan kembali.
Langkah 6: Ukur biaya dengan eksperimen canary
Uji keberhasilan koneksi, latensi handshake, ukuran pesan, CPU, memori, bandwidth, caching sertifikat, dan throughput HSM pada layanan internal, klien mobile yang dapat diperbarui, dan penyewa berisiko rendah. Lakukan uji beban pada saat puncak, jaringan lemah, pemulihan offline, dan berbagai wilayah. Bandingkan overhead pasca-kuantum dengan SLO bisnis; tanggapi berdasarkan versi dan jenis klien alih-alih menonaktifkan kebijakan keamanan secara global.
Langkah 7: Koordinasikan kunci, vendor, dan audit
Tentukan jendela pembuatan, penyimpanan (custody), rotasi, pencabutan, pencadangan, dan pemusnahan untuk kunci baru dan lama. Verifikasi dukungan format target di HSM, KMS cloud, otoritas sertifikat (CA), proksi, dan SDK pihak ketiga; catat perubahan suite sebagai peristiwa audit. Tim keamanan memiliki kebijakan, tim platform menangani implementasi, dan tim hukum atau kepatuhan mengonfirmasi persyaratan retensi dan bukti yang berlaku.
Langkah 8: Tetapkan release gates dan rencana penghentian jangka panjang
Release gates harus mencakup keberhasilan kompatibilitas, anggaran performa, proporsi lalu lintas algoritma lama, fallback abnormal, keberhasilan rotasi, dan kelengkapan audit. Berikan garis henti (stop line) dan pemilik untuk setiap tahapan. Setelah lalu lintas format lama berada di bawah ambang batasnya, hentikan penerbitan kredensial lama yang baru, lalu cabut penerimaannya setelah jendela verifikasi. Simpan catatan migrasi agar penggantian algoritma berikutnya dimulai dengan bukti yang jelas.
Trade-off dan batasan
Mode hibrida versus mode murni pasca-kuantum
Mode hibrida mengurangi ketergantungan pada satu algoritma baru tetapi meningkatkan ukuran handshake, kompleksitas implementasi, dan pengujian negosiasi. Mode murni pasca-kuantum mengekspresikan target secara lebih langsung tetapi dapat mengecualikan klien yang tidak dapat ditingkatkan. Biarkan matriks kompatibilitas dan batas risiko yang menentukan.
Kekuatan keamanan versus anggaran performa
Kunci, ciphertext, atau tanda tangan digital yang lebih besar memengaruhi MTU, handshake, cache, dan throughput HSM. Ukur lalu lintas nyata dan sediakan margin cadangan untuk jaringan seluler, CPU perangkat, dan puncak konkurensi. Peningkatan performa tidak boleh dicapai melalui downgrade tanpa pemberitahuan.
Rollback versus mempertahankan kunci lama
Titik masuk rollback dan pemusnahan kunci adalah keputusan yang terpisah. Kunci publik lama mungkin masih diperlukan untuk tanda tangan historis, sehingga rollback tidak boleh langsung menghapusnya. Hentikan penerbitan baru, batasi koneksi baru, pertahankan verifikasi read-only, dan musnahkan hanya jika bukti sudah mencukupi.
Simulasi kegagalan dan rencana evolusi
Perangkat lama tidak dapat ditingkatkan
Buat inventaris versi perangkat, gateway terisolasi, dan tanggal kedaluwarsa yang eksplisit. Verifikasi bahwa isolasi mencegah suite yang lemah menyebar ke klien baru, dan berikan jalur peningkatan atau penggantian kepada pemilik.
Handshake yang lebih besar memutus koneksi
Uji fragmentasi, MTU, batas waktu (timeouts), dan percobaan ulang (retries) melalui proksi nyata, load balancer, dan jaringan seluler. Jika suite baru gagal, kembalikan ke pool kompatibilitas yang disetujui dan berikan peringatan; klien tidak boleh mencoba suite lemah lainnya sendiri.
Vendor hanya mendukung tanda tangan digital lama
Berikan vendor antarmuka berversi dan sertifikat transisi, dengan masa berlaku dan izin terbatas untuk tanda tangan digital lama. Masukkan komitmen peningkatan ke dalam kontrak dan metrik penerimaan daripada menyembunyikan dependensi yang tidak terkontrol dalam "pekerjaan nanti".
Kesalahan umum dan tindak lanjut
Kesalahan 1: Memperlakukan penggantian algoritma sebagai satu kali rilis konfigurasi
Tindak lanjut: Bagaimana Anda menemukan setiap call site kripto, cadangan, dan perangkat offline? Jawaban yang kuat menyebutkan inventaris aset, grafik dependensi, dan pemilik.
Kesalahan 2: Menganggap publikasi FIPS sebagai dukungan klien universal
Tindak lanjut: Di mana bukti dukungan untuk pustaka target, otoritas sertifikat, HSM, gateway, dan browser? Pisahkan standar yang sudah selesai dari implementasi produk yang siap pakai.
Kesalahan 3: Melakukan fallback diam-diam ke RSA
Tindak lanjut: Siapa yang menyetujui downgrade, berapa lama batas waktunya, bagaimana peringatannya diberikan, dan apa yang mengakhirinya? Berikan jendela kompatibilitas yang dapat diaudit.
Kesalahan 4: Hanya mengukur latensi rata-rata
Tindak lanjut: Bagaimana Anda menguji puncak konkurensi, jaringan lemah, ukuran paket, CPU, memori, dan caching sertifikat? Jelaskan pengujian beban berlapis dan garis henti.
Pertanyaan lanjutan dan tanggapan
Mengapa memigrasikan pembentukan kunci dan tanda tangan digital secara terpisah?
Pembentukan kunci melindungi kerahasiaan sesi; tanda tangan digital melindungi identitas dan integritas. Algoritma, rantai sertifikat, ukuran kunci, dan masa verifikasinya berbeda, sehingga uji coba canary yang terpisah menghindari pemblokiran setiap beban kerja hanya karena satu penggantian.
Bagaimana Anda membuktikan kelincahan kripto (crypto agility)?
Tunjukkan suite berversi, peralihan kebijakan, metadata kunci, penggantian penyedia, matriks kompatibilitas, peristiwa audit, dan simulasi rollback. Mengedit satu file konfigurasi tidak membuktikan bahwa kode bisnis, sertifikat, dan jalur perangkat dapat diganti.
Kapan Anda dapat berhenti menerima algoritma lama?
Setelah cakupan klien baru, keberhasilan koneksi, performa, dan batas audit terpenuhi, lalu lintas lama telah teridentifikasi, dan pemilik menyelesaikan peningkatan, hentikan penerbitan baru terlebih dahulu. Setelah jendela verifikasi read-only, cabut penerimaan. Setiap langkah membutuhkan kondisi rollback dan penanggung jawab.