Keamanan ios ios 9.3 atau lebih baru. Mei 2016

Keamanan iOS

iOS 9.3 atau lebih baru Mei 2016

Konten Halaman 4

Pengantar

Halaman 5

Keamanan Sistem Rantai boot aman Pengesahan Perangkat Lunak Sistem Enklave Aman Touch ID

Halaman 10

Enkripsi dan Perlindungan Data Fitur keamanan perangkat keras Perlindungan Data File Kode Sandi Kelas Perlindungan Data Perlindungan Data Rantai Kunci Akses ke kata sandi yang disimpan Safari Kantong Kunci Sertifikasi Keamanan dan program

Halaman 19

Keamanan App Penandatanganan kode app Keamanan proses runtime Ekstensi Grup App Perlindungan Data di app Aksesori HomeKit HealthKit Catatan Aman Apple Watch

Halaman 29 Keamanan Jaringan TLS VPN Wi-Fi Bluetooth Masuk Tunggal Keamanan AirDrop Halaman 33

Apple Pay Komponen Apple Pay Bagaimana Apple Pay menggunakan Elemen Aman Bagaimana Apple Pay menggunakan pengontrol NFC Penyediaan kartu kredit dan debit Pengesahan pembayaran Kode keamanan dinamis khusus transaksi Pembayaran nirkontak dengan Apple Pay Membayar dengan Apple Pay di dalam app Kartu hadiah Menangguhkan, menghapus, dan membersihkan kartu

Keamanan iOS—Buku Putih | Mei 2016

2

Halaman 40 Layanan Internet ID Apple iMessage FaceTime iCloud Rantai Kunci iCloud Siri Berkelanjutan Saran Spotlight Halaman 54 Kontrol Perangkat Perlindungan kode sandi Model pemasangan iOS Pemberlakuan konfigurasi Mobile device management (MDM) iPad Bersama Apple School Manager Pendaftaran Perangkat Apple Configurator 2 Pengawasan Pembatasan Penghapusan Jarak Jauh Mode Hilang Kunci Aktivasi Halaman 61

Kontrol Privasi Layanan Lokasi Akses data pribadi Kebijakan privasi

Halaman 62 Kesimpulan Komitmen terhadap keamanan Halaman 63 Glosarium Halaman 65 Riwayat Revisi Dokumen


3

Pengantar

Kelas Perlindungan Data

Sandbox App

Perangkat Lunak

Partisi Pengguna (Dienkripsi)

Partisi OS Sistem File

Kernel Enklave Aman

Elemen Aman

Perangkat Keras dan Firmware Mesin Kripto

Apple merancang platform iOS dengan mengutamakan keamanan. Saat kami memutuskan untuk membuat platform bergerak terbaik, kami bersandar pada pengalaman puluhan tahun untuk membuat arsitektur yang baru seutuhnya. Kami mengkaji bahaya keamanan lingkungan desktop, dan membangun pendekatan baru terhadap keamanan dalam rancangan iOS. Kami mengembangkan dan menggabungkan fitur inovatif yang memperketat keamanan bergerak dan melindungi keseluruhan sistem secara default. Hasilnya, iOS menjadi terobosan besar di bidang keamanan untuk perangkat bergerak. Setiap perangkat iOS menggabungkan perangkat lunak, perangkat keras, dan layanan yang dirancang untuk berfungsi secara berdampingan untuk keamanan maksimum dan pengalaman pengguna yang transparan. iOS tidak hanya melindungi perangkat dan datanya, tapi juga keseluruhan ekosistem, meliputi semua hal yang dilakukan pengguna di perangkat, jaringan, dan dengan layanan Internet utama. iOS dan perangkat iOS menyediakan fitur keamanan lanjutan, tapi mudah digunakan. Banyak dari fitur ini yang diaktifkan secara default, sehingga bagian TI tidak perlu melakukan konfigurasi ekstensif. Selain itu, fitur keamanan utama seperti enkripsi perangkat tidak dapat dikonfigurasi, sehingga pengguna tidak dapat menonaktifkannya secara tidak sengaja. Fitur lainnya, seperti Touch ID, meningkatkan pengalaman pengguna dengan membuat pengamanan perangkat lebih mudah dan intuitif. Dokumen ini menyediakan detail mengenai bagaimana fitur dan teknologi keamanan diterapkan di dalam platform iOS. Dokumen ini juga membantu organisasi menggabungkan fitur dan teknologi keamanan platform iOS dengan kebijakan dan prosedur mereka sendiri untuk memenuhi kebutuhan keamanan mereka. Dokumen ini dibagi ke dalam topik pembahasan berikut:

Kunci Perangkat Kunci Grup Sertiﬁkat Dasar Apple

Diagram arsitektur keamanan iOS menyediakan tinjauan visual dari teknologi lain yang dibahas dalam dokumen ini.

• Keamanan sistem: Perangkat lunak dan perangkat keras terpadu dan aman yang merupakan platform bagi iPhone, iPad, dan iPod touch. • Enkripsi dan perlindungan data: Arsitektur dan rancangan yang melindungi data pengguna jika perangkat hilang atau dicuri, atau jika orang yang tidak berwenang mencoba menggunakan atau memodifikasinya. • Keamanan app: Sistem yang memungkinkan app untuk dijalankan dengan aman dan tanpa merusak integritas platform. • Keamanan jaringan: Protokol jaringan standar industri yang menyediakan pengesahan dan enkripsi data yang aman pada saat transmisi. • Apple Pay: Penerapan pembayaran aman oleh Apple. • Layanan internet: Infrastruktur berbasis jaringan milik Apple untuk pemrosesan pesan, penyelarasan, dan pencadangan. • Kontrol perangkat: Metode yang memungkinkan pengelolaan perangkat iOS, mencegah penggunaan yang tidak sah, dan mengaktifkan penghapusan jarak jauh jika perangkat hilang atau dicuri. • Kontrol privasi: Fitur iOS yang dapat digunakan untuk mengontrol akses ke Layanan Lokasi dan data pengguna.


4

Keamanan Sistem Memasuki mode Peningkatan Firmware Perangkat (DFU) Jika dipulihkan setelah memasuki mode DFU, perangkat akan kembali ke kondisi baik yang diketahui sambil memastikan bahwa hanya ada kode bertanda tangan Apple yang tidak dimodifikasi. Mode DFU dapat dimasuki secara manual: Pertama-tama, sambungkan perangkat ke komputer menggunakan kabel USB, lalu tahan tombol Utama dan Tidur/Bangun. Setelah 8 detik, lepaskan tombol Tidur/ Bangun sambil tetap menahan tombol Utama. Catatan: Tidak ada yang akan ditampilkan di layar saat perangkat dalam mode DFU. Jika logo Apple muncul, berarti tombol Tidur/Bangun ditahan terlalu lama.

Keamanan sistem dirancang sehingga perangkat keras dan lunak menjadi aman di semua komponen utama dari setiap perangkat iOS. Ini meliputi proses boot-up, pembaruan perangkat lunak, dan Enklave Aman. Arsitektur ini penting bagi keamanan di iOS, dan tidak menghalangi kebergunaan perangkat. Integrasi ketat antara perangkat lunak dan perangkat keras pada perangkat iOS memastikan bahwa tiap komponen sistem tepercaya, dan memvalidasi sistem secara keseluruhan. Dari boot-up awal hingga pembaruan perangkat lunak iOS hingga app pihak ketiga, setiap langkah dianalisis dan dikaji untuk membantu memastikan bahwa perangkat keras dan lunak berfungsi bersamaan secara optimal dan menggunakan sumber dengan benar.

Rantai boot aman Setiap langkah dari proses mulai berisi komponen yang ditandatangani oleh Apple secara kriptografis untuk memastikan integritas dan bahwa proses dilanjutkan setelah rantai kepercayaan terverifikasi. Ini meliputi bootloader, kernel, ekstensi kernel, dan firmware pita dasar. Saat perangkat iOS dinyalakan, prosesor aplikasinya akan langsung menjalankan kode dari memori hanya baca yang dikenal sebagai ROM Boot. Kode tetap ini, yang dikenal sebagai dasar kepercayaan pada perangkat keras, diterapkan pada saat pembuatan keping, dan tepercaya secara implisit. Kode ROM Boot berisi kunci publik CA Dasar Apple, yang digunakan untuk memverifikasi bahwa Bootloader Tingkat Rendah (LLB) ditandatangani oleh Apple sebelum mengizinkannya dimuat. Ini adalah langkah pertama dalam rantai kepercayaan yang setiap langkahnya memastikan bahwa langkah berikutnya ditandatangani oleh Apple. Setelah LLB menyelesaikan tugasnya, LLB akan memverifikasi dan menjalankan bootloader tahap berikutnya, iBoot, yang pada gilirannya akan memverifikasi dan menjalankan kernel iOS. Rantai boot aman ini membantu memastikan bahwa level terendah dari perangkat lunak tidak dirusak dan memungkinkan iOS untuk hanya dijalankan di perangkat Apple yang sah. Untuk perangkat dengan akses seluler, subsistem pita dasar juga menggunakan proses yang mirip berupa boot aman dengan perangkat dan kunci bertanda tangan yang diverifikasi oleh prosesor pita dasar. Untuk perangkat dengan prosesor A7 atau seri A yang lebih baru, koprosesor Enklave Aman juga menggunakan proses boot aman yang memastikan bahwa perangkat lunaknya yang terpisah diverifikasi dan ditandatangani oleh Apple. Jika satu langkah dari proses boot ini tidak dapat memuat atau memverifikasi proses berikutnya, proses mulai akan berhenti dan perangkat akan menampilkan layar “Sambungkan ke iTunes.” Ini disebut mode pemulihan. Jika ROM Boot tidak dapat memuat atau memverifikasi LLB, ROM Boot akan masuk ke mode DFU (Peningkatan Firmware Perangkat). Di kedua kasus, perangkat harus disambungkan ke iTunes melalui USB dan dipulihkan ke pengaturan pabrik default. Untuk informasi lainnya mengenai cara masuk ke mode pemulihan secara manual, lihat support.apple.com/kb/HT1808?viewlocale=id_ID.


5

Pengesahan Perangkat Lunak Sistem Apple merilis pembaruan perangkat lunak secara berkala untuk menanggulangi masalah keamanan yang muncul dan juga menyediakan fitur baru; pembaruan ini disediakan bagi semua perangkat yang didukung secara bersamaan. Pengguna menerima pemberitahuan pembaruan iOS di perangkat dan melalui iTunes, dan pembaruan dikirimkan secara nirkabel, mendorong penerapan perbaikan keamanan terbaru dengan cepat. Proses mulai yang dijelaskan di atas membantu memastikan bahwa hanya kode yang ditandatangani Apple yang dapat diinstal di perangkat. Untuk mencegah perangkat diturunkan ke versi lebih lama yang tidak memiliki pembaruan keamanan terbaru, iOS menggunakan proses yang disebut Pengesahan Perangkat Lunak Sistem. Jika penurunan versi dimungkinkan, penyerang yang mendapatkan perangkat dapat menginstal versi iOS yang lebih lama dan memanfaatkan kerentanan yang telah diperbarui di versi yang lebih baru. Di perangkat dengan prosesor A7 atau seri A yang lebih baru, koprosesor Enklave Aman juga menggunakan Pengesahan Perangkat Lunak Sistem untuk memastikan integritas perangkat lunaknya dan mencegah penginstalan penurunan versi. Lihat “Enklave Aman,” di bawah. Pembaruan perangkat lunak iOS dapat diinstal menggunakan iTunes atau secara nirkabel (OTA) di perangkat. Dengan iTunes, salinan lengkap dari iOS akan diunduh dan diinstal. Pembaruan perangkat lunak OTA hanya mengunduh komponen yang diperlukan untuk menyelesaikan pembaruan untuk meningkatkan efisiensi jaringan, bukan untuk mengunduh keseluruhan OS. Selain itu, pembaruan perangkat lunak dapat dibuat cache di server jaringan lokal yang menjalankan layanan cache di OS X Server sehingga perangkat iOS tidak perlu mengakses server Apple untuk mendapatkan data pembaruan yang diperlukan. Selama peningkatan iOS, iTunes (atau perangkat itu sendiri, pada kasus pembaruan perangkat lunak OTA) terhubung ke server pengesahan penginstalan Apple dan mengirimkan tindakan pengamanan kriptografis untuk setiap bagian bundel penginstalan yang akan diinstal (misalnya, LLB, iBoot, kernel, dan image OS), nilai anti-pemutaran ulang acak (nilai sekali pakai), dan ID unik perangkat (ECID). Server pengesahan membandingkan daftar tindakan pengamanan yang disediakan dengan versi yang diizinkan untuk penginstalan dan, jika menemukan kecocokan, akan menambahkan ECID ke tindakan pengamanan dan menandatangani hasilnya. Server meneruskan kumpulan lengkap data yang ditandatangani ke perangkat sebagai bagian dari proses peningkatan. Dengan menambahkan ECID, pengesahan untuk perangkat yang diminta menjadi bersifat "khusus". Dengan hanya mengesahkan dan menandatangani tindakan pengamanan yang diketahui, server memastikan bahwa pembaruan dilakukan sebagaimana mestinya oleh Apple. Evaluasi rantai kepercayaan pada saat boot memverifikasi bahwa tanda tangan berasal dari Apple dan tindakan pengamanan item yang dimuat dari disk, beserta ECID perangkat, cocok dengan yang tercakup oleh tanda tangan. Langkah ini memastikan bahwa pengesahan ditujukan kepada perangkat tertentu dan versi iOS yang lebih lama dari satu perangkat tidak dapat disalin ke perangkat lain. Nilai sekali pakai mencegah penyerang untuk menyimpan respons server dan menggunakannya untuk merusak perangkat atau mengubah perangkat lunak sistem.


6

Enklave Aman Enklave Aman adalah koprosesor yang digabungkan ke prosesor A7 Apple atau seri A yang lebih baru. Enklave Aman menggunakan memori terenkripsi dan disertai dengan pembuat nomor acak perangkat keras. Teknologi ini menyediakan semua operasi kriptografis untuk manajemen kunci Perlindungan Data dan menjaga integritas Perlindungan Data bahkan jika kernel telah rusak. Komunikasi antara Enklave Aman dan prosesor aplikasi diisolasi di kotak mail berbasis interupsi dan buffer data memori bersama. Enklave Aman dijalankan di mikrokernel L4 versi khusus Apple. Enklave Aman memanfaatkan boot amannya sendiri dan dapat diperbarui menggunakan proses pembaruan perangkat lunak khusus yang terpisah dari prosesor aplikasi. Setiap Enklave Aman diberikan selama produksi dengan UID (ID Unik) masing-masing yang tidak dapat diakses oleh bagian sistem lainnya dan tidak diketahui oleh Apple. Saat perangkat dimulai, kunci jangka pendek dibuat, dikaitkan dengan UID-nya, dan digunakan untuk mengenkripsi bagian ruang memori perangkat milik Enklave Aman. Selain itu, data yang disimpan ke sistem file oleh Enklave Aman dienkripsi dengan kunci yang dikaitkan dengan UID dan penghitung anti-pemutaran ulang. Enklave Aman bertanggung jawab dalam pemrosesan data sidik jari dari sensor Touch ID, menetapkan apakah terdapat kecocokan dengan sidik jari terdaftar, dan kemudian mengaktifkan akses atau pembelian atas nama pengguna. Komunikasi antara prosesor dan sensor Touch ID berlangsung di bus antarmuka periferal serial. Prosesor meneruskan data ke Enklave Aman tapi tidak dapat membacanya. Data dienkripsi dan disahkan dengan kunci sesi yang dinegosiasikan menggunakan kunci bersama perangkat, yang disediakan untuk sensor Touch ID dan Enklave Aman. Kunci sesi menggunakan bungkus kunci AES yang kedua sisinya menyediakan kunci acak yang membuat kunci sesi dan menggunakan enkripsi transpor AES-CCM.

Touch ID Touch ID adalah sistem sensor sidik jari yang membuat akses aman ke perangkat menjadi lebih cepat dan lebih mudah. Teknologi ini membaca data sidik jari dari semua sudut dan mempelajari sidik jari pengguna lebih lanjut seiring waktu, sementara sensor terus memperluas peta sidik jari dengan bertambahnya node tumpang tindih tambahan yang teridentifikasi dengan setiap penggunaan. Touch ID membuat penggunaan kode sandi yang lebih kompleks dan panjang menjadi lebih praktis karena pengguna tidak harus memasukkannya sesering biasanya. Touch ID juga menanggulangi masalah kunci berbasis kode sandi yang tidak praktis, tidak dengan menggantinya, namun dengan menyediakan akses dengan aman ke perangkat di dalam batas yang menyeluruh dan rentang waktu tertentu.

Touch ID dan kode sandi

Untuk menggunakan Touch ID, pengguna harus mengatur perangkat mereka sehingga kode sandi diperlukan untuk membukanya. Saat Touch ID memindai dan mengenali sidik jari terdaftar, perangkat akan membuka tanpa meminta kode sandi perangkat. Kode selalu dapat digunakan sebagai ganti Touch ID, dan masih diperlukan dalam kondisi berikut: • Perangkat baru dinyalakan atau dimulai ulang. • Perangkat belum dibuka selama lebih dari 48 jam. • Kode sandi belum digunakan untuk membuka perangkat dalam enam hari terakhir dan Touch ID belum membuka perangkat dalam delapan jam terakhir.


7

• Perangkat telah menerima perintah penguncian jarak jauh. • Setelah lima upaya gagal untuk mencocokkan sidik jari. • Saat mengatur atau mendaftarkan sidik jari baru dengan Touch ID. Jika Touch ID dinyalakan, perangkat akan langsung terkunci saat tombol Tidur/Bangun ditekan. Dengan keamanan hanya kode sandi, banyak pengguna yang mengatur masa tenggang pembukaan agar tidak harus memasukkan kode sandi setiap kali perangkat digunakan. Dengan Touch ID, perangkat akan terkunci setiap kali tidur, dan memerlukan sidik jari—atau kode sandi jika dipilih—setiap kali bangun. Touch ID dapat dilatih untuk mengenali maksimum lima sidik jari yang berbeda. Untuk setiap satu jari yang didaftarkan, kemungkinan adanya kecocokan acak dengan orang lain adalah 1 banding 50.000. Namun, Touch ID hanya mengizinkan lima upaya gagal saat mencocokkan sidik jari sebelum pengguna diharuskan untuk memasukkan kode sandi untuk mendapatkan akses.

Fungsi lain Touch ID

Touch ID juga dapat dikonfigurasi untuk menyetujui pembelian dari iTunes Store, App Store, dan iBooks Store, sehingga pengguna tidak harus memasukkan kata sandi ID Apple. Saat mereka memilih untuk mengesahkan pembelian, token pengesahan ditukar antara perangkat dan toko. Token dan nilai sekali pakai kriptografis disimpan di Enklave Aman. Nilai sekali pakai dengan kunci Enklave Aman dibagikan oleh semua perangkat dan iTunes Store. Touch ID juga dapat digunakan dengan Apple Pay, yang merupakan penerapan pembayaran aman milik Apple. Untuk informasi lainnya, lihat bagian Apple Pay dari dokumen ini. Selain itu, app pihak ketiga dapat menggunakan API yang disediakan sistem untuk meminta pengguna mengesahkan penggunaan Touch ID atau kode sandi. App hanya diberi tahu mengenai apakah pengesahan berhasil; app tidak dapat mengakses Touch ID atau data yang dikaitkan dengan sidik jari terdaftar. Item rantai kunci juga dapat dilindungi dengan Touch ID, sehingga hanya dapat dirilis oleh Enklave Aman dengan kecocokan sidik jari atau kode sandi perangkat. Pengembang app juga memiliki API untuk memverifikasi bahwa kode sandi telah diatur oleh pengguna dan, oleh karena itu, dapat mengesahkan atau membuka item rantai kunci menggunakan Touch ID. Dengan iOS 9, pengembang dapat mengharuskan operasi API Touch ID untuk tidak kembali menggunakan kata sandi aplikasi atau kode sandi perangkat. Selain kemampuan untuk memperoleh representasi status sidik jari terdaftar, ini memungkinkan Touch ID untuk digunakan sebagai faktor kedua dalam app yang sensitif terhadap keamanan.

Keamanan Touch ID

Sensor sidik jari hanya aktif saat lingkaran baja kapasitif yang mengelilingi tombol Utama mendeteksi sentuhan jari, yang memicu larik pencitraan mutakhir untuk memindai jari dan mengirimkan pindaian ke Enklave Aman. Pindaian raster disimpan untuk sementara di memori terenkripsi di dalam Enklave Aman saat dibuatkan vektor untuk dianalisis, lalu dihapus. Analisis menggunakan pemetaan sudut alur kerutan subdermal, yaitu proses tidak sempurna yang menghapus data terperinci yang diperlukan bagi rekonstruksi sidik jari sebenarnya milik pengguna. Peta node yang dihasilkan disimpan tanpa informasi identitas dalam format terenkripsi yang hanya dapat dibaca oleh Enklave Aman, dan tidak pernah dikirimkan ke Apple atau dicadangkan ke iCloud atau iTunes.


8

Bagaimana Touch ID membuka perangkat iOS

Jika Touch ID dimatikan, saat perangkat dikunci, kunci untuk Perlindungan Data kelas Lengkap, yang disimpan di Enklave Aman, akan dihapus. File dan item rantai kunci di kelas tersebut tidak dapat diakses hingga pengguna membuka perangkat dengan memasukkan kode sandinya. Dengan Touch ID yang dinyalakan, kunci tidak akan dihapus saat perangkat terkunci; sebagai gantinya, kunci dibungkus dengan sebuah kunci yang diberikan ke subsistem Touch ID di dalam Enklave Aman. Saat pengguna mencoba membuka perangkat, jika Touch ID mengenali sidik jari pengguna, Touch ID akan menyediakan kunci untuk membuka bungkusan kunci Perlindungan Data, dan perangkat akan dibuka. Proses ini menyediakan perlindungan tambahan dengan mengharuskan subsistem Perlindungan Data dan Touch ID untuk bekerja sama agar dapat membuka perangkat. Kunci yang diperlukan agar Touch ID dapat membuka perangkat akan hilang jika perangkat di-boot ulang dan dihapus oleh Enklave Aman setelah 48 jam atau lima upaya pengenalan Touch ID yang gagal.


9

Enkripsi dan Perlindungan Data Hapus konten & pengaturan Pilihan “Hapus konten & pengaturan” di Pengaturan akan menghilangkan semua kunci di Penyimpanan Dapat Dihapus, sehingga membuat semua data pengguna di perangkat menjadi tidak dapat diakses secara kriptografis. Oleh karena itu, ini merupakan cara yang ideal untuk memastikan bahwa semua informasi pribadi dihapus dari perangkat sebelum memberikannya ke orang lain atau mengembalikannya untuk diservis. Penting: Jangan gunakan pilihan “Hapus konten & pengaturan” sebelum mencadangkan perangkat, karena data yang terhapus tidak mungkin dapat dipulihkan.

Rantai boot aman, penandatanganan kode, dan keamanan proses runtime membantu memastikan bahwa hanya kode dan app tepercaya yang dapat dijalankan di perangkat. iOS memiliki fitur enkripsi dan perlindungan data tambahan untuk melindungi data pengguna, bahkan saat bagian lain dari infrastruktur keamanan telah rusak (misalnya, di perangkat dengan modifikasi yang tidak sah). Ini memiliki manfaat penting bagi pengguna dan administrator TI, melindungi informasi pribadi dan perusahaan setiap saat, dan menyediakan cara untuk menghapus perangkat secara instan dan menyeluruh jika dicuri atau hilang.

Fitur keamanan perangkat keras Di perangkat bergerak, efisiensi kecepatan dan daya bersifat penting. Operasi kriptografis adalah operasi yang rumit dan dapat berdampak pada masalah kinerja dan masa pakai baterai jika tidak dirancang dan diterapkan dengan mengutamakan prioritas ini. Setiap perangkat iOS memiliki mesin kripto 256 AES khusus yang terdapat di jalur DMA antara penyimpanan flash dan memori sistem utama, sehingga membuat enkripsi file menjadi sangat efisien. ID unik (UID) perangkat dan ID grup perangkat (GID) adalah kunci AES 256 bit yang digabungkan (UID) atau dikumpulkan (GID) ke dalam prosesor aplikasi dan Enklave Aman selama produksi. Tidak ada perangkat lunak atau firmware yang dapat membacanya secara langsung; perangkat lunak atau firmware hanya dapat melihat hasil operasi enkripsi atau dekripsi yang dilakukan oleh mesin AES khusus berupa silikon menggunakan UID atau GID sebagai kunci. Selain itu, UID dan GID Enklave Aman hanya dapat digunakan oleh mesin AES yang dikhususkan bagi Enklave Aman. UID berbeda-beda untuk setiap perangkat dan tidak direkam oleh Apple atau pemasoknya. GID bersifat umum bagi semua prosesor di satu kelas perangkat (misalnya, semua perangkat dengan prosesor Apple A8), dan digunakan untuk tugas yang tidak berisiko bagi keamanan seperti saat mengirimkan perangkat lunak sistem selama penginstalan dan pemulihan. Integrasi semua kunci ini ke dalam silikon membantu mencegah kunci untuk dirusak atau dipintas, atau diakses di luar mesin AES. UID dan GID juga tidak tersedia melalui JTAG atau antarmuka debug lainnya. UID memungkinkan data untuk dikaitkan secara kriptografis ke perangkat tertentu. Misalnya, hierarki kunci yang melindungi sistem file meliputi UID, sehingga jika keping memori dipindahkan dari satu perangkat ke perangkat lain, file tidak akan dapat diakses. UID tidak terkait dengan pengenal lain di perangkat. Selain UID dan GID, semua kunci kriptografis dibuat oleh pembuat nomor acak (RNG) pada sistem menggunakan logaritma berbasis CTR_DRBG. Entropi sistem dibuat dari variasi waktu saat boot, dan dari waktu interupsi setelah perangkat di-boot. Kunci yang dihasilkan di dalam Enklave Aman menggunakan pembuat nomor acak perangkat kerasnya yang sebenarnya berdasarkan beberapa osilator berlingkaran jamak dan kemudian diproses dengan CTR_DRBG. Sama halnya dengan proses pembuatannya, kunci yang disimpan juga harus dapat dihapus dengan aman. Hal tersebut sulit dilakukan terutama di penyimpanan flash, mengingat penyamarataan penggunaan dapat mengharuskan beberapa salinan data untuk dihapus. Untuk menanggulangi masalah ini, perangkat iOS disertai dengan fitur khusus bagi penghapusan data secara aman yang disebut Penyimpanan Dapat


10

Dihapus. Fitur ini mengakses teknologi penyimpanan lapisan bawah (misalnya, NAND) untuk secara langsung menanggulangi dan menghapus sejumlah kecil blok pada level yang sangat rendah.

Perlindungan Data File Selain fitur enkripsi perangkat keras yang terdapat di perangkat iOS, Apple menggunakan teknologi yang disebut Perlindungan Data untuk melindungi data di memori flash pada perangkat. Perlindungan Data memungkinkan perangkat untuk merespons kejadian umum seperti panggilan telepon masuk, tapi juga memungkinkan enkripsi tingkat tinggi bagi data pengguna. App sistem kunci, seperti nilai data Pesan, Mail, Kalender, Kontak, Foto, dan Kesehatan menggunakan Perlindungan Data secara default, dan app pihak ketiga yang diinstal di iOS 7 atau lebih baru menerima perlindungan ini secara otomatis. Perlindungan Data diterapkan dengan membangun dan mengelola hierarki kunci, dan berbasis teknologi enkripsi perangkat keras pada setiap perangkat iOS. Perlindungan Data dikontrol pada basis per file dengan menetapkan tiap file ke suatu kelas; aksesibilitas ditetapkan berdasarkan dibuka atau tidaknya kunci kelas.

Tinjauan arsitektur

Setiap kali file di partisi data dibuat, Perlindungan Data akan membuat kunci 256 bit baru (kunci "per file") dan memberikannya ke mesin AES perangkat keras, yang menggunakan kunci tersebut untuk mengenkripsi file sementara file dituliskan ke memori flash menggunakan mode AES CBC. (Di perangkat dengan prosesor A8, AES-XTS digunakan.) Vektor inisialisasi (IV) dihitung dengan ofset blok ke dalam file, dienkripsi dengan hash SHA-1 dari kunci per file. Kunci per file dibungkus dengan salah satu dari beberapa kunci kelas, tergantung situasi yang mengharuskan file untuk dapat diakses. Seperti pembungkusan lainnya, ini dilakukan menggunakan pembungkusan kunci NIST AES, per RFC 3394. Kunci per file yang dibungkus disimpan di metadata file. Saat file dibuka, metadatanya akan didekripsi dengan kunci sistem file, mengungkapkan kunci per file yang dibungkus dan catatan mengenai kelas mana yang melindunginya. Pembungkusan kunci per file dibuka dengan kunci kelas, lalu dipasok ke mesin AES perangkat keras, yang mendekripsi file sementara file dibaca dari memori flash. Semua penanganan kunci file yang dibungkus dilakukan di Enklave Aman; kunci file tidak pernah dipaparkan secara langsung ke prosesor aplikasi. Saat boot, Enklave Aman menegosiasikan kunci jangka pendek dengan mesin AES. Saat Enklave Aman membuka bungkus kunci file, kunci dibungkus kembali dengan kunci jangka pendek dan dikirimkan kembali ke prosesor aplikasi. Metadata semua file di sistem file dienkripsi dengan kunci acak, yang dibuat saat iOS diinstal untuk pertama kalinya atau saat perangkat dihapus oleh pengguna. Kunci sistem file disimpan di Penyimpanan Dapat Dihapus. Karena disimpan di perangkat, kunci ini tidak digunakan untuk menjaga kerahasiaan data; sebagai gantinya, kunci dirancang untuk dihapus dengan cepat saat diminta (oleh pengguna, dengan pilihan "Hapus konten & pengaturan", atau oleh pengguna atau administrator yang mengeluarkan perintah penghapusan jarak jauh dari server mobile device management (MDM), Exchange ActiveSync, atau iCloud). Jika kunci dihapus dengan cara ini, semua file akan menjadi tidak dapat diakses secara kriptografis.


11

Kunci Sistem File

Kunci Perangkat Keras

Kunci Kode Sandi

Kunci Kelas

Metadata File Kunci File

Konten File

Konten file dienkripsi dengan kunci per file, yang dibungkus dengan kunci kelas dan disimpan di metadata file, yang pada gilirannya dienkripsi dengan kunci sistem file. Kunci kelas dilindungi dengan UID perangkat keras dan, untuk beberapa kelas, dengan kode sandi pengguna. Hierarki ini menghasilkan fleksibilitas dan kinerja. Misalnya, pengubahan kelas file hanya memerlukan pembungkusan ulang kunci per file-nya, dan perubahan kode sandi hanya membungkus ulang kelas kunci.

Kode Sandi Pertimbangan kode sandi Jika kata sandi panjang yang hanya berisi angka dimasukkan, keypad numerik akan ditampilkan di layar Terkunci, bukan papan ketik lengkap. Kode sandi numerik yang lebih panjang dapat lebih mudah dimasukkan daripada kode sandi alfanumerik yang lebih pendek, meskipun sama-sama aman.

Dengan mengatur kode sandi perangkat, pengguna akan mengaktifkan Perlindungan Data secara otomatis. iOS mendukung kode sandi alfanumerik enam digit, empat digit, dan dengan panjang arbitrer. Selain membuka perangkat, kode sandi menyediakan entropi untuk kunci enkripsi tertentu. Ini berarti penyerang yang memegang perangkat tidak dapat mengakses data dalam kelas perlindungan tertentu tanpa kode sandi. Kode sandi dikaitkan dengan UID perangkat, sehingga perangkat hanya dapat diserang dengan upaya paksa. Jumlah pengulangan yang besar digunakan untuk memperlambat tiap upaya. Jumlah pengulangan dikalibrasi sehingga satu upaya memerlukan waktu kira-kira 80 milidetik. Ini berarti diperlukan waktu lebih dari 5½ tahun untuk mencoba semua kombinasi kode sandi alfanumerik enam digit dengan huruf kecil dan angka. Semakin kuat kode sandi yang digunakan pengguna, semakin kuat kunci enkripsinya. Touch ID dapat digunakan untuk meningkatkan persamaan ini dengan memungkinkan pengguna untuk membuat kode sandi yang jauh lebih kuat, yang lebih bermanfaat daripada kode sandi praktis namun lemah. Ini meningkatkan jumlah efektif entropi yang melindungi kunci enkripsi untuk Perlindungan Data, tanpa dampak negatif terhadap pengalaman pengguna saat membuka perangkat iOS beberapa kali sepanjang hari.

Penundaan di antara upaya memasukkan kode sandi Upaya Penundaan Diberlakukan 1-4 tidak ada 5 1 menit 6 5 menit 7-8 15 menit 9 1 jam

Untuk melawan serangan paksa terhadap kode sandi secara lebih lanjut, terdapat penundaan waktu yang meningkat setelah dimasukkannya kode sandi yang tidak sah di layar Terkunci. Jika Pengaturan > Touch ID & Kode Sandi > Hapus Data dinyalakan, perangkat akan dihapus secara otomatis setelah 10 upaya memasukkan kode sandi yang gagal. Pengaturan ini juga tersedia sebagai kebijakan administratif melalui mobile device management (MDM) dan Exchange ActiveSync, dan dapat diatur ke ambang batas yang lebih rendah. Di perangkat dengan prosesor A7 atau seri A lebih baru, penundaan diberlakukan oleh Enklave Aman. Jika perangkat dimulai ulang selama penundaan berbatas waktu, penundaan masih akan diberlakukan, dengan timer yang dimulai dari awal untuk periode saat ini.


12

Kelas Perlindungan Data Saat file baru dibuat di perangkat iOS, file akan diberi kelas oleh app yang membuatnya. Setiap kelas menggunakan kebijakan yang berbeda untuk menentukan kapan data dapat diakses. Kelas dan kebijakan dasar dijelaskan di bagian berikut.

Perlindungan Menyeluruh

(NSFileProtectionComplete): Kunci kelas dilindungi dengan kunci turunan dari kode sandi pengguna dan UID perangkat. Segera setelah pengguna mengunci perangkat (10 detik, jika pengaturan Memerlukan Kata Sandi adalah Segera), kunci kelas yang didekripsi dihapus, membuat semua data di kelas ini tidak dapat diakses hingga pengguna memasukkan kode sandi lagi atau membuka perangkat dengan Touch ID.

Dilindungi Kecuali Terbuka

(NSFileProtectionCompleteUnlessOpen): Sebagian file mungkin harus dituliskan saat perangkat dikunci. Contohnya, lampiran mail yang sedang diunduh di latar belakang. Perilaku ini dimungkinkan dengan menggunakan kriptografi kurva elips asimetris (ECDH melalui Curve25519). Kunci per file yang biasa dilindungi oleh kunci turunan dari penggunaan Persetujuan Kunci Diffie-Hellman Satu Pass sebagaimana dijelaskan di NIST SP 800-56A. Kunci publik jangka pendek untuk persetujuan disimpan bersama kunci per file yang dibungkus. KDF adalah Fungsi Derivasi Kunci Rangkaian (Alternatif yang Disetujui 1) sebagaimana yang dijelaskan di 5.8.1 pada NIST SP 800-56A. AlgorithmID dihilangkan. PartyUInfo dan PartyVInfo masing-masing adalah kunci jangka pendek dan kunci publik statis. SHA-256 digunakan sebagai fungsi hash. Segera setelah file ditutup, kunci per file akan dihapus dari memori. Untuk membuka file lagi, rahasia bersama dibuat ulang menggunakan kunci pribadi kelas Dilindungi Kecuali Terbuka dan kunci publik jangka pendek milik file, yang digunakan untuk membuka bungkus kunci per file, yang kemudian digunakan untuk mendekripsi file.

Dilindungi Hingga Pengesahan Pengguna Pertama

(NSFileProtectionCompleteUntilFirstUserAuthentication): Kelas ini berfungsi dengan cara yang sama dengan Perlindungan Menyeluruh, kecuali bahwa kunci kelas yang didekripsi tidak dihapus dari memori saat perangkat dikunci. Perlindungan di kelas ini memiliki properti yang mirip dengan enkripsi volume penuh desktop, dan melindungi data dari serangan yang melibatkan boot ulang. Ini adalah kelas default untuk semua data app pihak ketiga yang tidak ditetapkan ke kelas Perlindungan Data.

Tidak Ada Perlindungan

(NSFileProtectionNone): Kunci kelas ini hanya dilindungi dengan UID, dan disimpan di Penyimpanan Data Dihapus. Karena semua kunci yang diperlukan untuk mendekripsi file di kelas ini disimpan di perangkat, enkripsi hanya dapat memanfaatkan fitur penghapusan jarak jauh cepat. Jika file tidak diberi kelas Perlindungan Data, file masih akan disimpan dalam format yang dienkripsi (sebagaimana semua data di perangkat iOS).

Perlindungan Data Rantai Kunci Banyak app yang harus menangani kata sandi dan data pendek namun sensitif lainnya, seperti kunci dan token masuk. Rantai kunci iOS menyediakan cara yang aman untuk menyimpan item ini. Rantai kunci diterapkan sebagai basis data SQLite yang disimpan di sistem file. Hanya ada satu basis data; daemon securityd menentukan item rantai kunci mana yang dapat diakses tiap proses atau app. API akses rantai kunci membuat panggilan ke daemon, Keamanan iOS—Buku Putih | Mei 2016

13

Komponen item rantai kunci Bersama dengan grup akses, tiap item rantai kunci berisi metadata administratif (seperti tanda waktu "dibuat" dan "terakhir diperbarui"). Item rantai kunci juga berisi hash SHA-1 dari atribut yang digunakan untuk melakukan permintaan untuk item (seperti akun dan nama server) untuk memungkinkan pencarian tanpa mendekripsi setiap item. Dan terakhir, item berisi data enkripsi, yang berisi: • Nomor versi • Data daftar kontrol akses (ACL)

yang meminta hak “keychain-access-groups,” “application-identifier,” dan “applicationgroup” milik app. Alih-alih membatasi akses ke satu proses, grup akses mengizinkan item rantai kunci untuk dibagikan antarapp. Item rantai kunci hanya dapat dibagikan antarapp dari pengembang yang sama. Ini dikelola dengan mengharuskan app pihak ketiga untuk menggunakan grup akses dengan prefiks yang disediakan melalui Program Pengembang Apple via grup aplikasi. Persyaratan prefiks dan keunikan grup aplikasi diberlakukan melalui penandatanganan kode, Profil Penyedia, dan Program Pengembang Apple. Data rantai kunci dilindungi menggunakan struktur kelas yang mirip dengan yang digunakan di Perlindungan Data file. Kelas ini memiliki perilaku yang sama dengan kelas Perlindungan Data file, tapi menggunakan kunci yang khas dan bagian dari API dengan nama berbeda.

• Nilai yang menunjukkan kelas perlindungan yang digunakan item

Ketersediaan

Perlindungan Data File

Perlindungan Data Rantai Kunci

• Kunci per item yang dibungkus dengan kunci kelas perlindungan

Saat terbuka

NSFileProtectionComplete

kSecAttrAccessibleWhenUnlocked

Saat dikunci

NSFileProtectionCompleteUnlessOpen

-

Setelah pertama kali dibuka

NSFileProtectionCompleteUntilFirstUserAuthentication

kSecAttrAccessibleAfterFirstUnlock

Selalu

NSFileProtectionNone

kSecAttrAccessibleAlways

Kode sandi diaktifkan

-

kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly

• Kamus atribut yang menjelaskan item (sebagaimana yang diteruskan ke SecItemAdd), yang dikodekan sebagai plist biner dan dienkripsi dengan kunci per item Enkripsi tersebut berupa AES 128 dalam GCM (Mode Galois/Penghitung); grup akses disertakan di atribut dan dilindungi oleh label GMAC yang dihitung selama enkripsi.

App yang menggunakan layanan penyegaran latar belakang dapat menggunakan kSecAttrAccessibleAfterFirstUnlock untuk item rantai kunci yang harus diakses saat pembaruan latar belakang. Kelas kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly berperilaku sama dengan kSecAttrAccessibleWhenUnlocked, namun hanya tersedia saat perangkat dikonfigurasi dengan kode sandi. Kelas ini hanya ada di kantong kunci sistem; kelas tidak diselaraskan dengan Rantai Kunci iCloud, tidak dicadangkan, dan tidak disertakan di kantong kunci eskrow. Jika kode sandi dihapus atau diatur ulang, item menjadi tidak berguna dengan menghapus kunci kelas. Kelas rantai kunci lainnya memiliki versi “Hanya perangkat ini”, yang selalu dilindungi dengan UID saat disalin dari perangkat selama pencadangan, membuatnya tidak berguna jika dipulihkan ke perangkat lain. Apple memiliki keamanan dan kebergunaan yang berimbang dengan memilih kelas rantai kunci yang bergantung pada jenis informasi yang diamankan dan saat diperlukan oleh iOS. Misalnya, sertifikat VPN harus selalu tersedia sehingga perangkat memiliki koneksi yang berkelanjutan, tapi diklasifikasikan sebagai “non-migrasi,” sehingga tidak dapat dipindahkan ke perangkat lain. Untuk item rantai kunci yang dibuat oleh iOS, kelas perlindungan berikut diberlakukan: Item

Dapat Diakses

Kata sandi Wi-Fi


Akun Mail


Akun Exchange


Kata sandi VPN


LDAP, CalDAV, CardDAV


Token akun jejaring sosial


Kunci enkripsi iklan Handoff



14

Token iCloud


Kata sandi berbagi rumah

Saat terbuka

Token Cari iPhone Saya

Selalu

Pesan Suara

Selalu

Cadangan iTunes

Saat terbuka, non-migrasi

Kata sandi Safari

Saat terbuka

Penanda Safari

Saat terbuka

Sertifikat VPN

Selalu, non-migrasi

Kunci Bluetooth®

Selalu, non-migrasi

Token layanan Pemberitahuan Push Apple

Selalu, non-migrasi

Kunci pribadi dan sertifikasi iCloud

Selalu, non-migrasi

Kunci iMessage

Selalu, non-migrasi

Sertifikat dan kunci pribadi yang diinstal oleh Profil Konfigurasi

Selalu, non-migrasi

PIN SIM

Selalu, non-migrasi

Kontrol akses rantai kunci

Rantai kunci dapat menggunakan daftar kontrol akses (ACL) untuk mengatur kebijakan aksesibilitas dan persyaratan pengesahan. Item dapat menciptakan situasi yang memerlukan keberadaan pengguna dengan menetapkan bahwa item tidak dapat diakses kecuali disahkan menggunakan Touch ID atau memasukkan kode sandi perangkat. Akses ke item juga dapat dibatasi dengan menetapkan bahwa Touch ID belum berubah sejak item ditambahkan. Pembatasan ini membantu mencegah penyerang untuk menambahkan sidik jari mereka agar dapat mengakses item rantai kunci. ACL dievaluasi di dalam Enklave Aman dan dilepaskan ke kernel hanya jika batasannya yang ditetapkan dipenuhi.

Akses ke kata sandi yang disimpan Safari App iOS dapat berinteraksi dengan item rantai kunci yang disimpan Safari untuk isi-auto kata sandi menggunakan dua API berikut: • SecRequestSharedWebCredential • SecAddSharedWebCredential Akses hanya akan diberikan jika pengembang app dan administrator web telah memberikan persetujuan mereka, dan pengguna telah menyepakati. Pengembang app menyatakan tujuannya untuk mengakses kata sandi yang disimpan Safari dengan menyertakan hak di app mereka. Hak ini mencantumkan nama domain yang sepenuhnya berkualifikasi dari situs web terkait. Situs web harus menempatkan file di server mereka yang mencantumkan pengenal app unik dari app yang telah mereka setujui. Saat app dengan hak com.apple.developer.associated-domains diinstal, iOS membuat permintaan TLS ke setiap situs web yang dicantumkan, yang meminta file/asosiasi-situs-app-apple. Jika file mencantumkan pengenal app dari app yang sedang diinstal, iOS akan menandai situs web dan app sebagai memiliki hubungan tepercaya. Hanya dengan hubungan tepercaya, panggilan ke dua API ini akan menghasilkan permintaan ke pengguna, yang harus setuju sebelum kata sandi dirilis ke app, atau diperbarui atau dihapus.


15

Kantong Kunci Kunci untuk kelas Perlindungan Data file dan rantai kunci dikumpulkan dan dikelola di kantong kunci. iOS menggunakan lima kantong kunci berikut: pengguna, perangkat, cadangan, eskrow, dan cadangan iCloud. Kantong kunci pengguna adalah tempat kunci kelas terbungkus yang digunakan di operasi normal perangkat disimpan. Misalnya, saat kode sandi dimasukkan, kunci NSFileProtectionComplete akan dimuat dari kantong kunci sistem dan dibuka bungkusnya. Ini adalah plist biner yang disimpan di kelas Tidak Ada Perlindungan, tapi kontennya dienkripsi dengan kunci yang disimpan di Penyimpanan Dapat Dihapus. Agar dapat meneruskan keamanan ke kantong kunci, kunci ini dihapus dan dibuat ulang setiap kali pengguna mengubah kode sandinya. Ekstensi kernel AppleKeyStore mengelola kantong kunci pengguna, dan dapat ditanyai perihal status kunci perangkat. Ekstensi ini melaporkan bahwa perangkat dibuka hanya jika semua kunci kelas di kantong kunci pengguna dapat diakses, dan telah berhasil dibuka bungkusnya. Kantong kunci perangkat digunakan untuk menyimpan kunci kelas yang dibungkus untuk operasi yang melibatkan data khusus perangkat. Perangkat iOS yang dikonfigurasi untuk penggunaan bersama kadang memerlukan akses ke info pengesahan sebelum pengguna masuk; oleh karena itu, kantong kunci yang tidak dilindungi oleh kode sandi pengguna diperlukan. iOS tidak mendukung pemisahan kriptografis konten sistem file per pengguna, yang berarti sistem akan menggunakan kunci kelas dari kantong kunci perangkat untuk membungkus kunci per file. Namun, rantai kunci menggunakan kunci kelas dari kantong kunci pengguna untuk melindungi item di rantai kunci pengguna. Di perangkat iOS yang dikonfigurasi untuk digunakan oleh satu pengguna (konfigurasi default), kantong kunci perangkat dan pengguna berjumlah satu dan sama, serta dilindungi oleh kode sandi pengguna. Kantong kunci cadangan dibuat saat cadangan terenkripsi dibuat oleh iTunes dan disimpan di komputer tempat perangkat dicadangkan. Kantong kunci baru dibuat dengan kumpulan kunci baru, dan data cadangan dienkripsi ulang ke kunci baru ini. Sebagaimana dijelaskan sebelumnya, item rantai kunci non-migrasi tetap dibungkus dengan kunci turunan UID, sehingga memungkinkan item untuk dipulihkan ke perangkat tempat asal pencadangan, tapi membuatnya tidak dapat diakses di perangkat lain. Kantong kunci dilindungi dengan kata sandi yang diatur di iTunes, dijalankan melalui 10.000 pengulangan PKBDF2. Meskipun pengulangan ini berjumlah besar, tidak ada keterikatan terhadap perangkat tertentu, dan oleh karena itu serangan paksa yang paralel di banyak komputer secara teori dapat dicoba dilakukan di kantong kunci cadangan. Ancaman ini dapat dilawan dengan kata sandi yang cukup kuat. Jika pengguna memilih untuk tidak mengenkripsi cadangan iTunes, file cadangan tidak akan dienkripsi terlepas dari kelas Perlindungan Datanya, tapi rantai kunci akan tetap dilindungi dengan kunci turunan dari UID. Ini alasan mengapa item rantai kunci dimigrasi ke perangkat baru hanya jika kata sandi cadangan diatur. Kantong kunci eskrow digunakan untuk penyelarasan iTunes dan MDM. Kantong kunci ini memungkinkan iTunes untuk mencadangkan dan menyelaraskan tanpa mengharuskan pengguna untuk memasukkan kode sandi, dan memungkinkan server MDM untuk membersihkan kode sandi pengguna dari jauh. Kantong kunci disimpan di komputer yang digunakan untuk menyelaraskan dengan iTunes, atau di server MDM yang mengelola perangkat. Kantong kunci eskrow meningkatkan pengalaman pengguna pada saat penyelarasan perangkat, yang berpotensi memerlukan akses ke semua kelas data. Saat perangkat yang dikunci kode sandi pertama kali tersambung ke iTunes, pengguna akan diminta untuk memasukkan kode sandi. Perangkat kemudian membuat kantong kunci eskrow berisi kunci kelas yang sama dengan kunci kelas yang digunakan di perangkat, yang


16

dilindungi oleh kunci yang baru dibuat. Kantong kunci eskrow dan kunci yang melindunginya dibagi antara perangkat dan host atau server, dengan data yang disimpan di perangkat dalam kelas Dilindungi Hingga Pengesahan Pengguna Pertama. Ini alasan mengapa kode sandi perangkat harus dimasukkan sebelum pengguna mencadangkan dengan iTunes untuk pertama kalinya setelah di-boot ulang. Pada saat pembaruan perangkat lunak OTA, pengguna dimintai kode sandinya saat memulai pembaruan. Ini digunakan untuk membuat Token Sekali Buka dengan aman yang membuka kantong kunci pengguna setelah pembaruan. Token ini tidak dapat dibuat tanpa memasukkan kode sandi pengguna, dan token yang dibuat sebelumnya menjadi tidak sah jika kode sandi pengguna berubah. Token Sekali Buka dapat digunakan untuk penginstalan pembaruan perangkat lunak yang diawasi atau tidak diawasi. Token dienkripsi dengan kunci turunan dari nilai penghitung monoton saat ini di Enklave Aman, dan UUID kantong kunci, dan UID Enklave Aman. Jika penghitung Token Sekali Buka ditambah di Enklave Aman, token yang ada akan menjadi tidak sah. Penghitung ditambah saat token digunakan, setelah pertama kali dibuka di perangkat yang dimulai ulang, saat pembaruan perangkat lunak dibatalkan (oleh pengguna atau sistem), atau saat timer kebijakan token telah kedaluwarsa. Token Sekali Buka untuk pembaruan perangkat lunak yang diawasi kedaluwarsa setelah 20 menit. Token ini diekspor dari Enklave Aman dan dituliskan ke penyimpanan yang dapat dihapus. Timer kebijakan menambah penghitung jika perangkat belum di-boot ulang selama 20 menit. Untuk pembaruan perangkat lunak yang tidak diawasi, yang diatur saat pengguna memilih "Instal Nanti" saat diberi tahu mengenai pembaruan tersebut, prosesor aplikasi dapat menyimpan Token Sekali Buka di Enklave Aman selama maksimal 8 jam. Setelah itu, timer kebijakan akan menambah penghitung. Kantong kunci Cadangan iCloud mirip dengan kantong kunci cadangan. Semua kunci kelas di kantong kunci ini bersifat asimetris (menggunakan Curve25519, seperti kelas Perlindungan Data Dilindungi Kecuali Terbuka), sehingga pencadangan iCloud dapat dilakukan di latar belakang. Untuk semua kelas Perlindungan Data kecuali Tidak Ada Perlindungan, data terenkripsi dibaca dari perangkat dan dikirimkan ke iCloud. Kunci kelas yang sesuai dilindungi oleh kunci iCloud. Kunci kelas rantai kunci dibungkus dengan kunci turunan dari UID dengan cara yang sama dengan cadangan iTunes yang tidak terenkripsi. Kantong kunci asimetris juga digunakan untuk cadangan di aspek pemulihan rantai kunci dari Rantai Kunci iCloud.

Sertifikasi Keamanan dan program Catatan: Untuk informasi terbaru mengenai sertifikasi keamanan, validasi, dan petunjuk iOS, lihat support.apple.com/id-id/HT202739.

Validasi Kriptografis (FIPS 140-2)

Modul kriptografis di iOS telah divalidasi agar tunduk pada Standar Pemrosesan Informasi Federal A.S. (FIPS) 140-2 Level 1 menyusul setiap rilis sejak iOS 6. Modul kriptografis di iOS 9 identik dengan yang terdapat di iOS 8, tapi dengan setiap rilis, Apple mengirimkan modul untuk divalidasi ulang. Program ini memvalidasi integritas dari operasi kriptografis untuk app Apple dan app pihak ketiga yang menggunakan layanan kriptografis iOS dengan benar.


17

Sertifikasi Kriteria Umum (ISO 15408)

Apple telah mulai mengupayakan sertifikasi iOS dalam program Sertifikasi Kriteria Umum (CCC). Dua sertifikasi pertama yang diselesaikan adalah VID10695 untuk iOS 9 berdasarkan Profil Perlindungan Mendasar Perangkat Bergerak v2.0 (MDFPP2) dan Profil Perlindungan Klien VPN IPSecPP1.4 (VPNIPSecPP1.4). Sertifikasi aktif akan segera diselesaikan untuk protokol MDM internal berdasarkan Profil Perlindungan Agen MDM EP 2.0 (MDMAgentEP2). Apple telah berperan aktif dalam Komunitas Teknis Internasional (ITC) dalam mengembangkan Profil Perlindungan (PP) yang saat ini tidak tersedia yang difokuskan untuk mengevaluasi teknologi keamanan bergerak utama. Apple terus mengevaluasi dan mengupayakan sertifikasi berdasarkan versi PP yang baru dan diperbarui yang tersedia saat ini.

Solusi Komersial untuk Kerahasiaan (CSfC)

Jika berlaku, Apple juga telah mengirimkan platform iOS dan berbagai layanan untuk disertakan ke Daftar Komponen Program Solusi Komersial untuk Kerahasiaan (CSfC). Khususnya, iOS untuk Platform Bergerak dan klien IKEv2 untuk Klien VPN IPSec (hanya VPN Selalu Menyala IKEv2). Saat menjalani Sertifikasi Kriteria Umum, platform dan layanan Apple juga akan dikirimkan untuk disertakan di Daftar Komponen Program CSfC.

Petunjuk Konfigurasi Keamanan

Apple telah berkolaborasi dengan pemerintah di seluruh dunia untuk mengembangkan petunjuk yang memberikan instruksi dan anjuran untuk memelihara lingkungan yang lebih aman, juga disebut sebagai "penguatan perangkat." Petunjuk ini menyediakan informasi yang jelas dan teruji mengenai cara mengonfigurasi dan menggunakan fitur di iOS untuk perlindungan yang lebih baik.


18

Keamanan App App adalah salah satu elemen paling penting dari arsitektur keamanan bergerak modern. Meskipun sangat bermanfaat bagi produktivitas pengguna, app juga berpotensi untuk berdampak negatif bagi keamanan sistem, stabilitas, dan data pengguna jika tidak ditangani dengan benar. Karena alasan ini, iOS menyediakan beberapa lapisan perlindungan untuk memastikan bahwa app ditandatangani dan diverifikasi, dan menggunakan mekanisme sandbox untuk melindungi data pengguna. Elemen ini menyediakan platform yang aman dan stabil untuk app, sehingga memungkinkan ribuan pengembang untuk menghadirkan ratusan ribu app di iOS tanpa memengaruhi integritas sistem. Dan pengguna dapat mengakses app ini di perangkat iOS mereka tanpa khawatir terhadap virus, malware, atau serangan yang tidak diinginkan.

Penandatanganan kode app Setelah dimulai, kernel iOS akan mengontrol proses dan app pengguna mana yang dapat dijalankan. Untuk memastikan bahwa semua app berasal dari sumber yang diketahui dan disetujui dan belum dirusak, iOS mengharuskan semua kode yang dapat dijalankan untuk ditandatangani menggunakan sertifikat dari Apple. App yang menyertai perangkat, seperti Mail dan Safari, ditandatangani oleh Apple. App pihak ketiga juga harus divalidasi dan ditandatangani menggunakan sertifikat dari Apple. Penandatanganan kode yang wajib memperluas konsep rantai kepercayaan dari OS ke app, dan mencegah app pihak ketiga untuk memuat sumber kode yang tidak bertanda tangan atau menggunakan kode yang berubah sendiri. Agar dapat mengembangkan dan menginstal app di perangkat iOS, pengembang harus mendaftar di Apple dan bergabung dengan Program Pengembang Apple. Identitas sebenarnya dari setiap pengembang, baik perorangan maupun bisnis, diverifikasi oleh Apple sebelum sertifikatnya diterbitkan. Sertifikat ini memungkinkan pengembang untuk menandatangani app dan mengirimkannya ke App Store untuk diedarkan. Oleh karena itu, semua app di App Store telah dikirimkan oleh orang atau organisasi yang dapat dikenali, sehingga dapat mencegah pembuatan app yang berbahaya. App juga telah ditinjau oleh Apple untuk memastikan bahwa app beroperasi sebagaimana dijelaskan dan tidak berisi bug yang kentara atau masalah lainnya. Selain teknologi yang telah dibahas, proses kurasi ini meyakinkan konsumen akan kualitas app yang mereka beli. iOS memungkinkan pengembang untuk menanamkan framework di dalam app mereka, yang dapat digunakan oleh app itu sendiri atau oleh ekstensi yang ditanamkan di dalam app. Untuk melindungi sistem dan app lainnya dari kode pihak ketiga yang dimuat di dalam ruang alamat mereka, sistem akan melakukan validasi tanda tangan kode pada semua perpustakaan dinamis yang ditautkan proses saat diluncurkan. Verifikasi ini diselesaikan melalui pengenal tim (ID Tim), yang diekstrak dari sertifikat yang diterbitkan Apple. Pengenal tim adalah string alfanumerik 10 karakter; misalnya, 1A2B3C4D5F. Program dapat menautkan perpustakaan platform yang disertakan pada sistem atau perpustakaan dengan pengenal tim yang sama di tanda tangan kodenya dengan file utama yang dapat dieksekusi. Mengingat penyertaan file yang dapat dieksekusi sebagai bagian dari sistem tidak memiliki pengenal tim, file hanya dapat ditautkan dengan perpustakaan yang disertakan pada sistem itu sendiri.


19

Bisnis juga memiliki kemampuan untuk menulis app in-house untuk digunakan di dalam organisasi mereka dan mengedarkannya ke karyawan mereka. Bisnis dan organisasi dapat mengirimkan permohonan ke Program Perusahaan Pengembang Apple (ADEP) dengan nomor D-U-N-S. Apple akan menyetujui pemohon setelah memverifikasi identitas dan kelayakan mereka. Setelah menjadi anggota ADEP, organisasi dapat mendaftar untuk mendapatkan Profil Penyedia yang mengizinkan app in-house untuk dijalankan di perangkat yang disahkan. Pengguna harus menginstal Profil Penyedia agar dapat menjalankan app in-house. Ini memastikan bahwa hanya pengguna yang ditargetkan organisasi yang dapat memuat app ke perangkat iOS mereka. App yang diinstal melalui MDM dipercaya secara implisit karena hubungan antara organisasi dan perangkat telah terbangun. Jika tidak, pengguna harus menyetujui Profil Penyedia di Pengaturan. Organisasi dapat membatasi pengguna agar tidak menyetujui app dari pengembang yang tidak diketahui. Saat app perusahaan pertama kali diluncurkan, perangkat harus menerima konfirmasi positif dari Apple bahwa app diizinkan untuk dijalankan. Tidak seperti platform bergerak lainnya, iOS tidak mengizinkan pengguna untuk menginstal app tidak bertanda tangan yang berpotensi bahaya dari situs web, atau menjalankan kode yang tidak tepercaya. Saat runtime, pemeriksaan tanda tangan kode dari semua halaman memori yang dapat dieksekusi dilakukan saat halaman dimuat untuk memastikan bahwa app belum dimodifikasi setelah diinstal atau terakhir diperbarui.

Keamanan proses runtime Setelah diverifikasi sebagai app yang berasal dari sumber tepercaya, iOS memberlakukan tindakan pengamanan yang dirancang untuk mencegahnya menjadi berbahaya bagi app atau bagian sistem lainnya. Semua app pihak ketiga “menggunakan mekanisme sandbox,” sehingga dilarang untuk mengakses file yang disimpan oleh app lainnya atau untuk melakukan perubahan ke perangkat. Ini mencegah app untuk mengumpulkan atau memodifikasi informasi yang disimpan oleh app lainnya. Setiap app memiliki direktori utama unik untuk filenya, yang ditetapkan secara acak saat app diinstal. Jika app pihak ketiga memerlukan informasi yang bukan miliknya, app akan mengaksesnya hanya dengan menggunakan layanan yang disediakan secara eksplisit oleh iOS. File sistem dan sumber juga dilindungi dari app pengguna. Sebagian besar dari iOS dijalankan sebagai pengguna "bergerak" bukan istimewa, sebagaimana halnya dengan app pihak ketiga. Keseluruhan partisi OS dipasang sebagai hanya baca. Alat yang tidak diperlukan, seperti layanan masuk jarak jauh, tidak disertakan pada perangkat lunak sistem, dan API tidak mengizinkan app untuk meningkatkan hak mereka untuk memodifikasi app lainnya atau iOS itu sendiri. Akses oleh app pihak ketiga terhadap informasi pengguna dan fitur seperti iCloud dan ekstensibilitas dikontrol menggunakan hak yang ditetapkan. Hak adalah pasangan nilai utama yang masuk ke app dan mengizinkan pengesahan di luar faktor runtime seperti ID pengguna unix. Karena hak ditandatangani secara digital, hak tidak dapat diubah. Hak digunakan secara ekstensif oleh app sistem dan daemon untuk melakukan operasi istimewa tertentu yang sebaliknya mengharuskan agar proses dijalankan sebagai dasar. Ini sangat mengurangi potensi peningkatan hak oleh sistem aplikasi atau daemon yang berisiko.


20

Selain itu, app hanya dapat menjalankan pemrosesan latar belakang melalui API yang disediakan sistem. Ini memungkinkan app untuk terus berfungsi tanpa mengurangi kinerja atau memengaruhi masa pakai baterai secara drastis. Pengacakan tata letak ruang alamat (ASLR) melindungi dari eksploitasi bug kerusakan memori. App internal menggunakan ASLR untuk memastikan bahwa semua wilayah memori diacak saat diluncurkan. Dengan secara acak menyusun alamat memori dari kode yang dapat dieksekusi, perpustakaan sistem, dan konstruksi pemrograman terkait mengurangi kesamaan antara banyaknya eksploitasi yang rumit. Misalnya, serangan kembali-ke-libc mencoba untuk menipu perangkat agar menjalankan kode berbahaya dengan memanipulasi alamat memori dari tumpukan dan perpustakaan sistem. Dengan membuat penempatan yang acak, serangan ini menjadi jauh lebih sulit untuk dilakukan, khususnya di beberapa perangkat. Xcode, lingkungan pengembangan iOS, mengumpulkan program pihak ketiga secara otomatis dengan dukungan ASLR yang menyala. Perlindungan lebih lanjut disediakan oleh iOS menggunakan fitur Execute Never (XN) ARM, yang menandai halaman memori sebagai tidak dapat dieksekusi. Halaman memori yang ditandai sebagai dapat ditulisi dan dapat dieksekusi hanya dapat digunakan oleh app dengan kondisi yang dikontrol secara ketat: Pemeriksaan kernel terhadap keberadaan hak penandatanganan kode dinamis hanya Apple. Selain itu, hanya satu panggilan mmap yang dapat dilakukan untuk meminta halaman yang dapat dieksekusi dan ditulisi, yang diberi alamat acak. Safari menggunakan fungsi ini untuk kompilator JIT JavaScript-nya.

Ekstensi iOS memungkinkan app untuk menyediakan fungsinya bagi app lain dengan menyediakan ekstensi. Ekstensi adalah biner yang dapat dieksekusi bertanda tangan dengan tujuan khusus, yang disertakan di dalam app. Sistem akan mendeteksi ekstensi secara otomatis saat penginstalan dan membuatnya tersedia bagi app lainnya menggunakan sistem pencocokan. Area sistem yang mendukung ekstensi disebut dengan titik ekstensi. Setiap titik ekstensi menyediakan API dan memberlakukan kebijakan bagi area tersebut. Sistem menentukan ekstensi mana yang tersedia berdasarkan aturan pencocokan khusus titik ekstensi. Sistem akan meluncurkan proses ekstensi secara otomatis jika diperlukan dan mengelola masa berlakunya. Hak dapat digunakan untuk membatasi ketersediaan ekstensi bagi aplikasi sistem tertentu. Misalnya, widget tampilan Hari Ini hanya muncul di Pusat Pemberitahuan, dan ekstensi berbagi hanya tersedia dari panel Berbagi. Titik ekstensi adalah widget Hari Ini, Bagikan, Tindakan khusus, Pengeditan Foto, Penyedia Dokumen, dan Papan Ketik Khusus. Ekstensi dijalankan di ruang alamatnya sendiri. Komunikasi antara ekstensi dan app tempat asal aktivasi ekstensi menggunakan komunikasi antarproses yang diperantarai oleh framework sistem. Ekstensi tidak dapat mengakses file atau ruang memori satu sama lain. Ekstensi dirancang agar terisolasi dari satu sama lain, dari app yang mewadahinya, dan app yang menggunakannya. Ekstensi menggunakan mekanisme sandbox seperti app pihak ketiga lain dan memiliki wadah yang terpisah dari wadah app yang mewadahinya. Namun, ekstensi berbagi akses yang sama terhadap kontrol privasi dengan app wadah. Sehingga jika pengguna memberi akses Kontak ke app, pemberian akses ini dapat diperluas ke ekstensi yang ditanam di dalam app, tapi tidak ke ekstensi yang diaktifkan oleh app. Papan ketik khusus adalah ekstensi jenis khusus karena diaktifkan oleh pengguna untuk keseluruhan sistem. Setelah diaktifkan, ekstensi akan digunakan untuk semua bidang teks kecuali input kode sandi dan semua tampilan teks aman. Demi kepentingan privasi, papan ketik khusus dijalankan secara default di sandbox yang sangat terbatas yang


21

memblokir akses ke jaringan, ke layanan yang menjalankan operasi jaringan atas nama proses tertentu, dan ke API yang akan mengizinkan ekstensi untuk mengambil data pengetikan. Pengembang papan ketik khusus dapat meminta agar ekstensi mereka memiliki Akses Terbuka, yang akan memungkinkan sistem untuk menjalankan ekstensi di sandbox default setelah mendapatkan persetujuan dari pengguna. Untuk perangkat yang terdaftar di mobile device management, ekstensi dokumen dan papan ketik mematuhi aturan Buka Di yang Dikelola. Misalnya, server MDM dapat mencegah pengguna untuk mengekspor dokumen dari app yang dikelola ke Penyedia Dokumen yang tidak dikelola, atau menggunakan papan ketik tidak dikelola dengan app yang dikelola. Selain itu, pengembang app dapat mencegah penggunaan ekstensi papan ketik pihak ketiga di dalam app mereka.

Grup App App dan ekstensi yang dimiliki oleh akun pengembang tertentu dapat berbagi konten saat dikonfigurasi agar menjadi bagian dari Grup App. Pengembang memiliki kebebasan untuk membuat grup yang sesuai di Portal Pengembang Apple dan menyertakan kumpulan app dan ekstensi yang diinginkan. Setelah dikonfigurasi agar menjadi bagian dari Grup App, app memiliki akses ke: • Wadah bersama di disk untuk penyimpanan, yang akan tetap berada di perangkat selama setidaknya satu app dari grup diinstal • Preferensi bersama • Item rantai kunci bersama Portal Pengembang Apple menjamin bahwa ID Grup App bersifat unik di semua ekosistem app.

Perlindungan Data di app Kit Pengembangan Perangkat Lunak (SDK) iOS menawarkan rangkaian lengkap API yang memudahkan pengembang pihak ketiga dan in-house untuk mengadopsi Perlindungan Data dan membantu memastikan perlindungan level tertinggi di app mereka. Perlindungan Data tersedia untuk API file dan basis data, termasuk NSFileManager, CoreData, NSData, dan SQLite. App Mail (termasuk lampiran), buku yang dikelola, penanda Safari, gambar peluncuran app, dan data lokasi juga disimpan terenkripsi dengan kunci yang dilindungi oleh kode sandi pengguna di perangkat mereka. Kalender (kecuali lampiran), Kontak, Pengingat, Catatan, Pesan, dan Foto menerapkan Dilindungi Hingga Pengesahan Pengguna Pertama. App yang diinstal pengguna yang tidak mengaktifkan kelas Perlindungan Data tertentu menerima Dilindungi Hingga Pengesahan Pengguna Pertama secara default.

Aksesori Program pelisensian Made for iPhone, iPod touch, dan iPad (MFi) menyediakan akses produsen aksesori yang teruji terhadap Protokol Aksesori iPod (iAP) dan komponen perangkat keras pendukung yang diperlukan. Saat aksesori MFi berkomunikasi dengan perangkat iOS menggunakan konektor Lightning atau via Bluetooth, perangkat meminta aksesori untuk membuktikan bahwa aksesori telah disahkan oleh Apple dengan merespons dalam bentuk sertifikat yang disediakan Apple, yang kemudian diverifikasi oleh perangkat. Perangkat kemudian mengirimkan tantangan, yang harus dijawab aksesori dengan respons yang


22

ditandatangani. Keseluruhan proses ini ditangani oleh sirkuit terpadu khusus yang disediakan Apple untuk menyetujui produsen aksesori dan bersifat transparan bagi aksesori itu sendiri. Aksesori dapat meminta akses ke metode dan fungsi transpor yang berbeda; misalnya, akses ke stream audio digital melalui kabel Lightning, atau informasi lokasi yang disediakan melalui Bluetooth. IC pengesahan memastikan bahwa hanya perangkat yang disetujui yang diberi akses penuh ke perangkat. Jika aksesori tidak menyediakan pengesahan, aksesnya terbatas pada audio analog dan subset kecil dari kontrol pemutaran audio serial (UART). AirPlay juga menggunakan IC pengesahan untuk memverifikasi bahwa penerima telah disetujui oleh Apple. Stream audio AirPlay dan video CarPlay menggunakan MFi-SAP (Protokol Asosiasi Aman), yang mengenkripsi komunikasi antara aksesori dan perangkat menggunakan AES-128 dalam mode CTR. Kunci jangka pendek ditukar menggunakan pertukaran kunci ECDH (Curve25519) dan ditandatangani menggunakan kunci RSA 1024 bit milik IC pengesahan sebagai bagian dari protokol Stasiun-ke-Stasiun (STS).

HomeKit HomeKit menyediakan infrastruktur automasi utama yang menggunakan keamanan iCloud dan iOS untuk melindungi dan menyelaraskan data pribadi tanpa memaparkannya ke Apple.

Identitas HomeKit

Identitas dan keamanan HomeKit didasarkan pada pasangan kunci pribadi-publik Ed25519. Pasangan kunci Ed25519 dibuat di perangkat iOS bagi tiap pengguna untuk HomeKit, yang kemudian menjadi identitas HomeKit-nya. Pasangan kunci ini digunakan untuk mengesahkan komunikasi antarperangkat iOS, serta antara perangkat iOS dan aksesori. Kunci disimpan di Rantai Kunci dan hanya disertakan di cadangan Rantai Kunci terenkripsi. Kunci diselaraskan antarperangkat menggunakan Rantai Kunci iCloud.

Komunikasi dengan aksesori HomeKit

Aksesori HomeKit membuat pasangan kunci Ed25519-nya sendiri untuk digunakan saat berkomunikasi dengan perangkat iOS. Jika aksesori dipulihkan ke pengaturan pabrik, pasangan kunci baru akan dibuat. Untuk membangun hubungan antara perangkat iOS dan aksesori HomeKit, kunci ditukar menggunakan protokol Kata Sandi Jarak Jauh Aman (3072 bit), menggunakan kode 8 digit yang disediakan oleh produsen aksesori dan dimasukkan di perangkat iOS oleh pengguna, lalu dienkripsi menggunakan ChaCha20-Poly1305 AEAD dengan kunci turunan dari HKDF-SHA-512. Sertifikasi MFi aksesori juga diverifikasi selama pengaturan. Saat berkomunikasi selama penggunaan, perangkat iOS dan aksesori HomeKit saling mengesahkan penggunaan kunci yang ditukar pada proses di atas. Setiap sesi dibuat menggunakan protokol Stasiun-ke-Stasiun dan dienkripsi dengan kunci turunan dari HKDF-SHA-512 berdasarkan kunci Curve25519 per sesi. Ini berlaku bagi aksesori berbasis IP dan aksesori Bluetooth Rendah Energi.

Penyimpanan data lokal

HomeKit menyimpan data mengenai rumah, aksesori, tampilan, dan pengguna di perangkat iOS pengguna. Data yang disimpan ini dienkripsi menggunakan kunci turunan dari kunci identitas HomeKit pengguna, ditambah nilai sekali pakai acak.


23

Selain itu, data HomeKit disimpan menggunakan kelas Perlindungan Data Dilindungi Hingga Pengesahan Pengguna Pertama. Data HomeKit hanya dicadangkan di cadangan terenkripsi, sehingga, misalnya, cadangan iTunes yang tidak terenkripsi tidak berisi data HomeKit.

Penyelarasan data antara perangkat dan pengguna

Data HomeKit dapat diselaraskan antarperangkat iOS pengguna menggunakan iCloud dan Rantai Kunci iCloud. Data HomeKit dienkripsi selama penyelarasan menggunakan kunci turunan dari identitas HomeKit pengguna dan nilai sekali pakai acak. Data ini ditangani sebagai blob buram saat penyelarasan. Blob terbaru disimpan di iCloud untuk mengaktifkan penyelarasan, tapi tidak digunakan untuk tujuan lainnya. Karena blob dienkripsi menggunakan kunci yang hanya tersedia di perangkat iOS pengguna, kontennya tidak dapat diakses selama transmisi dan penyimpanan iCloud. Data HomeKit juga diselaraskan antara beberapa pengguna rumah yang sama. Proses ini menggunakan pengesahan dan enkripsi yang sama dengan yang digunakan antara perangkat iOS dan aksesori HomeKit. Pengesahan didasarkan pada kunci publik Ed25519 yang ditukar antara perangkat saat pengguna ditambahkan ke rumah. Setelah pengguna baru ditambahkan ke rumah, semua komunikasi lebih lanjut disahkan dan dienkripsi menggunakan protokol Stasiun-ke-Stasiun dan kunci per sesi. Hanya pengguna yang membuat rumah di HomeKit yang dapat menambahkan pengguna baru. Perangkatnya mengonfigurasi aksesori dengan kunci publik pengguna baru sehingga aksesori tersebut dapat mengesahkan dan menerima perintah dari pengguna baru. Proses untuk mengonfigurasi Apple TV untuk digunakan dengan HomeKit menggunakan pengesahan dan enkripsi yang sama dengan saat menambahkan pengguna baru, tapi dilakukan secara otomatis jika pengguna yang membuat rumah masuk ke iCloud di Apple TV dan Apple TV berada di rumah. Jika pengguna tidak memiliki beberapa perangkat, dan tidak memberi pengguna tambahan akses ke rumahnya, tidak ada data HomeKit yang akan diselaraskan ke iCloud.

Data dan app Rumah

Akses app ke data rumah dikontrol oleh pengaturan Privasi pengguna. Pengguna diminta untuk memberikan akses saat app meminta data rumah, sama dengan Kontak, Foto, dan sumber data iOS lainnya. Jika pengguna menyetujui, app akan memiliki akses ke nama ruangan, nama aksesori, dan ruangan tempat aksesori berada, serta informasi lainnya sebagaimana yang dirinci di dokumentasi pengembang HomeKit.

Siri

Siri dapat digunakan untuk meminta dan mengontrol aksesori, dan untuk mengaktifkan tampilan. Informasi yang minimal mengenai konfigurasi rumah disediakan secara anonim ke Siri, sebagaimana dijelaskan di bagian Siri dari dokumen ini, untuk menyediakan nama ruangan, aksesori, dan tampilan yang penting untuk pengenalan perintah.

Akses jarak jauh iCloud untuk aksesori HomeKit

Aksesori HomeKit dapat terhubung secara langsung dengan iCloud untuk mengaktifkan perangkat iOS agar dapat mengontrol aksesori saat komunikasi Bluetooth atau Wi-Fi tidak tersedia. Akses Jarak Jauh iCloud telah dirancang secara teliti sehingga aksesori dapat dikontrol dan mengirim pemberitahuan tanpa memberi tahu Apple mengenai jenis aksesori, atau perintah dan pemberitahuan yang dikirimkan. HomeKit tidak mengirim informasi mengenai rumah melalui akses Jarak Jauh iCloud.


24

Saat pengguna mengirimkan perintah menggunakan akses jarak jauh iCloud, aksesori dan perangkat iOS akan saling mengesahkan dan data dienkripsi menggunakan prosedur yang sama dengan yang dijelaskan untuk koneksi lokal. Konten komunikasi dienkripsi dan tidak dapat dilihat oleh Apple. Pengaturan alamat melalui iCloud didasarkan pada pengenal iCloud yang didaftarkan selama proses pengaturan. Aksesori yang mendukung akses jarak jauh iCloud disediakan selama proses pengaturan aksesori. Proses penyediaan dimulai dengan pengguna yang masuk ke iCloud. Setelah itu, perangkat iOS meminta aksesori untuk menandatangani tantangan menggunakan Koprosesor Pengesahan Apple yang terdapat di semua Built untuk aksesori HomeKit. Aksesori juga membuat kunci kurva elips prime256v1, dan kunci publiknya dikirimkan ke perangkat iOS bersama dengan tantangan bertanda tangan dan sertifikat X.509 dari koprosesor pengesahan. Ini digunakan untuk meminta sertifikat bagi aksesori dari server penyedia iCloud. Sertifikat disimpan oleh aksesori, tapi tidak berisi informasi pengenal mengenai aksesori, kecuali bahwa aksesori telah diberi akses ke akses jarak jauh iCloud HomeKit. Perangkat iOS yang melakukan penyediaan juga mengirimkan kantong ke aksesori, yang berisi URL dan informasi lainnya yang diperlukan untuk menghubungkan ke server akses jarak jauh iCloud. Informasi ini tidak khusus ditujukan bagi pengguna atau aksesori tertentu. Setiap aksesori mendaftarkan daftar pengguna yang diizinkan untuk menggunakan server akses jarak jauh iCloud. Pengguna ini telah diberi kemampuan untuk mengontrol aksesori oleh orang yang menambahkan aksesori ke rumah. Pengguna diberi pengenal oleh server iCloud dan dapat dipetakan ke akun iCloud untuk tujuan pengiriman pesan pemberitahuan dan respons dari aksesori. Aksesori juga memiliki pengenal yang diterbitkan oleh iCloud, tapi pengenal ini bersifat buram dan tidak menampilkan informasi apa pun mengenai aksesori itu sendiri. Saat terhubung ke server akses jarak jauh iCloud HomeKit, aksesori memberikan sertifikat dan pass-nya. Pass didapat dari server iCloud yang berbeda dan tidak bersifat unik untuk setiap aksesori. Saat meminta pass, aksesori menyertakan produsen, model, dan versi firmware di dalam permintaannya. Tidak ada informasi yang mengidentifikasi pengguna atau rumah yang dikirimkan oleh permintaan ini. Koneksi ke server pass tidak disahkan, untuk membantu melindungi privasi. Aksesori yang terhubung ke server akses jarak jauh iCloud menggunakan HTTP/2, diamankan menggunakan TLS 1.2 dengan AES-128-GCM dan SHA-256. Aksesori menjaga agar koneksinya ke server akses jarak jauh iCloud tetap terbuka sehingga dapat menerima pesan masuk dan mengirim respons serta pemberitahuan keluar ke perangkat iOS.

HealthKit HealthKit menyimpan dan mengagregatkan data dari app kesehatan dan kebugaran dengan izin pengguna. HealthKit juga bekerja langsung dengan perangkat kesehatan dan kebugaran, seperti monitor detak jantung Bluetooth LE yang kompatibel dan koprosesor gerakan yang terdapat di banyak perangkat iOS.

Data Kesehatan

HealthKit menyimpan dan mengagregatkan data kesehatan pengguna, seperti tinggi, berat badan, jarak berjalan kaki, tekanan darah, dan lain-lain. Data ini disimpan di Perlindungan Data kelas Perlindungan Menyeluruh, sehingga dapat diakses hanya setelah pengguna memasukkan kode sandinya atau menggunakan Touch ID untuk membuka perangkat.


25

Basis data lain menyimpan data operasional, seperti tabel akses untuk app, nama perangkat yang terhubung ke HealthKit, dan informasi jadwal yang digunakan untuk meluncurkan app saat data baru tersedia. Basis data ini disimpan di kelas Perlindungan Data Dilindungi Hingga Pengesahan Pengguna Pertama. File jurnal sementara menyimpan rekaman kesehatan yang dibuat saat perangkat terkunci, seperti saat pengguna berolahraga. Ini disimpan di Perlindungan Data kelas Dilindungi Kecuali Terbuka. Setelah dibuka, rekaman kesehatan diimpor ke basis data kesehatan utama, lalu dihapus setelah penggabungan selesai. Data kesehatan tidak diselaraskan antara perangkat. Data kesehatan disertakan di cadangan perangkat di iCloud dan di cadangan iTunes yang dienkripsi. Data kesehatan tidak disertakan di cadangan iTunes yang tidak terenkripsi.

Integritas Data

Data yang disimpan di basis data meliputi metadata untuk melacak sumber setiap rekaman data. Metadata ini berisi pengenal aplikasi yang mengidentifikasi app yang disimpan di rekaman. Selain itu, item metadata opsional dapat berisi salinan rekaman yang ditandatangani secara digital. Ini dimaksudkan untuk menyediakan integritas data untuk rekaman yang dibuat oleh perangkat tepercaya. Format yang digunakan untuk tanda tangan digital adalah Sintaks Pesan Kriptografis (CMS) yang tercantum di IETF RFC 5652.

Akses oleh app pihak ketiga

Akses ke API HealthKit dikontrol dengan hak, dan app harus menaati pembatasan mengenai cara menggunakan data. Misalnya, app tidak diizinkan untuk menggunakan data kesehatan untuk pengiklanan. App juga diharuskan untuk menyediakan kebijakan privasi yang merinci penggunaan data kesehatan kepada pengguna. Akses app ke data kesehatan dikontrol oleh pengaturan Privasi pengguna. Pengguna diminta untuk memberikan akses saat app meminta akses ke data kesehatan, sama dengan Kontak, Foto, dan sumber data iOS lainnya. Namun, dengan data kesehatan, app diberi akses terpisah untuk membaca dan menulis data, seperti akses terpisah untuk setiap jenis data kesehatan. Pengguna dapat melihat, dan membatalkan, izin yang telah mereka berikan untuk mengakses data kesehatan di tab Sumber di app Kesehatan. Jika diberi izin untuk menulis data, app juga dapat membaca data yang mereka tulis. Jika diberi izin untuk membaca data, app dapat membaca data yang ditulis oleh semua sumber. Namun, app tidak dapat menentukan akses yang diberikan ke app lainnya. Selain itu, app tidak dapat mengetahui secara pasti apakah app telah diberi akses baca ke data kesehatan. Jika app tidak memiliki akses baca, semua permintaan tidak menghasilkan data—respons yang sama dengan yang diberikan basis data kosong. Ini mencegah app untuk menyimpulkan status kesehatan pengguna dengan mempelajari jenis data yang dilacak pengguna.

ID Medis

App Kesehatan memberi pengguna pilihan untuk mengisi formulir ID Medis dengan informasi yang mungkin penting selama keadaan darurat medis. Informasi dimasukkan atau diperbarui secara manual dan tidak diselaraskan dengan informasi di basis data kesehatan. Informasi ID Medis dapat dilihat dengan mengetuk tombol Darurat di layar Terkunci. Informasi disimpan di perangkat menggunakan kelas Perlindungan Data Tidak Ada Perlindungan sehingga dapat diakses tanpa harus memasukkan kode sandi perangkat. ID Medis adalah fitur opsional yang memungkinkan pengguna untuk menentukan cara menyeimbangkan masalah keselamatan dan privasi.


26

Catatan Aman App Catatan dilengkapi dengan fitur Catatan Aman yang memungkinkan pengguna untuk melindungi konten catatan tertentu. Catatan aman dienkripsi menggunakan frasa sandi yang diberikan pengguna dan diperlukan untuk melihat catatan di iOS, OS X, dan situs web iCloud. Saat pengguna mengamankan catatan, kunci 16 bita diturunkan dari frasa sandi pengguna menggunakan PBKDF2 dan SHA256. Konten catatan dienkripsi menggunakan AES-GCM. Rekaman baru dibuat di Data Inti dan CloudKit untuk menyimpan catatan yang dienkripsi, label, dan vektor inisialisasi, dan rekaman catatan asli dihapus dan tidak digantikan oleh data yang dienkripsi. Lampiran juga dienkripsi dengan cara yang sama. Lampiran yang didukung meliputi gambar, sketsa, peta, dan situs web. Catatan yang berisi jenis lampiran lainnya tidak dapat dienkripsi, dan lampiran yang tidak didukung tidak dapat ditambahkan ke catatan aman. Saat pengguna berhasil memasukkan frasa sandi, baik itu untuk melihat atau membuat catatan aman, Catatan akan membuka sesi aman. Saat terbuka, pengguna tidak diharuskan untuk memasukkan frasa sandi, atau menggunakan Touch ID, untuk melihat atau mengamankan catatan lain. Namun, jika sebagian catatan memiliki frasa sandi yang berbeda, sesi aman hanya berlaku bagi catatan yang dilindungi dengan frasa sandi saat ini. Sesi aman akan ditutup saat pengguna mengetuk tombol Kunci Sekarang di Catatan, saat Catatan dialihkan ke latar belakang selama lebih dari tiga menit, atau saat perangkat dikunci. Pengguna yang lupa frasa sandinya masih dapat melihat catatan aman atau catatan tambahan aman jika mengaktifkan Touch ID di perangkat mereka. Selain itu, Catatan akan menampilkan petunjuk yang diberikan pengguna setelah tiga upaya gagal untuk memasukkan frasa sandi. Pengguna harus mengetahui frasa sandi saat ini agar dapat mengubahnya. Pengguna dapat mengatur ulang frasa sandi saat ini jika mereka lupa. Fitur ini memungkinkan pengguna untuk membuat catatan aman baru dengan frasa sandi baru, tapi tidak akan memungkinkan mereka untuk melihat catatan yang diamankan sebelumnya. Catatan yang diamankan sebelumnya masih dapat dilihat jika pengguna ingat frasa sandi lama. Pengaturan ulang frasa sandi memerlukan frasa sandi akun iCloud pengguna.

Apple Watch Apple Watch menggunakan fitur dan teknologi keamanan yang terdapat di iOS untuk membantu melindungi data di perangkat, serta fitur dan teknologi komunikasi dengan iPhone yang dipasangkan dan Internet. Ini meliputi teknologi seperti Perlindungan Data dan kontrol akses rantai kunci. Kode sandi pengguna dikaitkan dengan UID perangkat untuk membuat kunci enkripsi. Pemasangan Apple Watch dengan iPhone diamankan menggunakan proses luar jalur (OOB) untuk menukar kunci publik, diikuti oleh rahasia bersama tautan BTLE. Apple Watch menampilkan pola animasi, yang diambil oleh kamera iPhone. Pola berisi rahasia dikodekan yang digunakan untuk pemasangan luar jalur BTLE 4.1. Entri Kunci Pass BTLE Standar digunakan sebagai metode pemasangan balik, jika perlu. Setelah sesi BTLE dibuat, Apple Watch dan iPhone bertukar kunci menggunakan proses yang diadaptasi dari IDS, sebagaimana yang dijelaskan di bagian iMessage di dokumen ini. Setelah kunci ditukar, kunci sesi Bluetooth dihapus, dan semua komunikasi antara Apple Watch dan iPhone dienkripsi menggunakan IDS, dengan tautan BTLE dan Wi-Fi yang dienkripsi sehingga menyediakan lapisan enkripsi kedua. Penggantian kunci dilakukan dengan selang waktu 15 menit untuk membatasi jendela pemaparan, jika lalu lintas terganggu. Keamanan iOS—Buku Putih | Mei 2016

27

Untuk mendukung app yang memerlukan streaming data, enkripsi disediakan dengan metode yang dijelaskan di bagian FaceTime dokumen ini, menggunakan layanan IDS yang disediakan oleh iPhone yang dipasangkan. Apple Watch menerapkan penyimpanan berenkripsi perangkat keras dan perlindungan berbasis kelas untuk file dan item rantai kunci, sebagaimana yang dijelaskan di bagian Perlindungan Data dokumen ini. Kantong kunci dengan akses terkontrol untuk item rantai kunci juga digunakan. Kunci yang digunakan untuk komunikasi antara jam dan iPhone juga diamankan menggunakan perlindungan berbasis kelas. Saat Apple Watch tidak dalam jangkauan Bluetooth, Wi-Fi dapat digunakan sebagai gantinya. Apple Watch tidak akan bergabung dengan jaringan Wi-Fi kecuali jika terdapat info pengesahan untuk melakukannya di iPhone yang dipasangkan, yang menyediakan daftar jaringan yang dikenali ke jam secara otomatis. Apple Watch dapat dikunci secara manual dengan menahan tombol samping. Selain itu, heuristik gerakan digunakan untuk mencoba mengunci perangkat secara otomatis sesaat setelah dilepas dari pergelangan tangan. Saat terkunci, Apple Pay tidak dapat digunakan. Jika penguncian otomatis yang disediakan oleh deteksi pergelangan tangan dimatikan di pengaturan, Apple Pay akan dinonaktifkan. Deteksi pergelangan tangan dimatikan menggunakan app Apple Watch di iPhone. Pengaturan ini juga dapat diterapkan menggunakan mobile device management. iPhone yang dipasangkan juga dapat membuka jam, jika jam sedang dikenakan. Ini dapat dilakukan dengan membuat koneksi yang disahkan oleh kunci yang dibuka selama pemasangan. iPhone mengirimkan kunci, yang digunakan jam untuk membuka kunci Perlindungan Datanya. Kode sandi jam tidak diketahui oleh iPhone dan juga tidak ditransmisikan. Fitur ini dapat dimatikan menggunakan app Apple Watch di iPhone. Apple Watch dapat dipasangkan dengan hanya satu iPhone. Pemasangan dengan iPhone baru akan menghapus semua konten dan data dari Apple Watch secara otomatis. Jika Cari iPhone Saya diaktifkan di iPhone yang dipasangkan, Kunci Aktivasi di Apple Watch juga akan diaktifkan. Kunci Aktivasi menyulitkan orang untuk menggunakan atau menjual Apple Watch yang telah hilang atau dicuri. Kunci Aktivasi memerlukan ID Apple dan kata sandi pengguna untuk melepaskan, menghapus, atau mengaktifkan kembali Apple Watch.


28

Keamanan Jaringan Selain pengamanan internal yang digunakan Apple untuk melindungi data yang disimpan di perangkat iOS, ada banyak tindakan pengamanan jaringan yang dapat digunakan organisasi untuk menjaga keamanan informasi saat dikirimkan dari dan ke perangkat iOS. Pengguna perangkat bergerak harus dapat mengakses jaringan perusahaan dari mana pun di dunia, sehingga penting untuk memastikan bahwa mereka disahkan dan data mereka terlindungi selama transmisi. iOS menggunakan–dan menyediakan akses pengembang ke—protokol jaringan standar untuk komunikasi yang dienkripsi, diizinkan, dan disahkan. Untuk mencapai tujuan ini, iOS memadukan teknologi yang teruji dan standar terbaru untuk koneksi jaringan data seluler Wi-Fi. Di platform lain, perangkat lunak firewall diperlukan untuk melindungi port komunikasi terbuka dari gangguan. Karena iOS mengurangi ruang serangan dengan membatasi port transmisi dan menghapus utilitas jaringan yang tidak diperlukan seperti telnet, shell, atau server web, tidak ada perangkat lunak firewall tambahan yang diperlukan di perangkat iOS.

TLS iOS mendukung Keamanan Lapisan Transpor (TLS v1.0, TLS v1.1, TLS v1.2) dan DTLS. Safari, Kalender, Mail, dan app Internet lainnya menggunakan mekanisme ini secara otomatis untuk mengaktifkan saluran komunikasi terenkripsi antara perangkat dan layanan jaringan. API Level Tinggi (seperti CFNetwork) memudahkan pengembang untuk mengadopsi TLS di app mereka, sementara API level rendah (SecureTransport) menyediakan kontrol cermat. Secara default, CFNetwork tidak mengizinkan SSLv3, dan app yang menggunakan WebKit (seperti Safari) dilarang membuat koneksi SSLv3.

Keamanan Transpor App

Keamanan Transpor App menyediakan persyaratan koneksi default sehingga app diharuskan untuk mengutamakan koneksi aman saat menggunakan API NSURLConnection, CFULR, atau NSURLSession. Server setidaknya harus mendukung TLS 1.2, kerahasiaan berkelanjutan, dan sertifikat harus sah dan ditandatangani menggunakan SHA-256 atau lebih baik dengan setidaknya kunci RSA 2048 bit atau kunci kurva elips 256 bit. Koneksi jaringan yang tidak memenuhi persyaratan ini akan gagal, kecuali jika app menimpa Keamanan Transpor App. Sertifikat yang tidak sah selalu mengakibatkan kegagalan perangkat keras dan tidak adanya koneksi. Keamanan Transpor App diterapkan ke app yang dibuat untuk iOS 9 secara otomatis.


29

VPN Layanan jaringan aman, seperti jaringan pribadi virtual biasanya memerlukan sedikit pengaturan dan konfigurasi agar dapat digunakan dengan perangkat iOS. Perangkat iOS dapat digunakan dengan server VPN yang mendukung protokol dan metode pengesahan berikut: • IKEv2/IPSec dengan pengesahan oleh rahasia bersama, Sertifikat RSA, Sertifikat ECDSA, EAP-MSCHAPv2, atau EAP-TLS. • VPN SSL Pulse Secure, Cisco, Aruba Networks, SonicWALL, Check Point, Palo Alto Networks, Open VPN, AirWatch, MobileIron, NetMotion Wireless, dan F5 Networks yang menggunakan app klien yang sesuai dari App Store. • Cisco IPSec dengan pengesahan pengguna menggunakan Kata Sandi, RSA SecurID atau CRYPTOCard, dan pengesahan otomatis menggunakan rahasia bersama dan sertifikat. • L2TP/IPSec dengan pengesahan pengguna menggunakan Kata Sandi MS-CHAPV2, RSA SecurID atau CRYPTOCard, dan pengesahan otomatis menggunakan rahasia bersama. • PPTP dengan pengesahan pengguna menggunakan Kata Sandi MS-CHAPV2 dan RSA SecurID or CRYPTOCard didukung, tapi tidak dianjurkan. iOS mendukung VPN Menurut Permintaan untuk jaringan yang menggunakan pengesahan berbasis sertifikat. Kebijakan TI menetapkan domain mana yang memerlukan koneksi VPN menggunakan profil konfigurasi. iOS juga mendukung VPN Per App, memfasilitasi koneksi VPN pada level yang lebih kecil. Mobile device management (MDM) dapat menetapkan koneksi untuk tiap app yang dikelola dan/atau domain tertentu di Safari. Ini membantu memastikan bahwa data aman selalu menuju dan berasal dari jaringan perusahaan—dan data pribadi pengguna tidak. iOS mendukung VPN Selalu Nyala, yang dapat dikonfigurasi untuk perangkat yang dikelola melalui MDM dan diawasi menggunakan Apple Configurator atau Program Pendaftaran Perangkat. Ini memungkinkan pengguna untuk menghubungkan ke jaringan seluler atau Wi-Fi tanpa harus menyalakan VPN. VPN Selalu Nyala memberi organisasi kontrol penuh atas lalu lintas perangkat dengan menyalurkan lalu lintas IP ke perusahaan. Protokol penyaluran default, IKEv2, mengamankan transmisi lalu lintas dengan enkripsi data. Organisasi kini dapat mengawasi dan memfilter lalu lintas dari dan ke perangkatnya, mengamankan data di jaringannya, dan membatasi akses perangkat ke Internet.

Wi-Fi iOS mendukung protokol Wi-Fi standar industri, termasuk WPA2 Perusahaan, untuk menyediakan akses yang sah ke jaringan perusahaan nirkabel. WPA2 Perusahaan menggunakan enkripsi AES 128 bit, sehingga memberi pengguna jaminan tertinggi bahwa datanya tetap terlindungi saat mengirimkan dan menerima komunikasi melalui koneksi jaringan Wi-Fi. Dengan dukungan untuk 802.1X, perangkat iOS dapat dipadukan dengan berbagai lingkungan pengesahan RADIUS. Metode pengesahan nirkabel 802.1X yang didukung di iPhone dan iPad meliputi EAP-TLS, EAP-TTLS, EAP-FAST, EAP-SIM, PEAPv0, PEAPv1, dan LEAP. iOS menggunakan alamat Kontrol Akses Media (MAC) acak saat melakukan pemindaian Pengeluaran Jaringan Pilihan (PNO) ketika perangkat tidak dihubungkan dengan jaringan Wi-Fi dan ketika prosesornya tidur. Prosesor perangkat akan tidur segera setelah layar dimatikan. Pemindaian PNO dijalankan untuk menentukan apakah pengguna dapat terhubung ke jaringan Wi-Fi yang dipilih untuk melakukan aktivitas seperti menyelaraskan dengan iTunes secara nirkabel. Keamanan iOS—Buku Putih | Mei 2016

30

iOS juga menggunakan alamat MAC acak saat melakukan pemindaian Pengeluaran Jaringan Pilihan yang ditingkatkan (ePNO) jika perangkat tidak dikaitkan dengan jaringan Wi-Fi atau prosesornya tidur. Pemindaian ePNO dijalankan saat perangkat menggunakan Layanan Lokasi untuk app yang menggunakan geofence, seperti pengingat berbasis lokasi yang menentukan apakah perangkat berada di dekat lokasi tertentu. Karena alamat MAC perangkat kini berubah saat tidak terhubung ke jaringan Wi-Fi, alamat MAC tidak dapat digunakan untuk melacak perangkat secara terus menerus dengan pengamat pasif dari lalu lintas Wi-Fi, bahkan saat perangkat terhubung ke jaringan seluler. Kami telah bekerja sama dengan produsen Wi-Fi agar mereka tahu bahwa pemindaian latar belakang menggunakan alamat MAC acak, dan bahwa Apple atau produsen tidak dapat memprediksi alamat MAC acak ini. Pengacakan alamat MAC Wi-Fi tidak didukung di iPhone 4s.

Bluetooth Dukungan Bluetooth di iOS telah dirancang untuk menyediakan fungsi yang berguna tanpa akses yang tidak perlu ke data pribadi. Perangkat iOS mendukung koneksi Enkripsi Mode 3, Keamanan Mode 4, dan Layanan Level 1. iOS mendukung profil Bluetooth berikut: • Profil Bebas Tangan (HFP 1.5) • Profil Akses Buku Telepon (PBAP) • Profil Distribusi Audio Lanjutan (A2DP) • Profil Kontrol Remote Audio/Video (AVRCP) • Profil Jaringan Area Pribadi (PAN) • Profil Perangkat Antarmuka Manusia (HID) Dukungan untuk profil ini berbeda-beda menurut perangkat. Untuk informasi lainnya, lihat support.apple.com/kb/ht3647?viewlocale=id_ID.

Masuk Tunggal iOS mendukung pengesahan ke jaringan perusahaan melalui Masuk Tunggal (SSO). SSO dapat digunakan dengan jaringan berbasis Kerberos untuk mengesahkan pengguna memiliki wewenang atas akses layanan. SSO dapat digunakan untuk berbagai aktivitas jaringan, dari sesi Safari aman hingga app pihak ketiga. SSO iOS menggunakan token SPNEGO dan protokol Negosiasi HTTP untuk bekerja dengan gateway pengesahan berbasis Kerberos dan Pengesahan Terpadu Windows yang mendukung tiket Kerberos. Pengesahan berbasis sertifikat juga didukung. Dukungan SSO didasarkan pada proyek Heimdal sumber terbuka. Jenis enkripsi berikut didukung: • AES128-CTS-HMAC-SHA1-96 • AES256-CTS-HMAC-SHA1-96 • DES3-CBC-SHA1 • ARCFOUR-HMAC-MD5 Safari mendukung SSO, dan app pihak ketiga yang menggunakan API jaringan iOS standar yang juga dapat dikonfigurasi untuk menggunakannya. Untuk mengonfigurasi SSO, iOS mendukung muatan profil konfigurasi yang memungkinkan server MDM untuk menonaktifkan pengaturan yang diperlukan. Ini meliputi pengaturan nama


31

pokok pengguna (yaitu, akun pengguna Direktori Aktif ) dan pengaturan realm Kerberos, serta konfigurasi mengenai app dan/atau URL web Safari mana yang harus diizinkan untuk menggunakan SSO.

Keamanan AirDrop Perangkat iOS yang mendukung AirDrop menggunakan teknologi Bluetooth Rendah Energi (BLE) dan teknologi Wi-Fi rekan-ke-rekan yang dibuat Apple untuk mengirimkan file dan informasi ke perangkat di sekitar, termasuk komputer Mac yang kompatibel dengan AirDrop yang menjalankan OS X Yosemite atau lebih baru. Radio Wi-Fi digunakan untuk berkomunikasi langsung antarperangkat tanpa menggunakan koneksi Internet atau Titik Akses Wi-Fi. Saat pengguna mengaktifkan AirDrop, identitas RSA 2048 bit akan disimpan di perangkat. Selain itu, hash identitas AirDrop dibuat berdasarkan alamat email dan nomor telepon yang dikaitkan dengan ID Apple pengguna. Saat pengguna memilih AirDrop sebagai metode untuk berbagi item, perangkat akan memancarkan sinyal AirDrop melalui Bluetooth Rendah Energi. Perangkat lain yang bangun, dalam jarak yang dekat, dan dengan AirDrop dinyalakan saat mendeteksi sinyal dan merespons dengan versi singkat dari hash identitas pemiliknya. AirDrop diatur agar berbagi dengan Hanya Kontak secara default. Pengguna juga dapat memilih jika mereka ingin dapat menggunakan AirDrop untuk berbagi dengan Semua Orang atau sepenuhnya mematikan fitur ini. Dalam mode Hanya Kontak, hash identitas yang diterima dibandingkan dengan hash orang di app Kontak inisiator. Jika kecocokan ditemukan, perangkat pengirim akan membuat jaringan Wi-Fi rekan-ke-rekan dan menawarkan koneksi AirDrop menggunakan Bonjour. Dengan menggunakan koneksi ini, perangkat penerima akan mengirimkan hash identitas lengkap ke inisiator. Jika hash lengkap cocok dengan Kontak, nama depan dan foto penerima (jika ada di Kontak) akan ditampilkan di lembar berbagi AirDrop. Saat menggunakan AirDrop, pengguna pengirim memilih rekan berbagi mereka. Perangkat penerima memulai koneksi terenkripsi (TLS) dengan perangkat pengirim, yang akan menukar sertifikat identitas iCloud kedua perangkat. Identitas di sertifikat diverifikasi berdasarkan app Kontak masing-masing pengguna. Lalu pengguna penerima diminta untuk menerima transfer masuk dari orang atau perangkat yang telah diidentifikasi. Jika beberapa penerima telah dipilih, proses ini akan diulangi untuk setiap tujuan. Dalam mode Semua Orang, proses yang sama digunakan tapi jika kecocokan di Kontak tidak ditemukan, perangkat penerima akan ditampilkan di lembar pengirim AirDrop dengan siluet dan nama perangkat, sebagaimana yang dijelaskan di Pengaturan > Umum > Mengenai > Nama. Organisasi dapat membatasi penggunaan AirDrop untuk perangkat atau app yang sedang dikelola oleh solusi mobile device management.


32

Apple Pay Dengan Apple Pay, pengguna dapat menggunakan perangkat iOS yang didukung dan Apple Watch untuk bertransaksi secara mudah, aman, dan pribadi. Mudah digunakan bagi pengguna, dan dibuat dengan keamanan terpadu di perangkat keras dan perangkat lunak. Apple Pay juga dirancang untuk melindungi informasi pribadi pengguna. Apple Pay tidak mengumpulkan informasi transaksi yang dapat dikaitkan kembali dengan pengguna. Transaksi pembayaran terdapat di antara pengguna, penjual, dan penerbit kartu.

Komponen Apple Pay Elemen Aman: Elemen Aman adalah keping berstandar industri yang bersertifikat, menjalankan platform Java Card, dan tunduk pada persyaratan industri keuangan untuk pembayaran elektronik. Pengontrol NFC: Pengontrol NFC menangani protokol Komunikasi Jarak Dekat dan menyalurkan komunikasi antara prosesor aplikasi dan Elemen Aman, serta antara Elemen Aman dan terminal titik penjualan. Wallet: Wallet digunakan untuk menambah dan mengelola kartu kredit, debit, hadiah, dan toko serta untuk melakukan pembayaran dengan Apple Pay. Pengguna dapat melihat kartu mereka dan informasi tambahan mengenai penerbit kartu, kebijakan privasi penerbit kartu, transaksi terbaru, dan lainnya di Wallet. Pengguna juga dapat menambahkan kartu ke Apple Pay di Asisten Pengaturan dan Pengaturan. Enklave Aman: Di iPhone dan iPad, Enklave Aman mengelola proses pengesahan dan memungkinkan proses transaksi pembayaran untuk dilanjutkan. Enklave Aman menyimpan data sidik jari untuk Touch ID. Di Apple Watch, perangkat harus dibuka, dan pengguna harus mengeklik tombol samping dua kali. Klik dua kali akan terdeteksi dan diteruskan ke Elemen Aman secara langsung tanpa melalui prosesor aplikasi. Server Apple Pay: Server Apple Pay mengelola status kartu kredit dan debit di Wallet dan Nomor Akun Perangkat yang tersimpan di Elemen Aman. Server berkomunikasi dengan perangkat dan server jaringan pembayaran. Server Apple Pay juga bertanggung jawab untuk enkripsi ulang info pengesahan pembayaran untuk pembayaran di dalam app.

Bagaimana Apple Pay menggunakan Elemen Aman Elemen Aman memiliki applet yang dirancang secara khusus untuk mengelola Apple Pay. Elemen Aman juga berisi applet pembayaran yang disertifikasi oleh jaringan pembayaran. Data kartu kredit atau debit dikirimkan dari jaringan pembayaran atau penerbit kartu yang dienkripsi untuk applet pembayaran ini menggunakan kunci yang hanya diketahui oleh jaringan pembayaran dan domain keamanan applet pembayaran. Data ini disimpan di dalam applet pembayaran ini dan dilindungi menggunakan fitur keamanan Elemen Aman. Selama transaksi, terminal akan berkomunikasi secara langsung dengan Elemen Aman melalui pengontrol Komunikasi Jarak Dekat (NFC) melalui bus perangkat keras khusus.


33

Bagaimana Apple Pay menggunakan pengontrol NFC Sebagai gateway menuju Elemen Aman, pengontrol NFC memastikan bahwa semua transaksi pembayaran nirkontak dilakukan menggunakan terminal titik penjualan yang dekat dengan perangkat. Hanya permintaan pembayaran dari terminal jarak dekat yang ditandai oleh pengontrol NFC sebagai transaksi nirkontak. Setelah pembayaran disahkan oleh pemegang kartu menggunakan Touch ID atau kode sandi, atau di Apple Watch yang terbuka dengan mengeklik tombol samping dua kali, respons nirkontak yang disiapkan oleh applet pembayaran di dalam Elemen Aman dirutekan secara eksklusif oleh pengontrol ke area NFC. Karenanya, detail pengesahan pembayaran untuk transaksi nirkontak disimpan di area NFC lokal dan tidak pernah dipaparkan pada prosesor aplikasi. Di sisi lain, detail pengesahan untuk pembayaran di dalam app dirutekan ke prosesor aplikasi, tapi hanya setelah enkripsi oleh Elemen Aman ke Server Apple Pay.

Penyediaan kartu kredit dan debit Saat pengguna menambahkan kartu kredit atau debit (termasuk kartu toko) ke Apple Pay, Apple akan mengirimkan informasi kartu dengan aman, bersama dengan informasi lainnya mengenai akun dan perangkat pengguna, ke penerbit kartu. Penerbit kartu akan menentukan apakah mereka akan menyetujui penambahan kartu ke Apple Pay atau tidak dengan menggunakan informasi tersebut. Apple Pay menggunakan tiga perintah di server untuk mengirimkan dan menerima komunikasi dengan penerbit kartu atau jaringan sebagai bagian dari proses penyediaan kartu: Bidang yang Diperlukan, Periksa Kartu, dan Penautan dan Penyediaan. Penerbit kartu atau jaringan menggunakan tiga perintah ini untuk memverifikasi, menyetujui, dan menambahkan kartu ke Apple Pay. Sesi server klien ini dienkripsi menggunakan SSL. Nomor lengkap kartu tidak disimpan di perangkat atau di server Apple. Sebagai gantinya, Nomor Akun Perangkat unik dibuat, dienkripsi, dan kemudian disimpan di Elemen Aman. Nomor Akun Perangkat unik ini dienkripsi dengan cara yang tidak memungkinkan Apple untuk mengaksesnya. Nomor Akun Perangkat bersifat unik dan berbeda dari nomor kartu kredit atau debit biasa, penerbit kartu dapat mencegah penggunaannya pada kartu garis magnetik, melalui telepon, atau di situs web. Nomor Akun Perangkat di Elemen Aman diisolasi dari iOS dan WatchOS, tidak pernah disimpan di Server Apple Pay, dan tidak pernah dicadangkan ke iCloud. Kartu yang diperuntukkan bagi Apple Watch disediakan kepada Apple Pay menggunakan app Apple Watch di iPhone. Untuk menyediakan kartu kepada Apple Watch, jam harus berada di jangkauan komunikasi Bluetooth. Kartu didaftarkan secara khusus untuk digunakan dengan Apple Watch dan memiliki Nomor Akun Perangkat-nya sendiri, yang disimpan di dalam Elemen Aman di Apple Watch. Ada tiga cara untuk menyediakan kartu kredit atau debit untuk Apple Pay: • Menambahkan kartu kredit/debit secara manual ke Apple Pay • Menambahkan kartu kredit atau debit yang digunakan dari akun iTunes Store ke Apple Pay • Menambahkan kartu kredit atau debit dari app penerbit kartu

Menambahkan kartu kredit atau debit secara manual ke Apple Pay

Untuk menambahkan kartu secara manual, termasuk kartu toko, nama, nomor kartu kredit, tanggal kedaluwarsa, dan CVV akan digunakan untuk memfasilitasi proses penyediaan. Dari dalam Pengaturan, app Wallet, atau app Apple Watch, pengguna dapat memasukkan informasi tersebut dengan mengetikkannya, atau menggunakan


34

kamera iSight. Saat kamera mengambil informasi kartu, Apple akan mencoba untuk mengisi nama, nomor kartu, dan tanggal kedaluwarsa. Foto tidak pernah disimpan ke perangkat atau disimpan di perpustakaan foto. Setelah semua bidang diisi, proses Periksa Kartu akan memverifikasi bidang selain CVV. Data dienkripsi dan dikirimkan ke Server Apple Pay. Jika ID syarat dan ketentuan dikembalikan bersama dengan proses Periksa Kartu, Apple akan mengunduh dan menampilkan syarat dan ketentuan penerbit kartu ke pengguna. Jika pengguna menerima syarat dan ketentuan, Apple akan mengirimkan ID syarat yang diterima, serta CVV ke proses Penautan dan Penyediaan. Selain itu, sebagai bagian dari proses Penautan dan Penyediaan, Apple berbagi informasi dari perangkat dengan penerbit kartu atau jaringan, seperti informasi mengenai aktivitas akun iTunes dan App Store Anda (misalnya, apakah Anda memiliki riwayat transaksi yang panjang di iTunes), informasi mengenai perangkat Anda (misalnya, nomor telepon, nama, dan model perangkat, serta perangkat iOS pelengkap yang diperlukan untuk mengatur Apple Pay), serta perkiraan lokasi Anda pada saat menambahkan kartu (jika Anda mengaktifkan Layanan Lokasi). Penerbit kartu akan menentukan apakah mereka akan menyetujui penambahan kartu ke Apple Pay atau tidak dengan menggunakan informasi tersebut. Sebagai akibat dari proses Penautan dan Penyediaan, dua hal terjadi: • Perangkat mulai mengunduh file pass Wallet yang mewakili kartu kredit atau debit. • Perangkat mulai mengikat kartu ke Elemen Aman. File pass berisi URL untuk mengunduh gambar kartu, metadata mengenai kartu seperti informasi kontak, app penerbit terkait, dan fitur yang didukung. File pass juga berisi status pass, yang dilengkapi dengan informasi seperti apakah penyesuaian Elemen Aman telah selesai, apakah kartu sedang ditangguhkan oleh penerbit kartu, apakah pengesahan tambahan diperlukan sebelum kartu dapat digunakan untuk bertransaksi dengan Apple Pay.

Menambahkan kartu kredit atau debit dari akun iTunes Store ke Apple Pay

Untuk kartu kredit atau debit yang digunakan dengan iTunes, pengguna dapat diwajibkan untuk memasukkan kembali kata sandi ID Apple mereka. Nomor kartu diambil dari iTunes dan proses Periksa Kartu akan dimulai. Jika kartu layak untuk Apple Pay, perangkat akan mengunduh dan menampilkan syarat dan ketentuan, kemudian mengirimkan ID syarat dan kode keamanan kartu ke proses Penautan dan Penyediaan. Verifikasi tambahan dapat dilakukan untuk kartu akun iTunes yang digunakan.

Menambahkan kartu kredit atau debit dari app penerbit kartu

Saat app didaftarkan untuk digunakan dengan Apple Pay, kunci akan dibuat untuk app dan server penjual. Kunci ini digunakan untuk mengenkripsi informasi kartu yang dikirimkan ke penjual, yang mencegah informasi untuk dibaca oleh perangkat iOS. Alur penyediaan ini mirip dengan yang digunakan untuk kartu yang ditambahkan secara manual, yang dijelaskan di atas, kecuali bahwa kata sandi sekali pakai digunakan sebagai ganti CVV.

Verifikasi tambahan

Penerbit kartu dapat memutuskan apakah kartu kredit atau debit memerlukan verifikasi tambahan atau tidak. Bergantung pada apa yang ditawarkan oleh penerbit kartu, pengguna dapat memilih berbagai opsi untuk verifikasi tambahan, seperti pesan teks, email, panggilan layanan konsumen, atau metode di app pihak ketiga yang disetujui untuk menyelesaikan verifikasi. Untuk pesan teks atau email, pengguna memilih dari informasi kontak yang dimiliki penerbit. Kode akan dikirimkan, yang harus dimasukkan oleh pengguna ke Wallet, Pengaturan, atau app Apple Watch. Untuk layanan konsumen atau verifikasi menggunakan app, penerbit melakukan proses komunikasinya sendiri.


35

Pengesahan pembayaran Elemen Aman hanya akan mengizinkan pembayaran untuk dilakukan setelah menerima pengesahan dari Enklave Aman, yang mengonfirmasi bahwa pengguna telah mengesahkan dengan Touch ID atau kode sandi perangkat. Touch ID adalah metode default jika tersedia, tapi kode sandi dapat digunakan setiap saat sebagai pengganti Touch ID. Kode sandi ditawarkan secara otomatis setiap tiga percobaan gagal untuk mencocokkan sidik jari dan setelah lima percobaan gagal, kode sandi akan diwajibkan. Kode sandi juga diperlukan saat Touch ID tidak dikonfigurasi atau tidak diaktifkan untuk Apple Pay. Komunikasi antara Enklave Aman dan Elemen Aman berlangsung melalui antarmuka serial, dengan Elemen Aman yang terhubung ke pengontrol NFC, yang pada gilirannya akan dihubungkan ke prosesor aplikasi. Meskipun tidak terhubung secara langsung, Enklave Aman dan Elemen Aman dapat berkomunikasi secara aman menggunakan kunci pemasangan bersama yang disediakan selama proses produksi. Enkripsi dan pengesahan komunikasi didasarkan pada AES, dengan nilai sekali pakai kriptografis yang digunakan oleh kedua pihak untuk melindungi dari serangan pemutaran ulang. Kunci pemasangan dibuat di dalam Enklave Aman dari kunci UID-nya dan pengenal unik Elemen Aman. Kunci pemasangan kemudian ditransfer secara aman dari Enklave Aman ke modul keamanan perangkat keras (HSM) di pabrik, yang memiliki materi pokok yang diperlukan untuk memasukkan kunci pemasangan ke Elemen Aman. Saat pengguna mengesahkan transaksi, Enklave Aman akan mengirimkan data bertanda tangan mengenai jenis pengesahan dan detail mengenai jenis transaksi (nirkontak atau di dalam app) ke Elemen Aman, yang dikaitkan dengan nilai Pengesahan Acak (AR). AR dibuat di Enklave Aman saat pengguna menyediakan kartu kredit untuk pertama kalinya dan dipertahankan saat Apple Pay diaktifkan, dilindungi oleh enkripsi Enklave Aman dan mekanisme anti-rollback. AR dikirimkan dengan aman ke Elemen Aman melalui kunci pemasangan. Setelah menerima nilai AR baru, Elemen Aman menandai setiap kartu yang ditambahkan sebelumnya sebagai dihapus. Kartu kredit dan debit yang ditambahkan ke Elemen Aman hanya dapat digunakan jika Elemen Aman diberikan dengan pengesahan menggunakan kunci pemasangan yang sama dan nilai AR dari saat kartu ditambahkan. Ini juga memungkinkan iOS untuk menginstruksikan Enklave Aman untuk membuat kartu menjadi tidak dapat digunakan dengan menandai salinan AR-nya sebagai tidak sah dengan skenario berikut. Saat kode sandi dinonaktifkan. • Pengguna keluar dari iCloud. • Pengguna memilih Hapus Konten & Pengaturan. • Perangkat dipulihkan dari mode pemulihan. Dengan Apple Watch, kartu ditandai sebagai tidak sah jika: • Kode sandi jam dinonaktifkan. • Jam dilepaskan dari iPhone. • Deteksi pergelangan tangan dimatikan. Dengan menggunakan kunci pemasangan dan salinan nilai AR-nya saat ini, Elemen Aman memverifikasi pengesahan yang diterima dari Enklave Aman sebelum mengaktifkan applet pembayaran untuk pembayaran nirkontak. Proses ini juga berlaku saat menerima data pembayaran yang dienkripsi dari applet pembayaran untuk transaksi di dalam app.


36

Kode keamanan dinamis khusus transaksi Semua transaksi pembayaran dari applet pembayaran termasuk kode keamanan dinamis khusus transaksi dan Nomor Akun Perangkat. Kode sekali pakai ini dihitung menggunakan penghitung yang ditambah untuk setiap transaksi baru, dan kunci yang disediakan di applet pembayaran selama penyesuaian dan dikenali oleh jaringan pembayaran dan/atau penerbit kartu. Bergantung pada skema pembayaran, data lainnya juga dapat digunakan dalam penghitungan kode ini, termasuk yang berikut: • Nomor acak yang dibuat oleh applet pembayaran • Nomor acak lain yang dibuat oleh terminal—pada transaksi NFC atau • Nomor acak lain yang dibuat oleh server—pada transaksi di dalam app Kode keamanan ini disediakan untuk jaringan pembayaran dan penerbit kartu, yang memungkinkan mereka untuk memverifikasi setiap transaksi. Panjang kode keamanan ini dapat berbeda-beda tergantung jenis transaksi yang sedang dilakukan.

Pembayaran nirkontak dengan Apple Pay Jika iPhone menyala dan mendeteksi area NFC, iPhone akan menawari pengguna kartu kredit atau debit yang relevan, atau kartu default, yang dikelola di Pengaturan. Pengguna juga dapat membuka app Wallet dan memilih kartu kredit atau debit, atau saat perangkat dikunci, mengeklik tombol Utama dua kali. Selanjutnya, pengguna harus mengesahkan menggunakan Touch ID atau kode sandi mereka sebelum informasi pembayaran dikirimkan. Setelah Apple Watch dibuka, kartu default untuk pembayaran akan diaktifkan jika tombol samping diklik dua kali. Tidak ada informasi pembayaran yang dikirimkan tanpa pengesahan pengguna. Setelah pengguna mengesahkan, Nomor Akun Perangkat dan kode keamanan dinamis khusus transaksi akan digunakan saat memproses pembayaran. Apple atau perangkat pengguna tidak akan mengirim nomor lengkap kartu kredit atau debit ke penjual. Apple dapat menerima informasi transaksi anonim seperti perkiraan waktu dan lokasi transaksi, yang membantu Apple Pay dan produk serta layanan Apple lainnya.

Membayar dengan Apple Pay di dalam app Apple Pay juga dapat digunakan untuk melakukan pembayaran di dalam app iOS. Saat pengguna membayar di app menggunakan Apple Pay, Apple akan menerima informasi transaksi yang dienkripsi dan mengenkripsinya kembali dengan kunci khusus penjual sebelum dikirimkan ke penjual. Apple Pay akan menyimpan informasi transaksi anonim seperti perkiraan jumlah pembelian. Informasi ini tidak dapat dikaitkan kembali ke pengguna dan tidak akan menyertakan apa yang dibeli pengguna. Saat app memulai transaksi pembayaran Apple Pay, Server Apple Pay akan menerima transaksi yang dienkripsi dari perangkat sebelum penjual menerimanya. Server Apple Pay kemudian akan mengenkripsinya kembali dengan kunci khusus penjual sebelum mengirimkan transaksi ke penjual. Setelah app meminta pembayaran, app memanggil API untuk menentukan apakah perangkat mendukung Apple Pay dan apakah pengguna memiliki kartu kredit atau debit yang dapat digunakan untuk membayar di jaringan pembayaran yang diterima oleh penjual. App meminta informasi yang diperlukan untuk memproses dan melengkapi transaksi, seperti alamat penagihan dan pengiriman, dan informasi kontak. App kemudian


37

akan meminta iOS untuk mengeluarkan lembar Apple Pay, yang akan meminta informasi untuk app, serta informasi lainnya yang diperlukan, seperti kartu yang akan digunakan. Pada tahap ini, app akan diberi informasi kota, negara bagian, dan kode pos untuk menghitung total biaya pengiriman. Informasi lengkap tidak akan diberikan kepada app hingga pengguna mengesahkan pembayaran dengan Touch ID atau kode sandi perangkat. Setelah pembayaran disahkan, informasi yang diberikan di lembar Apple Pay akan ditransfer ke penjual. Setelah pengguna mengesahkan pembayaran, panggilan akan dilakukan ke Server Apple Pay untuk mendapatkan nilai sekali pakai kriptografis, yang mirip dengan nilai yang dikembalikan oleh terminal NFC yang digunakan untuk transaksi dalam toko. Nilai sekali pakai, bersama dengan data transaksi, diteruskan ke Elemen Aman untuk membuat info pengesahan pembayaran yang akan dienkripsi dengan kunci Apple. Setelah dibuat oleh Elemen Aman, info pengesahan pembayaran terenkripsi akan diteruskan ke Server Apple Pay, yang mendekripsi info pengesahan, memverifikasi nilai sekali pakai di info pengesahan berdasarkan nilai sekali pakai yang dikirimkan oleh Elemen Aman, dan mengenkripsi ulang info pengesahan pembayaran dengan kunci penjual yang dikaitkan dengan ID Penjual. Lalu, info pengesahan akan dikembalikan ke perangkat, yang akan menyerahkannya kembali ke app melalui API. App kemudian akan meneruskannya ke sistem penjual untuk diproses. Penjual dapat mendekripsi info pengesahan pembayaran dengan kunci pribadinya untuk diproses. Ini, bersama dengan tanda tangan dari server Apple, memungkinkan penjual untuk memverifikasi transaksi yang ditujukan untuk penjual ini. API memerlukan hak yang menetapkan ID penjual yang didukung. App juga dapat menyertakan data tambahan untuk dikirimkan ke Elemen Aman untuk ditandatangani, seperti nomor pesanan atau identitas konsumen, sehingga memastikan bahwa transaksi tidak dapat dialihkan ke konsumen lain. Ini dapat dilakukan oleh pengembang app. Pengembang app dapat menetapkan applicationData di PKPaymentRequest. Hash dari data ini disertakan di data pembayaran yang dienkripsi. Penjual kemudian bertanggung jawab untuk memverifikasi bahwa hash applicationData cocok dengan apa yang disertakan di data pembayaran.

Kartu hadiah Sejak iOS 9, Apple Pay mendukung protokol Layanan Pertambahan Nilai (VAS) untuk mengirimkan kartu hadiah penjual ke terminal NFC yang kompatibel. Protokol VAS dapat diterapkan di terminal penjual dan menggunakan NFC untuk berkomunikasi dengan perangkat Apple yang didukung. Protokol VAS dapat digunakan dalam jarak pendek dan berfungsi untuk menyediakan layanan pelengkap, seperti transmisi informasi kartu hadiah, sebagai bagian dari transaksi Apple Pay. Terminal NFC mulai menerima informasi kartu dengan mengirimkan permintaan kartu. Jika pengguna memiliki kartu dengan pengenal toko, pengguna akan diminta untuk mengesahkan penggunaannya. Jika penjual mendukung enkripsi, informasi kartu, tanda waktu, kunci P-256 ECDH acak sekali pakai akan digunakan dengan kunci publik penjual untuk membuat kunci enkripsi untuk data kartu, yang akan dikirimkan ke terminal. Jika penjual tidak mendukung enkripsi, pengguna akan diminta untuk menyediakan perangkat kembali ke terminal sebelum informasi kartu hadiah dikirim.


38

Menangguhkan, menghapus, dan membersihkan kartu Pengguna dapat menangguhkan Apple Pay di iPhone dan iPad dengan menyalakan Mode Hilang di perangkat menggunakan Cari iPhone Saya. Pengguna juga dapat menghapus dan membersihkan kartu mereka dari Apple Pay menggunakan Cari iPhone Saya, Pengaturan iCloud, atau langsung di perangkat mereka menggunakan Wallet. Di Apple Watch, kartu dapat dihapus menggunakan pengaturan iCloud, app Apple Watch di iPhone, atau langsung di jam. Fitur untuk melakukan pembayaran menggunakan kartu di perangkat akan ditangguhkan atau dihapus dari Apple Pay oleh penerbit kartu atau jaringan pembayaran terkait meskipun perangkat offline dan tidak terhubung ke jaringan seluler atau Wi-Fi. Pengguna juga dapat menghubungi penerbit kartunya untuk menangguhkan atau menghapus kartu dari Apple Pay. Selain itu, saat pengguna menghapus keseluruhan perangkat menggunakan “Hapus Konten & Pengaturan,” dengan Cari iPhone Saya, atau memulihkan perangkatnya menggunakan mode pemulihan, iOS akan memerintahkan Elemen Aman untuk menandai semua kartu sebagai dihapus. Ini dapat langsung berakibat pada menjadi tidak dapat digunakannya kartu hingga Server Apple Pay dapat dihubungi untuk menghapus kartu sepenuhnya dari Elemen Aman. Terlepas dari itu, Enklave Aman menandai AR sebagai tidak sah, sehingga kartu yang didaftarkan sebelumnya tidak mungkin mendapatkan pengesahan pembayaran lebih lanjut. Saat online, perangkat akan mencoba untuk menghubungi Server Apple Pay untuk memastikan bahwa semua kartu di Elemen Aman dihapus.


39

Layanan Internet Membuat kata sandi ID Apple yang kuat ID Apple digunakan untuk terhubung ke sejumlah layanan, termasuk iCloud, FaceTime, dan iMessage Untuk membantu pengguna membuat kata sandi yang kuat, semua akun baru harus berisi atribut kata sandi berikut: • Setidaknya delapan karakter • Setidaknya satu huruf • Setidaknya satu huruf besar • Setidaknya satu angka • Maksimum tiga karakter identik berturut-turut • Tidak sama dengan nama akun

Apple telah membangun beragam layanan yang lengkap untuk membantu pengguna mengoptimalkan utilitas dan produktivitas perangkat mereka, termasuk iMessage, FaceTime, Siri, Saran Spotlight, iCloud, Cadangan iCloud, dan Rantai Kunci iCloud. Layanan Internet ini telah dibuat dengan tujuan keamanan yang sama dengan yang digunakan iOS di seluruh platform. Tujuan ini meliputi penanganan data secara aman, saat tersimpan di perangkat atau saat transit melalui jaringan nirkabel; perlindungan informasi pribadi pengguna; dan perlindungan dari ancaman akses yang tidak berwenang atau berbahaya ke informasi dan layanan. Setiap layanan menggunakan arsitektur keamanannya sendiri yang andal tanpa mengganggu kemudahan penggunaan iOS secara keseluruhan.

ID Apple ID Apple adalah nama pengguna dan kata sandi yang digunakan untuk masuk ke layanan Apple, seperti iCloud, iMessage, FaceTime, iTunes Store, iBooks Store, App Store, dan lainnya. Penting bagi pengguna untuk menjaga agar ID Apple mereka tetap aman untuk mencegah akses yang tidak berwenang ke akun mereka. Untuk membantu perihal masalah ini, Apple mengharuskan kata sandi yang kuat yang setidaknya harus berisi delapan karakter, berisi huruf dan angka, tidak boleh meliputi lebih dari tiga karakter identik berturut-turut, dan tidak boleh berupa kata sandi yang umum digunakan. Pengguna dianjurkan untuk melampaui panduan ini dengan menambahkan karakter dan tanda baca untuk membuat kata sandi mereka lebih kuat lagi. Apple juga mengharuskan pengguna untuk mengatur tiga pertanyaan keamanan yang dapat digunakan untuk membantu verifikasi identitas pemilik saat membuat perubahan pada informasi akun mereka atau mengatur ulang kata sandi yang terlupakan. Apple juga mengirimkan email dan pemberitahuan push ke pengguna jika terdapat perubahan penting yang dilakukan pada akun mereka; misalnya jika kata sandi atau informasi penagihan telah diubah, atau ID Apple telah digunakan untuk masuk ke perangkat baru. Jika terdapat hal yang ganjil, pengguna diinstruksikan untuk segera mengubah kata sandi ID Apple mereka. Selain itu, Apple menerapkan berbagai kebijakan dan prosedur yang dirancang untuk melindungi akun pengguna. Ini meliputi pembatasan jumlah percobaan ulang untuk masuk dan upaya pengaturan ulang kata sandi, pengawasan penipuan aktif untuk membantu mengidentifikasi serangan pada saat kejadian, dan peninjauan kebijakan secara berkala yang memungkinkan kami untuk beradaptasi terhadap informasi baru yang dapat berpengaruh pada keamanan konsumen.

Pengesahan dua faktor

Untuk membantu pengguna mengamankan akun mereka secara lebih lanjut, Apple menawarkan pengesahan dua faktor. Pengesahan dua faktor adalah lapisan keamanan tambahan untuk ID Apple. Fitur ini dirancang untuk memastikan bahwa hanya pemilik akun yang dapat mengakses akun, bahkan jika orang lain mengetahui kata sandinya. Dengan pengesahan dua faktor, akun pengguna hanya dapat diakses di perangkat tepercaya, seperti iPhone, iPad, atau Mac pengguna. Agar dapat masuk untuk pertama kalinya di perangkat baru, dua jenis informasi diperlukan—kata sandi ID Apple dan kode verifikasi enam digit yang secara otomatis ditampilkan di perangkat tepercaya pengguna atau dikirimkan ke nomor telepon tepercaya. Dengan memasukkan kode, pengguna memverifikasi bahwa mereka mempercayai perangkat baru dan aman Keamanan iOS—Buku Putih | Mei 2016

40

untuk masuk. Karena kata sandi tidak lagi cukup untuk mengakses akun pengguna, pengesahan dua faktor meningkatkan keamanan ID Apple pengguna dan semua informasi pribadi yang mereka simpan dengan Apple. Pengesahan dua faktor meningkatkan keamanan ID Apple pengguna dan informasi pribadi yang mereka simpan dengan Apple. Fitur ini terintegrasi secara langsung di iOS, OS X, tvOS, watchOS, dan sistem pengesahan yang digunakan oleh situs web Apple. Untuk informasi lainnya mengenai pengesahan dua faktor, lihat support.apple.com/id-id/HT204915.

Verifikasi dua langkah

Sejak 2013, Apple juga telah menawarkan metode keamanan serupa yang disebut verifikasi dua langkah. Dengan verifikasi dua langkah yang diaktifkan, identitas pengguna harus diverifikasi melalui kode sementara yang dikirimkan ke salah satu perangkat tepercaya milik pengguna sebelum perubahan diizinkan untuk dilakukan pada informasi akun ID Apple-nya; sebelum masuk ke iCloud, iMessage, FaceTime, dan Game Center, dan sebelum melakukan pembelian iTunes Store, iBooks Store, atau App Store dari perangkat baru. Pengguna juga diberi 14 karakter Kunci Pemulihan untuk disimpan di tempat aman untuk berjaga-jaga jika mereka lupa kata sandi atau kehilangan akses ke perangkat tepercaya mereka. Untuk informasi lainnya mengenai verifikasi dua langkah untuk ID Apple, lihat support.apple.com/kb/ht5570?viewlocale=id_ID.

ID Apple yang Dikelola

Dengan iOS 9.3 atau lebih baru, ID Apple yang Dikelola berfungsi serupa dengan ID Apple, tapi dimiliki dan dikelola oleh institusi pendidikan. Institusi dapat mengatur ulang kata sandi, membatasi pembelian dan komunikasi seperti FaceTime dan Pesan, dan mengatur izin berbasis peran untuk anggota staf, instruktur, dan murid. Sebagian layanan Apple dinonaktifkan untuk ID Apple yang Dikelola, seperti Touch ID, Apple Pay, Rantai Kunci iCloud, HomeKit, dan Cari iPhone Saya. Untuk informasi lainnya mengenai ID Apple yang Dikelola, lihat Bantuan Apple School Manager.

Mengaudit ID Apple yang Dikelola

ID Apple yang Dikelola juga mendukung pengauditan, yang memungkinkan institusi untuk mematuhi peraturan hukum dan privasi. Akun administrator, guru, atau pengelola dapat diberi hak audit untuk ID Apple yang Dikelola tertentu. Auditor hanya dapat mengawasi akun yang berada di bawah mereka dalam hierarki sekolah. Dengan kata lain, guru dapat mengawasi murid, pengelola dapat mengaudit guru dan murid, dan administrator dapat mengaudit pengelola, guru, dan murid. Saat mengaudit info pengesahan yang diminta menggunakan Apple School Manager, akan diterbitkan akun khusus yang hanya memiliki akses ke ID Apple yang Dikelola yang akan diaudit. Izin audit kedaluwarsa setelah tujuh hari. Selama periode waktu tersebut, auditor dapat membaca dan memodifikasi konten pengguna yang disimpan di iCloud atau aplikasi yang menggunakan CloudKit. Semua permintaan untuk akses audit dicatat di Apple School Manager. Log menampilkan siapa yang mengaudit, ID Apple yang Dikelola yang akan diaudit, waktu permintaan, dan apakah audit dilakukan atau tidak.


41

ID Apple yang Dikelola dan perangkat pribadi

ID Apple yang Dikelola juga dapat digunakan dengan perangkat iOS milik pribadi. Murid masuk ke iCloud menggunakan ID Apple yang Dikelola yang diterbitkan oleh institusi dan kata sandi tambahan untuk penggunaan di rumah yang berfungsi sebagai faktor kedua pada proses pengesahan dua faktor ID Apple. Saat menggunakan ID Apple yang Dikelola di perangkat pribadi, Rantai Kunci iCloud tidak tersedia, dan institusi dapat membatasi fitur lain seperti FaceTime atau Pesan. Semua dokumen iCloud yang dibuat oleh murid saat mereka masuk dapat diaudit sebagaimana yang dijelaskan sebelumnya.

iMessage iMessage Apple adalah layanan pengolahan pesan untuk perangkat iOS dan komputer Mac. iMessage mendukung teks dan lampiran, seperti foto, kontak, dan lokasi. Pesan muncul di semua perangkat pengguna yang didaftarkan sehingga percakapan dapat dilanjutkan dari perangkat mana pun milik pengguna. iMessage memanfaatkan layanan Pemberitahuan Push Apple (APN) secara ekstensif. Apple tidak mencatat pesan atau lampiran, dan kontennya dilindungi oleh enkripsi ujung-ke-ujung sehingga tidak ada orang yang dapat mengaksesnya, kecuali pengirim dan penerima. Apple tidak dapat mendekripsi datanya. Saat pengguna menyalakan iMessage di perangkat, perangkat akan membuat dua pasang kunci untuk digunakan dengan layanan: kunci RSA 1280 bit untuk enkripsi dan kunci ECDSA 256 bit pada kurva P-256 NIST untuk penandatanganan. Kunci pribadi untuk kedua pasang kunci disimpan di rantai kunci perangkat dan kunci publik dikirimkan ke layanan direktori Apple (IDS), tempat kunci akan dikaitkan dengan nomor telepon atau alamat email pengguna, bersama dengan alamat APN perangkat. Saat pengguna mengaktifkan perangkat tambahan untuk digunakan dengan iMessage, enkripsi dan kunci publik penandatangan, alamat APN, dan nomor telepon terkaitnya akan ditambahkan ke layanan direktori. Pengguna juga dapat menambahkan alamat email lain, yang akan diverifikasi dengan mengirimkan tautan konfirmasi. Nomor telepon diverifikasi oleh jaringan operator dan SIM. Selain itu, semua perangkat pengguna yang terdaftar akan menampilkan pesan peringatan saat perangkat baru, nomor telepon, atau alamat email ditambahkan.

Bagaimana iMessage mengirimkan dan menerima pesan

Pengguna memulai percakapan iMessage baru dengan memasukkan alamat atau nama. Jika mereka memasukkan nomor telepon atau alamat email, perangkat akan menghubungi IDS untuk mengambil kunci publik dan alamat APN untuk semua perangkat yang dikaitkan dengan alamat tersebut. Jika pengguna memasukkan nama, perangkat pertama-tama akan menggunakan app Kontak milik pengguna untuk mengumpulkan nomor telepon dan alamat email yang terkait dengan nama tersebut, lalu mendapatkan kunci publik dan alamat APN dari IDS. Pesan keluar pengguna dienkripsi secara terpisah untuk setiap perangkat penerima. Kunci enkripsi RSA publik dari perangkat penerima diambil dari IDS. Untuk setiap perangkat penerima, perangkat pengirim akan membuat kunci 128 bit acak dan mengenkripsi pesan dengannya menggunakan AES dalam mode CTR. Kunci AES per pesan ini dienkripsi menggunakan RSA-OAEP ke kunci publik dari perangkat penerima. Kombinasi pesan teks terenkripsi dan kunci pesan terenkripsi kemudian di-hash dengan SHA-1, dan hash ditandatangani dengan ECDSA menggunakan kunci penandatangan pribadi milik perangkat pengirim. Pesan yang dihasilkan, satu untuk setiap perangkat penerima, berisi teks pesan terenkripsi, kunci pesan terenkripsi, dan tanda tangan digital pengirim. Pesan kemudian diteruskan ke APN untuk dikirim. Metadata, seperti tanda waktu dan informasi rute APN, tidak dienkripsi. Komunikasi dengan APN dienkripsi menggunakan saluran TLS dengan kerahasiaan berkelanjutan. Keamanan iOS—Buku Putih | Mei 2016

42

APN hanya dapat mengirimkan pesan berukuran hingga 4 KB atau 16 KB, tergantung versi iOS. Jika teks pesan terlalu panjang, atau jika lampiran seperti foto disertakan, lampiran dienkripsi menggunakan AES dalam mode CTR dengan kunci 256 bit yang dibuat secara acak dan diunggah ke iCloud. Kunci AES untuk lampiran, URI-nya (Pengenal Sumber Seragam), dan hash SHA-1 dari format terenkripsinya kemudian dikirimkan ke penerima sebagai konten iMessage, dengan kerahasiaan dan integritasnya yang terlindungi melalui enkripsi iMessage normal, sebagaimana yang ditampilkan di bawah. Lampiran dienkripsi dengan kunci acak

iCloud

APN Pesan ditandatangani dan dienkripsi untuk pengguna 2 dengan URI dan kunci untuk lampiran

Pengguna 1

Pengguna 2 Kunci publik dan token APN untuk pengguna 2

Kunci publik dan token APN untuk pengguna 1 IDS

Untuk percakapan grup, proses ini diulangi untuk setiap penerima dan perangkatnya.

Perangkat penerima menerima salinan pesannya dari APN, dan, jika perlu, mengambil lampiran dari iCloud. Nomor telepon atau alamat email masuk milik pengirim dicocokkan dengan kontak penerima sehingga nama dapat ditampilkan, jika memungkinkan. Sebagaimana halnya dengan semua pemberitahuan push, pesan dihapus dari APN saat dikirimkan. Berbeda dengan pemberitahuan APN lainnya, pesan iMessage diantrekan untuk dikirim ke perangkat offline. Pesan disimpan hingga selama 30 hari pada tahap ini.

FaceTime FaceTime adalah layanan panggilan audio dan video Apple. Mirip dengan iMessage, panggilan FaceTime juga menggunakan layanan Pemberitahuan Push Apple untuk membuat koneksi awal ke perangkat terdaftar milik pengguna. Konten audio/video dari panggilan FaceTime dilindungi oleh enkripsi ujung-ke-ujung, sehingga tidak ada orang yang dapat mengaksesnya kecuali pengirim dan penerima. Apple tidak dapat mendekripsi datanya. FaceTime menggunakan Pembuatan Konektivitas Internet (ICE) untuk membuat koneksi rekan-ke-rekan antara perangkat. Dengan menggunakan pesan Protokol Inisiasi Sesi (SIP), perangkat memverifikasi sertifikat identitasnya dan membuat rahasia bersama untuk setiap sesi. Nilai sekali pakai kriptografis yang disediakan oleh tiap perangkat dikombinasikan untuk memberi salt pada kunci tiap saluran media, yang di-stream melalui Protokol Real Time Aman (SRTP) menggunakan enkripsi AES-256.


43

iCloud iCloud menyimpan kontak, kalender, foto, dokumen, dan data pengguna lainnya serta menjaganya agar tetap terbaru di semua perangkat pengguna secara otomatis. iCloud juga dapat digunakan oleh app pihak ketiga untuk menyimpan dan menyelaraskan dokumen serta nilai kunci untuk data app sebagaimana yang didefinisikan oleh pengembang. Pengguna mengatur iCloud dengan masuk menggunakan ID Apple dan memilih layanan mana yang ingin digunakan. Fitur iCloud, termasuk Stream Foto Saya, iCloud Drive, dan Cadangan, dapat dinonaktifkan oleh administrator TI melalui profil konfigurasi. Layanan kompatibel dengan semua yang disimpan dan menangani semua konten file dengan cara yang sama, sebagai kumpulan bita. Setiap file dipecah menjadi beberapa potongan dan dienkripsi oleh iCloud menggunakan AES-128 dan kunci turunan dari setiap konten potongan yang menggunakan SHA-256. Kunci, dan metadata file, disimpan oleh Apple di akun iCloud pengguna. Potongan file yang dienkripsi disimpan, tanpa informasi yang mengidentifikasi pengguna, menggunakan layanan penyimpanan pihak ketiga, seperti Amazon S3 dan Windows Azure.

iCloud Drive

iCloud Drive menambahkan kunci berbasis akun untuk melindungi dokumen yang disimpan di iCloud. Sama dengan layanan iCloud yang ada, iCloud Drive memecah dan mengenkripsi konten file dan menyimpan potongan yang dienkripsi menggunakan layanan pihak ketiga. Namun, kunci konten file dibungkus oleh kunci rekaman yang disimpan dengan metadata iCloud Drive. Kunci rekaman ini pada gilirannya dilindungi oleh kunci layanan iCloud Drive milik pengguna, yang kemudian disimpan dengan akun iCloud pengguna. Pengguna mendapatkan akses ke metadata dokumen iCloud mereka melalui pengesahan dengan iCloud, tapi juga harus memiliki kunci layanan iCloud Drive untuk memaparkan bagian penyimpanan iCloud Drive yang dilindungi.

CloudKit

CloudKit memungkinkan pengembang app untuk menyimpan data nilai kunci, data terstruktur, dan aset di iCloud. Akses ke CloudKit dikontrol menggunakan hak app. CloudKit mendukung basis data pribadi dan publik. Basis data publik digunakan oleh semua salinan app, biasanya untuk aset umum, dan tidak dienkripsi. Basis data pribadi menyimpan data pengguna. Sama halnya dengan iCloud Drive, CloudKit menggunakan kunci berbasis akun untuk melindungi informasi yang disimpan di basis data pribadi pengguna dan, mirip dengan layanan iCloud lainnya, file dipecah, dienkripsi, dan disimpan menggunakan layanan pihak ketiga. CloudKit menggunakan hierarki kunci, mirip dengan Perlindungan Data. Kunci per file dibungkus dengan kunci Rekaman CloudKit. Kunci Rekaman, pada gilirannya, dilindungi oleh kunci zona, yang dilindungi oleh kunci Layanan CloudKit pengguna. Kunci Layanan CloudKit disimpan di akun iCloud pengguna dan hanya tersedia setelah pengguna mengesahkan dengan iCloud. Kunci Layanan CloudKit

Kunci Zona CloudKit

Kunci Rekaman CloudKit

Metadata File

Daftar Potongan File

Potongan File Enkripsi Konvergen


44

Cadangan iCloud

iCloud juga mencadangkan informasi—termasuk pengaturan perangkat, data app, foto, dan video di Rol Kamera, dan percakapan di app Pesan—setiap hari melalui Wi-Fi. iCloud mengamankan konten dengan mengenkripsinya saat dikirim melalui Internet, menyimpannya dalam format terenkripsi, dan menggunakan token aman untuk pengesahan. Cadangan iCloud hanya berlangsung saat perangkat dikunci, tersambung ke sumber daya, dan memiliki akses Wi-Fi ke Internet. Karena enkripsi yang digunakan di iOS, sistem dirancang untuk menjaga agar data tetap aman sambil tetap memungkinkan dilakukannya pencadangan dan pemulihan dengan penambahan konten serta tanpa pengawasan. Berikut adalah apa yang dicadangkan iCloud: • Informasi mengenai musik, film, acara TV, app, dan buku yang dibeli, tapi bukan konten yang dibeli itu sendiri • Foto dan video di Rol Kamera • Kontak, acara kalender, pengingat, dan catatan • Pengaturan perangkat • Data app • PDF dan buku yang ditambahkan ke iBook tapi tidak dibeli • Riwayat panggilan • Layar utama dan pengelolaan app • Pesan iMessage, teks (SMS), dan MMS • Nada dering • Data HomeKit • Data HealthKit • Pesan Suara Visual Saat file dibuat di kelas Perlindungan Data yang tidak dapat diakses ketika perangkat terkunci, kunci per filenya akan dienkripsi menggunakan kunci kelas dari kantong kunci Cadangan iCloud. File dicadangkan ke iCloud dalam kondisi aslinya yang dienkripsi. File di kelas Perlindungan Data Tidak Ada Perlindungan dienkripsi saat dikirimkan. Kantong kunci Cadangan iCloud berisi kunci asimetris (Curve25519) untuk setiap kelas Perlindungan Data, yang digunakan untuk mengenkripsi kunci per file. Untuk informasi lainnya mengenai konten kantong kunci cadangan dan kantong kunci Cadangan iCloud, lihat “Perlindungan Data Rantai Kunci” di bagian Enkripsi dan Perlindungan Data. Kumpulan cadangan disimpan di akun iCloud pengguna dan berisi salinan file pengguna, dan kantong kunci Cadangan iCloud. Kantong kunci Cadangan iCloud dilindungi oleh kunci acak, yang juga disimpan dengan kumpulan cadangan. (Kata sandi iCloud pengguna tidak digunakan untuk enkripsi sehingga perubahan kata sandi iCloud tidak akan membuat cadangan yang ada menjadi tidak sah.) Saat basis data rantai kunci pengguna dicadangkan ke iCloud, basis data rantai kunci tetap dilindungi oleh kunci yang dikaitkan dengan UID. Ini memungkinkan rantai kunci untuk hanya dipulihkan ke perangkat yang dengan perangkat asal kunci, sehingga orang lain, termasuk Apple, tidak akan dapat membaca item rantai kunci pengguna. Saat dipulihkan, file yang dicadangkan, kantong kunci Cadangan iCloud, dan kunci untuk kantong kunci diambil dari akun iCloud pengguna. Kantong kunci Cadangan iCloud didekripsi menggunakan kuncinya, lalu kunci per file di kantong kunci akan digunakan untuk mendekripsi file di kumpulan cadangan, yang dituliskan sebagai file baru di sistem file, sehingga akan membuatnya dienkripsi ulang menurut kelas Perlindungan Datanya. Keamanan iOS—Buku Putih | Mei 2016

45

Integrasi Safari dengan Rantai Kunci iCloud Safari dapat membuat string acak yang kuat secara kriptografis untuk kata sandi situs web, yang disimpan di Rantai Kunci dan diselaraskan dengan perangkat Anda yang lainnya. Item Rantai Kunci ditransfer dari perangkat ke perangkat, dikirim melalui server Apple, tapi dienkripsi sedemikian rupa sehingga Apple dan perangkat lainnya tidak dapat membaca kontennya.

Rantai Kunci iCloud Rantai Kunci iCloud memungkinkan pengguna untuk menyelaraskan kata sandinya dengan aman antarperangkat iOS dan komputer Mac tanpa memaparkan informasi ke Apple. Selain privasi dan keamanan yang kuat, tujuan lain yang sangat berpengaruh pada rancangan dan arsitektur Rantai Kunci iCloud adalah kemudahan penggunaan dan fitur untuk memulihkan rantai kunci. Rantai Kunci iCloud terdiri dari dua layanan: penyelarasan dan pemulihan rantai kunci. Apple merancang Rantai Kunci iCloud dan pemulihan rantai kunci sehingga kata sandi pengguna masih terlindungi dalam kondisi berikut: • Akun iCloud pengguna terganggu. • iCloud terganggu oleh penyerang dari luar atau karyawan. • Akses pihak ketiga ke akun pengguna.

Penyelarasan rantai kunci

Saat pengguna mengaktifkan Rantai Kunci iCloud untuk pertama kalinya, perangkat membangun lingkaran kepercayaan dan membuat identitas penyelarasan untuk dirinya sendiri. Identitas penyelarasan berisi kunci pribadi dan kunci publik. Kunci publik identitas penyelarasan disimpan di lingkaran, dan lingkaran ditandatangani dua kali: pertama oleh kunci pribadi identitas penyelarasan, lalu oleh kunci elips asimetris (menggunakan P256) turunan kata sandi akun iCloud pengguna. Juga yang disimpan bersama dengan lingkaran adalah parameter (salt dan iterasi acak) yang digunakan untuk membuat kunci berdasarkan kata sandi iCloud pengguna. Lingkaran penyelarasan yang ditandatangani ditempatkan di area penyimpanan nilai kunci iCloud pengguna. Lingkaran tidak dapat dibaca tanpa mengetahui kata sandi iCloud pengguna, dan tidak dapat dimodifikasi dengan sah tanpa memiliki kunci pribadi identitas penyelarasan dari anggotanya. Saat pengguna menyalakan Rantai Kunci iCloud di perangkat lain, perangkat baru akan mengetahui apabila pengguna telah membangun lingkaran penyelarasan di iCloud yang bukan merupakan bagian darinya. Perangkat akan membuat pasangan kunci identitas penyelarasannya, lalu membuat tiket aplikasi untuk mengajukan keanggotaan di lingkaran. Tiket terdiri dari kunci publik perangkat identitas penyelarasannya, dan pengguna akan diminta untuk mengesahkan dengan kata sandi iCloud-nya. Parameter pembuatan kunci elips diambil dari iCloud dan membuat kunci yang digunakan untuk menandatangani tiket aplikasi. Akhirnya, tiket aplikasi ditempatkan di iCloud. Saat melihat bahwa tiket aplikasi telah tiba, perangkat pertama akan menampilkan pemberitahuan untuk pengguna sebagai konfirmasi bahwa perangkat baru sedang meminta untuk bergabung dengan lingkaran penyelarasan. Pengguna memasukkan kata sandi iCloud-nya, dan tiket aplikasi diverifikasi sebagai ditandatangani oleh kunci pribadi yang cocok. Ini memastikan bahwa orang yang membuat permintaan untuk bergabung dengan lingkaran telah memasukkan kata sandi iCloud pengguna saat permintaan dibuat. Setelah pengguna setuju untuk menambahkan perangkat baru ke lingkaran, perangkat pertama akan menambahkan kunci publik anggota baru ke lingkaran penyelarasan, menandatanganinya kembali dengan identitas penyelarasan dan kunci turunan dari kata sandi iCloud pengguna. Lingkaran penyelarasan yang baru ditempatkan di iCloud, lalu ditandatangani secara serupa oleh anggota baru dari lingkaran. Ada dua anggota lingkaran penanda tangan pada tahap ini, dan setiap anggota memiliki kunci publik rekannya. Kedua anggota akan mulai bertukar item rantai kunci secara terpisah melalui penyimpanan nilai kunci iCloud. Jika kedua anggota lingkaran memiliki item yang sama, item dengan tanggal modifikasi terbaru akan diselaraskan. Item akan dilewati jika anggota lainnya memiliki item dan tanggal modifikasi yang sama. Setiap item yang diselaraskan akan dienkripsi, khususnya untuk perangkat Keamanan iOS—Buku Putih | Mei 2016

46

tujuan pengiriman. Item tidak dapat didekripsi oleh perangkat lain atau Apple. Selain itu, item yang dienkripsi bersifat sementara di iCloud; item akan ditimpa dengan tiap item baru yang diselaraskan. Proses ini diulangi setiap kali perangkat baru bergabung dengan lingkaran penyelarasan. Misalnya, saat perangkat ketiga bergabung, konfirmasi akan muncul di kedua perangkat pengguna lainnya. Pengguna dapat menyetujui anggota baru dari salah satu perangkat. Saat rekan baru ditambahkan, tiap rekan akan diselaraskan dengan rekan baru untuk memastikan bahwa semua anggota memiliki item rantai kunci yang sama. Namun, keseluruhan rantai kunci tidak diselaraskan. Beberapa item dikhususkan untuk perangkat tertentu, seperti identitas VPN, dan tidak boleh meninggalkan perangkat. Hanya item dengan atribut kSecAttrSynchronizable yang diselaraskan. Apple telah mengatur atribut ini untuk data pengguna Safari (termasuk nama pengguna, kata sandi, dan nomor kartu kredit), serta kata sandi Wi-Fi dan kunci enkripsi HomeKit. Selain itu, secara default, item rantai kunci yang ditambahkan oleh app pihak ketiga tidak diselaraskan. Pengembang harus mengatur kSecAttrSynchronizable saat menambahkan item ke rantai kunci.

Pemulihan rantai kunci

Pemulihan rantai kunci menyediakan cara bagi pengguna agar dapat mengeskrow secara opsional rantai kunci mereka kepada Apple, tanpa mengizinkan Apple untuk membaca kata sandi dan data lainnya yang tersimpan. Meskipun pengguna hanya memiliki satu perangkat, pemulihan rantai kunci menyediakan jaring pengaman atas hilangnya data. Ini penting khususnya jika Safari digunakan untuk membuat kata sandi yang kuat dan acak untuk akun web, karena satu-satunya rekaman yang ada mengenai kata sandi tersebut berada di rantai kunci. Landasan pemulihan rantai kunci adalah pengesahan kedua dan layanan eskrow yang aman, yang dibuat oleh Apple khusus untuk mendukung fitur ini. Rantai kunci pengguna dienkripsi menggunakan kode sandi yang kuat, dan layanan eskrow akan menyediakan salinan rantai kunci hanya jika persyaratan yang ketat terpenuhi. Jika Rantai Kunci iCloud dinyalakan, pengguna akan diminta untuk membuat Kode Keamanan iCloud. Kode ini diperlukan untuk memulihkan rantai kunci yang dipercayakan. Secara default, pengguna diminta untuk menyediakan nilai empat digit sederhana untuk kode keamanan. Namun, pengguna juga dapat menetapkan kode mereka sendiri yang lebih panjang, atau mengizinkan perangkat untuk membuat kode yang acak secara kriptografis yang dapat mereka rekam dan simpan sendiri. Berikutnya, perangkat iOS mengekspor salinan rantai kunci pengguna, mengenkripsinya melalui pembungkusan kunci di kantong kunci asimetris, dan menempatkannya di area penyimpanan nilai kunci iCloud milik pengguna. Kantong kunci dibungkus dengan Kode Keamanan iCloud milik pengguna dan kunci publik gugus HSM (modul keamanan perangkat keras) yang akan menyimpan rekaman eskrow. Ini menjadi Rekaman Eskrow iCloud pengguna. Jika pengguna memutuskan untuk menerima kode keamanan yang acak secara kriptografis, alih-alih menetapkan kodenya sendiri atau menggunakan nilai empat digit, rekaman eskrow tidak akan diperlukan. Sebagai gantinya, Kode Keamanan iCloud akan digunakan untuk membungkus kunci acak secara langsung. Selain membuat kode keamanan, pengguna harus mendaftarkan nomor telepon. Ini digunakan untuk menyediakan pengesahan level kedua pada saat pemulihan rantai kunci. Pengguna akan menerima SMS yang harus dibalas agar pemulihan dapat dilanjutkan.


47

Keamanan eskrow

iCloud menyediakan infrastruktur aman untuk eskrow rantai kunci yang memastikan bahwa hanya pengguna dan perangkat yang disahkan yang dapat melakukan pemulihan. Gugus modul keamanan perangkat keras (HSM) secara topografis diposisikan di belakang iCloud. Gugus ini menjaga rekaman eskrow. Setiap gugus memiliki kunci yang digunakan untuk mengenkripsi rekaman eskrow dengan pengawasan, sebagaimana yang dijelaskan sebelumnya. Untuk memulihkan rantai kunci, pengguna harus mengesahkan dengan kata sandi dan akun iCloud mereka dan merespons SMS yang dikirimkan ke nomor telepon mereka yang terdaftar. Setelah selesai, pengguna harus memasukkan Kode Keamanan iCloud mereka. Gugus HSM memverifikasi bahwa pengguna mengetahui Kode Keamanan iCloud-nya menggunakan protokol Kata Sandi Jarak jauh Aman (SRP); kodenya sendiri tidak dikirimkan ke Apple. Setiap anggota gugus menverifikasi secara terpisah bahwa pengguna belum melampaui jumlah upaya maksimum yang diizinkan untuk mengambil rekamannya, sebagaimana yang dijelaskan di bawah. Jika sebagian besar setuju, gugus akan membuka bungkus rekaman eskrow dan mengirimkannya ke perangkat pengguna. Berikutnya, perangkat menggunakan Kode Keamanan iCloud untuk membuka bungkus kunci acak yang digunakan untuk mengenkripsi rantai kunci pengguna. Dengan kunci tersebut, rantai kunci—yang diambil dari penyimpanan nilai kunci iCloud—didekripsi dan dipulihkan ke perangkat. Hanya ada 10 upaya pengesahan dan pengambilan rekaman eskrow yang diizinkan. Setelah beberapa upaya gagal, rekaman akan dikunci dan pengguna harus menghubungi Dukungan Apple untuk dapat mencoba kembali. Setelah 10 upaya gagal, gugus HSM akan menghancurkan rekaman eskrow dan rantai kunci akan hilang selamanya. Ini memberikan perlindungan dari upaya paksa untuk mengambil rekaman, dengan mengorbankan data rantai kunci sebagai bentuk penanggulangan. Kebijakan ini dikodekan di firmware HSM. Kartu akses administratif yang mengizinkan firmware untuk diubah telah dihancurkan. Setiap upaya untuk mengubah firmware atau mengakses kunci pribadi akan menyebabkan gugus HSM menghapus kunci pribadi. Jika ini terjadi, pemilik semua rantai kunci yang dilindungi oleh gugus akan menerima pesan yang memberi tahu bahwa rekaman eskrow mereka telah hilang. Mereka kemudian dapat memilih untuk mendaftar ulang.

Siri Cukup dengan berbicara seperti biasa, pengguna dapat meminta Siri untuk mengirim pesan, menjadwalkan pertemuan, melakukan panggilan telepon, dan lainnya. Siri menggunakan pengenalan suara, teks-ke-suara, dan model klien-server untuk merespons berbagai permintaan. Tugas yang didukung Siri telah dirancang untuk memastikan bahwa terdapat sesedikit mungkin informasi pribadi yang digunakan dan bahwa informasi tersebut terlindungi sepenuhnya. Saat Siri dinyalakan, perangkat membuat pengenal acak yang digunakan dengan pengenalan suara dan server Siri. Pengenal ini hanya digunakan di dalam Siri dan digunakan untuk meningkatkan layanan. Jika Siri kemudian dimatikan, perangkat akan membuat pengenal acak baru untuk digunakan jika Siri dinyalakan kembali. Agar dapat memfasilitasi fitur Siri, sebagian informasi pengguna dari perangkat akan dikirimkan ke server. Ini meliputi informasi mengenai perpustakaan musik (judul lagu, artis, dan daftar putar), nama daftar Pengingat, serta nama dan hubungan yang ditetapkan di Kontak. Semua komunikasi dengan server dilakukan melalui HTTPS.


48

Setelah sesi Siri dimulai, nama depan dan nama belakang pengguna (dari Kontak), bersama dengan perkiraan lokasi geografis, dikirimkan ke server. Dengan demikian, Siri dapat merespons dengan nama atau menjawab pertanyaan yang hanya memerlukan perkiraan lokasi, seperti pertanyaan tentang cuaca. Jika lokasi yang lebih tepat diperlukan, misalnya, untuk menentukan lokasi bioskop di sekitar, server akan meminta perangkat untuk menyediakan lokasi yang lebih tepat. Ini adalah contoh, secara default, bagaimana informasi hanya dikirimkan ke server jika memang benar-benar diperlukan untuk memproses permintaan pengguna. Di setiap kejadian, informasi sesi dihapus setelah 10 menit tidak aktif. Saat Siri digunakan dari Apple Watch, jam akan membuat pengenal unik acaknya sendiri, sebagaimana yang dijelaskan di atas. Namun, alih-alih mengirim kembali informasi pengguna, permintaannya juga mengirimkan pengenal Siri dari iPhone yang dipasangkan untuk menyediakan referensi ke informasi tersebut. Rekaman kata-kata lisan pengguna juga dikirimkan ke server pengenalan suara Apple. Jika tugas hanya melibatkan dikte, teks yang dikenali dikirimkan kembali ke perangkat. Jika tidak, Siri menganalisis teks dan, jika perlu, menggabungkannya dengan informasi dari profil yang terkait dengan perangkat. Misalnya, jika permintaan adalah “send a message to my mom,” hubungan dan nama yang diunggah dari Kontak akan digunakan. Perintah untuk tindakan yang dikenali kemudian dikirimkan kembali ke perangkat untuk dilaksanakan. Banyak fungsi Siri yang diselesaikan oleh perangkat atas perintah server. Misalnya, jika pengguna meminta Siri untuk membaca pesan masuk, server hanya memberi tahu perangkat untuk mengucapkan konten pesan yang belum dibaca. Konten dan pengirim pesan tidak dikirimkan ke server. Rekaman suara pengguna disimpan selama enam bulan sehingga sistem pengenalan dapat menggunakannya untuk memahami suara pengguna dengan lebih baik. Setelah enam bulan, salinan lain akan disimpan, tanpa pengenalnya, untuk digunakan oleh Apple dalam peningkatan dan pengembangan Siri hingga selama dua tahun. Selain itu, sebagian rekaman yang merujuk ke musik, tim dan pemain olahraga, serta bisnis atau tempat menarik disimpan dengan serupa untuk tujuan peningkatan Siri. Siri juga dapat diaktifkan tanpa tangan melalui aktivasi suara. Deteksi pemicu suara dilakukan secara lokal di perangkat. Dalam mode ini, Siri hanya diaktifkan saat pola audio yang masuk memiliki cukup kecocokan dengan akustik frasa pemicu yang ditetapkan. Saat pemicu terdeteksi, audio yang sesuai termasuk perintah Siri berikutnya dikirimkan ke server pengenalan suara Apple untuk pemrosesan lebih lanjut, yang mengikuti aturan yang sama dengan rekaman suara pengguna lainnya yang dibuat dengan Siri.

Berkelanjutan Berkelanjutan memanfaatkan teknologi seperti iCloud, Bluetooth, dan Wi-Fi untuk memungkinkan pengguna melanjutkan aktivitas dari satu perangkat ke perangkat lain, melakukan dan menerima panggilan telepon, mengirim dan menerima pesan teks, dan berbagi koneksi Internet seluler.

Handoff

Dengan Handoff, saat Mac dan perangkat iOS pengguna berada di dekat satu sama lain, pengguna dapat meneruskan apa yang mereka kerjakan dari satu perangkat ke perangkat lain secara otomatis. Handoff memungkinkan pengguna untuk beralih perangkat dan langsung melanjutkan pekerjaan.


49

Saat pengguna masuk ke iCloud di perangkat kedua dengan fitur Handoff, kedua perangkat tersebut akan membuat pemasangan luar jalur Bluetooth Rendah Energi 4.0 menggunakan layanan Pemberitahuan Push Apple (APN). Pesan dienkripsi secara terpisah dengan cara yang serupa dengan iMessage. Setelah dipasangkan, setiap perangkat akan membuat kunci AES 256 bit simetris yang disimpan di rantai kunci perangkat. Kunci ini digunakan untuk mengenkripsi dan mengesahkan iklan Bluetooth Rendah Energi yang mengomunikasikan aktivitas perangkat saat ini dengan perangkat iCloud lain yang dipasangkan menggunakan AES 256 dalam mode GCM, dengan tindakan perlindungan pemutaran ulang. Saat perangkat menerima iklan dari kunci baru untuk pertama kalinya, perangkat akan membuat koneksi Bluetooth Rendah Energi ke perangkat asal dan melakukan pertukaran kunci enkripsi iklan. Koneksi ini diamankan menggunakan enkripsi Bluetooth Rendah Energi 4.0 standar serta enkripsi pesan terpisah, yang serupa dengan bagaimana iMessage dienkripsi. Dalam situasi tertentu, pesan ini akan dikirim melalui layanan Pemberitahuan Push Apple, bukan melalui Bluetooth Rendah Energi. Muatan aktivitas dilindungi dan ditransfer dengan cara yang sama dengan iMessage. Handoff antara app asli dan situs web Handoff memungkinkan app asli iOS untuk melanjutkan halaman web di domain yang dikontrol secara sah oleh pengembang app. Handoff juga memungkinkan aktivitas pengguna app asli untuk dilanjutkan di browser web. Untuk mencegah app asli melanjutkan situs web yang tidak dikontrol oleh pengembang, app harus menunjukkan kontrol sah terhadap domain web yang ingin dilanjutkan app. Kontrol terhadap domain situs web dibangun melalui mekanisme yang digunakan untuk info pengesahan web bersama. Untuk detail, rujuk ke “Akses ke kata sandi yang disimpan Safari” di bagian Enkripsi dan Perlindungan Data. Sistem harus memvalidasi kontrol nama domain app sebelum app diizinkan untuk menerima Handoff aktivitas pengguna. Sumber Handoff halaman web dapat berupa browser apa pun yang mengadopsi API Handoff. Saat pengguna melihat halaman web, sistem mengiklankan nama domain halaman web dalam bita iklan Handoff yang dienkripsi. Hanya perangkat lain milik pengguna yang dapat mendekripsi bita iklan (sebagaimana yang dijelaskan sebelumnya di bagian di atas). Di perangkat penerima, sistem mendeteksi bahwa app asli yang diinstal menerima Handoff dari nama domain yang diiklankan dan menampilkan ikon app asli sebagai pilihan Handoff. Saat diluncurkan, app asli menerima URL lengkap dan judul halaman web. Tidak ada informasi lain yang diteruskan dari browser ke app asli. Di sisi lain, app asli dapat menetapkan URL balik jika app asli yang sama tidak terinstal di perangkat penerima Handoff. Pada kasus ini, sistem akan menampilkan browser default pengguna sebagai pilihan app Handoff (jika browser tersebut telah mengadopsi API Handoff). Saat Handoff diminta, browser akan diluncurkan dan diberi URL balik oleh app sumber. Tidak ada keharusan bagi URL balik untuk dibatasi menjadi nama domain yang dikontrol oleh pengembang app asli. Handoff data yang lebih besar Selain fitur dasar Handoff, beberapa app dapat memilih untuk menggunakan API yang mendukung pengiriman data dalam jumlah lebih besar melalui teknologi Wi-Fi rekan-ke-rekan (dengan cara yang serupa dengan AirDrop). Misalnya, app Mail menggunakan API ini untuk mendukung Handoff draf mail, yang dapat berisi lampiran besar. Saat app menggunakan fasilitas ini, pertukaran antara dua perangkat dimulai seperti di Handoff (lihat bagian sebelumnya). Namun, setelah menerima muatan awal menggunakan Bluetooth Rendah Energi, perangkat penerima memulai koneksi baru


50

melalui Wi-Fi. Koneksi ini dienkripsi (TLS), yang akan menukar sertifikat iCloud mereka. Identitas di sertifikat diverifikasi terhadap identitas pengguna. Data muatan lebih lanjut dikirimkan melalui koneksi terenkripsi ini higga transfer selesai. Penyampaian Panggilan Seluler iPhone Saat Mac, iPad, atau iPod Anda berada di jaringan Wi-Fi yang sama dengan iPhone Anda, perangkat dapat melakukan dan menerima panggilan telepon menggunakan koneksi seluler iPhone Anda. Konfigurasi mengharuskan perangkat Anda untuk masuk ke iCloud dan FaceTime menggunakan akun ID Apple yang sama. Saat panggilan masuk tiba, semua perangkat yang dikonfigurasi akan diberi tahu melalui layanan Pemberitahuan Push Apple (APN), dengan tiap pemberitahuan menggunakan enkripsi ujung-ke-ujung yang sama dengan yang digunakan iMessage. Perangkat yang berada di jaringan yang sama akan menampilkan UI pemberitahuan panggilan masuk. Saat menjawab panggilan, audio akan ditransmisikan tanpa sela dari iPhone Anda menggunakan koneksi rekan-ke-rekan yang aman antara kedua perangkat. Saat panggilan dijawab di satu perangkat, nada dering di perangkat di sekitar yang dipasangkan iCloud dihentikan oleh pengiklanan singkat melalui Bluetooth Rendah Energi 4.0. Bita pengiklanan dienkripsi menggunakan metode yang sama dengan pengiklanan Handoff. Panggilan keluar juga akan disampaikan ke iPhone melalui layanan Pemberitahuan Push Apple, dan audio akan ditransmisikan dengan cara yang serupa melalui tautan rekan-ke-rekan yang aman antarperangkat. Pengguna dapat menonaktifkan penyampaian panggilan telepon di perangkat dengan mematikan Panggilan Seluler iPhone di pengaturan FaceTime.

Penerusan Pesan Teks iPhone

Penerusan Pesan Teks mengirimkan pesan teks SMS yang diterima di iPhone secara otomatis ke iPad, iPod touch, atau Mac yang didaftarkan milik pengguna. Setiap perangkat harus masuk ke layanan iMessage menggunakan akun ID Apple yang sama. Saat Penerusan Pesan SMS dinyalakan, pendaftaran diverifikasi di setiap perangkat dengan memasukkan kode numerik enam digit acak yang dibuat oleh iPhone. Setelah perangkat tertaut, iPhone mengenkripsi dan meneruskan pesan teks SMS masuk ke setiap perangkat, menggunakan metode yang dijelaskan di bagian iMessage dalam dokumen ini. Balasan dikirim kembali ke iPhone menggunakan metode yang sama, lalu iPhone mengirimkan balasan sebagai pesan teks menggunakan mekanisme transmisi SMS operator. Penerusan Pesan Teks dapat dinyalakan atau dimatikan di pengaturan Pesan.

Instant Hotspot

Perangkat iOS yang mendukung Instant Hotspot menggunakan Bluetooth Rendah Energi untuk menemukan dan berkomunikasi dengan perangkat yang telah masuk ke akun iCloud yang sama. Komputer Mac kompatibel yang menjalankan OS X Yosemite dan lebih baru menggunakan teknologi yang sama untuk menemukan dan berkomunikasi dengan perangkat iOS Instant Hotspot. Saat pengguna memasukkan Pengaturan Wi-Fi di perangkat iOS, perangkat memancarkan sinyal Bluetooth Rendah Energi berisi pengenal yang disetujui oleh semua perangkat yang masuk ke akun iCloud yang sama. Pengenal dibuat dari DSID (Pengenal Sinyal Tujuan) yang dikaitkan dengan akun iCloud, dan dirotasi secara berkala. Saat perangkat lain yang masuk ke akun iCloud yang sama berada di sekitar dan mendukung hotspot pribadi, perangkat dapat mendeteksi sinyal dan merespons, menunjukkan ketersediaan.


51

Saat pengguna memilih perangkat yang tersedia untuk hotspot pribadi, permintaan untuk menyalakan Hotspot Pribadi akan dikirimkan ke perangkat tersebut. Permintaan dikirimkan melalui tautan yang dienkripsi menggunakan enkripsi Bluetooth Rendah Energi standar, dan permintaan dienkripsi dengan cara yang serupa dengan enkripsi iMessage. Perangkat kemudian merespons melalui tautan Bluetooth Rendah Energi yang sama menggunakan enkripsi per pesan yang sama dengan informasi koneksi hotspot pribadi.

Saran Spotlight Pencarian Safari dan Spotlight dilengkapi dengan saran pencarian dari Internet, app, iTunes, App Store, jadwal tayang film, lokasi di sekitar, dan lainnya. Untuk membuat saran lebih relevan bagi pengguna, konteks pengguna dan umpan balik pencarian dengan permintaan pencarian dikirimkan ke Apple. Konteks yang dikirimkan dengan permintaan pencarian memberi Apple: i) perkiraan lokasi perangkat; ii) jenis perangkat (misal, Mac, iPhone, iPad, atau iPod); iii) app klien, yaitu Spotlight atau Safari; iv) pengaturan bahasa dan wilayah default perangkat; v) tiga app yang paling terakhir digunakan di perangkat; dan vi) ID sesi anonim. Semua komunikasi dengan server dienkripsi melalui HTTPS. Untuk membantu melindungi privasi pengguna, Saran Spotlight tidak pernah mengirimkan lokasi persis, tapi mengaburkan lokasi di klien sebelum mengirimkannya. Level pengaburan didasarkan pada perkiraan kepadatan populasi di lokasi perangkat; misalnya, pengaburan yang lebih banyak akan digunakan di lokasi pedesaan, sedangkan pengaburan yang lebih sedikit digunakan di pusat kota tempat pengguna biasanya lebih dekat satu sama lain. Selain itu, pengguna dapat menonaktifkan pengiriman semua informasi lokasi ke Apple di Pengaturan, dengan mematikan Layanan Lokasi untuk Saran Spotlight. Jika Layanan Lokasi dinonaktifkan, maka Apple dapat menggunakan alamat IP milik klien untuk menentukan perkiraan lokasi. ID sesi anonim memungkinkan Apple untuk menganalisis pola antara permintaan dalam periode waktu 15 menit. Misalnya, jika pengguna sering mencari “nomor telepon Kafe” segera setelah mencari “Kafe,” Apple dapat menyimpulkan untuk membuat nomor telepon lebih tersedia di hasil. Tidak seperti kebanyakan mesin pencari, layanan pencarian Apple tidak menggunakan pengenal pribadi tetap di semua riwayat pencarian pengguna untuk mengaitkan permintaan ke pengguna atau perangkat; sebagai gantinya, perangkat Apple menggunakan ID sesi anonim sementara selama maksimal 15 menit sebelum menghapus ID tersebut. Informasi di tiga app yang paling terakhir digunakan di perangkat disertakan sebagai konteks pencarian tambahan. Untuk melindungi privasi pengguna, hanya app yang ada di daftar putih app populer yang dikelola Apple dan telah diakses dalam tiga jam terakhir yang disertakan. Umpan balik pencarian yang dikirim ke Apple memberi Apple: i) waktu antara tindakan pengguna, seperti tombol ditekan dan pilihan hasil; ii) hasil Saran Spotlight yang dipilih, jika ada; dan iii) jenis hasil lokal yang dipilih (misal, “Penanda” atau “Kontak”). Sama halnya dengan konteks pencarian, umpan balik pencarian tidak dikaitkan dengan orang atau perangkat tertentu. Apple menyimpan log Saran Spotlight dengan permintaan, konteks, dan umpan balik hingga selama 18 bulan. Log yang lebih sedikit yang hanya berisi permintaan, negara, bahasa, tanggal (hingga rincian jam), dan jenis perangkat disimpan hingga selama dua tahun. Alamat IP tidak disimpan dengan log permintaan. Dalam beberapa kasus, Saran Spotlight dapat meneruskan permintaan untuk kata dan frasa umum ke rekan yang berkualifikasi agar dapat menerima dan menampilkan hasil pencarian rekan. Permintaan ini tidak disimpan oleh rekan berkualifikasi dan Keamanan iOS—Buku Putih | Mei 2016

52

rekan tidak menerima umpan balik pencarian. Rekan juga tidak menerima alamat IP milik pengguna. Komunikasi dengan rekan dienkripsi melalui HTTPS. Apple akan menyediakan lokasi setingkat kota, jenis perangkat, dan bahasa klien sebagai konteks pencarian ke rekan berdasarkan lokasi, jenis perangkat, dan bahasa yang menjadi rujukan permintaan berulang bagi Apple. Saran Spotlight dapat dimatikan di Pengaturan untuk Spotlight, Safari, atau keduanya. Jika dimatikan untuk Spotlight, Spotlight akan kembali menjadi klien pencarian lokal di perangkat yang tidak mengirimkan informasi ke Apple. Jika dimatikan di Safari, permintaan pencarian pengguna, konteks pencarian, dan umpan balik pencarian tidak dikirimkan ke Apple. Spotlight juga disertai dengan mekanisme untuk membuat konten lokal di perangkat yang dapat dicari: • API CoreSpotlight, yang memungkinkan Apple dan app pihak ketiga untuk meneruskan konten yang dapat diindeks ke Spotlight. • API NSUserActivity, yang memungkinkan Apple dan app pihak ketiga untuk meneruskan informasi perihal halaman app yang dikunjungi pengguna. Spotlight memelihara indeks informasi di perangkat yang diterima menggunakan dua metode ini, sehingga hasil dari data ini dapat ditampilkan sebagai respons terhadap pencarian pengguna, atau secara otomatis saat Spotlight diluncurkan. Juga terdapat API pencarian gabungan di perangkat, hanya tersedia bagi app yang disediakan Apple, yang memungkinkan Spotlight untuk meneruskan permintaan pencarian pengguna ke app untuk diproses, dan menerima hasilnya.


53

Kontrol Perangkat iOS mendukung kebijakan dan konfigurasi keamanan fleksibel yang mudah diterapkan dan dikelola. Ini memungkinkan organisasi untuk melindungi informasi perusahaan dan memastikan bahwa karyawan memenuhi persyaratan perusahaan, meskipun mereka menggunakan perangkat yang disediakan sendiri—misalnya, sebagai bagian dari program “bawa perangkat Anda sendiri” (BYOD). Organisasi dapat menggunakan sumber seperti perlindungan kode sandi, profil konfigurasi, penghapusan jarak jauh, dan solusi MDM pihak ketiga untuk mengelola rangkaian perangkat dan membantu menjaga agar data perusahaan tetap aman, bahkan saat karyawan mengakses data ini di perangkat iOS pribadi mereka.

Perlindungan kode sandi Secara default, kode sandi pengguna dapat didefinisikan sebagai PIN numerik. Di perangkat dengan Touch ID, panjang minimum kode sandi adalah enam digit. Di perangkat lain, panjang minimum adalah empat digit. Pengguna dapat menetapkan kode sandi alfanumerik yang lebih panjang dengan memilih Kode Alfanumerik Khusus di Pilihan Kode Sandi di Pengaturan > Kode Sandi. Kode sandi yang lebih panjang dan rumit lebih sulit ditebak atau diserang, dan dianjurkan untuk penggunaan perusahaan. Administrator dapat menerapkan persyaratan kode sandi yang rumit dan kebijakan lain menggunakan MDM atau Exchange ActiveSync, atau dengan mengharuskan pengguna untuk menginstal profil konfigurasi secara manual. Kebijakan kode sandi berikut tersedia: • Mengizinkan nilai sederhana • Memerlukan nilai alfanumerik • Panjang kode sandi minimum • Jumlah karakter rumit minimum • Umur kode sandi maksimum • Riwayat kode sandi • Durasi waktu habis kunci otomatis • Masa tenggang penguncian perangkat • Jumlah maksimum upaya gagal • Mengizinkan Touch ID Untuk detail mengenai setiap kebijakan, lihat dokumentasi Referensi Kunci Profil Konfigurasi di developer.apple.com/library/ios/featuredarticles/ iPhoneConfigurationProfileRef.


54

Model pemasangan iOS iOS menggunakan model pemasangan untuk mengontrol akses ke perangkat dari komputer host. Pemasangan membangun hubungan kepercayaan antara perangkat dan host yang terhubung, ditandai oleh pertukaran kunci publik. iOS menggunakan tanda kepercayaan ini untuk mengaktifkan fungsi tambahan dengan host yang terhubung, seperti penyelarasan data. Di iOS 9, layanan yang memerlukan pemasangan tidak dapat dimulai hingga setelah perangkat telah dibuka oleh pengguna. Proses pemasangan mengharuskan pengguna untuk membuka perangkat dan menerima permintaan pemasangan dari host. Setelah pengguna melakukannya, host dan perangkat akan bertukar dan menyimpan kunci publik RSA 2048 bit. Host kemudian diberi kunci 256 bit yang dapat membuka kantung kunci eskrow yang disimpan di perangkat (lihat kantong kunci Eskrow di bagian Kantong Kunci). Kunci yang ditukar digunakan untuk memulai sesi SSL terenkripsi, yang diperlukan perangkat sebelum mengirimkan data terlindungi ke host atau memulai layanan (penyelarasan iTunes, transfer file, pengembangan Xcode, dll.). Perangkat memerlukan koneksi dari host melalui Wi-Fi untuk menggunakan sesi terenkripsi ini untuk semua komunikasi, sehingga perangkat harus telah dipasangkan sebelumnya melalui USB. Pemasangan juga mengaktifkan beberapa fitur diagnostik. Di iOS 9, jika rekaman pemasangan belum digunakan selama lebih dari enam bulan, rekaman akan kedaluwarsa. Untuk informasi lainnya, lihat support.apple.com/kb/HT6331?viewlocale=id_ID. Layanan tertentu, termasuk com.apple.pcapd, dibatasi untuk hanya dapat digunakan melalui USB. Selain itu, layanan com.apple.file_relay mengharuskan profil konfigurasi yang ditandatangani Apple untuk diinstal. Pengguna dapat membersihkan daftar host tepercaya dengan menggunakan pilihan “Atur Ulang Pengaturan Jaringan” atau “Atur Ulang Lokasi & Privasi”. Untuk informasi lainnya, lihat support.apple.com/kb/HT5868?viewlocale=id_ID.

Pemberlakuan konfigurasi Profil konfigurasi adalah file XML yang memungkinkan administrator untuk mendistribusikan informasi konfigurasi ke perangkat iOS. Pengaturan yang ditetapkan oleh profil konfigurasi yang diinstal tidak dapat diubah oleh pengguna. Jika pengguna menghapus profil konfigurasi, semua pengaturan yang ditetapkan oleh profil juga dihapus. Dengan cara ini, administrator dapat memberlakukan pengaturan dengan mengaitkan kebijakan ke akses. Misalnya, profil konfigurasi yang menyediakan konfigurasi email juga dapat menetapkan kebijakan kode sandi perangkat. Pengguna tidak akan dapat mengakses mail kecuali jika kode sandi mereka memenuhi persyaratan administrator. Profil konfigurasi iOS berisi sejumlah pengaturan yang dapat ditetapkan, meliputi: • Kebijakan kode sandi • Pembatasan terhadap fitur perangkat (menonaktifkan kamera, misalnya) • Pengaturan Wi-Fi • Pengaturan VPN • Pengaturan server Mail • Pengaturan Exchange • Pengaturan layanan direktori LDAP • Pengaturan layanan kalender CalDAV • Klip Web • Info pengesahan dan kunci • Pengaturan jaringan seluler lanjutan Keamanan iOS—Buku Putih | Mei 2016

55

Profil konfigurasi dapat ditandatangani dan dienkripsi untuk memvalidasi asalnya, memastikan integritasnya, dan melindungi kontennya. Profil konfigurasi dienkripsi menggunakan CMS (RFC 3852), yang mendukung 3DES dan AES-128. Profil konfigurasi juga dapat dikunci ke perangkat untuk mencegahnya dihapus secara keseluruhan, atau untuk hanya mengizinkan penghapusan dengan kode sandi. Karena banyak pengguna perusahaan yang memiliki perangkat iOS, profil konfigurasi yang mengikat perangkat ke server MDM dapat dihapus—tapi hal tersebut akan menghapus semua informasi konfigurasi, data, dan app yang dikelola. Pengguna dapat menginstal profil konfigurasi langsung di perangkat mereka menggunakan Apple Configurator, atau profil dapat diunduh melalui Safari, dikirimkan melalui pesan mail, atau secara nirkabel menggunakan server MDM.

Mobile device management (MDM) Dukungan Apple untuk MDM memungkinkan bisnis untuk mengonfigurasi dan mengelola penyebaran iPhone dan iPad secara aman di seluruh organisasi mereka. Fitur MDM dibuat berdasarkan teknologi iOS yang ada, seperti profil konfigurasi, pendaftaran nirkabel, dan layanan Pemberitahuan Push Apple (APN). Misalnya, APN digunakan untuk membangunkan perangkat sehingga dapat berkomunikasi langsung dengan server MDM melalui koneksi aman. Tidak ada informasi rahasia atau khusus yang dikirimkan melalui APN. Dengan MDM, departemen TI dapat mendaftarkan perangkat iOS di lingkungan perusahaan, mengonfigurasi dan memperbarui pengaturan secara nirkabel, mengawasi kepatuhan terhadap kebijakan perusahaan, bahkan menghapus atau mengunci perangkat yang dikelola dari jauh. Untuk informasi lain mengenai mobile device management, lihat www.apple.com/iphone/business/it/management.html.

iPad Bersama iPad Bersama adalah mode beberapa pengguna untuk kepentingan pengajaran. Mode ini memungkinkan murid untuk berbagi iPad tanpa membagikan dokumen dan data. iPad Bersama memerlukan penggunaan ID Apple yang Dikelola yang diterbitkan dan dimiliki oleh sekolah. iPad Bersama memungkinkan murid untuk masuk ke perangkat milik organisasi yang dikonfigurasi untuk digunakan oleh beberapa murid. Data murid dipartisi ke direktori utama terpisah, yang masing-masing dilindungi oleh izin UNIX dan sandbox. Saat murid masuk, ID Apple yang Dikelola disahkan dengan server identitas Apple menggunakan protokol SRP. Jika berhasil, token akses sementara khusus perangkat akan diberikan. Jika murid telah menggunakan perangkat sebelumnya, mereka akan memiliki akun pengguna lokal yang dibuka. Jika murid belum menggunakan perangkat sebelumnya, ID pengguna UNIX baru direktori utama, dan rantai kunci akan disediakan. (Jika perangkat tidak terhubung ke Internet, hanya pengguna dengan akun lokal yang sebelumnya ada yang dapat masuk.) Setelah akun lokal murid dibuka atau dibuat, jika disahkan dari jauh, token sementara yang diterbitkan server Apple akan dikonversi ke token iCloud yang mengizinkan proses masuk ke iCloud. Setelah itu, pengaturan murid akan disimpan dan dokumen serta data mereka akan diselaraskan dari iCloud. Saat sesi murid aktif dan perangkat online, dokumen dan data akan disimpan di iCloud saat dibuat atau dimodifikasi. Selain itu, mekanisme penyelarasan latar belakang memastikan bahwa perubahan didorong ke iCloud setelah murid keluar.


56

Apple School Manager Apple School Manager adalah layanan untuk institusi pendidikan yang memungkinkan mereka untuk membeli konten, mengonfigurasi pendaftaran perangkat otomatis di solusi mobile device management (MDM), membuat akun untuk murid dan staf, serta mengatur kursus iTunes U. Apple School Manager dapat diakses di web dan dirancang untuk pengelola teknologi dan administrator IT, staf, dan instruktur.

Pendaftaran Perangkat Program Pendaftaran Perangkat (DEP) menyediakan cara yang cepat dan sederhana untuk menyebarkan perangkat iOS yang telah dibeli organisasi langsung dari Apple atau melalui Pengecer Resmi Apple dan operator yang berpartisipasi. Pendaftaran perangkat juga merupakan fitur terpadu dari Apple School Manager untuk institusi pendidikan. Organisasi dapat mendaftarkan perangkat di MDM secara otomatis tanpa harus menyentuh atau mempersiapkan perangkat secara langsung sebelum perangkat sampai ke tangan pengguna. Setelah terdaftar di program, administrator masuk ke situs web program, menautkan program ke server MDM mereka. Perangkat yang mereka beli dapat ditetapkan ke pengguna melalui MDM. Setelah pengguna ditetapkan, semua konfigurasi, pembatasan, atau kontrol yang ditentukan MDM akan diinstal secara otomatis. Semua komunikasi antara perangkat dan server Apple dienkripsi saat dikirimkan melalui HTTPS (SSL). Proses pengaturan untuk pengguna dapat disederhanakan lebih lanjut dengan menghapus langkah tertentu di Asisten Pengaturan, sehingga perangkat pengguna dapat siap digunakan dengan cepat. Administrator juga dapat mengontrol apakah pengguna dapat menghapus profil MDM dari perangkat dan memastikan bahwa pembatasan perangkat telah aktif sejak awal. Setelah perangkat dibuka dan diaktifkan, perangkat akan terdaftar di MDM organisasi—dan semua pengaturan, app, dan buku manajemen akan terinstal. Untuk informasi lainnya, lihat Bantuan Program Pendaftaran Perangkat, atau untuk institusi pendidikan, lihat Bantuan Apple School Manager. Catatan: Pendaftaran perangkat tidak tersedia di semua negara atau wilayah.

Apple Configurator 2 Selain MDM, Apple Configurator untuk OS X memudahkan semua orang untuk mengatur dan mengonfigurasi awal perangkat sebelum menyerahkannya ke pengguna. Apple Configurator dapat digunakan untuk dengan cepat mengonfigurasi awal perangkat dengan app, data, pembatasan, dan pengaturan. Apple Configurator 2 memungkinkan Anda untuk menggunakan Apple School Manager (untuk pendidikan) atau Program Pendaftaran Perangkat (untuk bisnis) untuk mendaftarkan perangkat di solusi mobile device management (MDM) tanpa mengharuskan pengguna untuk menggunakan Asisten Pengaturan.


57

Penyeliaan Selama pengaturan perangkat, organisasi dapat mengonfigurasi perangkat untuk diselia. Penyeliaan menunjukkan bahwa perangkat dimiliki oleh suatu lembaga, yang menyediakan kontrol tambahan atas konfigurasi dan pembatasannya. Perangkat dapat diselia selama pengaturan melalui Apple School Manager, Program Pendaftaran Perangkat atau Apple Configurator. Untuk informasi lainnya mengenai cara mengonfigurasi dan mengelola perangkat menggunakan MDM atau Apple Configurator, lihat Referensi Penyebaran iOS di Referensi Penyebaran iOS.

Pembatasan Administrator dapat membatasi fitur perangkat dengan menginstal profil konfigurasi. Beberapa pembatasan yang tersedia meliputi: • Mengizinkan penginstalan app • Mengizinkan kepercayaan atas app perusahaan • Mengizinkan penggunaan kamera • Mengizinkan FaceTime • Mengizinkan jepretan layar • Mengizinkan panggilan suara saat terkunci • Mengizinkan penyelarasan otomatis saat roaming • Mengizinkan pembelian in-app • Mengizinkan penyelarasan Mail terbaru • Memaksa pengguna untuk memasukkan kata sandi toko untuk semua pembelian • Mengizinkan Siri saat perangkat terkunci • Mengizinkan penggunaan iTunes Store • Mengizinkan dokumen dari sumber yang dikelola di tujuan yang tidak dikelola • Mengizinkan dokumen dari sumber yang tidak dikelola di tujuan yang dikelola • Mengizinkan penyelarasan Rantai Kunci iCloud • Mengizinkan pembaruan basis data kepercayaan sertifikat secara nirkabel • Mengizinkan ditampilkannya pemberitahuan di layar Terkunci • Memaksa koneksi AirPlay untuk menggunakan kata sandi pemasangan • Mengizinkan Spotlight untuk menampilkan konten yang dibuat pengguna dari Internet • Mengaktifkan Saran Spotlight di Spotlight • Mengizinkan Handoff • Memperlakukan AirDrop sebagai tujuan yang tidak dikelola • Mengizinkan buku perusahaan untuk dicadangkan • Mengizinkan catatan dan penanda di buku perusahaan untuk menyelaraskan antar perangkat pengguna • Mengizinkan penggunaan Safari • Mengaktifkan isi-auto Safari • Memaksakan Peringatan Situs Web Palsu • Mengaktifkan JavaScript • Membatasi pelacakan iklan di Safari • Memblokir pop-up • Menerima cookie • Mengizinkan cadangan iCloud • Mengizinkan penyelarasan dokumen iCloud dan nilai kunci • Mengizinkan Berbagi Foto iCloud • Mengizinkan diagnostik untuk dikirimkan ke Apple • Mengizinkan pengguna untuk menerima sertifikat TLS yang tidak tepercaya Keamanan iOS—Buku Putih | Mei 2016

58

• Memaksa cadangan terenkripsi • Mengizinkan Touch ID • Mengizinkan akses Pusat Kontrol dari Layar Terkunci • Mengizinkan tampilan Hari Ini dari layar Terkunci • Memerlukan deteksi pergelangan tangan Apple Watch • Mengizinkan pengamatan layar dengan Ruang Kelas • Menggunakan AirDrop dari app yang dikelola • Mempercayai pengembang app perusahaan baru • Menggunakan Perpustakaan Foto iCloud

Pembatasan khusus pengawasan • Mengizinkan iMessage • Mengizinkan penghapusan app • Mengizinkan penginstalan manual profil konfigurasi • Proxy jaringan global untuk HTTP • Mengizinkan pemasangan ke komputer untuk penyelarasan konten • Membatasi koneksi AirPlay dengan daftar putih dan kode sandi koneksi opsional • Mengizinkan AirDrop • Mengizinkan modifikasi Cari Teman Saya • Mengizinkan Mode App Tunggal otonom untuk app tertentu yang dikelola • Mengizinkan modifikasi akun • Mengizinkan modifikasi data seluler • Mengizinkan pemasangan host (iTunes) • Mengizinkan Kunci Aktivasi • Mencegah Hapus Konten & Pengaturan • Mencegah pengaktifkan pembatasan • Filter konten pihak ketiga • Mode App Tunggal • VPN Selalu Nyala • Mengizinkan modifikasi kode sandi • Mengizinkan pemasangan Apple Watch • Mengizinkan pengunduhan app otomatis • Mengizinkan prediksi papan ketik, koreksi otomatis, pemeriksaan ejaan, dan pintasan • Mengizinkan Apple Music • Mengizinkan Radio • Pengamatan layar dengan Ruang Kelas • Perubahan pada pengaturan Pemberitahuan • Menampilkan atau menyembunyikan app tertentu di layar Utama • Menginstal app menggunakan App Store • Pengunduhan app otomatis • Pintasan papan ketik • Mengizinkan Definisi • Memodifikasi nama perangkat • Mengubah wallpaper • Menyembunyikan app News • Memasangkan dengan Apple Watch Untuk informasi mengenai kontrol tambahan atas perangkat yang diselia, lihat Referensi Profil Konfigurasi.


59

Penghapusan Jarak Jauh Perangkat iOS dapat dihapus dari jauh oleh administrator atau pengguna. Penghapusan jarak jauh instan dilakukan secara aman dengan menghapus kunci enkripsi penyimpanan blok dari Penyimpanan Dapat Dihapus, sehingga membuat semua data tidak dapat dibaca. Perintah penghapusan jarak jauh dapat dimulai oleh MDM, Exchange, atau iCloud. Saat perintah penghapusan jarak jauh dipicu oleh MDM atau iCloud, perangkat akan mengirimkan pengakuan dan melakukan penghapusan. Untuk penghapusan jarak jauh melalui Exchange, perangkat melakukan pemeriksaan dengan Server Exchange sebelum melakukan penghapusan. Pengguna juga dapat menghapus perangkat yang mereka miliki menggunakan app Pengaturan. Dan sebagaimana yang disebutkan, perangkat dapat diatur agar dihapus secara otomatis setelah serangkaian upaya memasukkan kode sandi yang gagal.

Mode Hilang Jika perangkat hilang atau dicuri, administrator MDM dapat mengaktifkan Mode Hilang dari jauh di perangkat yang diselia dengan iOS 9.3 atau lebih baru. Jika Mode Hilang diaktifkan, pengguna saat ini akan keluar dan perangkat tidak dapat dibuka. Layar menampilkan pesan yang dapat disesuaikan oleh administrator, seperti menampilkan nomor telepon untuk dihubungi jika perangkat ditemukan. Saat Mode Hilang diaktifkan di perangkat, administrator dapat meminta perangkat untuk mengirim lokasinya saat ini. Jika administrator mematikan Mode Hilang, yang merupakan satu-satunya cara untuk keluar dari mode tersebut, pengguna akan diberi tahu perihal tindakan ini melalui pesan di layar terkunci dan peringatan di layar utama.

Kunci Aktivasi Jika Cari iPhone Saya dinyalakan, perangkat tidak dapat diaktifkan ulang tanpa memasukkan info pengesahan ID Apple pemilik. Dengan perangkat yang dimiliki organisasi, Anda dianjurkan untuk menyelia perangkat sehingga kunci Aktivasi dapat dikelola oleh organisasi alih-alih meminta pengguna perorangan untuk memasukkan info pengesahan ID Apple mereka untuk mengaktifkan ulang perangkat. Di perangkat yang diselia, solusi MDM yang kompatibel dapat menyimpan kode pintasan saat Kunci Aktivasi diaktifkan, dan kemudian menggunakan kode ini untuk membersihkan Kunci Aktivasi secara otomatis saat perangkat perlu dihapus atau ditetapkan ke pengguna baru. Lihat dokumentasi solusi MDM Anda untuk detail. Secara default, perangkat yang diselia tidak pernah mengaktifkan Kunci Aktivasi, meskipun pengguna menyalakan Cari iPhone Saya. Namun, server MDM dapat menerima kode pintasan dan mengizinkan Kunci Aktivasi untuk diaktifkan di perangkat. Jika Cari iPhone Saya dinyalakan saat server MDM mengaktifkan Kunci Aktivasi, fitur akan diaktifkan pada tahap tersebut. Jika Cari iPhone Saya dimatikan saat server MDM mengaktifkan Kunci Aktivasi, fitur akan dinyalakan setelah pengguna mengaktifkan Cari iPhone Saya. Untuk perangkat yang digunakan untuk tujuan pendidikan dengan ID Apple yang Dikelola yang dibuat melalui Apple School Manager, Kunci Aktivasi dapat dikaitkan ke ID Apple Administrator alih-alih ke ID Apple pengguna, atau dinonaktifkan menggunakan kode pintasan perangkat.


60

Kontrol Privasi Apple tidak menyepelekan privasi pelanggan dan Apple memiliki kontrol dan pilihan internal yang memungkinkan pengguna iOS untuk memutuskan bagaimana dan kapan app dapat menggunakan informasi mereka, serta informasi apa yang digunakan.

Layanan Lokasi Layanan Lokasi menggunakan GPS, Bluetooth, dan hotspot Wi-Fi banyak sumber dan lokasi menara seluler untuk menentukan perkiraan lokasi pengguna. Layanan Lokasi dapat dimatikan menggunakan pengalih tunggal di Pengaturan, atau pengguna dapat menyetujui akses untuk setiap app yang menggunakan layanan. App dapat meminta untuk menerima data lokasi hanya saat app sedang digunakan atau setiap saat. Pengguna dapat memilih untuk tidak mengizinkan akses ini, dan dapat mengubah pilihan mereka setiap saat di Pengaturan. Dari Pengaturan, akses dapat diatur menjadi tidak pernah diizinkan, diizinkan saat digunakan, atau selalu, tergantung penggunaan lokasi yang diminta app. Selain itu, jika app yang diberi akses untuk menggunakan lokasi setiap saat menggunakan izin ini saat dalam mode latar belakang, pengguna akan diingatkan perihal persetujuan mereka dan dapat mengubah akses app. Sebagai tambahan, pengguna diberi kontrol yang detail terhadap penggunaan informasi lokasi oleh layanan sistem. Kontrol tersebut meliputi kemampuan untuk mematikan disertakannya informasi lokasi di informasi yang dikumpulkan oleh layanan diagnostik dan penggunaan yang digunakan Apple untuk meningkatkan iOS, informasi Siri berbasis lokasi, konteks berbasis lokasi untuk pencarian Saran Spotlight, kondisi lalu lintas lokal, dan lokasi yang sering dikunjungi yang digunakan untuk memperkirakan waktu perjalanan.

Akses data pribadi iOS membantu mencegah app untuk mengakses informasi pribadi milik pengguna tanpa izin. Selain itu, di Pengaturan, pengguna dapat melihat app mana yang mereka izinkan untuk mengakses informasi tertentu, serta memberikan atau membatalkan akses tertentu pada masa mendatang. Ini meliputi akses ke: • Kontak

• Mikrofon

• Kalender

• Kamera

• Pengingat

• HomeKit

• Foto

• HealthKit

• Aktivitas gerakan di iPhone 5s atau lebih baru

• Berbagi Bluetooth

• Perpustakaan Media • Akun media sosial, seperti Twitter dan Facebook Jika pengguna masuk ke iCloud, app diberi akses secara default ke iCloud Drive. Pengguna dapat mengontrol tiap akses app di bagian iCloud dalam Pengaturan. Selain itu, iOS menyediakan pembatasan yang mencegah perpindahan data antara app dan akun yang diinstal oleh MDM dan yang diinstal oleh pengguna.

Kebijakan privasi Kebijakan privasi Apple tersedia secara online di www.apple.com/legal/privacy/id. Keamanan iOS—Buku Putih | Mei 2016

61

Kesimpulan Komitmen terhadap keamanan Apple berkomitmen untuk membantu melindungi pelanggan dengan teknologi privasi dan keamanan terkemuka yang dirancang untuk menjaga informasi pribadi, serta metode yang menyeluruh untuk membantu melindungi data perusahaan di lingkungan perusahaan. Keamanan merupakan bagian internal dari iOS. Dari platform hingga jaringan hingga app, semua yang diperlukan bisnis tersedia di platform iOS. Bersama-sama, semua komponen ini memberi iOS keamanan terdepan di industrinya tanpa mengganggu pengalaman pengguna. Apple menggunakan infrastruktur keamanan terpadu dan konsisten di seluruh ekosistem app iOS dan di sistem iOS. Enkripsi penyimpanan berbasis perangkat keras menyediakan fitur penghapusan jarak jauh saat perangkat hilang, dan memungkinkan pengguna untuk sepenuhnya menghapus informasi perusahaan dan pribadi saat perangkat dijual atau ditransfer ke pemilik lain. Informasi diagnostik juga dikumpulkan secara anonim. App iOS yang dirancang oleh Apple dibuat dengan dasar keamanan yang ditingkatkan. Safari menawarkan penelusuran yang aman dengan dukungan untuk Protokol Status Sertifikat Online (OCSP), sertifikat EV, dan peringatan verifikasi sertifikat. Mail memanfaatkan sertifikat untuk Mail yang disahkan dan dienkripsi dengan mendukung S/MIME, yang mengizinkan S/MIME per pesan sehingga pengguna S/MIME dapat memilih untuk selalu menandatangani dan mengenkripsi secara default, atau mengontrol secara selektif bagaimana pesan dilindungi secara terpisah. iMessage dan FaceTime juga menyediakan enkripsi klien-ke-klien. Untuk app pihak ketiga, gabungan penandatanganan kode yang diperlukan, penggunaan mekanisme sandbox, dan hak memberikan pengguna perlindungan yang kuat dari virus, malware, dan eksploitasi lainnya yang dapat mengganggu keamanan platform lain. Proses pengiriman App Store berfungsi untuk melindungi pengguna secara lebih lanjut dari risiko ini dengan meninjau setiap app iOS sebelum disediakan untuk dijual. Untuk mengoptimalkan fitur keamanan ekstensif yang tersedia secara internal di iOS, bisnis dianjurkan untuk meninjau kebijakan TI dan keamanan mereka untuk memastikan bahwa mereka benar-benar memanfaatkan lapisan teknologi keamanan yang ditawarkan oleh platform ini. Apple mempekerjakan tim keamanan khusus untuk mendukung semua produk Apple. Tim tersebut mengaudit dan menguji keamanan untuk produk yang sedang dikembangkan, serta untuk produk yang telah dirilis. Tim Apple juga menyediakan alat dan pelatihan keamanan, dan secara aktif mengawasi laporan masalah dan ancaman keamanan baru. Apple adalah anggota Forum Tim Keamanan dan Penanganan Insiden (FIRST). Untuk mempelajari lebih lanjut tentang cara melaporkan masalah ke Apple dan berlangganan pemberitahuan keamanan, buka apple.com/id/support/security.


62

Glosarium Pengacakan tata letak ruang alamat (ASLR)

Teknik yang diterapkan oleh iOS untuk mempersulit eksploitasi bug perangkat lunak. Dengan memastikan bahwa alamat dan ofset memori tidak dapat diprediksi, kode eksploitasi tidak dapat mengodekan paksa nilai ini. Di iOS 5 dan lebih baru, posisi semua app sistem dan perpustakaan dibuat acak, bersama dengan semua app pihak ketiga yang dikumpulkan sebagai file bebas posisi yang dapat dieksekusi.

Layanan Pemberitahuan Push Apple (APN)

Layanan global dari Apple yang mengirimkan pemberitahuan push ke perangkat iOS.

ROM Boot

Kode paling pertama yang dijalankan oleh prosesor perangkat saat boot pertama. Sebagai bagian integral dari prosesor, ROM Boot tidak dapat diubah oleh Apple atau penyerang.

Perlindungan Data

Mekanisme perlindungan file dan rantai kunci untuk iOS. Perlindungan Data juga dapat merujuk ke API yang digunakan app untuk melindungi file dan item rantai kunci.

Peningkatan Firmware Perangkat (DFU)

Mode tempat kode ROM Boot perangkat menunggu untuk dipulihkan melalui USB. Layar menjadi hitam saat dalam mode DFU, tapi saat tersambung ke komputer yang menjalankan iTunes, perintah berikut akan muncul: “iTunes telah mendeteksi iPad dalam mode pemulihan. Anda harus memulihkan iPad ini sebelum perangkat dapat digunakan dengan iTunes.”

ECID

Pengenal 64 bit yang bersifat unik untuk prosesor di setiap perangkat iOS. Digunakan sebagai bagian dari proses penyesuaian, pengenal tidak dianggap sebagai rahasia.

Penyimpanan Dapat Dihapus

Area khusus penyimpanan NAND, digunakan untuk menyimpan kunci kriptografis, yang dapat diakses secara langsung dan dihapus dengan aman. Meskipun tidak menyediakan perlindungan jika perangkat berada di tangan penyerang, kunci yang disimpan di Penyimpanan Dapat Dihapus dapat digunakan sebagai bagian dari hierarki kunci untuk memfasilitasi penghapusan cepat dan keamanan berkelanjutan.

Kunci sistem file

Kunci yang mengenkripsi setiap metadata file, termasuk kunci kelasnya. Kunci ini disimpan di Penyimpanan Dapat Dihapus untuk memfasilitasi penghapusan cepat, bukan memfasilitasi kerahasiaan.

ID Grup (GID)

Seperti UID tapi bersifat umum untuk semua prosesor di satu kelas.

Modul keamanan perangkat keras (HSM)

Komputer khusus tahan kerusakan yang melindungi dan mengelola kunci digital.

iBoot

Kode yang dimuat oleh LLB, dan pada gilirannya memuat XNU, sebagai bagian dari rantai boot aman.

Layanan Identitas (IDS)

Direktori kunci publik iMessage Apple, alamat APN, serta nomor telepon dan alamat email yang digunakan untuk mencari kunci dan alamat perangkat.

Sirkuit terpadu (IC)

Juga disebut keping mikro.

Grup Tindakan Tes Gabungan (JTAG)

Alat debug perangkat keras standar yang digunakan oleh pemrogram dan pengembang sirkuit.


63

Kantong kunci

Struktur data yang digunakan untuk menyimpan kumpulan kunci kelas. Setiap jenis (pengguna, perangkat, sistem, cadangan, eskrow, atau Cadangan iCloud) memiliki format yang sama: • Header berisi: – Versi (diatur menjadi 3 di iOS 5) – Jenis (sistem, cadangan, eskrow, atau Cadangan iCloud) – UUID kantong kunci – HMAC jika kantong kunci ditandatangani – Metode yang digunakan untuk membungkus kunci kelas: dikaitkan dengan UID atau PBKDF2, bersama dengan jumlah salt dan iterasi • Daftar kunci kelas: – UUID kunci – Kelas (file atau kelas Perlindungan Data rantai kunci mana) – Jenis pembungkusan (hanya kunci turunan UID; kunci turunan UID, dan kunci turunan kode sandi) – Kunci kelas yang dibungkus – Kunci publik untuk kelas asimetris

Rantai Kunci

Infrastruktur dan kumpulan API yang digunakan oleh iOS dan app pihak ketiga untuk menyimpan dan mengambil kata sandi, kunci, dan info pengesahan sensitif lainnya.

Pembungkusan kunci

Dengan mengenkripsi satu kunci dengan kunci lain, iOS menggunakan pembungkusan kunci NIST AES, sesuai dengan RFC 3394.

Bootloader Level Rendah (LLB)

Kode yang diaktifkan oleh ROM Boot, dan pada gilirannya memuat iBoot, sebagai bagian dari rantai boot aman.

Kunci per file

Kunci 256 bit AES yang digunakan untuk mengenkripsi file di sistem file. Kunci per file dibungkus oleh kunci kelas dan disimpan di metadata file.

Profil Penyedia

Plist yang ditandatangani Apple berisi kumpulan entitas dan hak yang memungkinkan app untuk diinstal dan diuji di perangkat iOS. Profil Penyedia pengembangan membuat daftar perangkat yang telah dipilih pengembang untuk distribusi ad hoc, dan Profil Penyedia distribusi berisi ID app dari app yang dikembangkan perusahaan.

Pemetaan sudut alur kerutan

Representasi matematis dari arah dan lebar kerutan yang diekstrak dari bagian sidik jari.

Kartu cerdas

Sirkuit terpadu yang ditanam, yang menyediakan pengenalan, pengesahan, dan penyimpanan data secara aman.

Sistem pada keping (SoC)

Sirkuit terpadu (IC) yang menggabungkan beberapa komponen ke dalam satu keping. Enklave Aman adalah SoC di dalam prosesor pusat A7 Apple atau yang lebih baru.

Pengaitan

Proses pengubahan kode sandi pengguna menjadi kunci kriptografis dan diperkuat dengan UID perangkat. Ini memastikan bahwa serangan paksa harus dilakukan di perangkat tertentu, dan oleh karena itu, menjadi terbatas dan tidak dapat dilakukan secara paralel. Logaritma pengaitan adalah PBKDF2, yang menggunakan kunci AES dengan UID perangkat sebagai fungsi semu acak (PRF) untuk setiap iterasi.

Pengenal Sumber Seragam (URI)

String karakter yang mengidentifikasi sumber berbasis web.

ID Unik (UID)

Kunci AES 256 bit yang dibakar ke setiap prosesor pada proses produksi. UID tidak dapat dibaca oleh firmware atau perangkat lunak, dan hanya digunakan oleh mesin AES perangkat keras milik prosesor. Untuk mendapatkan kunci yang sebenarnya, penyerang harus melancarkan serangan fisik yang sangat rumit dan mahal pada silikon prosesor. UID tidak terkait dengan pengenal lain di perangkat termasuk, tapi tidak terbatas pada, UDID.

XNU

Kernel di pusat sistem operasi iOS dan OS X. XNU diasumsikan sebagai tepercaya, dan memberlakukan tindakan pengamanan seperti penandatanganan kode, penggunaan mekanisme sandbox, pemeriksaan hak, dan ASLR.


64

Riwayat Revisi Dokumen

Tanggal

Ringkasan

Mei 2016

Diperbarui untuk iOS 9,3 • iPad Bersama • ID Apple yang Dikelola • Pengesahan dua faktor untuk ID Apple • Kantong Kunci • Sertifikasi Keamanan • Kunci Aktivasi • Catatan Aman • Apple School Manager • Mode Hilang • Untuk informasi lainnya mengenai konten keamanan iOS 9.3, lihat: support.apple.com/id-id/HT206166

September 2015

Diperbarui untuk iOS 9 • Kunci aktivasi Apple Watch • Kebijakan kode sandi • Dukungan API Touch ID • Perlindungan Data di A8 menggunakan AES-XTS • Kantong kunci untuk pembaruan perangkat lunak yang tidak diawasi • Pembaruan sertifikasi • Model kepercayaan app perusahaan • Perlindungan data untuk penanda Safari • Keamanan Transpor App • Spesifikasi VPN • Akses Jarak Jauh iCloud untuk HomeKit • Kartu Hadiah Apple Pay • App penerbit kartu Apple Pay • Indeks Spotlight di perangkat • Model Pemasangan iOS • Apple Configurator • Pembatasan • Untuk informasi lainnya mengenai konten keamanan iOS 9, lihat: support.apple.com/kb/HT205212?viewlocale=id_ID

© 2016 Apple Inc. Semua hak cipta dilindungi undang-undang. Apple, logo Apple, AirDrop, AirPlay, Apple TV, Apple Watch, Bonjour, FaceTime, iBooks, iMessage, iPad, iPhone, iPod, iPod touch, iTunes, Rantai Kunci, Mac, OS X, Safari, Siri, Spotlight, dan Xcode adalah merek dagang Apple Inc., yang terdaftar di A.S. dan negara lainnya. Apple Pay, CarPlay Lightning, dan Touch ID adalah merek dagang Apple Inc. iCloud dan iTunes Store adalah merek layanan Apple Inc., yang terdaftar di A.S. dan negara lainnya. App Store dan iBooks Store adalah merek layanan Apple Inc. IOS adalah merek dagang atau merek dagang terdaftar Cisco di A.S. dan negara lainnya dan digunakan dengan lisensi. Merek kata dan logo Bluetooth® adalah merek dagang terdaftar milik Bluetooth SIG, Inc. dan segala penggunaan merek tersebut dilakukan oleh Apple berdasarkan lisensi. Java adalah merek dagang terdaftar Oracle dan/atau afiliasinya. Nama produk dan perusahaan lainnya yang disebutkan di sini mungkin adalah merek dagang dari perusahaan tersebut masing-masing. Spesifikasi produk dapat berubah tanpa pemberitahuan.


65

Keamanan ios ios 9.3 atau lebih baru. Mei 2016

Recommend Documents