Konsep Infrastruktur Kunci PublikPanjang Kunci & Keamanannya
Penyerangan dengan brute force attack:
| | Panjang Kunci (bit) | |||||
| Asimetris (RSA) | - | 384 | 512 | 768 | 1792 | 2304 |
| Simetris (DES) | 40 | 56 | 64 | 80 | 112 | 128 |
| $100,000 | 2 detik | 35 jam | 1 thn | 70 000 thn | 10^14 thn | 10^19 thn |
| $1,000,000 | 0,2 detik | 3,5 jam | 37 hari | 7 000 thn | 10^13 thn | 10^18 thn |
| $10,000,000 | 0,02 detik | 21 menit | 4 hari | 700 thn | 10^12 thn | 10^17 thn |
| $100,000,000 | 2 ms | 2 menit | 9 jam | 70 thn | 10^11 thn | 10^16 thn |
Tabel 1. Perkiraan waktu untuk membobol sebuah kunci dengan
harga tertentu tahun 1995
Jadi untuk membobol kunci asimetris 512-bit membutuhkan waktu komputasi yang kurang lebih sama untuk membobol kunci simetris sepanjang 64-bit. Dengan asumsi kemampuan komputer menjadi berlipat ganda setiap 18 bulan dengan harga yang sama, maka pada tahun 1999 estimasi tersebut akan menjadi:
| | Panjang Kunci (bit) | |||||
| Asimetris (RSA) | - | 384 | 512 | 768 | 1792 | 2304 |
| Simetris (DES) | 40 | 56 | 64 | 80 | 112 | 128 |
| $100,000 | 0,25 detik | 4,4 jam | 1,5 bulan | 10 000 thn | 10^13 thn | 10^18 thn |
| $1,000,000 | 25 ms | 25 menit | 4,5 hari | 1 000 thn | 10^12 thn | 10^17 thn |
| $10,000,000 | 2,5 ms | 2,6 menit | 12 jam | 100 thn | 10^11 thn | 10^16 thn |
| $100,000,000 | 0,25 ms | 2 menit | 1,1 jam | 10 thn | 10^10 thn | 10^15 thn |
Tabel 2. Perkiraan waktu untuk membobol sebuah kunci dengan
harga tertentu tahun 1999
Entitas PKI
Menurut RFC 2510 tentang manajemen sertifikat, dalam sebuah model public key infrastructure terdapat beberapa entitas:
1. Subject atau subscriber
2. Certification Authority (CA)
3. Registration Authority (RA)
4. Certificate Repository
Subscriber
Sebenarnya subscriber dari sebuah sertifikat digital tidaklah harus orang atau perusahaan, namun bisa juga peralatan (device) pada jaringan, aplikasi software dan downloadable application. Dalam RFC 2459, dipergunakan istilah ‘subject’ untuk subscriber.
Seorang subscriber harus bisa menjaga private key-nya baik-baik, jangan sampai tercuri oleh orang lain.
Certification Authority
Certification Authority (CA) ada sebuah lembaga yang bertugas untuk mensertifikasi jati diri subscriber / subject agar subscriber itu bisa dikenali di dunia digital, dengan menerbitkan sertifikat digital untuk tiap subscribernya.
Tentunya, CA harus merupakan entitas yang independen dan terpercaya (trusted third party).
Untuk memberikan gambaran bagaimana CA bekerja, kita ambil contoh bagaimana cara sebuah perusahaan meminta SSL. Perusahaan itu perlu menunjukkan kepada CA dua lembar surat, yakni surat ijin usaha dan surat izin penggunaan suatu domain name tertentu. Barulah setelah memeriksa keabsahan kedua dokumen tersebut, CA menerbitkan sertifikat digital SSL untuk perusahaan yang bersangkutan.
CA-internal di sebuah perusahaan bisa saja mengeluarkan digital ID buat pegawainya, untuk keluar masuk ruangan (access control card).
Registration Authority
Registration authority (RA) bertanggung jawab untuk melakukan proses identifikasi dan otentikasi terhadap subscriber dari sertifikat digital, tetapi tidak menandatangani sertifikat itu. Dalam kehidupan sehari-hari, banyak sekali dokumen yang diperiksa namun ditandatangani oleh orang yang berbeda.
Adanya sebuah RA dalam PKI memang sifatnya optional (tidak harus ada), karena memang RA hanya menjalankan beberapa tugas yang didelegasikan oleh CA jika CA tidak sanggup melakukannya. Artinya, bisa saja dalam suatu skenario tertentu, seluruh tugas RA berada dalam CA. Menurut Adams dan Lloyd, tugas-tugas RA dapat mencakup:
Otentikasi calon subscriber secara fisik
Registrasi calon subscriber
Membuat pasangan key untuk subscriber (jika subscriber tidak sanggup membuat sendiri pasangan kuncinya).
Membuat backup dari kunci privat yang dipergunakan untuk enkripsi (key recovery)
Pelaporan kalau ada sertifikat yang dicabut (revocation reporting)
Certificate Repository
Anto dapat menyerahkan sertifikat digitalnya kepada orang lain yang ingin berkomunikasi dengan aman dengan Anto. Teknik penyerahan sertifikat digital oleh pribadi ini disebut dengan istilah private dissemination. Tapi, teknik ini memiliki beberapa kekurangan:
1. Teknik ini hanya bisa untuk PKI dengan user dalam jumlah kecil. Artinya scalability-nya rendah, karena penyebaran informasinya tidak ‘meluas’.
2. Umumnya tidak sesuai dengan struktur perusahaan pada umumnya, yang cenderung sifatnya centralized/hierarchial, ketimbang user-centric.
Cara lain Badu mendapatkan sertifikat digital Anto?
Sebuah tempat penyimpanan (repository) on-line untuk sertifkat digital dibutuhkan dalam PKI. Repository ini juga berguna untuk menyimpan daftar sertifikat yang dibatalkan/CRL (yang tidak berlaku sebelum masa berlakunya habis).
Beberapa contoh yang masuk kategori repository mencakup: LDAP, X.500, OCSP Responder, database, dsb.
Relying Party
Relying party adalah pihak yang mempercayai keberadaan dan keabsahan suatu sertifikat digital.
Mungkin Anto mengenali dan mengakui keabsahan dari sertifikat digital tersebut, karena:
1. Anto mengakui IndoSign sebagai pihak ketiga yang dipercaya yang melakukan proses sertifikasi. Karena itu, Anto mengakui keabsahan sertifikat yang ditandatangani IndoSign.
2. Sertifikat web server (SSL certificate) P.T. Jaya Makmur ditandatangani oleh IndoSign.
3. Maka Anto mengakui keotentikan web server P.T. Jaya Makmur.
Anto adalah relying party.
Certificate Revocation List (CRL)
Ada kalanya sertifikat tersebut harus dibatalkan keabsahannya / dicabut meskipun belum kadaluarsa. Hal ini dapat terjadi kalau sang subscriber:
tidak menjalankan kewajibannya sehingga sertifikatnya terpaksa dicabut
mengganti namanya, atau ganti address e-mail, misalnya.
kehilangan kunci privat pasangannya
kunci privatnya berhasil dihack oleh orang lain
Daftar sertifikat yang dicabut sebelum kadaluarsa itu disebut dengan istilah certificate revocation list (CRL) dan disebarkan kepada publik melalui sebuah repository. CRL tersebut ditandatangani oleh CA, yang memuat:
1. Algoritma yang dipergunakan untuk menandatangani CRL
2. Nama pihak yang mengeluarkan CRL
3. Tanggal/waktu saat CRL ybs dikeluarkan
4. Kapan CRL ybs akan kadaluarsa
5. Kumpulan sertifikat yang dicabut: nomor seri, waktu pencabutan
6. Extension lainnya
Repository yang mengandung CRL yang di-cache di lokasi ‘dekat’ client, memungkinkan pengoperasian PKI secara off-line, tanpa perlu terhubung dengan repository utama di CA sentral. Ini amat penting, karena berarti transaksi elektronik dapat berlangsung secara terdistribusi tanpa perlu ada hubungan on-line ke pusat.
Namun kalau diperhatikan lebih jeli, maka ada jarak antara saat sertifikat dicabut, dengan waktu saat CRL diedarkan. Nah, seharusnya, jika ada transaksi yang terjadi setelah tanggal pencabutan, maka transaksi tersebut harus dibatalkan.
Online Certificate Status Protocol (OCSP)
Karena permasalahan data yang ada di CRL tidak real-time, maka mungkin untuk jenis aplikasi tertentu yang membutuhkan masalah besar. Misalnya, untuk transaksi fund-transfer bernilai tinggi, mungkin membutuhkan pengecekan validitas sertifikat secara real-time.
Dengan adanya Online Certificate Status Protocol (dispesifikasikan dalam RFC 2560), maka aplikasi-aplikasi yang menggunakan PKI, dapat menentukan status keberlakuan dari sebuah sertifikat digital, apakah masih berlaku atau sudah dibatalkan. Untuk melakukan pengecekan status sertifikat, sebuah client OCSP mengirimkan status request kepada OCSP responder. Client tidak akan mengakui keberadaan sertifikat yang bersangkutan, sebelum mendapatkan jawaban dari OCSP responder.
Key Backup & Recovery
Ada beberapa hal yang bisa ‘memaksa’ kunci privat juga dibackup oleh pihak ketiga yang dipercaya (trusted third party/TTP), misalnya:
kunci privatnya yang ada dalam hard disk, secara tidak sengaja terhapus
smartcard yang dipergunakannya hilang atau rusak
ada pegawai kantor yang mengenkripsi data-data penting perusahaan menggunakan kunci publiknya, sehingga saat pegawai kantor itu berhenti bekerja, perusahaan tidak bisa membuka data-data penting tersebut.
Perlu dicatat bahwa yang dibackup oleh TTP hanya private decryption key (kunci privat yang dipergunakan untuk mendekripsi pesan), bukan private signing key (kunci yang dipergunakan untuk membuat tanda tangan).
Key Update / Certificate Renewal
Saat mendekati masa kadaluarsa, sertifikat baru harus diterbitkan oleh CA untuk menggantikannya. Proses inilah yang disebut dengan key update atau pembaharuan sertifikat. Biasanya saat sertifikat berumur 80%-70%, sertifikat baru diterbitkan untuk menggantikan yang lama.
Tujuan penggantian kunci ini (key roll-over) adalah agar transaksi bisnis yang menggunakan PKI tidak terganggu kegiatannya operasinya.
Key update juga berkaitan dengan masalah peningkatan keamanan kunci. Dalam sekuriti komputer, ada suatu kebiasaan agar selalu mengganti password
Key History
Berkaitan dengan adanya key update, maka Anto dalam suatu saat dapat memiliki beberapa kunci sekaligus (miliknya), yakni sebuah kunci yang masih ‘berlaku’, dengan kunci-kunci lainnya yang sudah kadaluarsa atau sudah dibatalkan. Jika Anto ingin melakukan proses dekripsi data yang dia enkripsikan 5 tahun yang lalu, maka Anto perlu menggunakan kunci yang dipergunakan 5 tahun yang lalu.
Time stamping
Diperlukan suatu mekanisme khusus untuk menyediakan ‘waktu’ yang terpercaya dalam infrastruktur kunci publik. Artinya, ‘waktu’ tersebut tidak didapatkan dari ‘clock’ setiap komputer, namun didapatkan dari satu sumber yang dipercaya. Penyedia jasa sumber ‘waktu’ yang dipercaya, juga termasuk kategori TTP.
mendekati waktu resmi (dari Badan Metrologi dan Geofisika)
Model-model Jaringan Kepercayaan
Konsep Certification Path
Ccertification path adalah (penelusuran) rantai sertifikasi dari root CA ke subscriber, dimana di antara keduanya bisa ada beberapa CA lain.
Jadi, dalam kasus ini, certification path-nya adalah:
Sertifikat P.T. Jaya Makmur -->Sertifikat IndoSign --> Sertifikat ISETO
Cross-Certification
Di dunia cyber, seperti layaknya di dunia nyata sehari-hari, akan terdapat banyak pemegang kewenangan (otoritas) yang memberikan sertifikasi, surat izin, tanda pengenal, dan sebagainya. Artinya, pasti akan ada banyak CA di dunia ini.
Namun tidak perlu dipungkiri, bahwa kebutuhan akan pengakuan keabsahan seorang subscriber dari domain CA yang lain, akan terjadi dalam suatu transaksi. Mungkin tidak bisa karena karena tidak ada ‘trust’ antara kedua domain yang berbeda itu.
Untuk membuat hubungan kepercayaan antara kedua domain tersebut, maka kedua CA tersebut saling menandatangani sertifikat yang lain. Selain sertifikat digital yang self-signed, setiap CA juga memiliki sertifikat digital yang ditandatangani CA dari domain yang lain.
Jika dilakukan full cross certification, maka untuk 5 CA saja, akan diperlukan 4 + 3 + 2 + 1 = 10 cross certification.
Single-hub cross-certification: Dalam skenario ini, ada sebuah CA yang dijadikan rujukan, dimana CA-CA lain melakukan cross-ceritificaiton dengan CA rujukan.
Cross-Registration
Dalam kasus ini, sebuah domain cukup menyimpan root certificate dari domain yang lain ke dalam repository-nya. Sehingga, jika seorang relying party sedang menelusuri certification path seorang subscriber dari domain CA yang lain, dia akan menemukan root certificate domain CA yang lain itu di repository lokal.
Hirarkis
Cross certification biasanya dilakukan oleh CA-CA yang pada awalnya berdiri sendiri-sendiri, namun baru merasakan kebutuhan akan perlunya hubungan antar domain pada belakang hari.
Setiap subscriber yang berada dalam tree, hanya perlu memiliki root certificate saja untuk berkomunikasi dengan siapapun dalam tree.
Pola ini juga dianggap paling cocok dengan struktur perusahaan, sehingga pola ini banyak dipakai dalam bisnis.
Banyak trust network yang kita kenal menggunakan model hirarkis, seperti: ISETO/WISEkey, Identrus, Verisign, Baltimore OmniRoot (CyberTrust), dsb.
Browser dan e-mail client seperti Microsoft Internet Explorer dan Netscape Navigator juga menggunakan varian dari pola hirarkis ini, hanya saja tidak menggunakan CRL. Pola jaringan kepercayaan hirarkis pada browser dan e-mail dikenal dengan istilah web-model.
User-centric Web of Trust
Ada beberapa jenis trust network yang sangat terdistribusi, bahkan proses sertifikasi dari kunci publik tidak dilakukan oleh CA, melainkan oleh end-entity.
Sebagai contoh dalam web of trust PGP (Pretty Good Privacy), Joni (J) dapat berkomunikasi dengan Emir (E) karena jalur ‘kepercayaan mereka’ melalui Anto (A). Secara teknis, jika A dan J saling mempercayai kunci publik-nya satu sama lain, maka jika A menandatangani kunci publik E, maka J boleh jadi akan mempercayai E. Perhatikan bahwa tidak ada koordinasi sentral dari pola jenis ini.
Besarnya web of trust juga tidak menjamin bahwa Indra (I) dapat berkomunikasi dengan Deddy (D), karena certification path-nya sudah terlalu jauh. Artinya, semakin panjang certification path-nya, tingkat kepercayaannya juga semakin menurun.
Direct End-Entity Trust
Dalam kasus seperti ini, bisa saja terjadi direct end-entity trust, dimana mereka saling mempertukarkan sertifikat digital mereka masing-masing satu sama lain.
Karena domain tempat mereka tidak ada hubungan apa-apa, maka segala transaksi yang terjadi antara Anto dengan Encik Badrul, sepenuhnya bukan tanggung jawab CA manapun, melainkan pertanggungjawaban pribadi Anto dan Encik Badrul.
Certificate Policy & Certificate Practice Statement
Tingkat kepercayaan seorang relying-party terhadap sebuah sertifikat digital tergantung pada beberapa faktor:
cara atau metodologi CA dalam mengotentikasi calon subscriber saat registrasi
kebijakan CA, prosedure operasional CA dan manajemen keamanan yang diterapkan dalam CA
kejelasan mengenai hak dan kewajiban subscriber
kejelasan mengenai hak dan kewajiban subscriber CA, termasuk tanggung jawab dan batas kerugian yang bisa ditanggung CA.
dan sebagainya.
Certificate Policy
Menurut standar RFC 2527, certificate policy adalah
“sekumpulan aturan yang menjelaskan bagaimana sebuah sertifikat itu diberlakukan pada suatu komunitas tertentu atau pada jenis transaksi/aplikasi tertentu, dengan suatu tingkat keamanan yang sederajat. “
Contoh, sebuah certificate policy bisa saja menunjukkan bagaimana sertifikat digital bisa dipakai dalam transaksi EDI dengan suatu batas nilai transaksi tertentu.
Dengan ada certificate policy, seorang relying party dapat menentukan apakah sebuah sertifikat (yang dapat mengikat sang relying party) cukup dapat dipercaya untuk dipakai mengamankan suatu jenis transaksi tertentu.
Untuk memberikan sebuah gambaran mengenai certificate policy, kita ambil contoh mengenai IATA. Certification Authority (CA) dari IATA akan membuat certificate policy untuk sertifikat-sertifikat digital yang diterbitkan dalam domain CA IATA. IATA bisa mendefinisikan 2 macam certificate policy:
1. General purpose
Sebuah sertifikat digital yang memiliki policy “general purpose”, hanya bisa dipergunaka`n untuk keperluan rutin seperti e-mail, delivery order, cargo tracking, dan sebagainya. Batas ambang asuransinya juga tidak besar. Biasanya, cara mendapatkan sertifikat digital jenis ini cukup mudah, dimana seorang pegawai cukup mendaftarkan diri lewat web, dan mendapatkan sertifikat digital secara on-line. Bahkan, sang pegawai tidak perlu bertatap muka dengan RA. Syarat keamanan penyimpanan kunci privatnya pun rendah, cukup diletakkan di disket saja.
2. Commercial grade
Sedangkan sertifikat dengan policy “commercial grade” dipergunakan untuk transaksi-transaksi high security, seperti kontrak dengan supplier, fund-transfer antar bank, dan penjualan tiket pesawat on-line. Dalam kasus ini, mungkin subscriber harus menampilkan tanda pengenal di depan RA langsung sebelum menandatangani kontrak penggunaakn sertifikat digital. Penyimpanan kunci privatnya pun mungkin diharuskan menggunakan smartcard. Tentunya batas ambang transaksinya pun jauh lebih tinggi dan memiliki asuransi ganti rugi yang lebih baik juga.
Tingkat kepercayaan terhadap sertifikat
Tingkat keabsahan sertifikat digital sebenarnya tidak sama. Sebagai contoh, dalam Verisign Trust Network (VTN) ada beberapa kelas sertifikat. Cara mendapatkan sertifikat yang berbeda kelas, tidaklah sama. Disini juga berarti bahwa untuk setiap kelas, memiliki certificate policy yang berbeda-beda.
Ada sertifikat yang diberikan secara gratis. Sertifikat jenis ini (class 1) hanya bisa dipakai untuk menunjukkan bahwa X adalah X. Namun, ada juga sertifikat yang mahal sekali yang harganya mencapai ratusan dolar (misalnya class 4 certificate). Untuk mendapatkan sertifikat jenis ini, sebuah perusahaan harus menunjukkan akta perusahaan, surat izin usaha dan surat izin penggunaan domain name. Secara fisik, harus hadir di CA utk mendaftar.
Kesimpulan yang kita bisa tarik di sini adalah certificate policy atau level sertifikat menunjukkan “trustworthiness” dari suatu subscriber.
Certification Practice Statement
Deskripsi yang lebih detail dari praktek operasional yang dilakukan oleh CA dalam registrasi calon subscriber, menerbitkan sertifikat, dan mencabut sertifikat (dengan kata lain memanage life-cycle sertifikat digital) tercantum dalam Certification Practice Statement (CPS).
Menurut panduan tanda tangan digital dari American Bar Association (ABA), CPS adalah “a statement of the practices which a certification authority employs in issuing certificates.”
Sebenarnya, CPS tidak hanya saja dapat berupa statement dari CA saja. Sebuah CPS juga bisa terdiri beberapa dokumen yang mencakup hukum publik, hukum privat dan pernyataan sepihak. Kepatuhan pada regulasi dari pemerintah mengenai syarat sebuah CA yang berlisensi juga dapat dijadikan salah satu bagian dari CPS. Kemudian, CPS juga bisa menjadi bagian dari kontrak antara CA dengan subscriber.
Kewajiban CA terhadap relying party juga dapat diletakkan di dalam CPS. Meskipun relying party tidak terlibat ‘kontrak’ antara CA dengan subscriber, namun relying party dapat melihat hak-haknya yang tercantum dalam CPS. Menurut RFC 2527, disarankan agar CPS dirujuk dari sertifikat digital (incorporation by reference) agar relying party dapat membaca CPS tersebut.
- Arrianto Mukti Wibowo, Konsep Infrastruktur Kunci Publik., 2001
- B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd edition, (New York, John Wiley & Sons. Inc.: 1996)
- C. Adams, and S. Lloyd, Understanding Public-Key Infrastructure: Concepts, Standards, and Deployment Considerations, (Indianapolis, Macmillan Technical Publishing: 2000)
- http://www.ecomindo.com
-
staf.cs.ui.ac.id/WebKuliah/infosec/.../Transparan%20Digisec-3%20PKI.doc
