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

Autentikasi

Android menggunakan konsep kunci kriptografi dengan gerbang otentikasi pengguna yang membutuhkan komponen berikut:

  • Penyimpanan kunci kriptografi dan penyedia layanan. Menyimpan kunci kriptografi dan menyediakan rutin 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 Trusted Execution Environment (TEE) atau Secure Element (SE), seperti Strongbox.
  • Pengautentikasi pengguna. Buktikan keberadaan 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 ini mengomunikasikan status autentikasinya dengan layanan keystore melalui saluran yang diautentikasi. (Sistem Android Keystore di tingkat framework juga didukung oleh layanan keystore.)

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

Pendaftaran

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

Seorang 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, memungkinkan pengguna untuk tetap mengakses kunci setelah mengubah kredensial. Jika pengguna tidak menunjukkan kredensial yang ada, kredensial baru didaftarkan dengan SID Pengguna 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 tidak tepercaya, sehingga sebagian besar pengguna tidak akan pernah melihat fungsi ini. Namun, penyetelan ulang sandi secara paksa, baik oleh administrator perangkat atau penyerang, dapat menyebabkan hal ini terjadi.

Autentikasi

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

Alur otentikasi
Gambar 1. Alur otentikasi
  1. 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 yang 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 sesuai, seperti FingerprintManager atau FaceManager . Terlepas dari versinya, otentikasi biometrik terjadi secara tidak bersamaan setelah permintaan dikirim.
  2. 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 otentikasi 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 kejadian sidik jari dan mengirimkan data ke Sidik Jari 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.
  3. Daemon menerima AuthToken yang ditandatangani dan meneruskannya ke layanan keystore melalui ekstensi ke antarmuka Binder layanan keystore. ( gatekeeperd juga memberi tahu layanan keystore saat perangkat terkunci kembali dan saat sandi perangkat berubah.)
  4. Layanan keystore meneruskan AuthTokens ke Keymaster dan memverifikasinya menggunakan kunci yang dibagikan dengan Gatekeeper dan komponen TEE biometrik yang didukung. Keymaster mempercayai stempel waktu dalam token sebagai waktu autentikasi terakhir dan mendasarkan keputusan rilis kunci (untuk mengizinkan aplikasi menggunakan kunci) pada stempel waktu.

Format AuthToken

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

Bidang Tipe Yg dibutuhkan Deskripsi
Versi AuthToken 1 byte Iya Tag grup untuk semua bidang di bawah ini.
Tantangan Integer 64-bit unsigned Tidak Bilangan bulat acak untuk mencegah serangan replay. Biasanya ID 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 Integer 64-bit unsigned Iya Pengenal pengguna yang tidak berulang terikat secara kriptografis ke semua kunci yang terkait dengan otentikasi perangkat. Untuk detailnya, lihat Penjaga gerbang .
ID Authenticator (ASID) 64-bit unsigned integer dalam urutan jaringan Tidak Pengenal yang digunakan untuk mengikat ke kebijakan pengautentikasi tertentu. Semua pengautentikasi memiliki nilai ASID mereka sendiri yang dapat mereka ubah sesuai dengan kebutuhan mereka sendiri.
Jenis autentikator Integer 32-bit unsigned dalam urutan jaringan Iya
  • 0x00 adalah Penjaga Gerbang.
  • 0x01 adalah Sidik Jari.
Stempel waktu 64-bit unsigned integer dalam urutan jaringan Iya Waktu (dalam milidetik) sejak boot sistem terbaru.
AuthToken HMAC (SHA-256) Gumpalan 256-bit Iya MAC SHA-256 yang dikunci dari semua bidang kecuali bidang HMAC.

Alur 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 melakukan 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 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, tetapi TEE lain dapat digunakan sebagai gantinya. Trusty menggunakan sistem IPC internal untuk berkomunikasi secara langsung antara Keymaster dan Gatekeeper atau perwalian biometrik yang sesuai. Kunci HMAC disimpan hanya di Keymaster; Fingerprint dan Gatekeeper meminta kunci dari Keymaster untuk setiap penggunaan dan tidak menyimpan atau menyimpan nilai dalam cache.

Karena beberapa TEE tidak memiliki infrastruktur IPC, tidak ada komunikasi yang terjadi antar 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, menyimpan IPC yang berpotensi mahal ke dalam TEE.