Google Cloud Key Vault Service

אנחנו מתארים שירות בענן שמשתמש בחומרה מאובטחת לאחסון מפתחות קריפטוגרפיים, כך שהגישה אליהם מוגנת על ידי גורם ידע בעל אנטרופי נמוך (למשל, מספר PIN למסך הנעילה). החומרה המאובטחת נועדה למנוע התקפות כוח גולמי, על ידי כך שהמפתחות הקריפטוגרפיים המאוחסנים לא ניתנים לאחזור באופן סופי אחרי יותר מדי ניסיונות כושלים לספק את גורם הידע הנכון.

מחבר: Shabsi Walfish
תאריך גרסת: 6 במרץ 2018

הערה: המסמך הזה עדיין בתהליך פיתוח, ופרטי ההטמעה עדיין נמצאים בשלבי גיבוש. ככל שהמערכת תתייצב ואפשר יהיה ליצור מסמכי עזרה נוספים, נעדכן את המאמר הזה במידע מפורט יותר (במיוחד בשילוב עם גרסאות רלוונטיות של קוד פתוח).

סקירה כללית

באופן מסורתי, הצפנה (שמשמשת להבטחת פרטיות הנתונים) דורשת שימוש בסודות שיש להם אנטרופי גבוה מנקודת המבט של התוקף. אנטרופי גבוה נדרש כי סכמת ההצפנה צריכה לעמוד בהתקפות כוח גולמי שמחפשות את כל הסודות האפשריים עד שמוצאים את הסוד הנכון. בהתאם לזמינות של כוח המחשוב כיום, דרישת האנטרופיה המינימלית הסבירה לשמירת סודות קריפטוגרפיים עשויה להיות בין 70 ל-80 ביט. לצערנו, בני אדם מתקשים מאוד לזכור סיסמאות או סודות אחרים עם כמות אנטרופי כזו, ולזכור אותם בצורה מהימנה¹, במיוחד אם משתמשים בהם לעיתים רחוקות (אבל שימוש תכוף בסיסמה עם אנטרופי גבוה קשה ומייגע). כך נוצרת בעיה מאתגרת: איך אפשר להגן על נתונים פרטיים באמצעות טכנולוגיית הצפנה, אם רוצים שהסוד יהיה 'גורם ידע' שיש סיכוי גבוה שהמשתמש יזכור? מסיבות שונות, קשה מאוד לפתור את הבעיה הזו, ולכן בדרך כלל שירותי אחסון בענן מצפינים נתונים רק באמצעות סודות שמנוהלים על ידי ספק האחסון בענן עצמו, במקום להסתמך על המשתמש שיזכור את הסוד שלו.

אחת מהגישות לגשר על הפער בין הדרישות לסודות קריפטוגרפיים לבין סודות שאנשים יכולים לזכור היא להשתמש בשירות Cloud Key Vault ‏(CKV) כדי לאחסן 'מפתח שחזור' עם אנטרופיה גבוהה, שמוגן על ידי סוד עם אנטרופיה נמוכה שאנשים יכולים לזכור. שירות CKV ישחרר את מפתח השחזור רק לצד שיוכיח שהוא יודע את הסוד האנושי הנכון לזיכרון. שירות CKV יכול למנוע התקפות כוח brute על הסוד שקל לזכור, על ידי אכיפת מגבלה מוחלטת על מספר הניסיונות הכושלים להוכחת הידע של הסוד. מפתח השחזור עצמו הוא מפתח קריפטוגרפיה סימטרי רגיל, שמתאים לשימוש עם סכימה (מאומתת) להצפנה שיכולה להצפין בקלות כמות גדולה של נתונים (כמו גיבוי בדיסק) שאפשר לאחסן בבטחה בכל מקום – נתונים מוצפנים כאלה הם חסרי תועלת לכל מי שלא יכול לקבל את מפתח השחזור.

במאמר הזה מתוארת הגישה שלנו ליצירת שירות Cloud Key Vault באמצעות מודולים של חומרה מהימנה (THM). ההטמעה הראשונה של שירות CKV נועדה להגן על מפתחות השחזור באמצעות גורם הידע של נעילת המסך (LSKF) של המשתמש – קוד האימות, הסיסמה או קו ביטול הנעילה הסודיים שמשמשים לביטול הנעילה של הסמארטפונים. בני אדם יכולים לזכור את ה-LSKF שלהם בצורה מהימנה. עם זאת, בדרך כלל הסודות האלה של LSKF מכילים מספיק אנטרופיה כדי לעמוד בהתקפה של תוקף עם מספר ניסיונות מוגבל מאוד, ולכן הם מתאימים לשירות CKV.

היישום הראשון של שירות Cloud Key Vault יהיה הפעלת גיבויים של Android מוצפנים מצד הלקוח. בעבר, קבצים מוצפנים באופן מקומי במכשיר Android השתמשו במפתח שמוגן באמצעות LSKF של המשתמש, אבל הגיבויים של הקבצים האלה ששמורים (ומאובטחים) ב-Cloud לא היו מוגנים על ידי ה-LSKF. בפעם הראשונה, Cloud Key Vault מאפשר הגנה על נעילת המסך גם לגיבויים של Android שמאוחסנים בענן. המשמעות היא שלשרתים של Google אין אפשרות לגשת לתוכן של הגיבויים המוצפנים או לשחזר אותו – רק מכשיר עם ה-LSKF של המשתמש יכול לפענח את הגיבויים.

מושגי ליבה

בשלב הראשון, פלטפורמת הלקוח היחידה שנתמכת בשירות Cloud Key Vault היא מערכת ההפעלה Android 9 Pie. כשאנחנו מתייחסים ללקוח במאמר הזה, אנחנו מתכוונים למכשיר שפועלת בו מערכת ההפעלה Android 9 Pie עם Google Play Services. ההטמעה בצד השרת פועלת בשרתים ייעודיים של Google עם צ'יפ Titan נוסף². צ'יפ Titan ש-Google תכננה משמש כרכיב החומרה במודול החומרה המהימנה שלנו, ואנחנו מקצים לו באופן מיוחד את מנהל האתחול ואת הקושחה בהתאמה אישית שמטמיעים את הפרוטוקולים ואת מנגנוני אכיפת האבטחה שלנו (כפי שמתואר כאן). אנחנו משתמשים בשיטות אימות חומרה כדי לוודא שהפרוטוקול שלנו פועל באמת בחומרה של Titan.

שירות CKV צריך להתאים את עצמו כדי לטפל בתנועה ממיליארדי³ מכשירי Android, בלי לאבד כמות משמעותית של נתוני משתמשים כתוצאה מכשלים בחומרה (למשל, צ'יפים שנשרפו) או בלי להיחשף להפסקות זמניות ממושכות בשירות בגלל תחזוקה של מרכז הנתונים. לכן, השרתים עם צ'יפים של Titan מאורגנים בקבוצות, כאשר כל קבוצה מורכבת מכמה THM עצמאיים, שכל אחד מהם מכיל עותק של אותו חומר מפתח. קבוצה נתונה של משתמשים תופץ במרכזי נתונים פיזיים שונים באזורי תחזוקה שונים, כדי להבטיח שהמערכת תוכל לעמוד ביעדים של הזמינות והאמינות שלה. כדי לשפר את יכולת ההתאמה לעומס, הלקוחות יתחלקו למספר קבוצות שונות, כך שנוכל לשנות את הקיבולת של השירות פשוט על ידי הוספת עוד שרתים כדי להגדיל את מספר הקבוצות הזמינות.

עכשיו אנחנו מוכנים לפרט את הרכיבים העיקריים של ארכיטקטורת השירות של Cloud Key Vault.

רכיבים ארכיטקטוניים / מילון מונחים

גורם ידע של מסך הנעילה (LSKF): סוד שקל לזכור, כמו קוד אימות קצר, קו ביטול נעילה באמצעות החלקה על רשת של 3 x 3 נקודות או סיסמה. הסוד הזה משמש להגנה על היכולת לבטל את נעילת המכשיר באופן מקומי, והוא נחשב לגורם אימות ראשי (או 'חזק') של נעילת המסך המקומית של המכשיר של המשתמש.

לקוח: מכשיר של משתמש קצה שבו פועלות מערכת ההפעלה Android 9 Pie ו-Google Play Services, או תוכנה נתמכת מקבילית.

Android Framework: אנחנו משתמשים במונח הזה (או פשוט ב-Framework) כדי להתייחס לממשקי ה-API ב-Android 9 Pie ואילך, והוא לא מיועד להתייחס לגרסאות קודמות.

Google Play Services: אוסף של שירותים ואפליקציות שפועלים במכשיר של משתמש הקצה ומאפשרים לו לפעול עם מערכת החשבונות של Google וממשקי API מותאמים אישית של שרתים.

Recovery Agent: אפליקציית מערכת שפועלת כחלק מ-Google Play Services במרחב המשתמש במכשיר Android 9 Pie (או דומה). סוכני השחזור אחראים להריץ את הצד הלקוח של הפרוטוקולים השונים, ולבצע אינטראקציה עם מערכת ההפעלה של Android לפי הצורך כדי ליצור הודעות פרוטוקול שכוללות את LSKF.

הצהרת שחזור: כשהמשתמש רוצה לאחזר את מפתח השחזור, הוא צריך ליצור הצהרת שחזור, שמכילה עותק מוצפן של LSKF שהמשתמש טוען שהוא יודע. בדרך כלל, המשתמש יתבקש להזין את LSKF של המכשיר הישן במכשיר חדש שמנסה לגשת למפתח השחזור של המכשיר הישן.

מפתח שחזור: מפתח סודי קריפטוגרפי שמוגן על ידי שירות Cloud Key Vault, ומשמש להצפנת (ואימות) נתונים במכשיר הלקוח. אחרי שמפתח השחזור מועבר ל-Vault (ראו בהמשך), אפשר למחוק את העותק המקומי ברגע שהלקוח מסיים להשתמש בו להצפנת נתונים.

שירות Cloud Key Vault‏ (CKV): שירות אינטרנט שמאפשר למכשירי לקוח לאחסן מפתחות קריפטוגרפיים שמוגנים על ידי LSKF שקל לזכור.

קבוצה בעלת מאפיינים משותפים: אוסף של שרתי Vault או מכונות THM שיכולים לשמש כעותקים מיותרים זה של זה.

מפתח ציבורי של קבוצה בעלת מאפיינים משותפים: המפתח הציבורי מזוג מפתחות שנוצר על ידי קבוצה ספציפית של THM. המפתח הפרטי התואם זמין רק בתוך ה-THMs שהיו בקבוצה בזמן יצירת המפתח.

Trusted Hardware Module‏ (THM): מודול אבטחה ייעודי (מיקרו-בקר) שנועד לספק סביבת מחשוב מינימלית ואמינה. לפחות, האלמנט המאובטח צריך להיות מסוגל ליצור או לאחסן מפתחות סודיים, ולשמור מצב מתפתח לא נדיף (כדי למנוע התקפות שכוללות איפוס למצב קודם).

Vault: רשומה ספציפית במסד הנתונים של שירות CKV, שמכילה מפתח שחזור מוגן LSKF של מכשיר יחיד. יכול להיות שלמשתמש קצה יהיו כמה מאגרים בחשבון, כל אחד מהם מתאים למכשיר או ל-LSKF שונים. רק ה-THM בשרת Vault יכול לבדוק או לחלץ את התוכן של Vault.

שרת Vault: מכונה למטרות כלליות שפועלת במרכז נתונים של Google, שעברה התאמה מיוחדת להוספת מודול חומרה מהימן (THM).

תכנון פרוטוקול

פרוטוקול CKV מורכב מכמה שלבים:

אתחול

כדי לאתחל את המערכת, Google תספק מפתח ציבורי ל-Root of Trust, שמערכת המסגרת תשתמש בו כדי לאמת את האימותים של החומרה של Google. מפתח החתימה של עץ האמון הזה מאוחסן אופליין ומאובטח בקפידה, כך שנדרשת מעורבות של כמה עובדים כדי לחתום באמצעותו. המפתח הציבורי של בסיס האמון הזה מוטמע במערכת ההפעלה של Android, וניתן לשנות אותו רק באמצעות עדכון של מערכת ההפעלה.

Google גם מפרסמת מדי פעם רשימה של מפתחות ציבוריים לכל קבוצה של THM, יחד עם אימות של הרשימה. האימות ברשימה מתבצע באמצעות חתימה שמקשרת חזרה ל-root of trust. כל עדכון של הרשימה שפורסמה מכיל גם מספר סידורי, כדי שאפשר יהיה למנוע החזרות למצב קודם. סוכן השחזור יאתר את הרשימה האחרונה שפורסמה של מפתחות ציבוריים של קבוצות בעלות מאפיינים משותפים, וימסור אותה למסגרת. לאחר מכן, המסגרת מאמתת את האימות ובוחרת באופן אקראי מפתח ציבורי של קבוצה בעלת מאפיינים משותפים מהרשימה לשימוש בשלב יצירת הכספת.

יצירת Vault

אחרי שעוזר ל-Framework להשלים את האינטליקציה על ידי אחזור רשימת המפתחות הציבוריים של קבוצת המשתמשים, סוכני השחזור יבקשו מה-Framework ליצור Vault חדש. בפעם הבאה שהמשתמש יבצע הזנה של LSKF, ה-Framework ייצור מפתח שחזור חדש ויצפין אותו קודם עם מפתח שמבוסס על גיבוב של LSKF, ולאחר מכן עם המפתח הציבורי של הקבוצה שנבחר על ידי ה-Framework במהלך האינטליקציה. ה-blob המוצפן שנוצר הוא Vault, שמוחזר על ידי Framework אל Recovery Agent, שמעלה אותו לשירות CKV של Google.

פתיחת Vault

כשRecovery Agent במכשיר החדש צריך לקבל גישה לRecovery Key ששמור בVault מסוים, הוא קודם מופיע עם בקשה למשתמש להזין את LSKF של המכשיר המקורי שיצר את ה-Vault. לאחר מכן, Recovery Agent יבקש מה-Framework ליצור Recovery Claim באמצעות ה-LSKF הזה. ה-Framework ייצור מפתח חדש של מגיש התלונה, ויצפין את מפתח המגיש ואת הגיבוב של מפתח ה-LSKF שהוצהר באמצעות אותו מפתח ציבורי של קבוצה שבו Vault הוצפן במקור. ה-blob המוצפן שנוצר נקרא Recovery Claim, וה-Framework מעביר אותו ל-Recovery Agent, שמציג אותו לשירות CKV.

ה-CKV מפנה את Recovery Claim (ואת Vault התואם) לשרתי Vault שנכללים בקבוצה הנכונה. לאחר מכן, ה-THM בשרתי Vault מפענח את הצהרת השחזור ומנסה לחלץ את מפתח השחזור מ-Vault המקורי באמצעות גיבוב ה-LSKF שצוין (כדי להפיק את מפתח ההצפנה הפנימי). אם הגיבוב המקורי של LSKF והגיבוב של LSKF שצוין בתלונה תואמים, ה-THM יאחזר את מפתח השחזור מהמאגר ויצפין אותו מחדש באמצעות מפתח המבקש שהופיע בתלונה על שחזור. אם לא, ה-THM יעלה את המונה של ניסיונות כושלים. אחרי שמונה המספר של הניסיונות הכושלים את המגבלה, ה-THM יסרב לעבד בקשות שחזור נוספות לאותו Vault.

בסיום, אם הכל התנהל כשורה, מפתח השחזור (שמוצפן עכשיו באמצעות מפתח המבקש) יישלח חזרה משרת Vault עד ל-Framework. המערכת משתמשת בעותק שלה של מפתח המבקש כדי לפענח את מפתח השחזור, והפרוטוקול הושלם.

אמצעי אבטחה

המטרה של מערכת Cloud Key Vault היא לספק הגנה לעומק, על ידי הכללת אמצעי אבטחה בכמה רמות בסטראק שלנו. כדי להבין איך ההגנות האלה פועלות, נתחיל בתיאור הלקוח ונמשיך למעלה בסטאק עד לשירות Cloud Key Vault.

אבטחת לקוח

בהתאם ליצרן המכשיר הספציפי ולמכשיר עצמו, גורם הידע של מסך הנעילה (LSKF) מאוחסן ומוגן במכשיר בדרך כלל באמצעות מגוון שיטות שונות בהתאם ליצרן המכשיר. לדוגמה, במכשירי Pixel 2 של Google נעשה שימוש במודול אבטחה לחומרה עמיד בפני פגיעה כדי לאחסן את LSKF במנוחה, ולאכוף מגבלות קצב מבוססות-חומרה על אימות LSKF. ממשקי ה-API החדשים של Framework, שמאפשרים להשתמש ב-Cloud Key Vault, נועדו לשמור על ההתחייבויות הקיימות לאבטחה ככל האפשר, גם אם המכשיר משתמש במודול אבטחה לחומרה כדי להגן על האחסון של LSKF.

בקטע הזה נתמקד בבעיות האבטחה ובאמצעי ההגנה הרלוונטיים שמשפיעים על התכונה החדשה של Cloud Key Vault, במקום לנסות לספק תמונה מלאה של כל מנגנוני האבטחה המשויכים ל-LSKF.

אבטחה של ממשקי ה-API של Framework

ממשקי ה-API החדשים של Framework שנוספו כדי לתמוך בשירות CKV מסומנים בתווית @SystemApi ודורשים הרשאות מיוחדות, כדי לוודא שהם זמינים רק לאפליקציות מערכת שאושרו על ידי יצרני ציוד מקורי (OEM), כמו Google Play Services. כך אפשר למנוע כמעט לחלוטין שטח התקפה ישיר שעלול להיות חשוף לאפליקציות שהמשתמשים מתקינים במכשיר.

ממשקי ה-API של Framework מבטיחים גם שיוצרים מאגרים רק למפתחות ציבוריים של קבוצות בעלות מאפיינים משותפים (cohort) שאומתו על ידי Root of Trust. ה-root of trust מוטמע במסגרת על ידי יצרן הציוד המקורי (OEM) בזמן המשלוח, ואי אפשר לשנות אותו בלי עדכון של מערכת ההפעלה. כך אפשר לוודא שה-LSKF משמש רק ליצירת Vaults שיאמיצו כראוי הגנות מבוססות-חומרה מפני כוח גולמי. כשמשתמשים ב-THMs בשירות Cloud Key Vault להגנה מפני כוח גולמי ל-LSKF, אפשר להשיג אבטחה דומה לזו שמתקבלת משימוש בחומרה מאובטחת במכשיר לאותו מטרה (כמו במכשירי Google Pixel 2).

מכיוון שאנחנו לא מניחים שה-LSKF יישמר באף מקום במכשיר מלבד בחומרה מאובטחת, אפשר ליצור Vault חדש רק מיד אחרי ביטול הנעילה של המכשיר. בזמן שהמשתמש מזין את LSKF כדי לבטל את הנעילה של המכשיר, ה-LSKF זמין ל-Framework לזמן קצר ב-RAM. זהו הרגע שבו ה-API החדש ליצירת Vault משתמש בו. אי אפשר ליצור Vault חדש שמוגן באמצעות LSKF בזמן שהמכשיר נעול, כי ה-LSKF לא זמין.

אבטחת סוכן השחזור

אמצעי ההגנה העיקרי שאנחנו מספקים ל-Recovery Agent הוא שהפרוטוקול תוכנן למנוע ממנו לראות את ה-LSKF של המכשיר הנוכחי או מפתחות שחזור כלשהם. רק Framework צריך לראות את הדברים האלה בצד הלקוח, כך שיהיה קשה יותר לנצל באגים פוטנציאליים או נקודות חולשה באבטחה של Recovery Agent. ה-Recovery Agent משמש בעיקר לניהול אירועים במחזור החיים ולהעברת נתונים הלוך ושוב בין הענן לבין המסגרת. היוצא מן הכלל היחיד הוא במהלך שחזור, ממש לפני פרוטוקול פתיחת הכספת, כאשר המשתמש צריך להזין את ה-LSKF של המכשיר הישן. ממשק המשתמש שאוסף את ה-LSKF של המכשיר הישן מוטמע ב-Recovery Agent‏⁴. עם זאת, ההטמעה של Recovery Agent "שוכחת" את ה-LSKF שצוין בבקשה ברגע שה-Framework מתחיל ליצור את בקשת השחזור.

תכונות האבטחה של הפרוטוקול

ניתוח מלא של הפרוטוקול חורג מהיקף המסמך הזה, אבל אנחנו רוצים להדגיש כמה מההגנות המובנות בפרוטוקול. באופן ספציפי, הפרוטוקול משתמש רק בגיבוב של LSKF לכל אורך הדרך. המשמעות היא שאם ל-LSKF יש אנטרופיה גבוהה (למשל, אם זו סיסמה טובה עם אנטרופיה גבוהה), אחסון Vault עדיף בהרבה על אחסון גיבוב של סיסמה, ובמקרה כזה גיבוב הסיסמה יכול לספק רמת אבטחה שאיננה תלויה באבטחה של THM. לכן אנחנו תומכים בגיבוב מתובל של LSKF עם 'זיכרון קשה' כחלק מהפרוטוקול. אנחנו גם מקשרים באופן קריפטוגרפי את Vault למזהה של המכשיר שיצר אותו, ומקשרים את הצהרת השחזור למזהה חד-פעמי (nonce) שמשמש כאתגר במהלך פרוטוקול פתיחת Vault, כדי לוודא שהצהרת השחזור עדכנית.

מכיוון שמפתח השחזור נוצר מחדש בכל יצירה של Vault, אנחנו מטמיעים רוטציה של מפתחות על ידי החלפת רשומה קיימת ב-Vault ב-Vault חדש שנוצר. הכתובת של מונה הניסיונות שנכשלו שבהם Vault משתמש נבחרת במהלך יצירת Vault, והמסגרת מבטיחה שכתובת המונה שבה Vault משתמש בכל Vault מאוחר יותר לא תשתנה, אלא אם LSKF השתנה או שיש רשימה חדשה מאומתת של מפתחות ציבוריים של קבוצות בעלות מאפיינים משותפים. כך אפשר לבצע רוטציה של מפתח השחזור בלי לפגוע בהגנה מפני כוח גולמי של LSKF.

אבטחת שרת לשירות Cloud Key Vault

השרת מיושם באמצעות שילוב של תוכנה שפועלת בחומרת שרת רגילה, וקושחה שפועלת בחומרה ייעודית (שבב Titan). נסביר על אמצעי ההגנה בכל שכבה.

אמצעי הגנה בחומרה

אמצעי האבטחה העיקרי שמוטמע בצד השרת של שירות CKV הוא מודולים של חומרה מהימנה (THMs), שנוצרים באמצעות צ'יפים מותאמים אישית של Titan ש-Google פיתחה. שבבים אלה פועלים עם קושחת שמציגה את ממשקי ה-API הנדרשים להטמעת פרוטוקולי CKV. במיוחד, הם יכולים ליצור זוג מפתחות ולשתף אותו באופן מאובטח עם חברים אחרים בקבוצה שלהם, כך שהלוגיקה של הקושחה מגינה על המפתח הפרטי מפני דליפת מידע מחוץ לצ'יפים של Titan בקבוצה. הם יכולים גם לבצע את הפעולה של פתיחת Vault ולנהל ספירה של ניסיונות כושלים ב-Vault (הספירה מתבצעת באופן קפדני, והיא מבוססת על מצב שנשמר בתוך צ'יפ Titan). תיאור מפורט יותר של הפרוטוקול שמופעל על ידי קושחת הצ'יפ של CKV Titan יסופק בגרסה עתידית של המסמך הזה.

מאחר שאבטחת השרת נובעת מהלוגיקה של הקושחה בצ'יפים של Titan, אנחנו צריכים לוודא שהלוגיקה לא משתנה באופן שמאפשר לצ'יפים לדלוף סודות או להתעלם ממגבלות המונה. כדי להשיג את המטרה הזו, אנחנו משנים גם את מנהל האתחול של Titan כדי לוודא שהנתונים השמורים של הצ'יפ (כמו המפתח הפרטי של הקבוצה בעלת המאפיינים המשותפים) נמחקים לחלוטין לפני שמחילים עדכון כלשהו. החיסרון של ההגנה הזו הוא שאנחנו לא יכולים לתקן באגים בקושחה בלי אובדן נתונים מסוים – עדכון הקושחה שווה ערך מבחינה פונקציונלית להרס החומרה הקיימת והחלפתה בשבבים חדשים. במקרה שנדרש תיקון קריטי לקושחה, Google תצטרך ליצור ולפרסם רשימה חדשה לגמרי של מפתחות ציבוריים מאומתים של קבוצות בעלות מאפיינים משותפים, ולהעביר בהדרגה את כל המשתמשים לרשימה החדשה. כדי לצמצם את הסיכון הזה, אנחנו מנסים לשמור על קוד הליבה של הקושחה מינימלי למדי, ובודקים אותו בקפידה כדי לאתר בעיות אבטחה פוטנציאליות.

אמצעי הגנה על תוכנות

בנוסף למגבלות הקשות על מספר הפעמים שאפשר לנסות לבצע פעולה ב-Vault, שה-THMs אוכפים, שירות CKV מטמיע גם הגבלת קצב מבוססת-תוכנה. הגבלת הקצב נועדה למנוע ממפיץ לא מורשה להיכנס לחשבון של משתמש ולצרוך במהירות את המכסה של ניסיונות שחזור שנכשלו, וכך למנוע מהמשתמש האמיתי לגשת למפתחות השחזור שלו. בדומה להשהיות הזמן שהמכשיר של המשתמש מטיל אחרי יותר מדי ניסיונות כושלים לביטול נעילת המסך, שירות CKV יאכוף השהיה הולכת וגדלה אחרי כל בקשה כושלת נוספת לפתיחת Vault.

אנחנו גם מטמיעים אמצעי אבטחה סטנדרטיים בשירותי Cloud שמארחים נתוני משתמשים, כולל בקרות גישה, ניטור וביקורת מחמירות.

מפרט פרוטוקול מפורט

המפרט המפורט של הפרוטוקול עדיין נמצא בתהליך, והמסמך הזה יתעדכן כך שיכלול את הפרטים האלה, יחד עם פרסום קוד הלקוח בפרויקט Android Open Source בהמשך השנה.

הערות

1. "Towards Reliable Storage of 56-bit Secrets in Human Memory | USENIX". 1 באוגוסט 2014,‏ https://www.usenix.org/node/184458.  ↩
2. "Google Cloud Platform Blog: Titan in depth: Security in plaintext" 24 באוגוסט 2017,‏ https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html.  ↩
3. "Google announces over 2 billion monthly active devices on Android ‎…" 17 במאי 2017, https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users.  ↩
4. כך אנחנו יכולים לספק ממשקי משתמש גמישים להזנת ה-LSKF של מכשיר אחר – יכול להיות שבמסגרת של המכשיר הנוכחי אין ממשק משתמש מתאים להזנת ה-LSKF של המכשיר הישן. ↩