פריצה לשרת הודעות אינה אומרת בהכרח שכל ההודעות נקראו. התוצאה תלויה בנתונים המאוחסנים, במיקום המפתחות וברמת הגישה של התוקף. גם כאשר טקסט הצ׳אט מוצפן כראוי מקצה לקצה, פרטי חשבון, זמנים, חברות בקבוצות ונתיבי מסירה עשויים להיות רגישים.
כדי להעריך אירוע, שאלו תחילה מה הגיע לידי התוקף: עותק של מסד הנתונים, מפתחות תשתית, השרת הפעיל או מערכת הפצת התוכנה? לתרחישים האלה אין אותן השלכות.
מסד נתונים שנגנב שונה משרת שנמצא בשליטת התוקף
תוקף שמחזיק רק עותק ישן של מסד הנתונים מוגבל לנתונים שנרשמו בו. שליטה בשירות פעיל עשויה לאפשר רישום נתונים חדשים, גניבת הפעלות, שינוי תגובות או ניסיון להחליף מפתח של איש קשר. גישה לשרשרת הפצת התוכנה היא סיכון אחר: קוד זדוני בנקודת הקצה עשוי לראות את הטקסט לפני ההצפנה או אחרי הפענוח.
לכן הטענה ״מסד הנתונים אינו מכיל את המפתח לטקסט ההודעות״ חשובה, אך אינה תשובה מלאה לכל סוגי החדירה.
השוואה בין חמש תבניות ארכיטקטורה
אלו תבניות לימודיות, לא דירוג של חמישה מוצרים. שירות יכול להשתמש בכמה תבניות עבור יכולות שונות.
| תבנית | נתונים נגישים מתוך מסד הנתונים | גבול חשוב |
|---|---|---|
| הודעות וסיסמאות בטקסט גלוי | התוכן ופרטי ההתחברות ניתנים לקריאה ישירה | היעדר הגנה מתאימה לשני סוגי הנתונים |
| סיסמאות מגובבות, הודעות גלויות | התוכן קריא; ייתכן שאפשר לבדוק ניחושי סיסמה | איכות שיטת אחסון הסיסמאות אינה מגינה על טקסט הצ׳אט |
| תוכן מוצפן במפתח שרת | טקסט מוצפן; הקריאה תלויה בגישה למפתח | חשובה הפרדה אמיתית בין המפתח לנתונים |
| צ׳אט E2EE עם גיבוי נגיש לספק | הצ׳אט החי עשוי להיות מוגן, אבל לעותק ההיסטוריה יש מסלול חשיפה נפרד | יש לבדוק את מדיניות הגיבוי ואת המפתח שלו |
| צ׳אט E2EE עם שחזור מוצפן ומפתח עצמאי | טקסט מוצפן ונתונים תפעוליים; הגנת התוכן תלויה בתכנון ובהגנה על המפתח | המכשיר, ביטוי השחזור ואימות זהות איש הקשר עדיין חשובים |
הצפנת דיסק השרת מועילה נגד גניבת דיסק גולמי. כאשר גם השירות הפעיל או מפתח הפענוח נמצאים בידי התוקף, אין להניח שקיימת אותה הגנה. ב־E2EE המטרה היא שלשירות המתווך לא יהיה המפתח הנדרש לקריאת התוכן המוגן.
מה המטא־נתונים מראים?
מטא־נתונים עשויים להראות אילו חשבונות תקשרו, מתי היו פעילים, באילו קבוצות הם חברים וכמה נתונים הועברו. המידע הזה אינו טקסט ההודעה, אך הוא בעל ערך להבנת רשת הקשרים או דפוסי הפעילות.
עמוד האבטחה של Livara מסביר במפורש אחסון ועיבוד של נתונים תפעוליים, ובהם ניתוב, חברות, זמנים, גודל הטקסט המוצפן ומצב המסירה. אין לפרש סודיות של תוכן פרטי כאנונימיות מלאה או כהיעדר כל נתון בשרת.
SRP אינו פוטר נתוני חשבון מסיכון של ניחוש סיסמאות
SRP הוא דרך להוכיח ידיעה של סיסמה בלי לשלוח ישירות את הסיסמה עצמה. השרת עדיין מחזיק נתון אימות, או verifier. סעיף האבטחה של RFC 5054 מסביר שגניבת ה־verifier עשויה לאפשר התקפת מילון לניחוש הסיסמה.
לכן ״הסיסמה אינה נשלחת ברשת״ שונה מ״אין נתונים הקשורים לסיסמה שאפשר לגנוב״. סיסמה ייחודית וחזקה, הגנת המכשיר ותגובה מתאימה לאירוע עדיין נחוצות. SRP גם אינו תחליף להצפנת תוכן או להגנת הפעלת ההתחברות.
אילו גבולות הוצהרו לגבי Livara?
מסמך האבטחה של Livara מתאר את LVR1 עבור הודעות ישירות ואת LGS1 עבור קבוצות מוגנות. הגנת הקבוצה תלויה במצבה בפועל; קבוצה ישנה שאינה תואמת לא אמורה לקבל תווית E2EE. ערוצים ציבוריים נמצאים מחוץ לגבול הסודיות הזה.
אותו מסמך מציג את שחזור v7 כחבילת זהות מוצפנת שמוגנת לפני העלאתה. התהליך הזה מחזיר את הזהות הקריפטוגרפית, לא את היסטוריית הצ׳אט. חשיפה של ביטוי השחזור או של המכשיר שמחזיק במפתחות היא תרחיש שונה מגניבת מסד הנתונים בלבד.
אלו תיאורים שפורסמו על המוצר, ולא תוצאה של ביקורת בלתי תלויה במסגרת מאמר זה. גם אזכור של AES או ML-KEM כשלעצמו אינו מוכיח שניהול המפתחות ומימוש האפליקציה נכונים.
אילו שאלות לשאול כשמוכרז אירוע?
- באיזה פרק זמן ובאילו מערכות מדובר? הביטוי המעורפל ״מידע של משתמשים״ אינו מספיק.
- האם היו נגישים טקסט גלוי, קבצים, מפתחות, verifier, הפעלות התחברות או רק טקסט מוצפן?
- האם התוקף יכול היה לשנות את השירות או את התוכנה שמסופקת למשתמשים?
- אילו פעולות נדרשות בערוץ הרשמי: סיום הפעלות, שינוי סיסמה, עדכון או בדיקת זהות איש קשר?
- האם המלצת השחזור עלולה למחוק את ההיסטוריה המקומית? קראו את המגבלות לפני מחיקת האפליקציה.
אל תשתמשו בקישור מהודעה אנונימית לצורך ״אימות חשבון מיידי״. פתחו באופן עצמאי את הכתובת הרשמית כדי לקרוא את ההודעה. מודל האיומים של Livara מועיל להבנת הגבולות הכלליים; את היקפו של אירוע אמיתי יש לקבוע לפי הראיות של אותו אירוע.
