הצפנה מקצה לקצה, ההסבר האמיתי

מה המשמעות האמיתית של הצפנה

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

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

הפרדוקס של הסוד המשותף

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

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

האלגנטיות של Diffie-Hellman

בשנת 1976, שני מתמטיקאים בשם Whitfield Diffie ו-Martin Hellman הוכיחו משהו שנראה בלתי אפשרי: ששני אנשים, המדברים רק דרך ערוץ ציבורי — ערוץ שבו כל אחד יכול לשמוע כל מה שהם אומרים — יכולים להסכים על סיסמה סודית מבלי שאף מאזין יוכל לגלות אותה. זה נשמע כמו קסם. זה לא: זה מתמטיקה. החלפת מפתחות Diffie-Hellman, כפי שהיא ידועה מאז, היא הבסיס לכל תקשורת האינטרנט המוצפנת כמעט, וחצי מאה של שימוש אינטנסיבי ובחינה אקדמית עולמית מאשרים את חוסנה. מי שרוצה לראות את האינטואיציה הוויזואלית או את המתמטיקה יכול להמשיך לקרוא. מי שמעדיף לסמוך על כך שזה עובד יכול גם להמשיך מבלי לאבד את חוט המאמר.

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

מ-Diffie-Hellman לפרוטוקול Signal

הצפנה מקצה לקצה שבה משתמשות כיום אפליקציות מסרים מקצועיות נשענת, כמעט ללא יוצא מן הכלל, על גרסה אלגנטית ומחוזקת של החלפת מפתחות Diffie-Hellman. פרוטוקול Signal, שתוכנן על ידי Trevor Perrin ו-Moxie Marlinspike בין 2013 ל-2016, הוא נקודת הייחוס. הוא משלב שני רעיונות מרכזיים. הראשון, החלפת מפתחות בעקומים אליפטיים (X25519), המייצרת את הסוד המשותף הראשוני בין שני מכשירים. השני, ה-Double Ratchet — גלגל שיניים כפול — המחדש את המפתחות באופן אוטומטי עם כל הודעה, כך שפריצה למכשיר היום אינה מאפשרת פענוח הודעות עבר, ולא הודעות עתידיות ברגע שגלגל השיניים הסתובב.

ב-Zig, החלפת X25519 המייצרת את הסוד המשותף בין שני מכשירים נכנסת בשישה שורות, תוך שימוש בספריה הסטנדרטית:

const std = @import("std");
const X25519 = std.crypto.dh.X25519;

// Alicia y Bruno generan cada uno un par (privada, pública).
const par_alicia = X25519.KeyPair.generate(io);
const par_bruno  = X25519.KeyPair.generate(io);

// Cada parte recibe la clave pública de la otra y deriva el mismo secreto.
const secreto_alicia = X25519.scalarmult(par_alicia.secret_key, par_bruno.public_key) catch unreachable;
const secreto_bruno  = X25519.scalarmult(par_bruno.secret_key,  par_alicia.public_key) catch unreachable;
// secreto_alicia == secreto_bruno  (32 bytes)

ומה בדיוק יש בתוך std.crypto.dh.X25519? אין קסם נסתר. אלו שתי פונקציות קצרות שניתן לקרוא אותן במלואן בספרייה הסטנדרטית של Zig עצמה. הראשונה גוזרת את המפתח הציבורי מתוך הפרטי — ה-«gᵃ» של ההחלפה:

pub fn recoverPublicKey(secret_key: [secret_length]u8) IdentityElementError![public_length]u8 {
    const q = try Curve.basePoint.clampedMul(secret_key);
    return q.toBytes();
}

בשפת המאמר: המפתח הפרטי "מוכפל" — במובן האליפטי, לא במובן האריתמטי הבסיסי — בנקודת הבסיס של עקום Curve25519, והתוצאה עוברת סריאליזציה (serialization) לשלושים ושניים בייטים. הפעולה clampedMul היא הגרסה המוקשחת של כפל סקלרי זה: היא משלבת את אמצעי ההגנה שהקהילה הקריפטוגרפית הוסיפה לאורך השנים כדי לעמוד בפני משפחות ידועות של התקפות. שתי שורות של גוף פונקציה.

הפונקציה השנייה משלבת את המפתח הפרטי שלך עם המפתח הציבורי שהצד השני שולח לך. זהו ה-«(gᵇ)ᵃ» של ההחלפה, אשר מייצר את הסוד המשותף של שלושים ושניים בייטים שאף אחד מכם לא שידר מעולם:

pub fn scalarmult(secret_key: [secret_length]u8, public_key: [public_length]u8) IdentityElementError![shared_length]u8 {
    const q = try Curve.fromBytes(public_key).clampedMul(secret_key);
    return q.toBytes();
}

עוד שתי שורות. המפתח הציבורי שהתקבל מפורש כנקודה על העקום, ו"מוכפל" במפתח הפרטי של עצמו. בזכות תכונת החילופיות (commutativity) של פעולת העקום — בדומה לחילופיות של כפל החזקות שראינו בדוגמה המספרית — שני הצדדים מסיימים עם אותה נקודה מסוראלת (serialized): בדיוק הסוד המשותף שעליו מדבר המאמר.

על מה מגנה הצפנה מקצה לקצה

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

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

על מה לא מגנה הצפנה מקצה לקצה

כדאי לדעת זאת באותה מידה. ה-E2EE אינו מגן על מטא-נתונים: השרת עדיין יודע שמשתמש א' שולח נתונים למשתמש ב', באיזו שעה, באיזו תדירות ומאיפה, גם אם הוא לא יודע מה הוא אומר. המטא-נתונים האלה, כפי שכבר טענו ב-להצפין זה לא להיות פרטי, הם לעתים קרובות חושפניים יותר מהתוכן. הידיעה שמישהו התקשר למשרד עורכי דין המתמחה בגירושין ביום שישי בשעה 22:00 למשך שלושים דקות מספרת סיפור שתוכן השיחה מעולם לא סיפר. זהו אותו מצב כמו לראות אדם נכנס ויוצא מספר פעמים ממרפאה אונקולוגית: אין צורך לשמוע דבר ממה שנאמר בפנים כדי לדמיין מה קורה. מטא-נתון בודד עשוי לא לסמל דבר; כמה כאלה מוצלבים ביניהם מציירים משהו שדומה מדי לאמת. ה-E2EE אינו מגן על הקצוות: אם המכשיר של המקבל נפרץ על ידי תוכנה זדונית, ההודעה מפוענחת כרגיל עבור אותו מקבל והתוכנה הזדונית קוראת אותה. ה-E2EE אינו מגן מפני זהות בן השיח כשלעצמה: אם אליס מאמינה שהיא מדברת עם ברונו אך תוקף התערב בהתחלה (man in the middle) והפרוטוקול אינו כולל אימות עצמאי, שני הצדדים מסיימים לדבר עם הפולש במחשבה שהם מדברים זה עם זה.

יש דבר רביעי שכדאי לנסח ללא עמימות. ה-E2EE אינו מונע מספק שטוען שהוא מציע אותו לשמור, בנוסף, עותק של ההודעה ללא הצפנה במערכות שלו. הטענה «ההודעות שלי מוצפנות מקצה לקצה» והטענה «הספק אינו שומר את התוכן שלי» אינן זהות. אפליקציה יכולה לקיים את הראשונה תוך שהיא מפרה את השנייה; ראינו זאת בכותרות העיתונים שוב ושוב מאז 2018. למשתמש, אלא אם כן קוד הלקוח ניתן לאימות, אין דרך טכנית להבחין בין מקרה אחד למשנהו ללא חקירת מומחה. המקרה המוכר ביותר בציבור הרחב: WhatsApp מצפינה את ההודעות מקצה לקצה במעבר, אך אם המשתמש מפעיל את הגיבוי ב-iCloud או ב-Google Drive ללא הצפנה נוספת, העותק הזה נשמר קריא בתשתית של צד שלישי, וההצפנה נשברת בקצה של המשתמש עצמו.

השאלה שהמפעיל לא רוצה לשמוע

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

1. המפתחות נמצאים רק במכשירים. הם נוצרים ונמצאים אך ורק במכשירי המשתמשים; המפעיל אינו מכיר אותם ואינו מאחסן אותם. זהו המקרה האופטימלי.
2. המפעיל יכול לגשת אם הוא רוצה. למפעיל יש את המפתחות של המשתמשים (או שהוא יכול לייצר אותם כרצונו) והוא שומר אותם במסדי הנתונים שלו. אם הוא רוצה או נאלץ, הוא יכול לקרוא את התוכן. זהו המצב ברוב שירותי ה"ענן".
3. המפעיל אינו יכול לגשת לפי התכנון, אך הוא שולט בגישה. למפעיל אין את המפתחות, אך יש לו שליטה על האפליקציה שמייצרת אותם. אם הוא ייאלץ, הוא יכול לשלוח עדכון זדוני שילכוד את המפתחות או את התוכן לפני ההצפנה. זהו המצב בשירותי E2EE מסחריים רבים.

לכן, השאלה המבצעית אינה האם משהו מוצפן, אלא למי יש שליטה על המכשיר ועל התוכנה שמנהלת את המפתחות. ב-Solo2, המפתחות שוכנים אך ורק ב"כספת" שלך (IndexedDB מוצפנת בסיסמה שלך) והתוכנה היא קוד פתוח שניתן לאימות.

לקורא המקצועי

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

1. היכן מיוצרים המפתחות הקריפטוגרפיים והיכן הם שוכנים פיזית? אם למפעיל יש גישה אליהם (אפילו באופן זמני, אפילו תחת מסווה של שחזור), ה-E2EE הוא נומינלי בלבד.
2. האם קיים אימות עצמאי של בן השיח (מספרי אבטחה, קודי QR, השוואה מחוץ לערוץ) שמונע התקפת אדם באמצע (man-in-the-middle) במהלך ביסוס השיחה?
3. האם קוד הלקוח ניתן לביקורת — פתוח, מפורסם, ניתן לשחזור — או שהוא דורש לסמוך על מילת הספק לגבי מה שהלקוח עושה בפועל?
4. אילו מטא-נתונים השירות מייצר ושומר, ולכמה זמן? גם אם התוכן אטום, מטא-נתונים יכולים לשחזר חלק ניכר מהמידע הרגיש.

ארבע השאלות הללו אינן דורשות מידע טכני מתקדם; הן דורשות מידע שכל מפעיל ישר יכול לענות עליו בתיעוד הציבורי שלו. איכות הדיוק של התשובה אומרת על המוצר באותה מידה כמו התשובה עצמה.

---

הצפנה מקצה לקצה, כשהיא נעשית נכון, היא אחת המבנים העדינים ביותר שהקריפטוגרפיה העכשווית העניקה לפרקטיקה היומיומית. הרעיון המקורי — ששני אנשים יכולים להסכים על סוד בערוץ ציבורי — שייך ל-Whitfield Diffie ו-Martin Hellman, 1976; חצי מאה לאחר מכן אנו ממשיכים לחיות בתוצאותיו. אך כפי שקורה עם כל הבטחה טכנית, ערכה תלוי במימוש בפועל, ולא בתווית. שאלתו של איש המקצוע הישר אינה «האם זה מוצפן?», אלא «למי יש את המפתחות?». לתשובות יש השלכות שונות. כדאי לדעת אותן.