נתונים מאומתים נוספים (AAD) הם מחרוזת שמעבירים ל-Cloud Key Management Service כחלק מבקשת הצפנה או פענוח. ה-AAD משמש כבדיקת תקינות ויכול לעזור בהגנה על הנתונים מפני התקפת סוכן מבולבל. המחרוזת AAD לא יכולה להיות גדולה מ-64KiB.
Cloud KMS לא יפענח טקסט מוצפן אלא אם נעשה שימוש באותו ערך AAD גם להצפנה וגם לפענוח.
נתוני ה-AAD קשורים לנתונים המוצפנים, כי אי אפשר לפענח את המידע המוצפן בלי לדעת את נתוני ה-AAD, אבל הם לא מאוחסנים כחלק מהמידע המוצפן. בנוסף, ה-AAD לא מגביר את העוצמה הקריפטוגרפית של הטקסט המוצפן. במקום זאת, זו בדיקה נוספת של Cloud KMS לאימות בקשת פענוח.
ב-Cloud KMS, AAD תמיד קיים כשמבצעים קריאה להצפנה או לפענוח. אם לא מספקים ערך ל-AAD, נעשה שימוש במחרוזת ריקה. אם משתמשים במחרוזת ריקה כ-AAD להצפנה של טקסט ללא הצפנה, רק מחרוזת ריקה תאפשר פענוח של הטקסט המוצפן.
יומני הביקורת של Cloud לא מתעדים את AAD.
מתי כדאי להשתמש ב-AAD
דוגמה לשימוש ב-AAD היא כשמשתמשים באפליקציה כפרוקסי לעטיפה/פרימה עם מפתח יחיד ומספר בלתי מוגבל של לקוחות, כאשר כל לקוח נמצא בגבולות אבטחה נפרדים. לדוגמה, האפליקציה יכולה להיות אפליקציית יומן שמאפשרת למשתמשים לנהל יומן פרטי. כשמשתמש צריך לצפות ברשומה פרטית ביומן, האפליקציה יכולה להשתמש בשם המשתמש הייחודי כ-AAD בבקשת הפתיחה (פענוח) כדי לאמת את המשתמש באופן מפורש. במקרה כזה, אפשר להשתמש במפתח יחיד כדי לשרת מספר משתמשים (לא מוגבל). היתרון העיקרי הוא שלא צריך לשמור את הסטטוס של כל משתמש בנפרד.
דוגמה נוספת היא אם האפליקציה שלכם צריכה להשתמש בטוקנים מסוג bearer שמכילים מידע פרטי, כמו כתובת אימייל. הקלט לאסימון ה-Bearer יהיה הנתונים המאומתים שמשמשים לאסימון ה-Bearer, בתוספת כתובת האימייל בטקסט פשוט. הנתונים האלה יוצפנו כך שאסימון ה-bearer שיוחלף יהיה בפורמט של נתונים מאומתים מוצפנים נוספים (AEAD).
דוגמה למתקפת סגן מבולבל
בדוגמה הזו אפשר לראות איך אפשר להערים על אפליקציה כדי שתפענח טקסט מוצפן מטעם משתמש זדוני. האפליקציה היא ה-confused deputy בדוגמה הזו, כי היא לא יודעת שהתוקף רימה אותה וגרם לה להשתמש בסמכות שלה לרעה. התוצאה היא שהתוקף יכול לראות נתונים מפוענחים שהיו מוצפנים במקור עבור משתמש אחר. שימו לב שבמתקפה הזו, התוקף לא צריך לדעת את מפתח ההצפנה, כי הוא מסתמך על ה-confused deputy כדי לבצע את הפענוח.
אפליקציית יומן מאפשרת למשתמשים לנהל יומן פרטי. כל רשומה ביומן מוצפנת, והיא מיועדת לפיענוח רק על ידי המשתמש שיצר אותה.
אליס יוצרת רשומה ביומן. האפליקציה מצפינה את הרשומה ביומן ואז מאחסנת אותה במיקום ששמור לרשומות ביומן ששייכות לאליס.
אליס שולחת בקשה לצפייה ביומן שלה. מכיוון שרשומה ביומן המוצפן נמצאת במיקום ששמור לעינת, האפליקציה מפענחת את הנתונים ומחזירה אותם כתשובה לבקשה של עינת. זו ההתנהגות המיועדת של האפליקציה.
מלאורי מעתיקה את הרשומה ביומן של אליס מהמיקום ששמור לאליס למיקום ששמור למלאורי.
מלאורי שולחת בקשה לצפייה בעותק של מלאורי של רשומה ביומן של אליס. מכיוון שהעותק של הרשומה ביומן של אליס נמצא במיקום ששמור למאלורי, האפליקציה מפענחת את הרשומה ביומן ומחזירה את הטקסט לא מוצפן כתגובה לבקשה של מאלורי. בשלב הזה, Mallory יכולה לראות את הרשומה ביומן של Alice, וזה לא אופן הפעולה הרצוי של האפליקציה.
כדי להתגונן מפני סוג כזה של מתקפה, האפליקציה יכולה להשתמש במחרוזת לא ריקה כ-AAD להצפנה ולפענוח. ה-AAD מספק בדיקה נוספת לבקשות פענוח. כשמלאורי שולחת בקשת פענוח כדי לראות את העותק של מלאורי של רשומה ביומן של אליס, הבקשה של מלאורי לא תצליח אלא אם מלאורי תצליח גם לגרום לאפליקציה להשתמש ב-AAD הנכון.
אחסון או שכפול של AAD
לפני שמצפינים באמצעות AAD, צריך להחליט אם לאחסן את ה-AAD לצד הנתונים המוצפנים, או לשחזר את ה-AAD לצורך פענוח בהמשך.
אחת הסיבות לאחסון נתוני AAD היא כדי שיהיה קל להשתמש בהם כשצריך לפענח טקסט מוצפן. לדוגמה, שורה במסד נתונים יכולה להכיל גם את המידע המוצפן (ciphertext) וגם את ה-AAD ששימש כשהטקסט הלא מוצפן הוצפן. כשמתקבלת בקשת פענוח, האפליקציה יכולה לאחזר את ה-AAD ואת הטקסט המוצפן ממסד הנתונים. לאחר מכן האפליקציה יכולה להשתמש ב-AAD לתהליך הפענוח של המידע המוצפן.
אחת הסיבות לשחזור של AAD היא אימות של נתונים לא פרטיים, תוך הימנעות מאחסון של AAD. לדוגמה, אם רוצים לוודא שנתיב הקובץ ושם הקובץ של קובץ מוצפן לא השתנו, אפשר לכלול את נתיב הקובץ ואת שם הקובץ כ-AAD כשמצפינים את הקובץ. לאחר מכן, כשנשלחת בקשת פענוח לקובץ, אפשר לשחזר את ה-AAD על ידי בדיקת נתיב הקובץ ושם הקובץ.
אחסון AAD
שמירת AAD פירושה ש-AAD נשמר ואז זמין בקלות לשימוש עתידי באפליקציה. לדוגמה, טבלת מסד נתונים יכולה להכיל עמודה של טקסט מוצפן ועמודה של נתוני אימות נוספים (AAD) ששימשו ליצירת הטקסט המוצפן. כשמגיע הזמן לפענח את המידע המוצפן, האפליקציה מאחזרת את ה-AAD ומשתמשת בו לפענוח.
נניח שיש אפליקציית יומן שנועדה להציג רשומה ביומן רק למשתמש שיצר אותה. כשיוצרים רשומה ביומן, היא מוצפנת ואז נשמרת במסד נתונים, בעמודה ENCRYPTED_DIARY_ENTRY. לכל בקשה לצפייה ברשומה ביומן, האפליקציה מאמתת את המשתמש ואז מספקת לו את הרשומה.
נניח שלא נעשה שימוש ב-AAD (מלבד מחרוזת ריקה שמוגדרת כברירת מחדל), ובהיפותזה, מאלורי הצליח להעתיק את נתוני ENCRYPTED_DIARY_ENTRY של אליס לנתוני ENCRYPTED_DIARY_ENTRY של מאלורי. כשמלכי שולחת בקשת פענוח לנתונים של מלכי ENCRYPTED_DIARY_ENTRY (שהועתקו מהנתונים של עינת), האפליקציה מבצעת את הפענוח בלי להבין שהיא הולכה שולל.
מלאורי יכול לראות את הרשומה ביומן של אליס כטקסט לא מוצפן.
נניח שכתובת האימייל של המשתמש משמשת כ-AAD כשמצפינים רשומה ביומן. כשדנה יוצרת רשומה ביומן, האפליקציה מאחסנת את כתובת האימייל שלה שלא מוצפנת בעמודה EMAIL, לצד הנתונים ENCRYPTED_DIARY_ENTRY. נניח שוב שמירי הצליחה להעתיק את הנתונים של אליס מ-ENCRYPTED_DIARY_ENTRY אל הנתונים של מירי ב-ENCRYPTED_DIARY_ENTRY.
כשמלאכי שולח בקשת פענוח, האפליקציה מאחזרת את כתובת האימייל של מלאכי מהעמודה EMAIL כדי להשתמש בה כ-AAD עבור בקשת הפענוח.
כתובת האימייל של מירי לא תצליח לשמש כ-AAD לצורך פענוח, ולכן האפליקציה לא מאפשרת למירי לראות את הרשומה ביומן של אליס כטקסט לא מוצפן.
שחזור של AAD
שחזור של AAD פירושו שהוא לא מאוחסן בשום מקום, אבל אפשר לשחזר אותו כשמגיע הזמן לפענוח.
לדוגמה, אפשר להשתמש בנתיב קובץ ובשם קובץ כ-AAD. במהלך תהליך ההצפנה, נניח שהקובץ המוצפן נשמר ב-MY_PATH\MY_FILE1.enc, ולכן "MY_PATH\MY_FILE1.enc" שימש כ-AAD. ה-AAD הזה לא מאוחסן. כשמתקבלת בקשת פענוח, האפליקציה יוצרת מחדש את ה-AAD על ידי בדיקת נתיב הקובץ ושם הקובץ שצריך לפענח. אם הקובץ המוצפן לא הועבר למיקום אחר, הערך "MY_PATH\MY_FILE1.enc" ישמש כ-AAD במהלך הפענוח, שהוא זהה ל-AAD ששימש במהלך ההצפנה, ולכן הפענוח יכול להתבצע.
אם הקובץ המוצפן הועבר, למשל אל SOME_OTHER_PATH\MY_FILE1.enc, אז "SOME_OTHER_PATH\MY_FILE1.enc" ישמש כ-AAD לפענוח. הערך הזה של AAD לא תואם לערך של AAD שמשמש להצפנה, ולכן הפענוח ייכשל.