ברירת המחדל להצפנה במנוחה

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

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

המאמר מיועד לאדריכלי אבטחה ולצוותי אבטחה שמשתמשים כרגע או שוקלים להשתמש במוצרים ובשירותים של Google. הנחת המוצא במסמך הזה היא שיש לכם הבנה בסיסית בהצפנה ובפרימיטיבים קריפטוגרפיים. למידע נוסף על הצפנה, ראו Introduction to Modern Cryptography.

הצפנה במנוחה משמשת להגנה על נתונים שמאוחסנים בדיסק (כולל בכונני SSD) ובמדיה לגיבוי. כל הנתונים שמאוחסנים ב-Google מוצפנים בשכבת האחסון באמצעות אלגוריתם תקן ההצפנה המתקדם (AES) ‏AES-256. אנחנו משתמשים בספרייה הקריפטוגרפית המשותפת Tink, שכוללת את המודול המאומת FIPS 140-2 (שנקרא BoringCrypto) לצורך הטמעת ההצפנה ב-Google Cloud באופן עקבי.

אנחנו מנהלים את המפתחות שמשמשים להצפנת ברירת המחדל במנוחה. אם אתם משתמשים ב-Google Cloud, בעזרת Cloud Key Management Service תוכלו ליצור מפתחות הצפנה משלכם ובאמצעותם להוסיף לנתונים שלכם הצפנת מעטפת. באמצעות Cloud KMS אפשר ליצור מפתחות, להשתמש בהם בסבב, לעקוב אחריהם ולמחוק אותם. מידע נוסף זמין בניתוח המעמיק של Cloud Key Management Service.

איך הצפנה במנוחה עוזרת לאבטח נתונים

הצפנה במנוחה היא רק חלק מאסטרטגיית אבטחה רחבה יותר. להצפנה יש כמה יתרונות:

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

מהם נתוני לקוחות?

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

התוכן מורכב מנתונים שאתם יוצרים בעצמכם או מוסרים לנו, כמו נתונים שנשמרים ב-Cloud Storage, קובצי snapshot של דיסקים לשימוש ב-Compute Engine וכללי מדיניות של IAM. המאמר מתמקד בברירת המחדל להצפנה במנוחה של תוכן של לקוחות.

המטא-נתונים של הלקוחות מורכבים משאר הנתונים שלהם. לדוגמה, מספרי פרויקטים שנוצרו באופן אוטומטי, חותמות זמן, כתובות IP, הבייטים של אובייקטים ב-Cloud Storage או סוג המכונה ב-Compute Engine. המטא-נתונים מוגנים במידה סבירה שמאפשרת המשכיות של הביצועים והפעולות.

ברירת המחדל להצפנת נתונים במנוחה

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

שכבות הצפנה

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

בתרשים הבא מוצגות שכבות ההצפנה שמשמשות בדרך כלל להגנה על נתוני המשתמשים שמאוחסנים במרכזי הנתונים של Google בסביבות ייצור. כל נתוני המשתמשים עוברים הצפנה מבוזרת של מערכות קבצים או הצפנה של מסדי נתונים ואחסון קבצים. נוסף על כך מתבצעת הצפנה של מכשירי האחסון של כל הנתונים שמאוחסנים במרכזי הנתונים של Google בסביבות ייצור.

שכבות ההצפנה שלנו.

הצפנה בשכבות החומרה והתשתית

בכל מערכות האחסון של Google נעשה שימוש בארכיטקטורת הצפנה דומה, אך פרטי ההטמעה משתנים בהתאם למערכת. הנתונים מחולקים למקטעים של תתי-קבצים לצורך אחסון. המקטעים יכולים להיות בגודל של כמה ג'יגה-בייט. כל מקטע מוצפן ברמת האחסון באמצעות מפתח יחיד להצפנת נתונים (DEK): לשני מקטעים לא יהיה אותו DEK, גם אם הם בבעלות של אותו לקוח או מאוחסנים באותה מכונה (יכול להיות שמקטע נתונים שנמצא ב-Datastore, ב-App Engine וב-Pub/Sub יכיל נתונים של כמה לקוחות).

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

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

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

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

בתרשים הבא מתוארת ההעלאה של נתונים לתשתית שלנו וחלוקה שלהם למקטעים מוצפנים לצורך אחסון.

אופן ההעלאה של נתונים.

כדי להצפין נתונים במנוחה אנחנו משתמשים באלגוריתם של תקן הצפנה מתקדם (AES). כל הנתונים ברמת האחסון מוצפנים באמצעות מפתחות DEK שמשתמשים ב-AES-256 כברירת מחדל, מלבד מספר קטן של דיסקים של אחסון מתמיד (persistent disk) שנוצרו לפני 2015 ושמשתמשים ב-AES-128. השימוש ב-AES נפוץ כי המכון הלאומי לתקנים וטכנולוגיה (NIST) ממליץ גם על AES-256 וגם על AES-128 לאחסון לטווח ארוך, וגם כי לעיתים קרובות השימוש ב-AES נכלל בדרישות התאימות של לקוחות.

הצפנה בשכבת מכשיר האחסון

נוסף להצפנה ברמת מערכת האחסון, הנתונים מוצפנים ברמת מכשיר האחסון באמצעות AES-256 בדיסקים קשיחים (HDD) ובכונני SSD על ידי מפתח נפרד ברמת המכשיר (המפתח הזה שונה מהמפתח שמשמש להצפנת הנתונים ברמת האחסון). מספר קטן של דיסקים מסוג HDD מדור קודם משתמשים ב-AES-128. בכונני ה-SSD ש-Google משתמשת בהם, נתוני המשתמשים מוטמעים באמצעות AES-256 בלבד.

הצפנה של גיבויים

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

כמו כן, מערכת הגיבוי ממשיכה להצפין בנפרד את רוב קובצי הגיבוי באמצעות DEK משלה. ה-DEK נגזר ממפתח שמאוחסן ב-Keystore, והוא נוצר בזמן הגיבוי באופן אקראי לכל קובץ. ‏DEK אחר משמש לכל המטא-נתונים שבגיבויים, וגם הוא שמור ב-Keystore.

תאימות של נתונים במנוחה ל-FIPS

בסביבת הייצור שלה, Google משתמשת במודול הצפנה עם הסמכת FIPS 140-2 (אישור 4407).

ניהול מפתחות

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

מפתחות ה-KEK שמורים ב-Keystore באופן מרוכז. זהו מאגר שנוצר במיוחד לאחסון מפתחות. מספר קטן יותר של מפתחות KEK מאשר מפתחות DEK, ושימוש ב-Keystore מרוכז, מאפשרים לנו לשמור ולהצפין נתונים בהיקף גדול וגם לעקוב אחרי הגישה לנתונים מסוימים ולשלוט בה ממקום מרכזי.

ב-Google Cloud, ללקוחות יכולים להיות משאבים משותפים ומשאבים לא משותפים. דוגמה למשאב משותף: קובץ image בסיסי משותף ב-Compute Engine. במשאבים משותפים, לקוחות מרובים מפנים לעותק יחיד שהוצפן במפתח DEK יחיד. משאבים לא משותפים מחולקים למקטעי נתונים, והם מוצפנים באמצעות מפתחות נפרדים ממפתחות שמשמשים לקוחות אחרים. המפתחות האלה נפרדים גם ממפתחות שמגינים על חלקים אחרים של הנתונים שבבעלות אותו לקוח. הנתונים שמאוחסנים ב-Datastore, ב-App Engine וב-Pub/Sub הם יוצאי דופן, כי הנתונים של מספר לקוחות עשויים להיות מוצפנים באמצעות אותו DEK.

יצירה של מפתחות DEK

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

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

יצירה של מפתחות KEK

רוב מפתחות ה-KEK להצפנת מקטעי נתונים נוצרים ב-Keystore, והיתר נוצרים בתוך שירותי האחסון. כדי לשמור על עקביות, כל מפתחות ה-KEK נוצרים באמצעות הספרייה הקריפטוגרפית המשותפת של Google, תוך שימוש במחולל מספרים אקראי (RNG) ש-Google פיתחה. ה-RNG מבוסס על תקן NIST 800-90Ar1 CTR-DRBG, והוא יוצר מפתח KEK מסוג AES-256‏ (בעבר, AES-128, וחלק מהמפתחות האלה עדיין פעילים לצורך פענוח הנתונים).

הוראות RDRAND של Intel וה-RNG של ליבת Linux הם המקור של ה-RNG. מקור ה-RNG של ליבת Linux מגיע ממספר מקורות אנטרופיה עצמאיים, כולל RDRAND ואירועים אנטרופיים ממסביבת מרכז הנתונים (למשל מדידות מדוקדקות של סרגלי דיסקים (disk seeks) וזמני הגעה בין חבילות).

מפתחות ה-DEK נארזים במפתחות KEK באמצעות AES-256 או AES-128, בהתאם לשירות Google Cloud. אנחנו עובדים כרגע על שדרוג כל מפתחות ה-KEK של שירותי Google Cloud ל-AES-256.

ניהול KEK

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

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

השימוש ב-KEK מנוהל ב-Keystore באמצעות רשימות ACL לכל מפתח, לפי המדיניות של כל מפתח. רק משתמשים ושירותים מורשים של Google יכולים לגשת למפתח. מתבצע מעקב אחרי השימוש בכל מפתח ברמת הפעולה הבודדת שדורשת את המפתח הזה, ולכן מתבצע רישום ביומן ואימות של כל משתמש בכל שימוש שלו במפתח. כחלק ממדיניות האבטחה והפרטיות הכללית של Google, נבדקת כל גישה של משתמשים לנתונים.

תהליך הגישה למקטעי נתונים מוצפנים

כששירות של Google ניגש למקטע נתונים מוצפן:

  1. השירות שולח למערכת האחסון קריאה לקבלת הנתונים הדרושים לו.
  2. מערכת האחסון מזהה את המקטעים שבהם מאוחסנים הנתונים (מזהי המקטעים) ואת המקום שבו הם שמורים.
  3. לכל מקטע, מערכת האחסון שולפת את ה-DEK הארוז שמאוחסן עם אותו מקטע (יש מקרים שבהם השירות מבצע את הפעולה הזו) ושולחת אותו ל-Keystore כדי לפתוח את האריזה.
  4. מערכת האחסון מאמתת שלמשימה שצוינה יש הרשאה לגשת למקטע הנתונים על סמך מזהה משימה ושימוש במזהה המקטע. מערכת Keystore מאמתת שהשירות מורשה להשתמש ב-KEK שמשויך לשירות ולפתוח את האריזה של ה-DEK הספציפי.
  5. מערכת Keystore מבצעת אחת מהפעולות האלה:
    • מחזירה את ה-DEK שהאריזה שלו נפתחה למערכת האחסון, שמפענחת את מקטע הנתונים ומעבירה אותו לשירות.
    • במקרים נדירים, מעבירה לשירות את ה-DEK שהאריזה שלו נפתחה. מערכת האחסון מעבירה את מקטע הנתונים המוצפן לשירות, שמפענח אותו ומשתמש בו.

התהליך הזה שונה במכשירי אחסון ייעודיים, כמו כונני SSD מקומיים, שבהם המכשיר מנהל את ה-DEK ברמת המכשיר ומגן עליו.

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

תהליך הצפנה של מקטעי נתונים.

היררכיית מפתחות הצפנה ו-Root of Trust

ה-Keystore מוגן באמצעות מפתח Root שנקרא מפתח המאסטר של מאגר המפתחות, שמשמש לאריזה של כל KEK ב-Keystore. מפתח המאסטר של מאגר המפתחות הוא מסוג AES-256, והוא עצמו מאוחסן בשירות אחר לניהול מפתחות (KMS) שנקרא Root Keystore (בעבר, מפתח המאסטר של מאגר המפתחות היה מסוג AES-128, וחלק מהמפתחות האלו עדיין פעילים לצורך פענוח הנתונים). ב-Root Keystore נשמר מספר מפתחות נמוך בהרבה, בערך 12 מפתחות לאזור. להגברת האבטחה, Root Keystore לא פועל במכונות כלליות בסביבת הייצור, אלא רק במכונות ייעודיות בכל מרכז נתונים של Google.

ל-Root Keystore עצמו יש מפתח root משלו שנקרא מפתח המאסטר של מאגר המפתחות. גם המפתח הזה הוא מסוג AES-256. הוא מאוחסן בתשתית מקצה לקצה (P2P) שנקראת מפיץ מפתח המאסטר של Root Keystore, והתשתית יוצרת רפליקות של המפתחות האלה באופן גלובלי (בעבר, מפתח root מאסטר של מאגר המפתחות היה מסוג AES-128, וחלק מהמפתחות האלו עדיין פעילים לצורך פענוח הנתונים). מפיץ מפתח המאסטר של Root Keystore שומר את המפתחות ב-RAM רק באותן מכונות ייעודיות כמו Root Keystore, והוא משתמש ברישומים ביומן כדי לאמת שימוש ראוי בהם. מכונה אחת של מפיץ מפתח root מאסטר של מאגר המפתחות פועלת לכל מכונה של Root Keystore.

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

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

בתרשים הבא מוצגת ההיררכיה של מפתחות ההצפנה. היררכיית מפתחות ההצפנה מגינה על מקטעי נתונים באמצעות DEK, שארוז ב-KEK ב-Keystore, שמוגן באמצעות Root Keystore והמפיץ של מפתח root מאסטר של מאגר המפתחות.

ההיררכיה של מפתחות ההצפנה.

סיכום של ניהול מפתחות

סיכום של ניהול מפתחות ב-Google:

  • הנתונים מחולקים למקטעים ומוצפנים באמצעות DEK.
  • מפתחות ה-DEK מוצפנים באמצעות מפתחות KEK.
  • מפתחות ה-KEK מאוחסנים ב-Keystore.
  • ‏Keystore פועל בכמה מכונות במרכזי נתונים ברחבי העולם.
  • מפתחות מ-Keystore נארזים באמצעות מפתח מאסטר של מאגר המפתחות, שנשמר ב-Root Keystore.
  • ‏Root Keystore קטן בהרבה מ-Keystore, ופועל רק במכונות ייעודיות בכל מרכז נתונים.
  • מפתחות Root Keystore נארזים באמצעות מפתח root מאסטר של מאגר המפתחות, שנשמר במפיץ של מפתח root מאסטר של Root Keystore.
  • המפיץ של מפתח root מאסטר של Root Keystore הוא תשתית מקצה לקצה (P2P) שפועלת בו-זמנית ב-RAM במכונות ייעודיות ברחבי העולם. כל מכונה מקבלת את חומר המפתח שלה ממכונות אחרות שפועלות באזור.
  • אם כל המכונות של המפיץ באזור מסוים מושבתות, מפתח מאסטר מאוחסן בחומרה מאובטחת אחרת בכספות פיזיות במספר מוגבל של מיקומים ב-Google.

זמינות ברחבי העולם ויצירת רפליקות

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

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

‏Root Keystore פועל בכמה מכונות שמיועדות לפעולות אבטחה בכל מרכז נתונים. המפיץ של מפתח המאסטר של Root Keystore פועל במכונות האלה במקביל ל-Root Keystore. מפיץ מפתח המאסטר של Root Keystore מספק מנגנון הפצה באמצעות פרוטוקול gossiping במרווח זמן קבוע, כל מכונה של המפיץ בוחרת מכונה אקראית אחרת כדי להשוות מולה את המפתחות שלה ולגשר על ההבדלים בגרסאות של המפתחות. במודל הזה אין צומת מרכזי שכל התשתית שלנו תלויה בו. שיטת ההפצה הזו מאפשרת לנו לשמור חומרי מפתחות עם זמינות גבוהה ולהגן עליהם.

הספרייה הקריפטוגרפית המשותפת של Google

הספרייה הקריפטוגרפית המשותפת של Google נקראת Tink. משולב בה המודול המאומת FIPS 140-2 שנקרא BoringCrypto. ספריית Tink זמינה לכל מפתחי Google. המשמעות של שימוש עקבי בספרייה משותפת היא שרק צוות קטן של קריפטוגרפים צריך להטמיע את הקוד הזה, שנמצא בפיקוח קפדני ועובר בדיקות קפדניות, וכך אין צורך שכל הצוותים ב-Google יפתחו קריפטוגרפיה משלהם. צוות האבטחה המיוחד של Google אחראי על התחזוקה של הספרייה הקריפטוגרפית המשותפת בכל המוצרים.

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

נכון לעכשיו, אנחנו משתמשים באלגוריתמים הבאים להצפנה במנוחה למפתחות DEK ו-KEK. מאחר שאנחנו כל הזמן משפרים את היכולות ואת האבטחה שלנו, הם עשויים להשתנות.

פרימיטיב קריפטוגרפי פרוטוקולים מועדפים פרוטוקולים נתמכים אחרים
הצפנה סימטרית AES-GCM‏ (256 ביטים)
  • AES-CBC ו-AES-CTR‏ (128 ו-256 ביטים)
  • AES-EAX‏ (128 ו-256 ביטים)
חתימות סימטריות (בשימוש משולב עם AES-CBC ו-AES-CTR שצוינו למעלה למטרות אימות) HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

הספרייה כוללת פרוטוקולים קריפטוגרפיים אחרים שבעבר הייתה בהם תמיכה, אבל בטבלה הזו מפורטים הפרוטוקולים העיקריים ש-Google משתמשת בהם.

מחקר וחדשנות בתחום הקריפטוגרפיה

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

לדוגמה, במחקר קריפטוגרפי פוסט-קוונטי, אנחנו פועלים בתחומים האלה:

המאמרים הבאים