עצרתם לחשוב מה קורה עם כל המידע שהרכב שלכם מצלם ואוסף?

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

לקח שלמדנו עוד מפרשת Apple וה-FBI (תמונה מעובדת: Dreamstime)

מאת רני ירושינסקי

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

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

מה זה E2EE ולמה זה כל כך קריטי?

המונח End-to-End Encryption, או בקיצור E2EE, פירושו שהמידע מוצפן כבר בקצה השולח ונשאר מוצפן עד שהוא מגיע לקצה המקבל. השרתים שבאמצע רואים רק ביטים מוצפנים, וגם אם מישהו פורץ אליהם, הוא מקבל לכל היותר ג'יבריש.

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

יישום E2EE למצלמות הרכב מבטיח שהמפתח לפענוח הווידאו קיים רק בשני מקומות: ברכב עצמו ובטלפון המורשה של בעל/ת הרכב (או מי שהוסמך על ידי בעל/ת הרכב). המשמעות היא שצד השרת של GM רואה רק וידאו מוצפן, כך שגם אם יש גישה למידע, אי אפשר לפענח אותו בלי המפתח. למעשה, E2EE מחזיר לבעל הרכב שליטה על אחד הנכסים הרגישים ביותר בעידן המידע: איך, מתי ועל ידי מי נעשה שימוש בתיעוד החזותי של חייו.

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

אתגרי האימות בעולם שבו לא סומכים על ה-Backend

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

אחד האתגרים בהגנה על פרטיות הלקוח הוא אימות. למה האימות כל כך מאתגר? ברכב מחובר יש שני קצוות “אמיתיים”: הרכב, והטלפון של הבעלים שמחובר לאפליקציית MyBrand/OnStar (אפליקציות של GM המאפשרות מגוון פעולות ומידע דרך הנייד). כדי לאפשר E2EE צריך לבסס ביניהם מפתח סימטרי משותף – SK (Symmetric Key). הבעיה היא שאין ביניהם ערוץ ישיר, כי כל המסרים עוברים דרך שרתי GM. מבחינה קריפטוגרפית, זה נראה כמו שני צדדים שמנסים לבצע חילוף מפתחות דרך מתווך לא אמין. ברירת המחדל הפשוטה – “נעביר את המפתח דרך השרת ונקווה שאין מתחזה בדרך” – לא עומדת בשום מודל איום סביר.

שכבת ההגנה הראשונה היא שימוש ב-Elliptic Curve Diffie-Hellman (או בקיצור, ECDH). כל צד מייצר זוג מפתחות זמני: המפתחות הציבוריים (Public Keys) כן עוברים ברשת (בגלוי), אך המפתח הפרטי נשאר מקומי. ה-Shared Secret הוא זה שלא עובר ברשת, אלא מחושב בשני הקצוות.

אבל ECDH לבדו לא פותר את בעיית ה-Man in The Middle: אם השרת יכול להכניס מפתחות משלו, הוא גם יכול לבצע שני חילופי מפתחות נפרדים ולהעמיד פנים שהוא הרכב מול המובייל (התחזות), ולהפך. כדי לנטרל את זה נדרש מנגנון אימות הדדי חזק – Attestation ברמת המכשיר והאפליקציה. במילים אחרות, לכל צד חייב להיות Primitive קריפטוגרפי שמאפשר לו לוודא שהמפתח שקיבל מחובר למכשיר פיזי בעל זהות ידועה, ולא לאלמנט שרירותי בענן.

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

• שליטה מרכזית על ניהול מפתחות ומכשירים, שמאפשרת תרחישים תיאורטיים שבהם שרת זדוני ינסה להחדיר מפתח חדש למכשיר יעד (טכניקה שנקראת key injection).
• יכולת תיאורטית של השרת להוסיף לשיחה Ghost user ולשכפל אליו תעבורה.

אז למדנו את השיעור, והחלטנו לממש פרוטוקול שדורש קרבה – בדומה לפרוטוקול ה-Bluetooth בצימוד ראשוני של הנייד.

הפתרון: Pairing בקרבה פיזית + PAKE

הפתרון שבנינו מבוסס על רעיון פשוט למשתמש, וקשה מאוד לתקיפה:

1. Pairing בקרבה פיזית

בתהליך האתחול של המשתמש החדש, אחרי העברת הבעלות על הרכב, שמטרתו לייצר מפתח בין הקצוות (רכב, נייד). על מסך הרכב מוצג QR code או PIN חד-פעמי, והאפליקציה סורקת או מקלידה. אף אדמין לא יכול לדמות מצב שבו הוא פיזית בתוך הרכב. שתי האופציות גם מאפשרות לבעל הרכב לשלוח מישהו מטעמו שיקבל צילום או תמונה של הקוד בערוץ צד (OOB) שאינו מנוהל על ידי GM, וכך לשמור על ערוץ אימות חסוי.

2. PAKE – PACE/CPACE – balanced, composable Password Authenticated Key Exchange
ברקע, המערכת משתמשת במשפחת הפרוטוקולים PAKE (Password Authenticated Key Exchange), ובפרט ב-CPACE (balanced, composable PAKE) – אחת הטיוטות המתקדמות של התקן. הרעיון – באמצעות סיסמה חלשה כמו PIN בן 6 ספרות, אפשר להשתמש בה כדי להגן על החלפת המפתח מפני גורם עוין המאזין לתעבורה או מנסה להתערב בה (MITM). יחד עם הגבלת מספר הניסיונות, אנחנו יכולים להגן בהסתברות גבוהה מפני ניסיון התחזות.

בשלב זה, כל צד (רכב ומובייל) מייצר מפתחות ECDH זמניים, אבל כל החישוב נעשה בתוך הקשר שכולל את ה-PIN, מזהה הרכב (VIN), סוג המכשיר ועוד. ה-PIN עצמו אף פעם לא עובר בערוץ, אלא משמש קלט לפונקציה שמגדירה את נקודת ההתחלה על העקום האליפטי. כך, גם מי שמקליט את כל התעבורה המוצפנת לא יכול לבצע Brute‑force לא מקוון על הסיסמה.

3. ECDH בלי ערוץ סודי
היישום הקלאסי של Diffie‑Hellman מניח קיום של ערוץ חסוי לצד השני – כגון תעודה חתומה, או ערוץ צד שבו אנחנו נותנים אמון. בעולם שלנו אין ערוץ כזה, וזאת בדיוק הבעיה ש-PAKE פותר – הוא ממיר סיסמה משותפת חלשה (ה-PIN שהמשתמש רואה על המסך) למנגנון אימות קריפטוגרפי, שמבטיח שרק מי שרואה את המסך של הרכב וגם מחזיק במכשיר המורשה יוכל להשלים את הפרוטוקול.

התוצאה: גם אם אדמין זדוני מנסה להתחזות לאחד הקצוות, הוא לא יכול לייצר לעצמו מפתח סימטרי מקביל מבלי להיות פיזית ברכב ולראות את ה-QR/PIN. המערכת נשענת על הקרבה לרכב והבעלות עליו, ולא על אמון ביושרה של הארגון או של תשתיות הענן.

בנוסף, יש כאן מורכבות ארכיטקטונית לא טריוויאלית: הפרוטוקול חייב לרוץ בצורה עקבית על שלושה גורמים שונים – מובייל, רכב וצד שרת/ענן – שכל אחד מהם מפותח בסטאק טכנולוגי אחר ובסט אילוצים שונה (משאבי CPU ,latency, יכולת עדכון גרסה ועוד). התכנון כולל דרישה להפרדה בין החלק הקריפטוגרפי הטהור לבין שכבות ה-Transport וה-UX, כך שלא יווצרו הבדלי התנהגות בין הפלטפורמות.

פתרון שיעבוד גם עם סוכני AI

פרוטוקול ה-E2EE שתואר כאן לא נבנה רק עבור מצלמות. הכוונה שלנו היא להשתמש באותו עקרון Pairing ו-Key Distribution (PKD) לכל השירותים שדורשים רמת אבטחה גבוהה: פתיחת/נעילת רכב מרחוק, התנעה, שיתוף מידע טלמטרי עם מוסכים ומבטחים ועוד. במקום שכל שירות ימציא לעצמו מודל הרשאות, כולם יישענו על אותה שכבת בסיס של מפתחות מוצפנים הקשורים לרכב ולניידים המורשים.

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

כאשר ה-E2EE מלווה בהצפנת מפתחות חזקה בצד המכשירים (Keystore בנייד, TEE ברכב), נוצר גבול ברור: הסוכן יכול לפעול רק במסגרת מה שהבעלים מסכים לחשוף מקומית. הענן – כולל מודלי ה-AI עצמם – לא רואים את החומר הגולמי.

מבחינה פרקטית, אותם מפתחות משמשים גם ל-Live View (צפייה חיה ממצלמות הרכב) וגם ל-Event Recording (העלאת הקלטות אירוע לענן). הווידאו מוצפן כבר ברכב, נשלח כ-Blob מוצפן לענן, ומפוענח רק במובייל המורשה. גם אם בעתיד נוסיף שכבות אנליטיקה, הן יוכלו לרוץ בצורה מבוקרת בקצה – ולא להפוך את הרכב שלכם לעוד מצלמת מעקב ציבורית.

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

האתגרים שעוד צריך לפתור

מבלי להיכנס לקוד ולדיאגרמות, חשוב להבין ש-CPACE עצמו הוא פרוטוקול PAKE אלגנטי, אך תובעני מאוד מבחינת יישום. ברמה הקריפטוגרפית הוא דורש מימוש מדויק של Hash‑to‑curve שמייצר נקודות אחידות על העקום בלי הטיה; ברמת הקוד הוא מחייב ביצוע ב-Constant‑time, ללא Branching או Access שתלויים בסיסמה; ארכיטקטונית צריך להבטיח RNG (Random Number Generator) חזק ועמיד לקליפטוגרפיה (כולל ערבוב בין מספר מקורות אנטרופיה); ולבסוף, חייבים לנהל Transcript hashing ותצורות Cipher suites בצורה קפדנית, כך שכל פרמטר של הסשן נכלל בקונטקסט החתום ומונע מתקפות של Mis‑binding או Downgrade.

ה-E2EE הוא רק תשתית מאפשרת. יישום בפועל של הצפנה מקצה לקצה מעל Live stream או מעל הקלטות שמורות הוא אתגר בפני עצמו, שלא נתמך באמצעים הסטנדרטיים (נשאיר לכם לשער מדוע). אתגרים נוספים כוללים התמודדות עם מתקפות מסוג Replay Attack או שיבושים מכוונים של מערכות הרכב – ועל כל אלו נרחיב בכתבות הבאות.