Kebutuhan Fungsional Kebutuhan Non-Fungsional

Menggabungkan Algoritma Simetris Dan Asimetris untuk Mengamankan Data Teks. Mesin Material Manusia Metode Kriptografi Simetri Kriptografi Asimetri Pengirim dan Penerima Pihak Ketiga Memiliki rasa curiga dan Ingin tahu Data yang dikirim aman Proses Komputasi Yang relatif lama Jalur Pengiriman Tidak Aman Kunci dapat diketahui Pihak Ketiga Lemahnya Pengamanan Kunci Gambar 3.1 Diagram Ishikawa Pada gambar 3.1, dapat disimpulkan bahwa permasalahannya adalah muncul rasa curiga atau ingin tahu dari pihak ketiga terhadap kerahasian sebuah pesan yang disebabkan faktor perubahan ciphertext dan penggunaan menggunakan satu kunci yang tidak aman dalam mengirimkan pesan kepada orang lain. Solusi yang dapat ditawarkan adalah dengan mengunci ciphertext dengan kunci kriptografi simetri serta mengunci cipherkey dengan kriptografi asimetri dalam pengiriman pesan. Dengan cara melakukan teknik Hybridcryptosystem dengan Algortima One Time Pad dan Algoritma Rabin. 3.1.2 Analisis Kebutuhan Didalam analisis kebutuhan ini terdapat dua kebutuhan yaitu kebutuhan fungsional dan kebutuhan non fungsional.

3.1.2.1 Kebutuhan Fungsional

Kebutuhan fungsional adalah menjelaskan proses-proses aktifitas yang dapat dilakukan oleh sistem dalam melakukan pelayanan yang dilakukan sistem dan kebutuhan yang harus dipenuhi oleh sistem, yaitu: Universitas Sumatera Utara 1. Fungsi Pembangkit Kunci Pengguna pada fungsi ini berperan sebagai penerima pesan. Pembangkitan kunci dapat dilakukan dengan input langsung atau pun dibangkitkan secara acak untuk memudahkan proses enkripsi dan dekripsi. 2. Fungsi Enkripsi Pengguna dapat melakukan proses enkripsi pesan dari plaintext menjadi ciphertext dengan memiliki kunci enkripsi berupa input langsung ataupun dengan memilih berkas yang tersimpan dalam format .txt atau .doc. 3. Fungsi Dekripsi Dapat melakukan proses dekripsi dengan memiliki kunci dekripsi dan ciphertext yang sesuai dan pengguna dapat melakukan proses dekripsi menjadi plaintext. 4. Fungsi Penguncian Kunci Pesan Dalam fungsi ini, pengguna dapat melakukan enkripsi kunci pesan dengan kunci publik yang sudah dibangkitkan dengan mengubahnya kedalam bentuk cipherkey .

3.1.2.2 Kebutuhan Non-Fungsional

Kebutuhan non-fungsional adalah mendeskripsikan fitur, karakteristik dan batasan lainnya seperti performa, penggunaan, model penyimpanan data, dokumentasi, kontrol, dan ekonomi. Terdapat beberapa hal yang menjadi syarat kebutuhan non- fungsional antara lain: 1. Performa Aplikasi yang dibangun dapat menampilkan dan menyimpan hasil dari fungsi kriptografi yang dilakukan oleh sistem. 2. Mudah dipelajari dan digunakan Aplikasi yang dibangun harus sederhana dan user friendly agar mudah digunakan dan dipelajari oleh pengguna. Universitas Sumatera Utara 3. Model Penyimpanan Data Data pesan teks yang dihasilkan baik berupa ciphertext maupun plaintext disimpan pada alamat file khusus dalam bentuk .txt dan .doc. 4. Dokumentasi Aplikasi yang akan dibangun memiliki panduan penggunaan aplikasi. 5. Kontrol Aplikasi yang akan dibangun memiliki pesan error jika pengguna tidak memasukkan data input tidak lengkap atau salah. 6. Ekonomi Aplikasi yang dibangun tidak membutuhkan biaya dan perangkat tambahan. 3.1.3 Analisis Proses Pada penelitian ini Aplikasi yang dibangun menggunakan algoritma One Time Pad untuk melakukan proses enkripsi dan dekripsi pesan dan algoritma Rabin Cryptosystem dalam melakukan proses enkripsi dan dekripsi kunci pesan. Data pesan yang diolah adalah berbentuk teks berformat .txt dan .doc. Pada algoritma Rabin Cryptosystem untuk membangkitkan kunci digunakan Theorema Fermat untuk menemukan suatu bilangan prima atau menguji keprimaan suatu bilangan. Pada proses dekripsi algoritma Rabin digunakan algoritma Chinese Remainder Theorem dan dalam menentukan hasil dekripsi dari empat kemungkinan hasil dilakukan secara otomatis autodecrypt, yaitu dengan memilih nilai yang paling kecil. Hal ini berdasarkan pengalaman dalam melakukan dekripsi dari nilai 1 hingga 255 mencakup karakter dalam ASCII 8 bit dengan kunci publik yang sama n dan lebih besar dari 255 n 255, nilai hasil dekripsi yang benar biasanya adalah nilai yang paling kecil .

3.2 Pemodelan

Pemodelan sistem dilakukan untuk menunjukkan dan mendeskripsikan gambaran dari sistem yang akan dibangun. Pada penelitian ini dilakukan pemodelan dengan menggunakan UML untuk mendesain serta merancang sistem.UML adalah bahasa yang digunakan untuk memberikan penjelasan mengenai komponen-komponen untuk Universitas Sumatera Utara membangun sistem dan interaksi antar komponen sistem. Model UML yang digunakan dalam penelitian ini antara lain adalah use case diagram, activity diagram serta sequance diagram. 3.2.1 Use-Case Diagram Use-case Diagram adalah gambaran skenario penggunaan aplikasi sistem tentang bagaimana cara sistem bekerja dengan pengguna. Use-case Diagram membutuhkan identifikasi siapakah pengguna yang akan menggunakan sistem tersebut. Pengguna tersebut dinamakan actor. Actor berperan untuk melakukan komunikasi dengan sistem dimana actor bekerja diluar dari sistem itu sendiri. Hubungan antar actor dengan use- case dihubungkan dengan garis lurus. Sedangkan hubungan dimana satu use-case digunakan untuk meredudansi use-case lainnya digunakan garis putus-putus dengan keterangan include. Untuk extend digunakan untuk mensimplifikasi satu use-case dengan use-case lainnya. Gambar 3.2 Diagram Use-Case Pada gambar 3.2 terdapat dua actor yang mempunyai peran masing-masing yaitu pengirim dan penerima.Pengirim mengenkripsikan pesan terlebih dahulu dengan algoritma One Time Pad setelah plaintext dienkripsikan menjadi ciphertext lalu kunci dari One Time Pad dienkripsikan dengan kunci publik yang diterima dari penerima Universitas Sumatera Utara menjadi cipherkey. Kemudian penerima menentukan kunci terlebih dahulu untuk dikirim ke sipengirim dengan membangkitkan kunci terlebih dahulu dengan algoritma Rabin. Penerima mengirimkan kunci publik ke sipengirim untuk mengunci kunci pesan dan sipenerima mengdekripsikan terlebih dahulu kunci pesan untuk mengetahui kunci pesan lalu mengedekripsikan pesan dari ciphertext menjadi plaintext. Berikut ini merupakan tabel narrative use-case yang dapat dilihat pada tabel 3.1 Tabel 3.1 Narrative Use-Case Enkripsi Pesan Use-case Name Enkripsi Pesan Design Scope Sistem black box Goal Level User-goal Stakeholder and Interest PengirimPengguna: dapat mengenkripsikan pesan dan kunci pesan untuk menjaga keamanan pesan. Precondition PenggirimPengguna memiliki file teks plaintext .txt atau .doc atau dapat memasukkan pesan secara langsung dan kunci publik. Minimal Guarantee Sistem akan memberikan pesan error ketika enkripsi pesan gagal. Success Guarantee Sistem akan memberikan pesan enkripsi telah sukses. Trigger Pengguna menekan tombol enkripsi pesan. Main Success Scenario 1. Pengirim menginputkan plaintext yang akan dienkripsi 2. Pengirim memasukkan kunci dan menekan tombol enkripsi. 3. Sistem akan melakukan enkripsi pesan. 4. Pengirim melakukan proses enkripsi kunci pesan dengan kunci publik. 5. Sistem akan melakukan enkripsi kunci pesan. 6. Sistem akan memberikan pesan bahwa enkripsi pesan dan kunci pesan telah sukses. Extensions 2. Kunci enkripsi tidak lengkap atau kosong. 2a. Sistem akan memberikan pesan kepada pengirim untuk dilakukan cek ulang kembali input-an yang telah diberikan. Berikut ini merupakan tabel narrative use-case yang dapat dilihat pada tabel 3.2 yang menjelaskan Narrative Use-Case Dekripsi Pesan. Universitas Sumatera Utara Tabel 3.2 Narrative Use-Case Dekripsi Pesan Use-case Name Dekripsi Pesan Design Scope Sistem black box Goal Level User-goal Stakeholder and Interest Penerima dapat mendekripsikan kembali cipherkey dan ciphertext ke dalam bentuk plaintext. Precondition Penerima memiliki file teks ciphertext Minimal Guarantee Sistem akan memberikan pesan error ketika dekripsi pesan gagal. Success Guarantee Sistem akan memberikan pesan dekripsi telah sukses dan menyimpannya pada alamat yang telah ditentukan. Trigger Pengguna dapat menekan tombol Dekripsi File. Main Succes Scenario 1. Penggirim memiliki kunci privat Rabin 2. Penggirim mengdenkripsikan kunci Pesan dengan Kunci Privat. 3. Penggirim mengdenkripsikan ciphertext yang akan didekripsi. 4. Sistem akan melakukan dekripsi pesan. 5. Sistem akan memberikan pesan bahwa dekripsi telah sukses. 6. Sistem akan menampilkan plaintext Berikut ini merupakan tabel narrative use-case yang dapat dilihat pada tabel 3.3 yang menjelaskan Narrative Use-Case Bangkitkan Kunci. Tabel 3.3 Narrative Use-Case Bangkitkan Kunci Use-Case Name Bangkitkan Kunci Secara Acak Design Scope Sistem black box Goal Level User-goal Stakeholders and Interest Pengirim Pengguna: Ingin menentukan atau membangkitkan kunci secara acak karena sulit secara manual. Precondition - Minimal Guarantee - Success Guarantee Sistem menampilkan kunci yang sudah memenuhi syarat. Trigger Pengguna menekan tombol bangkitkan kunci. Main Success Scenario 1. Sistem menampilkan kunci private dan kunci publik pada form. Universitas Sumatera Utara

3.2.2 Sequence Diagram