ANALISIS DAN IMPLEMENTASI CERTIFICATE AUTHORITIES (CA) DALAM PUBLIC SWITCHED TELEPHONE NETWORK (PSTN) ABI SUPIYANDI

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 BOGOR 2010

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

Tanggal Lulus:

PRAKATA

Syukur Alhamdulillah penulis panjatkan kepada Allah SWT atas limpahan rahmat dan karuniaNya 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

Abi Supiyandi

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

iv

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 Implementasi Utils.java..........................................................................................................................23

v

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.

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

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.

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.

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 nonrepudiasi dan otentikasi sehingga kasus penipuan yang menggunakan sarana telepon dapat semakin diminimalisir.

Protokol

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

3. Suatu langkah tidak dapat dikerjakan bila langkah sebelumnya belum selesai.

TINJAUAN PUSTAKA

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.

4. Diperlukan dua pihak atau lebih untuk melaksanakan suatu protokol.

1

5. Protokol harus mencapai suatu hasil.

(Ferguson dan Schneier 2003).

6. Setiap pihak yang terlibat dalam protokol harus mengetahui terlebih dahulu mengenai protokol dan seluruh langkah yang akan dilaksanakan.

SHA-1

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:

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):

E K  M =C

1.

Memilih suatu prima q sehingga 2159 < q < 2160.

Proses untuk mendekripsi dengan kunci pribadi KP dapat dinotasikan sebagai berikut:

2.

Memilih t sehingga 0 ≤  t  ≤   8,   lalu  pemilihan   bilangan   prima  p  dengan  2511+64t < p < 2512+64t, dengan q membagi  (p­1).

3.

Memilih   suatu   generator  α dari suatu grup unik siklik dengan orde q dalam field p.

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

a)

Memilih suatu elemen g dalam field p dan menghitung α=g(p-1)/q mod p.

b) Jika

α=1, maka kembali ke 2

langkah a. 4.

Memilih suatu random integer dengan 1 < a < q-1.

a

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).

Gambar 1 Skema pembangkitan tanda tangan pada DSA (Hook 2005). 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
Gambar 2 Skema verifikasi tanda tangan digital (Hook 2005) 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, subjectpublic 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)

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.

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:

6.

Terima tanda tangan jika dan hanya jika v=r.

1. Membangkitkan pasangan kunci publik dan pribadi. 2. Membangkitkan

sertifikat

digital

untuk 3

setiap pasangan kunci yang dibangkitkan. 3. Menyimpan sertifikat digital dalam basis data CA dan tersedia untuk publik. 4. Berantarmuka dengan jaringan telepon publik.

CA

lain

P dan Q merupakan SCP, dan W, X, Y, dan Z merupakan pasangan STP.

dalam

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,

Gambar 3 Skema Jaringan SS7 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.

Gambar 4 Skema Arsitektur Telepon Aman 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. 4

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 S AC, 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#.

Gambar 5 Skema Otentikasi Sistem. Otentikasi kedua yang digunakan adalah otentikasi pelanggan. Gambar 6 menunjukkan skema untuk otentikasi pelanggan. Langkahlangkah untuk otentikasi pelanggan adalah

5

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.

2.

Ketika kunci simetrik terenkripsi diterima, unit telepon mendekripsinya menggunakan kunci private masingmasing unit telepon. Kunci simetrik ini kemudian digunakan untuk mengenkripsi dan mendekripsi sinyal 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.

Gambar 7 Skema keamanan suara pada arsitektur telepon aman METODE PENELITIAN

Gambar 6 Skema otentikasi pelanggan. 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.

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.

6

3. Disruption, gangguan atau pencegahan dari langkah operasi yang benar.

membuat sertifikat, dan bagaimana menyimpan dan merawat CRL.

4. Unsurpation, pengaturan beberapa bagian sistem oleh pihak yang tidak berwenang.

Implementasi

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.

CA

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.

Gambar 8 Metode Penelitian (Bishop 2003)

4. IDE NetBeans 6.5. 5. RDBMS Mysql 14.12 Distrib 5.0.75.

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,

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 7

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.

8

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 langkahlangkah yang dilakukan dalam proses pendaftaran:

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.

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:

Gambar 9 Skema proses pendaftaran pelanggan. Ilustrasi untuk proses revoke dapat dilihat pada Gambar 10.

1. Pelanggan meminta agar sertifikat digital dalam unit telepon aman miliknya di9

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. Gambar 10 langkah-langkah dalam pembangkitan CRL Bagian yang ditandai dengan garis putusputus 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.

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:

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.

a) Inisialisasi key generator untuk pasangan kunci DSA 512 bit milik CA.

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.

e) Pembangkitan sertifikat digital untuk pasangan kunci intermediate yang ditandatangani oleh sertifikat CA atau root certificate.

2. Perancangan proses pendaftaran. Proses pendaftaran pelanggan terdiri dari

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.

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 10

ditandatangi oleh sertifikat intermediate. i) Pembangkitan private credential untuk menyimpan pasangan kunci dan sertifikatnya di dalam keystore.

pembangkitan CRL. Flowchart pada Gambar 13 menggambarkan skema pada saat pembangkitan CRL.

j) Pembangkitan keystore berisi tiga buah private credential yang telah dibangkitkan pada langkah sebelumnya.

Gambar 11 Skema rantai sertifikat 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 direvoke. Permintaan revoke ini membutuhkan alasan resmi kenapa unit telepon atau nomor telepon tertentu harus di-revoke. Hasil perancangan pembangkitan dijelaskan sebagai berikut:

CRL

a) Inisialisasi key generator untuk membangkitkan pasangan kunci CA. b) Pembangkitan sertifikat digital untuk CA menggunakan fungsi untuk membangkitkan self signed certificate.

Gambar 12 Diagram alir pembangkitan sertifikat 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 direvoke. 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.

c) Pembangkitan CRL dengan menggunakan sertifikat digital CA yang telah dibangkitkan sebelumnya dan alasan kenapa unit telepon tersebut direvoke sebagai masukan fungsi 11

a) Nomor seri untuk sertifikat menggunakan tipe variabel BigInteger dari waktu dibangkitkannya sertifikat kecuali untuk root sertifikat yang menggunakan nilai BigInteger dari 1.

Gambar 13 Diagram alir pembangkitan CRL 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.

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

Keterangan

Sertifikat

ID, Informasi Subject_name, mengenai path_toFile pemilik sertifikat, serta lokasi dimana sertifikat digital tersebut disimpan.

CRL

ID, no_seriCRL, path_toFileCR L, reason

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:

Atribut

Informasi mengenai lokasi CRL dan alasan sertifikat direvoke

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 12

baris-baris perintah berikut ini: public   static   KeyPair  generaterootDSAKeyPair()throws Exception     {                 KeyPairGenerator  kpGen=KeyPairGenerator.getInstance("DSA", "BC");                 kpGen.initialize(512,  Utils.createFixedRandom());             kpGen.generateKeyPair();

 

  return 

    }

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());             kpGen.generateKeyPair();

 

  return 

    }

Langkah selanjutnya setelah pasangan kunci untuk intermediate dibangkitkan adalah pembangkitan sertifikat digital untuk pasangan 13

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());

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" );

            certGen0.setSubjectDN(new  X500Principal("CN=TEST   Intermediate  Certificate"));

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:

            certGen0.setPublicKey(int ermediate.getPublic());

KeyPair  end=Utils.Utils.generateDSAKeyPair();

            certGen0.setSignatureAlgo rithm("SHA1WithDSA");

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:

            certGen0.setNotBefore(new  Date(System.currentTimeMillis()));              certGen0.setNotAfter(new  Date(System.currentTimeMillis() +VALIDITY_PERIOD));

            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));

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));

                        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.

                       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   | 

14

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[] Certificate[3];

 

 

 

chain=new 

                        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 keystore.

kunci

pribadi

dalam

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 15

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 direvoke dan pembangkitan CRL dapat dilihat dalam pemrograman berikut ini: BigInteger  revokedSerialNumber=BigInteger.valueOf(2 ); X509CRL  crl=X509CRLExample.createCRL(caCert,  caPair.getPrivate(),  revokedSerialNumber);

CRL yang telah dibangkitkan kemudian 16

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 of Information and Software Engineering,

17

George Mason University.

18

LAMPIRAN

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 running file root memiliki memiliki PrototypeCA.jar pasangan kunci pasangan kunci publik/pribadi

2

Membangkitkan self signed sertifikat untuk root

root memiliki running file pasangan PrototypeCA.jar kunci, tapi belum memiliki sertifikat untuk pasangan kunci tersebut

root memiliki Berhasil sertifikat yang ditandatangani oleh root sendiri

3

Membangkitkan private credential untuk root

Pasangan kunci running file untuk root dan PrototypeCA.jar sertifikatnya masih terpisah, belum disimpan dalam satu tempat

Pasangan kunci Berhasil root dan sertifikatnya disimpan dalam satu private credential dengan alias root

4

Membangkitkan pasangan kunci untuk intermediate

intermediate running file intermediate belum PrototypeCA.jar memiliki memiliki pasangan kunci pasangan kunci publik/pribadi

5

Membangkitkan sertifikat Pasangan kunci running file digital untuk intermediate PrototypeCA.jar intermediate belum memiliki sertifikat digital

Pasangan kunci Berhasil intermediate disertifikasi oleh root

6

Membangkitkan private credential untuk intermediate

Pasangan kunci running file dan sertifikat PrototypeCA.jar untuk intermediate terpisah, belum disimpan dalam sebuah tempat

Pasangan kunci Berhasil dan sertifikat untuk intermediate disimpan dalam satu private credential dengan alias intermediate

7

Membangkitkan pasangan kunci untuk end/pelanggan

end belum running end memiliki memiliki PrototypeCA.jar pasangan kunci pasangan kunci

8

Membangkitkan sertifikat Pasangan kunci running untuk end/pelanggan untuk end PrototypeCA.jar belum disertifikasi

Pasangan kunci untuk end disertifikasi dengan adanya

Berhasil

Berhasil

Berhasil

Berhasil

20

No

Deskripsi Uji

Kondisi Awal

Skenario Uji

Hasil yang diharapkan

Hasil Uji

sertifikat 9

Membangkitkan private credential untuk end

Pasangan kunci running dan sertifikat PrototypeCA.jar untuk end masih disimpan terpisah

Pasangan kunci Berhasil dan sertifikatnya disimpan dalam private credential dengan alias end

10

Membangkitkan keystore untuk menyimpan private credential root, intermediate, dan end

keystore untuk running menyimpan PrototypeCA.jar private credential belum ada

private Berhasil credential root, intermediate, dan end disimpan dalam sebuah keystore

11

Menyimpan keystore dalam sebuah file dengan nama file <nomor_telepon>.cert

file keystore running file <nomor_telepo PrototypeCA.jar n>.cert tidak terdapat dalam root folder CA

Terdapat file Berhasil dengan nama <nomor_telepon >.cert dalam root folder CA

12

Menyimpan path menuju record dengan running file file keystore dalam tabel subject_name PrototypeCA.jar sertifikat <nomor_telepo n> dan ID <serial_number > tidak terdapat dalam tabel sertifikat

Terdapat record Berhasil dengan id <serial_number > dan subject_name <nomor_telepon > dalam tabel sertifikat

13

Membangkitkan pasangan kunci root

root tidak running file CA memiliki memiliki PrototypeCA.jar pasangan kunci pasangan kunci pribadi

Berhasil

14

Membangkitkan CRL untuk pasangan kunci yang akan di-revoke

CRL untuk running file Terdapat file pasangan kunci PrototypeCA.jar CRL dengan belum ada nama <serial_number >.crl dalam folder crl di root CA

Berhasil

15

Menyimpan path menuju record dengan Running file CRL dalam basis data serial PrototypeCA.jar <serial_number > sertifikat yang di-revoke tidak terdapat dalam tabel crl dalam basis data

Terdapat record Berhasil dengan serial <serial_number > sertifikat dalam tabel crl di basis data.

21

LAMPIRAN 2 Format X509 Certificate X509 Sertifikat v1 Certificate fields Version Serial Number Signature Algorithm Issuer Validity period Subject name Subject public-key information Issuer's signature X509 Sertifikat v2 Certificate fields v1=v2 (for seven fields ) Issuer unique identifier Subject unique identifier v1=v2 (for last field) X509 Sertifikat v3 Certificate fields v1=v2=v3 (for seven fields) v2=v3 (for two fields) Extension

v1=v2=v3 (for last fields)

Interpretation of contents Version of certificate format Certificate Serial Number Signature Algorithm identifier for certificate issuer's signature CA's X509 name Start and Expiry dates/times Subject X509 name Algorothm identifier and subject public-key value Certificate authoritys' digital signature

Interpretation of two more added fields Version, serial number, signature Algorithm, issuer, validity period, subject name, subject's public-key information To handle the possibility of reuse of issuer and/or subject names through time Issuer's signature

Interpretation of contents Version, serial number, signature Algorithm, issuer, validity period, subject name, subject's public-key information Issuer unique identifier, subject unique identifier Key and policy information, subject and issuerattributes, certificateion path constraints, extension related CRL's Issuer's signature

22

LAMPIRAN 3 Implementasi Utils.java /*   * To change this template, choose Tools | Templates   * and open the template in the editor.   */  package ui;  import java.security.NoSuchAlgorithmException;  import java.security.NoSuchProviderException;  import java.security.SecureRandom;  import java.security.MessageDigest;  import java.security.KeyPair;  import java.security.PublicKey;  import java.security.PrivateKey;  import java.security.KeyPairGenerator;  import java.math.BigInteger;  //import java.security.*;  import java.security.cert.X509Certificate;  import java.util.Date;  //import java.security.KeyPair;  //import java.security.PrivateKey;  //import java.security.cert.X509Certificate;  import javax.security.auth.x500.X500PrivateCredential;  import javax.security.auth.x500.X500Principal;  import javax.crypto.KeyGenerator;  import javax.crypto.SecretKey;  import javax.crypto.spec.IvParameterSpec;  import org.bouncycastle.asn1.x509.*;  import org.bouncycastle.x509.*;  import org.bouncycastle.x509.extension.*;  /**   *   * @author aboy   */  public class Utils {      //from chapter2 utils      private static String digits="0123456789abcdef";      public static String toHex(byte[] data, int length)      {          StringBuffer    buff=new StringBuffer();          for (int i=0;i!=length; i++)          {              int v=data[i] & 0xff;              buff.append(digits.charAt(v>>4));              buff.append(digits.charAt(v&0xf));          }          return buff.toString();      }      public static String toHex(byte[] data)      {          return toHex(data, data.length);      }      //chapter3 utils      public static SecretKey createKeyForAES(int bitLength, SecureRandom random)  throws NoSuchAlgorithmException, NoSuchProviderException      {          KeyGenerator generator=KeyGenerator.getInstance("AES","BC");          generator.init(256, random);          return generator.generateKey();      }      public static IvParameterSpec createCtrIvForAES(int messageNumber, SecureRandom  random)      {          byte[]  ivBytes=new byte[16];          random.nextBytes(ivBytes);          ivBytes[0]=(byte)(messageNumber >>24); 

23

        ivBytes[1]=(byte)(messageNumber >>16);          ivBytes[2]=(byte)(messageNumber >>8);          ivBytes[3]=(byte)(messageNumber >>0);          for (int i=0;i!=7;i++)          {              ivBytes[8+i]=0;          }          ivBytes[15]=1;          return new IvParameterSpec(ivBytes);      }      public static String toString(byte[] bytes, int Length)      {          char[]  chars=new char[Length];          for (int i=0;i!=chars.length;i++)          {              chars[i]=(char)(bytes[i] &0xff);          }          return new String(chars);      }      public static String toString(byte[] bytes)      {          return toString(bytes, bytes.length);      }      public static byte[] toByteArray(String string)      {          byte[] bytes=new byte[string.length()];          char[] chars=string.toCharArray();          for (int i=0;i!=chars.length;i++)          {              bytes[i]=(byte)chars[i];          }          return bytes;      }      //chapter 4      private static class FixedRand extends SecureRandom      {          MessageDigest   sha;          byte[]  state;          FixedRand()          {              try              {                  this.sha=MessageDigest.getInstance("SHA­1","BC");                  this.state=sha.digest();              }              catch(Exception e)              {                  throw new RuntimeException("Cant find SHA­1");              }          }          public void nextBytes(byte[] bytes)          {              int off=0;              sha.update(state);              while (off < bytes.length)              {                  state=sha.digest();                  if (bytes.length­off>state.length)                  {                      System.arraycopy(state, 0, bytes, off, state.length);                  }                  else                  {                      System.arraycopy(state, 0, bytes, off, bytes.length­off);                  }                  off+= state.length;                  sha.update(state);              }          } 

24

    }      public static SecureRandom createFixedRandom()      {          return new FixedRand();      }      //chapter5      public static KeyPair generateRSAKeyPair() throws Exception      {          KeyPairGenerator kpGen=KeyPairGenerator.getInstance("RSA","BC" );          kpGen.initialize(1024, new SecureRandom());          return kpGen.generateKeyPair();      }      public static KeyPair generateElGamalKeyPair() throws Exception      {          KeyPairGenerator kpGen=KeyPairGenerator.getInstance("ElGamal","BC");          kpGen.initialize(256,new SecureRandom());          return kpGen.generateKeyPair();      }      public static KeyPair generateDSAKeyPair() throws Exception      {          KeyPairGenerator kpGen=KeyPairGenerator.getInstance("DSA", "BC");          kpGen.initialize(512, new SecureRandom());          return kpGen.generateKeyPair();      }      public static KeyPair generaterootDSAKeyPair()throws Exception      {          KeyPairGenerator kpGen=KeyPairGenerator.getInstance("DSA","BC");          kpGen.initialize(512, Utils.createFixedRandom());          return kpGen.generateKeyPair();      }      //chapter7      private static final int VALIDITY_PERIOD=7*24*60*60*1000;      public static X509Certificate generateRootCert(KeyPair pair) throws Exception      {          X509V1CertificateGenerator certGen=new X509V1CertificateGenerator();          certGen.setSerialNumber(BigInteger.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.getPublic());          certGen.setSignatureAlgorithm("SHA1WithDSA");          return certGen.generateX509Certificate(pair.getPrivate(),"BC");      }      public static X509Certificate generateIntermediateCert(PublicKey intKey,  PrivateKey caKey, X509Certificate caCert ) throws Exception      {          X509V3CertificateGenerator certGen=new X509V3CertificateGenerator();          certGen.setSerialNumber(BigInteger.valueOf(1));          certGen.setIssuerDN(caCert.getSubjectX500Principal());          certGen.setNotBefore(new Date(System.currentTimeMillis()));          certGen.setNotAfter(new Date(System.currentTimeMillis()+VALIDITY_PERIOD));          certGen.setSubjectDN(new X500Principal("CN=TEST Intermediate Certificate"));          certGen.setPublicKey(intKey);          certGen.setSignatureAlgorithm("SHA1WithDSA");          certGen.addExtension(X509Extensions.AuthorityKeyIdentifier, false, new  AuthorityKeyIdentifierStructure(caCert));          certGen.addExtension(X509Extensions.SubjectKeyIdentifier, false, new  SubjectKeyIdentifierStructure(intKey));          certGen.addExtension(X509Extensions.BasicConstraints, true, new  BasicConstraints(0));          certGen.addExtension(X509Extensions.KeyUsage, true, new  KeyUsage(KeyUsage.digitalSignature|KeyUsage.keyCertSign|KeyUsage.cRLSign)); 

25

          return certGen.generateX509Certificate(caKey, "BC");      }      public static X509Certificate generateEndEntityCert(PublicKey entityKey,  PrivateKey caKey, X509Certificate caCert)throws Exception      {          X509V3CertificateGenerator certGen=new X509V3CertificateGenerator();          certGen.setSerialNumber(BigInteger.valueOf(1));          certGen.setIssuerDN(caCert.getSubjectX500Principal());          certGen.setNotBefore(new Date(System.currentTimeMillis()));          certGen.setNotAfter(new Date(System.currentTimeMillis()+VALIDITY_PERIOD));          certGen.setSubjectDN(new X500Principal("CN=test end Certificate"));          certGen.setPublicKey(entityKey);          certGen.setSignatureAlgorithm("SHA1WithDSA");          certGen.addExtension(X509Extensions.AuthorityKeyIdentifier, false, new  AuthorityKeyIdentifierStructure(caCert));          certGen.addExtension(X509Extensions.SubjectKeyIdentifier, false, new  SubjectKeyIdentifierStructure(entityKey));          certGen.addExtension(X509Extensions.BasicConstraints, true, new  BasicConstraints(false));          certGen.addExtension(X509Extensions.KeyUsage, true, new  KeyUsage(KeyUsage.digitalSignature|KeyUsage.keyEncipherment));          return certGen.generateX509Certificate(caKey,"BC");      }      //chapter 8      public static String ROOT_ALIAS="root";      public static String INTERMEDIATE_ALIAS="intermediate";      public static String END_ENTITY_ALIAS="end";      //generate a x500privatecredential for the root entity.      public static X500PrivateCredential createRootCredential()throws Exception      {          KeyPair rootPair=generateDSAKeyPair();          X509Certificate rootCert=generateRootCert(rootPair);          return new X500PrivateCredential(rootCert, rootPair.getPrivate(),  ROOT_ALIAS);      }      //generate a x500Privatecredential for the intermediate centity      public static X500PrivateCredential createIntermediateCredential(PrivateKey  caKey, X509Certificate caCert) throws Exception      {          KeyPair interPair=generateDSAKeyPair();          X509Certificate  interCert=generateIntermediateCert(interPair.getPublic(),  caKey, caCert);          return new X500PrivateCredential(interCert, interPair.getPrivate(),  INTERMEDIATE_ALIAS);      }      //generate a x500Privatecredential for the end entity      public static X500PrivateCredential createEndEntityCredential(PrivateKey  caKey,X509Certificate caCert) throws Exception      {          KeyPair endPair=generateDSAKeyPair();          X509Certificate endCert=generateEndEntityCert(endPair.getPublic(), caKey,  caCert);          return new X500PrivateCredential(endCert, endPair.getPrivate(),  END_ENTITY_ALIAS);      }  }

26