גמישות קריפטוגרפית היא היכולת להעביר פרוטוקול מחבילה קריפטוגרפית אחת לאחרת בלי לאבד חוזה אבטחה ברור. בהודעות, המשמעות היא יותר מהוספת שם של אלגוריתם חדש. לקוחות ישנים, נמענים שאינם מחוברים, הודעות שמורות ומכשירים מקושרים חייבים כולם להתנהג באופן צפוי במהלך המעבר.
מסמך RFC 7696 של IETF מתאר גמישות אלגוריתמית כבעיית מעבר הכוללת מזהים, מימושים ושינוי תפעולי. מספר גרסה מסייע לזהות מה נמצא בשימוש; הוא אינו הופך את המעבר לבטוח בפני עצמו.
שלוש גרסאות שקל לבלבל ביניהן
ליישום הודעות יכולות להיות גרסת יישום, גרסת פרוטוקול תעבורה ומזהה חבילה קריפטוגרפית. הן עונות על שאלות שונות:
| מזהה | מה הוא אומר לבודק | מה הוא אינו מוכיח |
|---|---|---|
| מהדורת יישום | איזו בנייה של התוכנה מותקנת | שכל שיחה משתמשת בפרוטוקול החדש ביותר |
| גרסת פרוטוקול | אילו פורמט הודעות וכללי מצב חלים | שהמימוש פועל נכון לפי הכללים האלה |
| מזהה אלגוריתם או חבילה | אילו רכיבים קריפטוגרפיים נבחרו | שלא ניתן לכפות הורדת רמה במשא ומתן |
הערות הגרסה צריכות להבהיר את הקשר במפורש. האמירה ״הושקה הצפנה חדשה״ עמומה אם רק שיחות שנוצרו לאחרונה משתמשות בה, או אם לקוח מקושר ישן יותר גורם לחזרה למצב קודם.
מה מעבר בטוח חייב להגדיר
התחילו בתרחיש מוחשי: אליס מעדכנת היום; בוב נשאר לא מחובר בטלפון ישן יותר. אליס שולחת הודעה ובהמשך מוסיפה מכשיר שני. מה כל מכשיר צריך לקבל, לשמור ולהציג?
תכנון שניתן לבדיקה עונה לפחות על השאלות האלה:
- כיצד כל צד לומד אילו גרסאות הצד השני תומך בהן?
- האם הגרסה שנבחרה מאומתת כחלק מהסשן?
- מה קורה כשאין גרסה משותפת מקובלת?
- האם ממסר זדוני יכול להסיר מידע על יכולת ולגרום למצב חלש יותר?
- האם הודעות ישנות עדיין ניתנות לקריאה, ואילו מפתחות ישנים עדיין נחוצים?
- האם שחזור גיבוי מחזיר מצב פרוטוקול מיושן?
- מתי אלגוריתמים שהוצאו משימוש מומלץ יושבתו, במקום רק להמליץ שלא להשתמש בהם?
כשל גלוי לרוב בטוח יותר ממעבר שקט למצב שהמשתמש לא התכוון אליו. אך יש לתעד את ההתנהגות המדויקת בעת כשל והתאוששות, כדי שאנשים לא יעקפו אותה באמצעות מעבר לערוץ לא מוגן.
מטריצת בדיקות מעשית לשדרוג
שדרוג אבטחה דורש יותר מצ׳אט מוצלח בין שתי התקנות חדשות. בדקו את המקרים האלה באמצעות נתונים שאינם רגישים:
| בדיקה | ראיות שיש לתעד |
|---|---|
| לקוח חדש מול לקוח ישן | הפרוטוקול שנבחר או תוצאה ברורה של חוסר תאימות |
| הנמען אינו מחובר בזמן השדרוג | התנהגות המסירה והפענוח לאחר ההתחברות מחדש |
| מכשיר מקושר ישן חוזר | האם הוא יכול לקרוא, לשלוח או לכפות מצב לא צפוי |
| קבוצה מוסיפה חבר לא תואם | מדיניות קבוצה מפורשת ומצב גלוי למשתמש |
| גיבוי משוחזר לאחר הוצאה משימוש | האם מצב שאינו נתמך נדחה או מועבר למצב חדש |
| מטא־נתוני גרסה שונו בזדון | כשל באימות במקום הורדת רמה שלא הורגשה |
אלה קריטריונים להערכה, לא טענות שמוצר מסוים עבר את הבדיקות. שמרו מזהי בנייה ותוצאות שנצפו כדי שניתן יהיה להבחין בהמשך בין נסיגה בתפקוד לבין שינוי בתיעוד.
כיצד לקרוא את שמות הפרוטוקולים של Livara
Livara מציינת את LVR1 לצ׳אטים ישירים ואת LGS1 לקבוצות פרטיות בתיעוד האבטחה שלה. השמות האלה מבחינים בין תחומי אחריות; אין לראות בהם הוכחה לתקינה או לביקורת בלתי תלויות. העמוד דן גם בהתנהגות של לקוחות או קבוצות שאינם יכולים לעמוד בתנאים המקדימים של המצב המוצפן.
הראיות השימושיות הבאות יהיו מפרט בעל גרסאות, וקטורי בדיקה, כללי תאימות ותוצאות סקירה המקושרים למהדורה מסוימת. Proof Lab מבהירה במפורש שהיקף ההדגמה שלה מצומצם יותר. הפעלת פרימיטיבים בדפדפן אינה זהה לבדיקה של כל מסלול מעבר ביישום.
מה משתמשים צריכים לעשות במהלך שדרוג הצפנה
הקפידו לעדכן לקוחות נתמכים, קראו הודעות אבטחה על תאימות מכשירים ושימו לב לשינויים במחווני זהות או מצב הצפנה. אל תניחו שסמל יישום חדש פירושו שכל קבוצה וגיבוי ישנים קיבלו הגנה חדשה. אם המוצר אינו יכול להסביר על אילו נתונים השתנתה ההגנה, שאלו לפני שיתוף חומר רגיש.
גמישות קריפטוגרפית טובה הופכת שינוי לניתן לבדיקה. היא מזהה מה השתנה, כיצד הצדדים מסכימים עליו, מה עלול להשתבש ומתי המנגנון הישן מפסיק להתקבל.
