שלמות הודעות: האם השרת יכול לשנות צ׳אט מוצפן?

מסנג׳ר יכול להציע עריכה או מחיקה; אך במערכת עם הצפנה מאומתת, השרת לא אמור להיות מסוגל לשנות בשקט את הטקסט המוצפן ועדיין למסור הודעה תקפה. שלמות הודעות במסנג׳ר פירושה שהנמען יכול לזהות שהנתונים השתנו לאחר ההצפנה; תכונה זו אינה זהה לשמירת היסטוריה מלאה או להוכחה משפטית של השיחה.

נקודות מרכזיות

• הצפנה מאומתת חושפת שינוי בטקסט המוצפן, אך אינה שומרת בהכרח היסטוריה של עריכות ומחיקות.
• לפי המסמכים הטכניים של Livara, ‏AES-256-GCM מגן על הודעות פרטיות באמצעות תג אימות; חבילה ששונתה לא אמורה להתפענח כתקפה.
• עריכה מורשית צריכה להיות אירוע חדש המוצפן מקצה לקצה, לא שכתוב חשאי של החבילה הקודמת בידי השרת.
• מספרי בטיחות מסייעים בבדיקת מפתח הצד השני, לא במדידת יושרו או תוקפו המשפטי של צילום מסך.
• במחלוקות רגישות, שמרו גם מחוץ לשרשור השיחה את הקובץ המקורי, הזמנים, מצב העריכה וראיות עצמאיות.

מהי בדיוק שלמות הודעות במסנג׳ר?

שלמות הודעה פירושה שהנמען יכול לזהות שינוי לא מורשה בנתונים המוצפנים. סודיות שואלת ״מי יכול לקרוא את הטקסט?״; שלמות שואלת ״האם הגיעו אותם נתונים שהשולח הצפין?״. ההסבר על הצפנה מקצה לקצה וגבולותיה מפרט את ההבדל הזה.

זהו איור מושגי עם תוויות להמחשה; הוא אינו הממשק האמיתי של Livara ואינו תוצאה של בדיקת דחיית הודעה ששונתה.

לפי המסמכים הטכניים של Livara, הודעות ישירות מוצפנות מקצה לקצה באמצעות LVR1 וקבוצות פרטיות תואמות באמצעות LGS1. לפי עמוד האבטחה של Livara, קבוצה ישנה שאינה תואמת נשארת במפורש מחוץ ל־E2EE, וקבוצה חדשה לא נוצרת עם תווית מוצפנת עד שכל חבריה מוכנים. בדקו את מצב השיחה המסוימת. המסמכים אומרים ש־LVR1 משתמש ב־ECDH P-256 וב־ML-KEM-768 לגזירת מפתח ההודעה. היותו של רכיב תקני אינה אישור עצמאי לכל השילוב או המוצר. לאחר מכן Livara משתמשת ב־AES-256-GCM להגנת התוכן.

לפי תיעוד המוצר, ההגנה כוללת טקסט, עריכות וקבצים מצורפים בשיחות פרטיות. אך ערוצי Livara אינם מוצפנים מקצה לקצה: השרת יכול בכוונה לקרוא את תוכנם, בין היתר כדי להסיר תוכן פוגעני. גם החברות בקבוצות נמצאת בשליטת השרת. את אבטחת השיחות הקוליות ומצב ההקלטה יש לבחון בנפרד מהודעות טקסט.

זיהוי שינוי בהודעה מוצפנת והצפנת AES-256-GCM במסנג׳ר

מלבד הצפנת התוכן, AES-GCM יוצר תג אימות. אם הטקסט המוצפן או הנתונים המאומתים משתנים, בדיקת התג צריכה להיכשל. NIST SP 800-38D מגדיר את מצב GCM ומזהיר ששימוש חוזר ב־nonce עם אותו מפתח עלול לפגוע קשות באבטחה.

לפי המפרט הטכני של Livara, הודעות פרטיות משתמשות ב־AES-256-GCM. אם השרת משנה חלק מהחבילה המוגנת, הוא אינו יכול ליצור תג אימות חדש בלי מפתח ההודעה; לכן הנמען לא אמור לקבל את החבילה כתקינה. התשובה הקצרה לשאלה ״האם השרת יכול לשנות הודעה?״ היא: השרת יכול למחוק, להחזיק, לחסום או לעכב נתונים, אך לא אמור להיות מסוגל להציג תוכן ששונה כתקף.

ההבטחה אינה בלתי מוגבלת. הצפנה אינה מנטרלת נוזקה במכשיר, גישת תוקף למסך פתוח או עריכה מורשית של המשתמש. גם שלמות התוכן אינה בהכרח מסתירה מטא־נתונים. המדריך למטא־נתונים במסנג׳רים ולמה שהם חושפים מסביר גבול זה.

האם השרת יכול לשנות הודעה, או שעריכה היא דבר אחר?

השרת לא אמור להיות מסוגל לשכתב בחשאי את החבילה המוצפנת הקודמת, אך יכול למסור אירוע עריכה שהשולח יצר. אבטחת עריכת הודעות תלויה בכך שגם העריכה תאומת ותוצפן מקצה לקצה כמו ההודעה המקורית, ולא בכך שהשרת ישנה ישירות את הטקסט השמור.

לפי תיעוד Livara, עריכה בצ׳אט ישיר מוגנת תחת LVR1 ובקבוצה פרטית תואמת תחת LGS1. כדי להעריך את הממשק, בדקו אם האפליקציה מציגה מצב ״נערך״; עם זאת, הצפנה לבדה אינה שומרת את הגרסה הקודמת לנצח בכל המכשירים.

גם ״מחיקה אצל כולם״ היא בקשה להסרת התוכן, לא הוכחה להשמדת כל העותקים. הנמען עשוי כבר לראות את ההודעה, לקרוא את ההתראה, לשמור את הקובץ או לצלם את המסך. הודעות נעלמות מפחיתות התמדה, אך אינן מבטיחות מחיקה של כל העותקים.

מה מוכיח אימות של הודעת צ׳אט?

אימות הודעת צ׳אט מראה שההודעה נוצרה עם מפתחות הסשן ולא שונתה בדרך. הוא אינו מוכיח שבעל החשבון החזיק אישית במכשיר, שהטקסט אמיתי או שהנמען יוכל אחר כך להוכיח אותו לצד שלישי באופן מכריע.

Livara מציגה במסמכיה הטכניים מספרי בטיחות כדרך לזיהוי החלפת מפתח. שני אנשים יכולים להשוות טביעות אצבע של מפתחות בערוץ עצמאי; המדריך לבדיקת צ׳אט בעזרת מספרי בטיחות מתאר את הצעדים המעשיים. הבדיקה מפחיתה את הסיכון להחלפת מפתח איש הקשר במפתח תוקף, אך אינה מאבטחת מכשיר נגוע.

גם אימות החשבון הוא נושא נפרד. שום מנגנון כניסה, חזק ככל שיהיה, אינו מחליף שלמות הודעות, בדיקת מפתח איש הקשר או אבטחת המכשיר.

שלמות התוכן אינה סדר ההודעות ועדכניותן

לחבילה ישנה עשוי להיות תג אימות תקף. מניעת קבלתה שוב דורשת תכנון פרוטוקול, מונים, מזהה סשן ושמירת מצב אצל הנמען; AES-GCM לבדו אינו יומן הסדר של השיחה כולה. ההבדל חשוב להערכת שידור חוזר, הודעות מאוחרות וסנכרון בין מכשירים.

יש גם לברר אילו נתונים מכוסים בפועל בתג האימות. אם מזהה השיחה או סוג האירוע נמצאים מחוץ להקשר המאומת, הגנה על גוף ההודעה בלבד אינה פותרת את כל הבעיה. סקירת קוד ובדיקה של אותה גרסה צריכות להבהיר את הקשר.

אם הטקסט או מצב ההודעה אינם צפויים

תעדו את גרסת האפליקציה, זמן התצפית, המכשירים המעורבים וקיומה של תווית עריכה. בדקו עם איש הקשר בערוץ עצמאי אם ביצע עריכה מורשית. אל תייחסו פער סנכרון לשינוי בידי השרת ללא ראיות; אך גם אל תתעלמו משגיאת אימות או מהחלפת מפתח ללא סיבה.

לדוח טכני השתמשו בהודעת בדיקה שאינה רגישה, ואל תכללו מידע פרטי של איש הקשר בדוח ציבורי. אם השיחה מיועדת לשימוש בעניין משפטי, הצפנה או צילום מסך לבדם אינם קובעים תוקף משפטי; לפני שינוי ראיות, היעזרו במומחה מוסמך.

כיצד מעריכים טענת שלמות של מסנג׳ר?

אל תסתפקו במילה ״מוצפן״. שאלו:

• אילו שיחות וקבצים מוצפנים מקצה לקצה?
• באיזה אלגוריתם AEAD משתמש השירות?
• כיצד עריכות ומחיקות מתועדות ומוצגות?
• כיצד המשתמש מזהה החלפת מפתח של איש הקשר?
• באילו מטא־נתונים, תוכן או חברות בקבוצות שולט השרת?
• האם לשיחות יש אותן הבטחות כמו להודעות?
• האם הפרוטוקול עבר ביקורת עצמאית?

Livara מפרסמת מפרטים וכלים לבדיקת חלק מטענותיה, ומשתמשי Android יכולים להשוות את סכום הביקורת של קובץ APK באמצעות SHA-256 ב־Proof Lab לבדיקת האפליקציה ללא חיבור. עם זאת, מאמר זה אינו מציג ראיה לביקורת עצמאית של הגרסה הנוכחית. פרסום מפרטים ווקטורי בדיקה מסייע לבדיקה, אך אינו מחליף ביקורת עצמאית.

לגבי שיחות פרטיות, הטענה המרכזית של Livara מוגבלת וברורה: AES-256-GCM אמור לחשוף שינוי בחבילה, וגם עריכות אמורות להיות מוצפנות. הטענה אינה אומרת שקיים יומן בלתי ניתן לשינוי, מחיקה ודאית של כל העותקים או ראיה משפטית אוטומטית.

שאלות נפוצות

האם מנהל השרת יכול לשנות את טקסט ההודעה המוצפנת?

בתכנון נכון עם AES-256-GCM, מנהל השרת אינו יכול לשנות את הטקסט המוצפן וליצור תג אימות תקף ללא מפתח ההודעה. הוא עדיין יכול למחוק, לחסום או לעכב את החבילה. ההבטחה אינה מכסה מכשיר נגוע או עריכה מורשית של השולח.

האם התווית ״נערך״ מוכיחה מה הייתה הגרסה הקודמת?

לא. היא רק אומרת שהתוכן המוצג השתנה לאחר השליחה, אלא אם האפליקציה שומרת גם היסטוריית גרסאות. הצפנה יכולה לאמת את אירוע העריכה, אך אינה שומרת אוטומטית את הטקסט הקודם.

האם מספר בטיחות מבטיח את האותנטיות של כל ההודעות?

לא. מספר בטיחות עוזר לבדוק שמפתח ההצפנה שייך לאיש הקשר ולזהות את החלפתו. הבדיקה אינה אומרת מי החזיק במכשיר בזמן השליחה, שההודעה אמת או שאין במכשיר נוזקה.

האם מחיקה אצל כולם מוחקת את ההודעה מכל מקום?

לא. התכונה עשויה להסיר את העותק שבתוך האפליקציה, אך אינה מחזירה קובץ שנשמר, התראה, צילום מסך או תיעוד קודם. היא מפחיתה התמדה; אינה מבטיחה מחיקה ממכשיר הנמען או ממערכות אחרות.