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 kriptografis otentikasi 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 menyertakan Lingkungan Eksekusi Tepercaya (TEE) atau Elemen Aman (SE), seperti Strongbox.
Pengautentikasi pengguna. Buktikan kehadiran pengguna dan/atau autentikasi yang berhasil. Android mendukung Gatekeeper untuk otentikasi PIN/pola/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 di tingkat kerangka kerja juga didukung oleh layanan keystore.)

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

Pendaftaran

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

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

Dalam keadaan normal, kerangka kerja 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 otentikasi, yang dimulai saat pengguna memberikan PIN, pola, kata sandi, atau sidik jari. Semua komponen TEE berbagi kunci rahasia yang mereka gunakan untuk mengotentikasi pesan satu sama lain.

Gambar 1. Alur otentikasi

Seorang pengguna menyediakan metode otentikasi dan layanan terkait membuat permintaan ke daemon terkait.
- Untuk PIN, pola, atau kata sandi, LockSettingsService membuat permintaan ke gatekeeperd .
- Alur otentikasi berbasis biometrik bergantung pada versi Android. Pada perangkat yang menjalankan Android 8.x dan lebih rendah, FingerprintService membuat permintaan untuk 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, otentikasi biometrik terjadi secara asinkron setelah permintaan dikirim.
Daemon mengirimkan data ke mitranya, yang menghasilkan AuthToken:
- Untuk otentikasi PIN/pola/sandi, gatekeeperd mengirimkan PIN, pola, atau hash kata sandi ke Gatekeeper di TEE. Jika otentikasi di TEE berhasil, Gatekeeper di TEE mengirimkan AuthToken yang berisi SID pengguna yang sesuai (ditandatangani dengan kunci HMAC AuthToken) ke mitranya di OS Android.
- Untuk otentikasi sidik jari, fingerprintd mendengarkan kejadian sidik jari dan mengirimkan data ke Fingerprint di TEE. Jika otentikasi di TEE berhasil, Sidik Jari di TEE 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 pelepasan kunci (untuk mengizinkan aplikasi menggunakan kunci) pada stempel waktu.

format Token Otentikasi

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	Yg dibutuhkan	Keterangan
Versi AuthToken	1 byte	Ya	Tag grup untuk semua bidang di bawah ini.
Tantangan	Bilangan bulat 64-bit yang tidak ditandatangani	Tidak	Sebuah bilangan bulat acak untuk mencegah serangan replay. Biasanya ID dari operasi kripto yang diminta. Saat ini digunakan oleh otorisasi sidik jari transaksional. Jika ada, AuthToken hanya valid untuk operasi kripto yang mengandung tantangan yang sama.
ID Pengguna	Bilangan bulat 64-bit yang tidak ditandatangani	Ya	Pengenal pengguna yang tidak berulang terikat secara kriptografis ke semua kunci yang terkait dengan autentikasi perangkat. Untuk detailnya, lihat Penjaga Gerbang .
ID Authenticator (ASID)	64-bit unsigned integer dalam urutan jaringan	Tidak	Identifier yang digunakan untuk mengikat ke kebijakan authenticator tertentu. Semua autentikator memiliki nilai ASID mereka sendiri yang dapat mereka ubah sesuai dengan kebutuhan mereka sendiri.
Jenis autentikator	Integer tidak bertanda 32-bit dalam urutan jaringan	Ya	0x00 adalah Penjaga Gerbang. 0x01 adalah Sidik Jari.
stempel waktu	64-bit unsigned integer dalam urutan jaringan	Ya	Waktu (dalam milidetik) sejak boot sistem terbaru.
AuthToken HMAC (SHA-256)	gumpalan 256-bit	Ya	Mengetik SHA-256 MAC dari semua bidang kecuali bidang HMAC.

Aliran boot perangkat

Pada setiap boot 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 adalah fitur implementasi yang bergantung pada platform. Kunci tidak boleh tersedia di luar TEE. Jika TEE OS tidak memiliki mekanisme internal interprocess communication (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 sebelah Android, adalah contoh TEE, tetapi 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 disimpan hanya di Keymaster; Fingerprint dan Gatekeeper meminta kunci dari Keymaster untuk setiap penggunaan dan tidak menyimpan atau menyimpan nilainya.

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