Kunci CA eMudhra yang Lemah: 5 Mitos PKI, Terbongkar

Salah satu kunci privat certificate authority milik eMudhra adalah angka 4. Bukan bilangan 384-bit yang kebetulan diawali 4, melainkan cuma 4, lalu diisi 47 byte nol supaya kelihatan layak. Ini kegagalan pembangkitan kunci CA yang dulu saya kira mustahil, dan lolos dari audit, cross-signing oleh Sectigo, serta tujuh belas bulan di infrastruktur yang dekat dengan produksi, sampai akhirnya ada yang mencoba cara paling jelas: brute-force satu byte. Berikut lima keyakinan tentang PKI yang dihancurkan insiden ini sampai tak tersisa.

Mitos 1: “Sertifikat yang struktur dan formatnya valid itu pasti aman”

Setiap pemeriksaan otomatis di pipeline menyatakan sertifikat-sertifikat ini baik-baik saja. Dan mereka benar, dalam arti yang sempit dan tidak berguna. Public key yang sesuai dengan d = 4 adalah titik yang valid di kurva P-384. Encoding ASN.1-nya bisa di-parse. Signature-nya terverifikasi. Chain-nya terbentuk. Setiap linter, setiap validator struktur, dan setiap checklist kepatuhan yang memeriksa apakah sertifikat terbentuk dengan benar akan meloloskannya, karena memang terbentuk dengan benar.

Di sinilah jebakannya. Validasi struktural menjawab pertanyaan “apakah ini sertifikat yang formatnya benar?” Ia tidak menjawab “apakah kunci di dalamnya dibangkitkan dengan benar?” Untuk kunci kurva elliptic, kedua hal itu hampir sepenuhnya independen. Kunci privat hanyalah skalar d; public key-nya adalah d × G, dengan G sebagai titik generator kurva. Seluruh argumen keamanannya bertumpu pada fakta bahwa memulihkan d dari titik publik membutuhkan penyelesaian masalah logaritma diskrit, tetapi hanya jika d benar-benar dipilih dari ruang 384-bit penuh. Kalau d dipilih dari 8 bit, masalah yang “mustahil” itu berubah menjadi loop yang paling banyak berjalan 255 iterasi.

Tidak ada yang ada di sertifikat hasilnya mengisyaratkan hal ini. Titik publik yang diturunkan dari d = 4 tampak sama acaknya dengan yang berasal dari kunci yang dibangkitkan dengan benar. Anda tidak bisa mengeceknya dengan mata. Anda tidak bisa melakukan lint. Satu-satunya cara untuk tahu adalah mencoba nilai kecil dan pola lemah yang sudah dikenal, dan itulah yang terjadi: sang pelapor menjalankan suite tes paranoid_crypto milik Google terhadap korpus Common CA Database, langsung pakai, dan mendapat hit. Ini pemeriksaan yang memakan waktu milidetik di laptop, terhadap kunci yang menjadi jangkar kepercayaan untuk browser sungguhan.

Jadi pelajaran pertamanya: validitas itu perlu, tapi jauh dari cukup. Kalau pengujian PKI Anda berhenti di “sertifikatnya bisa di-parse dan membentuk chain”, Anda cuma menguji amplopnya dan mengabaikan isinya.

Mitos 2: “Baseline Requirements dan audit pasti menangkap bug pembangkitan kunci”

CA beroperasi di bawah CA/Browser Forum Baseline Requirements dan diaudit berdasarkan kriteria WebTrust atau ETSI. Ada dokumentasi seremoni, persyaratan HSM, dan persyaratan panjang kunci. Kunci eMudhra punya panjang yang benar, yaitu 384 bit di atas kertas. Celah auditnya: kepatuhan memverifikasi representasi kunci, bukan entropi proses yang menghasilkannya. Kunci yang diisi 47 byte nol tetap memakan 48 byte di disk.

Menurut laporan eMudhra sendiri yang diposting di tiket insiden Mozilla, akar masalahnya terdengar seperti komedi gelap: bug di skrip seremoni menghasilkan pasangan kunci lemah kedua di HSM; kedua pasangan kunci itu punya nama yang mirip; lalu seseorang memilih yang salah untuk CSR. Tiga kegagalan terpisah, yaitu bug skrip, tabrakan penamaan, dan kesalahan pemilihan, dan tidak ada satu kontrol pun yang bertanya “apakah kunci ini benar-benar punya entropi yang sudah kita bayar ke HSM?”

Bagian inilah yang seharusnya membuat setiap engineer yang mengelola PKI internal sendiri khawatir. Kalau CA yang tepercaya publik, dengan root program yang mengawasi dan audit yang terjadwal, bisa mengirim kunci privat yang sama dengan 4, apa yang ada di backend Vault PKI Anda atau template Active Directory Certificate Services Anda? Perbaikannya murah dan tidak ada alasan untuk melewatkannya. Setelah membangkitkan kunci apa pun, dan sebelum menandatangani apa pun dengannya, jalankan melalui paranoid_crypto atau setidaknya pemeriksaan kewarasan yang sederhana:

from cryptography.hazmat.primitives.asymmetric import ec
CURVE_ORDER_BITS = 384
def sanity_check_private_key(key: ec.EllipticCurvePrivateKey) -> None:
d = key.private_numbers().private_value
# Reject keys whose effective entropy is far below the curve size.
# A healthy P-384 key should have a bit length close to 384.
if d.bit_length() < CURVE_ORDER_BITS - 32:
raise ValueError(
f"Suspiciously small private scalar: {d.bit_length()} bits"
)
# Also reject known bad values outright.
if d < 2**16:
raise ValueError("Private scalar is trivially brute-forceable")

Tiga puluh detik kerja. Ini sudah cukup untuk menangkap kedelapan kunci eMudhra. Audit memverifikasi bahwa proses itu ada; mereka tidak memverifikasi bahwa proses itu berjalan benar pada hari Selasa tertentu di bulan April. Hanya pengujian output yang bisa melakukan itu.

Mitos 3: “Kunci CA yang bocor masih bisa dikendalikan”

Ketika kunci CA “bocor” dalam arti biasa, ada pencurinya. Seseorang mengeksfiltrasi kunci pada momen tertentu, dan Anda bisa menalar radius dampaknya: sertifikat yang diterbitkan setelah pencurian, oleh pihak yang memegang kunci curian. Jelek, tapi terbatas. Kami pernah menulis tentang apa yang terjadi saat kompromi intermediate CA mematahkan trust chain, dan buku panduan standarnya (cabut, hapus kepercayaan, terbitkan ulang) mengasumsikan adanya kondisi sebelum dan sesudah.

Insiden ini tidak punya sebelum dan sesudah. Kuncinya pada dasarnya sudah publik sejak sertifikatnya dibuat, karena siapa pun yang pernah melihat sertifikat itu bisa memulihkan kuncinya dalam milidetik. Tidak ada peristiwa pencurian yang bisa dibatasi. Jendelanya adalah seluruh masa hidup sertifikat, sejak April 2025 dan seterusnya, dan tidak ada cara untuk tahu siapa, jika ada, yang masuk lewat pintu terbuka itu. Pernyataan eMudhra bahwa intermediate tidak menerbitkan sertifikat end-entity, yang dikuatkan oleh log Certificate Transparency, memang menenangkan untuk apa yang dilakukan CA tersebut. Tapi itu tidak mengatakan apa-apa tentang apa yang bisa dilakukan siapa pun yang memegang d=4 secara oportunistik di jalur jaringan.

Lebih buruk lagi, responsnya sendiri tidak bisa sepenuhnya efektif. Chrome dan Firefox memblokir intermediate dalam hitungan jam lewat CRLSet dan OneCRL, dan keduanya mewajibkan logging CT, jadi sertifikat TLS palsu memang tidak akan tervalidasi di browser tersebut. Bagus. Tapi perlindungan itu berhenti di batas browser, dan itu membawa kita ke mitos berikutnya.

Mitos 4: “Kalau browser aman, ekosistemnya aman”

Browser adalah skenario terbaik di ekosistem TLS, dan mereka hanya minoritas dari klien TLS yang penting bagi operasional Anda. Pikirkan apa yang sebenarnya membuat koneksi HTTPS di infrastruktur Anda: curl, requests di Python, Node, binary Go, layanan Java, git, package manager, dan SDK cloud. Klien-klien ini punya tiga karakteristik yang bertumpuk buruk di sini: mereka mempercayai bundle CA di disk, mereka tidak mengecek revocation secara default, dan mereka tidak mengecek Certificate Transparency. Ketiga perlindungan yang menyelamatkan pengguna Chrome itu tidak ada.

Scott Helme mendemonstrasikannya secara konkret: dengan sertifikat palsu untuk api.stripe.com yang di-chain ke salah satu intermediate eMudhra yang lemah, curl default melaporkan SSL certificate verify ok, Python menyelesaikan handshake, Node melaporkan koneksi authorized, dan Windows CryptoAPI menerima chain-nya. Ini terjadi di setiap kotak Linux dan macOS yang diuji. Sertifikat palsu untuk hostname apa pun diterima oleh tooling default yang menjadi dasar skrip deployment dan runner CI Anda. Itu bukan masalah browser; itu masalah infrastruktur Anda.

Peta paparannya lebih buruk daripada yang kebanyakan orang bayangkan:

• Installer curl | sh dan self-updater. rustup, nvm, installer Homebrew, dan begitu banyak halaman “install.sh”. Sertifikat palsu di sini berarti menjalankan kode penyerang, sering kali sebagai root.
• Pipeline CI/CD. Runner mengambil dependensi dan mendorong artefak sambil memegang kredensial cloud dan kunci penandatanganan, sering kali di base image yang sudah usang.
• Traffic server-ke-server. Webhook pembayaran, pertukaran token OAuth, dan panggilan SDK cloud yang membawa secret di header.
• Perangkat IoT dan embedded. Firmware yang beku dengan bundle CA yang tidak akan berubah sampai sertifikatnya kedaluwarsa, yaitu pada Juli 2039.
• Code signing Windows. Dua dari delapan kunci lemah itu milik CA code-signing; malware yang ditandatangani dengannya terlihat seperti perangkat lunak dari penerbit yang sah.

Saran yang bisa langsung diterapkan itu membosankan dan benar: perbarui semua yang membawa bundle CA. Itu paket ca-certificates OS Anda, certifi, Node, dan Homebrew. Bangun ulang image container Anda setelah base image mengambil penghapusan kepercayaan tersebut, karena layer itu menyimpan memori. Bagian yang tidak bisa Anda tindak lanjuti adalah perangkat yang tidak bisa diperbarui. Smart TV itu akan mempercayai kunci yang sama dengan 4 selama satu setengah dekade lagi. Kalau Anda butuh satu argumen lagi untuk mensegmentasi jaringan perangkat IoT, inilah dia.

Mitos 5: “Pasti sudah ada yang memeriksa ini”

Baris paling diam-diam memberatkan dari insiden ini datang dari sang pelapor: penemuannya berasal dari menjalankan paranoid_crypto terhadap korpus CCADB sebagai tes korpus cepat sebelum beralih ke sertifikat subscriber. Buah yang paling mudah dijangkau. Kata-kata sang pelapor sendiri: “Sebagian besar waktu saya habis untuk memeriksa hal-hal dasar yang semua orang kira sudah dikerjakan orang lain, kesalahan kritis yang tidak boleh terjadi di dekat keamanan.”

Baca lagi. Delapan kunci privat CA, permata mahkota dari otoritas tepercaya publik yang di-cross-sign ke root AAA Certificate Services milik Sectigo, bisa dibobol dengan brute-force selama tujuh belas bulan. Kunci-kunci itu ditemukan bukan oleh auditor, bukan oleh root program, bukan oleh CA itu sendiri, melainkan oleh satu orang yang menjalankan alat open-source langsung pakai. Ekosistem secara kolektif menganggap hal-hal dasar sudah tercakup. Tidak ada yang benar-benar mencakupnya.

Ini pola yang lebih luas dalam infrastruktur keamanan, dan inilah alasan saya terus mengulang-ulang soal defensive engineering, yaitu sistem yang tahan terhadap bencana, alih-alih sistem yang berasumsi operasinya selalu benar. Pemeriksaan yang akan menangkap masalah ini murahnya hampir memalukan:

1. Jalankan paranoid_crypto atau pemeriksaan kunci lemah yang setara terhadap setiap kunci saat pembangkitan dan terhadap setiap CSR sebelum penandatanganan.
2. Verifikasi entropi secara empiris: periksa panjang bit skalar privat dan tolak apa pun yang entropi efektifnya rendah secara tidak masuk akal, seperti pada contoh kode di atas.
3. Uji seremoninya, bukan hanya konfigurasinya. Jalankan dry-run seremoni kunci Anda dan periksa artefak nyata yang dihasilkan, termasuk objek HSM bernama mana yang berakhir di CSR.
4. Pindai terus sertifikat yang sudah Anda terbitkan, bukan hanya template Anda. Sertifikat adalah kebenaran dasar; semua yang ada di hulunya hanyalah niat.

Sertifikat adalah kebenaran dasar. Semua yang ada di hulunya, yaitu skrip, seremoni, dan audit, hanyalah niat.

Delapan Bit Sudah Cukup

Ada sesuatu yang hampir menenangkan dari bencana dengan penyebab yang konyol. Bug skrip, dua kunci dengan nama mirip di HSM, dan seseorang yang memilih yang salah. Tanpa negara adidaya, tanpa kriptanalisis baru, hanya episode komedi slapstick dengan sumbu tujuh belas bulan. Tapi kekonyolan itu justru peringatannya. Kalau mata rantai terlemah di CA tepercaya publik bisa berupa satu byte, maka kekuatan PKI Anda tidak ditentukan oleh pilihan kurva atau anggaran HSM. Ia ditentukan oleh apakah ada orang, di mana pun dalam pipeline, yang benar-benar menguji output-nya.

Vendor browser sudah melakukan bagiannya dalam hitungan jam. Sisanya ada di tangan kita: audit pembangkitan kunci Anda sendiri, jalankan pemeriksaan murah, perbarui setiap bundle CA yang bisa dijangkau, dan segmentasikan perangkat yang tidak bisa Anda perbarui. Dan berhentilah berasumsi bahwa orang lain sudah memeriksa hal-hal dasarnya. Dalam keamanan, itu asumsi termahal yang ada.