Institutional Repository | Satya Wacana Christian University: Perancangan Autentikasi Time Based One Time Password (TOTP) MD5 dan Kriptografi AES-CBC 128 bit untuk Proses Penerimaan Data dalam Aplikasi Pelaporan

  

Perancangan Autentikasi Time Based One Time Password

(TOTP) MD5 dan Kriptografi AES-CBC 128 bit untuk

Proses Penerimaan Data dalam Aplikasi Pelaporan

Jurnal

  

Peneliti:

Ericko Santoso (672014006)

Hindriyanto Dwi Purnomo, ST., MIT., Ph.D.

  

Program Studi Teknik Informatika

Fakultas Teknologi Informasi

Universitas Kristen Satya Wacana

Salatiga

  

Januari 2018

1. Pendahuluan

  Dengan banyaknya jumlah minimarket yang dimiliki oleh Perusahaan XYZ, menjadikan beberapa tokonya tidak terurus dengan baik, bahkan terkadang pada beberapa toko terdapat keluhan yang dapat mengganggu pelanggan saat berbelanja, seperti pendingin ruangan yang rusak, rak belanja patah, lantai rusak, mesin kasir yang rusak, serta keluhan-keluhan lain yang membuat para pelanggan tersebut menjadi malas untuk berbelanja kembali di tempat tersebut. Memang semua keluhan yang dimiliki pelanggan dapat disampaikan kepada petugas yang berada pada minimarket tersebut, namun sayangnya keluhan yang diajukan sering kali tidak dapat sampai ke kantor pusat untuk ditindak lanjuti. Maka dari itu, demi meningkatkan layanan kepada pelanggan yang merasa ada kekurangan saat berbelanja di minimarket, Perusahaan

  XYZ mengembangkan sebuah aplikasi yang mampu memudahkan petugas minimarket dalam menyampaikan keluhan pelanggan kepada kantor pusat secara cepat. Aplikasi tersebut bernama “Pelaporan XYZ” yang berbasis Mobile, sehingga penggunaannya dapat digunakan dimana saja dan kapan saja. Pengguna hanya perlu mengisikan alamat toko, kategori pelaporan, serta keluhan apa yang perlu untuk disampaikan ke dalam aplikasi. Pengguna aplikasi ini tidak hanya dikhususkan kepada petugas minimarket yang bersangkutan, namun dapat juga digunakan oleh seluruh pegawai di Perusahaan

  XYZ, sehingga apabila ada pegawai XYZ sedang berbelanja dan memiliki keluhan dapat segera melaporkannya ke kantor pusat agar dapat segera ditangani.

  Akan tetapi dalam penggunaannya selama ini, aplikasi Pelaporan XYZ masih belum memiliki sistem pengamanan dalam proses penerimaan datanya. Beberapa dampak yang terjadi apabila proses penerimaan data tidak dilindungi antara lain, meningkatnya resiko pengambilan data dari pihak ketiga, memungkinkan hacker untuk menerobos masuk, memungkinkan data yang dikirim tidak valid, dan berbagai dampak negatif lainnya. Cara yang tepat untuk mengamankan aplikasi tersebut adalah dengan menambahkan proses autentikasi dan kriptografi. Penggunaan proses autentikasi adalah untuk memvalidasi pengguna aplikasi tersebut, sedangkan kriptografi digunakan untuk mengamankan proses penerimaan data. Proses autentikasi yang saat ini sedang banyak digunakan adalah dengan menggunakan token berbasis waktu atau yang biasa disebut dengan Time Based One Time Password (TOTP), hal ini terlihat dari pemakaian TOTP di beberapa aplikasi besar, yang salah satunya adalah Google

  

Authenticator [1]. Untuk meningkatkan keamanan, token TOTP akan ditambahkan

fungsi hashing MD5, sehingga token yang dihasilkan berisi karakter acak [2].

  Sedangkan untuk metode kriptografi yang saat ini diakui keunggulannya adalah metode Kriptografi Advanced Encryption Standard (AES) [3]. Di dalam AES sendiri, mode operasi yang yang sering digunakan dan menjadi mode standar dari AES adalah mode Cipher Block Chaining (CBC) [4]. Dalam dunia kriptografi dibutuhkan suatu kunci yang digunakan untuk enkrip dan dekrip data. Maka dari itu, untuk aplikasi ini kunci yang digunakan berukuran 128 bit, karena ukuran tersebut dinilai lebih baik dan lebih cepat dibanding kunci berukuran 256 bit yang dinilai sudah tidak terlalu aman dan lebih lambat [3].

  Berdasarkan latar belakang tersebut, maka dilakukan penelitian yang bertujuan untuk merancang proses autentikasi Time Based One Time Password (TOTP) MD5 dan Kriptografi AES-CBC 128 bit untuk proses penerimaan data dalam aplikasi pelaporan. Sehingga setiap data yang dikirim dari server ke client atau sebaliknya dapat terlindungi dari serangan para pencuri data.

2. Tinjauan Pustaka 2.1. Penelitian Terdahulu

  Penelitian mengenai masalah pengamanan data telah banyak diteliti dan diimplementasikan. Pada penelitian yang berjudul Penerapan Enkripsi dan Dekripsi

  

File Menggunakan Algoritma Advanced Encryption Standard (AES), membahas

  tentang metode AES yang dipadukan ke pemrograman berbahasa Java dapat digunakan untuk mengamankan data berupa teks dan file [5].

  Pada penelitian yang berjudul Enkripsi dan Dekripsi dengan Algoritma AES 256 untuk Semua Jenis File, membahas tentang penggunaan metode kriptografi AES 256 bit mampu mengenkripsi file menjadi data tidak dapat dibaca, namun dapat didekripsi kembali menjadi file semula. Akan tetapi dengan menggunakan metode kriptografi AES 256 bit ukuran file yang dienkripsi menjadi bertambah dikarenakan adanya penambahan header untuk menyimpan informasi ekstensi file sumber [6].

  Penelitian ketiga dengan judul Perbandingan Algoritma AES dengan Algoritma

  XTS-AES untuk Enkripsi dan Dekripsi Teks SMS Berbasis Java ME, membahas mengenai analisa perbandingan algoritma yang lebih baik digunakan untuk proses enkripsi dan dekripsi teks SMS. Hasil dari penelitian tersebut menunjukkan bahwa Algoritma AES lebih unggul untuk mengamankan teks SMS dibandingkan Algoritma XTS-AES. Keunggulannya terdapat dalam segi kecepatan dan kompleksitas [7].

  Penelitian keempat yang berjudul Peningkatan Sistem Keamanan Autentikasi

  

Single Sign On (SSO) Menggunakan Algoritma AES dan One-Time Password Studi

  Kasus: SSO Universitas Ubudiyah Indonesia, membahas mengenai penggunaan metode AES dengan pembangkit kunci dinamis mampu mencegah serangan dictionary

  

attacks dan rainbow tables, selain itu penggunaan One-Time Password yang

  dikombinasi dengan Salt mampu menanggulangi kemungkinan aksi intercept terhadap penyalahgunaan hak akses user SSO [8].

  Dalam penelitian yang berjudul Pengembangan Mekanisme One Time Password dengan Menggunakan Strategi Dual Channel pada Aplikasi Web membahas tentang penggunaan Algoritma One Time Password mampu menjadi solusi pengamanan kata sandi karena hanya dapat digunakan satu kali proses login, selain itu layanan pemrosesan ke web service cukup cepat meskipun menggunakan proses enkripsi dan penggunaan bandwith aplikasi tidak berubah secara signifikan [9].

  Berdasarkan penelitian-penelitian yang pernah dilakukan terkait autentikasi One

  

Time Password (OTP) dan metode Kriptografi Advanced Encryption Standard (AES),

  maka akan dilakukan penelitian yang membahas tentang perancangan autentikasi Time

  

Based One Time Password (TOTP) MD5 dan metode Kriptografi AES-CBC dengan kunci 128 bit pada aplikasi pelaporan di Perusahaan XYZ yang berbasis Android. Penelitian ini diharapkan dapat mengamankan proses penerimaan data dalam aplikasi pelaporan milik Perusahaan XYZ.

2.2. Autentikasi Time Based One Time Password (TOTP) MD5

  Autentikasi merupakan sebuah proses yang memverifikasi apakah user yang mencoba untuk mengakses sumber daya dalam sistem benar-benar user yang valid atau tidak. User di ijinkan untuk mengakses sebuah sistem dan seluruh sumber daya di dalamnya jika sudah di autentikasi oleh sistem yang bersangkutan [10]. TOTP adalah

  

One Time Password (OTP) yang berbasis sinkronisasi waktu, dan berubah secara

  konstan pada setiap satuan interval waktu tertentu. Proses ini memerlukan sinkronisasi antara token milik client dengan server autentikasi. Pada jenis token yang terpisah (disconnected token), sinkronisasi waktu dilakukan sebelum token diberikan kepada

  

client . Tipe token lainnya melakukan sinkronisasi saat token dimasukkan dalam suatu

  alat input. Di dalam token terdapat sebuah jam akurat yang telah disinkronisasikan dengan waktu yang terdapat pada server autentikasi. Pada sistem OTP ini, waktu merupakan bagian yang penting dari algoritma password, karena pembangkitan

  

password baru didasarkan pada waktu saat itu dan bukan pada password sebelumnya

atau sebuah kunci rahasia.

  OTP jenis ini sudah mulai diimplementasikan terutama pada remote Virtual

  

Private Network (VPN), dan keamanan jaringan Wi-Fi dan juga pada berbagai aplikasi

Electronic Commerce (E-commerce). Ukuran standar penggunaan waktu pada

  algoritma ini adalah 30 detik. Nilai ini dipilih sebagai keseimbangan antara keamanan dan kegunaan [8].

  Berdasarkan teori tentang TOTP yang telah dijelaskan, dalam penelitian ini akan dilakukan sedikit perubahan tentang cara pembuatan token. Dalam penelitian ini, token akan dibuat berdasarkan username yang berupa NIK (Nomor Identitas Kepabeanan) serta waktu saat client melakukan login. Waktu yang digunakan terdiri dari tanggal, bulan, tahun serta jam dari client tanpa memperhatikan menit dan detik. Setelah token TOTP terbentuk, token ditambahkan dengan metode MD5, fungsi MD5 di sini adalah untuk mengubah hasil token TOTP menjadi karakter acak hasil dari proses MD5, yang merupakan metode pengamanan satu arah, sehingga token yang dihasilkan akan memiliki tingkat keamanan yang lebih baik.

  MD5 adalah singkatan dari Message Digest Algorithm 5, dan merupakan sebuah algoritma fungsi hash dari kriptografi yang digunakan dengan hash value 128 bit. Penggunaaan MD5 adalah untuk menyamarkan password yang tersimpan di database agar meningkatkan keamanan sistem tersebut. MD5 dikembangkan dan dirancang pada tahun 1991 oleh seorang bernama Ronald Rivest untuk menggantikan fungsi hash sebelumnya, yaitu MD4. MD5 telah digunakan untuk berbagai macam keperluan dalam membangun keamanan sebuah aplikasi. Salah satu penggunaan MD5 adalah untuk membantu validasi login pada sebuah sistem. MD5 mengenkripsi data yang bersifat rahasia dan tidak ingin diketahui orang lain, biasanya digunakan untuk mengamankan password agar tidak dapat dibaca pada database, sehingga meskipun ada pengguna yang membaca password tersebut [2].

  Untuk proses autentikasi aplikasi Pelaporan XYZ, dilakukan saat pengguna melakukan proses login, sehingga pengguna tersebut dapat diperiksa validitas identitasnya dalam menggunakan aplikasi Pelaporan XYZ. Untuk batas toleransi waktu yang diberikan adalah 1 jam, hal ini dimaksudkan untuk meminimalkan kemungkinan terjadinya perbedaan waktu. Misalnya, user melakukan login pukul 07.59 WIB, ada kemungkinan login yang diterima server terjadi pada pukul 08.00 atau 08.01 WIB, apabila tidak ada toleransi waktu, maka permintaan login dari user akan ditolak karena

  

token yang dihasilkan akan berbeda berdasarkan perbedaan jam yang ada. Maka dari

  itu, untuk mengurangi resiko tersebut, rancangan proses autentikasi diberikan toleransi waktu sebesar 1 jam.

2.3. Kriptografi AES – CBC 128 bit

  Kriptografi (cryptography ) berasal dari Bahasa Yunani: “cryptós” artinya

  “secret” (rahasia), sedangkan “gráphein” artinya “writing” (tulisan). Jadi, kriptografi berarti “secret writing” (tulisan rahasia). Kriptografi adalah ilmu yang mempelajari berbagai macam teknik matematika yang berhubungan dengan aspek keamanan informasi seperti kerahasiaan, integritas data, serta autentikasi [7]. Aspek keamanan kriptografi, antara lain kerahasiaan (confidentiality), autentikasi (authentication), integritas (integrity), nirpenyangkalan (nonrepudiation) [11].

  AES merupakan algoritma cipher yang cukup aman untuk melindungi data atau informasi yang bersifat rahasia. Pada tahun 2001, AES digunakan sebagai standar algoritma kritografi terbaru yang dipublikasikan oleh National Institute of Standard

  

and Technology (NIST) sebagai pengganti Algoritma Data Encryption Standard (DES)

  yang sudah berakhir masa penggunaannya. Algoritma AES adalah algoritma kriptografi yang dapat mengenkripsi dan mendekripsi data dengan panjang kunci yang bervariasi, yaitu 128 bit, 192 bit, dan 256 bit [8]. Untuk perbandingan perputaran tiap kunci, dapat dilihat pada Tabel 1 [6]. Dari perbandingan tersebut, menunjukkan bahwa semakin besar ukuran kunci, maka akan semakin banyak pula proses perputaran untuk menghasilkan kunci. Maka dari itu, untuk penelitian ini kunci yang digunakan berukuran 128 bit, karena ukuran tersebut dinilai lebih baik dan lebih cepat dibanding kunci berukuran 256 bit yang dinilai sudah tidak terlalu aman dan lebih lambat [3].

  

Tabel 1 Skema Enkripsi dan Dekripsi CBC [6]

  AES Jumlah Key Ukuran Blok Jumlah Putaran (NK) (Nb) (Nr)

  128

  4

  4

  10 192

  6

  4

  12 256

  8

  4

  14 Proses enkripsi algoritma AES terdiri dari 4 jenis transformasi bytes, yaitu

  

SubBytes , ShiftRows, MixColumns, dan AddRoundKey. Awal proses enkripsi, input

yang telah disalin ke dalam state akan mengalami transformasi byte AddRoundKey.

  Setelah itu, state akan mengalami transformasi SubBytes, ShiftRows, MixColumns, dan

  

AddRoundKey secara berulang-ulang sebanyak Nr. Proses ini dalam algoritma AES

  disebut dengan round function. Round terakhir sedikit berbeda dengan round sebelumnya dimana pada round terakhir, state tidak mengalami transformasi

  

MixColumns . Pada proses dekripsi AES transformasi cipher dapat dibalikkan dan

  diimplementasikan dalam arah yang berlawanan untuk menghasilkan inverse cipher yang mudah dipahami untuk algoritma AES. Transformasi byte yang digunakan pada

  

invers cipher adalah InvShiftRows, InvSubBytes, InvMixColumns, dan AddRoundKey

[8].

  Dalam metode AES, terdapat beberapa mode untuk melakukan proses kriptografi, salah satunya adalah mode Cipher Block Chaining (CBC). Mode operasi CBC ditemukan oleh IBM pada tahun 1976. Pada mode ini, tiap blok dari plaintext diproses menggunakan operasi XOR dengan hasil ciphertext dari blok sebelumnya yang kemudian dilakukan enkripsi. Dengan cara ini, tiap ciphertext dari setiap blok akan tergantung pada seluruh hasil ciphertext dari setiap blok yang ada sebelumnya. Selain itu, untuk membuat tiap pesan menjadi unik, digunakan IV (Initialization

  

Vector ) untuk dilakukan XOR dengan blok pertama. IV dapat diberikan oleh pengguna

  atau dibangkitkan secara acak oleh program. Pada cipher blok, rangkaian bit plaintext dibagi menjadi susuna blok bit dengan panjang sama. Enkripsi dilakukan terhadap blok bit plaintext menggunakan kunci (yang ukurannya sama dengan blok plaintext). Algoritma enkripsi menghasilkan blok ciphertext yang berukuran sama dengan blok

  

plaintext. Dekripsi dilakukan dengan cara yang serupa seperti enkripsi. Untuk skema

enkripsi dan dekripsi CBC dapat dilihat pada Gambar 1 [12].

  Gambar 1 Skema Enkripsi dan Dekripsi CBC [12]

3. Metode dan Perancangan Sistem

  Secara umum penelitian terbagi ke dalam lima tahap (dapat dilihat pada gambar 2), yaitu: (1) tahap identifikasi masalah, (2) tahap studi literatur, (3) tahap perancangan sistem keamanan data, (4) tahap implementasi, (5) tahap pengujian.

  

Identifikasi Masalah

Studi Literatur

Perancangan Sistem Keamanan Data

Implementasi

  

Pengujian

Gambar 2 Tahapan Penelitian [13]

  Tahapan penelitian pada gambar 2, dijelaskan sebagai berikut. Tahap Identifikasi

  

Masalah, pada tahapan ini adalah tahap dalam menganalisis permasalahan yang ada,

  yaitu masalah mengenai keamanan saat proses penerimaan data di Aplikasi Pelaporan

  XYZ. Dalam proses penerimaan data, data yang dikirim dari server ke aplikasi client belum memiliki keamanan, sehingga data sangat beresiko untuk diserang atau dicuri;

  

Tahap Studi Literatur pada tahapan ini pengumpulan data terkait penelitian serupa

  yang pernah dilakukan sebelumnya. Tujuan dari tahapan ini adalah untuk mengumpulkan pengetahuan yang memadahi untuk menjalankan penelitian serta untuk mengantisipasi kesamaan topik dengan penelitian terdahulu; Tahap Perancangan

  

Sistem Keamanan Data, pada tahapan ini perancangan meliputi pemilihan metode

  autentikasi dan kriptografi apa yang akan digunakan, perancangan arsitektur sistem, serta perancangan Unified Modelling Language (UML) yang terdiri dari use case diagram dan activity diagram; Tahap Implementasi, pada tahapan ini, rancangan pengamanan data yang telah disiapkan mulai diimplementasikan; Tahapan Pengujian, pada tahapan ini, hasil implementasi rancangan autentikasi dan kriptografi akan dilakukan pengujian dengan menggunakan Performance Test untuk mengukur performa aplikasi dan Stress Test untuk mengetahui batas kemampuan aplikasi Pelaporan XYZ, sehingga apabila ada kekurangan dapat diperbaiki. Skenario

  

performance test adalah dengan membandingkan performa aplikasi sebelum

  ditambahkan kriptografi dan setelah ditambahkan dalam menghadapi 1.000 pengguna yang mengakses aplikasi secara hampir bersamaan (delay 100 ms), untuk stress test akan dilakukan dengan mensimulasikan 10.000 pengguna mengakses aplikasi secara bersamaan, sehingga akan terlihat bagaimana performa aplikasi untuk menyelesaikan simulasi tersebut.

  Rancangan arsitektur sistem ini dapat dilihat pada gambar 3. Dalam arsitektur tersebut terlihat bahwa client yang ingin mengakses aplikasi harus memiliki koneksi

  VPN internet sebelum dapat saling melakukan proses transaksi data antara server dengan database. Lalu terdapat admin yang membutuhkan koneksi VPN internet untuk terhubung dengan database dan server yang berperan sebagai pengawas dan pengontrol jalannya aplikasi.

  

Gambar 3 Rancangan Arsitektur Sistem

  Rancangan UML dalam penelitian ini terdiri dari use case diagram dan activity diagram. Penggambaran use case diagram dapat dilihat pada gambar 4. Dalam use case tersebut terlihat bahwa terdapat dua actor yaitu admin dan client. Client adalah semua karyawan perusahaan XYZ yang mempunyai hak akses untuk membuat laporan, melihat laporan, mencari laporan, memberi komentar, melihat komentar, melihat profil diri serta mengubah profil diri. Sedangkan admin adalah karyawan perusahaan XYZ yang mempunyai hak akses untuk menerima laporan dan menolak laporan.

  Gambar 4 Use Case Diagram Aplikasi Pelaporan

  Penggambaran Activity diagram dapat dilihat pada gambar 5. Berikut adalah penjelasan mengenai Activity diagram, Client mempunyai beberapa hak atau aktivitas yang dapat dilakukan saat membuka aplikasi. Namun, sebelum client diperbolehkan menggunakan hak dalam pemakaian aplikasi, terlebih dahulu client tersebut perlu melewati pemeriksaan username dan password dalam proses login. Setelah proses

  

login terlewati, client perlu untuk melewati pemeriksaan token dalam proses

  autentikasi. Setelah pemeriksaan login dan autentikasi terlewati, barulah client dapat masuk ke dalam aplikasi untuk menggunakan haknya.

  Dalam aplikasi terdapat beberapa menu untuk meminta data yang diperlukan, seperti menu lihat profil, lihat laporan, cari laporan, dan lihat komentar. Pemilihan

  

menu tersebut merupakan penghubung antara client dengan server, yang fungsinya

  untuk membantu server mengetahui data apa yang diperlukan client. Setiap permintaan dari client dikirim ke server dalam bentuk ciphertext, setelah permintaan tersebut diterima server, barulah server melakukan proses dekripsi untuk mengetahui permintaan data yang dibutuhkan. Untuk setiap data yang diminta atau di-request oleh

  

client, sebelum dikirim ke client, data tersebut akan dienkripsi terlebih dahulu, lalu saat

  telah diterima oleh client, client akan melakukan dekripsi sehingga data yang berbentuk

  

ciphertext berubah kembali menjadi plaintext. Hanya data yang akan dikirim yang

  melalui proses enkripsi, sedangkan menu tambah laporan, tambah komentar, dan

  

update profil tidak memerlukan proses enkripsi. Data yang telah terenkripsi tersebut,

  dikirim ke server dan server akan melakukan dekripsi terlebih dahulu, apabila berhasil maka data akan disimpan ke dalam database.

  

Gambar 5 Activity Diagram Aplikasi Pelaporan

  Untuk rancangan proses autentikasi dalam penelitian ini menggunakan token berbasis waktu, atau biasa yang disebut dengan Time Based One Time Password (TOTP). Jadi proses autentikasi akan dilakukan saat pengguna melakukan proses login, dalam proses login tersebut selain harus memiliki username dan password yang valid, pengguna juga harus memiliki token yang valid. Proses pengecekan token dilakukan dalam server, sehingga pengguna perlu mengirimkan token yang dibuat dari aplikasi ke server, apabila server menganggap token tersebut valid, maka pengguna diperbolehkan untuk masuk ke dalam sistem. Namun apabila gagal, server tidak langsung menolak permintaan pengguna, tetapi server akan mencoba mencocokkan kembali token tersebut dengan token satu (1) jam sebelumnya. Tujuannya untuk meminimalkan terjadinya perbedaan waktu. Token TOTP dihasilkan dari penggabungan username serta waktu pembuatan token. Username dalam aplikasi ini berbentuk NIK sehingga sifatnya unik, sedangkan waktu yang dimaksud terdiri dari tanggal, bulan, tahun, serta jam saat melakukan proses login. Setelah itu, kombinasi karakter yang terbentuk diamankan kembali menggunakan metode hashing MD5. Misalnya, pengguna melakukan login pukul 07.59 WIB dan mengirimkan hasil token- nya yaitu “22ef486f254b3b09f3b1696e86af4bc2”, ada kemungkinan login yang diterima server terjadi pada pukul 08.00 atau 08.01 WIB sehingga token yang dibuat dari sisi server telah berubah menjadi “08352ce6957eb75193125a2ab9d211eb”. Apabila tidak ada toleransi waktu, maka server akan langsung menolak permintaan pengguna, maka dari itu proses autentikasi dalam aplikasi pelaporan ini dirancang untuk mentoleransi waktu satu jam sebelumnya.

  Untuk meningkatkan keamanan aplikasi, selain menggunakan autentikasi TOTP, diperlukan sebuah mekanisme pengamanan dalam proses pertukaran data (upload dan

  

download ). Mekanisme pengamanan pengiriman data dalam aplikasi ini dilakukan

  dengan teknik kriptografi yaitu mengenkripsi setiap data yang akan dikirim menjadi

  

ciphertext , lalu ketika menerima data, data yang telah berbentuk ciphertext didekripsi

  kembali menjadi plaintext agar data dapat dibaca kembali. Proses pengamanan dalam penelitian ini akan lebih ditekankan pada proses penerimaan (download) data. Berikut adalah penjelasan mengenai mekanisme pengamanan data, setiap kali pengguna melakukan permintaan (request) data ke server, permintaan tersebut dienkripsi terlebih dahulu. Kunci yang dipakai dalam metode tersebut dihasilkan dari username digabung dengan waktu server serta salt. Salt yang dipakai dalam aplikasi ini bersifat tetap atau tertanam dalam source code. Waktu dari server didapat dengan meminta (request) setiap kali akan melakukan enkripsi ataupun dekripsi. Waktu dari server yang akan dipakai terdiri dari tanggal, bulan, tahun, dan jam tanpa memperhatikan menit dan detik. Penggunaan waktu dari server bertujuan untuk menghasilkan ciphertext yang unik dan valid, karena apabila menggunakan waktu dari client, ada kemungkinan perbedaan zona waktu yang dapat membuat ciphertext tidak dapat didekripsi kembali.

  

Request yang telah dienkripsi, dikirim ke server untuk mendapatkan data yang

  dibutuhkan client. Namun, karena request yang dikirim tidak berbentuk plaintext,

  

server akan mencoba untuk mendekrip permintaan tersebut. Sama seperti proses

  autentikasi yang bergantung dengan waktu, kunci untuk kriptografi juga bergantung dengan waktu, maka dari itu apabila proses dekripsi request pertama gagal, akan dilakukan proses dekripsi request untuk kedua kalinya dengan menggunakan kunci satu jam sebelumnya. Tujuannya agar apabila proses penerimaan request ke server mengalami keterlambatan, request yang dikirim dapat tetap diproses oleh server.

  Proses pembuatan kunci untuk dekripsi di sisi server memiliki cara yang sama dengan pembuatan kunci dari sisi client, karena kunci AES bersifat simetris [8]. Apabila

  

request gagal didekripsi oleh server, maka server akan mengirimkan pesan error

  kepada client. Apabila request telah berhasil terdekripsi, maka server akan mengirimkan data yang diminta oleh client. Tetapi data yang akan dikirim ke client tidak langsung dikirim secara mentah (plaintext), namun data tersebut dienkripsi terlebih dahulu menjadi bentuk ciphertext, menggunakan kunci yang sama dengan saat pembuatan kunci untuk mengenkripsi request. Data yang telah berbentuk ciphertext, dikirim ke client. Nantinya client akan mendekripsi kembali data yang berbentuk

  

ciphertext tersebut menjadi plaintext agar dapat dibaca kembali. Untuk memperjelas

rancangan autentikasi dan kriptografi dapat melihat gambar 6 dan 7.

  Gambar 6 Rancangan Proses Autentikasi

  Gambar 7 Rancangan Proses Kriptografi dalam Proses Penerimaan Data

4. Hasil dan Pembahasan

  Berdasarkan perancangan yang telah disiapkan, menghasilkan sebuah aplikasi yang mampu melakukan autentikasi menggunakan token TOTP dan proses penerimaan datanya dilindungi oleh kriptografi AES-CBC 128 bit. Sebelum client dapat mengakses aplikasi, client harus terlebih dahulu melewati proses login dan autentikasi token untuk mengecek kevaliditasan pengguna. Proses login meliputi pengecekan username dan

  

password client, apabila berhasil maka akan berlanjut ke proses autentikasi untuk

  mencocokkan token yang dimiliki client dengan token milik server. Proses pembuatan

  

token dalam login dapat dilihat dalam kode program 1 dan 2. Kode program 1

  merupakan perintah untuk membuat hashing MD5. Kode program 2 merupakan perintah untuk menghasilkan token TOTP, token yang dihasilkan merupakan penggabungan antara username dengan waktu (tanggal, bulan, tahun, dan jam) saat melakukan login. Sedangkan perintah untuk mencocokkan token milik client dengan

  

token milik server terdapat dalam kode program 3. Di dalam kode program 3, terdapat

  perintah untuk menghasilkan token TOTP MD5 dari sisi server serta perintah untuk mentoleransi token client dengan menggunakan waktu satu jam sebelumnya apabila proses pencocokkan token yang pertama kali mengalami kegagalan.

  Kode Program 1 Algoritma MD5

  1 MessageDigest md = MessageDigest.getInstance("MD5"); 2 byte[] messageDigest = md.digest(input.getBytes());

3 BigInteger number = new BigInteger(1, messageDigest);

  4 String hashtext = number.toString(16); 5 while (hashtext.length() < 32) { Setiap kali client membutuhkan data dari server, client akan mengirimkan permintaan (request) yang diamankan atau dienkripsi terlebih dahulu menggunakan metode kriptografi AES-CBC. Dalam proses enkripsi tersebut, client meminta waktu dari server sebagai salah satu komposisi dari kunci kriptografi. Waktu server yang diminta terdiri dari tanggal, bulan, tahun, dan jam. Selain waktu server, kunci kriptografi juga terdiri dari username serta salt. Perintah untuk mengenkripsi request dapat dilihat pada kode program 4.

  6

  23

  16

  17

  18

  19

  20

  21

  22

  24

  14

  25

  26

  27

  28 If status = 0 Then 'Percobaan pertama strToHash = dt.ToString("yyyyMMdd") + userid + "|" + dt.ToString("HH") + "|" ElseIf status = 1 Then 'Untuk percobaan kedua, jam dikurangi 1 jam sebelumnya strToHash = dt.ToString("yyyyMMdd") + userid + "|" + dt.AddHours(- 1).ToString("HH") + "|" Else strToHash = "Gagal" End If Dim waktu As String = dt.ToString("dd-MM-yyyy HH:mm") Dim md5Obj As New MD5CryptoServiceProvider() Dim bytesToHash() As Byte = System.Text.Encoding.ASCII.GetBytes(strToHash) bytesToHash = md5Obj.ComputeHash(bytesToHash) Dim strResult As String = "" For Each b As Byte In bytesToHash strResult += b.ToString("x2") Next If otp = strResult Then result.namajsonproperty = "OK" Else If status = 0 Then result.namajsonproperty = "RETRY" Else result.namajsonproperty = waktu End If End If

  1

  2

  3 String key = time + sharedpreferences.getString("userKey", "")+ "1nI4DaLL4ahHP4Dd11N9994ANnNKKkkKKuUuUNnnnnCcCCI1I!I!"; Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");

  15

  13

  7

  2

  8 hashtext = "0" + hashtext; } return hashtext;

  1

  2

  3

  4

  5 String time1 = new SimpleDateFormat("yyyyMMdd").format(new Date());

String time2 = new SimpleDateFormat("HH").format(new Date());

String userid = userid; ToHash = time1 + userid + "|"+ time2 + "|"; sResult = getMD5(ToHash);

  1

  3

  12

  4

  5

  6

  7

  8

  9

  10

  11

  Kode Program 2 Perintah Pembuatan Token Client Kode Program 3 Perintah Pembuatan Token Server dan Pencocokkan Token Kode Program 4 Metode Enkripsi Request AES-CBC

  Setelah request client diterima oleh server, server akan mencoba untuk mendekripsi request tersebut untuk mengetahui data apa yang diminta oleh client. Metode yang digunakan untuk mendekripsi request client sama seperti yang digunakan dalam proses enkripsi request yaitu dengan menggunakan metode AES-CBC dengan kunci yang sama yaitu terdiri dari username, waktu server (tanggal, bulan, tahun, dan jam), serta salt. Saat pertama kali melakukan dekripsi request, apabila mengalami kegagalan, request tersebut tidak langsung ditolak, namun server akan mencoba untuk mendekripsi request tersebut menggunakan waktu satu jam sebelumnya. Perintah untuk mendekripsi request tersebut tertulis dalam kode program 5.

  26

  17

  18

  19

  20

  21

  22

  23

  24

  25

  27

  15

  28

  29

  30

  31

  32

  33

  34

  35

  36 Try Dim plainText As Byte() If status = 0 Then time = dt.ToString("ddMMyyyy") + dt.ToString("HH") ElseIf status = 1 Then

time = dt.ToString("ddMMyyyy") + dt.AddHours(-1).ToString("HH")

End If Dim key As String = time + userid + "1nI4DaLL4ahHP4Dd11N9994ANnNKKkkKKuUuUNnnnnCcCCI1I!I!" Dim rijndaelCipher As New RijndaelManaged() rijndaelCipher.Mode = CipherMode.CBC rijndaelCipher.Padding = PaddingMode.PKCS7 rijndaelCipher.KeySize = &H80 rijndaelCipher.BlockSize = &H80 '128bit Dim encryptedData As Byte() = Convert.FromBase64String(textToDecrypt) Dim pwdBytes As Byte() = Encoding.UTF8.GetBytes(key) Dim keyBytes As Byte() = New Byte(15) {} Dim len As Integer = pwdBytes.Length If len > keyBytes.Length Then len = keyBytes.Length End If Array.Copy(pwdBytes, keyBytes, len) rijndaelCipher.Key = keyBytes rijndaelCipher.IV = keyBytes plainText = rijndaelCipher.CreateDecryptor().TransformFinalBlock(encryptedData, 0, encryptedData.Length) result = Encoding.UTF8.GetString(plainText) Catch ex As Exception ''jika gagal If status = 0 Then result = "RETRY" Else Dim waktu As String = dt.ToString("dd-MM-yyyy HH:mm") result = "DECRYPTION FAILED... " + waktu End If End Try

  16

  14

  4

  1

  5

  6

  7

  8

  9

  10

  11

  12

  13 byte[] keyBytes = new byte[16]; byte[] b = key.getBytes("UTF-8"); int len = b.length; if (len > keyBytes.length) len = keyBytes.length; System.arraycopy(b, 0, keyBytes, 0, len); SecretKeySpec keySpec = new SecretKeySpec(keyBytes, "AES"); IvParameterSpec ivSpec = new IvParameterSpec(keyBytes); cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec); byte[] results = cipher.doFinal(text.getBytes("UTF-8")); result = Base64.encodeToString(results, Base64.DEFAULT);

  2

  13

  3

  4

  5

  6

  7

  8

  9

  10

  11

  12

  Kode Program 5 Metode Dekripsi Request AES-CBC

  Apabila proses dekripsi request berhasil, maka server akan mengirimkan data yang diminta oleh client dalam bentuk ciphertext. Setiap data yang akan dikirim ke

  

client diubah ke dalam bentuk ciphertext terlebih dahulu menggunakan metode AES-

  CBC sama seperti saat proses client mengirim request ke server. Saat client melakukan proses download data, data yang berbentuk ciphertext tersebut diterima lalu didekripsi terlebih dahulu menjadi bentuk semula (plaintext) sebelum ditampilkan dalam aplikasi.

  Yang menjadi point penting dalam aplikasi ini adalah setiap proses dekripsi baik dekripsi request yang berbentuk ciphertext dalam server ataupun dekripsi data yang berbentuk ciphertext dalam client, terdapat toleransi waktu sebesar satu jam. Dikarenakan setiap ciphertext terbuat dari kunci yang salah satu komposisinya adalah waktu. Tujuan dari toleransi waktu tersebut adalah untuk mengurangi resiko perbedaan jam saat proses pengiriman dan penerimaan request atau data, karena hal tersebut sangat dipengaruhi oleh waktu. Pengiriman request atau data pukul 08.59 WIB akan berbeda dengan pengiriman pukul 09.00 WIB, sehingga apabila gagal dapat dicoba sekali lagi dengan menggunakan waktu satu jam sebelumnya.

  Demi menjaga performa aplikasi yang ditakutkan berkurang karena adanya proses penambahan kriptografi, maka dalam aplikasi yang telah diimplementasikan, dilakukan pengujian menggunakan Performance Test untuk mengukur performa aplikasi dan Stress Test untuk mengukur sampai sejauh mana batas kemampuan aplikasi. Skema performance test untuk aplikasi ini adalah dengan melihat perbandingan antara performance test aplikasi sebelum penambahan kriptografi dan sesudah penambahan kriptografi, pengujian dilakukan saat proses mengambil data laporan, karena untuk mengambil seluruh data laporan membutuhkan waktu dan

  

resource yang cukup banyak. Untuk skenario performance test dimisalkan terdapat

  1.000 orang yang akan mengakses data laporan secara hampir bersamaan (delay 100 ms) dengan batas time out 300 ms. Apabila melihat perbandingan antara sebelum dan sesudah penambahan kriptografi dalam aplikasi yang ditakutkan akan menurunkan performa, ternyata perbandingan antara keduanya tidak jauh berbeda, karena total waktu yang dibutuhkan untuk menyelesaikan skenario tersebut sebesar 35.125 ms atau naik sebesar 7,007 detik (24,92%) yang dapat dikategorikan dalam hal yang wajar, sehingga membuktikan bahwa dengan ditambahkannya proses kriptografi, aplikasi dapat tetap berjalan dengan baik. Berikut adalah perbandingan performanya (dapat dilihat pada Tabel 2) :

  

Tabel 2 Perbandingan Performa Sebelum dan Sesudah Penambahan Kriptografi

  Nilai Waktu Sebelum Nilai Waktu Sesudah Variabel

  Penambahan Kriptografi Penambahan Kriptografi

  Min Duration 12 ms 15 ms Max Duration 163 ms 236 ms Average Duration 28 ms 35 ms Total Duration 28118 ms 35125 ms Setelah performance test terlewati, maka selanjutnya adalah melakukan Stress

  

Test untuk mengukur sampai sejauh mana batas kemampuan aplikasi. Skenario yang

  digunakan yaitu terdapat 10.000 orang yang mengakses aplikasi secara bersamaan (delay 1 ms) dengan batas time out sebesar 300 ms. Melihat grafik hasil dari stress test yang terdapat pada gambar 8, terlihat bahwa beberapa kali terjadi kenaikan waktu proses yang cukup lama bahkan ada yang mencapai 629 ms. Namun setelah terjadi kenaikan waktu tersebut, proses dapat kembali berjalan normal tanpa terjadi error atau

  

crash . Sehingga ini membuktikan bahwa aplikasi masih dapat berjalan dengan baik

  walaupun terdapat 10.000 orang yang mengakses aplikasi secara bersamaan. Dari hasil

  

stress test , total waktu yang dibutuhkan untuk menyelesaikan skenario tersebut sebesar

  186.030 ms (186 detik) dan rata-rata durasinya sebesar 19 ms, dengan waktu tercepat untuk menyelesaikan sebuah proses adalah 12 ms dan waktu terlamanya adalah 629 ms.

  

Gambar 8 Grafik Stress Test

  Hasil penilaian tersebut sebenarnya dipengaruhi juga oleh kondisi client dan

  

server yang berjalan. Untuk melihat hasil stress test yang lebih detil dapat dilihat pada

  Tabel 3. Dalam tabel tersebut terlihat bahwa sebenarnya apabila client dan server berada dalam kondisi terbaik, performa aplikasi dapat berjalan lebih baik. Terlihat bahwa apabila client berada pada kondisi terbaik, sebenarnya skenario tersebut dapat diselesaikan dengan average duration sebesar 17 ms, dengan banyak request yang dapat ditangani sebesar 58,82 request/detik (naik 6,19 request/detik). Sedangkan apabila server sedang dalam kondisi terbaik, skenario tersebut dapat diselesaikan dengan average duration sebesar 15 ms dan dapat menangani 66,67 request/detik, bahkan dapat menangani 334 user secara bersamaan (dapat dilihat pada Tabel 3).

  Tabel 3 Hasil Stress Test Client Server Client Server

  Variabel (kondisi (kondisi (keseluruhan) (keseluruhan) terbaik) terbaik)

  Average

  19 ms 17 ms 17 ms 15 ms

  Duration

  52,63 58,82 58,82 66,67

  Throughput request/sec request/sec request/sec request/sec Inter-

  5019 ms 5017 ms 5017 ms 5015 ms

  arrival time Concurrent

  264 295 295 334

  users

  5. Simpulan

  Berdasarkan hasil pembahasan dan pengujian, dapat disimpulkan bahwa perancangan autentikasi Time Based One Time Password (TOTP) MD5 dan Kriptografi AES-CBC 128 bit dapat berjalan baik dalam aplikasi pelaporan. Proses autentikasi mampu menjaga kevaliditasan pengguna dengan adanya pengecekan token yang berbasis waktu, serta amannya pengiriman data dalam proses download data yang telah dirubah ke dalam bentuk ciphertext terlebih dahulu sebelum akhirnya didekripsi kembali untuk ditampilkan dalam aplikasi client. Bahkan hasil yang telah diimplementasikan, telah berhasil melewati performance test dengan penambahan waktu sebesar 7,007 detik dibandingkan dengan performa aplikasi sebelum ditambahkan kriptografi, yang termasuk dalam kategori wajar. Selain itu hasil penelitian juga berhasil mengatasi stress test yang mencapai 10.000 pengguna dalam waktu bersamaan tanpa terjadi error atau crash.

  Untuk pengembangan sistem kedepannya, rancangan sistem keamanan dapat dikembangkan lagi, dengan menggunakan metode autentikasi dan kriptografi terbaru seperti RSA, AES-CTR atau AES-GCM. Selain itu, rancangan sistem juga dapat dikembangkan agar mampu berjalan secara nasional tanpa terkendala perbedaan zona waktu.

  6. Daftar Pustaka

  [1] Franusic, J., 2013. Add Two Factor Authentication to Your Website with Google

  Authenticator and Twilio SMS

  kses pada 12 Oktober 2017. [2] Hadi, D. A., 2017. Pengertian, Penggunaan dan Cara Membuat MD5 Pada

  Pkses pada 12 Oktober 2017.

  [3] Schneier, B., 2009. Another New AES Attack . Diakses pada 12 Oktober 2017. [4] Kowalczyk, C., 2013. Block Cipher Modes of Operationkses pada 12 Oktober 2017.