Sumber utama: C. Adams, and S. Lloyd, Understanding Public-Key Infrastructure: Concepts, Standards, and Deployment Considerations, (Indianapolis, Macmillan Technical Publishing: 2000)
E-Commerce: lebih pada aspek keterhubungan external dari sebuah perusahaan. Umumnya suatu transaksi perniagaan sifatnya rahasia (untuk kepentingan-kepentingan tertentu, misalnya pada perpajakan sifatnya terbuka). Padahal Internet tidak aman.
Dalam
kriptografi,
Public Key Infrastructure (
PKI) adalah sebuah cara untuk otentikasi, pengamanan data dan perangkat anti sangkal. Secara teknis, PKI adalah implementasi dari berbagai teknik kriptografi yang bertujuan untuk mengamankan data, memastikan keaslian data maupun pengirimnya dan mencegah penyangkalan.
Teknik-teknik kriptografi yang digunakan antara lain: - fungsi hash, - algoritma enkripsi simetrik, dan - algoritma enkripsi asimetrik. Fungsi hash akan digunakan bersama dengan algoritma enkripsi asimetrik dalam bentuk tanda tangan digital untuk memastikan integritas dan keaslian berita/data berikut pengirimnya. Algoritma enkripsi simetrik digunakan untuk mengamankan data dengan cara enkripsi. Dalam PKI penggunaan algoritma enkripsi simetrik tidak langsung didefinisikan tetapi telah diimplementasikan oleh berbagai perangat lunak. Secara garis besar PKI diwujudkan dalam bentuk kolaborasi antar komponen-komponennya.
Komponen-komponen PKI antara lain: - Subscriber, - Certification Authority (CA), - Registration Authority (RA), - Sertifikat Digital. Secara praktis wujud PKI adalah penggunaan sertifikat digital. Sertifikat digital adalah sebuah file komputer yang berisi data-data tentang sebuah public key, pemiliknya (subscriber atau CA), CA yang menerbitkannya dan masa berlakunya.
PKI telah diimplementasikan dengan berbagai aplikasi seperti S/MIME, HTTPS, VPN, dll. Anda dapat melihat fitur S/MIME pada software email yang terkenal seperti Outlook Express, Mozilla Mail/Thunderbird, dan Evolution.
“infrastruktur sekuriti yang diimplementasikan menggunakan konsep dan teknik kriptografi kuni publik”.
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
5. Relying Party
1
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 (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)
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 adalah pihak yang mempercayai keberadaan dan keabsahan suatu sertifikat digital.
Certification 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
Perhatikan bahwa sertifikat digital dari root CA selalu ditandatangani oleh dirinya sendiri (self signed certificate).
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.
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.
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.
Jika pada awalnya sudah dirasakan kebutuhan untuk hubungan antar domain, maka sebuah struktur baku yang hirarkis dapat menjadi model yang baik. Bahkan pada umumnya, model hubungan yang hirarkis diinisiasi / dimulai oleh sebuah root CA yang memiliki inisiatif untuk membangun sebuah hierarchial trust tree.
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.
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.
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.
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
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 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.
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.
Klik disini untuk melanjutkan »»
