Pembatasan kapasitas

Android melindungi data pengguna, termasuk penyimpanan yang dienkripsi dengan kredensial dan kunci Keystore yang terikat dengan autentikasi dengan faktor pengetahuan layar kunci (LSKF) yang dikonfigurasi pengguna seperti PIN, pola, dan sandi. LSKF biasanya merupakan nilai entropi rendah seperti PIN 4 atau 6 digit, sehingga diperlukan perlindungan dari serangan brute force.

Android menggunakan pembatas kecepatan Trusted Execution Environment (TEE) atau Secure Element (SE) untuk memperlambat, dan jika upaya yang dilakukan cukup banyak, memblokir penyerang yang melakukan serangan brute force pada LSKF. CDD 9.11 menentukan persyaratan dan rekomendasi keamanan minimum untuk pembatas kecepatan LSKF. Android 16 QPR2 dan yang lebih tinggi menerapkan kebijakan pembatasan frekuensi yang jauh lebih kuat daripada versi Android yang lebih rendah. Untuk mengetahui detail selengkapnya, lihat Kebijakan pembatasan kapasitas default yang lebih kuat di Android 16 QPR2 dan yang lebih baru.

Android 17 dan yang lebih tinggi menggunakan pembatasan kecepatan layar kunci default yang lebih kuat daripada versi yang lebih rendah. Pengguna dapat mengalami waktu tunggu layar kunci yang lama dalam kasus yang jarang terjadi, sehingga Android 17 dan yang lebih tinggi memberikan masukan pengguna yang ditingkatkan berikut di layar kunci.

  • Peningkatan format waktu: Layar kunci menampilkan waktu tunggu yang berlangsung selama satu menit atau lebih menggunakan unit waktu yang lebih besar agar lebih mudah dibaca, seperti Coba lagi dalam 30 menit, bukan Coba lagi dalam 1.800 detik.
  • Link pendek pemulihan: Layar kunci menampilkan link pendek (secara default g.co/android/unlock) untuk membantu pengguna menemukan opsi pemulihan di perangkat lain. Link ini dapat dikonfigurasi melalui resource config_lockscreenLockoutShortlink.
  • Masukan percobaan duplikat: Di perangkat dengan penerapan Weaver, sistem menampilkan pesan unik saat tebakan salah duplikat dimasukkan. Masukan khusus ini tidak tersedia di perangkat khusus Gatekeeper karena perangkat tersebut tidak memberikan kode respons terpisah untuk tebakan yang salah dan kegagalan verifikasi lainnya.
  • Pengelolaan entri kredensial yang konsisten: Layar kunci menonaktifkan tombol entri PIN jika perangkat menggunakan kredensial PIN, mirip dengan entri kredensial sandi dan pola.

Metode LockPatternUtils#getLockoutAttemptDeadline(int) diganti namanya menjadi LockPatternUtils#getLockoutEndTime(int) dan memberikan waktu berakhir penguncian dari cache yang dikelola sistem. Update ini menyelesaikan masalah saat waktu tunggu di-cache hanya per instance LockPatternUtils, yang secara keliru tidak menampilkan waktu tunggu aktif jika dipicu menggunakan instance lain. Developer perintah kredensial sistem seperti aktivitas layar kunci dan setelan harus mengupdatenya untuk memverifikasi waktu tunggu yang ada sebelum mengizinkan upaya lebih lanjut.

Membuka kunci data pengguna yang dilindungi dengan LSKF

LockSettingsService mengelola penyimpanan dan verifikasi LSKF. Pengguna hanya memiliki satu LSKF aktif dalam satu waktu. Menetapkan LSKF baru akan membatalkan LSKF sebelumnya dan memulai kebijakan pembatasan kecepatan dari awal.

Pembatasan frekuensi utama di TEE atau SE, salah satunya Gatekeeper atau Weaver, menerapkan pembatasan frekuensi untuk LSKF aktif. LockSettingsService lebih memilih Weaver jika implementasi tersedia.

Data pengguna yang dilindungi hanya dapat dibuka kuncinya jika LSKF yang benar diberikan ke pembatas frekuensi utama. Jika LSKF salah, pembatas kecepatan akan menambah penghitung kegagalan dan menerapkan waktu tunggu setelah jumlah kegagalan tertentu. Selama waktu tunggu, aplikasi akan menolak semua tebakan dan memberikan waktu tunggu yang tersisa.

Kebijakan pembatasan kapasitas default yang lebih kuat di Android 16 QPR2 dan yang lebih tinggi

CDD 9.11 mewajibkan pembatasan frekuensi LSKF di Android 6 dan yang lebih tinggi. Secara historis, kebijakan pembatasan frekuensi yang diperlukan cukup longgar. Misalnya, implementasi yang memenuhi persyaratan minimum Android 16 memungkinkan hingga 10 tebakan dalam satu menit pertama, 20 tebakan dalam 6 menit, 50 tebakan dalam 25 menit, 110 tebakan dalam 24 jam, dan 1.800 tebakan dalam 5 tahun.

Meskipun kebijakan ini cukup aman untuk LSKF yang dipilih secara acak dan seragam, dalam praktiknya pengguna tidak memilih LSKF secara acak dan seragam. Beberapa LSKF terjadi jauh lebih sering daripada yang lain. Penyerang dapat mencapai tingkat keberhasilan yang signifikan dengan mencoba LSKF dalam urutan frekuensi yang menurun.

Misalnya, studi PIN Ini Dapat dengan Mudah Ditebak menemukan tingkat keberhasilan 16,2% untuk menebak PIN dunia nyata setelah 100 kali menebak dan 35,5% untuk pola. Penyerang yang mengetahui informasi spesifik pengguna seperti tanggal lahir dapat mencapai tingkat keberhasilan yang lebih tinggi.

Oleh karena itu, Android 16 QPR2 dan yang lebih baru menyediakan kebijakan pembatasan frekuensi LSKF default yang lebih kuat. Kebijakan ini mengizinkan hingga 6 tebakan dalam satu menit pertama, 7 tebakan dalam 6 menit, 8 tebakan dalam 25 menit, 12 tebakan dalam 24 jam, dan 19 tebakan dalam 5 tahun. Tidak ada lagi tebakan yang diizinkan setelah 20 tebakan salah. Jadwal waktu tunggu lengkap ditampilkan dalam tabel berikut. Hal ini dapat berubah di versi Android mendatang.

Jumlah tebakan salah Waktu tunggu habis setelah tebakan salah
0 Tidak berlaku
1-4 0 detik
5 1 menit
6 5 menit
7 15 menit
8 30 menit
9 90 menit
10 4 jam
11 12 jam
12 36 jam
13 4 hari
14 13 hari
15 41 hari
16 123 hari
17 1 tahun
18 3 tahun
19 9 tahun
20+ Tidak ada lagi tebakan yang diizinkan

Pembatasan kapasitas yang diperbarui

Android 16 QPR2 dan yang lebih tinggi menyertakan implementasi Gatekeeper dan Weaver yang diperbarui yang menerapkan kebijakan pembatasan kecepatan dalam tabel.

Pembatasan frekuensi software

Android 16 QPR2 dan yang lebih tinggi menyertakan pembatasan kecepatan sekunder opsional, SoftwareRateLimiter. Pembatasan ini diterapkan di server sistem dan memungkinkan perangkat menawarkan kebijakan pembatasan kecepatan yang lebih kuat saat TEE atau SE tidak dapat diupdate.

Konfigurasi SoftwareRateLimiter dalam mode penerapan melalui nilai konfigurasi config_softwareLskfRateLimiterEnforcing. Dalam mode penerapan, SoftwareRateLimiter menerapkan kebijakan pembatasan frekuensinya secara bersamaan dengan pembatas frekuensi utama. Untuk jumlah tebakan salah tertentu, waktu tunggu adalah waktu yang lebih lama yang diperlukan oleh pembatasan frekuensi utama dan yang diperlukan oleh SoftwareRateLimiter. Dalam mode tidak menerapkan, SoftwareRateLimiter meneruskan semua permintaan verifikasi ke pembatas kecepatan utama tanpa menerapkan kebijakan pembatasan kecepatan sekunder.

Deteksi tebakan duplikat

Untuk meningkatkan kegunaan dan memungkinkan penggunaan kebijakan pembatasan frekuensi yang lebih kuat, Android 16 QPR2 dan yang lebih tinggi mendukung deteksi tebakan duplikat. Jika diaktifkan, pengguna tidak akan dikenai sanksi karena memasukkan LSKF yang salah beberapa kali.

Pengguna yang sah terkadang salah memasukkan LSKF yang sama dan salah beberapa kali. Hal ini menyebabkan waktu tunggu yang tidak perlu jika dihitung sebagai beberapa tebakan. Penyerang yang kompeten tidak akan mencoba LSKF tertentu lebih dari sekali. Kebijakan yang tidak menghitung tebakan duplikat meningkatkan kegunaan entri LSKF bagi pengguna yang sah tanpa mempermudah penyerang yang kompeten menebak LSKF, sehingga memungkinkan kebijakan pembatasan frekuensi yang lebih kuat diterapkan. Pengguna yang sah cenderung tidak mengalami waktu tunggu, karena pengguna harus memasukkan 5 tebakan salah yang unik, bukan 5 tebakan salah termasuk duplikat.

Di perangkat dengan Android 16 QPR2 dan yang lebih tinggi, implementasi Weaver, dan SoftwareRateLimiter dikonfigurasi dalam mode penerapan, tebakan duplikat akan terdeteksi dan ditolak sebelum diteruskan ke Weaver. Penolakan tersebut tidak menambah jumlah tebakan yang salah. Hingga 5 tebakan salah yang unik dilacak dalam memori. Jika pelacak penuh, pelacak yang paling lama akan dihapus untuk memberi ruang. Semua tebakan yang dilacak akan dibuang 5 menit setelah tebakan salah terakhir yang tidak dilacak dibuat.

Gatekeeper tidak memisahkan tebakan yang salah dari kegagalan verifikasi lainnya, sehingga SoftwareRateLimiter tidak mendukung deteksi tebakan duplikat saat Gatekeeper menjadi pembatas kecepatan utama.

Penerap Weaver dapat memilih untuk mendukung deteksi tebakan duplikat dalam penerapan Weaver.