Android מגן על נתוני משתמשים, כולל אחסון מוצפן של פרטי כניסה ומפתחות Keystore שקשורים לאימות, באמצעות גורמי ידע לפתיחת מסך הנעילה (LSKF) שהמשתמש מגדיר, כמו קודי אימות, קודי פתיחת נעילה וסיסמאות. מפתחות LSKF הם בדרך כלל ערכים עם אנטרופיה נמוכה, כמו קודי אימות בני 4 או 6 ספרות, ולכן נדרשת הגנה מפני התקפות כוח ברוטלי.
Android משתמש במגבילי קצב של סביבת מחשוב אמינה (TEE) או של רכיב מאובטח (SE) כדי להאט את התהליך, ואם יש מספיק ניסיונות, לחסום תוקפים שמבצעים התקפות כוח ברוטלי על LSKF. ב-CDD 9.11 מפורטות דרישות האבטחה המינימליות וההמלצות לגבי מגבילי קצב של LSKF. ב-Android 16 QPR2 ואילך מיושמת מדיניות חזקה יותר של הגבלת קצב הבקשות בהשוואה לגרסאות Android ישנות יותר. פרטים נוספים מופיעים במאמר בנושא מדיניות ברירת מחדל חזקה יותר להגבלת קצב הבקשות ב-Android 16 QPR2 ואילך.
ב-Android 17 ואילך, הגבלת הקצב של מסך הנעילה חזקה יותר מאשר בגרסאות קודמות. במקרים נדירים, המשתמשים עלולים להיתקל בפרקי זמן ארוכים מדי של חוסר פעילות במסך הנעילה, ולכן ב-Android 17 ואילך יש משוב משופר למשתמשים במסך הנעילה.
- פורמט זמן משופר: מסך הנעילה מציג פסק זמן של דקה אחת או יותר באמצעות יחידות זמן גדולות יותר כדי לשפר את הקריאות, למשל אפשר לנסות שוב בעוד 30 דקות במקום אפשר לנסות שוב בעוד 1,800 שניות.
- קישור מקוצר לשחזור: במסך הנעילה מוצג קישור מקוצר
(ברירת המחדל היא g.co/android/unlock) כדי לעזור למשתמשים למצוא
אפשרויות שחזור במכשיר אחר. אפשר להגדיר את הקישור הזה דרך המשאב
config_lockscreenLockoutShortlink. - משוב על ניסיון כפול: במכשירים עם הטמעה של Weaver, המערכת מציגה הודעה ייחודית כשמוזן ניסיון כפול שגוי. המשוב הספציפי הזה לא זמין במכשירים עם Gatekeeper בלבד, כי הם לא מספקים קודי תגובה נפרדים לניחושים שגויים ולכשלים אחרים באימות.
- ניהול עקבי של הזנת פרטי כניסה: מסך הנעילה משבית את לוח המקשים להזנת קוד האימות אם המכשיר משתמש בפרטי כניסה של קוד אימות, בדומה להזנת פרטי כניסה של סיסמה וקו ביטול נעילה.
השם של ה-method LockPatternUtils#getLockoutAttemptDeadline(int) שונה ל-LockPatternUtils#getLockoutEndTime(int), והיא מספקת את שעת הסיום של הנעילה ממטמון שמנוהל על ידי המערכת. העדכון הזה פותר בעיה שבה הם נשמרו במטמון רק לכל מופע של LockPatternUtils, ולכן לא הוצג פסק זמן פעיל אם הופעל ממופע אחר. מפתחים של הנחיות למתן פרטי כניסה למערכת, כמו מסך הנעילה ופעילויות ההגדרות, צריכים לעדכן אותן כדי לאמת את פסק הזמן הקיים לפני שמאפשרים ניסיונות נוספים.
ביטול הנעילה של נתוני משתמשים מוגנים באמצעות LSKF
LockSettingsService
מנהל את האחסון והאימות של מפתחות LSKF. לכל משתמש יכול להיות רק מפתח LSKF פעיל אחד בכל זמן נתון. הקצאה של LSKF חדש מבטלת את התוקף של הקודם ומתחילה את מדיניות הגבלת הקצב מההתחלה.
אחד ממנגנוני הגבלת הקצב הראשיים ב-TEE או ב-SE, Gatekeeper או Weaver, אוכף הגבלת קצב עבור LSKF פעיל. LockSettingsService מעדיף את Weaver כשהטמעה זמינה.
נעילת נתוני המשתמש המוגנים מוסרת רק כשמספקים את מפתח ה-LSKF הנכון למגביל הקצב הראשי. אם ה-LSKF שגוי, מגביל הקצב מגדיל את מונה הכשלים ומחיל פסק זמן אחרי מספר מסוים של כשלים. במהלך פסק זמן, המערכת דוחה את כל הניסיונות ומספקת את פסק הזמן שנותר.
מדיניות חזקה יותר של הגבלת קצב ברירת המחדל ב-Android 16 QPR2 ומעלה
ב-CDD 9.11 נדרש הגבלת קצב (rate-limiting) של LSKF ב-Android מגרסה 6 ואילך. בעבר, מדיניות הגבלת הקצב הנדרשת הייתה די מקלה. לדוגמה, הטמעה שעומדת בדרישות המינימליות של Android 16 מאפשרת עד 10 ניסיונות ניחוש בדקה הראשונה, 20 ניסיונות ב-6 דקות, 50 ניסיונות ב-25 דקות, 110 ניסיונות ב-24 שעות ו-1, 800 ניסיונות ב-5 שנים.
המדיניות הזו מאובטחת למדי עבור מפתחות LSKF שנבחרו באופן אקראי ואחיד, אבל בפועל המשתמשים לא בוחרים מפתחות LSKF באופן אקראי ואחיד. חלק מהמילים הנפוצות לחיפוש מופיעות בתדירות גבוהה בהרבה מאחרות. תוקפים יכולים להשיג שיעור הצלחה גבוה על ידי ניסיון של LSKF בסדר יורד של התדירות.
לדוגמה, במחקר This PIN Can Be Easily Guessed נמצא ששיעור ההצלחה בניסיון לנחש קודי אימות מהעולם האמיתי הוא 16.2% אחרי 100 ניסיונות ניחוש, ו-35.5% לגבי תבניות. אם התוקפים יודעים פרטים ספציפיים על המשתמשים, כמו תאריכי לידה, הם יכולים להשיג שיעורי הצלחה גבוהים עוד יותר.
לכן, ב-Android 16 QPR2 ואילך יש מדיניות חזקה יותר של הגבלת קצב ברירת מחדל של LSKF. המדיניות הזו מאפשרת עד 6 ניסיונות ניחוש בדקה הראשונה, 7 ניסיונות ב-6 דקות, 8 ניסיונות ב-25 דקות, 12 ניסיונות ב-24 שעות ו-19 ניסיונות ב-5 שנים. אחרי 20 ניסיונות ניחוש שגויים, לא ניתן לנחש יותר. בטבלה הבאה מוצג לוח הזמנים המלא של פסק הזמן. הדבר עשוי להשתנות בגרסאות עתידיות של Android.
| מספר הניחושים השגויים | פסק זמן אחרי ניחוש שגוי |
|---|---|
| 0 | לא רלוונטי |
| 1-4 | 0 שניות |
| 5 | דקה אחת |
| 6 | 5 דקות |
| 7 | 15 דקות |
| 8 | 30 דקות |
| 9 | 90 דקות |
| 10 | 4 שעות |
| 11 | 12 שעות |
| 12 | 24 שעות |
| 13 | 4 ימים |
| 14 | 13 ימים |
| 15 | 41 ימים |
| 16 | 123 ימים |
| 17 | שנה אחת |
| 18 | 3 שנים |
| 19 | 9 שנים |
| מעל 20 | אין יותר ניחושים |
עדכון של הגבלת קצב של יצירת בקשות
Android 16 QPR2 ואילך כולל הטמעות מעודכנות של Gatekeeper ו-Weaver שמחילות את מדיניות הגבלת הקצב שמופיעה בטבלה.
הגבלת קצב של יצירת בקשות בתוכנה
Android 16 QPR2 ואילך כולל מגביל קצב משני אופציונלי, SoftwareRateLimiter.. הוא מיושם בשרת המערכת ומאפשר למכשירים להציע מדיניות חזקה יותר של הגבלת קצב, אם אי אפשר לעדכן את TEE או SE.
מגדירים את SoftwareRateLimiter במצב אכיפה באמצעות ערך ההגדרה config_softwareLskfRateLimiterEnforcing. במצב אכיפה, SoftwareRateLimiter מחיל את מדיניות הגבלת הקצב שלו במקביל למגביל הקצב הראשי. לכל מספר ניסיונות ניחוש שגויים, הזמן הקצוב לתפוגה הוא הארוך מבין הזמן שנדרש על ידי מגביל הקצב הראשי והזמן שנדרש על ידי SoftwareRateLimiter.
במצב לא מחייב, SoftwareRateLimiter מעביר את כל בקשות האימות למגביל הקצב הראשי בלי להחיל מדיניות משנית להגבלת קצב.
זיהוי ניחושים כפולים
כדי לשפר את נוחות השימוש ולאפשר שימוש במדיניות חזקה יותר של הגבלת קצב, Android 16 QPR2 ומעלה תומך בזיהוי ניסיונות כפולים של ניחוש סיסמה. כשההגדרה הזו מופעלת, המשתמשים לא נענשים על הזנת אותו מפתח LSKF שגוי כמה פעמים.
לפעמים משתמשים לגיטימיים מזינים את אותו מפתח LSKF שגוי כמה פעמים. אם כל ניסיון נספר כניחוש נפרד, יכול להיות שיהיו יותר מדי ניסיונות כושלים. תוקפים מיומנים לא ינסו לבצע LSKF מסוים יותר מפעם אחת. מדיניות שלא סופרת ניסיונות ניחוש כפולים משפרת את השימושיות של הזנת מפתחות LSKF למשתמשים לגיטימיים, בלי להקל על תוקפים מיומנים לנחש את מפתחות ה-LSKF, וכך מאפשרת לאכוף מדיניות חזקה יותר של הגבלת קצב. למשתמשים לגיטימיים יש סיכוי נמוך יותר להיתקל בפסק זמן, כי הם צריכים להזין 5 ניחושים שגויים ייחודיים במקום 5 ניחושים שגויים כולל כפילויות.
במכשירים עם Android 16 QPR2 ומעלה, הטמעה של Weaver ו-SoftwareRateLimiter
שמוגדר במצב אכיפה, ניחושים כפולים מזוהים ונפסלים לפני שהם מועברים ל-Weaver. דחיות כאלה לא מגדילות את מספר הניחושים השגויים. המערכת עוקבת אחרי עד 5 ניחושים שגויים ייחודיים בזיכרון. אם מכשיר המעקב מלא, המיקום הכי ישן נמחק כדי לפנות מקום. כל הניסיונות המעקב נמחקים 5 דקות אחרי הניסיון השגוי האחרון שלא נכלל במעקב.
Gatekeeper לא מבדיל בין ניחושים שגויים לבין כשלים אחרים באימות, ולכן SoftwareRateLimiterלא תומך בזיהוי ניחושים כפולים כש-Gatekeeper הוא מגביל הקצב הראשי.
מטמיעי Weaver יכולים לבחור לתמוך בזיהוי של ניחושים כפולים בהטמעה של Weaver.