Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. iOS SDK
Code

Mengamankan Data iOS: Enkripsi

by
Difficulty:AdvancedLength:LongLanguages:
This post is part of a series called Securing iOS Data at Rest.
Securing iOS Data at Rest: The Keychain

Indonesian (Bahasa Indonesia) translation by Husain Ali Yahya (you can also view the original English article)

Pada kiriman ini, kita akan melihat penggunaan lebih lanjut dari eknripsi untuk data pengguna di aplikasi iOS. Kita mulai dengan penampakkan tingkat tinggi dari enkripsi AES, lalu melihat beberapa contoh cara mengimplementasikan enkripsi AES di Swift.

Pada kiriman terakhir, kamu telah belajar cara menyimpan data menggunakan keychain, yang bagus untuk bagian kecil dari informasi seperti, keys, password, dan certificates.

Jika kamu menyimpan banyak data kostum yang ingin hanya tersedia setelah pengguna atau perangkat terotentikasi, maka lebih baik mengenkripsi data-nya menggunakan sebuah framework enkripsi. Contohnya, kamu bisa memiliki sebuah aplikasi yang bisa mengarsipkan pesan pribadi yang disimpan oleh pengguna atau foto pribadi yang diambil oleh pengguna, atau yang bisa menyimpan detil keuangan pengguna. Pada kasus tersebut, kamu mungkin ingin menggunakan enkripsi.

Ada dua alur umum di aplikasi untuk enkripsi dan dekripsi data dari aplikasi iOS. Baik penggunanya ditampilkan dengan sebuah layar kata sandi, atau aplikasi-nya diotentikasi dengan sebuah server yang mengembalikan sebuah kunci untuk dekripsi data-nya.

Tidak pernah menjadi sebuah ide yang bagus untuk menciptakan roda-nya ketika berbicara tentang enkripsi. Maka, kita akan menggunakan standar AES yang disediakan oleh pustaka Common Crypto iOS.

AES

AES adalah sebuah standar yang mengenkripsi data yang diberikan sebuah key. Key yang sama digunakan untuk mengenkripsi data yang digunakan untuk mendekripsi data-nya. Ada berbagai ukuran key berbeda dan AES256 (256 bits) panjang yang diminati untuk digunakan dengan data sensitif.

RNCryptor adalah sebuah pembungkus enkripsi populer untuk iOS yang mendukung AES. RNCryptor adalah pilihan yang bagus karena dia siap dan berjalan dengan sangat cepat tanpa perlu khawatir mengenai detil-detil yang mendasari. Dia juga open source sehingga ilmuwan keamanan bisa menganalisan dan mengaudit kode-nya.

Di sisi lain, jika aplikasi-mu mengurusi informasi sensitif dan kamu pikir aplikasimu akan ditarget dan di-crack, kamu mungkin ingin menulis solusi-mu sendiri. Alasan untuk ini adalah karena saat banyak aplikasi menggunakan kode yang sama, dia bisa membuat pekerjaan hacker menjadi lebih mudah, mengizinkan mereka untuk menulis sebuah aplikasi cracking yang menemukan pola umum di dalam kode-nya dan menerapkan patch pada mereka.

Ingat, bahwa menulis solusi--mu sendiri hanya memperlambar seorang penyerang dan mencegah serangan otomatis. Perlindungan yang kamu dapat dari implementasi-mu sendiri adalah bahwa seorang hacker akan butuh beberapa waktu dan dedikasi saat meng-crack aplikasimu.

Baik kamu memilih sebuah solusi pihak ketiga atau memilih untuk membuat milikmu sendiri, penting untuk tahu mengenai cara kerja sistem enkripsi. Dengan begitu, kamu bisa memutuskan jika sebuah framework tertentu yang ingin kamu gunakan benar-benar aman. Maka, sisas dari panduan ini akan fokus pada penulisan solusi kostum-mu sendiri. Dengan pengetahuan yang akan kamu pelajari dari panduan ini, kamu akan bisa memberitahu jika kamu menggunakan framework tertentu secara aman.

Kita akan mulai dengan pembuatan sebuah secret key yang akan digunakan untuk mengenkripsi data-mu.

Buat sebuah Key

Sebuah error yang paling umum pada enkripsi AES adalah untuk menggunakan sebuah password pengguna secara langsung sebagai kunci enkripsi. Bagaimana jika penggunanya memutuskan untuk menggunakan sebuah password yang biasa atau lemah? Bagaiaman kita memaksa pengguna menggunakan sebuah key yang acak dan cukup kuat (memiliki entropi yang cukup) untuk enkripsi dan membuat mereka mengingatnya?

Solusi-nya adalah key stretching. Key strecthing menurunkan sebuah key dari sebuah password dengan hashing berkali-kali dengan sebuah garam. Salt (garam) hanya urutan dari data acak, dan alah sebuah kesalahan umum untuk mengabaikan garam ni - garamnya memberi kunci-nya entropy yang sangat penting, dan tanpa garamnya kunci yang sama bisa diturunkan jika password yang sama pernah digunakan oleh seseorang sebelumnya.

Tanpa garamnya, sekumpulan kata bisa digunakan untuk menyimpulkan keys yang umum yang bisa digunakan untuk menyerang data pengguna. Ini disebut dengan "dictionary attack". Tabel-tabel dengan keys umum yang berhubungan dengan password yang tidak bergaram digunakan untuk mencapainya. Mereka disebut "rainbow tables".

Jebakan lain saat membuat garam adalah penggunaan angka acak yang membuat fungsi yang tidak didesain untuk keamanan. Contohnya adalah fungsi rand() di C yang bisa diakses melalui Swift. Keluarannya bisa sangat mudah ditebak!

Untuk membuat garam yang aman, kita akan menggunakan fungsi SecRandomCopyBytes untuk membuat bytes acak yang aman secara kriptografis-yaitu angka-angka yang sulit untuk ditebak.

Untuk menggunakan kodenya, kamu perlu menambahkan hal berikut ke header yang menjembatani:
#import <CommonCrypto/CommonCrypto.h>

Ini adalah awal dari kode yang akan membuat garam. Kita akan menambahkannya ke kode seiring berjalan di panduan ini:

Sekarang kita siap untuk melakukan key strecthing. Untungnya kita telah memiliki sebuah fungsi di pembuangan kita untuk melakukan stetching yang sebenarnya: Password-Based Key Derivation Function (PBKDF2). PBKDF2 menjalankan sebuah fungsi berkali-kali untuk menurunkan key-nya; meningkatkan jumlah pengulangan yang meningkatkan waktu yang digunakan untuk beroperasi pada seperangkat key selama serangan paksa yang kasar. Sangat direkomendasikan untuk menggunakan PBKDF2 untuk membuat key-mu.

Server-Side Key

Kamu mungkin sekarang bertanya-tanya mengenai kasus-kasus di mana kamu tidak ingin meminta password ke pengguna aplikasimu. Mungkin mereka telah terotentikasi menggunakan skema single sign-on. Dalam kasus ini, buat server-mu membuat sebuah AES 256-bit (32 byte) key menggunakan sebuah generator yang aman. Key-nya harus berbeda untuk pengguna dan perangkat yang berbeda. Saat mengotentikasikan servermu, kamu bisa melewatkan server-nya sebuah perangkat atau user ID melalui koneksi aman, dan dia bisa mengirim kode-nya kembali.

Skema ini memiliki perbedaan yang besar. Jika key-nya berasal dari server, entitas yang mengontrol server-nya memiliki kapasitas untuk membaca data yang terenkripsi jika perangkat atau data-nya pernah diraih. Ada juga kemungkinan key-nya bocor atau terekspos suatu saat nanti.

Di sisi lain, jika key-nya diturunkan dari sesuatu yang hanya diketahui pengguna-password pengguna-maka hanya pengguna yang bisa mendekrip kan data tersebut. Jika kamu melindungi informasi seperti data keuangan pribadi, cukup pengguna-nya yang bisa membuka kunci data-nya. Jika informasi tersebut diketahui ke entitas, itu bisa diterima untuk membuat server-nya membuka kunci konten-nya melalui sebuah server-side key.

Modes dan IVs

Sekarang kita memiliki sebuah key, mari enkripsi beberapa data. Ada beberapa mode enkripsi, tapi kita akan menggunakan mode yang direkomendasikan: cipher block chaining (CBC). Ini mengoperasikan data satu blok kita sekaligus.

Jebakan yang umum dengan CBC adalah fakta bahwa blok data tidak terenkripsi berikutnya adalah XOR'd dengan blok terenkripsi sebelumnya untuk membuat enkripsi-nya lebih kuat. Masalahnya di sini adalah blok pertama tidak pernah seunik yang lainnya. Jika sebuah pesan untuk dienkripsi dimulai bersama dengan pesan lain yang ingin dienkripsi, awalan dari keluaran yang dienkripsi akan sama dan akan memberikan penyerang sebuah petunjuk untuk menebak seperti apa pesannya.

Untuk mengatasi kelemahan potensial ini, kita akan mulai data-nya untuk disimpan dengan sesuatu yang disebut sebuah initialization vector (IV): sekumpulan bytes acak. IV-nya akan menjadi XOR'd dengan baris blok pertama dari data pengguna, dan karena tiap blok bergantung pada setiap blok di atasnya hingga poin tersebut. Dia akan memastikan bahwa seluruh pesan-nya akan dienkripsi secara unik bahkan jika dia memiliki data yang sama sepert pesan yang lainnya. Dengan kata lain, pesan mirip yang dienkripsi dengan key yang sama tidak akan menghasilkan hasil yang identik. Jadi sementara garam dipertimbangkan publik, mereka harus tidak berurutan atau digunakan kembali.

Kita akan menggunakan fungsi SecRandomCopyBytes aman yang sama untuk membuat IV-nya.

Menyatukan Semua-nya

Untuk melengkapi contoh kita, kita akan menggunakan fungsi CCCrypt baik dengan kCCEncrypt atau kCCDecrypt. Karena kita menggunakan sebuah block cipher, jika pesannya tidak cocok dengan baik ke aneka ukuran blok, kita harus memberi tahu fungsi-nya untuk secara otomatis menambahkan lapisan ke bagian akhirnya.

Seperti yang biasanya dienkripsi, akan sangat baik untuk mengikuti standar yang telah ada. Pada kasus ini, standar PKCS7 menentukan cara melapisi data-nya. Kita akan memberitahu fungsi enkripsi kita untuk menggunakan standar ini dengan menyediakan opsi KCCOptionPKCS7Padding. Menyatukan semuanya, ini adalah kode lengkap untuk enkripsi dan dekripsi sebuah string.

Dan ini adalah kode dekripsinya:

Akhirnya, ini adalah seuah kode untuk memastikan data-nya didekripsikan dengan benar setelah enkripsi:

Pada contoh kita, kita membungkus semua informasi yang dibutuhkan dan mengembalikannya sebagai Dictionary sehingga semua bagiannya bisa digunakan nanti untuk mendekripsi data secara tepat. Kamu hany perlu menyimpan IV dan garam-nya, baik di keychain-nya atau di server-mu.

Kesimpulan

Ini melengkapi tiga-seri dari mengamankan data. Kita telah melihat cara menyimpan password, bagian sensitif informasi, dan banyak data pengguna secar tepat. Teknik-teknik ini adalah dasar untuk melindungi data informasi pengguna di aplikasimu,

Adalah sebuah resiko yang besar ketika perangkat pengguna hilang atau dicuri terutama dengan eksploitasi terbaru untuk mendapat akses ke perangkat terkunci. Walau banyak kerentanan ditambal melalui pembaruan perangkat lunak, perangkat-nya sendiri hanya seaman kata sandi pengguna dan versi dari iOS. Oleh karenanya, ini terserah pengembang dari tiap aplikasi untuk menyediakan perlindungan kuat dari data sensitif yang disimpan.

Semua topik yang dibahas sejauh ini menggunakan framework Apple. Saya akan meninggalkan sebuah ide untuk kamu pikirkan. Apa yang terjadi ketika pustaka enkripsi Apple diserang?

Ketika arsitektur keamanan yang biasa digunakan dikompromi, maka semua aplikasi yang bergantung padanya juga dikompromi. Pustaka iOS manapun yang tertaut secara dinamis, terutama diperangkat jailbreak, bisa ditambal dan diganti dengan yang berbahaya.

Namun, sebuaj pustaka statis yang dibundel dengan binary dari aplikasi-mu terlindungi dari serangan macam ini karena jika kamu mencoba dan menambalnya, kamu akan berakhir dengan mengganti binary aplikasinya. Ini akan menghancurkan code signature aplikasinya, mencegah aplikasi-nya diluncurkan. Jika kamu mengimpor dan menggunakan, contohnya, OpenSSL untuk enkripsimu, aplikasimu tidak akan rentan ke aneka serangan Apple API. Kamu bisa mengompilasi OpenSSL oleh dirimu sendiri dan menautkannya secara statis ke aplikasimu.

Jadi selalu ada sesuatu untuk dipelajari, dan masa depan dari keamanan aplikasi di iOS selalu berkembang. Bahkan arsitektur keamanan iOS mendukung perangkat kriptografis dan kartu cerdas! Sebagai penutup, sekarang kamu tahu cara terbaik untuk mengamankan data yang tidak bergerak, sekarang terserah kamu untuk mengikutinya atau tidak!

Di waktu luang, cek-lah konten lain kami mengenai pengembangan aplikasi iOS dan keamanan aplikasi.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.