כדי להעריך את אבטחת השיחה, אל תשאלו רק ״היא מוצפנת?״; שאלו היכן ההצפנה מסתיימת ומה ההקלטה משנה.
הצפנת הצ'אט אינה מוכיחה כשלעצמה שגם שמע, וידאו, שיתוף מסך או הקלטת שיחה זוכים לאותה הגנה. כדי להעריך שיחה, צריך לשאול עד איזו נקודה המדיה נשארת מוצפנת, מי מחזיק במפתח ומה משתנה כשמפעילים תכונות כמו הקלטה.
המדריך הזה מחלק את טענות האבטחה לשכבות שאפשר לבדוק; שם של פרוטוקול או סמל מנעול אינם תחליף לתשובות על השאלות האלה.
שלושה מסלולים שונים באותה אפליקציה
| מסלול | דוגמאות לנתונים | שאלת האבטחה |
|---|---|---|
| הודעות שנשמרות | טקסט, תמונות, קבצים והודעות קוליות | מי יכול לקרוא את העותקים שבמכשיר, בשרת ובגיבוי? |
| מדיה בזמן אמת | שמע מהמיקרופון, וידאו ושיתוף מסך | האם ההצפנה מסתיימת במכשיר של הצד השני או בשרת מתווך? |
| איתות | הזמנה לשיחה, מענה ומידע לתיאום החיבור | מי יכול לשנות את הודעות הבקרה או את זהות היעד? |
הודעה קולית שנשלחת בצ'אט היא קובץ; שיחה קולית היא זרם בזמן אמת. מוצר עשוי להשתמש במפתחות ובמנגנונים שונים עבור השניים. גם איכות שמע טובה או הודעת טקסט שלא הגיעה אינן מלמדות כשלעצמן דבר על האבטחה של המסלול האחר.
על מה מעיד DTLS-SRTP?
ב־WebRTC, SRTP מגן על זרם המדיה, ו־DTLS-SRTP הוא דרך לבסס את חומר המפתח הנדרש לכך. RFC 5764 מסביר את מנגנון DTLS-SRTP, ו־RFC 3711 מסביר את ההגנה על מנות המדיה.
אבל האמירה ״אנחנו משתמשים ב־WebRTC״ אינה עונה כשלעצמה על השאלה אם שרת הוועידה מפענח את המדיה. צריך להבהיר מהן נקודות הקצה של ההצפנה וכיצד מאמתים את זהותן. ייתכן שיש חיבור מוצפן בין המשתמש לשרת, אבל לשרת יש גישה לתוכן המפוענח לצורך עיבוד או הקלטה. זה אינו אותו דבר כמו הצפנה מקצה לקצה (E2EE) בין המשתתפים.
ארכיטקטורת האבטחה של WebRTC ב־RFC 8827 מראה גם שלצד ההגנה על המדיה, יש חשיבות לאמון באפליקציית הווב, למסלול האיתות ולזהות הצד השני. העובדה שהמנות מוצפנות אינה אומרת שאפשר לתת אמון בכל רכיבי המוצר.
למה צריך להעריך את האיתות בנפרד?
האיתות מתאם מי מתקשר למי וכיצד נוצר החיבור. גם אם אפליקציה מגינה על הודעות הבקרה, עדיין צריך לבדוק כיצד ההגנה הזאת קשורה לזהות האמיתית של המשתתפים ולמפתחות המדיה.
כשקוראים את התיעוד, מספיקות שלוש שאלות:
- האם ההזמנה, המענה ופרטי המפתח מוגנים מפני שינוי?
- איך המשתמש יודע שהמפתח שייך לצד השני שאליו התכוון להתקשר?
- איזו אזהרה מוצגת כשהמפתח או המכשיר משתנים?
גם בשיחה עם E2EE, השירות עשוי לדעת את פרטי הניתוב, את זמן השיחה ואת זהות המשתתפים בה. המאמר ״הסבר על מטא־נתונים באפליקציות מסרים״ עוסק בהבדל הזה.
הקלטת שיחה היא גבול אבטחה חדש
״שיחה מוצפנת״ אינה תשובה מלאה לגבי העותק המוקלט. משתתף יכול להקליט שמע או וידאו באמצעות המכשיר שלו. גם הקלטה בצד השרת צריכה להיות מתועדת בנפרד: האם השרת מקבל גישה למדיה מפוענחת כדי להקליט? מי שומר את הקובץ? מתי הוא נמחק?
אם הפעלת ההקלטה משנה את מצב האבטחה, השינוי צריך להיות ברור למשתתפים. לפני שיחה רגישה, בדקו את מצב ההקלטה ואת הסכמת המשתתפים; העובדה שחיווי ההקלטה המובנה כבוי אינה מבטיחה שאיש אינו מקליט באמצעות כלי אחר.
איך לקרוא את התיעוד העדכני של Livara?
עמוד האבטחה של Livara מתאר שיחות ישירות וקבוצתיות כשיחות עם E2EE, אבל מחריג הקלטה אופציונלית בצד השרת: במצב שבו מוצג חיווי REC, ההגנה על השיחה משתנה להצפנת תעבורה. זו טענה בתיעוד המוצר, ולא תוצאה של בדיקה או ביקורת בלתי תלויה שנערכה במסגרת המאמר הזה.
ההגבלה בטקסט הישן של כל השיחות הקבוצתיות ל־״2 עד 6 משתתפים ב־Android״ אינה תואמת את התיעוד העדכני ואינה משמשת בסיס למדריך הזה. לגבי מספר המשתתפים הנתמך, הפלטפורמה והגרסה הרלוונטיים, צריך לבדוק את המדריך העדכני ואת ההתנהגות בפועל של האפליקציה; המאמר הזה אינו מציג בדיקה של קיבולת השיחות.
כמו כן, אזכור של אלגוריתמים בצ'אט, כגון ML-KEM, אינו מוכיח כשלעצמו שאותו אלגוריתם משמש גם למדיה של השיחה. כדי לטעון שלשיחה יש הגנה פוסט־קוונטית, נדרשות ראיות ייעודיות למסלול המדיה ולאימות הזהות. קראו את מודל האיומים של Livara לצד עמוד היכולות, ולא כתחליף לבדיקה בלתי תלויה.
רשימת בדיקה קצרה לפני שמשווים בין שני שירותים
לכל תשובת ״כן״, רשמו גם את הגרסה ואת המקור:
- האם שיחות בין שני משתתפים, שיחות קבוצתיות ושיתוף מסך מתוארים בנפרד?
- האם ברור אם השרת רק מעביר מנות או מסוגל גם לפענח את המדיה?
- האם אפשר לאמת את זהות המשתתף ואת המפתח שלו?
- האם החלפת מכשיר, הוספת משתתף והפעלת הקלטה גלויות לעין?
- האם מסלול השיחה בווב ובאפליקציה זהה או שונה?
- האם יש הסבר על שמירת קובצי ההקלטה והמטא־נתונים?
- האם ראיות מבדיקה או מביקורת מתייחסות לאותה גרסה ולאותה תכונה?
אם התשובה אינה בתיעוד, כתבו ״לא ידוע״; היעדר תשובה אינו מוכיח אבטחה ואינו מוכיח האזנה.
שאלות נפוצות
האם שיחה עם E2EE מונעת מהצד השני להקליט?
לא. לנמען המורשה יש גישה לתוכן המפוענח, והוא עשוי להקליט אותו באמצעות תוכנה או מכשיר אחר.
האם הצפנת תעבורה היא דבר רע?
הצפנת תעבורה מספקת הגנה חשובה מפני האזנה לאורך מסלול התקשורת. ההבדל הוא שלשירות שהוא נקודת הקצה עשויה להיות גישה לתוכן המפוענח; אין לכנות זאת E2EE בין משתמשים.
האם שימוש בהצפנה פוסט־קוונטית בצ'אט הופך גם את השיחה לפוסט־קוונטית?
לא. הטענה חייבת להתייחס לאותה שכבה, לאותם אלגוריתמים ולאותה גרסת מימוש. העריכו את הצ'אט ואת השיחה בנפרד.
