Functional Requirements Algoritma Proses Pembangkitan Kunci Algoritma Penentuan Bilangan p dan q Prima

Requirements yang ada akan dibagi menjadi 2 dua bagian. Bagian pertama adalah Functional Requirement yaitu aktivitas dan service yang harus disediakan oleh sistem yang akan dikembangkan. Bagian kedua adalah Nonfunctional Requirement yaitu fitur-fitur lain yang diperlukan oleh sistem agar sistem dapat lebih memuaskan.

a. Functional Requirements

Sistem yang dikembangkan harus mempunyai functional requirements sebagai berikut: 1. Aplikasi yang ada harus dapat mengirim sms ke handphone penerima. a. Pada saat pengiriman data sms, pengirim harus memasukan password dari sms tersebut. b. Aplikasi dapat melakukan enkripsi data SMS. 2. Handphone penerima ketika menerima pesan yang masuk dari HP pengirim data atau pesan yang ada masih di enkripsi, ketika HP penerima memasukan password proses deskripsi dilakukan. 3. Sistem memiliki tingkat keamanan yang tinggi dalam pemprosesan pesan. 4. Algoritma yang digunakan untuk enkripsi dan deskripsi adalah algoritma RSA. 5. Adanya fasilitas inbox dan outbox yang digunakan untuk menyimpan dan melihat data sms yang masuk dan keluar. 6. Adanya fasilitas petunjuk penggunaan teknis atau bantuan pada aplikasi, sehingga aplikasi mudah digunakan.

b. Nonfunctional Requirements

Nonfunctional Requirements dari sistem yang dikembangkan akan dijelaskan dalam bentuk tabel berikut: Tabel 4.3 Nonfunctional Requirement Jenis Kebutuhan Penjelasan 1. Model Tampilan Performance a Tampilan interface yang menarik dan lebih user friendly sehingga lebih mudah dimengerti dan digunakan oleh user. 2. Model Penyimpanan Data Information a Model penyimpanan data yang digunakan bukanlah suatu tools database, tetapi menggunakan tools dari J2ME yang bernama RMS, RMS merupakan suatu mekanisme yang digunakan oleh MIDP untuk menyimpan data, pada dasarnya RMS menyimpan kumpulan kumpulan record pada memori persistence. Dengan digunakannya RMS, sehingga aplikasi yang dijalankan tidak perlu mengakses dari tools database lain, sehingga tidak memberatkan aplikasi yang dijalankan. 3. Model Pengontrolan Sistem Control a Meningkatkan keamanan terhadap pelaksanaan proses penyimpanan data. b Membatasi akses penggunaan terhadap aplikasi dengan cara menerapkan input password pada HP pengirim dan penerima . c Mencegah kebocoran pesan kepada pihak yang tidak berwenang. 4. Model Efisiensi Sistem Eficiency a Menggunakan sistem penyimpanan data yang terpadu untuk memudahkan proses cross-checking pesan antara pengirim dan penerima. b Mengefisienkan waktu untuk pelaksanaan proses validasi pembacaan pesan

4.2.1.3 Analisis Keputusan Decision Analysis

Dari tahapan analisis sebelumnya telah diketahui permasalahan dari sistem berjalan dan persyaratan dan kebutuhan sistem yang diinginkan, maka fase selanjutnya adalah analisis keputusan yaitu menentukan komponen-komponen dari sistem usulan yang akan dirancang, dibangun dan diimplementasikan. Berikut merupakan komponen-komponen yang dibutuhkan: 1. Data SMS masuk Data sms masuk tersimpan didalam inbox pada bagian ini user dapat membalas sms, mengedit sms dan menghapus sms yang masuk. 2. Data SMS keluar Pada data sms keluar fitur yang disajikan sama dengan data sms masuk, pada bagian ini dilengkapi fasilitas membalas sms, mengedit sms dan menghapus sms yang masuk. 3. Enkripsi dan Dekripsi data Enkripsi data dilakukan ketika pesan akan disampaikan ke HP penerima. Dekripsi data dilakukan ketika pesan diterima dari HP pengirim. Enkripsi dan dekripsi data menggunakan algoritma RSA. Algoritma RSA adalah adalah sebuah algoritma pada enkripsi public key. RSA merupakan salah satu algoritma yang paling maju dalam bidang kriptografi public key. RSA masih digunakan secara luas dalam protokol electronic commerce, dan dipercaya dalam mengamankan dengan menggunakan kunci yang cukup panjang. 4. Bantuan Bantuan adalah petunjuk teknis penggunaan aplikasi yang bisa dibaca oleh user yang menggunakan aplikasi. Berikut ini adalah alur kerja sistem yang diusulkan : Gambar 4.1. Alur kerja sistem yang diusulkan Setelah mengetahui komponen-komponen sistem yang diusulkan selanjutnya adalah menentukan jenis perangkat sistem yaitu berupa tools atau alat untuk merancang dan mengimplementasikan sistem ususlan sehingga menghasilkan arsitektur sistem yang diinginkan. Dalam menentukan arsitektur sistem usulan yang terpenting adalah pemahaman terhadap jenis tools yang akan digunakan karena harus sesuai dengan kebutuhan pengguna dan fungsi-fungsi sistem yang terdapat didalamnya. Sistem usulan dirancang dengan menggunakan UML Unified Modeling Language , dan bahasa pemograman JAVA khususnya J2ME. Sehingga konsep tentang UML dn JAVA harus benar-benar dikuasai.

4.2.2 Perancangan Aplikasi

4.2.2.1. Identifikasi Use case dan Aktor

Identifikasi aktor dan use case ini didasari pada kebutuhan fungsi-fungsi sistem. Kebutuhan akan fungsi ini diakomodir di use case. Selanjutnya use case menyediakan nilai hasil kepada aktor. Atas dasar spesifikasi ini paling tidak didapat cara menetukan aktor. Berdasarkan penjelasan bab sebelumnya use case mencakup aliran-aliran kerja workflow dalam sistem bersifat internal sedangkan aktor-aktor mencakup segala sesuatu yang ada di luar sistem bersifat eksternal. Perbedaan antara use case dan aktor yang sedang dibahas saat ini dengan use case bisnis dan pekerja bisnis dibahas secara sekilas pada tabel di bawah ini. Tabel 4.4 Perbedaan Objek-objek dalam Model Bisnis dan Model Sistem. Nama Objek Model Bisnis Model Sistem Use Case Mendeskripsikan apa yang dikerjakan perusahaan atau instansi. Mendeskripsikan sistem yang akansedang dikembangkan dalam perusahaan atau instansi. Aktor Bersifat eksternal terhadap perusahan atau instansi. Bersifat eksternal terhadap sistem yang akansedang dikembangkan Pekerja Bisnis Bersifat internal dalam perusahaan atau instansi. Tidak digunakan Pemodelan sistem dilakukan untuk mendeskripsikan use case apa saja dan aktor yang akan terlibat dalam analisis sistem usulan, dapat dilihat dalam tabel requirement aktor dan use case berikut ini. Tabel 4.5 Requirement Aktor dan Use case Requirement Aktor Use case 1. Pengirim sms dapat mengirim sms. Pengirim Kirim SMS 2. Pengirim dan penerima sms dapat melihat data sms masuk yang tersimpan dan juga dapat mengedit, membalas dan menghapus sms. Pengirim dan penerima. Inbox 3. Pengirim dan penerima sms dapat melihat data sms keluar yang tersimpan dan juga dapat mengedit, membalas dan menghapus sms. Pengirim dan penerima. Inbox 4. Penerima sms dapat membaca sms yang masuk. 5. Penerima dan pengirim sms dapat membaca petunjuk teknis penggunaan aplikasi. Penerima Pengirim dan Penerima terima SMS bantuan 4.2.2.2.2Use Case Diagram Use Case Diagram menjelaskan apa yang akan dilakukan oleh sistem yang akan dibangun dan siapa yang berinteraksi dengan sistem. Use Case Diagram dapat dibuat sesuai dengan tabel Requirement Aktor dan Use Case di atas. Berikut ini adalah use case diagram untuk aplikasi enkripsi SMS. Gambar 4.2 Use case Diagram

4.2.2.3 Use Case Scenario

Setiap use case di atas harus di deskripsikan dalam dokumen yang disebut dokumen flow of event. Dokumentasi ini mendefinisikan apa yang harus dilakukan oleh sistem ketika aktor mengaktifkan use case. Struktur dari dokumen use case ini bisa bermacam-macam tetapi umumnya deskripsi ini paling tidak harus mengandung: 1. Brief Description deskripsi singkat 2. Aktor yang terlibat 3. Precondition yang penting bagi use case untuk memulai 4. Deskripsi rinci dari aliran kejadian yang mencakup a. Main flow dari kejadian yang bisa dirinci lagi menjadi sub flow dari kejadian sub flow bisa dibagi lagi lebih jauh menjadi sub flow yang lebih kecil agar dokumen lebih mudah dibaca dan dimengerti b. Alternative flow untuk mendefinisikan situasi perkecualian 5. Postcondition yang menjelaskan state dari sistem setelah use case berakhir Selain beberapa hal yang disebutkan di atas, dapat juga memakai beberapa deskripsi tambahan lainnya untuk melengkapi pendeskripsian yang dibuat. Setelah menjelaskan use case pada bahasan sebelumnya, maka berikut ini akan dijelaskan spesifikasi use case yang telah ditentukan. 1. Use case kirim SMS Tabel 4.6 Use case scenario kirim SMS Use Case Name kirim SMS Actor Pengirim Description Use case ini digunakan pengirim SMS untuk mengirimkan SMS. References Gambar 4.2 Actor Action System Response Typical Course of Events Step 1: Actor memilih kirim SMS Step 3: Actor memasukan no yang dituju ketik pesan dan memasukan password. Step 2: Sistem menampilkan form untuk kirim SMS. Step 4 : Sistem mengenkripsi sms dan mengirimkan pesan. Alternative Course Jika pesan tidak terkirim maka user harus mengulang step 1 Pre Condition Actor belum mengirimkan sms dan password pada HP penerima. Post Condition SMS terkirim dan data sms terenkripsi. 2. Use case inbox Tabel 4.7 Use case scenario inbox Use Case Name Inbox Actor Pengirim dan Penerima Description Use case ini digunakan pengirim dan penerima untuk melihat data sms yang masuk, mengedit sms, delete sms dan balas sms. References Gambar 4.2 Actor Action System Response Typical Course of Events Step 1: Actor memilih menu inbox Step 3: Actor memasukan pilihan edit, reply atau delete. Step 2: Sistem menampilkan data-data SMS Step 4 : Jika actor memilih edit maka aplikasi akan menampilkan form edit, jika memilih reply,aplikasi akan melakukan proses kirim sms, tanpa perlu memasukan nomor HP, jika actor memilih delete maka data akan terhapus. Alternative Course Jika pesan actor memilih reply maka akan melakukan usecase kirim SMS. Pre Condition Data SMS masuk ada di inbox. Post Condition SMS terkirim, data sms yang masuk dapat diedit dan dihapus.

3. Use case outbox Tabel 4.8

Use case scenario outbox Use Case Name Outbox Actor Pengirim dan Penerima Description Use case ini digunakan pengirim dan penerima untuk melihat data sms yang keluar, mengedit sms, delete sms dan balas sms. References Gambar 4.2 Actor Action System Response Typical Course of Events Step 1: Actor memilih menu outbox Step 3: Actor memasukan pilihan edit, reply atau delete. Step 2: Sistem menampilkan data-data SMS Step 4 : Jika actor memilih edit maka aplikasi akan menampilkan form edit, jika memilih reply,aplikasi akan melakukan proses kirim sms, tanpa perlu memasukan nomor HP, jika actor memilih delete maka data akan terhapus. Alternative Course Jika pesan actor memilih reply maka akan melakukan usecase kirim SMS. Pre Condition Data SMS masuk ada di outbox. Post Condition SMS terkirim, data sms yang masuk dapat diedit dan dihapus. 4. Use case terima SMS Tabel 4.9 Use case scenario terima SMS Use Case Name terima SMS Actor Penerima Description Use case ini digunakan penerima SMS untuk membaca SMS. References Gambar 4.2 Actor Action System Response Typical Course of Events Step 1: Actor memilih baca SMS Step 3: Actor memasukan memasukan password. Step 2: Sistem menampilkan form untuk terima SMS. Step 4 : Sistem mengdekripsi sms dan pesan ditampilkan. Alternative Course Jika password salah maka sms tidak akan didekripsi, dan actor harus kembali ke step 3. Pre Condition Actor sudah menerima SMS Post Condition SMS dekripsi dan dapat ditampilkan. 5. Use case Bantuan Tabel 4.10 Use case scenario bantuan Use Case Name Bantuan Actor Pengirim dan Penerima Description Use case ini digunakan pengirim dan penerima SMS untuk membaca petunjuk teknis aplikasi. References Gambar 4.2 Actor Action System Response Typical Course of Events Step 1: Actor memilih menu bantuan . Step 2: Sistem menampilkan petunjuk teknis aplikasi. Alternative Course - Pre Condition Actor belum mengerti tata cara penggunaan aplikasi Post Condition Petunjuk teknis aplikasi dapat dibaca oleh actor.

4.2.2.4 Activity Diagram

Activity diagram memodelkan alur kerja work flow sebuah urutan aktivitas pada suatu proses. Diagram ini sangat mirip dengan flow chart karena kita dapat memodelkan proses logika, proses bisnis dan alur kerja. Perbedaan utamanya adalah flow chart dibuat untuk menggambarkan alur kerja dari sebuah sistem, sedangkan activity diagram dibuat untuk menggambarkan aktivitas aktor. Berikut akan digambarkan satu persatu activity diagram untuk masing- masing use case. 1. Activity Diagram kirim SMS. Gambar 4.3 Activity Diagram dari use case kirim SMS Pertama kali pengirim memilih menu kirim SMS, kemudian sistem akan menampilkan form untuk kirim SMS, pada form tersebut pengirim menginput nomor yang akan dikirim SMS, kemudian setelah menginput nomor maka pengirim mengetikan pesan yang akan disampaikan , setelah itu pengirim menginput password yang akan digunakan pada SMS tersebut, setelah itu SMS akan di enkripsi dan pesan akan dikirimkan. 2. Activity Diagram Inbox Gambar 4.4 Activity Diagram dari use case inbox Pada activity diagram ini actor memilih menu inbox, kemudian sistem akan menampilkan data sms yang masuk, kemudian actor memilih menu yang ada. Jika actor memilih untuk edit maka sistem akan menampilkan form edit, kemudian actor mengedit sms yang masuk. Jika actor memilih menu delete, maka data sms yang dipilih akan terhapus dari sistem. Jika actor memilih menu reply maka sistem akan menampilkan form untuk reply, dan kemudian actor mengisi form reply, kemudian sms di enkripsi dan sms disampaikan ke nomor tujuan. 3. Activity Diagram Outbox Gambar 4.5 Activity Diagram dari use case outbox Pada activity diagram ini actor memilih menu outbox, kemudian sistem akan menampilkan data sms yang keluar, kemudian actor memilih menu yang ada. Jika actor memilih untuk edit maka sistem akan menampilkan form edit, kemudian actor mengedit sms yang keluar. Jika actor memilih menu delete, maka data sms yang dipilih akan terhapus dari sistem. Jika actor memilih menu reply maka sistem akan menampilkan form untuk reply, dan kemudian actor mengisi form reply, kemudian sms di enkripsi dan sms disampaikan ke nomor tujuan, 4. Activity Diagram Terima SMS Gambar 4.6 Activity Diagram dari use case terima SMS Pada activity diagram ini actor memilih menu baca sms, kemudian sistem akan menampilkan sms yang masuk, sms yang masuk masih terenkrip. kemudian actor memasukan password, Jika password yang dimasukan benar maka sistem akan mendekrip pesan SMS, dan menampilkannya ke layar penerima. Jika password yang dimasukan salah, maka actor harus memasukan password dengan benar. 5. Activity Diagram Bantuan Gambar 4.7 Activity Diagram dari use case bantuan Pada activity diagram ini actor memilih menu bantuan, kemudian sistem akan menampilkan petunjuk teknis yang dapat dibaca untuk mengetahui tata cara penggunaan aplikasi.

4.2.2.5 Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem termasuk pengguna, display, dan sebagainya berupa message yang digambarkan terhadap waktu. Dibawah ini adalah sequence diagram untuk masing-masing modul. 1. Sequence Diagram Kirim SMS Gambar 4.8. Sequence Diagram dari use case kirim SMS Pada sequence diagram ini pengirim memilih menu kirim SMS, kemudian sistem akan menampilkan form untuk kirim SMS, pada form tersebut pengirim menginput nomor yang akan dikirim SMS, kemudian setelah menginput nomor maka pengirim mengetikan pesan yang akan disampaikan , setelah itu memanggil class untuk enkripsi data, setelah data di enkripsi maka pesan dikirim, dan masuk ke dalam data sms keluar. 2. Sequence Diagram Inbox Gambar 4.9. Sequence Diagram dari use case inbox Pada sequence diagram ini actor memilih menu inbox, kemudian memanggil modul data sms, kemudian user memilih data sms, kemudian sistem akan memanggil class menu, jika user memilih edit, maka sistem akan menampilkan class edit, kemudian user mengedit sms yang ada. Jika user memilih delete maka data akan di delete di hapus dari data sms masuk jika memilih reply maka sistem akan menampilkan form untuk kirim SMS, pada form tersebut pengirim menginput nomor yang akan dikirim SMS, kemudian setelah menginput nomor maka pengirim mengetikan pesan yang akan disampaikan , setelah itu memanggil class untuk enkripsi data, setelah data di enkripsi maka pesan dikirim, dan masuk ke dalam data sms keluar. 3. Sequence Diagram Outbox Gambar 4.10 Sequence Diagram untuk use case outbox Pada sequence diagram ini actor memilih menu outbox, kemudian memanggil modul data sms, kemudian user memilih data sms, kemudian sistem akan memanggil class menu, jika user memilih edit, maka sistem akan menampilkan class edit, kemudian user mengedit sms yang ada. Jika user memilih delete maka data akan di delete di hapus dari data sms keluar. Jika memilih reply maka sistem akan menampilkan form untuk kirim SMS, pada form tersebut pengirim menginput nomor yang akan dikirim SMS, kemudian setelah menginput nomor maka pengirim mengetikan pesan yang akan disampaikan , setelah itu memanggil class untuk enkripsi data, setelah data di enkripsi maka pesan dikirim, dan masuk ke dalam data sms keluar. 4. Sequence Diagram Terima SMS Gambar 4.11. Sequence Diagram untuk use case terima SMS Pada sequence diagram ini sistem memanggil data sms, kemudian memanggil class form sms, kemudian actor menginput password, dan akan memanggil class cek password, jika password yang dimasukan benar, maka class untuk dekripsi pesan akan di panggil dan pesan akan ditampilkan, kemudian pesan masuk ke dalam class data pesan keluar. 5. Sequence Diagram Bantuan Gambar 4.12. Sequence Diagram untuk use case Bantuan Pada sequence diagram ini sistem menu awal, kemudian memanggil class bantuan, kemudian akan menampilkan bantuan pada user.

4.2.2.6 Class Diagram Class diagram

merupakan diagram yang selalu ada di permodelan sistem berorientasi objek. Class diagram menunjukkan hubungan antar class dalam sistem yang sedang dibangun dan bagaimana mereka saling berkolaborasi untuk mencapai suatu tujuan. Dibawah ini adalah class diagram pada aplikasi enkripsi dan deskripsi sms: Gambar 4.13. Class Diagram Daftar Operasi dapat dilihat pada table 4.11 dan Daftar Atribut pada Kelas Kirim SMS dapat dilihat pada tabel 4.12 Operasi dan Atribut 1. Kelas Kirim SMS Tabel 4.11 Daftar Operasi dari Kelas Kirim SMS Nama Operasi Visibility Private, Public Keterangan Proses Enkripsi Public Untuk mengirimkan pesan dan password yang telah dienkripsi IsValidPhone Number Protected Untuk memasukkan nomor telepon penerima Tabel 4.12 Daftar Atribut dari Kelas Kirim SMS Nama Atribut Visibility Private, Public Type Hasil Enkrip Protected String HEnkrip Private String Tambah Record Outbox Public void Menu Proses Enkripsi Private void Menu Reply SMS Public String Menu Kirim SMS Private Void Menu Forward SMS public void

2. Kelas Enkripsi SMS

Daftar Atribut pada Kelas Enkripsi SMS dapat dilihat pada tabel 4.13 Tabel 4.13 Daftar Operasi dari Kelas Enkripsi SMS

3. Kelas Receive SMS

Daftar Operasi dapat dilihat pada table 4.14 dan Daftar Atribut pada Kelas Receive SMS dapat dilihat pada tabel 4.15 Tabel 4.14 Daftar Operasi dari Kelas Receive SMS Nama Operasi Visibility Private, Public Keterangan Proses Dekripsi Public Untuk menghitung hasil dekrip dari SMS yang telah dienkrip Nama Atribut Visibility Private, Public Type Status Protected String Menu Reply SMS Public Void Menu Kirim SMS Private Void Command Action public Void Hitung Enkripsi Public String Tabel 4.15 Daftar Atribut dari Kelas Receive SMS Nama Atribut Visibility Private, Public Type txtPengirim private String Plaintext private String PK private Int txtPesan private String Status protected String txtTujuan private String SK private Int HasilDekrip private String Plaintext2 private String Port protected String menuSMS private Void Pangkat private Void menuProsesDekripsi private Void Hitung Dekripsi Public String Dekrip private Int Data2753 private Int

4. Kelas Outbox

Daftar Atribut pada Kelas Kirim SMS dapat dilihat pada tabel 4.16 Tabel 4.16 Daftar Atribut dari Kelas Outbox Nama Atribut Visibility Private, Public Type cariRecordOutbox public Void deleteOutbox public Void detailoutbox Public Void menuForward Public Void menuOutbox Public Void Menu SMS Public Void TambahRecordOutbox public Void

5. Kelas Inbox

Daftar Atribut pada Kelas Kirim SMS dapat dilihat pada tabel 4.17 Tabel 4.17 Daftar Atribut dari Kelas Inbox Nama Atribut Visibility Private, Public Type noPengirim protected String txtPesan protected String Menu kirim SMS Private Void menuInbox Public Void Delete Inbox Public Void Detail Inbox Public String Cari Record public Void

4.2.2.7. Spesifikasi Proses yang Diusulkan

Pada bagian ini akan dibahas mengenai proses perancangan sistem program, pengimplementasian kriptografi dalam proses pengambilan data SMS dengan mempertimbangkan berbagai faktor dan kebutuhan, seperti yang telah ditetapkan pada tahap analisis sistem.

4.2.2.7.1 Rancangan Pembangkitan Kunci

Seperti yang telah di jelaskan pada bagian analisis sistem, program sistem keamanan ini akan dibuat dengan menggunakan Kriptografi RSA. RSA merupakan sebuah algoritma pada enkripsi public key. RSA merupakan salah satu algoritma yang paling maju dalam bidang kriptografi public key dan dipercaya dalam mengamankan dengan menggunakan kunci yang cukup panjang. Modul-modul proses yang terdapat dalam algoritma RSA adalah sebagai berikut: Gambar 4.14 Tahapan algoritma RSA Dari modul diatas dapat dijelaskan sebagai berikut:

a. Algoritma Proses Pembangkitan Kunci

1. Tentukan bilangan prima p dan q 2. if p = “prima“ and q = “prima” then 3. Hitung r ← p q 4. Hitung r ← p – 1q – 1 5. Pilih PK 5.1 While PK relative prima dgn r dan PK r 5.2 PiliH PK 4.3 END WHILE 5. Hitung SK 6. SELESAI Keterangan dari algoritma diatas adalah sebagai berikut: Tentukan bilangan prima secara acak p dan q, setalah itu lakukan proses perhitungan p q untuk menghasilkan nilai r sebagai modulus. Lakukan proses perhitungan p-1q-1 untuk menghasilkan nilai ryang digunakan untuk mencari nilai SK Secret Key. Pilih bilangan bulat PK Public Key, dan selama PK adalah bilangan pembagi terbesar dan lebih kecil dari r, lakukan proses untuk mencari nilai SK. Berikut ini adalah flow chart pembangkitan kunci algoritma RSA. Gambar 4.15 Flow Chart Algoritma Pembangkit Kunci RSA

b. Algoritma Penentuan Bilangan p dan q Prima

1. Mulai 3. For i=1, i=100, i++ 3.1 if i = 1 Cetak “prima” 3.2 else if i = 2 Cetak “prima” 3.3 else ifi mod 2 = 0 and i mod 3 = 0 cetak “prima” 3.4 else cetak “bukan Prima” 4. END FOR 5. Selesai

c. Algoritma Proses Enkripsi