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