Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Autentikasi

Android menggunakan konsep kunci kriptografi dengan gerbang autentikasi pengguna yang memerlukan komponen berikut:

Penyimpanan kunci kriptografi dan penyedia layanan. Menyimpan kunci kriptografi dan menyediakan rutinitas kripto standar di atas kunci tersebut. Android mendukung Keystore dan Keymaster yang didukung perangkat keras untuk layanan kriptografi, termasuk kriptografi yang didukung perangkat keras untuk penyimpanan kunci yang mungkin mencakup Trusted Execution Environment (TEE) atau Secure Element (SE), seperti Strongbox.
Pengautentikasi pengguna. Membuktikan kehadiran pengguna dan/atau otentikasi yang berhasil. Android mendukung Gatekeeper untuk otentikasi PIN/pola/kata sandi dan Sidik Jari untuk otentikasi sidik jari. Perangkat yang dikirimkan dengan Android 9 dan lebih tinggi dapat menggunakan BiometricPrompt sebagai titik integrasi tunggal untuk sidik jari dan biometrik tambahan. Komponen-komponen ini mengomunikasikan status autentikasinya dengan layanan keystore melalui saluran yang diautentikasi. ( Sistem Android Keystore pada tingkat kerangka kerja juga didukung oleh layanan keystore.)

Komponen Gatekeeper, Fingerprint, dan Biometric bekerja dengan Keystore dan komponen lainnya untuk mendukung penggunaan token autentikasi yang didukung perangkat keras (AuthTokens).

Pendaftaran

Pada booting pertama perangkat setelah reset pabrik, semua pengautentikasi siap menerima pendaftaran kredensial dari pengguna. Pengguna awalnya harus mendaftarkan PIN/pola/kata sandi dengan Gatekeeper. Pendaftaran awal ini membuat pengidentifikasi aman pengguna (SID) 64-bit yang dihasilkan secara acak yang berfungsi sebagai pengidentifikasi bagi pengguna dan sebagai token pengikat untuk materi kriptografi pengguna. SID pengguna ini terikat secara kriptografis dengan kata sandi pengguna; otentikasi yang berhasil ke Gatekeeper menghasilkan AuthToken yang berisi SID pengguna untuk kata sandi tersebut.

Pengguna yang ingin mengubah kredensial harus menunjukkan kredensial yang sudah ada. Jika kredensial yang ada berhasil diverifikasi, SID pengguna yang terkait dengan kredensial yang ada akan ditransfer ke kredensial baru, sehingga memungkinkan pengguna untuk tetap mengakses kunci setelah mengubah kredensial. Jika pengguna tidak menunjukkan kredensial yang ada, kredensial baru akan didaftarkan dengan SID Pengguna yang sepenuhnya acak. Pengguna dapat mengakses perangkat, tetapi kunci yang dibuat menggunakan SID pengguna lama akan hilang secara permanen. Hal ini dikenal sebagai pendaftaran tidak tepercaya .

Dalam keadaan normal, framework Android tidak mengizinkan pendaftaran yang tidak tepercaya, sehingga sebagian besar pengguna tidak akan pernah melihat fungsi ini. Namun, pengaturan ulang kata sandi secara paksa, baik oleh administrator perangkat atau penyerang, dapat menyebabkan hal ini terjadi.

Autentikasi

Setelah pengguna menyiapkan kredensial dan menerima SID pengguna, mereka dapat memulai autentikasi, yang dimulai saat pengguna memberikan PIN, pola, kata sandi, atau sidik jari. Semua komponen TEE berbagi kunci rahasia yang mereka gunakan untuk mengautentikasi pesan satu sama lain.

Gambar 1. Alur otentikasi

Pengguna menyediakan metode autentikasi dan layanan terkait membuat permintaan ke daemon terkait.
- Untuk PIN, pola, atau kata sandi, LockSettingsService membuat permintaan ke gatekeeperd .
- Alur autentikasi berbasis biometrik bergantung pada versi Android. Pada perangkat yang menjalankan Android 8.x dan lebih rendah, FingerprintService membuat permintaan ke fingerprintd ). Pada perangkat yang menjalankan Android 9 dan lebih tinggi, BiometricPrompt membuat permintaan ke daemon biometrik yang sesuai (misalnya, fingerprintd untuk sidik jari atau faced untuk wajah) menggunakan kelas Biometric Manager yang sesuai, seperti FingerprintManager atau FaceManager . Terlepas dari versinya, autentikasi biometrik terjadi secara asinkron setelah permintaan dikirim.
Daemon mengirimkan data ke mitranya, yang menghasilkan AuthToken:
- Untuk otentikasi PIN/pola/kata sandi, gatekeeperd mengirimkan PIN, pola, atau hash kata sandi ke Gatekeeper di TEE. Jika autentikasi di TEE berhasil, Gatekeeper di TEE mengirimkan AuthToken yang berisi SID pengguna terkait (ditandatangani dengan kunci HMAC AuthToken) ke mitranya di OS Android.
- Untuk otentikasi sidik jari, fingerprintd mendengarkan peristiwa sidik jari dan mengirimkan data ke Sidik Jari di TEE. Jika autentikasi di TEE berhasil, Sidik Jari di TEE akan mengirimkan AuthToken (ditandatangani dengan kunci HMAC AuthToken) ke mitranya di OS Android.
- Untuk otentikasi biometrik lainnya, daemon biometrik yang sesuai mendengarkan kejadian biometrik dan mengirimkannya ke komponen TEE biometrik yang sesuai.
Daemon menerima AuthToken yang ditandatangani dan meneruskannya ke layanan keystore melalui ekstensi ke antarmuka Binder layanan keystore. ( gatekeeperd juga memberi tahu layanan keystore ketika perangkat dikunci kembali dan ketika kata sandi perangkat berubah.)
Layanan keystore meneruskan AuthTokens ke Keymaster dan memverifikasinya menggunakan kunci yang dibagikan dengan Gatekeeper dan komponen TEE biometrik yang didukung. Keymaster memercayai stempel waktu dalam token sebagai waktu autentikasi terakhir dan mendasarkan keputusan rilis kunci (untuk mengizinkan aplikasi menggunakan kunci) pada stempel waktu tersebut.

format AuthToken

Untuk memastikan pembagian token dan kompatibilitas antar bahasa dan komponen, format AuthToken dijelaskan dalam hw_auth_token.h . Formatnya adalah protokol serialisasi sederhana dengan bidang ukuran tetap.

Bidang	Jenis	Diperlukan	Keterangan
Versi AuthToken	1 byte	Ya	Tag grup untuk semua bidang di bawah.
Tantangan	Bilangan bulat 64-bit yang tidak ditandatangani	TIDAK	Bilangan bulat acak untuk mencegah serangan ulangan. Biasanya ID dari operasi kripto yang diminta. Saat ini digunakan oleh otorisasi sidik jari transaksional. Jika ada, AuthToken hanya valid untuk operasi kripto yang berisi tantangan yang sama.
SID pengguna	Bilangan bulat 64-bit yang tidak ditandatangani	Ya	Pengidentifikasi pengguna yang tidak berulang terikat secara kriptografis ke semua kunci yang terkait dengan autentikasi perangkat. Untuk detailnya, lihat Penjaga Gerbang .
ID Pengautentikasi (ASID)	Integer tak bertanda 64-bit dalam urutan jaringan	TIDAK	Pengidentifikasi yang digunakan untuk mengikat kebijakan pengautentikasi tertentu. Semua pengautentikasi memiliki nilai ASID masing-masing yang dapat diubah sesuai kebutuhannya.
Tipe pengautentikasi	Integer tak bertanda tangan 32-bit dalam urutan jaringan	Ya	0x00 adalah Penjaga Gerbang. 0x01 adalah Sidik Jari.
Stempel waktu	Integer tak bertanda 64-bit dalam urutan jaringan	Ya	Waktu (dalam milidetik) sejak booting sistem terkini.
AuthToken HMAC (SHA-256)	gumpalan 256-bit	Ya	Mengetik SHA-256 MAC dari semua bidang kecuali bidang HMAC.

Alur booting perangkat

Pada setiap booting perangkat, kunci HMAC AuthToken harus dibuat dan dibagikan dengan semua komponen TEE (Gatekeeper, Keymaster, dan trustlet biometrik yang didukung). Jadi, untuk perlindungan tambahan terhadap serangan replay, kunci HMAC harus dibuat secara acak setiap kali perangkat di-boot ulang.

Protokol untuk berbagi kunci HMAC ini dengan semua komponen merupakan fitur implementasi yang bergantung pada platform. Kuncinya tidak boleh tersedia di luar TEE. Jika TEE OS tidak memiliki mekanisme komunikasi antarproses internal (IPC) dan perlu mentransfer data melalui OS yang tidak tepercaya, transfer harus dilakukan melalui protokol pertukaran kunci yang aman.

Sistem operasi Trusty , yang berjalan di samping Android, adalah contoh TEE, namun TEE lain dapat digunakan sebagai gantinya. Trusty menggunakan sistem IPC internal untuk berkomunikasi langsung antara Keymaster dan Gatekeeper atau trustlet biometrik yang sesuai. Kunci HMAC hanya disimpan di Keymaster; Sidik Jari dan Penjaga Gerbang meminta kunci dari Keymaster untuk setiap penggunaan dan tidak menyimpan atau menyimpan nilainya dalam cache.

Karena beberapa TEE tidak memiliki infrastruktur IPC, tidak ada komunikasi yang terjadi antar applet di TEE. Hal ini juga memungkinkan layanan keystore dengan cepat menolak permintaan yang pasti gagal karena memiliki pengetahuan tentang tabel otentikasi dalam sistem, sehingga menghemat IPC yang berpotensi mahal ke dalam TEE.