השוו את העלות של פעולה מוגדרת ואת הראיות מול איום מוגדר — לא רק תרשים עץ מול תרשים מפתחות שולחים.
Messaging Layer Security (MLS) ו־LGS1 של Livara אינם שתי תעודות חלופיות לבטיחות של צ׳אט קבוצתי. MLS הוא תקן פרוטוקול של IETF; LGS1 הוא תכנון מתועד ייחודי למוצר של Livara. השוואה הוגנת מחייבת להפריד בין ארכיטקטורה, ראיות לגבי המימוש וההתנהגות שהמשתמשים חווים בפועל.
ההבחנה המרכזית היא בין מצב קבוצתי משותף מבוסס עץ לבין מפתחות שולחים שמופצים דרך הפעלות זוגיות. אף תווית כשלעצמה אינה אומרת אם אפליקציה מסוימת מטפלת נכון בחבר שהוסר, במכשיר עם מצב מיושן או במפתח שנחשף.
ההבדל הארכיטקטוני
RFC 9420 מגדיר MLS להקמת מפתחות קבוצתיים באופן אסינכרוני. הוא משתמש בעץ ratchet ובתקופות קבוצתיות, עם סודיות קדימה ואבטחה לאחר פריצה בתנאים מוצהרים. מבנה העץ שלו מצמצם עלויות מסוימות של עדכון מפתחות ככל שהקבוצה גדלה.
תיעוד האבטחה של Livara מתאר את LGS1 כשרשרת שולח חתומה לכל חבר, המופצת דרך הפעלות זוגיות של LVR1 ומוחלפת עם שינויי החברות. זו טענת מוצר, לא ראיה לכך ש־LGS1 תואם ל־MLS או שנערך לו אותו ניתוח.
| שאלה | MLS | תיעוד Livara LGS1 |
|---|---|---|
| מבנה משותף | עץ ratchet ותקופות | שרשראות לכל שולח |
| עדכוני מפתחות | שינויי מצב הקבוצה מקובעים בתקופה חדשה | מפתחות שולחים חדשים מופצים לחברים |
| מעמד המפרט | תקן IETF, RFC9420 | תיאור מפורסם ייחודי למוצר |
| מה עדיין דורש הערכה | שילוב באפליקציה והמימוש | מפרט מלא, מימוש וראיות עצמאיות |
הטבלה מתארת קטגוריות של תכנון. היא אינה מבחן ביצועים או דירוג אבטחה.
מה פירוש ״לוגריתמי״ — ומה לא
עדכון קריפטוגרפי יכול להשתמש במספר לוגריתמי של רכיבים מוצפנים בנתיב עץ, בלי להפוך את כל העבודה במערכת ללוגריתמית. עדיין צריך להפיץ הודעות, לקוחות שומרים מצב וההתנהגות תלויה במבנה הקבוצה ובפעולות. ההשוואה הישנה ״MLS דורש O(log N) הודעות ואילו הכול ב־LGS1 מהיר יותר״ ערבבה עלויות שונות ולא הציגה מדידות.
ארכיטקטורת MLS, RFC 9750, מתייחסת לשירות המסירה בנפרד מהקמת מפתחות קריפטוגרפית. היא דנה בהפצת הודעות ובסידור שינויי קבוצה. ההפרדה חשובה: חישובי לקוח, מספר הבתים ב־commit, סך תפוצת השרת ותעבורת התחברות מחדש הם מדדים שונים.
דוח ביצועים בעל משמעות צריך לציין:
- גודל קבוצה ומספר מכשירים לאדם;
- האם הפעולה היא הודעה רגילה, הסרת חבר, עדכון מפתח או התחברות מחדש;
- בתים שנשלחו בידי הלקוח היוזם לעומת כלל תעבורת המסירה;
- זמן שחלף, דגם מכשיר, גרסת מימוש ותנאי רשת;
- עלות של עדכונים שהוחמצו ושל שינויי חברות חוזרים.
בלי הפרטים האלה, טענות על ״אלפיות שנייה״, ״תקורת מצב נמוכה״ או עליונות בגודל קבוצה מסוים אינן מבוססות.
הסרת חבר היא בדיקת מחזור חיים
מנהל שמסיר חשבון הוא רק חלק מסיפור האבטחה. הלקוחות צריכים להסכים על מצב החברות החדש, להשתמש במפתחות חדשים מתאימים ולהימנע ממסירתם למכשירים שהוחרגו. אדם שכבר מחזיק בטקסט גלוי ישן או במפתחות ישנים עשוי לשמור גישה לתוכן ישן; הסרה אינה יכולה להעלים את העותקים שלו.
בכל אחת מהמערכות, בדיקה מועילה שואלת: לאחר השלמת ההסרה, האם המכשיר שהוסר יכול לפענח הודעת בדיקה חדשה שאינה רגישה? האם חבר שהיה לא מחובר יכול להשלים פערים בבטחה? האם מטופלים כל המכשירים ששייכים לחשבון? האם הממשק מציג כשלים או שינויי חברות?
אלה שאלות מוצעות להערכה, לא תוצאות של בדיקות שבוצעו כאן. השוואת מוצרים צריכה לפרסם את התוצאה שנצפתה ואת הגרסה שנבדקה, ולא להשוות לחיצה מוצלחת של מנהל להחרגה קריפטוגרפית.
סודיות קדימה והתאוששות תלויות בתנאים
שמירת ההגנה על הודעות ישנות לאחר פריצה מאוחרת יותר תלויה בהוצאה משימוש של חומר סודי ישן. שיקום ההגנה על הודעות עתידיות תלוי בשילוב סודות חדשים אחרי שהתוקף מאבד את הגישה הרלוונטית. ב־MLS, עיבוד עדכוני קבוצה הוא חלק מתהליך ההתאוששות; עצם שליחת עדכון אינה זהה לכך שכל חבר החיל אותו. ראו שיקולי אבטחה ב־RFC 9420.
בתכנון של מפתחות שולחים, שאלו איך מחליפים ומפיצים מחדש את המצב שנחשף אצל כל שולח. אין לתאר שרשרת חד־כיוונית לבדה ככזו שמחלימה אוטומטית מתוקף שיודע את מצבה הנוכחי. ההגנה הזוגית המשמשת בהפצה מחדש רלוונטית, אך אינה מחליפה ניתוח מלא ברמת הקבוצה.
טענות פוסט־קוונטיות דורשות חבילת אלגוריתמים והיקף מוגדרים
חבילות האלגוריתמים שמוגדרות ב־RFC9420 הבסיסי משתמשות במנגנוני מפתח ציבורי קלאסיים. MLS ניתן להרחבה, ולכן טענה על מימוש מסוים צריכה לזהות את החבילה ואת ההרחבות שבהן הוא משתמש בפועל, במקום להכריז שכל פריסות MLS יישארו קלאסיות לעד.
השימוש המתועד של LGS1 בהפצה היברידית של LVR1 הוא טענה שונה מערובה פוסט־קוונטית שעברה ניתוח עצמאי לכל פעולה קבוצתית. FIPS 203 מתקנן את ML-KEM; הוא אינו מסמיך את כל הפרוטוקול הקבוצתי שמשלב אותו. העריכו יחד אימות, שינויי חברות, חשיפת מפתחות ומימוש, ולא רק את שם ה־KEM.
מה לבקש לפני בחירת מוצר
בקשו את מפרט הפרוטוקול העדכני, וקטורי בדיקה ובדיקה עצמאית לגרסה המסוימת, לרבות ממצאים שלא נפתרו. לאחר מכן השוו דרישות מוצר רגילות: מכשירים נתמכים, התנהגות עדכונים, שחזור, תפקידי ניהול ותוכן והנתונים שהשרתים שומרים.
ארכיטקטורת MLS מתייחסת במפורש לשירותי אפליקציה ולהנחות האמון שלהם. בדומה לכך, יש לקרוא את מודל האיומים של Livara לצד טענות המוצר. הצפנה אינה הופכת משתתפים מורשים לאמינים, אינה מונעת צילומי מסך ואינה מסירה כל סוג של מטא־נתונים.
אם חסרות ראיות, רשמו ״לא הוכח״ במקום לתייג אוטומטית תכנון כלא מאובטח או כעדיף. ההחלטה צריכה לשקף את הסיכונים של הקבוצה שלכם ואת איכות הראיות הזמינות.
שאלות נפוצות
האם LGS1 הוא מימוש של MLS?
התיאורים שפורסמו מציגים ארכיטקטורות שונות. המאמר אינו מזהה את LGS1 כמימוש MLS ואינו טוען לתאימות הדדית.
האם MLS דורש שכל החברים יהיו מחוברים בו־זמנית?
לא. שימוש אסינכרוני הוא חלק מהתכנון שלו. אפליקציות עדיין צריכות מדיניות לעדכונים מושהים, למצב מיושן ולחברים שאינם מחוברים זמן רב.
האם הפצת מפתחות פוסט־קוונטית פותרת את אבטחת הקבוצה?
לא. היא מטפלת בחלק מהקמת המפתחות. זהות, חברות, מחזור חיי המפתחות, אבטחת נקודות קצה ומימוש עדיין דורשים ראיות.
איזה תכנון מהיר יותר?
אין במאמר הזה מבחן ביצועים שמבסס מנצח. מדדו את הפעולות ואת הפריסה שחשובות לקבוצה שלכם.
