AES-GCM יכול להגן על סודיות הודעה ולזהות שינויים לא מורשים. כשלעצמו, הוא אינו אומר למקבל אם הודעה תקפה מבחינות אחרות כבר עובדה.
קל לבלבל בין שלוש דרישות: זוגות מפתח/nonce ייחודיים להצפנה, אימות ההודעה וההקשר שלה, וטיפול בשידור חוזר ברמת הפרוטוקול. HKDF יכול לסייע בגזירת מפתחות, אך אינו ממלא אוטומטית את כל שלוש הדרישות.
שימוש חוזר ב־nonce ושידור חוזר הם אירועים שונים
| אירוע | מה קורה | ההגנה הנדרשת |
|---|---|---|
| שימוש חוזר ב־nonce בעת הצפנה | טקסטים גלויים שונים מוצפנים באותו מפתח GCM ובאותו nonce | אסטרטגיה אמינה להקצאת מפתח/nonce |
| חבלה | הטקסט המוצפן או ההקשר המאומת משתנים | פענוח מאומת ודחייה במקרה כשל |
| שידור חוזר | הודעה מוצפנת שהייתה תקפה נמסרת שוב | מצב וכללי יישום שמזהים כפילויות או הודעות מיושנות |
| שינוי סדר | הודעות תקפות מגיעות בסדר אחר | סדר המוגדר בפרוטוקול וטיפול מוגבל בהודעות מחוץ לסדר |
טקסט מוצפן ששודר שוב עשוי עדיין לשאת תג אימות תקף. דבר לא השתנה. לכן לא נכון לומר שכל כפילות נכשלת אוטומטית באימות AES-GCM. RFC 5116 מפריד במפורש בין ממשק AEAD לבין שירותי הגנה משידור חוזר.
מדוע אסור לזוג המפתח וה־nonce לחזור על עצמו
ה־nonce של GCM אינו חייב להיות סודי, אך עליו לעמוד בדרישות הייחודיות של השיטה תחת מפתח נתון. nonce באורך 96 סיביות, או 12 בתים, הוא נפוץ; בחירת האורך הזה אינה מבטיחה יצירה נכונה.
שימוש באותו מפתח ובאותו nonce לטקסטים גלויים שונים עושה שימוש חוזר בזרם המפתח של ההצפנה, וחושף קשרים בין הטקסטים. הוא עלול גם לערער את האותנטיות ולאפשר זיוף. ההשפעה חמורה, אך אין לתאר אותה כחשיפה אוטומטית של כל מפתח ישן או של כל הודעה בחשבון. היקף הפגיעה תלוי במפתח שנעשה בו שימוש חוזר ובפרוטוקול.
NIST SP 800-38D מגדיר את GCM ואת דרישותיו. מימושים חייבים לציית למגבלות ההפעלה ולכללי יצירת nonce החלים עליהם, ולא לכלל אצבע פשטני של ״בטוח עד מספר כזה של הודעות״.
מה HKDF מוסיף
HKDF, המוגדר ב־RFC 5869, גוזר חומר מפתחות מחומר סודי בקלט באמצעות שלבי חילוץ והרחבה. פרוטוקולים יכולים להשתמש בתוויות הקשר ובקלטים נפרדים כדי להפריד בין מפתחות למטרות שונות.
HKDF דטרמיניסטי. אם לקוח שקרס או הוחזר למצב קודם חוזר על אותו מצב ואותם קלטים, הוא יכול לגזור שוב את אותו פלט. לכן הוספת HKDF לתכנון אינה הופכת שימוש חוזר ב־nonce לבלתי אפשרי.
מפתחות נפרדים לכל הודעה יכולים לצמצם את כמות התוכן המוגנת במפתח יחיד, אך קידום בטוח של המצב, הפרדת מפתחות ומחיקה עדיין חשובים. אותו ערך nonce תחת מפתחות שונים באמת אינו אותו כשל כמו חזרה על זוג מפתח/nonce; הפרוטוקול חייב לבסס שהמפתחות אכן שונים.
הגנה משידור חוזר שייכת לפרוטוקול
מקבל יכול לעקוב אחר מזהי הודעות, מיקומים ברצף, תקופות הפעלה או מפתחות ratchet שכבר נוצלו. השדות הרלוונטיים חייבים להיות מאומתים כדי שתוקף לא יוכל לתייג מחדש הודעה ישנה כחדשה.
לאחר מכן היישום חייב להחליט מה משמעותה של כפילות. הצגת בועת צ׳אט כפולה אינה נוחה; ביצוע אותה פעולה פעמיים עלול להיות חמור יותר. ניסיונות חוזרים ברשת הם רגילים, ולכן לעיתים קרובות נדרש עיבוד אידמפוטנטי לצד בדיקות קריפטוגרפיות.
אל תדרשו שכל הודעה תקפה תגיע בסדר קשיח, אלא אם הפרוטוקול מגדיר התנהגות כזו. לקוחות ניידים מתחברים מחדש, מנסים שוב ומקבלים הודעות שהתעכבו באופן שגרתי. טיפול בטוח מבחין בין הודעה לגיטימית שהגיעה באיחור לבין הודעה שכבר נוצלה או שייכת להקשר שגוי.
מה לבדוק לפני שטוענים לקיומה של הגנה
- הפעלה מחדש אחרי הקצאת nonce אך לפני תיעוד השליחה: האם ההקצאה יכולה לחזור על עצמה?
- שחזור תמונת מצב ישנה יותר: האם מפתחות, מונים או רישומי שידורים חוזרים עלולים לחזור לאחור?
- שליחה במקביל משני תהליכי עבודה או מכשירים: האם תחומי המפתח/nonce שלהם מופרדים?
- מסירת אותה הודעה תקפה פעמיים: האם פעולת היישום מבוצעת פעם אחת?
- שינוי מזהה הפעלה או כותרת: האם ההקשר קשור קריפטוגרפית?
- מסירת הודעות תקפות מחוץ לסדר: האם עיכובים נתמכים מטופלים בלי לקבל מצב מיושן?
ממשקי API לפענוח מאומת צריכים להחזיר טקסט גלוי ליישום רק לאחר אימות מוצלח. זו דרישת ממשק; אין זו טענה ששום מימוש לעולם אינו מחשב חוצץ זמני של טקסט גלוי באופן פנימי.
קריאה מדויקת של טענות Livara
תיעוד האבטחה של Livara מציין AES-256-GCM, שרשראות לכל הודעה והקשר LVR1/LGS1. אבני הבניין האלה אינן מוכיחות בפני עצמן התאוששות נכונה מקריסה, הקצאת nonce או דחיית שידורים חוזרים. טענות כאלה זקוקות לפרטי פרוטוקול מזוהי גרסה ולראיות מבדיקות.
תכנון חזק מקצה כל תפקיד במפורש: גזירת מפתחות יוצרת את המפתחות המיועדים, AEAD מאמת תוכן והקשר, והלוגיקה של הפרוטוקול השומרת מצב מחליטה אם הודעה תקפה קבילה כעת.
