ANALISIS DAN IMPLEMENTASI CERTIFICATE
AUTHORITIES (CA) DALAM PUBLIC SWITCHED TELEPHONE
NETWORK (PSTN)
ABI SUPIYANDI
DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
ANALISIS DAN IMPLEMENTASI CERTIFICATE
AUTHORITIES (CA) DALAM PUBLIC SWITCHED TELEPHONE
NETWORK (PSTN)
ABI SUPIYANDI
Skripsi
Sebagai salah satu syarat untuk memperoleh gelar
Sarjana Komputer pada
Departemen Ilmu Komputer
DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
BOGOR
2010
ABSTRACT
ABI SUPIYANDI. Analysis and Implementation of Certificate Authorities (CA) on Public Switched Telephone Network (PSTN). Under supervision of Dr. SUGI GURITMAN.
Secure Telephone Protocol has ability to authenticate involved party and keep the secrecy of the message sent over the protocol. The secrecy of the message archieved by using symmetric key cryptographic scheme, and authentication archieved using public key cryptographic scheme. One of several party involved in the protocol and hold an important function called Certificate Authorities or CA. CA responsible for generating public key pair for other party involved in the protocol.
When CA generates public key pair, several primitive cryptographic scheme used for guarantee the security of the key. Two of them are hash function SHA-1 and El-Gamal public key scheme embedded in Digital Signature Algorithm scheme. The prototype implementing the scheme above developed using Java programming language with JCE addition from Bauncy Castle.
The analysis towards implemented prototype indicates that the prototype still has some flaws to be implemented in real world.
Keywords: Certificate Authorities, Secure Telephone, Bouncy Castle provider, Public Key Infrastructure.
Judul : Analisis dan Implementasi Certificate Authorities (CA) pada Public Switched Telephone Network (PSTN)
Nama : Abi Supiyandi NRP : G64051846 Menyetujui: Pembimbing Dr. Sugi Guritman NIP 196209271992031004 Mengetahui:
Ketua Departemen Ilmu Komputer Institut Pertanian Bogor
Dr. Ir. Sri Nurdiati, M.Sc NIP 19601126 198601 2001
PRAKATA
Syukur Alhamdulillah penulis panjatkan kepada Allah SWT atas limpahan rahmat dan karunia-Nya sehingga penulis dapat menyelesaikan penelitian ini. Sholawat dan salam semoga selalu tercurahkan kepada Nabi Besar Muhammad SAW, keluarga, para sahabat, serta pengikutnya hingga akhir jaman.
Penulis sadar bahwa banyak pihak yang telah banyak membantu dalam penyelesaian penelitian dan karya tulis ini. Oleh karena itu, penulis ingin mengucapkan terima kasih kepada:
1. Kedua orang tua tercinta: Djupri Suhendri dan Otih Maryati atas limpahan doa, kasih sayang, semangat, dan pengorbanannya selama ini,
2. Saudara tersayang Ismasari, Nita, dan Sepri atas doa dan dukungannya, 3. Bapak Sugi Guritman atas bimbingannya selama ini,
4. Bapak Hendra Rahmawan dan Ibu Sri Wahjuni atas ketersediaanya menjadi dosen penguji serta masukan terhadap karya ilmiah ini,
5. Dosen-dosen Departemen Ilmu Komputer atas segala ilmu yang bermanfaat, 6. Orang tua kedua, keluarga Bu Noerma atas segala dukungannya selama ini,
7. Sahabat-sahabat yang tergabung dalam Ilkom42 atas yang memberi warna dalam kehidupan saya 5 tahun ke belakang,
8. Sahabat-sahabat satu pondok Assalam atas segala kegilaannya,
9. Segenap Companion yang selalu setia menemani penulis baik dalam suka maupun duka, 10. Serta pihak-pihak lain yang membantu penulis dan tidak bisa penulis sebutkan satu
persatu, terima kasih banyak.
Penulis menyadari bahwa penulisan karya tulis ini terdapat banyak kekurangan dalam berbagai hal karena keterbatasan kemampuan penulis. Oleh karena itu penulis menerima masukan baik berupa kritik maupun saran yang membangun demi kesempurnaan karya tulis ini. Penulis berharap semoga karya tulis ini bisa bermanfaat bagi siapa saja yang membacanya.
Bogor, Oktober 2010
RIWAYAT HIDUP
Penulis dilahirkan di Sukabumi pada tanggal 4 April 1987 dari ayah Djupri Suhendri dan ibu Otih Maryati. Tahun 2002 penulis menempuh pendidikan menengah atas di SMA Negeri 1 Cibadak program IPA dan lulus tahun 2005. Tahun 2005 penulis diterima sebagai mahasiswa di Institut Pertanian Bogor (IPB) melalui jalur USMI.
Tahun 2006 Penulis diterima sebagai mahasiswa Departemen Ilmu Komputer Fakultas Matematika dan Ilmu Pengetahuan Alam (FMIPA) dengan minor Fisika Instrumentasi. Pada tahun 2009 penulis melakukan praktik kerja lapangan di PT Lembu Jantan Perkasa Serang selama satu bulan.
DAFTAR ISI Halaman DAFTAR GAMBAR...v DAFTAR LAMPIRAN...v PENDAHULUAN...1 Latar Belakang...1 Tujuan...1 Ruang Lingkup...1 TINJAUAN PUSTAKA...1 Protokol...1
Algoritme Kunci Publik...2
Fungsi Hash...2
SHA-1...2
Tanda Tangan Digital...2
DSA...2
Sertifikat Digital...3
Certificate Authorities (CA)...3
Authentication Center (AC)...4
Signaling System 7 (SS7)...4
Proposed Security Architecture...4
METODE PENELITIAN...6 Ancaman...6 Kebijakan...7 Spesifikasi...7 Perancangan...7 Implementasi...7 Pengujian...7 Lingkungan Pengembangan...7 PEMBAHASAN...7 Ancaman...7 Kebijakan...8 Spesifikasi...8 Perancangan...10 Implementasi...12 Pengujian...17 KESIMPULAN...17 Kesimpulan...17 Saran...17 DAFTAR PUSTAKA...17
DAFTAR GAMBAR
Skema pembangkitan tanda tangan digital pada DSA...3
Skema verifikasi tanda tangan digital...3
Skema Jaringan SS7...4
Skema arsitektur telepon aman...4
Skema otentikasi sistem...5
Skema otentikasi pelanggan...6
Skema keamanan suara pada arsitektur telepon aman...6
Metode penelitian...7
Skema proses pendaftaran pelanggan...9
Langkah-langkah dalam pembangkitan CRL...10
Skema rantai sertifikat...11
Diagram alir pembangkitan sertifikat...11
Diagram alir pembangkitan CRL...12
DAFTAR LAMPIRAN Tabel Hasil Pengujian...20
Format Sertifikat Digital X509 ...22
PENDAHULUAN Latar Belakang
Jaringan komunikasi suara dengan telepon saat ini dirasa sangat tidak aman. Beberapa waktu lalu sempat marak pemberitaan mengenai kasus-kasus terkait hukum terkuak berkat rekaman komunikasi lewat telepon. Hampir bersamaan dengan pemberitaan kasus tersebut, muncul juga pemberitaan mengenai betapa mudahnya seseorang atau lembaga baik yang memiliki otoritas maupun tidak untuk menyadap sekaligus merekam suatu pembicaraan telepon. Kemudahan ini semakin dipermudah lagi dengan infrastruktur telepon khususnya di indonesia yang memang tidak dilengkapi dengan perlindungan kerahasiaan terhadap data suara yang hilir mudik dalam jaringan yang ada. Dari dua hal yang mendasar diatas, salah satu solusi yang mungkin dilakukan oleh penyedia jasa telepon adalah dengan menambah kemampuan keamanan berupa kerahasiaan ke dalam jaringan yang telah ada.
Beberapa usulan telepon dengan kemampuan kerahasiaan informasi yang disampaikan terus dikembangkan. Salah satu contoh yang populer adalah telepon STU III (Secure Telephone Unit : third generation) yang dikembangkan oleh NSA pada tahun 1987. Telepon ini menggunakan suatu jalur komunikasi khusus dan bekerja secara berpasangan. Kemanan berupa kerahasiaan informasi didapat dengan mengenkripsi sinyal suara menggunakan protokol enkripsi kunci simetrik.
Dalam sebuah jurnal yang ditulis oleh Syarif dan Wijesekera pada tahun 2003, dijabarkan suatu usulan protokol keamanan yang dapat diterapkan pada Public Switched Telephone
Network (PSTN). Protokol yang diusulkan
diharapkan mampu memberikan keamanan berupa kerahasiaan data suara dalam jaringan. Lebih jauh lagi, protokol yang diusulkan juga memberikan aspek keamanan lain berupa non-repudiasi dan otentikasi sehingga kasus penipuan yang menggunakan sarana telepon dapat semakin diminimalisir.
Protokol yang diusulkan memiliki tiga tambahan node utuk diimplementasikan dalam infrastruktur yang telah ada. Ketiga node tersebut adalah Certificate Authorities (CA),
Authentication Center (AC), dan unit telepon
khusus. Kedua node yang pertama merupakan suatu aplikasi dalam lapisan Application
Service Element (ASE) dalam model protokol Signaling System 7 (SS7), sedangkan node unit
telepon merupakan suatu unit telepon dengan kemampuan kriptografi berupa enkripsi dan dekripsi.
Pada penelitian ini akan dijabarkan suatu implementasi prototype certificate authorities sederhana. Implementasi pada penelitian ini menggunakan bahasa pemrograman Java, dan hanya terfokus kepada proses pembangkitan dan penyimpanan sertifikat digital. Prototype yang dihasilkan kemudian dianalisis sisi kemanan implementasinya.
Tujuan
Tujuan dari penelitian ini adalah:
1. Mengimplementasikan suatu prototype CA sederhana.
2. Menganalisis CA untuk diimplementasikan dalam dunia nyata.
Ruang Lingkup
Ruang lingkup penelitian ini adalah satu bagian dari arsitektur protokol telepon aman yang diusulkan oleh Sharif dan Wijesekera, yaitu membahas tentang CA. Bahasan dari penelitian ini mencakup pembangkitan sertifikat digital, pembangkitan Certificate Revocation
List (CRL), dan pembuatan basis data untuk
sertifikat digital beserta CRL. TINJAUAN PUSTAKA Protokol
Protokol adalah serangkaian langkah yang melibatkan dua pihak atau lebih dan dirancang untuk suatu tugas tertentu (Ferguson dan Schneier 2003). Protokol akan memiliki karakteristik sebagai berikut:
1. Protokol memiliki urutan dari awal hingga akhir.
2. Setiap Langkah harus dilaksanakan secara berurutan.
3. Suatu langkah tidak dapat dikerjakan bila langkah sebelumnya belum selesai.
4. Diperlukan dua pihak atau lebih untuk melaksanakan suatu protokol.
5. Protokol harus mencapai suatu hasil.
6. Setiap pihak yang terlibat dalam protokol harus mengetahui terlebih dahulu mengenai protokol dan seluruh langkah yang akan dilaksanakan.
7. Setiap pihak yang terlibat harus menyetujui untuk mengikutinya.
8. Protokol tidak boleh rancu, setiap langkahnya harus didefinisikan dengan baik dan tidak boleh ada kemungkinan untuk suatu kesalahpahaman.
9. Protokol harus lengkap, harus ada aksi untuk setiap kemungkinan situasi.
Algoritme Kunci Publik
Algoritme kunci publik atau biasa disebut dengan asymmetric algorithm adalah algoritme yang dirancang sedemikian rupa sehingga kunci yang digunakan untuk proses enkripsi berbeda dengan kunci yang digunakan untuk proses dekripsi (Ferguson dan Schneier 2003). Lebih jauh lagi, kunci untuk dekripsi tidak bisa didapatkan dari kunci untuk enkripsi. Algoritme kunci publik disebut demikian karena kunci untuk enkripsinya dapat dibuat publik, artinya seseorang yang tidak dikenal dapat menggunakan kunci tersebut untuk mengenkripsi suatu pesan, tapi hanya pihak tertentu yang memiliki pasangan kunci yang tepat saja yang bisa mendekripsi pesan tersebut. Dalam algoritme kunci publik, kunci enkripsi bisa disebut sebagai kunci publik, dan kunci untuk dekripsi biasa disebut sebagai kunci pribadi.
Proses untuk mengenkripsi dengan kunci publik K dapat dinotasikan sebagai berikut:
E
K
M =C
Proses untuk mendekripsi dengan kunci pribadi KP dapat dinotasikan sebagai berikut:
D
KP
C =M
Fungsi Hash
Fungsi Hash adalah sebuah fungsi, baik matematis maupun fungsi lainnya yang mengambil suatu string input (biasa disebut
pre-image) dengan panjang sembarang dan
mengubahnya menjadi string output (disebut nilai hash atau digest) dengan panjang tetap
(Ferguson dan Schneier 2003). SHA-1
Secure Hash Algorithm (SHA) merupakan
sebuah fungsi hash yang dirancang oleh NSA lalu distandarkan oleh NIST (Ferguson dan Scheier 2003). SHA didasarkan pada algoritme MD4 yang dikembangkan oleh Ronald L. Rivest dari MIT. salah satu varian dari SHA adalah SHA-1. SHA-1 ini menerima masukan dengan ukuran blok maksimum 64 bit dan menghasilkan suatu message digest dengan panjang 160 bit.
Tanda Tangan Digital
Tanda tangan digital adalah suatu primitif kriptografi yang menjadi dasar penting dalam otentikasi, otorisasi, dan non-repudiasi. Kegunaan tanda tangan digital adalah sebagai bukti yang digunakan suatu pihak untuk mengikat identitasnya kepada suatu bentuk informasi (Menezes 1996). Konsep tanda tangan digital terdisi dari dua fungsi yaitu fungsi pemberian tanda tangan suatu dokumen dan fungsi verifikasi. Fungsi verifikasi digunakan untuk memeriksa tanda tangan yang telah dibuat.
DSA
DSA atau Digital Signature Algorithm adalah standar yang digunakan oleh Amerika serikat untuk tanda tangan digital. DSA diusulkan oleh NIST pada tahun 1991 untuk digunakan dalam DSS (Digital Signature
Standard). Keamanan algoritme ini bergantung
kepada masalah logaritme diskret, mirip dengan algoritme Diffie-hellman dan Elgamal. Berikut adalah algoritme untuk pembangkitan pasangan kunci untuk DSA (Menezes 1996):
1. Memilih suatu prima q sehingga 2159 <
q < 2160.
2. Memilih t sehingga 0 ≤ t ≤ 8, lalu pemilihan bilangan prima p dengan 2511+64t < p < 2512+64t, dengan q membagi
(p1).
3. Memilih suatu generator α dari suatu grup unik siklik dengan orde q dalam
field p.
a) Memilih suatu elemen g dalam field p dan menghitung α=g(p-1)/q
mod p.
langkah a.
4. Memilih suatu random integer a dengan 1 < a < q-1.
5. Meghitung y= αa mod p.
6. Kunci publik yang dibangkitkan adalah (p, q, α, y); dan kunci pribadinya adalah a.
Skema untuk pembangkitan tanda tangan digital dapat dilihat pada Gambar 1, sedangkan algoritme yang digunakan adalah sebagai berikut:
1. Memilih suatu random integer k, 0< k<
q.
2. Menghitung r= (αk mod pI) mod q. 3. Menghitung k-1 mod q.
4. Menghitung s=k-1(h(m)+ar) mod q. 5. Tanda tangan digital untuk pesan m
adalah pasangan (r,s).
Skema untuk proses verifikasi tanda tangan digital dapat dilihat pada Gambar 2, sedangkan untuk algoritme yang digunakan adalah sebagai berikut:
1. Mendapatkan kunci publik pembuat tanda tangan digital.
2. Melakukan verifikasi apakah 0<r<q dan 0 < s < q, jika keduanya tidak memenuhi, maka tanda tangan tersebut ditolak.
3. Menghitung w=s-1 mod q dan h(m). 4. Menghitung u1=w.h(m) mod q dan
u2=rw mod q.
5. Menghitung v=(αu1yu2 mod p) mod q. 6. Terima tanda tangan jika dan hanya
jika v=r.
Sertifikat Digital
Sertifikat digital atau biasa disebut sebagai sertifikat kunci publik adalah sebuah dokumen elektronik yang digunakan untuk menjamin bahwa suatu kunci publik dimiliki oleh hanya satu pihak. Mengacu kepada dokumen RFC X.509, sampai saat ini sertifikat telah memiliki tiga versi: v1 yang dikeluarkan tahun 1988, v2 dirilis tahun 1993, dan terakhir v3 yang dirilis tahun 1996 (Hook 2005). Sertifikat v1 merupakan sertifikat paling sederhana dan memiliki sembilan field yaitu certificate fields,
version, serial number, signature algorithm, issuer, validity period, subject name, subject-public key information, dan issuer's signature.
Sertifikat v2 merupakan pengembangan dari sertifikat v1 dan memiliki semua field dalam sertifikat v1 dengan tambahan issuer unique
identifier dan subject unique identifier. Kedua field tersebut ditambah untuk menangani
kemungkinan adanya kesamaan dalam field
subject name dan issuer. Sertifikat v3
merupakan sertifikat yang paling banyak digunakan hingga saat ini. Sertifikat v3 berisi semua field yang ada dalam sertifikat v2 ditambah dengan field Extension yang dapat berisi informasi tentang kunci yang disimpan didalamnya, atribut dari subject name dan
issuer, batasan dari certification path, serta
ekstensi yang berkaitan dengan CRL.
Certificate Authorities (CA)
Certificate authorities (CA) adalah suatu
pihak yang bertanggung jawab dalam mengeluarkan sertifikat kunci publik. Detail tugas CA menurut Syarif dan Wijesekera (2003) untuk digunakan dalam telepon aman adalah sebagai berikut:
1. Membangkitkan pasangan kunci publik dan pribadi.
2. Membangkitkan sertifikat digital untuk
Gambar 1 Skema pembangkitan tanda tangan pada DSA (Hook 2005).
Gambar 2 Skema verifikasi tanda tangan digital (Hook 2005)
setiap pasangan kunci yang dibangkitkan. 3. Menyimpan sertifikat digital dalam basis
data CA dan tersedia untuk publik.
4. Berantarmuka dengan CA lain dalam jaringan telepon publik.
5. Menyimpan dan merawat CRL atau daftar sertifikat yang diragukan atau sudah tidak berlaku lagi.
Authentication Center (AC)
Authentication Center menurut Syarif dan Wijesekera (2003) adalah bagian protokol yang bertugas dalam membuat dan mendistribusikan kunci untuk enkripsi, otentikasi telepon dan otentikasi pelanggan. Selain itu AC juga bertanggung jawab menjaga basis data yang digunakan untuk otentikasi. Basis data ini berisi informasi mengenai pelanggan seperti identitas,
password dan informasi lain.
Signaling System 7 (SS7)
Signaling System 7 adalah sebuah arsitektur untuk melakukan out-of-band signaling sebagai tulang punggung dalam pembentukan suatu panggilan telepon, billing, routing, dan pertukaran informasi pada public switched
telephone network (Illuminet 2000). Jaringan
SS7 yang ada dibangun oleh beberapa komponen berikut ini, dihubungkan oleh kanal sinyal:
1. Signal Switching Points (SSPs), merupakan switch telepon yang dilengkapi dengan perangkat lunak untuk persinyalan dan kanal terminal untuk persinyalan. Komponen ini secara umum mengawali, mengakhiri, atau memindahkan panggilan.
2. Signal Transfer points (STPs), merupakan switch untuk paket-paket jaringan SS7. Komponen STP menerima dan menyalurkan paket pesan sinyal kepada node yang dituju oleh paket pesan tersebut. STP juga dapat melakukan fungsi untuk routing khusus.
3. Signal control points (SCPs), merupakan basis data yang menyediakan informasi yang dibutuhkan untuk kemampuan pemrosesan panggilan bersifat lanjut. Skema untuk jaringan SS7 dapat dilihat pada Gambar 3. A,B,C, dan D merupakan SSP. L, M,
P dan Q merupakan SCP, dan W, X, Y, dan Z merupakan pasangan STP.
Proposed Security Architecture
Menurut Sharif dan Wijesekera (2003), arsitektur telepon aman terdiri dari certificate
authorities (CA), authentication centers (AC),
dan suatu unit telepon dengan kemampuan kriptografi Ketiganya bekerja diatas jaringan telepon yang sudah ada. Skema arsitektur telepon aman dapat dilihat pada Gambar 4.
CA dan AC diimplementasikan pada lapisan
application service element dalam model
protokol SS7. CA bertanggung jawab untuk membangkitkan pasangan kunci publik dan pribadi, membuat sertifikat digital untuk kunci publik, dan menyimpan sertifikat digital tersebut dalam suatu basis data yang tersedia untuk publik serta berinteraksi dengan CA lain dalam jaringan telepon. Sebagai tambahan, CA juga bertanggung jawab dalam menjaga
certificate revocation list (CRL) yang berisi
daftar kunci yang telah berakhir masa berlakunya dan kunci yang diragukan. Sebuah sertifikat digital merupakan suatu dokumen yang mengikat suatu kunci publik ke satu nomor telepon dan ditandatangani oleh CA dari perusahaan telepon yang menyediakan layanan keamanan.
Gambar 4 Skema Arsitektur Telepon Aman Gambar 3 Skema Jaringan SS7
AC bertanggung jawab dalam membangkitkan dan mendistribusikan kunci enkripsi, dan mengotentikasi telepon dan pelanggan. AC juga bertanggung jawab dalam menjaga basis data untuk otentikasi yang berisi profil pelanggan. Profil pelanggan berisi identitas pelanggan beserta password dan beberapa informasi lain. AC dapat beriteraksi dengan AC lain dalam jaringan untuk memberikan layanan kepada pelanggan dari luar daerah.
Tujuan yang ingin dicapai dalam arsitektur telepon aman adalah otentikasi dan keamanan data suara. Otentikasi dicapai dengan menggunakan kriptografi kunci publik, sedangkan keamanan data suara dicapai dengan menggunakan kriptografi kunci simetrik.
Arsitektur telepon aman menggunakan kriptografi kunci publik untuk mengakomodasi fungsi otentikasi. CA suatu perusahaan telekomunikasi membangkitkan pasangan kunci publik/pribadi dan sebuah sertifikat digital untuk AC. Sertifikat digital yang dibangkitkan disimpan dalam basis data CA yang tersedia untuk umum. Pasangan kunci disimpan dalam suatu file aman dalam server CA.
Ketika ada suatu pelanggan meminta layanan telepon, CA akan membangkitkan pasangan kunci dan sertifikat digital untuk pelanggan tersebut. Sertifikat digital akan disimpan dalam profil pelanggan dan basis data CA. Profil pelanggan berisi informasi seperti lokasi, nama pelanggan, informasi tagihan, dan lail-lain. Profil pelanggan ini bisa disimpan dalam Line Information Database (LIDB) atau
Home Location Register (HRL) khusus bagi
pelanggan yang memiliki telepon wireless. Pada unit telepon pelanggan disimpan pasangan kunci publik/pribadi milik pelanggan disertai kunci publik AC. Kunci-kunci ini disimpan sedemikian rupa sehingga tidak perlu diketahui oleh pelanggan yang bersangkutan. Ketika pasagan kunci publik/pribadi pelanggan tersebut diragukan keabsahannya, CA akan menarik kembali sertifikat yang telah dikeluarkannya dan menyimpannya dalam CRL dan profil telepon, lalu membangkitkan pasangan kunci yang baru.
Ketika pelanggan mendaftarkan dirinya untuk bisa mendapatkan layanan keamanan, pelanggan tersebut harus memilih suatu pasangan ID dan password. Pasangan ID dan password tersebut disimpan dalam basis data
untuk otentikasi yang dimiliki AC bersama dengan profil pelanggan. Dengan cara ini, setiap pelanggan yang telah mendaftarkan dirinya untuk mendapatkan layanan telepon aman, dapat menggunakan telepon mana saja untuk mendapatkan layanan telepon aman tersebut.
Dua otentikasi terjadi dalam arsitektur telepon aman. Otentikasi yang pertama adalah otentikasi sistem yang bisa diajukan baik oleh unit telepon pelanggan maupun AC. Otentikasi sistem dilakukan untuk mengetahui apakah sistem telah bekerja dengan benar, dan sebagai bahan untuk mengambil keputusan apakah suatu unit telepon diperbolehkan untuk menerima layanan dari jaringan. Skema otentikasi sistem dapat dilihat pada Gambar 5. Berikut adalah langkah-langkah dalam otentikasi sistem dengan AC sebagai pihak yang memulai: 1. AC membangkitkan suatu bilangan random
R#, mengenkripsinya dengan kunci pribadi AC K*AC dan mendapatkan SAC=EK*AC(R#).
2. AC mengirimkan SAC ke unit telepon
pelanggan menggunakan kanal kontrol dan kanal suara.
3. Unit telepon pelanggan menerima SAC,
mendekripsinya dengan kunci publik AC KAC untuk mendapatkan kembali
R#=DKAC(SAC).
4. Unit telepon melakukan hal yang sama dengan langkah pertama untuk medaptkan ST=EK*T(R#), lalu mengirimkannya ke AC.
5. AC menerima ST, kemudian melakukan
langkah ke tiga untuk mendapatkan kembali R#.
Otentikasi kedua yang digunakan adalah otentikasi pelanggan. Gambar 6 menunjukkan skema untuk otentikasi pelanggan. Langkah-langkah untuk otentikasi pelanggan adalah
sebagai berikut:
1. Ketika pelanggan meminta suatu koneksi yang aman, interactive voice response(IVR) menginstruksikan agar memasukkan ID dan
password pelanggan (ID & P).
2. Unit telepon kemudian mengenkripsi ID dan password dengan kunci publik AC (KAC)
dengan algoritme enkripsi E (C=EKAC(ID&P)) dan mengirimkannya ke
AC menggunakan kanal kontrol dan kanal suara.
3. AC mendekripsi C menggunakan kunci pribadi AC K*AC dengan algoritme dekripsi
D dan mendapatkan ID & P pelanggan. 4. AC memverifikasi ID dan password yang
diterima dengan ID dan password yang dimiliki AC dalam basis data otentikasi miliknya. Jika hasilnya benar, pelanggan tersebut diperbolehkan untuk menerima layanan telepon aman.
Setelah pelanggan yang melakukan panggilan berhasil diotentikasi, AC kemudian melakukan otentikasi untuk pelanggan yang akan dipanggil menggunakan langkah yang sama.
Keamanan data suara dicapai dengan mengenkripsi sinyal suara antara dua telepon menggunakan algoritme kriptografi kunci simetrik. Enkripsi suara dimulai ketika telepon dan pelanggan telah diotentikasi dan pelanggan yang dipanggil menerima permintaan untuk melakukan layanan telepon aman. Gambar 7 menunjukkan skema untuk mencapai keamanan suara dalam arsitektur telepon aman. Berikut merupakan langkah-langkah dalam mencapai telepon aman tersebut:
1. AC membangkitakan kunci enkripsi KE
dan mengenkripsinya menggunakan kunci publik masing-masing telepon yang akan melakukan pembicaraan.
2. Ketika kunci simetrik terenkripsi diterima, unit telepon mendekripsinya menggunakan kunci private masing-masing unit telepon. Kunci simetrik ini kemudian digunakan untuk mengenkripsi dan mendekripsi sinyal suara.
METODE PENELITIAN
Penelitian ini dilakukan dengan menggunakan metode Security Lifecycle. Metode ini terdiri dari 6 tahap yaitu: (1) Ancaman, (2) Kebijakan, (3) Spesifikasi, (4) Perancangan, (5) Implementasi, dan (6) Operasi dan Pemeliharaan (Bishop, 2003). Gambar 8 menunjukkan skema dari metode Security Lifecycle. Penelitian ini dibatasi hanya sampai pada tahap (5) karena keluaran dari penelitian ini hanya sampai kepada prototype dari CA. Ancaman
Ancaman merupakan kekerasan potensial dalam suatu sistem keamanan. Analisis yang dilakukan bertujuan untuk mengetahui kebutuhan keamanan pada suatu sistem CA. Data yang disimpan dalam suatu server CA seperti pasangan kunci publik/pribadi mutlak untuk dilindungi karena disitulah letak keamanan otentikasi dari protokol telepon aman. Suatu sistem CA yang dibangun perlu memperhatikan beberapa ancaman yang dpaat dibagi menjadi 4 kelas, yaitu:
1. Disclosure, pengaksesan informasi oleh pihak yang tidak berwenang.
2. Deception, penerimaan data yang tidak benar.
Gambar 7 Skema keamanan suara pada arsitektur telepon aman
3. Disruption, gangguan atau pencegahan dari langkah operasi yang benar.
4. Unsurpation, pengaturan beberapa bagian sistem oleh pihak yang tidak berwenang. Kebijakan
Kebijakan adalah suatu penyataan atas apa saja yang diperbolehkan dan apa saja yang tidak dalam menjalankan suatu sistem. Dalam sistem CA, contoh kebijakan diperlukan ketika sistem akan membuat suatu sertifikat digital atas pihak tertentu, atau ketika sertifikat digital suatu pihak akan dimasukkan ke dalam CRL.
Spesifikasi
Spesifikasi dapat ditentukan setelah kebijakan sistem dibuat. Spesifikasi adalah penyataan baik formal maupun informal mengenai fungsi sistem yang akan dikembangkan (Bishop, 2003). Spesifikasi dapat berupa bagian low-level, kombinasi kode program dengan logika dan hubungan kewaktuan untuk menetapkan tugas yang dikerjakan.
Perancangan
Rincian kebutuhan dari sistem disusun dalam tahap perancangan. Rincian tersebut tidak diperbolehkan keluar dari spesifikasi yang telah ditentukan pada tahap sebelumnya.
Perancangan ini dibuat sehingga mencakup bagaimana CA membangkitkan pasangan kunci,
membuat sertifikat, dan bagaimana CA menyimpan dan merawat CRL.
Implementasi
Pada tahap ini hasil perancangan akan diimplementasikan menjadi suatu sistem dengan lingkungan implementasi sebagai berikut: 1. Platform: Java 1.6.
2. JCE dari Bouncy Castle. 3. GUI: java Swing.
4. Skema kunci Publik skema Elgamal dalam DSA.
5. Fungsi Hash: SHA-1. Pengujian
Tahap pengujian dilakukan untuk menguji apakah sistem memberika keluaran yang sesuai dengan yang diharapkan. Pengujian pada penelitian ini dilakukan dengan Metode Black
Box.
Lingkungan Pengembangan
Perangkat keras dan perangkat lunak yang digunakan dalam penelitian ini berupa notebook dengan spesifikasi sebagai berikut:
1. Prosesor AMD Turion X2. 2. Memori 1,2 GB.
3. Sistem operasi Linux Ubuntu 9.04. 4. IDE NetBeans 6.5.
5. RDBMS Mysql 14.12 Distrib 5.0.75. PEMBAHASAN Ancaman
Keunggulan arsitektur yang diusulkan oleh Sharif dan Wijisekera adalah pada kemampuannya untuk memberikan layanan kerahasiaan dari percakapan yang dilakukan dan otentikasi pelanggan layanan telepon. Untuk bisa mencapai kemampuan tersebut, terutama dalam memberikan layanan otentikasi, keamanan data yang disimpan dalam CA menjadi hal yang sangat penting untuk diperhatikan dalam perancangan suatu CA. Keamanan data ini mutlak diperlukan karena CA merupakan suatu pihak dalam arsitektur yang mutlak harus bisa dipercaya baik oleh pelanggan, maupun oleh pihak lain yang
Gambar 8 Metode Penelitian (Bishop 2003)
menjadi bagian dalam arsitektur telepon aman. Oleh karena itu pembangunan suatu sistem untuk CA dengan data yang perlu dilindungi didalamnya perlu dimulai dari analisis terhadap ancaman-ancaman yang mungkin menyerang sistem CA tersebut.
CA memiliki suatu basis data untuk menyimpan pasangan kunci publik/pribadi beserta sertifikat digital pasangan kunci tersebut, dan CRL. Pasangan kunci ini nantinya digunakan oleh AC untuk melakukan otentikasi dan pengiriman kunci simetrik untuk mencapai kerahasiaan suara. Beberapa ancaman potensial yang dapat menyerang CA diantaranya adalah: 1. Pengintaian. Pengintaian atau snooping
adalah penahanan informasi oleh pihak yang tidak berwenang. Ancaman ini dapat didefinisikan bahwa terdapat suatu pihak tertentu di luar pihak yang secara resmi terlibat dalam arsitektur telepon aman berusaha untuk ikut membaca informasi yang ada dalam basis data CA. Dalam kaitannya dengan pengamanan server CA, pihak luar telah berhasil mengakses basis data yang dimiliki oleh CA. Tujuan serangan seperti ini biasanya digunakan untuk mendapatkan informasi yang digunakan oleh kriptanalis, atau lebih jauh, digunakan untuk penyadapan telepon aman. Ancaman snooping dapat diatasi dengan menyimpan kunci pribadi dalam suatu
container yang memiliki kemampuan
kerahasiaan pesan.
2. Modifikasi. Modifikasi atau pengubahan adalah pengubahan informasi yang dilakukan oleh pihak penyerang. Dalam konteks CA, perubahan terhadap kunci pribadi seharusnya diikuti oleh perubahan kunci simetri pasangannya dan sebaliknya. Perubahan ini juga harusnya diikuti oleh perubahan pasangan kunci yang terpasang pada unit telepon yang dimiliki pengguna sehingga pasangan kunci yg ada di CA dan di unit telepon akan selalu sinkron. Ancaman berupa pengubahan kunci publik/pribadi dapat mengarah ke dalam kelas ancaman deception. Jika pihak penyerang hanya mengubah salah satu saja, sebagai contoh mengubah kunci yang ada di CA, ketika AC akan melakukan otentikasi telepon dengan kunci yang telah diubah tersebut, maka otentikasi akan gagal karena AC akan menganggap unit telepon tersebut tidak terdaftar atau ilegal meskipun unit
telepon tersebut legal. Layanan kemanan berupa integritas digunakan untuk menghindari akibat yang ditimbulkan dari ancaman ini. Sedangkan jika ancaman ini telah benar-benar terjadi dan mulai meninggalkan dampak, maka CRL digunakan untuk menanggulanginya.
Kebijakan
Kebijakan yang diterapkan dalam pengembangan arsitektur telepon aman mengacu kepada jurnal yang ditulis oleh Sharif dan Wijesekera pada tahun 2003. Jurnal ini menjelaskan arsitektur yang dapat diterapkan untuk dapat mencapai kerahasiaan dalam komunikasi menggunakan telepon dengan tanpa melakukan perubahan signifikan terhadap arsitektur PSTN yang telah ada. Arsitektur yang diterangkan dapat digunakan untuk fungsi otentiksi dan kerahasiaan percakapan yang dilakukan lewat jaringan telepon.
Dalam menjalankan protokol yang berkaitan dengan pelanggan, ada beberapa kebijakan yang harus dipatuhi agar jaminan kerahasiaan suara dan otentikasi dapat terpenuhi, yaitu:
1. Satu unit telepon hanya boleh memiliki satu pasangan kunci publik/pribadi.
2. Satu pelanggan bisa memiliki beberapa unit telepon.
3. Satu pelanggan bisa memiliki satu atau lebih ID dan password.
4. Kunci simetrik yang digunakan untuk mencapai kerahasiaan pesan suara hanya digunakan sekali dan langsung dimusnahkan begitu komunikasi selesai dilakukan.
Spesifikasi
Berdasarkan ruang lingkup yang telah disebutkan sebelumnya, penelitian ini hanya akan membahas mengenai bagian certificate
authorities dari keseluruhan arsitektur telepon
aman yang diusulkan oleh Sharif dan Wijesekera. Certificate authorities memiliki lima fungsi yang harus dimiliki untuk dapat menunaikan tugasnya dengan baik. Pembahasan dari penelitian ini lebih difokuskan kepada empat dari lima fungsi CA yang ada, yaitu fungsi pembangkitan pasangan kunci, pembangkitan sertifikat digital untuk pasangan kunci yang dibangkitkan, menyimpan pasangan kunci beserta sertifikat digitalnya, dan membuat dan merawat CRL.
Fungsionalitas pertama yang dapat dilayani oleh CA adalah pendaftaran pelanggan. Fungsionalitas pertama ini mencakup fungsi pembangkitan pasangan kunci publik, pembangkitan sertifikat digital kunci publik, dan penyimpanan pasangan kunci beserta sertifikatnya. Ketiga fungsi tersebut digabungkan dalam satu .
Fungsi pembangkitan pasangan kunci, sertifikat digital, dan penyimpanan dapat digabungkan dalam satu tahapan yaitu tahap pendaftaran pelanggan. Hal ini bisa dilakukan karena ketiga fungsi tersebut memang dilakukan hampir dalam waktu bersamaan dan dilakukan secara berurutan. Berikut ini adalah langkah-langkah yang dilakukan dalam proses pendaftaran:
1. Pelanggan meminta untuk berlangganan telepon.
2. CA membangkitkan pasangan kunci untuk unit telepon yang akan diberikan kepada pelanggan.
3. CA membangkitkan sertifikat digital untuk pasangan kunci yang dibangkitkan pada langkah 2.
4. CA menyimpan sertifikat dalam basis datanya, kemudian mengintalasikan pasangan kunci yang dibangkitkan pada langkah 2 beserta kunci publik AC ke dalam unit telepon yang akan diberikan kepada pelanggan.
5. Pelanggan meminta untuk layanan telepon aman.
6. Pelanggan memberikan ID dan password pilihannya.
7. AC menyimpan ID dan password pelanggan dalam basis data otentikasi miliknya.
Ilustrasi proses pendaftaran pelanggan ketika pemasangan telepon beserta pendaftaran layanan telepon aman dapat dilihat pada Gambar 9.
Satu lagi fungsi yang dimiliki oleh CA dan dikembangkan dalam penelitian ini adalah fungsi revoke sertifikat digital. Berikut ini adalah langkah-langkah ketika pelanggan ingin me-revoke sertifikat sertifikat digital dalam unit telepon yang dimilikinya dikarenakan alasan tertentu:
1. Pelanggan meminta agar sertifikat digital dalam unit telepon aman miliknya
di-revoke. Bersama permintaan ini, alasan
kenapa pelanggan meminta revoke dicantumkan.
2. CA melihat alasan yang diberikan pelanggan. Jika alasan tersebut memenuhi syarat untuk melakukan revoke, maka CA akan me-revoke sertifikat yang dimiliki pelanggan tersebut.
3. CA menyimpan informasi revoke yang telah dilakukannya dalam CRL dalam server CA. 4. CA membangkitakan pasangan kunci baru
untuk pelanggan tersebut beserta sertifikat digital pasangan kunci. Pasangan kunci diinstalasi dalam unit telepon yang kemudian diberikan kepada pelanggan.
Ilustrasi untuk proses revoke dapat dilihat pada Gambar 10.
Gambar 9 Skema proses pendaftaran pelanggan.
Bagian yang ditandai dengan garis putus-putus pada Gambar 9 dan Gambar 10 merupakan fokus pengembangan pada penelitian ini. Penggunaan ruang lingkup seperti ini diharapkan membuat ruang lingkup masalah menjadi jelas dan tidak terlalu melebar.
Perancangan
1. Perancangan arsitektur telepon aman. Arsitektur telepon aman dirancang menggunakan model infrastruktur SS7. Pada infrastruktur SS7 yang telah ada, ditambahkan dua node tambahan yaitu AC sebagai pihak yang bertanggung jawab terhadap kunci simetri dan CA yang bertanggung jawab terhadap pasangan kunci publik/pribadi. AC dan CA diimplementasikan dalam lapisan application
service elements(ASE) dalam SS7. Kedua
bagian ini dibuat terpisah satu sama-lain dan terhubung melalui pasangan STP.
Penelitian ini difokuskan kepada pengimplementasian fungsi dasar CA dari arsitektur telepon aman. Perancangan untuk fungsi pembangkitan pasangan kunci, pembangkitan sertifikat digital, dan penyimpanan keduanya digabungkan dalam satu proses perancangan yaitu proses pendaftaran pelanggan. Selain fungsi dasar, pada penelitian ini juga dirancang model basis data yang sesuai dengan kebutuhan CA.
2. Perancangan proses pendaftaran.
Proses pendaftaran pelanggan terdiri dari
tiga fungsi dasar CA, yaitu fungsi pembangkitan pasangan kunci publik/pribadi, pembangkitan sertifikat digital pasangan kunci tersebut, dan fungsi menyimpan pasangan kunci beserta sertifikat digital yang dibangkitkan ke dalam basis data yang dimiliki oleh CA. Ketiga fungsi dasar ini dikelompokkan dalam satu proses karena ketiganya dilakukan pada saat yang hampir bersamaan dan berurutan.
Pembangkitan sertifikat digital pada penelitian ini menggunakan skema rantai sertifikat. Skema rantai sertifikat ini menggunakan sertifikat digital intermediate untuk menandatangani sertifikat milik pelanggan telepon. Skema rantai sertifikat ini dapat dilihat pada Gambar 11.
Pasangan kunci publik beserta sertifikatnya disimpan dalam bentuk keystore. Keystore merupakan suatu objek yang disediakan oleh
platform Java untuk menyimpan sertifikat
digital beserta pasangan kuncinya . Satu buah
keystore bisa menyimpan beberapa pasangan
kunci beserta sertifikat yang bersesuaian dalam
container yang disebut dengan private credential.
Hasil perancangan proses pendaftaran pelanggan pada bagian pembangkitan sertifikat digital dijelaskan sebagai berikut:
a) Inisialisasi key generator untuk pasangan kunci DSA 512 bit milik CA.
b) Pembangkitan sertifikat digital CA menggunakan fungsi untuk membangkitkan self signed sertificate.
c) Pembangkitan private credential untuk menyimpan sertifikat beserta pasangan kunci CA dalam keystore.
d) Inisialisasi key generator untuk pasangan kunci intermediate.
e) Pembangkitan sertifikat digital untuk pasangan kunci intermediate yang ditandatangani oleh sertifikat CA atau
root certificate.
f) Pembangkitan private credential untuk menyimpan sertifikat beserta pasangan kunci intermediate dalam keystore. g) Inisialisasi key generator untuk pasangan
kunci end entity atau pasangan kunci pelanggan.
h) Pembangkitan sertifikat digital untuk pasangan kunci pelanggan yang
Gambar 10 langkah-langkah dalam pembangkitan CRL
ditandatangi oleh sertifikat intermediate. i) Pembangkitan private credential untuk
menyimpan pasangan kunci dan sertifikatnya di dalam keystore.
j) Pembangkitan keystore berisi tiga buah
private credential yang telah dibangkitkan pada langkah sebelumnya.
Keystore yang dihasilkan kemudian disimpan dalam server CA. Keystore disimpan dalam bentuk sebuah file dengan lokasi folder
root CA. Link menuju file keystore ini disimpan
dalam basis data CA.
Diagram alir proses pendaftaran pelanggan untuk bagian pembangkitan sertifikat digital dapat dilihat pada Gambar 12.
3. Perancangan skema pembangkitan CRL. Fungsi pembangkitan CRL dimulai dari permintaan pelanggan agar unit telepon atau nomor tertentu yang dimilikinya untuk
di-revoke. Permintaan revoke ini membutuhkan
alasan resmi kenapa unit telepon atau nomor telepon tertentu harus di-revoke.
Hasil perancangan pembangkitan CRL dijelaskan sebagai berikut:
a) Inisialisasi key generator untuk membangkitkan pasangan kunci CA. b) Pembangkitan sertifikat digital untuk CA
menggunakan fungsi untuk membangkitkan self signed certificate. c) Pembangkitan CRL dengan
menggunakan sertifikat digital CA yang telah dibangkitkan sebelumnya dan alasan kenapa unit telepon tersebut
di-revoke sebagai masukan fungsi
pembangkitan CRL.
Flowchart pada Gambar 13 menggambarkan
skema pada saat pembangkitan CRL.
4. Perancangan basis data CA.
Basis data CA dirancang untuk bisa menyimpan data berupa sertifikat digital dan CRL. Secara fisik, data yang disimpan dalam CA hanya berupa path saja. Hal ini karena pada implementasinya, sertifikat digital dan CRL disimpan dalam file khusus di luar basis data CA.
Untuk keperluan menyimpan sertifikat dan CRL, CA membutuhkan basis data dengan dua entitas yaitu sertifikat dan CRL. Entitas CRL digunakan untuk menyimpan path menuju file CRL dengan dengan nomor seri sertifikat tertentu, dan alasan kenapa sertifikat tersebut
di-revoke. Entitas sertifikat digunakan untuk
menyimpan path menuju sertifikat digital pelanggan. Selain itu, pada entitas sertifikat terdapat atribut tambahan yaitu id berupa nomor seri sertifikat, dan subject name dari sertifikat yaitu nomor telepon dari pelanggan yang bersangkutan.
Gambar 11 Skema rantai sertifikat
Gambar 12 Diagram alir pembangkitan sertifikat
Tabel 1 adalah tabel untuk hasil perancangan konseptual basis data CA. Pada tabel 1 tersebut dapat terlihat dua entitas, yaitu entitas sertifikat dan entitas CRL.
Implementasi
1. Implementasi arsitektur telepon aman. Penelitian ini hanya memfokuskan implementasi fungsi-fungsi dasar dari CA yang merupakan salah satu bagian pada arsitektur telepon aman.
Prototype sederhana sistem CA mencoba
untuk diimplementasikan menggunakan teknologi Java dan dikembangkan dengan menggunakan NetBeans 6.5 sebagai IDE.
Provider dari Bouncy Castle digunakan untuk
menambah kemampuan kriptografi standar yang disediakan oleh Java. Provider merupakan salah satu JCE (Java Cryptography Extension) yang termasuk dalam JCA (Java Cryptography
Architecture). Pada prototype sederhana
digunakan tiga file bertipe java, Formdaftar.java, Database.java dan Utils.java. Formdaftar.java merupakan file yang
menangani segala hal yang berhubungan dengan antarmuka dari prototype. File kedua, Database.java merupakan file yang menangani koneksi ke dalam basis data MySQL yang digunakan dalam prototype. File ketiga, Utils.java merupakan File penting yang berisi implementasi untuk fungsi-fungsi yang ada dalam prototype CA.
2. Implementasi proses pendaftaran pelanggan. Implementasi untuk proses pendaftaran menggunakan beberapa asumsi. Beberapa sumsi tersebut digunakan pada saat pembuatan sertifikat digital dari setiap entitas yang memiliki pasangan kunci publik/pribadi dan sertifikat yang bersesuaian dengan pasangan kunci tersebut. Berikut adalah beberapa asumsi yang digunakan dalam implementasi prototype CA:
a) Nomor seri untuk sertifikat menggunakan tipe variabel BigInteger dari waktu dibangkitkannya sertifikat kecuali untuk root sertifikat yang menggunakan nilai BigInteger dari 1. b) Field IssuerDN pada sertifikat
menggunakan “CN=Test CA Certificate” sebagai nilainya.
c) Field NotBefore menggunakan waktu pada saat sertifikat dibangkitkan sebagai nilainya.
d) Validity period atau masa aktif sertifikat adalah selama 7 hari setelah sertifikat dibangkitkan.
e) SubjectDN pada sertifikat adalah “CN=Test CA Certificate” untuk sertifikat root dan sertifikat intermediate, untuk sertifikat end nilai SubjectDN yang digunakan adalah nomor telepon untuk unit telepon yang diinputkan ke dalam sistem.
Tabel 1 hasil perancangan konseptual basis data CA
Nama Entitas Atribut Keterangan Sertifikat ID, Subject_name, path_toFile Informasi mengenai pemilik sertifikat, serta lokasi dimana sertifikat digital tersebut disimpan. CRL ID, no_seriCRL, path_toFileCR L, reason Informasi mengenai lokasi CRL dan alasan sertifikat di-revoke
Pendaftaran pelanggan dimulai dengan pembangkitan pasangan kunci publik/pribadi untuk CA. Pembuatan pasangan kunci untuk CA ditunjukkan oleh pemrograman berikut ini:
KeyPair
root=Utils.Utils.generaterootDSAKeyPair( );
Fungsi generaterootDSAKeyPair() berisi
baris-baris perintah berikut ini:
public static KeyPair generaterootDSAKeyPair()throws Exception { KeyPairGenerator kpGen=KeyPairGenerator.getInstance("DSA", "BC"); kpGen.initialize(512, Utils.createFixedRandom()); return kpGen.generateKeyPair(); }
Implementasi fungsi createFixedRandom() merupakan suatu fungsi yang memanggil konstruktor untuk membangkitkan suatu objek
SecureRandom. Pemanggilan seperti ini
dilakukan karena objek SecureRandom
dikonstruksi dari kelas yang bersifat private. Setelah pasangan kunci untuk root dibangkitkan, sertifikat untuk root dibuat.
Pembuatan sertifikat untuk root ini
menggunakan pemrograman yang dituliskan berikut ini:
X509Certificate
rootcert=Utils.Utils.generateRootCert(ro ot);
Fungsi generateRootCert(root)
menggunakan pasangan kunci untuk root yang dibangkitkan pada tahap sebelumnya sebagai parameter input. Implementasi fungsi
generateRootCert(root) dapat dilihat pada
pemrograman berikut ini:
public static X509Certificate generateRootCert(KeyPair pair) throws Exception { X509V1CertificateGenerator certGen=new X509V1CertificateGenerator(); certGen.setSerialNumber(BigIn teger.valueOf(1)); certGen.setIssuerDN(new X500Principal("CN=Test CA Certificate")); certGen.setNotBefore(new Date(System.currentTimeMillis())); certGen.setNotAfter(new Date(System.currentTimeMillis() +VALIDITY_PERIOD)); certGen.setSubjectDN(new X500Principal("CN=Test CA Certificate")); certGen.setPublicKey(pair.get Public()); certGen.setSignatureAlgorithm ("SHA1WithDSA"); return certGen.generateX509Certificate(pair.get Private(),"BC"); }
Setelah sertifikat untuk root dibangkitkan, maka langkah selanjutnya adalah membuat
private credential untuk root yang digunakan
untuk menyimpan digital sertifikat dan pasangan kunci untuk root. Private credential untuk root ini menggunakan “ROOT” sebagai pengenal dalam private credential-nya. Pembuatan private credential dapat dilihat pada pemrograman berikut ini:
X500PrivateCredential rootcredential=new
X500PrivateCredential(rootcert, root.getPrivate(), "ROOT");
Setelah root private credential dibangkitkan, dilakukan pembangkitan pasangan kunci untuk
intermediate. Berikut adalah pemrograman
untuk membangkitkan pasangan kunci
intermediate tersebut:
KeyPair
intermediate=Utils.Utils.generateDSAKeyP air();
Pembangkitan pasangan kunci untuk
intermediate sedikit berbeda dengan pembangkitan kunci untuk root. Pembangkitan kunci untuk intermediate menggunakan fungsi generateDSAKeyPair() yang menggunakan nilai SecureRandom yang selalu berubah-ubah sehingga pasangan kunci publik/pribadinya juga selalu berubah. Implementasi fungsi generateDSAKeyPair() dapat dilihat pada pemrograman di bawah ini:
public static KeyPair generateDSAKeyPair() throws Exception { KeyPairGenerator kpGen=KeyPairGenerator.getInstance("DSA", "BC"); kpGen.initialize(512, new SecureRandom()); return kpGen.generateKeyPair(); }
Langkah selanjutnya setelah pasangan kunci untuk intermediate dibangkitkan adalah pembangkitan sertifikat digital untuk pasangan
kunci tersebut. Berikut adalah pemrograman yang dilakukan untuk membangkitkan sertifikat digital untuk intermediate:
X509V3CertificateGenerator certGen0=new X509V3CertificateGenerator(); certGen0.setSerialNumber( BigInteger.valueOf(System.currentTimeMil lis())); certGen0.setIssuerDN(root cert.getSubjectX500Principal()); certGen0.setNotBefore(new Date(System.currentTimeMillis())); certGen0.setNotAfter(new Date(System.currentTimeMillis() +VALIDITY_PERIOD)); certGen0.setSubjectDN(new X500Principal("CN=TEST Intermediate Certificate")); certGen0.setPublicKey(int ermediate.getPublic()); certGen0.setSignatureAlgo rithm("SHA1WithDSA"); certGen0.addExtension(X50 9Extensions.AuthorityKeyIdentifier, false, new AuthorityKeyIdentifierStructure(rootcert )); certGen0.addExtension(X50 9Extensions.SubjectKeyIdentifier, false, new SubjectKeyIdentifierStructure(intermedia te.getPublic())); certGen0.addExtension(X50 9Extensions.BasicConstraints, true, new BasicConstraints(0));
certGen0.addExtension(X50 9Extensions.KeyUsage, true, new KeyUsage(KeyUsage.digitalSignature| KeyUsage.keyCertSign|KeyUsage.cRLSign));
X509Certificate intermediatecert=certGen0.generateX509Ce rtificate(root.getPrivate(), "BC");
Sedikit berbeda dengan sertifikat untuk root, sertifikat untuk intermediate memiliki beberapa
field extension tambahan. Tambahan yang
pertama adalah basic contraints extension yag menandakan bahwa sertifikat ini merupakan sertifikat CA dan sertifikat untuk end atau pelanggan disertifikasi oleh sertifikat ini. Ekstensi yang kedua adalah key usage yang menandakan bahwa sertifikat ini bisa digunakan untuk mensertifikasi sertifikat lain atau untuk mem-validasi CRL.
Langkah berikutnya yang dijalankan setelah sertifikat untuk intermediate dibangkitkan adalah pembuatan private credential untuk meyimpan sertifikat beserta pasangan kunci
intemediate dalam keystore. Berikut adalah
pemrograman yang dijalankan untuk membuat
private credential intermediate:
X500PrivateCredential intermediatecredential=new
X500PrivateCredential(intermediatecert, intermediate.getPrivate(),"INTERMEDIATE" );
Langkah selanjutnya dalam adalah proses pembuatan sertifikat untuk end atau pelanggan. Proses pembuatan sertifikat untuk pelanggan ini hampir sama dengan pembangkitan sertifikat untuk intermediate dan dimulai dengan pembangkitan pasangan kunci untuk pelanggan. Pembangkitan pasangan kunci untuk pelanggan dapat dilihat pada pemrograman berikut ini:
KeyPair
end=Utils.Utils.generateDSAKeyPair();
Setelah proses pembangkitan kunci selesai dilakukan, proses selanjutnya adalah pembangkitan sertifikat digital untuk pasangan kunci yang telah dibangkitkan tersebut. Proses pembangkitan sertifikat digital dapat dilihat pada pemrograman berikut ini:
X509V3CertificateGenerator certGen=new X509V3CertificateGenerator(); BigInteger serial=BigInteger.valueOf(System.currentT imeMillis()); certGen.setSerialNumber(s erial); certGen.setIssuerDN(new X500Principal("CN=Test Certificate")); certGen.setNotBefore(new Date(System.currentTimeMillis()50000)); certGen.setNotAfter(new Date(System.currentTimeMillis()+50000)); certGen.setSubjectDN(new X500Principal("CN="+data)); certGen.setPublicKey(end. getPublic()); certGen.setSignatureAlgor ithm("SHA1WithDSA"); certGen.addExtension(X509 Extensions.BasicConstraints, true, new BasicConstraints(false));
certGen.addExtension(X509 Extensions.KeyUsage, true, new KeyUsage(KeyUsage.digitalSignature |
KeyUsage.keyEncipherment));
certGen.addExtension(X509 Extensions.ExtendedKeyUsage, true, new ExtendedKeyUsage(KeyPurposeId.id_kp_serv erAuth));
certGen.addExtension(X509 Extensions.SubjectAlternativeName, false, new GeneralNames(new GeneralName(GeneralName.rfc822Name, "[email protected]")));
X509Certificate endcert=certGen.generateX509Certificate( intermediate.getPrivate(),"BC");
Sedikit perbedaan dengan pembangkitan sertifikat intermediate adalah pada input untuk
SubjectDN. SubjectDN pada sertifikat end
menggunakan nomor telepon yang diinputkan pada saat proses pendaftaran pelanggan dimulai.
Langkah selanjutnya yang dilakukan adalah pembangkitan private credential untuk pasangan kunci beserta sertifikat untuk end. Berikut adalah pemrograman untuk membangkitkan private credential untuk end:
X500PrivateCredential endcredential=new
X500PrivateCredential(endcert, end.getPrivate(),"END");
Setelah private credential untuk root,
intermediate dan end dibangkitkan, langkah
berikutnya adalah membuat keystore untuk menyimpan seluruh private credential tersebut. Proses tersebut dapat dilihat pada pemrograman berikut ini: Certificate[] chain=new Certificate[3]; chain[0]= rootcredential.getCertificate(); chain[1]= intermediatecredential.getCertificate(); chain[2]= endcredential.getCertificate(); store.setCertificateEntry (rootcredential.getAlias(), rootcredential.getCertificate()); store.setKeyEntry(endcred ential.getAlias(), endcredential.getPrivateKey(), keyPassword, chain); store.setKeyEntry(endcred ential.getAlias(), endcredential.getPrivateKey(), keyPassword, chain);
Variabel chain merupakan array yang menyimpan sementara sertifikat root,
intermediate dan end agar lebih mudah
digunakan.
Proses terakhir dari pendaftaran adalah proses penyimpanan sertifikat. Proses penyimpanan sertifikat ini dapat dilihat pada pemrograman berikut ini:
String path="./cert/"+data+".cert"; char[] password="storePassword".toCharArray(); FileOutputStream fOut=new FileOutputStream(path); ByteArrayOutputStream bOut=new ByteArrayOutputStream(); store.store(fOut, password); Connection dbcon=new Utils.Database().getConnection(); try { Statement stmt=dbcon.createStatement(); stmt.executeUpdate("i nsert into sertifikat(id, certificate, subject_name) values("+endcert.getSerialNumber() +",'"+path+"','"+endcert.getSubjectDN() +"')"); dbcon.close(); }
Proses penyimpanan ini akan menyimpan sertifikat ke dalam sebuah file dengan nama sama dengan nomor telepon yang diinputkan, dan sebuah baris di tabel sertifikat yang ada dalam basis data CA berupa path menuju file yang bersesuaian.
Implementasi seperti diatas memiliki kelemahan. Beberapa kelemahan yang paling dasar adalah sebagai berikut:
a) Penyimpanan kunci pribadi dalam
keystore.
Disimpannya kunci pribadi dalam keystore bersamaan dengan sertifikat dapat menghasilkan suatu kontradiksi. Di satu sisi, sertifikat merupakan hal yang bersifat publik sehingga semua orang boleh mengetahuinya, di pihak lain kunci pribadi merupakan kunci yang hanya boleh diketahui oleh pemilik sah pasangan kunci dan CA sebagai pihak yang membuat. Meskipun keystore sendiri memiliki suatu mekanisme untuk mengamankan kunci
yang disimpan didalamnya, pengamanan seperti ini dirasa kurang karena semakin majunya teknologi membuat kriptanalis mudah untuk membongkar suatu mekanisme pegamanan yang dimiliki oleh keystore. Pengamanan yang ditawarkan oleh keystore adalah berupa enkripsi kunci pribadi menggunakan algoritme tertentu. Sebagai contoh, keystore dengan tipe JCEKS adalah format keystore yang menggunakan algoritme Triple-DES untuk mengamankan kunci pribadi yang tersimpan didalamnya.
Alternatif yang dapat dilakukan untuk mengurangi resiko tersebut adalah dengan memisahkan antara keystore untuk sertifikat dengan keystore untuk pasangan kunci publik/pribadi. Pemisahan ini dilakukan agar kontradiksi yang terjadi antara sertifikat yang bersifat publik dengan kunci pribadi yang bersifat private tidak terjadi.
b) Penyimpanan rantai sertifikat dalam sebuah keystore.
Kelemahan lain yang dapat dilihat dari implementasi pembangkitan sertifikat seperti yang dijelaskan sebelumnya adalah pada penyimpanan semua pasangan kunci dan sertifikat dalam satu keystore untuk satu pelanggan. Hal ini dapat berakibat pada kunci pribadi yang dimiliki oleh root, meski telah diberikan keamanan tambahan berupa pengamanan kunci simetri lebih rentan terhadap serangan, karena kunci tersebut seolah-olah terbuka bagi siapa saja untuk di kriptanalisis.
Alternatif solusi untuk masalah ini adalah dengan alternatif pemecahan masalah nomor 1 sebelumnya ditambah dengan pemisahan antara masing-masing sertifikat. Jadi, untuk sebuah
file berisi sebuah keystore berisi tiga sertifikat,
setelah diaplikasikan alternatif pertama dan kedua akan menjadi tiga buah file keystore berisi masing-masing sebuah sertifikat, tiga buah file keystore berisi pasangan kunci publik/pribadi, dan sebuah record berisi rantai sertifikat untuk keperluan verifikasi oleh AC.
c) Penggunaan file sebagai tempat untuk penyimpan keystore.
Penggunaan file sebagai tempat penyimpanan keystore memiliki kelemahan. Sebuah file tentunya akan memiliki sebuah tempat untuk menyimpan selain di basis data yang telah ada. Sebaik-baiknya layanan keamanan yang ditawarkan untuk menyimpan sebuah file tidaklah sebaik layanan keamanan
data yang ditawarkan oleh sebuah database
management system (DBMS). Sebuah DBMS
memiliki kemampuan untuk membatasi siapa saja yang dapat mengakses data yang tersimpan didalamnya sehingga dirasakan lebih aman dibandingkan dengan penggunaan file. Selain itu, meski penyimpanan dalam bentuk file lebih mudah untuk didistribusikan, kemudahan distribusi ini kurang cocok untuk diterapkan dalam sistem PSTN. salah satu alasannya adalah karena dalam unit telepon kemungkinan besar tidak dirancang untuk menyimpan data dalam bentuk file.
Alternatif solusi untuk masalah ini adalah dengan menyimpan data seluruhnya di dalam DBMS.
3. Implementasi pembangkitan CRL.
CRL dibangkitkan dengan terlebih dahulu memilih sertifikat yang ingin di-revoke. Sertifikat yang akan di-revoke ini diambil nomor seri sertifikatnya dan digunakan sebagai masukkan untuk membangkitkan CRL. Selain nomor seri sertifikat, masukan lain yang diperlukan untuk pembangkitan CRL adalah alasan kenapa sertifikat tersebut di-revoke.
Langkah pertama yang dilakukan dalam pembangkitan CRL adalah pembangkitan pasangan kunci publik/pribadi untuk root. Pembangkitan pasangan kunci ini dapat dilihat apda pemrograman berikut ini:
KeyPair caPair=Utils.generaterootDSAKeyPair();
Langkah berikutnya adalah pembangkitan sertifikat root yang dapa dilihat pada pemrograman berikut ini:
X509Certificate
caCert=Utils.generateRootCert(caPair);
Setelah sertifikat untuk root dibangkitkan, berikutnya adalah menentukan nomor seri sertifikat yang akan dimasukkan dalam CRL, kemudian membangkitkan CRL-nya. Tahapan penentuan nomor seri sertifikat yang akan di-revoke dan pembangkitan CRL dapat dilihat dalam pemrograman berikut ini:
BigInteger revokedSerialNumber=BigInteger.valueOf(2 ); X509CRL crl=X509CRLExample.createCRL(caCert, caPair.getPrivate(), revokedSerialNumber);
disimpan dalam certstore. CollectionCertStoreParameters params=new CollectionCertStoreParameters(Collection s.singleton(crl)); CertStore store=CertStore.getInstance("Collection" , params,"BC"); X509CRLSelector selector=new X509CRLSelector(); selector.addIssuerName(caCert.get SubjectX500Principal().getEncoded()); Iterator it=store.getCRLs(selector).iterator(); Pengujian
Pengujian prototype dari CA dilakukan dengan metode blackbox testing. Pengujian dilakukan untuk melihat apakah sistem telah bekerja dengan benar sehingga kebenaran sistem dapat menjadi pertimbangan untuk implementasi pada penelitian selanjutnya. Pengujian yang dilakukan dapat dibagi menjadi 2 tahap, yaitu:
1. Tahap pengujian pembangkitan sertifikat digital.
Pada tahap ini dilakukan pengujian apakah output yang berupa sertifikat telah sesuai dengan input yang berupa data pelanggan. Hasil pengujian untuk proses pendaftaran dapat dilihat pada Lampiran 1.
2. Tahap pengujian pembangkitan CRL. Pada tahap ini dilakukan pengujian apakah hasil CRL yang dibangkitkan sesuai dengan parameter input yang dimasukkan. Hasil pengujian untuk CRL dapat dilihat pada Lampiran 1.
KESIMPULAN Kesimpulan
Arsitektur telepon aman yang diusulkan oleh Sharif dan Wijesekera dapat memberikan keamanan tambahan berupa voice privacy dan otentikasi dalam jaringan telepon yang telah ada sekarang. Arsitektur yang diusulkan tidak banyak mengubah arsitektur lama yang telah ada dan digunakan sekarang.
Salah satu pihak penting yang menjadi bagian dalam arsitektur telepon aman adalah
certificate authorities. Bagian ini bertanggung
jawab terhadap segala hal yang berkaitan dengan sertifikat untuk otentikasi.
Prototype CA dapat diimplementasikan
dengan bahasa pemrograman Java dengan bantuan provider dari Bouncy Castle. Pembangkitan sertifikat digital dapat menggunakan skema rantai sertifikat agar mendapatkan tambahan kemanan. Untuk penyimpanan sertifikat beserta pasangan kunci publik/pribadi secara sederhana dapat menggunakan fasilitas keystore.
Optimalisasi penggunaan keystore dapat dilakukan untuk menutupi kelemahan prototype yang dikembangkan pada penelitian ini.
CRL dibangkitkan untuk mengantisipasi adanya sertifikat yang diragukan keabsahannya. Saran
Implementasi yang dilakukan dalam penelitian ini masih memiliki banyak kekurangan. Rekomendasi yang dapat dilakukan untuk penelitian selanjutnya adalah dengan mencoba menerapkan beberapa alternatif implementasi lain yang lebih aman.
DAFTAR PUSTAKA
Ferguson, Niel & Bruce Schneier. 2003.
Practical Cryptography. Wiley Publishing.
Indianapolis.
Guritman, Sugi. 2003. Pengantar Kriptografi. Fakultas Matematika dan Ilmu Pengetahuan Alam, Institut Pertanian Bogor. Bogor Hook, David. 2005. Beginning Cryptography
with Java. Wrox Press.
Illuminet. 2000. Signaling System 7 (SS7). Illuminet.
Menezes A, Oorschot P, Vanstone S. 1996.
Handbook of Applied Cryptogaphy. CRC
Press.
Munir, Rinaldi. 2004. Digital Signature
Standard (DSS). Departemen Teknik
Informatika, Institut Teknologi Bandung. Bandung.
Sharif, Mohamed & Duminda Wijesekera. 2003. Providing Voice Privacy Over Public
Switched Telephone Network. Departemen
LAMPIRAN 1 Tabel Hasil pengujian
No Deskripsi Uji Kondisi Awal Skenario Uji Hasil yang
diharapkan Hasil Uji 1 Membangkitkan
pasangan kunci untuk
root
root tidak
memiliki pasangan kunci
running file
PrototypeCA.jar root memiliki pasangan kunci publik/pribadi
Berhasil
2 Membangkitkan self signed sertifikat untuk
root root memiliki pasangan kunci, tapi belum memiliki sertifikat untuk pasangan kunci tersebut running file PrototypeCA.jar root memiliki sertifikat yang ditandatangani oleh root sendiri
Berhasil
3 Membangkitkan private
credential untuk root
Pasangan kunci untuk root dan sertifikatnya masih terpisah, belum disimpan dalam satu tempat running file PrototypeCA.jar Pasangan kunci root dan sertifikatnya disimpan dalam satu private credential dengan alias root Berhasil 4 Membangkitkan pasangan kunci untuk
intermediate intermediate belum memiliki pasangan kunci publik/pribadi running file PrototypeCA.jar intermediate memiliki pasangan kunci Berhasil 5 Membangkitkan sertifikat digital untuk intermediate Pasangan kunci intermediate belum memiliki sertifikat digital running file
PrototypeCA.jar Pasangan kunci intermediate
disertifikasi oleh root Berhasil 6 Membangkitkan private credential untuk intermediate Pasangan kunci dan sertifikat untuk intermediate terpisah, belum disimpan dalam sebuah tempat running file PrototypeCA.jar Pasangan kunci dan sertifikat untuk intermediate disimpan dalam satu private credential dengan alias intermediate Berhasil 7 Membangkitkan pasangan kunci untuk
end/pelanggan
end belum
memiliki pasangan kunci
running
PrototypeCA.jar end memiliki pasangan kunci Berhasil
8 Membangkitkan sertifikat
untuk end/pelanggan Pasangan kunci untuk end belum
disertifikasi
running
PrototypeCA.jar Pasangan kunci untuk end disertifikasi dengan adanya
