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 מחייב הגבלת קצב של 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 | 36 שעות |
| 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.