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