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