Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Code
  2. iOS SDK
Code

Mengamankan Data iOS di Rest: Keychain

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Securing iOS Data at Rest.
Securing iOS Data at Rest: Protecting the User's Data
Securing iOS Data at Rest: Encryption

Indonesian (Bahasa Indonesia) translation by ⚡ Rova Rindrata (you can also view the original English article)

Aplikasi apa pun yang menyimpan data pengguna harus menjaga keamanan dan privasi data tersebut. Seperti yang telah kita lihat dengan pelanggaran data terakhir, ada kemungkinan konsekuensi serius karena gagal melindungi data pengguna Anda yang tersimpan. Dalam tutorial ini, Anda akan mempelajari beberapa praktik terbaik untuk melindungi data pengguna Anda.

Di posting sebelumnya, Anda belajar bagaimana melindungi file menggunakan API Data Protection. Perlindungan berbasis file adalah fitur yang ampuh untuk mengamankan penyimpanan data massal. Tapi mungkin berlebihan untuk sejumlah kecil informasi yang harus dilindungi, seperti kunci atau kata sandi. Untuk jenis item ini, keychain adalah solusi yang disarankan.

Layanan Keychain

Keychain adalah tempat yang tepat untuk menyimpan sejumlah kecil informasi seperti string dan ID sensitif yang bertahan meskipun pengguna menghapus aplikasi. Contohnya mungkin merupakan perangkat atau token sesi bahwa server Anda kembali ke aplikasi saat pendaftaran. Entah Anda menyebutnya string rahasia atau token unik, keychain mengacu pada semua item ini sebagai kata sandi.

Ada beberapa perpustakaan pihak ketiga yang populer untuk layanan keychain, seperti Strongbox (Swift) dan SSKeychain (Objective-C). Atau, jika Anda menginginkan kontrol penuh atas kode Anda sendiri, mungkin Anda ingin langsung menggunakan API Keychain Service, yang merupakan API C.

Saya akan menjelaskan secara singkat bagaimana keychain bekerja. Anda bisa menganggap keychain sebagai database khas tempat Anda menjalankan kueri pada tabel. Fungsi dari keychain API semuanya membutuhkan objek CFDictionary yang berisi atribut dari kuerinya.

Setiap entri di keychain memiliki nama layanan. Nama layanan adalah pengenal: kunci untuk nilai apa pun yang ingin Anda simpan atau ambil di keychain. Agar item keychain disimpan hanya untuk pengguna tertentu, Anda juga sering ingin menentukan nama akun.

Karena setiap fungsi keychain menggunakan kamus yang sama dengan banyak parameter yang sama untuk melakukan kueri, Anda dapat menghindari duplikat kode dengan membuat fungsi helper yang mengembalikan kamus kueri ini.

Kode ini mengatur Dictionary kueri dengan nama akun dan layanan Anda dan memberitahukan keychain bahwa kita akan menyimpan kata sandi.

Demikian pula bagaimana Anda dapat mengatur tingkat perlindungan untuk file individual (seperti yang telah kita bahas di posting sebelumnya), Anda juga dapat mengatur tingkat perlindungan untuk item keychain Anda dengan menggunakan kunci kSecAttrAccessible.

Menambahkan Kata Sandi

Fungsi SecItemAdd() menambahkan data ke keychain. Fungsi ini mengambil objek Data, yang membuatnya serbaguna untuk menyimpan berbagai macam objek. Dengan menggunakan fungsi kueri kata sandi yang kami buat di atas, mari menyimpan string di keychain. Untuk melakukan ini, kita hanya perlu mengubah String ke Data.

Menghapus Kata Sandi

Untuk mencegah penyisipan duplikat, kode di atas pertama akan menghapus entri sebelumnya jika ada. Mari kita tulis fungsi itu sekarang. Ini dilakukan dengan menggunakan fungsi SecItemDelete().

Mengambil Kata Sandi

Selanjutnya, untuk mengambil entri dari keychain, gunakan fungsi SecItemCopyMatching(). Ini akan mengembalikan AnyObject yang sesuai dengan kueri Anda.

Dalam kode ini, kita tetapkan parameter kSecReturnData ke kCFBooleanTrue. kSecReturnData berarti data aktual barang akan dikembalikan. Pilihan yang berbeda bisa mengembalikan atribut (kSecReturnAttributes) dari item tersebut. Kuncinya mengambil tipe CFBoolean yang menyimpan konstanta kCFBooleanTrue atau kCFBooleanFalse. Kami menetapkan kSecMatchLimit ke kSecMatchLimitOne sehingga hanya item pertama yang ditemukan di keychain yang akan dikembalikan, dibandingkan dengan jumlah hasil yang tidak terbatas.

Kunci Public dan Private

Keychain juga merupakan tempat yang disarankan untuk menyimpan objek kunci public dan private, misalnya, jika aplikasi Anda bekerja dan perlu menyimpan objek EC atau RSA SecKey.

Perbedaan utamanya adalah bahwa alih-alih memberi tahu keychain untuk menyimpan kata sandi, kita dapat memberitahukannya untuk menyimpan sebuah kunci. Sebenarnya, kita bisa spesifik dengan menetapkan jenis kunci yang tersimpan, seperti apakah itu public atau private. Semua yang perlu dilakukan adalah menyesuaikan fungsi helper kueri agar sesuai dengan jenis kunci yang Anda inginkan.

Kunci umumnya diidentifikasi menggunakan tag domain terbalik seperti com.mydomain.mykey, bukan nama layanan dan akun (karena kunci public dibagi secara terbuka antara perusahaan atau entitas yang berbeda). Kita akan mengambil string layanan dan akun dan mengkonversikannya ke objek Data tag. Misalnya, kode di atas yang disesuaikan untuk menyimpan RSA Private SecKey akan terlihat seperti ini:

Kata Sandi Aplikasi

Item yang diamankan dengan flag kSecAttrAccessibleWhenUnlocked hanya dibuka saat perangkat tidak terkunci, namun bergantung pada pengguna yang memiliki kode akses atau Touch ID yang dipasang di tempat pertama.

Kredensial applicationPassword memungkinkan item dalam keychain diamankan dengan menggunakan kata sandi tambahan. Dengan cara ini, jika pengguna tidak memiliki kode akses atau Touch ID, item akan tetap aman, dan menambahkan lapisan keamanan tambahan jika mereka memiliki kode sandi.

Sebagai contoh skenario, setelah aplikasi Anda mengotentikasi dengan server Anda, server Anda dapat mengembalikan kata sandi melalui HTTPS yang diperlukan untuk membuka item keychain. Ini adalah cara yang disukai untuk memasok kata sandi tambahan itu. Pengkodean manual kata sandi dalam biner tidak disarankan.

Skenario lain mungkin untuk mengambil kata sandi tambahan dari kata sandi yang disediakan pengguna di aplikasi Anda; namun, ini memerlukan lebih banyak pekerjaan untuk mengamankan dengan benar (menggunakan PBKDF2). Kita akan melihat mengamankan password yang disediakan pengguna di tutorial berikutnya.

Penggunaan lain dari kata sandi aplikasi adalah untuk menyimpan kunci sensitif—misalnya, yang tidak ingin Anda lihat hanya karena pengguna belum menyiapkan kode akses.

applicationPassword hanya tersedia di iOS 9 dan di atasnya, jadi Anda memerlukan fallback yang tidak menggunakan applicationPassword jika Anda menargetkan versi iOS yang lebih rendah. Untuk menggunakan kode ini, Anda perlu menambahkan hal berikut ke dalam header bridging Anda:

Kode berikut menetapkan kata sandi untuk kueri Dictionary.

Perhatikan bahwa kami menetapkan kSecAttrAccessControl pada Dictionary. Ini digunakan sebagai pengganti kSecAttrAccessible, yang sebelumnya ditetapkan dalam metode passwordQuery kita. Jika Anda mencoba menggunakan keduanya, Anda akan mendapatkan kesalahan OSStatus -50.

Otentikasi Pengguna

Berawal dari iOS 8, Anda dapat menyimpan data di keychain yang hanya dapat diakses setelah pengguna berhasil mengotentikasi perangkat dengan Touch ID atau kode sandi. Bila sudah saatnya pengguna melakukan otentikasi, Touch ID akan diprioritaskan jika sudah diatur, jika tidak, layar passcode akan ditampilkan. Menyimpan ke keychain tidak akan mengharuskan pengguna untuk melakukan otentikasi, namun mengambil data akan membutuhkannya.

Anda dapat mengatur item keychain untuk meminta otentikasi pengguna dengan menyediakan objek kontrol akses yang disetel ke .userPresence. Jika tidak ada kode sandi yang disiapkan maka permintaan keychain apapun dengan .userPresence akan gagal.

Fitur ini bagus bila Anda ingin memastikan aplikasi Anda digunakan oleh orang yang tepat. Misalnya, penting bagi pengguna untuk melakukan otentikasi sebelum dapat masuk ke aplikasi perbankan. Ini akan melindungi pengguna yang telah membiarkan perangkat mereka tidak terkunci, sehingga perbankan tidak dapat diakses.

Selain itu, jika Anda tidak memiliki komponen sisi server ke aplikasi Anda, Anda dapat menggunakan fitur ini untuk melakukan otentikasi sisi perangkat.

Untuk kueri pemuatan, Anda dapat memberikan deskripsi mengapa pengguna perlu melakukan otentikasi.

Saat mengambil data dengan SecItemCopyMatching(), fungsi akan menampilkan UI otentikasi dan menunggu pengguna menggunakan Touch ID atau memasukkan kode akses. Karena SecItemCopyMatching() akan memblokir sampai pengguna selesai melakukan otentikasi, Anda perlu memanggil fungsi dari thread latar belakang agar thread UI utama tetap responsif.

Sekali lagi, kita menetapkan kSecAttrAccessControl pada Dictionary kueri. Anda perlu menghapus kSecAttrAccessible, yang sebelumnya ditetapkan dalam metode passwordQuery kita. Menggunakan keduanya sekaligus akan menghasilkan kesalahan OSStatus -50.

Kesimpulan

Pada artikel ini, Anda telah mengunjungi API Keychain Services. Seiring dengan API Data Protection yang kita lihat di posting sebelumnya, penggunaan perpustakaan ini adalah bagian dari praktik terbaik untuk mengamankan data.

Namun, jika pengguna tidak memiliki passcode atau Touch ID pada perangkat, tidak ada enkripsi untuk kedua kerangka tersebut. Karena API Keychain Services dan Data Protection biasanya digunakan oleh aplikasi iOS, terkadang mereka ditargetkan oleh penyerang, terutama pada perangkat jailbroken. Jika aplikasi Anda tidak bekerja dengan informasi yang sangat sensitif, ini mungkin merupakan risiko yang dapat diterima. Sementara iOS terus mengupdate keamanan kerangka kerjanya, kita masih berada dalam belas kasihan pengguna yang mengupdate OS, menggunakan kode akses yang kuat, dan tidak melakukan jailbreaking perangkat mereka.

Keychain dimaksudkan untuk potongan data yang lebih kecil, dan Anda mungkin memiliki jumlah data yang lebih besar untuk mengamankan yang tidak tergantung pada otentikasi perangkat. Sementara pembaruan iOS menambahkan beberapa fitur baru yang hebat seperti kata sandi aplikasi, Anda mungkin masih perlu untuk mendukung versi iOS yang lebih rendah dan masih memiliki keamanan yang kuat. Untuk beberapa alasan ini, Anda mungkin ingin mengenkripsi data Anda sendiri.

Artikel terakhir dalam seri ini mencakup mengenkripsi data Anda dengan menggunakan enkripsi AES, dan walaupun ini adalah pendekatan yang lebih maju, ini memungkinkan Anda memiliki kontrol penuh atas bagaimana dan kapan data Anda dienkripsi.

Jadi nantikanlah. Dan sementara itu, periksa beberapa posting kami yang lain mengenai pengembangan aplikasi iOS!

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.