השאלה המועילה על אבטחה אינה אם ההצפנה נשמעת חזקה, אלא על מה היא מגינה, מי מחזיק במפתחות ואילו ראיות תומכות בטענה.
״הצפנה ברמה צבאית״ אינה מידע מספיק להערכת אפליקציית מסרים. הביטוי אינו אומר מי מחזיק במפתחות, אילו שיחות מוגנות, האם גיבויים חושפים טקסט גלוי או מה קורה כאשר מכשיר נפרץ.
התגובה המועילה אינה לפטור את ההצפנה כחסרת ערך. היא להחליף תווית מרשימה בטענות ספציפיות שאפשר לבדוק.
AES-256 הוא בחירת אלגוריתם, לא מודל אבטחה שלם
AES הוא תקן ציבורי, לא טכנולוגיה צבאית סודית. FIPS 197 של NIST מגדיר AES-128, AES-192 ו־AES-256; הסיומת מציינת את אורך המפתח. התקן עבר עדכון עריכתי ב־2023 ללא שינוי באלגוריתם.
גם צופן חזק יכול לשמש במערכת שמעניקה לשירות גישה לטקסט גלוי. שאלו מי יכול לפענח, ולא רק מה אורך המפתח. שאלו גם איך מפתחות נוצרים ונשמרים, איך זהויות מאומתות ואילו תנאי כשל גורמים לאפליקציה לעצור במקום להמשיך באופן לא מאובטח.
כאשר ספק מציין AES-GCM, זו אמירה ספציפית יותר מציון AES בלבד: GCM משלב הצפנה עם אימות. טיפול נכון ב־nonce, אימות תגיות ודרישות מימוש אחרות עדיין חשובים. מפרט GCM של NIST הוא המקור הטכני; סמל אינו ראיה לכך שאפליקציה מממשת אותו כראוי.
ארבע טענות שונות ששיווק מרבה לשלב
| טענה | במה היא עוסקת | מה היא אינה מוכיחה |
|---|---|---|
| תעבורה מוצפנת | הגנה לאורך חיבור, למשל בין אפליקציה לשרת | שהשרת אינו יכול לקרוא תוכן |
| הצפנה במנוחה | הגנה על נתונים מאוחסנים לפי מודל מסוים של מפתחות וגישה | שלמפעיל אין מפתח פענוח |
| הצפנה מקצה לקצה | הגנה על תוכן בין נקודות קצה מוגדרות | בטיחות של נקודת קצה שנפרצה או יושרו של הנמען |
| הקמת מפתחות פוסט־קוונטית | עמידות בפני איומים קוונטיים מוגדרים בעת הקמת מפתחות | ביקורת מלאה של האפליקציה, אנונימיות או אבטחה עתידית מובטחת |
הצפנת תעבורה אינה מרמזת שכל מסד נתונים של ספק שומר טקסט גלוי גולמי. שירות יכול גם להצפין נתונים מאוחסנים. ההבחנה הרלוונטית היא האם הספק שולט במפתחות או שיש לו גישה אחרת לתוכן קריא. דייקו במקום להחליף סיסמה אחת באחרת.
למבוא רחב יותר, עיינו בהסבר על מה שהצפנה מקצה לקצה מגינה עליו.
״משתמש בתקן NIST״ אינו ״מתוקף לפי FIPS״
FIPS 203 מגדיר את ML-KEM, מנגנון כימוס מפתחות. אפליקציית מסרים יכולה לתאר שימוש באלגוריתם הזה בלי שהאפליקציה כולה הוסמכה או נבדקה באופן עצמאי. תקנים, בדיקות אלגוריתמים, תיקוף מודולים קריפטוגרפיים וביקורות אבטחת מוצר הם סוגים שונים של ראיות.
תוכנית תיקוף המודולים הקריפטוגרפיים של NIST מבהירה שמימוש פונקציות מאושרות אינו מספיק כדי לבסס תיקוף מודול לפי FIPS 140. אם מוצר מפרסם תיקוף, בקשו את התעודה, את המודול והגרסה המדויקים, את סביבת ההפעלה ואת התצורה המאושרת. לאחר מכן בררו איזה חלק במוצר התעודה באמת מכסה.
זו גם הסיבה שלא צריך להשתמש ב״אבטחה של 256 סיביות״ כציון כולל לאפליקציית מסרים שלמה. שילוב פרוטוקולים, ניהול מפתחות ומימוש יכולים להציב מגבלות שונות.
אימות באמצעות סיסמה אינו הצפנת הודעות
מנגנון כניסה עונה על השאלה אם משתמש יכול לגשת לחשבון. E2EE עונה על השאלה מי יכול לקרוא תוכן הודעות מוגן. אף אחד מהם אינו מספק אוטומטית את תכונותיו של האחר.
למשל, SRP נועד לאמת בלי להעביר את הסיסמה עצמה. אין פירוש הדבר שמסד נתוני אימות שנגנב אינו מזיק. דיון האבטחה של SRP ב־RFC 5054 מסביר שערך אימות שנגנב מאפשר מתקפות ניחוש סיסמאות וסיכונים אחרים. הימנעו מהמסקנה ״אין סיסמאות שאפשר לגנוב, ולכן לפריצה לשרת לא יכולה להיות משמעות״.
עבור הקוראים, הצעד המעשי הבא הוא לשאול על שחזור חשבון, הפעלות פעילות והקשר בין גישה לחשבון לבין מפתחות הצפנה. תשובה שרק חוזרת על ״אפס ידע״ משאירה את השאלות החשובות ללא מענה.
מבחן של חמש שאלות לעמוד האבטחה של אפליקציית מסרים
- אילו משטחים מכוסים? לשיחות אישיות, קבוצות, קבצים, שיחות קוליות, פרסומים ציבוריים וגיבויים עשויים להיות גבולות שונים.
- מי מחזיק במפתחות שמישים? כללו מפתחות שחזור, מכשירים מקושרים ומצבי עיבוד בצד השרת.
- איך מאמתים את נקודת הקצה השנייה? חפשו אימות מפתחות, אזהרות משמעותיות על שינויים ומודל אמון מתועד.
- אילו ראיות קיימות? מפרטים, בניות הניתנות לשחזור, וקטורי בדיקה וביקורות עצמאיות עונים על שאלות שונות. בקשו את הגרסה וההיקף של כל אחד.
- מה נשאר גלוי או פגיע? מטא־נתונים, מכשירים שנפרצו, הודעות שהועתקו ותוכן ציבורי לא אמורים להיעלם מההסבר.
החילו את אותו מבחן על Livara. תיעוד האבטחה שלה מציין את LVR1 ואת LGS1 ומפרסם גבולות תפעוליים. התייחסו אליהם כאל טענות מוצר שיש להעריך, לא כהסמכה עצמאית. Proof Lab מציע הדגמות מוגבלות ובדיקות של תוצרים, לא הוכחה שכל תכונה או גרסה מאובטחת.
איך לקרוא ביקורת עצמאית
בדקו את התאריך, את המבקר, את גרסת הקוד, את הפלטפורמות שנכללו ואת הרכיבים שהוחרגו. קראו את הממצאים ואת מצב התיקונים, לא רק את תג הסיכום. ביקורת של ספרייה קריפטוגרפית אינה מכסה אוטומטית שחזור חשבון, את אפליקציית הווב, התראות או אבטחה תפעולית.
היעדר ביקורת הוא פער בביסוס הביטחון באבטחה, לא הוכחה לחולשה מסוימת. מנגד, ביקורת אינה ערובה לכל החיים. השוואה מועילה מתעדת את הראיות ואת מגבלותיהן במקום להכריז על מנצח אוניברסלי שהוא ״המאובטח ביותר״.
שאלות נפוצות
האם ״ברמה צבאית״ הוא תמיד שם אחר ל־AES-256?
לא. אל תסיקו מהביטוי אלגוריתם מסוים או הסמכה. בקשו מהספק לציין בדיוק למה הוא מתכוון.
האם הצפנה חזקה יותר מונעת צילומי מסך או נוזקות?
היא אינה מונעת מנמען להעתיק תוכן או ממכשיר שנפרץ לחשוף נתונים שיש לו גישה אליהם. אלה איומים אחרים.
מהו סימן טוב יותר מסיסמת אבטחה?
היקף ברור, פרוטוקול מצוין בשמו, מגבלות מפורשות וראיות ניתנות לבדיקה לגבי המימוש שמופץ בפועל. ההסבר צריך לעזור לכם להחליט במה לתת אמון — ומה עדיין דורש בדיקה.
