PENGAMANAN PAYLOAD VoIP BERBASIS ASTERISK DENGAN PROTOKOL SRTP MENGGUNAKAN TWINKLE
Oleh:
MUHARTANTO E 103091029610
PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAIS DAN TEKNOLOGI UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA 2010 M/1431 H
i PENGAMANAN PAYLOAD VoIP BERBASIS ASTERISK DENGAN PROTOKOL SRTP MENGGUNAKAN TWINKLE
Skripsi Diajukan untuk Memenuhi Persyaratan Memperoleh Gelar Sarjana Komputer Pada Fakultas Sains dan Teknologi Universitas Islam Negeri Syarif Hidayatullah Jakarta
Oleh:
MUHARTANTO E 103091029610
PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAIS DAN TEKNOLOGI UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA 2010 M/1431 H
ii PENGAMANAN PAYLOAD VoIP BERBASIS ASTERISK DENGAN PROTOKOL SRTP MENGGUNAKAN TWINKLE
Skripsi Sebagai salah satu syarat untuk memperoleh gelar Sarjana Komputer Fakultas Sains dan Teknologi Universitas Islam Negeri Syarif Hidayatullah Jakarta
Oleh:
MUHARTANTO E 103091029610
Menyetujui,
Pembimbing I, Pembimbing II,
Arini, MT Zulfiandri, MMSI NIP. 197601312009012001 NIP. 197001302005011003
Mengetahui, Ketua Program Studi Teknik Informatika
Yusuf Durrachman, MIT NIP. 197105222006041002
iii PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKONOLOGI UIN SYARIF HIDAYATULLAH JAKARTA
Dengan ini menyatakan bahwa skripsi yang ditulis oleh :
Nama : Muhartanto E NIM : 103091029610 Fakultas : Sains dan Teknologi Program Studi : Teknik Informatika Judul Skripsi : Pengamanan Payload VoIP Berbasis Asterisk Dengan Protokol SRTP Menggunakan Twinkle.
Dapat diterima sebagai syarat kelulusan untuk memperoleh gelar Sarjana Komputer pada Program Studi Teknik Informatika, Fakultas Sains dan Teknologi, Universitas Islam Negeri Syarif Hidayatullah Jakarta.
Jakarta, Agustus 2010
Menyetujui,
Dosen Pembimbing
Dosen Pembimbing I Dosen Pembimbing II
Arini, MT Zulfiandri, MMSI NIP. 19760131 200901 2 001 NIP. 19700130 200501 1 003
Mengetahui,
Dekan Fakultas Sains & Teknologi Ketua Prodi Teknik Informatika
DR. Syopiansyah Jaya Putra, M.Sis Yusuf Durrachman, MIT NIP. 19680117 200112 1 001 NIP. 19710522 200604 1 002
iv PENGESAHAN UJIAN
Skripsi berjudul “Pengamanan Payload VoIP Berbasis Asterisk Dengan Protokol SRTP Mengunakan Twinkle” yang ditulis oleh Muhartanto Esafullah, NIM 103091029610 telah diuji dan dinyatakan lulus dalam Sidang Munaqosyah Program Studi Teknik Informatika, Fakultas Sains dan Teknologi, Universitas Islam Negeri Syarif Hidayatullah Jakarta pada hari Senin, tanggal 6 September 2010. Skripsi ini telah diterima sebagai salah satu syarat untuk memperoleh gelar Sarjana Strata Satu (S1) Program Studi Teknik Informatika.
Jakarta, September 2010
Tim Penguji,
Penguji I, Penguji II,
Andrew Fiade, M.Kom Herlino Nanang, MT NIP. 19731209 2005011 1 002
Mengetahui,
Dekan Fakultas Sains dan Teknologi Ketua Prodi Teknik Informatika
DR. Syopiansyah Jaya Putra, MSis Yusuf Durrachman, MIT NIP. 19680117 200112 1 001 NIP. 19710522 200604 1 002
v PERNYATAAN
DENGAN INI SAYA MENYATAKAN BAHWA SKRIPSI INI BENAR-
BENAR HASIL KARYA SENDIRI YANG BELUM PERNAH DIAJUKAN
SEBAGAI SKRIPSI ATAU KARYA ILMIAH PADA PERGURUAN TINGGI
ATAUPUN LEMBAGA MANAPUN.
Jakarta, Agustus 2010
MUHARTANTO E 103091029610
vi ABSTRAK
Muhartanto E - 103091029610, Pengamanan Payload VoIP Berbasis Asterisk Dengan Protokol SRTP Menggunakan Twinkle. Dibawah bimbingan ARINI dan ZULFIANDRI.
Perkembangan teknologi komputer saat ini semakin pesat penggunaannya, antara lain penggunaan komunikasi lewat internet. Salah satunya adalah menggunakan jaringan Voice Over Internet Protocol (VoIP). Komunikasi VoIP menggunakan protokol Real Time Protocol (RTP) mengirimkan payload data melewati sebuah jaringan Internet Protocol (IP). Komunikasi tersebut keamanannya belum terjamin, sehingga informasi payload yang ditransmisikan dapat ditangkap dan dibaca. Karena itu diimplementasikan protokol SRTP yang dapat menenkripsi payload. Peneliti menggunakan metode Rapid Application Development (RAD) dalam pengembangan sistemnya, yang terdiri dari fase menentukan syarat-syarat dan tujuan informasi, fase perancangan, fase konstruksi, dan fase pelaksanaan. Hasil pengujian implementasi SRTP pada server Asterisk dan client Twinkle, payload yang ditransmisikan berhasil dienkripsi sehingga terjamin proses confidentiality dan integrity. Pengembangan aplikasi ini selanjutnya dapat ditambahkan pengamanan pada tingkat network seperti IPSec atau TLS (Transport Layer Security).
Kata Kunci : VoIP, SRTP, Payload, Asterisk, Twinkle, RAD.
vii KATA PENGANTAR
Puji serta syukur kami panjatkan ke Hadirat Allah SWT karena atas berkat dan rahmat-Nya, peneliti dapat menyusun dan menyelesaikan skripsi ini. Adapun judul dari skripsi ini adalah “Pengamanan Payload VoIP berbasis Asterisk
Dengan Protokol SRTP Menggunakan Twinkle ”.
Penyusunan skripsi ini tidak mungkin dapat peneliti laksanakan dengan baik tanpa bantuan dari berbagai pihak yang terkait. Untuk itu peneliti ingin mengucapkan banyak terima kasih secara khusus kepada beberapa pihak, yaitu:
1. DR. Syopiansyah Jaya Putra, M.Sis, selaku Dekan Fakultas Sains dan
Teknologi UIN Syarif Hidayatullah Jakarta.
2. Yusuf Durrachman, MIT, selaku Ketua Program Studi Teknik Informatika
dan Viva Arifin, MMSi, selaku Sekretaris Program Studi Teknik
Informatika.
3. Arini, MT dan Zulfiandri, MMSI selaku Dosen Pembimbing, yang telah
memberikan bimbingan, waktu dan perhatiannya dalam penyusunan
skripsi ini.
4. Seluruh Dosen Teknik Informatika yang tidak dapat peneliti sebutkan satu
persatu yang telah memberikan ilmu dan bimbingannya selama peneliti
menyelesaikan studi di Teknik Informatika.
5. Seluruh staff Jurusan TI/SI dan staff Akademik FST yang telah membantu
peneliti dalam masa perkuliahan.
viii Peneliti sadar masih banyak sekali kekurangan dari skripsi ini, dan peneliti terbuka terhadap segala saran dan kritik yang membangun.
Akhir kata peneliti mempersembahkan skripsi ini dengan segala kelebihan dan kekurangannya, semoga dapat bermanfaat bagi kita semua, amien.
Tangerang, Agustus 2010
Muhartanto E 103091029610
ix LEMBAR PERSEMBAHAN
Skripsi ini peneliti persembahkan kepada beberapa pihak yang telah memberi dukungan baik berupa dukungan moril maupun materil, yaitu:
1. Kedua orang tua, serta adik-adik yang tak henti-hentinya memberikan
dukungan baik moril maupun materiil bagi peneliti dalam menjalani hidup
ini.
2. Teman-teman dari Prodi Teknik Informatika angkatan 2003 khususnya
kelas D (Bahtiar, Ali, Rijal,.Syukur, Wildan, Ba’i, Rulan, Gun-gun, Erwin,
Harry, Aida, Diah, Prilia, Yuni, Desi, Ratih, Lela, Mimi, Ma’ul, Shidiq,
Syamsul, Hafizs, Adam, Putro, Fahmi, Teddy dan Giri) yang telah
melewatkan waktu bersama selama masa kuliah.
3. Teman-teman seperjuangan penyusunan skripsi TI 2003 kelas A, B & C.
4. Teman-teman dari masa SMU, Zaki, Toni, Aidil, Fany.
5. Teman-teman kosan, Pribadi Muslim, Eko “Petir”, Papa Zaki “Ridwan”,
Agus, Fahrudin.
Dan kepada Seluruh pihak dan teman-teman peneliti yang lain yang tidak bisa disebutkan namanya satu per satu yang telah memberi dukungan kepada peneliti sehingga skripsi ini dapat terselesaikan dengan baik.
Jakarta Agustus 2010
Muhartanto E 103091029610
x
xi DAFTAR ISI
Halaman Sampul ...... i
Halaman Judul...... ii
Lembar Pengesahan Pembimbing ...... iii
Surat Keterangan ...... iv
Lembar Pengesahan Ujian ...... v
Lembar Pernyataan ...... vi
Abstrak ...... vii
Kata Pengantar ...... viii
Lembar Persembahan ...... x
Daftar Isi ...... xii
Daftar Gambar ...... xvii
Daftar Tabel ...... xx
Daftar Lampiran ...... xxi
Daftar Istilah ...... xxii
BAB I PENDAHULUAN
1.1 Latar Belakang Masalah ...... 1
1.2 Rumusan Masalah ...... 2
1.3 Batasan Masalah ...... 2
1.4 Tujuan Penelitian ...... 3
1.5 Manfaat Penulisan ...... 3
xii 1.6 Metode Penelitian ...... 4
1.7 Sistematika Penulisan ...... 5
BAB II LANDASAN TEORI
2.1 Keamanan Paket Data ...... 7
2.1.1 Keamanan Komputer ...... 8
2.1.2 Paket Data ...... 10
2.1.3 Aspek-aspek Keamanan Komputer ...... 11
2.2 Kriptografi ...... 13
2.2.1 Komponen Kriptografi ...... 13
2.2.2 Macam-macam Kriptografi ...... 14
2.3 Protokol...... 17
2.3.1 Referensi Model OSI ...... 18
2.3.2 Protokol Model TCP/IP ...... 19
2.4 VoIP ...... 23
2.5 Keuntungan dan Kelemahan VoIP ...... 25
2.6 Quality of Service (QOS)...... 28
2.7 Codec ...... 29
2.8 H.323...... 30
2.8.1 Arsitektur H.323...... 31
2.8.2 Protokol-protokol H.323...... 34
2.9 Session Initiation Protocol ...... 40
2.10 SRTP (Secure Real-time Transport Protocol) ...... 44
xiii 2.10.1 Proses SRTP ...... 44
2.10.2 Kelebihan dan Kekurangan SRTP ...... 47
2.11 Asterisk ...... 48
2.11.1 Konfigurasi Minimal Asterisk ...... 49
2.9.1.1 sip.conf ...... 49
2.9.1.2 extensions.conf ...... 51
2.11.2 Modul Pendukung Asterisk ...... 52
2.9.2.1 Zaptel/DAHDI ...... 52
2.9.2.2 LibPRI ...... 52
2.9.2.3 Mpg123 ...... 52
2.9.2.4 Asterisk Add-ons...... 53
2.12 Twinkle ...... 53
2.13 Network Address Translation...... 54
2.14 Rapid Application Development ...... 55
2.11.1 Keunggulan RAD ...... 56
2.11.2 Kelemahan RAD ...... 57
BAB III METODE PENELITIAN
3.1 Metode Pengumpulan Data ...... 58
3.2 Metode Pengembangan Sistem...... 58
3.2.1 Fase Perencanaan Syarat-Syarat ...... 59
3.2.2 Fase Perancangan ...... 59
3.2.3 Fase Konstruksi ...... 59
3.2.4 Fase Pelaksanaan ...... 60
xiv
BAB IV PEMBAHASAN DAN IMPLEMENTASI
4.1 Fase Perencanaan Syarat-syarat ...... 61
4.1.1 Analisis Kebutuhan Masalah...... 61
4.1.2 Tujuan ...... 61
4.1.3 Syarat-syarat ...... 62
4.2 Fase Perancangan Proses ...... 64
4.2.1 Perancangan Proses VoIP ...... 64
4.2.2 Perancangan Proses SRTP ...... 65
4.3 Fase Konstruksi ...... 68
4.3.1 Instalasi DAHDI Linux...... 68
4.3.2 Instalasi LibPRI...... 69
4.3.3 Instalasi LibSRTP...... 69
4.3.4 Instalasi Asterisk...... 69
4.3.5 Instalasi Asterisk Add-ons ...... 70
4.3.6 Instalasi Twinkle...... 70
4.3.7 Instalasi Wireshark ...... 70
4.3.8 Konfigurasi Jaringan...... 71
4.4 Fase Pelaksanaan...... 73
4.4.1 Implementasi SRTP pada Asterisk...... 73
4.4.2 Keadaan Sebelum Implementasi SRTP ...... 74
4.4.3 Keadaan Sesudah Implementasi SRTP...... 78
xv
BAB V PENUTUP
5.1 Kesimpulan...... 84
5.2 Saran ...... 85
DAFTAR PUSTAKA ...... 86
xvi DAFTAR GAMBAR
Gambar 2.1 Security Cost Function ...... 9
Gambar 2.2 Paket Data IP ...... 11
Gambar 2.3 Lapisan-lapisan OSI ...... 20
Gambar 2.4 TCP/IP Protocol Suite ...... 21
Gambar 2.5 Jaringan VoIP ...... 24
Gambar 2.6 Arsitektur H.323 ...... 32
Gambar 2.7 Protokol-protokol H.323...... 36
Gambar 2.8 RTP Header ...... 37
Gambar 2.9 Contoh Paket SIP ...... 41
Gambar 2.10 Arsitektur SIP ...... 42
Gambar 2.11 Proses Pembuatan Paket SRTP ...... 45
Gambar 2.12 Aplikasi Twinkle ...... 54
Gambar 2.13 Skema Pengembangan Sistem RAD ...... 56
Gambar 3.1 Ilustrasi Metodologi Pengembangan VoIP ...... 61
Gambar 4.1 VoIP Call Flow ...... 64
Gambar 4.2 Desain Jaringan VoIP Penelitian ...... 65
Gambar 4.3 Konfigurasi sip.conf ...... 72
Gambar 4.4 Konfigurasi extension.conf ...... 73
Gambar 4.5 Tampilan Awal Asterisk ...... 74
Gambar 4.6 Transmisi dari client-server ...... 75
Gambar 4.7 Transmisi dari client-client ...... 76
xvii Gambar 4.8 Paket SIP sebelum keadaan implementasi...... 77
Gambar 4.9 Pilihan Keamanan pada aplikasi Twinkle...... 78
Gambar 4.10 Protokol SRTP/ZRTP pada client-server...... 79
Gambar 4.11 Protokol SRTP/ZRTP pada user 1...... 80
Gambar 4.12 Protokol SRTP/ZRTP pada user 2...... 80
Gambar 4.13 Paket SIP setelah keadaan implementasi ...... 81
Gambar 4.14 Capture suara sebelum implementasi ...... 82
Gambar 4.15 Protokol ZRTP/SRTP pada user 1 ...... 83
xviii DAFTAR TABEL
Tabel 2.1 Hubungan OSI Model, protokol dan fungsi VoIP ...... 25
Tabel 2.2 Manajemen Kunci SRTP ...... 46
Tabel 4.1 Menu SIP Proxy pada Twinkle ...... 72
xix DAFTAR LAMPIRAN
Lampiran A RFC 3550 RTP ...... A
Lampiran B RFC 3711 SRTP ...... B
Lampiran C Asterisk Command ...... C
xx DAFTAR ISTILAH
Istilah Arti Komputer yang memanfaatkan sumber daya dalam jaringan yang disediakan oleh komputer lainnya, yang disebut dengan server. Juga merupakan sebuah aplikasi atau proses yang meminta pelayanan dari komponen atau proses lainnya. Adanya client ini, Client memudahkan koneksi ke komputer server, dan mengatur serta menjaga hubungan dari sumber daya lainnya. Dalam lingkungan Client/Server, workstation biasanya adalah merupakan komputer client.
Perangkat. Perangkat nyata yang dikendalikan oleh chip controller di board sistem atau card. Perangkat ini terdiri dari perangkat masukan atau keluaran, yang terdiri dari dua bagian: Komponen mekanis, perangkat itu sendiri. Komponen elektronis, pengendali perangkat berupa chip controller. Controller dihubungkan dengan pemroses dan komponen-komponen lain lewat bus. Controller bisa Device berbeda-beda, namun mempunyai register-register untuk mengendalikannya. Status register berisi statis yang mendeskripsikan kode kesalahan. Control register untuk maksud kendali. Tiap controller dibuat agar dapat dialamati secara individu oleh pemroses, sehingga perangkat lunak device driver dapat menulis ke register-registernya dan dengan demikian mengendalikannya. Beberapa karakter yang terletak pada permulaan suatu file yang tersimpan di dalam disk. File header File Header ini memiliki hubungan dengan nama dan sifat file tersebut. Perangkat keras (hardware) mengacu kepada obyek memungkinkan untuk disentuh, seperti disket, disk Hardware drive, layar monitor, keybord, printer, scanner, dan chip. Jaringan dari sistem komunikasi data yang melibatkan sebuah atau lebih sistem komputer yang Network dihubungkan dengan jalur transmisi alat komunikasi membentuk satu sistem.
xxi Komputer yang bertugas sebagai pelayan jaringan. Server mengatur lalu lintas data dalam sebuah jaringan dan menyediakan resource yang dapat dipakai oleh komputer lain yang terhubung dalam jaringannya. Server merupakan piranti khusus dalam jaringan komputer yang menjadi tempat bagi semua nodes di dalam jaringan untuk bisa melakukan resource sharing. Server melayani semua nodes, jika Server nodes membutuhkan. Server ada beberapa macam, yaitu: printer server, file server, disk server, dan database server. Server bisa bersifat dedicated, artinya server tidak bisa dipergunakan sebagai nodes untuk komunikasi, ada juga yang bersifat non- dedicated, yaitu selain berfungsi sebagai server juga dapat dipergunakan sebagai titik masuk untuk berkomunikasi di dalam jaringan. Cara seperti ini populer dengan istilah client-server. Perangkat Lunak (software) adalah perintah-perintah atau data komputer. Semua yang dapat disimpan secara elektronik adalah software. Software sering dibagi menjadi dua kaktegori: - Software sistem (system software): yang meliputi sistem operasi dan Software semua utilitas yang menjalankan komputer - Software aplikasi (application software): yang meliputi program yang digunakan oleh pengguna untuk melakukan pekerjaan tertentu, seperti pengolah kata (word processors), sehingga mudah untuk membuah dan menguji program-program sederhana. Pengguna. Biasanya ditujukan kepada pengguna User suatu sistem yang umumnya adalah manusia. Misalnya pengguna komputer. Sebuah device dari jaringan komputer personal dengan daya yang lebih besar jika dibandingkan dengan standar PC IBM atau Macintosh. Secara tipikal, sebuah workstation memiliki sistem operasi Workstation seperti UNIX yang bisa menjalankan beberapa task pada saat yang bersamaan. Workstation umumnya memiliki sejumlah memori megabyte dan display dengan resolusi tinggi. Contoh workstation adalah DEC VAXstation dan IBM RT-PC.
xxii BAB I
PENDAHULUAN
1.1 Latar Belakang
Voice Over Internet Prorokol (VoIP) adalah teknologi yang memungkinkan percakapan suara jarak jauh melalui media internet. Data suara diubah menjadi kode digital dan dialirkan melalui jaringan internet yang mengirimkan paket-paket data (payload).
Real-time Transport Protocol (RTP) adalah protokol yang digunakan untuk mengirim data real-time dalam suatu jaringan. Protokol tersebut mengatur transmisi multimedia melewati sebuah jaringan IP, seperti komunikasi audio atau video conference oleh protokol Session Initiation Protokol (SIP).
Dalam implementasinya, paket data dalam transmisi tersebut dapat ter- capture pihak luar dengan cara sniffing sehingga pembicaraan antar klien VoIP dapat disadap/direkam. Informasi-informasi tersebut dapat dimanfaatkan untuk menerobos jaringan oleh hacker. Selain itu paket tersebut dapat direplay secara berulang-ulang dalam jaringan sehingga dapat menimbulkan Denial of Service
(DOS).
Secure Real-Time Transport Protocol (SRTP),sesuai dengan RFC 3711, menggambarkan bagaimana memproteksi media IP telephony untuk enkripsi paket-paket RTP,untuk autentikasi keseluruhan paket RTP.
Diharapkan dengan penggunaan protokol SRTP, paket-paket data RTP terenkripsi dan terlindungi sehingga komunikasi antar klien VoIP terjamin prinsip confidentiality dan integrity. Oleh karena itu penulis akan mengimplementasikan
1 protokol SRTP pada VoIP dengan menggunakan VoIP server Asterisk dan VoIP client Twinkle.
1.2 Rumusan Masalah
Berdasarkan latar belakang tersebut dapat dirumuskan bahwa permasalahan yang ada adalah :
1. Bagaimana membuat suatu komunikasi VoIP melewati jaringan yang
terdiri dari satu server VoIP dan dua VoIP client.
2. Bagaimana menerapkan protokol SRTP pada aplikasi VoIP berbasis server
Asterisk dan di bagian client dengan menggunakan Twinkle.
3. Bagaimana pengujian terhadap hasil sebelum dan sesudah penerapan
SRTP pada skema VoIP.
1.3 Batasan Masalah
Pembahasan keamanan VoIP relatif luas dan rumit, maka penulis menyadari perlu adanya pembatasan masalah dalam melakukan penelitian ini agar ruang lingkup penelitian tidak terlalu luas. Adapun batasan masalah tersebut adalah sebagai berikut:
1. Pada penelitian ini hanya membahas pengamanan paket pada tingkat data
dan tidak pada jaringan .
2. Komunikasi client-server VoIP menggunakan Asterisk sebagai VoIP
server dan aplikasi client.
3. Pengujian keamanan paket data dengan menggunakan aplikasi Wireshark.
2 4. Implementasi SRTP di VoIP client menggunakan Twinkle.
1.4. Tujuan Penelitian
Tujuan dan penulisan skripsi ini adalah untuk membangun komunikasi
VoIP dengan satu server VoIP (Asterisk) dan dua client VoIP client (Twinkle), menerapkan protokol SRTP pada server dan client. Kemudian menguji keadaan sebelum dan sesudah implementasi SRTP pada komunikasi VoIP.
1.5 Manfaat Penelitian
Sesuai dengan permasalahan dan tujuan penelitian yang telah disebutkan di atas, maka manfaat penelitian dapat dirumuskan sebagai berikut :
1) Bagi Penulis :
a. Menerapkan ilmu-ilmu yang diperoleh selama kuliah.
b. Memahami kondisi real gangguan dalam jaringan VoIP
c. Untuk memenuhi salah satu syarat kelulusan strata satu (S1) Program
Studi Teknik Informatika Fakultas Sains dan Teknologi UIN SYARIF
HIDAYATULLAH JAKARTA
2) Bagi Universitas
a. Mengetahui kemampuan mahasiswa dalam menguasai materi baik
teori maupun praktek yang telah diperoleh selama kuliah.
b. Mengetahui kemampuan mahasiswa dalam menerapkan ilmunya dan
sebagai bahan evaluasi.
3 c. Memberikan gambaran tentang kesiapan mahasiswa dalam
menghadapi dunia kerja yang sebenarnya.
3) Bagi Masyarakat
a. Membantu pengamanan jaringan VoIP yang dianggap penting atau
vital.
b. Sebagai referensi bagi semua pihak yang mempunyai minat dalam
mengembangkan keamanan VoIP.
1.6 Metode Penelitian
Adapun metode penelitian untuk mengumpulkan data-data yang
diperlukan adalah sebagai berikut :
1. Metode Pengumpulan Data
Metode yang penulis lakukan untuk mendapatkan data dan
informasi adalah metode studi pustaka, yaitu pengumpulan data dan
informasi dengan cara membaca buku-buku referensi, e-book dan
jurnal-jurnal dari internet, artikel, website, dan lain-lain.
2. Metode Pengembangan Sistem
Pengembangan sistem yang digunakan dalam penelitian ini
adalah metode pengembangan model RAD (Rapid Application
Development). Tahap - tahap siklus pengembangan model RAD
(Rapid Application Development), yaitu:
4 a) Fase Perencanaan Syarat-syarat
Yaitu menentukan tujuan dan syarat-syarat informasi
dengan menetapkan analisis kebutuhan, tujuan dan syarat-
syarat.
b) Fase Perancangan
Yaitu perancangan proses-proses yang akan terjadi dalam
sistem dan perancangan antarmuka.
c) Fase Konstruksi
Pada tahapan ini dilakukan tahap pengkodean dan
pembuatan script atau penginstallan dan konfigurasi
terhadap rancangan-rancangan yang telah didefinisikan.
d) Fase Pelaksanaan
Pada tahap ini dilakukan konfigurasi dari aplikasi sistem
VoIP (VoIP server , dan VoIP client), pengujian sistem,
dan perbandingan keadaan sebelum dan sesudah penerapan
keamanan SRTP .
1.7 Sistematika Penulisan
Dalam penyusunan skripsi ini, pembahasan yang penulis sajikan
terbagi dalam lima bab, yang secara singkat akan diuraikan sebagai
berikut :
5 BAB I PENDAHULUAN
Pada bab ini akan dijelaskan tentang latar belakang masalah,
tujuan penulisan, manfaat penulisan, batasan masalah, metode
penelitian, kerangka pemikiran dan sistematika penulisan.
BAB II LANDASAN TEORI
Bab ini akan menjelaskan secara singkat teori yang diperlukan
dalam penulisan.
BAB III METODOLOGI PENELITIAN
Metode yang dilakukan dalam mengumpulkan data pada bab ini
berisi uraian lebih rinci tentang metode perancangan sistem yang
digunakan dalam membuat rancangan aplikasi ini.
BAB IV HASIL DAN PEMBAHASAN
Bab ini akan menjelaskan perancangan program dan
implementasinya yang menggunakan beberapa tahap
pengembangan sistem yang meliputi fase menentukan tujuan dan
syarat-syarat informasi, fase perancangan, fase konstruksi, dan
fase pelaksanaan.
BAB V KESIMPULAN DAN SARAN
Dalam bab ini berisi uraian tentang kesimpulan-kesimpulan yang
didapat serta mengemukakan saran yang dianggap perlu.
DAFTAR PUSTAKA
LAMPIRAN
6 BAB II
LANDASAN TEORI
2.1 Keamanan Paket Data
Istilah keamanan (security) berkaitan erat dengan dengan faktor keamanan informasi dengan menggunakan teknologi. Hal tersebut disebabkan karena adanya kelemahan di dalam: kebijaksanaan suatu perusahaan (Policy
Vulnerabilities), konfigurasi suatu sistem (Configuration Vulnerabilities), dan teknologi yang digunakan (Technology Vulnerabilities) (Sitepu, 2001: 15).
Kelemahan-kelemahan itu dapat dimanfaatkan untuk menyusup ke dalam suatu jaringan komputer tanpa diketahui pengelolanya. Beberapa masalah dapat timbul seperti :
1. Packet Sniffing: penangkapan isi data yang melalui jaringan.
2. Identity Spoofing: menggunakan identitas resmi secara ilegal.
3. Data Theft: menyalin dan mengirim data yang bersifat rahasia tanpa
diketahui pemiliknya.
4. Data Alteration: memodifikasi suatu data tanpa sepengetahuan
pemilik yang bersangkutan.
Karena itu diperlukan tindakan dalam mengamankan data-data, terlebih yang sifatnya rahasia, seperti hanya bisa dibaca dan tidak bisa dihapus (read-
7 only). Tindakan lainnya adalah memberikan kode kunci (password) dan kriptografi sehingga data tersebut hanya bisa dibuka oleh yang berhak.
2.1.1 Keamanan Komputer
Menurut John D. Howard, istilah keamanan komputer adalah
suatu usaha pencegahan dan pendeteksian penggunaan komputer secara
tidak sah atau tidak diizinkan (Wahono, 2008: 3). Selain itu keamanan
komputer juga meliputi usaha melindungi aset dan menjaga privacy dari
pelaku serangan (hacker / cracker).
Sistem komputer yang aman adalah suatu tarik ulur perimbangan
antara keamanan dan biaya (cost). Menurut Thomas Olovsson dengan
teori Security Cost Function yang ditulisnya, semakin aman sebuah
sistem, maka semakin tinggi biaya yang diperlukan untuk
memenuhinya. Karena itu dalam kenyataan, tingkat sistem yang aman
adalah tingkat optimal dimana ada perimbangan antara biaya yang
dikeluarkan dengan tingkat keamanan yang dibutuhkan.
8
Gambar 2.1 Security Cost Function
(Sumber: Wahono, 2008: 3)
Jenis pendekatan yang biasa digunakan untuk meningkatkan keamanan komputer mencakup :
1. Secara fisik membatasi akses ke komputer hanya kepada
mereka yang tidak mengkompromikan tingkat keamanan.
2. Secara mekanisme hardware, yang menekankan aturan pada
program komputer yang dipakai, untuk menghindari
ketergantungan terhadap program komputer untuk computer
security.
3. Secara mekanisme sistem operasi, yang menekankan aturan
kepada sistem operasi untuk menghindari kepercayaan
(trust) terhadap program-program komputer.
9 4. Secara strategi programming agar program komputer dapat
dipercaya dan menolak adanya subversion (pengubahan).
2.1.2 Paket Data
Data merupakan sinyal-sinyal elektromagnetik yang dibangkitkan oleh sumber data yang dapat ditangkap dan dikirimkan kepada terminal-terminal penerima (Wahono, 2008: 6). Sedangkan yang dimaksud dengan terminal, menurut Intenational
Telecommunications Union-Telephony adalah data terminal equipment atau peralatan untuk terminal suatu data seperti printer, disk drive, monitor, papan ketik, plotter, scanner dan lain sebagainya.
Sebuah paket merupakan satuan format data dalam komunikasi jaringan digital. Sebuah paket terdiri dari dua jenis data: kontrol informasi (control information) dan user data/payload. Kontrol informasi memberikan kebutuhan informasi jaringan dimana user data dikirim seperti : alamat sumber dan tujuan, kode deteksi kesalahan seperti checksum, informasi urutan. Kontrol informasi terletak di packet header (kepala) dan trailer (ujung) dengan user data di bagian tengah.
Paket data juga dikenal sebagai datagram, segmen, blok, cell artau frame, tergantung protokol yang digunakan. Dalam protokol TCP
10 istilah yang digunakan adalah paket sedangkan dalam protokol UDP disebut sebagai datagram.
Gambar 2.1 Paket Data IP
(Sumber: http://articles.techrepublic.com)
2.1.3 Aspek-aspek Keamanan Komputer
Menurut Ariyus (2006: 9), terdapat beberapa aspek yang meliputi keamanan komputer, yaitu :
1. Authentication: agar penerima informasi dapat memastikan
keaslian pesan, bahwa pesan itu datang dari orang yang
dimintai informasi . Dengan kata lain, informasi itu benar-
benar datang dari orang yang dikehendaki.
11 2. Integrity: keaslian pesan yang dikirim melalui jaringan dan
dapat dipastikan bahwa informasi yang dikirim tidak
dimodifikasi oleh orang yang tidak berhak.
3. Non-repudiation: merupakan hal yang berhubungan dengan
si pengirim. Pengirim tidak dapat mengelak bahwa dialah
yang mengirim informasi tersebut.
4. Authority: Informasi yang berada pada sistem jaringan tidak
dapat dimodifikasi oleh pihak yang tidak berhak untuk
mengaksesnya.
5. Confidentialty: merupakan usaha untuk menjaga informasi
dari orang yang tidak berhak mengakses. Kerahasiaan ini
biasanya berhubungan dengan informasi yang diberikan ke
pihak lain.
6. Privacy: lebih kearah data-data yang bersifat pribadi.
7. Availability: aspek availabilitas berhubungan dengan
ketersediaan informasi ketika dibutuhkan. Sistem informasi
yang diserang atau dijebol dapat menghambat atau
meniadakan akses ke informasi.
8. Access Control: Aspek ini berhubungan dengan cara
pengaturan akses ke informasi. Hal ini biasanya
12 berhubungan dengan masalah otentikasi dan privasi. Kontrol
akses seringkali dilakukan dengan menggunakan kombinasi
user id dan password.
2.2 Kriptografi
Menurut terminologinya, kriptografi adalah ilmu dan seni untuk
menjaga keamanan pesan dikirim dari suatu tempat ke tempat yang lain
(Ariyus, 2006: 9). Sedangkan menurut Bruce Schneider dalam Applied
Cryptography, kriptografi adalah seni dan ilmu untuk menjaga agar
pesan rahasia tetap aman dan merupakan salah satu cabang ilmu
algoritma matematika (Munir, 2006: 7).
2.2.1 Komponen Kriptografi
Kriptografi terdiri dari beberapa komponen yaitu (Ariyus:2006,
10):
1. Enkripsi: mengubah pesan yang dimengerti menjadi bentuk yang
tidak dapat dibaca (cyphertext).
2. Deskripsi: mengubah pesan yang telah dienkripsi menjadi ke
bentuk asalnya.
13 3. Kunci: kunci yang dipakai untuk melakukan enkripsi dan
deskripsi. Kunci terbagi menjadi dua bagian, yaitu kunci rahasia
(private key) dan kunci umum (public key).
4. Ciphertext: pesan yang melalui proses enkripsi. Pesan ini tidak
bisa dibaca karena berupa karakter-karakter yang tidak
mempunyai arti
5. Plaintext: pesan asli yang akan diubah dengan kriptografi untuk
menjadi ciphertext.
6. Pesan: data atau informasi yang dikirim atau yang disimpan
dalam media perekaman.
7. Cryptanalysis: analisa kode untuk mendapatkan pesan asli tanpa
harus mengetahui kunci yang sah secara wajar.
2.2.2 Macam-macam Kriptografi
Kriptografi modern merupakan suatu algoritma yang digunakan pada saat sekarang ini, yang mana kriptografi modern mempunyai kerumitan yang sangat kompleks, karena dalam pengoperasiannya menggunakan komputer. Macam-macam algoritma menurut kunci dan hash adalah (Ariyus, 2006: 16) :
14 1. Algoritma Simetris
Algoritma simetris disebut juga sebagai algoritma
konvensional, yaitu algoritma yang menggunakan kunci yang
sama untuk proses enkripsi dan dekripsinya. Keamanan
algoritma simetris tergantung pada kuncinya. Algoritma
simetris sering juga disebut algoritma kunci rahasia, algoritma
kunci tunggal atau algoritma satu kunci. Contoh algoritma
yang termasuk dalam kategori algoritma simetris diantaranya
adalah:
a. Block cipher (Kurniawan, 2004: 50), adalah algoritma
yang masukan dan keluarannya berupa satu block, dan
setiap blocknya terdiri dari banyak bit. Beberapa model
algoritma block cipher antara lain : DES (Data Encryption
Standard), AES (Advanced Encryption Standard),
Blowfish.
b. Stream cipher (Kurniawan, 2004: 80), adalah cipher
yang berasal dari hasil XOR antara bit plaintext dengan
setiap bit kuncinya. Beberapa model algoritma stream
cipher antara lain: OTP (One Time Pad), RC4 (Rivest
Code 4).
15
2. Algoritma Asimetris
Algoritma asimetris atau biasa disebut algoritma kunci
publik dirancang sedemikian mungkin sehingga kunci yang
digunakan untuk mengenkripsi dan mendekripsi yang
berbeda. Selanjutnya kunci dekripsi tidak dapat dihitung
dengan dari kunci enkripsi. Algoritma tersebut disebut public
key karena kunci enkripsi dapat dibuat secara publik. Orang
asing dapat menggunakan kunci enkripsi tersebut untuk
mengenkripsi sebuah pesan, tetapi hanya orang tertentu
dengan kunci dekripsi sepadan dapat mendekripsi pesan
tersebut, dalam sistem ini kunci enkripsi sering disebut
public key sedangkan kunci dekripsi sering disebut private
key. Beberapa algoritma asimetris antara lain: RSA (Rivest
Shamir Adleman) dan Diffie Hellman.
3. Hash Function
Fungsi hash mengurangi data dari ukuran yang berubah-
ubah menjadi ukuran yang khusus. Fungsi hash dibutuhkan
dalam bagian konfigurasi sistem untuk memudahkan
pengecekan terhadap kelebihan data. Seluruh data dapat
16 diperiksa untuk melihat apakah data yang berkapasitas besar
dapat diulang, sebab hal ini akan mendatangkan kerugian
besar dalam kecepatan dan waktu. Fungsi hash digunakan
dalam kriptografi, yaitu dalam hal membagi atribut yang
mirip, terutama dalam hal tanda tangan digital. Biasanya
sering dikombinasikan dengan fungsi kriptografi yang punya
integritas, seperti dalam hal kombinasi antara algoritma
tanda tangan digital dan fungsi hash atau fungsi hash
dengan algoritma kriptografi kunci rahasia (Wahana
Komputer, 2003: 107). Contoh algoritma fungsi hash satu
arah adalah MD-5 (Message Digest 5) dan SHA (Secure
Hash Algorithm).
2.3 Protokol
Dalam jaringan komputer, proses komunikasi terjadi antara suatu
entiti pada sistem yang berbeda-beda (Stallings, 2001: 13). Contoh
entiti disini adalah program-program aplikasi user (user applications
programs), program transfer file (file transfer package), sistem
manajemen database (database management system), fasilitas electronic
mail, dan terminal. Sedangkan contoh dari sistem adalah komputer,
17 terminal dan sensor remote. Bagi dua entiti agar dapat berkomunikasi dengan lancar, keduanya harus berbicara dengan dua bahasa yang sama.
Apa yang dkomunikasikan, bagaimana komunikasi itu terjadi, serta saat komunikasi itu dilakukan haruslah sesuai dengan kesepakatan antara entiti-entiti yang terlibat. Kesepakatan yang dimaksud adalah protokol, yaitu suatu rangkaian aturan yang membawahi proses pertukaran data antara dua entiti.
Elemen – elemen kunci dari sebuah protokol adalah sebagai berikut
(Prakoso, 2005: 164) :
1. Syntax, meliputi struktur atau format data, yang berarti urutan dari
bagaimana representasinya. Sebagai contoh, sebuah protokol dapat
mengandung 8 bit data pertama untuk alamat pengirim, 8 bit kedua
untuk alamat penerima dan sisanya untuk pesan itu sendiri
2. Semantics, meliputi arti dari tiap bagian bit. Bagaimana pola tertentu
diinterpretasikan dan bagaimana tindakan yang diambil berdasarkan
interpretasi tersebut. Sebagai contoh , apakah sebuah alamat yang
mengidentifikasikan rute harus diambil atau tujuan akhir dari pesan
tersebut
3. Timing, meliputi dua karakteristik : bagaimana data dikirim dan
seberapa cepat dikirimnya. Sebagai contoh, jika pengirim
18 menghasilkan data dala 100 Mbps tetapi penerima dapat memproses
data hanya dalam 1 Mbps, transmisi tersebut akan overload dan
beberapa data akan hilang.
Dalam jaringan komputer, untuk menjelaskan proses komunikasi antara dua entiti digunakan arsitektur model Layer. Dua arsitektur protokol telah disediakan sebagai dasar atau basis pengembangan standar-standar komunikasi: OSI reference model dan TCP/IP protocol suite.
2.31 Referensi Model OSI
Model OSI (Open Systems Interconnection) dikembangkan
oleh ISO (International Organization for Standardization)
sebagai model untuk arsitektur komunikasi komputer. Model
OSI juga digunakan sebagai kerangka kerja bagi pengembangan
standar-standar protokol (Stallings, 2001: 21).
Model OSI terdiri dari tujuh lapisan/Layer. Berikut
merupakan gambar tujuh Layer dari Model OSI dan
penjelasannya :
19
Gambar 2.2 Lapisan-lapisan OSI (Sumber: Stallings, 2001: 20)
2.3.2 Protokol model TCP/IP
TCP/IP mereperentasikan kumpulan dari protokol-protokol
jaringan yang menyediakan layanan di Layer Network dan
Transport dari Reference Model OSI (Lamle, 2005: 68). Suite
protokol TCP/IP yang dikembangkan oleh US Departement of
Defense Advanced Research Project Agency Network
20 (ARPANet) ini juga dikenal sebagai protokol DOD atau Internet
protocol suite.
Gambar 2.3 TCP/IP Protocol Suite (Sumber: http://technet.microsoft.com)
Fungsi dari tiap-tiap lapisan itu adalah sebagai berikut
(Iskandarsyah, 2003, 3-4):
1. Aplication layer. Fungsi utama lapisan ini adalah
pemindahan file. Perpindahan file dari sebuah sistem ke
sistem lainnya yang berbeda memerlukan suatu sistem
pengendalian untuk mengatasi adanya ketidakcocokan
sistem file yang berbeda – beda. Protokol ini berhubungan
21 dengan aplikasi. Salah satu contoh aplikasi yang telah
dikenal misalnya HTTP (Hypertext Transfer Protocol)
untuk web, FTP (File Transfer Protocol) untuk
perpindahan file, dan TELNET untuk terminal maya jarak
jauh.
2. Transport Layer. Dalam mentransmisikan data pada layer
Transpor ada dua protokol yang berperan yaitu TCP dan
UDP. TCP merupakan protokol yang connection-oriented
yang artinya menjaga reliabilitas hubungan komunikasi
end-to-end. Konsep dasar cara kerja TCP adalah mengirm
dan menerima segment – segment informasi dengan
panjang data bervariasi pada suatu datagram internet. TCP
menjamin realibilitas hubungan komunikasi karena
melakukan perbaikan terhadap data yang rusak, hilang atau
kesalahan kirim. Sedangkan UDP digunakan untuk situasi
yang tidak mementingkan mekanisme reliabilitas.
3. Internet Layer. Internet Protocol dalam lapisan internet
didesain untuk interkoneksi sistem komunikasi komputer
pada jaringan paket-switched. Pada jaringan TCP/IP,
sebuah komputer diidentifikasi dengan alamat IP. Tiap-tiap
22 komputer memiliki alamat IP yang unik, masing-masing
berbeda satu sama lainnya. Hal ini dilakukan untuk
mencegah kesalahan pada transfer data.
4. Netwok Interface Layer. Protokol data akses yang
berhubungan langsung dengan media fisik. Protokol ini
bertugas untuk menangani media dan proses transfer data
2.4 VoIP
Voice over Internet Protocol (VoIP) adalah teknologi yang mampu
melewatkan trafik suara, video dan data yang berbentuk paket melalui
jaringan IP. Jaringan IP sendiri adalah merupakan jaringan komunikasi
data yang berbasis packet-switch, jadi dalam bertelepon menggunakan
jaringan IP atau Internet. Dengan bertelepon menggunakan VoIP,
banyak keuntungan yang dapat diambil diantaranya adalah dari segi
biaya, VoIP lebih murah dari tarif telepon tradisional, karena jaringan IP
bersifat global. Sehingga untuk hubungan internasional dapat ditekan
hingga 70%. Selain itu, biaya maintenance dapat di tekan karena voice
dan data network terpisah, sehingga IP Phone dapat di tambah, dipindah
dan di ubah. Hal ini karena VoIP dapat dipasang di sembarang ethernet
23 dan IP address, tidak seperti telepon tradisional yang harus mempunyai port tersendiri di Sentral atau PBX (Iskandarsyah,2003: 1).
Gambar 2.5 Jaringan VoIP (Sumber: Raharja, 2004: 5)
VoIP yang bekerja di Layer 3, menggunakan beragam protokol point-to-point Layer 2 atau protokol-protokol data link, seperti PPP,
Frame Relay, atau ATM, untuk kebutuhan transportnya. Dalam VOIP, digital signal processors (DSP) melakukan segmentasi (pemecahan) sinyal voice ke berbagai bentuk frame dan menyimpan mereka dalam paket-paket suara. Paket-paket suara tersebut selanjutnya ditransportasikan melewati jaringan IP bekerjasama dengan protokol
24 komunikasi suara, seperti H.323, Media Gateway Control Protocol
(MGCP), atau Session Initiation Protocol (SIP) (Rafiudin, 2004: 6).
Dua protokol session yang akan dibahas disini adalah H.323 dan SIP.
Tabel 2.1 Hubungan OSI Model,protokol dan fungsi elemen jaringan VoIP (Sumber: Rafiudin,2006: 4) Nomor Layer OSI Nama Layer Protokol-protokol VoIP 7 Application NetMeeting/Applications 6 Presentation Codecs 5 Session H.323/MGCP/SIP 4 Transport RTP/TCP/UDP 3 Network IP 2 Data Link Frame Relay, ATM, Ethernet, PPP, MLP dll.
2.5 Keuntungan dan Kelemahan VoIP Keuntungan yang didapat dari penerapan komunikasi VoIP antara
lain (Alexander, 2007: 24):
1. Biaya lebih rendah untuk sambungan langsung jarak jauh.
Penekanan utama dari VoIP adalah biaya. Dengan dua lokasi yang
terhubung dengan internet maka biaya percakapan menjadi sangat
rendah.
2. Memanfaatkan infrastruktur jaringan data yang sudah ada untuk
suara. Berguna jika perusahaan sudah mempunyai jaringan. Jika
25 memungkinkan jaringan yang ada bisa dibangun jaringan VoIP
dengan mudah. Tidak diperlukan tambahan biaya bulanan untuk
penambahan komunikasi suara.
3. Penggunaan bandwidth yang kecil. Dengan majunya teknologi
kompresi suara, penggunaan bandwidth untuk voice sekarang ini
menjadi sangat kecil.
4. Memungkinkan digabung dengan jaringan telepon lokal yang sudah
ada. Dengan adanya gateway bentuk jaringan VoIP bisa
disambungkan dengan PABX yang ada dikantor. Komunikasi antar
kantor bisa menggunakan pesawat telepon biasa
5. Berbagai bentuk jaringan VoIP bisa digabungkan menjadi jaringan
yang besar. Contoh di Indonesia adalah VoIP Rakyat.
6. Variasi penggunaan peralatan yang ada, misal dari PC disambung ke
telepon biasa, IP phone handset.
Sementara itu kelemahan dari penggunaan VoIP sampai saat ini adalah:
1. Kualitas suara tidak sejernih Telkom. Merupakan efek dari
kompresi suara dengan bandwidth kecil maka akan ada
penurunan kualitas suara dibandingkan jaringan PSTN
26 konvensional. Namun jika koneksi internet yang digunakan
adalah koneksi internet pita-lebar / broadband seperti Telkom
Speedy, maka kualitas suara akan lebih jernih dan tidak terputus-
putus.
2. Ada jeda dalam berkomunikasi. Proses perubahan data menjadi
suara, jeda jaringan, membuat adanya jeda dalam komunikasi
dengan menggunakan VoIP.
3. Regulasi dari pemerintah RI membatasi penggunaan untuk
disambung ke jaringan milik Telkom.
4. Jika belum terhubung secara 24 jam ke internet perlu janji untuk
saling berhubungan.
5. Jika memakai internet dan komputer dibelakang NAT (Network
Address Translation), maka dibutuhkan konfigurasi khusus
untuk membuat VoIP tersebut berjalan.
6. Tidak pernah ada jaminan kualitas jika VoIP melewati internet.
7. Peralatan relatif mahal. Peralatan VoIP yang menghubungkan
antara VoIP dengan PABX (IP telephony gateway) relatif
berharga mahal.
8. Berpotensi menyebabkan jaringan terhambat/Stuck. Jika
pemakaian VoIP semakin banyak, maka ada potensi jaringan
27 data yang ada menjadi penuh jika tidak diatur dengan baik.
Pengaturan bandwidth adalah perlu agar jaringan di perusahaan
tidak menjadi jenuh akibat pemakaian VoIP.
9. Penggabungan jaringan tanpa dikoordinasi dengan baik akan
menimbulkan kekacauan dalam sistem penomoran.
2.6 Quality of Service (QOS)
Quality of Service (QoS) dalam istilah jaringan komputer
merupakan kemampuan menyediakan prioritas yang berbeda-beda ke
aplikasi, user, yang berbeda-beda pula untuk menjamin tingkat
performance tertentu untuk aliran data (Prakoso, 2005: 157). Jaminan
QoS penting jika kapasitas jaringan tidak mencukupi, terutama untuk
aplikasi streaming multimedia seperti VoIP, online games, IP-TV.
Beberapa parameter dari QoS antara lain:
1. Data Rate: ukuran kecapatan transmisi data, satuannya Kbps or
Mbps.
2. Latency (maximum packet delay) : waktu maksimum yang
dibutuhkan dari transmisi ke penerimaan yang diukur dengan
satuan milidetik. Dalam voice communication: <= 50 ms
28 3. Packet Loss / Error : ukuran error rate dari transmisi paket data
yang diukur dalam persen. Packet hilang (bit loss) yang
biasanya dikarenakan buffer yang terbatas, urutan paket yang
salah termasuk dalam error rate ini. Sedangkan Packet Loss
merupakan payload/frame-size dari Transmitter dikurangi
frame-size dari Receiver.
4. Jitter : ukuran delay penerimaan paket yang melambangkan
smoothness dari audio/video playback.
2.7 Codec
Pengkodean suara merupakan pengalihan kode analog menjadi kode
digital agar suara dapat dikirim dalam jaringan komputer (Purbo, 2007:
6). Pengkodean dikenal dengan istilah codec, singkatan dari
compressor-decompressor. Berbagai jenis codec dikembangkan untuk
memampatkan/mengkompresi suara agar bisa menggunakan bandwith
secara lebih hemat tanpa mengorbankan kualitas suara.
Ada beberapa standar codecsuara yang banyak digunakan di
jaringan:
GIPS - 13.3Kbps dan lebih tinggi.
GSM - 13,3Kbps(full rate), 20ms frame size.
29 iLBC - 15Kbps, 20ms frame size: 13,3Kbps, 30ms frame size.
ITU G.711 - 64 Kbps, sample-based (alaw/ulaw)
ITU G.729 - 8Kbps, 10ms frame size
Codec yang sering digunakan adalah codec G.729 dan GSM,
sedangkan di LAN biasanya digunakan codec G.711 yang memang
bagus kualitasnya. Pengguna open source lebih banyak menggunakan
codec GSM yang tidak memiliki hak cipta (copyright). Sementara itu ,
banyak peralatan VoIP menggunakan codec G.729, tapi codec ini
memiliki hak cipta.
2.8 H.323
VoIP dapat berkomunikasi dengan sistem lain yang beroperasi pada jaringan packet-switch. Untuk dapat berkomunikasi dibutuhkan suatu standar sistem komunikasi yang kompatibel satu sama lain. Salah satu standar komunikasi pada VoIP menurut rekomendasi ITU-T adalah H.323 (1995-
1996).
Standar H.323 terdiri dari komponen, protokol, dan prosedur yang menyediakan komunikasi multimedia melalui jaringan packet-based. Bentuk jaringan packet-based yang dapat dilalui antara lain jaringan internet, Internet
Packet Exchange (IPX)-based, Local Area Network (LAN), dan Wide Area
30 Network (WAN). H.323 dapat digunakan untuk layanan - layanan multimedia seperti komunikasi suara (IP telephony), komunikasi video dengan suara (video telephony), dan gabungan suara, video dan data.
Tujuan desain dan pengembangan H.323 adalah untuk memungkinkan interoperabilitas dengan tipe terminal multimedia lainnya. Terminal dengan standar H.323 dapat berkomunikasi dengan terminal H.320 pada N-ISDN, terminal H.321 pada ATM, dan terminal H.324 pada Public Switched
Telephone Network (PSTN). Terminal H.323 memungkinkan komunikasi real time dua arah berupa suara , video dan data (Iskandarsyah, 2003: 5).
2.8.1 Arsitektur H.323
Standar H.323 terdiri dari 4 komponen fisik yg digunakan saat
menghubungkan komunikasi multimedia point-to-point dan point-to-
multipoint pada beberapa macam jaringan. Komponen-komponen
tersebut adalah:
31
Gambar 2.6 Arsitektur H.323
(Sumber : Iskandarsyah, 2003: 6)
A. Terminal
Terminal digunakan untuk komunikasi multimedia real time
dua arah . Terminal H.323 dapat berupa personal computer
(PC) atau alat lain yang berdiri sendiri yang dapat
menjalankan aplikasi multimedia.
B. Gateway
Gateway digunakan untuk menghubungkan dua jaringan
yang berbeda yaitu antara jaringan H.323 dan jaringan non
H.323, sebagai contoh gateway dapat menghubungkan dan
menyediakan komunikasi antara terminal H.233 dengan
32 jaringan telepon , misalnya: PSTN. Dalam menghubungkan
dua bentuk jaringan yang berbeda dilakukan dengan
menterjemahkan protokol-protokol untuk call setup dan
release serta mengirimkan informasi antara jaringan yang
terhubung dengan gateway. Namun demikian gateway tidak
dibutuhkan untuk komunikasi antara dua terminal H.323.
C. Gatekeeper
Gatekeeper dapat dianggap sebagai otak pada jaringan H.323
karena merupakan titik yang penting pada jaringan H.323.
D. Multipoint Control Unit (MCU)
MCU digunakan untuk layanan konferensi tiga terminal
H.323 atau lebih. Semua terminal yang ingin berpartisipasi
dalam konferensi dapat membangun hubungan dengan
MCU yang mengatur bahan-bahan untuk konferensi,
negosiasi antara terminal-terminal untuk memastikan audio
atau video coder/decoder (CODEC). Menurut standar
H.323, sebuah MCU terdiri dari sebuah Multipoint
Controller (MC) dan beberapa Multipoint Processor (MP).
MC menangani negoisasi H.245 (menyangkut pensinyalan)
antar terminal-terminal untuk menenetukan kemampuan
33 pemrosesan audio dan video. MC juga mengontrol dan
menentukan serangkaian audio dan video yang akan
multicast. MC tidak menghadapi secara langsung
rangkainan media tersebut. Tugas ini diberikan pada MP
yang melakukan mix, switch, dan memproses audio, video,
ataupun bit – bit data. Gatekeeper, gateway, dan MCU secara
logik merupakan komponen yang terpisah pada standar
H.323 tetapi dapat diimplementasikan sebagai satu alat
secara fisik.
2.8.2 Protokol-protokol H.323
Spesifikasi H.323 menjelaskan kegunaan dari bermacam-macam protokol untuk transmisi data, video dan audio. Menurut ITU-T
Recommendations protokol-protokol tersebut antara lain :
1. H.225 Registration, Admission and Status (RAS), digunakan
antara H.323 end-point dan Gatekeeper untuk menyediakan
address resolution dan layanan admission control.
2. H.225 Call Signalling, digunakan antara dua entiti H.323
untuk membangun komunikasi .
34 3. H.245 Control Protocol untuk komunikasi multimedia, yang
menjelaskan pesan dan prosedur yang digunakan untuk
capability exchange, membuka dan menutup channel logikal
untuk audio, video dan data, control dan indikasi.
4. Real Time Transport Protocol (RTP), yang digunakan untuk
mengirim dan menerima informasi multimedia (video, data
dan suara) antar dua entiti.
5. H.235 series, digunakan dalam keamanan signal dan media
6. H.239, menjelaskan dual stream dalam video-conference,
biasanya satu untuk live video dan satu untuk still image.
7. H.450 series, untuk bermacam-macam layanan tambahan
(supplementaries)
8. H.460 series, mendefinisikan ekstensi optional yang
diimplementasikan dalam di endpoint atau Gatekeeper, dan
sebagai Network Addredd Translation /Firewall tranversal.
35
Gambar 2.7 Protokol-protokol H.323
(Sumber: www.accessgrid.org)
Pada H.323 terdapat beberapa protokol dalam pengiriman data yang mendukung agar data terkirim secara real-time. Dibawah ini dijelaskan beberapa protokol pada Layer network dan transport
(Iskandarsyah, 2003: 7):
1. RTP (Real-Time Protocol)
Protokol yang dibuat untuk mengkompensasi jitter dan
desequencing yang terjadi pada jaringan IP. RTP dapat
digunakan untuk beberapa macam data stream yang realtime
36 seperti data suara dan data video. RTP berisi informasi tipe data yang di kirim, timestamps yang digunakan untuk pengaturan waktu suara percakapan terdengar seperti sebagaimana diucapkan, dan sequence numbers yang digunakan untuk pengurutan paket data dan mendeteksi adanya paket yang hilang.
Gambar 2.8 RTP Header
(Sumber: Iskandarsyah: 2003, 8)
RTP didesain untuk digunakan pada Layer transport.
Namun demikian, RTP digunakan diatas UDP, bukan pada TCP karena TCP tidak dapat beradaptasi pada pengerimiman data yang real-time dengan keterlambatan yang relatif kecil seperti pada pengiriman data komunikasi suara. Dengan menggunakan
UDP yang dapat mengirimkan paket IP secara multicast, RTP
37 stream yang dibentuk oleh satu terminal dapat dikirimkan ke beberapa terminal tujuan.
2. RTCP (Real-Time Control Protocol)
Merupakan suatu protokol yang biasanya digunakan bersama-sama dengan RTP. RTCP digunakan untuk mengirimkan packet control setiap terminal yang berpartisipasi pada percakapan yang digunakan sebagai informasi untuk kualitas transmisi pada jaringan. Terdapat dua komponen penting pada paket RTCP, yang pertama adalah sender report yang berisikan informasi banyaknya data yang dikirimkan, pengecekan timestamp pada header RTP dan memastikan bahwa datanya tepat dengan timestamp-nya. Elemen yang kedua adalah receiver report yang dikirimkan oleh penerima panggilan.
Receiver report berisi informasi mengenai jumlah paket yang hilang selama sesi percakapan, menampilkan timestamp terakhir dan delay sejak pengiriman sender report yang terakhir.
3. RSVP (Resource Reservation Protocol)
RSVP bekerja pada layer transport. Digunakan untuk menyediakan bandwidth agar data suara yang dikirimkan tidak mengalami delay ataupun kerusakan saat mencapai alamat
38 tujuan unicast maupun multicast. RSVP merupakan signaling protocol tambahan pada VoIP yang mempengaruhi QoS.
RSVP bekerja dengan mengirimkan request pada setiap node dalam jaringan yang digunakan untuk pengiriman data stream dan pada setiap node RSVP membuat resource reservation untuk pengiriman data. Resource reservation pada suatu node dilakukan dengan menjalankan dua modul yaitu admission control dan policy control.
Admission control digunakan untuk menentukan apakah suatu node tersebut memiliki resource yang cukup untuk memenuhi QoS yang dibutuhkan. Policy control digunakan untuk menentukan apakah user yang memiliki ijin administratif
(administrative permission) untuk melakukan reservasi. Bila terjadi kesalahan dalam aplikasi salah satu modul ini, akan terjadi RSVP error dimana request tidak akan dipenuhi. Bila kedua modul ini berjalan dengan baik, maka RSVP akan membentuk parameter packet classifier dan packet scheduler.
Packet Clasiffier menentukan kelas QoS untuk setiap paket data yang digunakan untuk menentukan jalur yang digunakan untuk pengiriman paket data berdasarkan kelasnya dan Packet
39 Scheduler berfungsi untuk menset antarmuka (interface) tiap
node agar pengiriman paket sesuai dengan QoS yang diinginkan.
2.9 Session Initation Protocol
Menurut RFC 2543, Session Initiation Protocol (SIP) adalah “an
application-layer control (signaling) protocol for creating, modifying
and terminating sessions with one or more participants. These sessions
include Internet multimedia conferences, Internet telephone calls and
multimedia distribution”.
Protokol SIP mempunyai empat fungsi yaitu (Raharja, 2004: 9):
1. Call Initiation, yaitu membangun sebuah sesi komunikasi
dan mengundang user lain untuk bergabung dalam sesi
komunikasi.
2. Call Modification, bila perlu SIP dapat memodifikasi sesi
komunikasi.
3. Call Termination, menutup sesi komunikasi
4. Presence, mengumumkan status user pada user lain, online
atau offline, away atau busy
Dalam VoIP, terdapat dua channel untuk pembuatan session
panggilan, yaitu signaling channel (SIP) dan media channel
40 (RTP/RTCP). Protokol SIP bekerja di layer Application pada layer
TCP/IP. SIP bukan sebuah protokol media transfer, sehingga SIP tidak membawa paket suara atau video. SIP memanfaatkan RTP (Real Time
Protocol) untuk media transfer.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.20.30.40:5060
From: UserA
To: UserB
Call-ID: [email protected]
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 141
Gambar 2.9 Contoh Paket SIP
(Sumber: Alexander, 2007: 6)
Session Initiation Protocol (SIP) dibangun dengan empat buah komponen yang mendukung berjalannya transfer data dan suara.
Komponen tersebut adalah user agent, proxy, redirect server dan registrar (Raharja, 2004: 10).
41
Gambar 2.10 Arsitektur SIP
(Sumber: Raharja, 2004: 10)
User agent adalah komponen SIP yang memulai, menerima, dan menutup sesi komunikasi. User agent terdiri dari dua komponen utama, yaitu User Agent Client (UAC), yaitu komponen yang memulai sesi komunikasi dan User Agent Server (UAS), yang menerima atau menanggapi sesi komunikasi. Baik UAC maupun UAS dapat menutup sesi komunikasi. Bentuk dari user agent sendiri dapat berupa software
(softphone seperti Kphone, X-Lite, SJPhone dsb) dan hardware (Analog
Telephone Adaptor, IP Phone, USB Phone dsb).
42 Proxy merupakan komponen penengah antar user agent, yang bertindak sebagai server dan client yang menerima request message dari user agent dan menyampaikan pada user agent lainnya. Request message ini dapat dilayani sendiri atau disampaikan (forward) pada proxy lain atau server lain. Proxy bertugas untuk menerjemahkan dan atau menulis ulang request message sebelum menyampaikan pada user agent tujuan atau proxy lain. Proxy server menyimpan state sesi komunikasi antara UAC dan UAS.
Redirect server adalah komponen yang menerima request message dari user agent, memetakan alamat SIP user agent atau proxy tujuan kemudian menyampaikan hasil pemetaan kembali pada user agent pengirim (UAC). Redirect server tidak menyimpan state sesi komunikasi antara UAC dan UAS setelah pemetaan disampaikan pada
UAC. Tidak seperti proxy server, redirect server tidak dapat memulai inisiasi request message dan tidak seperti UAS, redirect server tidak dapat menerima dan menutup sesi komunikasi.
Registrar merupakan komponen yang menerima request message REGISTER. Registrar dapat menambahkan fungsi otentikasi user untuk validasi. Registrar menyimpan database user untuk otentikasi dan lokasi sebenarnya (berupa IP dan port) agar user agar
43 yang terdaftar dapat dihubungi oleh komponen SIP lainnya (berfungsi
juga sebagai Location Server). Komponen ini biasa disandingkan
dengan proxy server.
2.10 Secure Real-time Transprot Protocol (SRTP)
Secure Real transport Protocol (SRTP) adalah sebuah standar
mekanisme untuk melindungi media real-time(suara dan video) dalam
aplikasi multimedia. SRTP mendeskripsi profil protokol RTP (Real
Time Protocol) untuk menyediakan confidentiality, integrity, dan
autentikasi media streaming yang didefinisikan di RFC 3711. SRTP
juga melindungi pesan dari RTCP (Real Time Transport Control
Protocol) yang memberikan feedback QoS pada VoIP. Hal ini karena
RTP dan RTCP sama-sama digunakan dalam multimedia session
meskipun port yang digunakan berbeda (Thermos, 2007: 218).
2.10.1 Proses SRTP
Proses SRTP dimulai saat aplikasi men-capture input dari
device (contohnya microphone atau kamera). Input tersebut di-
encode sinyal menggunakan codec standar atau negosiasi
(G.711, G.729, H.261, H.264) dan menghasilkan payload paket
44 RTP. Kemudian paket RTP dienkripsi dengan algoritma enkripsi yang dinegosiasikan (Thermos, 2007: 219).
SRTP menggunakan dua mode dalam prosesnya. Mode
Counter menggunakan kriptografi AES dengan panjang kunci
128 bit dan saltkey (bit random untuk kunci) 112 bit. Mode
AES-F8 digunakan dalam jaringan mobile 3G dengan men- enkripsi data UMTS (Unified Mobile Telecommunication
System) dengan panjang kunci yang sama dengan mode counter.
SRTP juga mampu meniadakan enkripsi dengan menggunakan null cipher (hasil streaming kunci berupa 0 saja).
Gambar 2.11 Proses pembuatan paket SRTP
(Sumber: Alexander, 2007: 11)
45 Untuk menambah enkripsi data, SRTP menunjang autentikasi
dan integritas paket RTP. Secara default, SRTP menggunakan algoritma
SHA-1 dengan panjang kunci 160 bit. Sebuah MAC (Message
Authentication Code) dibuat dari hasil hash keseluruhan paket RTP,
termasuk RTP header dan payload yang terenkripsi dan meletakkan
hasil perhitungannya ke authentication tag header. Penggunaan
authentication tag ini penting untuk melindungi dari serangan message-
replay. Serangan ini memodifikasi pesan-pesan audio/video menjadi
corrupt dan kacau. Atau dapat juga dengan mengirim pesan tiruan
sehingga device mengalihkan sumberdaya untuk memproses pesan
tersebut.
Tabel 2.2 Manajemen Kunci SRTP
(Sumber: Thermos,2007: 224)
Parameter Mandatory Default
SRTP/ SRTCP Kriptografi AES_CM, NULL AES_CM, AES_F8, for UMTS SRTP/SRTCP Autentikasi HMAC_SHA1 HMAC_SHA1 Parameter Autentikasi 80-bit Authentication 80-bit Authentication SRTP/SRCP Tag tag Fungsi Key Derivation AES_CM AES_CM Panjang kunci Enkripsi 128 bit 128 bit Panjang kunci Autentikasi 160 bit 160 bit
46 Panjang kunci Salt 112 bit 112 bit Rata-rata Key Derivation 0 0 Paket SRTP lifetime 248 248 Paket SRTCP lifetime 231 231 Indikator MKI 0 0 Panjang MKI 0 0
2.10.2 Kelebihan dan kekurangan SRTP
SRTP menyediakan beberapa properti untuk mengamankan
streaming media dalam komunikasi multimedia. Karena itu ada
beberapa hal yang perlu diperhatikan dalam menerapkan SRTP pada
jaringan. Kelebihan dari SRTP antara lain :
1. Menyediakan kepercayaan (confidentiality), integritas dan
autentikasi dari isi pesan.
2. Menyediakan perlindungan terhadap replay attack terhadap
RTP dan RTCP
3. Karena SRTP menunjang AES, SRTP menyediakan
perlindungan terhadap DoS attack yang bertujuan merusak
isi pesan.
4. Algoritma kunci (AES dan hash) membantu melindungi dari
serangan cryptanalytic tertentu dan menyediakan
kerahasiaan penerusan pesan .
47 Pengembangan SRTP masih menyisakan beberapa kekurangan
yang harus dioptimalkan. Kekurangan SRTP antara lain:
1. Jika diatur null cipher, maka membiarkan terjadinya analisa
trafik pada paket data.
2. Belum dapat menjamin integritas dan autentikasi pesan dari
jaringan IP ke PSTN.
3. Penyegaran kunci (refresh) dan manajemen kunci
berpengaruh terhadap konsumsi sumberdaya dalam jaringan
multicast yang besar. Hal ini kurang cocok dengan peralatan
mobile dengan sumber daya terbatas.
2.11 Asterisk
Asterisk adalah sebuah framework yang terdapat beberapa
modul/bagian di dalamnya untuk menciptakan suatu sistem telepon
yang sesuai. Asterisk dikembangkan oleh Digium dan merupakan inti
dari sistem VoIP yang dibangun serta bersifat open source yang hanya
berjalan di sistem operasi Linux. Dengan Asterisk, sistem VoIP dapat
diintegraskan dengan sistem telepon. Asterisk mendukung protokol SIP.
Pada saat skripsi ini dibuat, telah terdapat Asterisk versi 1.6.2. Asterisk
bsa didownload pada http://asterisk .org.
48 2.11.1 Konfigurasi Minimal Asterisk
Untuk dapat melakukan panggilan terhadap beberapa file
yang perlu dikonfigurasikan yaitu:
2.9.1.1 sip.conf
File ini terdapat pada /etc/asterisk/sip.conf. File ini
berguna untuk autentikasi username. Berikut ini baris yang
perlu ditambahkan untuk penambahan user:
[2001]
context=default
type=friend
username=2001
secret=asdf
host=dynamic
dtmfmode=rfc2833
mailbox=2001@default
Keterangan dari baris diatas yaitu:
[2001] : Menandakan username atau nomer ekstensi
user tersebut.
49 context : Context untuk panggilan masuk ke VoIP
server type : Secara default yaitu friend. Terdapat beberapa
tipe yaitu friend, peer dan user. Jika user maka
hanya dapat menerima panggilan. Jika peer
maka hanya dapat melakukan panggilan. Friend
berarti dapat melakukan panggilan dan
menerimanya. username: User name yang digunakan. Username ini
merupakan nomor ekstensi. secret : Password yang digunakan. host : Bisa berisi dynamics, hostname atau alamat
IP. Secara default berisikan dynamics. Jika
dynamics berarti user sendiri yang
mendaftarkan mengenai alamat IP yang
dimilikinya. Jika hostname atau alamat IP,
maka user tersebut terdaftar berdasarkan
hostname atau alamat IP tersebut. dtmfmode : Aturan dtmf yang digunakan yatu standar
RFC2833.
50 mailbox : user pada mailbox.
2.9.1.2 extensions.conf
File ini terdapat pada /etc/asterisk/extensions.conf.
File ini berfungsi untuk menentukan apa yang harus
dilakukan jika ada panggilan ke ekstensi tertentu.
Sebagai contoh yaitu sebagai berikut:
exten=>_20xx,1,Dial(SIP/${EXTEN},20,rt)
exten=>_20xx,2,HangUp
Arti dari perintah tersebut yaitu jika ada panggilan
masuk ke ekstensi 20xx maka langkah pertama yaitu
melakukan dial/panggilan ke ekstension tersebut dengan
protokol SIP dan tunggu dua puluh detik, jika panggilan
tersebut tidak diangkat maka timeout (rt). Langkah
berikutnya yaitu hangup.
2.11.2 Modul Pendukung Asterisk
Untuk dapat berfungsi lebih maksimal maka perlu
beberapa modul pendukung yaitu:
51 2.9.2.1 Zaptel / DAHDI
Modul ini berfungsi jika pada server menggunakan card
Zapata yang berfungsi untuk menghubungkan sistem VoIP
dengan sistem telepon. Modul ini juga berfungsi pada fitur
Meetme.
2.9.2.2 LibPRI
Modul driver yang dibutuhkan jika menggunakan interface
Digium untuk menghubungkan ke sisten telepon.
2.9.2.3 Mpg123
Modul yang berfungsi pada fitur musicon hold (MOH).
Dengan adanya modul ini maka file musik bisa dijalankan.
2.9.2.4 Asterisk Add-ons
Modul suara operator wanita. Modul ini bekerja misalkan
pada fitur echo test dan speaking clock.
52 2.12 Twinkle
Twinkle merupakan sebuah softphone VoIP yang menggunakan
protokol SIP pada sistem operasi Linux. Twinkle dibuat oleh Michel De
Boer pada Februari tahun 2009, yang pada saat itu hanya dapat
melakukan call sederhana. Kontribusi dari berbagai komunitas,
menjadikan Twinkle mendapat fitur-fitur baru antara lain:
1. Mensupport ZRTP/SRTP.
2. Autentikasi digest MD5 untuk SIP request.
3. Mensupport Advance Linux Sound Architecture (ALSA).
Gambar 2.12 Aplikasi Twinkle
53 2.13 Network Address Translation (NAT)
Network Address Translation (NAT) merupakan standar IETF
yang membuat LAN menggunakan satu set alamat IP untuk lalu-lintas
internal dan satu set lainnya untuk lalu lintas eksternal (Lamle, 2005:
69). Translasi alamat IP terjadi jika LAN bertemu dengan internet. NAT
mengkonversi packet header pada lalu-lintas incoming dan outgoing.
NAT dibuat dengan tujuan :
1. Sebagai firewall yang menyembunyikan alamat IP internal.
2. Membuat perusahaan dapat menggunakan alamat IP internal
yang lebih banyak, karena alamat IP internal dan alamat IP
internet perusahaan berbeda.
3. Memperbolehkan perusahaan membundel banyak koneksi
ISDN menjadi satu koneksi internet.
2.14 Rapid Application Development
RAD adalah sebuah model proses perkembangan perangkat lunak
sekuensial linier yang menekankan siklus perkembangan yang sangat
pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi”
dari model sekuensial linier di mana perkembangan cepat dicapat
dengan menggunakan pendekatan konstruksi berbasis komponen. Jika
54 kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari)
(Pressman, 2002:42).
Menurut Kendal & Kendal (2003, 237), RAD adalah suatu pendekatan berorientasi objek terhadap pengembangan sistem yang mencakup suatu metode pengembangan serta perangkat-perangkat lunak.
Gambar 2.13 Skema Pengembangan Sistem RAD
(Sumber: Kendall & Kendall, 2003: 237)
55
Metode pengembangan Rapid Application Development (RAD) memiliki beberapa keunggulan dan kelemahan. Berikut ini merupakan beberapa keunggulan dan kelemahan model RAD:
2.14.1 Keunggulan RAD
1. Meningkatkan kecepatan pengembangan aplikasi dengan
menggunakan metode-metode seperti rapid prototyping,
penggunaan CASE tools, dan teknik-teknik lainnya.
2. Mengurangi fungsionalitas end user (Fokus desain menjadi
lebih sempit), mengurangi kompleksitas.
2.11.2 Kelemahan RAD
1. Mengurangi skalabilitas pengembangan sistem.
2. Mengurangi jumlah fitur-fitur yang disertakan karena
mengejar waktu proses pengerjaan.
56 BAB III
METODOLOGI PENELITIAN
Pada bab ini akan diuraikan metode penelitian yang digunakan oleh penulis dalam Pengamanan Payload VoIP dengan Protokol SRTP , diantaranya adalah:
3.1 Metode Pengumpulan Data
Dalam melakukan penelitian ini diperlukan data-data informasi yang relatif lengkap sebagai bahan yang dapat mendukung kebenaran materi uraian pembahasan. Oleh karena itu sebelum menyusun skripsi ini, dalam persiapannya terlebih dahulu dilakukan pencarian dan pengumpulan data-data atau bahan materi yang diperlukan.
Metode pengumpulan data yang dilakukan penulis adalah metode studi pustaka, yaitu pengumpulan data dan informasi dengan cara membaca buku-buku referensi, e-book dan situs internet yang dapat dijadikan acuan pembahasan dalam masalah ini. Adapun buku-buku yang dipakai dalam skripsi ini dapat dilihat pada daftar pustaka. Selain itu penulis juga mengumpulkan data-data dan informasi apliksi VoIP yang sudah ada dari berbagai situs di internet.
3.2 Metode Pengembangan Sistem
Dalam penelitian ini metode pengembangan sistem yang digunakan adalah model pendekatan RAD (Rapid Application Depelovment). Penulis menggunakan
58 model RAD karena metode RAD adalah metode yang diperuntukkan untuk jangka pendek sesuai dengan sistem yang dikembangkan.
Model pengembangan RAD diperkenalkan oleh James Martin pada tahun
1991 Adapun skema model pengembangan RAD (Rapid Application
Development) adalah sebagai berikut:
3.2.1. Fase Perencanaan Syarat-Syarat
Pada tahap ini dilakukan pengindentifikasian tujuan aplikasi atau sistem serta untuk mengidentifikasi syarat-syarat informasi yang ditimbulkan dari tujuan- tujuan tersebut.
3.2.2. Fase Perancangan Proses
Pada tahap ini dilakukan perancangan proses yaitu menjelaskan perancangan proses-proses yang akan terjadi di dalam sistem. Perancangan ini akan dilakukan perancangan evaluasi dan memperbaiki sistem sesuai dengan kebutuhan. Perancangan proses meliputi perancangan proses VoIP dan SRTP.
3.2.3 Fase Kontruksi
Pada tahapan ini dilakukan penginstallan Asterisk, Twinkle dan Wireshark.
Serta dialakukan konfigurasi jaringan yang diisikan pada aplikasi tersebut.
59 3.2.4. Fase Pelaksanaan
Pada tahapan ini dilakukan pengujian terhadap sistem VoIP yang telah dibuat dengan inplementasi SRTP, perbandingan keadaan sebelum dan sesudah penerapan keamanan protokol SRTP tersebut.
Ilustrasi Metodologi Penelitian yang dilakukan dalam pengembangan sistem VoIP ini dapat dililhat pada gambar 3.1 di bawah ini :
60 Metode Pengumpulan Data
Tujuan: Menciptakan suatu Syarat-Syarat: Analisa Asterisk Server Kebutuha pengamanan payload VoIP berbasis Asterisk server Twinkle menggunakan protokol Library SRTP SRTP, untuk memberikan solusi dalam mengatasi
Fase Perencanaan Syarat -syarat Perancangan Fase Proses VoIP Perancangan Perancangan Proses SRTP
Konfigurasi Fase Jaringan Konstruksi Instalasi Asterisk, Wireshark, Twinkle
Ujicoba Implementasi SRTP Fase Pelaksana n Keadaan Sebelum Implementasi SRTP
Keadaan Sesudah Implementasi
Perbandingan Keadaan Sebelum dan Sesudah Implementasi SRTP Gambar 3.1 Ilustrasi Metodologi Pengembangan VoIP dengan protokol SRTP
61 BAB IV
HASIL DAN PEMBAHASAN
Perancangan dan pengembangan skripsi “Pengamanan Payload dalam VoIP
Dengan Protokol SRTP” ini menggunakan metode Rapid Application Development
(RAD). Menurut Kendall & Kendall (2003:228), tahapan-tahapan RAD terdiri atas fase perencanaan syarat-syarat, fase perancangan, fase konstruksi dan fase pelaksanaan.
4.1 Fase Perencanaan Syarat-syarat
4.1.1 Analisa Kebutuhan Masalah
Keamanan komunikasi Voice over Internet Protocol (VoIP) sudah
sangat penting untuk dikembangkan mengingat terdapat model serangan
untuk menjadikan komunikasi VoIP tersebut tidak aman. Diantaranya
adalah:
1. Pembajakan dalam proses registrasi.
2. Pengrusakan pada isi message.
3. Penghentian sesi komunikasi.
4. Denial of Service attack.
Oleh karena itu, penulis merasa perlu menyumbangkan suatu cara
perlindungan terhadap komunikasi VoIP. Penulis mencoba menggunakan
protokol SRTP untuk mengamankan komunikasi VoIP tersebut.
61 4.1.2 Tujuan
Dalam skema Voice over Internet Protocol (VOIP) yang penulis buat,
jenis keamanan yang dikembangkan adalah mengamankan protokol yang
mengirimkan paket-paket data (RTP) dengan membuat profil di protokol
tersebut dan membuat replay list sehingga tidak memungkinkan adanya
pengiriman paket-paket yang berulang.
4.1.3 Syarat-syarat
Adapun untuk mewujudkan tujuan tersebut maka dibutuhkan beberapa
syarat dalam pengembangan skripsi ini yaitu meliputi hal-hal sebagai
berikut:
1. VoIP Server
VoIP Server merupakan syarat mutlak untuk terjadinya komunikasi
VoIP. VoIP server membuat session saat pertama kali berkomunikasi
dan mendaftar pengguna yang ada dalam jaringan VoIP tersebut.
Dalam pengembangan skripsi ini, penulis menggunakan Asterisk versi
1.6.2.5.
2. VoIP Client
VoIP Client merupakan aplikasi yang digunakan oleh pengguna dalam
VoIP. Aplikasi yang digunakan oleh penulis adalah Twinkle 1.4.2.
3. Library SRTP
Secara default protokol yang digunakan dalam komunikasi VoIP
adalah Real-time Transport Protocol (RTP) dan Real-time Transport
62 Control Protocol (RCP). Kerja dari RTP adalah pembawa media
stream (seperti audio dan video) sedangkan RTCP memonitor statistic
transmisi dan informasi Quality of Service (QOS) (RFC 3711).
Karena masih rentan terhadap serangan, dibutuhkan protokol SRTP
sebagai profil pengamanannya. Library dari protokol SRTP sendiri,
terpisah dari VoIP server sehingga dibutuhkan instalasi agar dapat
berjalan dengan baik.
Spesifikasi perangkat lunak dan perangkat keras yang digunakan dalam implementasi keamanan ini adalah sebagai berikut:
a. Perangkat Lunak :
1. Asterisk VoIP Server versi 1.6.2.5
2. Linux Fedora 9
3. Wireshark 1.2.10
4. Mplayer for Linux
5. Avideo Capture Screen
6. Twinkle 1.4.2
b. Perangkat Keras :
1. Processor Intel Core2Duo T5800 @2.00 GHz
2. Processor Pentium IV @2,4 GHz
3. HDD 80 GB
4. Memory 1 GHz
5. Monitor dengan resolusi 1280x800 pixel.
63 4.2 Fase Perancangan Proses
4.2.1 Perancangan Proses Komunikasi VoIP
Protokol RTP merupakan protokol yang umumnya digunakan untuk
streaming aplikasi multimedia. Merupakan standar format paket untuk
mengirimkan audio dan video di internet.
Proses perancangan komunikasi VoIP untuk panggilan dua orang,
dijelaskan dalam gambar dibawah ini:
User 1 User 2
1: INVITE ()
2: 100 TRYING ()
3: 100 RINGING ()
4: 200 OK ()
5: ACK ()
6: RTP VOICE CALL ()
7: BYE ()
8: 200 OK ()
Gambar 4.1 VoIP Call flow
64
Topografi jaringan yang digunakan penulis, meneggunakan dua
komputer dengan desain satu buah VoIP server dan dua buah VoIP client
dibelakang NAT. Penggunaan komunikasi VoIP pada server Asterisk
menggunakan IP public yang didapatkan dari internet dan dijadikan
gateway server bagi Asterisk untuk menghubungkan pihak-pihak yang
berkomunikasi.
Gambar 4.2 Desain jaringan VoIP penelitian
4.2.2 Perancangan Proses SRTP
Tugas dari Secure Real-time Transport Protocol (SRTP) adalah
membuat suatu profil protokol Real Transport Protocol (RTP) untuk
menyediakan enkripsi, message authentication, integrity dan replay
protection ke paket data RTP.
65 Konteks Kriptografi (Crypto Context) SRTP meliputi (sesuai dengan
RFC 3711) :
1. Encryption key.
2. Salt key.
3. Message Authentication key.
4. 32-bit rollover counter (penghitung ).
5. Sequence number (urutan paket).
6. Synchronization source number (SSRC).
7. Replay list (Daftar paket yang direplay).
Setelah proses Key Management dilakukan, maka pengirim (SENDER) akan melakukan hal-hal berikut untuk membuat paket SRTP (RFC 3711).
1. Menentukan cryptographic context yang akan digunakan.
2. Menentukan Index paket SRTP menggunakan rollover counter
(ROC), urutan tertinggi dalam cryptography context, dan urutan
dalam paket RTP.
3. Meentukan Master Key dan Master Salt.
4. Menentukan Session Key dan Session Salt, dengan menggunakan
Master Key, Master Salt, Key_derivation_rate dan Session Key-
length dalam cryptographic context dengan Index.
5. Menenkripsi RTP payload untuk membuat paket yang terenkripsi,
dengan menggunakan algoritma enkripsi, Session Encryption Key,
dan Session Salt dengan Index.
6. Menambahkan MKI, bila indikator MKI di-set menjadi 1.
66 7. Untuk message authentication untuk bagian paket yg diautentikasi,
dengan menggunakan rollover counter, algoritma autentikasi, dan
Session Autentication Key dan ditempelkan pada paket.
8. Update ROC menggunakan Index.
Untuk mengautentikasi dan mendeskripsikan paket SRTP, penerima
(RECEIVER) akan melakukan sebagai berikut (RFC 3711):
1. Menentukan cryptographic context yang sesuai.
2. Menjalankan algoritma untuk mendapatkan Index. Algoritma
dijalankan dengan menggunakan rollover counter, dan urutan
tertinggi dengan urutan pada paket SRTP.
3. Menentukan Master Key dan Master Salt. Jika indikator MKI diset
ke 1, gunakan MKI pada paket SRTP. Jika tidak gunakan Index
sebelumnya.
4. Menetukan Session Key dan Session Salt, dengan mengunakan
Master Key, Master Salt, Key_derivation_rate dan
Session_key_length dengan Index.
5. Untuk message authentication dan replay protection, cek paket
apakah sudah direplay atau belum, dengan menggunakan Replay
List dan Index. Jika diketahui terjadi replay, maka paket akan
dibuang dan event akan dicatat dalam log. Kemudian dilakukan
verifikasi pada Autentication Tag, dengan menggunakan rollover
counter, algoritma autentikasi, dan Session Authentication Key.
67 Jika tidak berhasil maka paket akan dibuang dan even akan dicatat
dalam log.
6. Dekripsi bagian paket yang dienkripsi, dengan menggunakan
algoritma dekripsi, Session Encryption Key, dan Master Salt
dengan Index.
7. Update rollover counter dan urutan tertinggi dengan menggunakan
Index. Jika terdapat replay protection, update juga Replay List.
8. Jika ada, hapus MKI dan Authentication tag dari paket.
4.3 Fase Konstruksi
Pada fase ini, dilakukan instalasi aplikasi-aplikasi yang dibutuhkan dan juga
pemasangan perangkat keras dalam skema VoIP. Untuk instalasi Asterisk,
didahului dengan instalasi LibPRI sebagai library Asterisk dan DAHDI Linux
yang digunakan sebagai penghubung IP phone dan software. Kemudian diikuti
dengan isntalasi Twinkle sebagai VoIP client dan Wireshark untuk memantau
traffic paket data. Codec yang digunakan pada aplikasi adalah G.117 dan GSM.
4.3.1 Instalasi DAHDI Linux
1. Download DAHDI versi terbaru (saat ini terbaru versi 2.2.1.1)
2. Ketik tar -zxvf dahdi-linux-2.2.1.1.tar.gz
3. Ketik cd dahdi-linux-2.2.1.1
4. Ketik ./configure
5. Ketik make
68 6. Ketik make install
4.3.2 Instalasi LibPRI
1. Download LibPRI versi terbaru (saat ini terbaru versi 1.4.10.2)
2. Ketik tar -zxvf libpri-1.4.10.2.tar.gz
3. Ketik cd libpri-1.4.10.2
4. Ketik ./configure
5. Ketik make
6. Ketik make install
4.3.3 Instalasi LibSRTP
1. Download http://srtp.sourceforge.net/download.html
2. Ketik tar -xzf srtp-tarball
3. Ketik ./configure --prefix=/usr
4. Ketik make
5. Ketik make runtest
6. Ketik make install
4.3.4 Instalasi Asterisk
1. Ketik svn co http://svn.digium.com/svn/asterisk/team/
group/srtp asterisk-srtp
2. Ketik cd asterisk-srtp
3. Ketik ./configure
69 4. Ketik make menuselect (check res_srtp in "resource modules")
5. Ketik make
6. Ketik make install
4.3.5 Instalasi Asterisk Add-Ons
1. Download Add-Ons versi terbaru (versi 1.6.2)
2. Ketik tar -zxvf asterisk-addons-1.6.2.0.tar.gz
3. Ketik cd asterisk-addons-1.6.2.0
4. Ketik ./configure
5. Ketik make
6. Ketik make install
4.3.6 Instalasi Twinkle
1. Download Twinkle versi terbaru (1.4.2)
2. Ketik tar -xvfj twinkle-1.4.2
3. Ketik cd twinkle-1.4.2
4. Ketik ./configure
5. Ketik make clean
6. Ketik make
7. Ketik make install
4.3.7 Instalasi Wireshark
1. Download Wireshark versi terbaru (versi 1.2.6)
70 2. Ketik tar -xvfj wireshark-1.2.6.tar.bz2
3. Ketik cd wireshark-1.2.6
4. Ketik ./configure
5. Ketik make clean
6. Ketik make
7. Ketik make install
4.3.8 Konfigurasi Jaringan
Setelah perangkat lunak telah di-install semua, langkah
selanjutnya diberi IP address sesuai dengan kebutuhan. Pada
aplikasi Twinkle, implementasi VoIP lebih mudah karena bentuk
aplikasinya seperti telepon sehingga mudah digunakan, dan
mendukung self calling, fitur dimana dalam satu aplikasi bisa
digunakan banyak panggilan, sehingga dapat menelepon ke
aplikasi itu sendiri.
Pada software Twinkle 1.4.2, diisikan pada pilihan menu SIP
proxy sebagai berikut:
Menu SIP Proxy Default SIP Proxy 1
Enabled Yes Yes
Display Name user1 user2
Authorization User user1 user2
Password user1 user2
Domain/realm 192.168.1.4 192.168.1.3
71 SIP Proxy 192.168.1.4 192.168.1.3
Outbound Proxy 192.168.1.4 192.168.1.3
Tabel 4.1 Menu SIP Proxy pada Twinkle
Pada server Asterisk, perlu dibuat dial-plan sehingga peng- gunaan SRTP hanya untuk setting VoIP client yang sudah dibuat.
File konfigurasi yang perlu diubah terletak di /etc/asterisk yaitu file sip.conf dengan penambahan srtpcapable dan extension.conf dengan penambahan _SIPSRTP=${SIPPEER (srtpcapable)}. sip.conf srtpcapable=yes
[user1] type=friend username=user1 secret=user1 host=dynamic context=tescoba nat=yes canreinvite=yes disallow=all allow=ulaw srtpcapable=yes
Gambar 4.3 Konfigurasi sip.conf
72 [tescoba] exten => 123,1,Dial(SIP/user1) exten => 432,1,Dial(SIP/user2) exten => _600X,1,Set(_SIPSRTP=${SIPPEER(${EXTEN}, srtpcapable)}) exten=> 123,1,Set(_SIPSRTP=${SIPPEER(${EXTEN}, srtpcapable)}) exten=> 432,1,Set(_SIPSRTP=${SIPPEER(${EXTEN}, srtpcapable)}) exten => _600X,n,Dial(SIP/${EXTEN}) exten => 600,1,Playback(demo-echotest) exten => 600,n,Echo ; Do the echo test exten => 600,n,Playback(demo-echodone) exten => 600,n,hangup
Gambar 4.4 Konfigurasi extension.conf
4.4 Fase Pelaksanaan
Fase pelaksanaan terdiri dari empat tahap, yaitu :
4.4.1 Implementasi SRTP pada Asterisk
Implementasi SRTP dimulai dengan menginstal library SRTP yang
bisa diunduh secara gratis di www.sourceforge.net. Setelah diinstall, maka
dilakukan pengecekan dengan mengetik:
# asterisk -&
# asterisk -r
73
Gambar 4.5 Tampilan awal Asterisk
Jika berhasil diinstall, maka akan tertera pesan ”Asterisk SVN-group-
srtp”. Kemudian jika diketikkan:
# sip show peers
Maka akan muncul keterangan pengguna yang terhubng dalam server.
Pada keterangan sebelumnya, ”user1” dan ”user2” telah didaftarkan dalam
server.
4.4.2 Keadaan sebelum implementasi SRTP diterapkan pada protokol RTP
Untuk dapat melakukan komunikasi VoIP dengan aman, perlu
dilakukan implementasi pada kedua sisi yang terhubung, yaitu server dan
client. Jika hanya dilakukan pada salah satu sisi, maka implementasi tidak
akan berpengaruh pada segi keamanan karena protokol SRTP harus
diterapkan antara pihak-pihak yang terhubung,
Untuk mengetahui paket-paket data yang yang ditransmisikan dalam
VoIP, maka diperlukan suatu aplikasi yang dapat memantau dan
74 menangkap paket-paket data tersebut. Aplikasi yang digunakan dalam penelitian ini adalah Wireshark versi 1.2.6.
Untuk mengetahuinya, penulis menggunakan Twinkle versi 1.4.2,
Aplikasi Twinkle berbentuk seperti form dengan diisikan nama pihak yang
akan dihubungi. Penulis mencoba user2 yang sama-sama terhubung oleh
VoIP server Asterisk.
Untuk mengetahui transmisi data, penulis mempergunakan aplikasi
Wireshark. Aplikasi ini akan mengetahui semua paket yang melewati
protokol IP/UDP dan jika dikehendaki menangkap paket yang diinginkan
untuk seteliti lebih lanjut.
Gambar 4.6 Transmisi dari client-server
75
Gambar 4.7 Transmisi dari client-client
Dari dataflow di Wireshark, kita juga dapat melihat isi dari paket
SIP. Analisa ini dilakukan dengan meng-klik kanan salah satu paket SIP yang didapat dari hasil capture.
76 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.1.4:5062;rport;branch=z9hG4bKkeibwmzm Max-Forwards: 70 To:
Gambar 4.8 Paket SIP sebelum keadaan implementasi
77 4.4.3 Keadaan sesudah implementasi SRTP diterapkan.
Implementasi selanjutnya adalah merekam keadaan sesudah
penerapan SRTP. Untuk aplikasi Twinkle, terdapat pilihan yang sudah
disediakan untuk memilih protokol yang akan digunakan yaitu,
ZRTP/SRTP. ZRTP merupakan protokol yang bersamaan dengan protokol
SRTP menegosiasikan kunci untuk enkripsi, dengan menggunakan
pertukaran kunci Diffie-Hellman.
Gambar 4.9 Pilihan keamanan pada aplikasi Twinkle
Setelah pilihan ZRTP/SRTP dicentang, maka selanjutnya mencoba
kembali transmisi data dengan implementasi VoIP yang berjalan di kedua
pihak. Pemantauan jaringan menunjukkan bahwa terdapat protokol ZRTP
78 yang berjalan pada transmisi data. Hal ini dapat diartikan implementasi
SRTP telah dilaksanakan di komunikasi VoIP.
Gambar 4.10 Protokol SRTP/ZRTP pada client-server
79
Gambar 4.11 Protokol SRTP/ZRTP pada user 1
Gambar 4.12 Protokol SRTP/ZRTP pada user 2
80 Kemudian paket SIP dari hasil capture diatas dilihat dan dibandingkan dengan keadaan sebelum implementasi SRTP diterapkan.
Perbedaannya dapat dilihat pada line: a=crypto:1
AES_CM_128_HMAC_SHA1_80. Dari keterangan line ini dapat dilihat bahwa telah dilakukan kriptografi AES 128 dan HMAC SHA1 pada request
INVITE dari paket SIP.
INVITE sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3:2048;branch=z9hG4bK-wnmg0b9gk8nw;rport From: "user1"
v=0 o=root 1878679225 1878679225 IN IP4 172.17.3.101 s=call c=IN IP4 172.17.3.101 t=0 0 m=audio 64498 RTP/SAVP 0 8 9 3 18 4 101 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:LcvvS+vRCWoRlNMoQMUkieDdzxMbZp34Hb07ETwB a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=fmtp:18 annexb=no Gambar 4.13 Paket SIP setelah keadaan implementasi
81 Untuk hasil suara yang di-capture, penulis menggunakan aplikasi gratis SPEAR yang dapat diunduh di http://www.klingbeil/spear.com yang langsung dapat digunakan. Untuk hasil suara setelah implementasi dari
SRTP, hanya terdengar bunyi noice yang berubah-ubah sesuai dengan keras rendahnya percakapan.
Gambar 4.14 Capture suara sebelum implementasi
82
Gambar 4.15 Capture suara setelah implementasi
83 BAB V
PENUTUP
5.1 Kesimpulan
Berdasarkan uraian bab-bab sebelumnya, maka dapat diambil
kesimpulan dari penulisan skripsi ini sebagai berikut:
1. Komunikasi VoIP dapat dibangun dari sebuah VoIP server
(Asterisk) dan VoIP client (Twinkle). Skema jaringan VoIP yang
dilakukan penulis seperti yang ditunjukkan pada gambar 4.2.
2. Implementasi SRTP dapat berjalan dengan baik. Penerapan library
SRTP dilakukan pada server Asterisk dapat dilihat hasilnya pada
gambar 4.6. Pada aplikasi Twinkle, penerapan SRTP dapat dilihat
pada gambar 4.10.
3. Hasil pengujian keadaan sebelum implementasi SRTP , payload
dapat dicapture dengan aplikasi Wireshark . Hal ini menunjukkan
bahwa komunikasi VoIP dapat didengarkan oleh pihak lain
sehingga tidak terjamin konsep confidentiality dan integrity. Hasil
ini dapat dilihat pada gambar 4.7 pada client-server dan gambar 4.8
pada client-client.
4. Hasil pengujian keadaan sesudah implementasi SRTP, payload
telah terenkripsi sehingga terjamin confidentiality dan integrity.
Hasilnya dapat dilihat pada gambar 4.11 pada client-server dan
gambar 4.12 dan 4.13 untuk client-client.
72 5.2 Saran
Berdasarkan penelitian yang diperoleh, ada beberapa saran untuk
pengembangan sistem lebih lanjut, saran-saran tersebut yaitu:
1. Pengembangan keamanan selanjutnya tidak hanya pada paket data
saja, tetapi meluas sampai pada keamanan tingkat jaringan.
2. Setelah terdapat kriptografi simetris yang digunakan dalam
protokol SRTP ini (AES 128 bit), sebaiknya diikuti pula dengan
adanya penambahan kriptografi asimetris seperti RSA agar
kriptografi lebih banyak dan sulit untuk ditembus..
73 DAFTAR PUSTAKA
Ariyus, Dony. 2006. KRIPTOGRAFI Keamanan Data dan Komunikasi. Penerbit
Graha Ilmu.
Alexander, Andre. 2007. Securing VoIP. Penerbit Townson University.
Basuki, Mudji. 2007. Desain dan konfigurasi VoIP dan Data pada Jaringan Frame
Relay. http://www.routeronsale.com, 31 Mei 2009, pk: 21:00
Iskandarsyah, M. 2003. Dasar-dasar Jaringan VoIP. 10 hlm.
http://www.ilmukomputer.com/berseri/iskandar-voip/index.php, 6 Mei 2007, pk.
14:02 WIB.
Javvin. 2005. Network Protocols Handbook 2nd Edition. 319 hlm.
Kenneth E. Kendall., Jullie E. Kendall. 2003. Systems Analysis and Design. fifth
Edition. Dialihbahasakan oleh Thamir Abdul Hafed Al-Hamdany, B.Sc, M.Sc
dalam buku Analisa dan Perancangan Sistem Jilid 1. Penerbit : PT Prenhallindo
Jakarta.
Kurniawan, Yusuf. Ir. MT. 2004. KRIPTOGRAFI Keamanan Internet dan Jaringan
Komputer. Penerbit Informatika Bandung.
Lamle, Todd. 2005. CCNA: Cisco Certified Network Associate Study Guide. PT. Elex
Media Komputindo Jakarta.
Munir, Rinaldi. 2006. Kriptografi . Penerbit : Informatika Bandung.
86 Munir, Rinaldi. Bahan Kuliah Ke 1Kriptografi. 20 hlm.
http://www.informatika.org/~rinaldi/-Kriptografi/2006-
2007/bahankuliah2006.htm. 12 November 2007 pukul 11.30
Porter, Thomas. 2006. Practical VoIP Security.. Penerbit Syngress Publishing.
Rockland : 563 hlm.
Prakoso, Samuel. 2005. Jaringan Komputer Linux: Konsep Dasar, Instalasi, Aplikasi,
Keamanan dan Penerapan. Penerbit Andi, Yogyakarta: x+298 hlm.
Pressman, Roger.S. 1997. Rekayasa Perangkat Lunak: Pendekatan Praktisi (Buku
Satu). Terj. Dari Software Engineering: A Practioner’s Approach, oleh L.N
Harnaningrum. Penerbit Andi, Yogyakarta: xx + 648 hlm.
Purbo, Onno W. 2007. VoIP Cikal Bakal “Telkom Rakyat”. Penerbit Infokomputer,
Jakarta: xi + 268 hlm.
Rafiudin, Rahmat. 2006. Cisco Router: Konfigurasi Voice, Video dan Fax. Penerbit
Andi Yogyakarta.
Raharja, R. Anton. 2004. VoIP Fundamental. 36 hlm.
http://www.voiprakyat.or.id//?inc=files&file=materi-voip-fundamental.pdf,
3 Juni 2007, pk. 21:37 WIB.
RFC 3550, 2003. RTP: A Transport Protocol for Real-Time Applications. 104 hlm.
http://ietf.org/rfc/rfc3550.txt, 31 Agustus 2007, pk: 13:30
RFC 3711, 2005. SRTP: Secure Real time Transport Protocol. 106 hlm.
http://ietf.org/rfc/rfc/rfc3711.txt, 31 Mei 2009, pk 21:00
87 Sitepu, Herry. 2001. Aspek Keamanan Komunikasi Multimedia H.323 . 28 hlm. 8
Mei 2007. http://www.cs.columbia.edu/~hgs/papers/Schu9807_Comparison.pdf,
31 Agustus 2007, pukul 13:07
Stallings, William. 2001 . Komunikasi Data Dan Komputer: Dasar-dasar
Komunikasi Data. Terj. Dari Data and Computer Communications, 6th Edition,
oleh Thamir Abdul Hafedh Al-Hamdany. Penerbit Salemba Teknika,
Jakarta:xv+445 hlm.
Stallings, William. 200b. Komunikasi Data Dan Komputer: Jaringan Komputer. Terj
dari Data and Computer Communications, 6th Edition, oleh Thamir Abdul
Hafedh Al-Hamdany. Penerbit Salemba Teknika, Jakarta: xv+431 hlm.
Thermos, Peter dan Ari Takanen. 2007. Securing VoIP Networks: Threats,
Vulnerabilities, and Countermeasures. Penerbit Addison-Wesley, 359 hlm.
Wahana Komputer. 2003. Memahami Model Enkripsi dan Security Data. Penerbit :
Andi Yogyakarta.
Wahono, 2008. Aspek Keamanan dalam Paket Data Jaringan.
http://www.ilmukomputer.com/berseri/wahono-security/index.php. 6 Mei 2007,
pukul 14.02 WIB
Wijaya, Hendra. 2004. Cisco Router, Edisi Baru Untuk Mengambil Sertifikat
CCNA(640-801). Penerbit Elex Media Komputindo, Jakarta:xvi + 384 hlm.
88 Lampiran 1
RFC 3550 RTP: A Transport for Real Tme Protocol (RTP Packet)
This document defines RTP, consisting of two closely-linked parts:
• The real-time transport protocol (RTP), to carry data that hasreal-time properties.
• The RTP control protocol (RTCP), to monitor the quality of service and to convey information about the participants in an on-going session. The latter aspect of RTCP may be sufficient for "loosely controlled" sessions, i.e., where there is no explicit membership control and set-up, but it is not necessarily intended to support all of an application's control communication requirements. This functionality may be fully or partially subsumed by a separate session control protocol, which is beyond the scope of this document.
RTP represents a new style of protocol following the principles of application level framing and integrated layer processing proposed by Clark and Tennenhouse [10]. That is, RTP is intended to be malleable to provide the information required by a particular application and will often be integrated into the application processing rather than being implemented as a separate layer. RTP is a protocol framework that is deliberately not complete. This document specifies those functions expected to be common across all the applications for which RTP would be appropriate. Unlike conventional protocols in which additional functions might be accommodated by making the protocol more general or by adding an option mechanism that would requireparsing, RTP is intended to be tailored through modifications and/or additions to the headers as needed. Examples are given in Sections 5.3 and 6.4.3.
Therefore, in addition to this document, a complete specification of RTP for a particular application will require one or more companion documents (see Section 13):
• A profile specification document, which defines a set of payload type codes and their mapping to payload formats (e.g., media encodings). A profile may also define extensions or modifications to RTP that are specific to a particular class of applications. Typically an application will operate under only one profile. A profile for audio and video data may be found in the companion RFC 3551 [1].
• payload format specification documents, which define how a particular payload, such as an audio or video encoding, is to be carried in RTP.
A discussion of real-time services and algorithms for their implementation as well as background discussion on some of the RTP design decisions can be found in [11].
2.1 Simple Multicast Audio Conference
A working group of the IETF meets to discuss the latest protocol document, using the IP multicast services of the Internet for voice communications. Through some allocation mechanism the working group chair obtains a multicast group address and pair of ports. One port is used for audio data, and the other is used for control (RTCP) packets. This address and port information is distributed to the intended participants. If privacy is desired, the data and control packets may be encrypted as specified in Section 9.1, in which case an encryption key must also be generated and distributed. The exact details of these allocation and distribution mechanisms are beyond the scope of RTP.
The audio conferencing application used by each conference participant sends audio data in small chunks of, say, 20 ms duration. Each chunk of audio data is preceded by an RTP header; RTP header and data are in turn contained in a UDP packet. The RTP header indicates what type of audio encoding (such as PCM, ADPCM or LPC) is contained in each packet so that senders can change the encoding during a conference, for example, to accommodate a new participant that is connected through a low-bandwidth link or react to indications of network congestion.
The Internet, like other packet networks, occasionally loses and reorders packets and delays them by variable amounts of time. To cope with these impairments, the RTP header contains timing information and a sequence number that allow the receivers to reconstruct the timing produced by the source, so that in this example, chunks of audio are contiguously played out the speaker every 20 ms. This timing reconstruction is performed separately for each source of RTP packets in the conference. The sequence number can also be used by the receiver to estimate how many packets are being lost.
Since members of the working group join and leave during the conference, it is useful to know who is participating at any moment and how well they are receiving the audio data. For that purpose, each instance of the audio application in the conference periodically multicasts a reception report plus the name of its user on the RTCP (control) port. The reception report indicates how well the current speaker is being received and may be used to control adaptive encodings. In addition to the user name, other identifying information may also be included subject to control bandwidth limits. A site sends the RTCP BYE packet (Section 6.6) when it leaves the conference.
2.2 Audio and Video Conference
If both audio and video media are used in a conference, they are transmitted as separate RTP sessions. That is, separate RTP and RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. There is no direct coupling at the RTP level between the audio and video sessions, except that a user participating in both sessions should use the same distinguished (canonical) name in the RTCP packets for both so that the sessions can be associated.
One motivation for this separation is to allow some participants in the conference to receive only one medium if they choose. Further explanation is given in Section 5.2. Despite the separation, synchronized playback of a source's audio and video can be achieved using timing information carried in the RTCP packets for both sessions.
3. Definitions
RTP payload: The data transported by RTP in a packet, for example audio samples or compressed video data. The payload format and interpretation are beyond the scope of this document.
RTP packet: A data packet consisting of the fixed RTP header, a possibly empty list of contributing sources (see below), and the payload data. Some underlying protocols may require an encapsulation of the RTP packet to be defined. Typically one packet of the underlying protocol contains a single RTP packet, but several RTP packets MAY be contained if permitted by the encapsulation method (see Section 11).
RTCP packet: A control packet consisting of a fixed header part similar to that of RTP data packets, followed by structured elements that vary depending upon the RTCP packet type. The formats are defined in Section 6. Typically, multiple RTCP packets are sent together as a compound RTCP packet in a single packet of the underlying protocol; this is enabled by the length field in the fixed header of each RTCP packet.
Port: The "abstraction that transport protocols use to distinguish among multiple destinations within a given host computer. TCP/IP protocols identify ports using small positive integers." [12] The transport selectors (TSEL) used by the OSI transport layer are equivalent to ports. RTP depends upon the lower- layer protocol to provide some mechanism such as ports to multiplex the RTP and RTCP packets of a session.
Transport address: The combination of a network address and port that identifies a transport-level endpoint, for example an IP address and a UDP port. Packets are transmitted from a source transport address to a destination transport address.
RTP media type: An RTP media type is the collection of payload types which can be carried within a single RTP session. The RTP Profile assigns RTP media types to RTP payload types.
Multimedia session: A set of concurrent RTP sessions among a common group of participants. For example, a videoconference (which is a multimedia session) may contain an audio RTP session and a video RTP session.
RTP session: An association among a set of participants communicating with RTP. A participant may be involved in multiple RTP sessions at the same time. In a multimedia session, each medium is typically carried in a separate RTP session with its own RTCP packets unless the the encoding itself multiplexes multiple media into a single data stream. A participant distinguishes multiple RTP sessions by reception of different sessions using different pairs of destination transport addresses, where a pair of transport addresses comprises one network address plus a pair of ports for RTP and RTCP. All participants in an RTP session may share a common destination transport address pair, as in the case of IP multicast, or the pairs may be different for each participant, as in the case of individual unicast network addresses and port pairs. In the unicast case, a participant may receive from all other participants in the session using the same pair of ports, or may use a distinct pair of ports for each.
The distinguishing feature of an RTP session is that each maintains a full, separate space of SSRC identifiers (defined next). The set of participants included in one RTP session consists of those that can receive an SSRC identifier transmitted by any one of the participants either in RTP as the SSRC or a CSRC (also defined below) or in RTCP. For example, consider a three- party conference implemented using unicast UDP with each participant receiving from the other two on separate port pairs. If each participant sends RTCP feedback about data received from one other participant only back to that participant, then the conference is composed of three separate point-to-point RTP sessions. If each participant provides RTCP feedback about its reception of one other participant to both of the other participants, then the conference is composed of one multi-party RTP session. The latter case simulates the behavior that would occur with IP multicast communication among the three participants.
The RTP framework allows the variations defined here, but a particular control protocol or application design will usually impose constraints on these variations.
Synchronization source (SSRC): The source of a stream of RTP packets, identified by a 32-bit numeric SSRC identifier carried in the RTP header so as not to be dependent upon the network address. All packets from a synchronization source form part of the same timing and sequence number space, so a receiver groups packets by synchronization source for playback. Examples of synchronization sources include the sender of a stream of packets derived from a signal source such as a microphone or a camera, or an RTP mixer (see below). A synchronization source may change its data format, e.g., audio encoding, over time. The SSRC identifier is a randomly chosen value meant to be globally unique within a particular RTP session (see Section 8). A participant need not use the same SSRC identifier for all the RTP sessions in a multimedia session; the binding of the SSRC identifiers is provided through RTCP (see Section 6.5.1). If a participant generates multiple streams in one RTP session, for example from separate video cameras, each MUST be identified as a different SSRC.
Contributing source (CSRC): A source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer (see below). The mixer inserts a list of the SSRC identifiers of the sources that contributed to the generation of a particular packet into the RTP header of that packet. This list is called the CSRC list. An example application is audio conferencing where a mixer indicates all the talkers whose speech was combined to produce the outgoing packet, allowing the receiver to indicate the current talker, even though all the audio packets contain the same SSRC identifier (that of the mixer).
End system: An application that generates the content to be sent in RTP packets and/or consumes the content of received RTP packets. An end system can act as one or more synchronization sources in a particular RTP session, but typically only one.
Mixer: An intermediate system that receives RTP packets from one or more sources, possibly changes the data format, combines the packets in some manner and then forwards a new RTP packet. Since the timing among multiple input sources will not generally be synchronized, the mixer will make timing adjustments among the streams and generate its own timing for the combined stream. Thus, all data packets originating from a mixer will be identified as having the mixer as their synchronization source.
Translator: An intermediate system that forwards RTP packetswith their synchronization source identifier intact. Examples of translators include devices that convert encodings without mixing, replicators from multicast to unicast, and application-level filters in firewalls.
Monitor: An application that receives RTCP packets sent by participants in an RTP session, in particular the reception reports, and estimates the current quality of service for distribution monitoring, fault diagnosis and long-term statistics. The monitor function is likely to be built into the application(s) participating in the session, but may also be a separate application that does not otherwise participate and does not send or receive the RTP data packets (since they are on a separate port). These are called third- party monitors. It is also acceptable for a third-party monitor to receive the RTP data packets but not send RTCP packets or otherwise be counted in the session.
Non-RTP means: Protocols and mechanisms that may be needed in addition to RTP to provide a usable service. In particular, for multimedia conferences, a control protocol may distribute multicast addresses and keys for encryption, negotiate the encryption algorithm to be used, and define dynamic mappings between RTP payload type values and the payload formats they represent for formats that do not have a predefined payload type value. Examples of such protocols include the Session Initiation Protocol (SIP) (RFC 3261 [13]), ITU Recommendation H.323 [14] and applications using SDP (RFC 2327 [15]), such as RTSP (RFC 2326 [16]). For simple applications, electronic mail or a conference database may also be used. The specification of such protocols and mechanisms is outside the scope of this document.
5. RTP Data Transfer Protocol
5.1 RTP Fixed Header Fields
The RTP header has the following format:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first twelve octets are present in every RTP packet, while thelist of CSRC identifiers is present only when inserted by a mixer.he fields have the following meaning:
version (V): 2 bits This field identifies the version of RTP. The version defined by this specification is two (2). (The value 1 is used by the first draft version of RTP and the value 0 is used by the protocol initially implemented in the "vat" audio tool.)
padding (P): 1 bit If the padding bit is set, the packet contains one or more additional padding octets at the end which are not part of the payload. The last octet of the padding contains a count of how many padding octets should be ignored, including itself. Padding may be needed by some encryption algorithms with fixed block sizes or for carrying several RTP packets in a lower-layer protocol data unit.
extension (X): 1 bit If the extension bit is set, the fixed header MUST be followed by exactly one header extension, with a format defined in Section 5.3.1.
CSRC count (CC): 4 bits The CSRC count contains the number of CSRC identifiers that follow the fixed header.
marker (M): 1 bit The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. A profile MAY define additional marker bits or specify that there is no marker bit by changing the number of bits in the payload type field (see Section 5.3).
payload type (PT): 7 bits This field identifies the format of the RTP payload and determines its interpretation by the application. A profile MAY specify a default static mapping of payload type codes to payload formats. Additional payload type codes MAY be defined dynamically through non-RTP means (see Section 3). A set of default mappings for audio and video is specified in the companion RFC 3551 [1]. An RTP source MAY change the payload type during a session, but this field SHOULD NOT be used for multiplexing separate media streams (see Section 5.2).
sequence number: 16 bits The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number SHOULD be random (unpredictable) to make known-plaintext attacks on encryption more difficult, even if the source itself does not encrypt according to the method in Section 9.1, because the packets may flow through a translator that does. Techniques for choosing unpredictable numbers are discussed in [17].
timestamp: 32 bits The timestamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant MUST be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations (see Section 6.4.1). The resolution of the clock MUST be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not sufficient). The clock frequency is dependent on the format of data carried as payload and is specified statically in the profile or payload format specification that defines the format, or MAY be specified dynamically for payload formats defined through non-RTP means. If RTP packets are generated periodically, the nominal sampling instant as determined from the sampling clock is to be used, not a reading of the system clock. As an example, for fixed-rate audio the timestamp clock would likely increment by one for each sampling period. If an audio application reads blocks covering 160 sampling periods from the input device, the timestamp would be increased by 160 for each such block, regardless of whether the block is transmitted in a packet or dropped as silent.
The initial value of the timestamp SHOULD be random, as for the sequence number. Several consecutive RTP packets will have equal timestamps if they are (logically) generated at once, e.g., belong to the same video frame. Consecutive RTP packets MAY contain timestamps that are not monotonic if the data is not transmitted in the order it was sampled, as in the case of MPEG interpolated video frames. (The sequence numbers of the packets as transmitted will still be monotonic.)
RTP timestamps from different media streams may advance at different rates and usually have independent, random offsets. Therefore, although these timestamps are sufficient to reconstruct the timing of a single stream, directly comparing RTP timestamps from different media is not effective for synchronization. Instead, for each medium the RTP timestamp is related to the sampling instant by pairing it with a timestamp from a reference clock (wallclock) that represents the time when the data corresponding to the RTP timestamp was sampled. The reference clock is shared by all media to be synchronized. The timestamp pairs are not transmitted in every data packet, but at a lower rate in RTCP SR packets as described in Section 6.4.
The sampling instant is chosen as the point of reference for the RTP timestamp because it is known to the transmitting endpoint and has a common definition for all media, independent of encoding delays or other processing. The purpose is to allow synchronized presentation of all media sampled at the same time. Applications transmitting stored data rather than data sampled in real time typically use a virtual presentation timeline derived from wallclock time to determine when the next frame or other unit of each medium in the stored data should be presented. In this case, the RTP timestamp would reflect the presentation time for each unit. That is, the RTP timestamp for each unit would be related to the wallclock time at which the unit becomes current on the virtual presentation timeline. Actual presentation occurs some time later as determined by the receiver.
An example describing live audio narration of prerecorded video illustrates the significance of choosing the sampling instant as the reference point. In this scenario, the video would be presented locally for the narrator to view and would be simultaneously transmitted using RTP. The "sampling instant" of a video frame transmitted in RTP would be established by referencing its timestamp to the wallclock time when that video frame was presented to the narrator. The sampling instant for the audio RTP packets containing the narrator's speech would be established by referencing the same wallclock time when the audio was sampled. The audio and video may even be transmitted by different hosts if the reference clocks on the two hosts are synchronized by some means such as NTP. A receiver can then synchronize presentation of the audio and video packets by relating their RTP timestamps using the timestamp pairs in RTCP SR packets.
SSRC: 32 bits The SSRC field identifies the synchronization source. This identifier SHOULD be chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier. An example algorithm for generating a random identifier is presented in Appendix A.6. Although the probability of multiple sources choosing the same identifier is low, all RTP implementations must be prepared to detect and resolve collisions. Section 8 describes the probability of collision along with a mechanism for resolving collisions and detecting RTP-level forwarding loops based on the uniqueness of the SSRC identifier. If a source changes its source transport address, it must also choose a new SSRC identifier to avoid being interpreted as a looped source (see Section 8.2).
CSRC list: 0 to 15 items, 32 bits each The CSRC list identifies the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 can be identified. CSRC identifiers are inserted by mixers (see Section 7.1), using the SSRC identifiers of contributing sources. For example, for audio packets the SSRC identifiers of all sources that were mixed together to create a packet are listed, allowing correct talker indication at the receiver.
5.3.1 RTP Header Extension
An extension mechanism is provided to allow individualplementations to experiment with new payload- format-independentunctions that require additional information to be carried in theTP data packet header. This mechanism is designed so that the header extension may be ignored by other interoperatingimplementations that have not been extended.
Note that this header extension is intended only for limited use. Most potential uses of this mechanism would be better done anotherway, using the methods described in the previous section. For example, a profile-specific extension to the fixed header is less expensive to process because it is not conditional nor in a variable location. Additional information required for a particular payload format SHOULD NOT use this header extension, but SHOULD be carried in the payload section of the packet.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | defined by profile | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header extension | | .... |
If the X bit in the RTP header is one, a variable-length header extension MUST be appended to the RTP header, following the CSRC list if present. The header extension contains a 16-bit length field that counts the number of 32-bit words in the extension, excluding the four-octet extension header (therefore zero is a valid length). Only a single extension can be appended to the RTP data header. To allow multiple interoperating implementations to each experiment independently with different header extensions, or to allow a particular implementation to experiment with more than one type of header extension, the first 16 bits of the header extension are left open for distinguishing identifiers or parameters. The format of these 16 bits is to be defined by the profile specification under which the implementations are operating. This RTP specification does not define any header extensions itself.
Lampiran 2 SRTP: The Secure Real time Transport Protocol (RFC 3711)
1. Introduction
This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, RTCP (the Real-time Transport Control Protocol) [RFC3350].
SRTP provides a framework for encryption and message authentication of RTP and RTCP streams (Section 3). SRTP defines a set of default cryptographic transforms (Sections 4 and 5), and it allows new transforms to be introduced in the future (Section 6). With appropriate key management (Sections 7 and 8), SRTP is secure (Sections 9) for unicast and multicast RTP applications (Section 11).
SRTP can achieve high throughput and low packet expansion. SRTP proves to be a suitable protection for heterogeneous environments (mix of wired and wireless networks). To get such features, default transforms are described, based on an additive stream cipher for encryption, a keyed-hash based function for message authentication, and an "implicit" index for sequencing/synchronization based on the RTP sequence number for SRTP and an index number for Secure RTCP (SRTCP).
2. Goals and Features
The security goals for SRTP are to ensure:
* the confidentiality of the RTP and RTCP payloads, and
* the integrity of the entire RTP and RTCP packets, together with protection against replayed packets.
These security services are optional and independent from each other, except that SRTCP integrity protection is mandatory (malicious or erroneous alteration of RTCP messages could otherwise disrupt the processing of the RTP stream).
Other, functional, goals for the protocol are:
* a framework that permits upgrading with new cryptographic transforms,
* low bandwidth cost, i.e., a framework preserving RTP header compression efficiency,
and, asserted by the pre-defined transforms:
* a low computational cost,
* a small footprint (i.e., small code size and data memory for keying information and replay lists),
* limited packet expansion to support the bandwidth economy goal,
* independence from the underlying transport, network, and physical layers used by RTP, in particular high tolerance to packet loss and re-ordering.
These properties ensure that SRTP is a suitable protection scheme for RTP/RTCP in both wired and wireless scenarios.
3.1. Secure RTP
The format of an SRTP packet is illustrated in Figure 1.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +<+ |V=2|P|X| CC |M| PT | sequence number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | timestamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | synchronization source (SSRC) identifier | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | contributing source (CSRC) identifiers | | | .... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | RTP extension (OPTIONAL) | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | payload ... | | | | +------+ | | | | RTP padding | RTP pad count | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +<+ | ~ SRTP MKI (OPTIONAL) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : authentication tag (RECOMMENDED) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +- Encrypted Portion* Authenticated Portion --- +
Figure 1. The format of an SRTP packet. *Encrypted Portion is the same size as the plaintext for the Section 4 pre-defined transforms.
The "Encrypted Portion" of an SRTP packet consists of the encryption of the RTP payload (including RTP padding when present) of the equivalent RTP packet. The Encrypted Portion MAY be the exact size of the plaintext or MAY be larger. Figure 1 shows the RTP payload including any possible padding for RTP [RFC3550].
None of the pre-defined encryption transforms uses any padding; for these, the RTP and SRTP payload sizes match exactly. New transforms added to SRTP (following Section 6) may require padding, and may hence produce larger payloads. RTP provides its own padding format (as seen in Fig. 1), which due to the padding indicator in the RTP header has merits in terms of compactness relative to paddings using prefix-free codes. This RTP padding SHALL be the default method for transforms requiring padding. Transforms MAY specify other padding methods, and MUST then specify the amount, format, and processing of their padding. It is important to note that encryption transforms that use padding are vulnerable to subtle attacks, especially when message authentication is not used [V02]. Each specification for a new encryption transform needs to carefully consider and describe the security implications of the padding that it uses. Message authentication codes define their own padding, so this default does not apply to authentication transforms.
The OPTIONAL MKI and the RECOMMENDED authentication tag are the only fields defined by SRTP that are not in RTP. Only 8-bit alignment is assumed.
MKI (Master Key Identifier): configurable length, OPTIONAL. The MKI is defined, signaled, and used by key management. MKI identifies the master key from which the session key(s) were derived that authenticate and/or encrypt the particular packet. Note that the MKI SHALL NOT identify the SRTP cryptographic context, which is identified according to Section 3.2.3. The MKI MAY be used by key management for the purposes of re-keying, identifying a particular master key within the cryptographic context (Section 3.2.1).
Authentication tag: configurable length, RECOMMENDED. The authentication tag is used to carry messag authentication data. The Authenticated Portion of an SRTP packet consists of the RTP header followed by the Encrypted Portion of the SRTP packet. Thus, if both encryption and authentication are applied, encryption SHALL be applied before authentication on the sender side and conversely the receiver side. The authentication tag provides authentication of the RTP header and payload, and it indirectly provides replay protection by authenticating the sequence number. Note that the MKI is not integrity protected as this does not provide any extra protection.
3.2. SRTP Cryptographic Contexts
Each SRTP stream requires the sender and receiver to maintain cryptographic state information. This information is called the "cryptographic context".
SRTP uses two types of keys: session keys and master keys. By a "session key", we mean a key which is used directly in a cryptographic transform (e.g., encryption or message authentication), and by a "master key", we mean a random bit string (given by the key management protocol) from which session keys are derived in a
cryptographically secure way. The master key(s) and other parameters in the cryptographic context are provided by key management mechanisms external to SRTP, see Section 8.
3.2.1. Transform-independent parameters
Transform-independent parameters are present in the cryptographic context independently of the particular encryption or authentication transforms that are used. The transform-independent parameters of the cryptographic context for SRTP consist of:
* a 32-bit unsigned rollover counter (ROC), which records how many times the 16-bit RTP sequence number has been reset to zero after passing through 65,535. Unlike the sequence number (SEQ), which SRTP extracts from the RTP packet header, the ROC is maintained by SRTP as described in Section 3.3.1.
We define the index of the SRTP packet corresponding to a given ROC and RTP sequence number to be the 48-bit quantity
i = 2^16 * ROC + SEQ.
* for the receiver only, a 16-bit sequence number s_l, which can be thought of as the highest received RTP sequence number (see Section 3.3.1 for its handling), which SHOULD be authenticated since message authentication is RECOMMENDED,
* an identifier for the encryption algorithm, i.e., the cipher and its mode of operation,
* an identifier for the message authentication algorithm,
* a replay list, maintained by the receiver only (when authentication and replay protection are provided), containing indices of recently received and authenticated SRTP packets,
* an MKI indicator (0/1) as to whether an MKI is present in SRTP and SRTCP packets,
* if the MKI indicator is set to one, the length (in octets) of the MKI field, and (for the sender) the actual value of the currently active MKI (the value of the MKI indicator and length MUST be kept fixed for the lifetime of the context),
* the master key(s), which MUST be random and kept secret,
* for each master key, there is a counter of the number of SRTP packets that have been processed (sent) with that master key (essential for security, see Sections 3.3.1 and 9),
* non-negative integers n_e, and n_a, determining the length of the session keys for encryption, and message authentication.
In addition, for each master key, an SRTP stream MAY use the following associated values:
* a master salt, to be used in the key derivation of session keys. This value, when used, MUST be random, but MAY be public. Use of master salt is strongly RECOMMENDED, see Section 9.2. A "NULL" salt is treated as 00...0.
* an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", where an unspecified value is treated as zero. The constraint to be a power of 2 simplifies the session-key derivation implementation, see Section 4.3.
* an MKI value,
*
SRTCP SHALL by default share the crypto context with SRTP, except:
* no rollover counter and s_l-value need to be maintained as the RTCP index is explicitly carried in each SRTCP packet,
* a separate replay list is maintained (when replay protection is provided),
* SRTCP maintains a separate counter for its master key (even if the master key is the same as that for SRTP, see below), as a means to maintain a count of the number of SRTCP packets that have been processed with that key.
Note in particular that the master key(s) MAY be shared between SRTP and the corresponding SRTCP, if the pre-defined transforms including the key derivation) are used but the session key(s) MUST NOT be so shared.
In addition, there can be cases (see Sections 8 and 9.1) where several SRTP streams within a given RTP session, identified by their synchronization source (SSRCs, which is part of the RTP header), share most of the crypto context parameters (including possibly master and session keys). In such cases, just as in the normal SRTP/SRTCP parameter sharing above, separate replay lists and packet counters for each stream (SSRC) MUST still be maintained. Also, separate SRTP indices MUST then be maintained.
3.3. SRTP Packet Processing
The following applies to SRTP. SRTCP is described in Section 3.4.
Assuming initialization of the cryptographic context(s) has taken place via key management, the sender SHALL do the following to construct an SRTP packet:
1. Determine which cryptographic context to use as described in Section 3.2.3.
2. Determine the index of the SRTP packet using the rollover counter, the highest sequence number in the cryptographic context, and the sequence number in the RTP packet, as described in Section 3.3.1.
3. Determine the master key and master salt. This is done using the index determined in the previous step or the current MKI in the cryptographic context, according to Section 8.1.
4. Determine the session keys and session salt (if they are used by the transform) as described in Section 4.3, using master key, master salt, key_derivation_rate, and session key-lengths in the cryptographic context with the index, determined in Steps 2 and 3.
5. Encrypt the RTP payload to produce the Encrypted Portion of the packet (see Section 4.1, for the defined ciphers). This step uses the encryption algorithm indicated in the cryptographic context, the session encryption key and the session salt (if used) found in Step 4 together with the index found in Step 2.
6. If the MKI indicator is set to one, append the MKI to the packet.
7. For message authentication, compute the authentication tag for the Authenticated Portion of the packet, as described in Section 4.2. This step uses the current rollover counter, the authentication algorithm indicated in the cryptographic context, and the session authentication key found in Step 4. Append the authentication tag to the packet.
8. If necessary, update the ROC as in Section 3.3.1, using the packet index determined in Step 2.
To authenticate and decrypt an SRTP packet, the receiver SHALL do the following:
1. Determine which cryptographic context to use as described in Section 3.2.3.
2. Run the algorithm in Section 3.3.1 to get the index of the SRTP packet. The algorithm uses the rollover counter and highest sequence number in the cryptographic context with the sequence number in the SRTP packet, as described in Section 3.3.1.
3. Determine the master key and master salt. If the MKI indicator the context is set to one, use the MKI in the SRTP packet, otherwise use the index from the previous step, according to Section 8.1.
4. Determine the session keys, and session salt (if used by the transform) as described in Section 4.3, using master key, master salt, key_derivation_rate and session key-lengths in the cryptographic context with the index, determined in Steps 2 and 3.
5. For message authentication and replay protection, first check if the packet has been replayed (Section 3.3.2), using the Replay List and the index as determined in Step 2. If the packet is judged to be replayed, then the packet MUST be discarded, and the event SHOULD be logged.
Next, perform verification of the authentication tag, using the rollover counter from Step 2, the authentication algorithm indicated in the cryptographic context, and the session authentication key from Step 4. If the result is "AUTHENTICATION FAILURE" (see Section 4.2), the packet MUST be discarded from further processing and the event SHOULD be logged.
6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for the defined ciphers), using the decryption algorithm indicated in the cryptographic context, the session encryption key and salt found in Step 4 with the index from Step 2.
7. Update the rollover counter and highest sequence number, s_l, in the cryptographic context as in Section 3.3.1, using the packet index estimated in Step 2. If replay protection is provided, also update the Replay List as described in Section 3.3.2.
8. When present, remove the MKI and authentication tag fields from the packet.
Lampiran 3 Asterisk Command
General commands
• !
Server management
• restart gracefully: Restart Asterisk gracefully, i.e. stop receiving new calls and restart at empty call volume • restart now: Restart Asterisk immediately • restart when convenient: Restart Asterisk at empty call volume • reload: Reload configuration • stop gracefully: Gracefully shut down Asterisk, i.e. stop receiving new calls and shut down at empty call volume • stop now: Shut down Asterisk imediately • stop when convenient: Shut down Asterisk at empty call volume • Asterisk cli dialplan reload: Reload extensions and only extensions (formerly extensions reload) • unload: Unload a dynamic module by name • show modules: List modules and info about them • show uptime: Show uptime information • show version: Display Asterisk version info
AGI commands
• show agi: Show AGI commands or specific help • dump agihtml: Dumps a list of agi command in html format
Database handling commands
• database del: Removes database key/value • database deltree: Removes database keytree/values • database get: Gets database value • database put: Adds/updates database value • database show: Shows database contents • database showkey: Shows database contents: An alternative to showing keys by family with database show, this command shows all the families with a particular key IAX Channel commands
• iax2 debug: Enable IAX debugging • iax2 no debug: Disable IAX debugging • iax2 set jitter: Sets IAX jitter buffer • iax2 show cache: Display IAX cached dialplan • iax2 show channels: Show active IAX channels • iax2 show netstats: Show network and jitter buffer statistics for active IAX calls • iax2 show peers: Show defined IAX peers • iax2 show registry: Show IAX registration status • iax2 show stats: Display IAX statistics • iax2 show users: Show defined IAX users • iax2 trunk debug: Request IAX trunk debug
• iax debug: Enable IAX debugging • iax no debug: Disable IAX debugging • iax set jitter: Sets IAX jitter buffer • iax show cache: Display IAX cached dialplan • iax show channels: Show active IAX channels • iax show peers: Show defined IAX peers • iax show registry: Show IAX registration status • iax show stats: Display IAX statistics • iax show users: Show defined IAX users • init keys: Initialize RSA key passcodes • show keys: Displays RSA key information
H323 channel commands
• h.323 debug: Enable chan_h323 debug • h.323 gk cycle: Manually re-register with the Gatekeper • h.323 hangup: Manually try to hang up a call • h.323 no debug: Disable chan_h323 debug • h.323 no trace: Disable H.323 Stack Tracing • h.323 show codecs: Show enabled codecs • h.323 show tokens: Manually try to hang up a call • h.323 trace: Enable H.323 Stack Tracing
SIP channel commands
• Debugging o Enable sip debug sip set debug on (valid on 1.6.2.7) o Disable sip no debug sip set debug off (valid on 1.6.2.7) • sip reload: Reload sip.conf (added after 0.7.1 on 2004-01-23) • sip show channels: Show active SIP channels • sip show channel: Show detailed SIP channel info • sip show inuse: List all inuse/limit • sip show peers: Show defined SIP peers (clients that register to your Asterisk server), see details here • sip show registry: Show SIP registration status (when Asterisk registers as a client to a SIP Proxy) • sip show subscriptions: Lists all sip presence (busy lamp indication) subscriptions • sip show users: Show defined SIP users
Zap channel commands
• zap destroy channel: Destroy a channel • zap show channels: Show active zapata channels • zap show channel: Show information on a channel • zap show status: lists all the Zaptel spans. A span will apear here whether or not its channels are configured with chan_zap. • zap show cadences: Show the configured ring cadences (available e.g with Zap/1r2). • zap set swgain(<= 1.6): set the (software) gain for a hannel. Temporary equivalents of rxgain and txgain in zapata.conf. • zap set hwgain(<=1.6): set the hardware gain for channels that support it. • zap set dnd(<=1.6) set a channel's do-not-disturb mode on or off.
The following commands are available if the channel is built with support for libpri:
• pri debug span: Enables PRI debugging on a span • pri intense debug span: Enables REALLY INTENSE PRI debugging • pri no debug span: Disables PRI debugging on a span • pri show spans: List spans and their status. • pri show span: Information about a span. • pri show debug: show where debug is enabled.
Console channel commands
• dial : Dials the given extension, if specified, from the console. Can be used to initiate a call, or to dial digits during an existing call. • Asterisk CLI answer: Answer a call if one is currently ringing on the console. • Asterisk CLI hangup: Hangup the call if there is currently one on the console.
Asterisk channel MGCP commands
• mgcp audit endpoint: Audit specified MGCP endpoint • mgcp debug: Enable MGCP debugging • mgcp no debug: Disable MGCP debugging • mgcp show endpoints: Show defined MGCP endpoints
skinny channel commands
• skinny debug: Enable Skinny debugging • skinny no debug: Disable Skinny debugging • skinny show lines: Show defined Skinny lines per device
Asterisk channel CAPI commands
• capi debug: Enable CAPI debugging • capi no debug: Disable CAPI debugging • capi info: Show CAPI info
Sirrix ISDN channel commands
• srx reload: Reload channel driver configuration; active calls are not being terminated! • srx show ccmsgs: Disable / enable output of incoming callcontrol messages. • srx show chans: Show info about B-Channels • srx show globals: Show info about global settings • srx show groups: Show info about configured groups • srx show layers: Show info about ISDN stack (Layer 1, 2, 3) • srx show sxpvts: Show private info about active channels • srx show timers: Show info about running timers