הגבלת קצב של יצירת בקשות

‫Android מגן על נתוני משתמשים, כולל אחסון מוצפן של פרטי כניסה ומפתחות Keystore שקשורים לאימות, באמצעות גורמי ידע לביטול נעילת המסך (LSKF) שהוגדרו על ידי המשתמש, כמו קודי אימות, קודי פתיחת נעילה וסיסמאות. מפתחות LSKF הם בדרך כלל ערכים עם אנטרופיה נמוכה, כמו קודי אימות בני 4 או 6 ספרות, ולכן נדרשת הגנה מפני התקפות כוח ברוטלי.

מערכת Android משתמשת במגבילי קצב של סביבת מחשוב אמינה (TEE) או של רכיב מאובטח (SE) כדי להאט את התהליך, ואם התוקפים ינסו מספיק פעמים, היא תחסום אותם ותמנע מהם לבצע התקפות כוח ברוטלי על LSKF. CDD 9.11 מפרט את דרישות האבטחה המינימליות ואת ההמלצות לגבי מגבילי קצב של LSKF. ב-Android 16 QPR2 ואילך מיושמת מדיניות חזקה יותר משמעותית להגבלת קצב הבקשות בהשוואה לגרסאות Android ישנות יותר. פרטים נוספים זמינים במאמר בנושא מדיניות חזקה יותר להגבלת קצב ברירת המחדל ב-Android 16 QPR2 ואילך.

ביטול הנעילה של נתוני משתמשים מוגנים באמצעות 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) מופיעות בתדירות גבוהה בהרבה מאחרות. תוקפים יכולים להשיג שיעור הצלחה משמעותי על ידי ניסיון של 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.