מהי הצפנה מקצה לקצה? איך היא מגינה על התמונות שלך
הצפנה מקצה לקצה מרחיקה את תוכן התמונות הקריא ואת מפתחות התוכן הגלויים מספק האחסון.
הצפנה מקצה לקצה (E2EE) היא מודל אבטחה שבו התוכן הגלוי מוצפן בנקודת קצה מורשית אחת ומפוענח בנקודת קצה אחרת. ספק האחסון או ההעברה לא מחזיק את מפתח התוכן הגלוי. הגבול הזה מגן על התוכן מפני קריאה ישירה בצד השרת, אבל הוא לא מסתיר כל פריט מטא-נתונים ולא מגן על נקודת קצה פרוצה, על פרטי שחזור, על נמען משותף או על עדכון לקוח זדוני.
באחסון תמונות, הצפנה מקצה לקצה פירושה שהטלפון מצפין את תוכן התמונות לפני ההעלאה, והענן שומר טקסט מוצפן ולא תמונות קריאות. הפענוח דורש מפתח שזמין דרך מכשיר מורשה או נתיב שחזור. גודל הקבצים, התזמון, נתוני החשבון, קשרי השיתוף ומטא-נתונים אחרים עשויים להישאר גלויים. המדריך הזה מסביר את הגבול ומשווה בין מודלים נפוצים של שירותים.
איך הצפנה מקצה לקצה עובדת
המנגנון המרכזי כולל שלושה שלבים: יצירת מפתח, הצפנה ופענוח.
יצירת מפתח
המכשיר של המשתמש יוצר מפתח קריפטוגרפי. בהצפנה סימטרית (כמו AES-256), אותו מפתח מצפין ומפענח. בהצפנה א-סימטרית (כמו RSA), מפתח ציבורי מצפין ומפתח פרטי מפענח. מערכות E2EE רבות משלבות את שתיהן: הצפנה א-סימטרית מעבירה מפתח סשן סימטרי, והוא מטפל בהצפנת הנתונים עצמם.
אפליקציות כספת תמונות משתמשות בכמה תכנונים של ניהול מפתחות. חלקן גוזרות מפתח קבצים ישירות מסיסמה; תכנונים שכבתיים חזקים יותר יכולים להשתמש במפתח פתיחה שנגזר מפרטי הגישה כדי לעטוף מפתח קבצים אקראי. Vaultaire משתמשת ב-PBKDF2-HMAC-SHA512 כדי לגזור מפתח כספת של 256 ביט מתבנית 5x5 וממלח משותף לכל המכשיר. מפתח הכספת הזה מאמת את האינדקס המוצפן ופותח מפתח ראשי אקראי נפרד שמשמש להצפנת הקבצים.
הצפנה
התוכן הגלוי (התמונה שלך) הופך לטקסט מוצפן בעזרת מפתח ההצפנה ואלגוריתם הצפנה. AES-256-GCM הוא הצופן הסימטרי הנפוץ ביותר למטרה הזאת. GCM (Galois/Counter Mode) מספק הצפנה מאומתת: הוא גם מצפין את הנתונים וגם מפיק תג אימות שמזהה כל שינוי. כל קובץ מקבל וקטור אתחול (IV) ייחודי, כך שקבצים זהים מפיקים טקסט מוצפן שונה.
פענוח
המכשיר של הנמען משתמש באותו מפתח (סימטרי) או במפתח הפרטי התואם (א-סימטרי) כדי להפוך את התהליך. בלי המפתח הנכון, הטקסט המוצפן לא נבדל מנתונים אקראיים. אין קיצור דרך מתמטי. ל-AES-256 יש 2^256 מפתחות אפשריים, יותר מהמספר המשוער של האטומים ביקום הנצפה.
הצפנה מקצה לקצה מול מודלים אחרים של הצפנה
לא כל הצפנה היא מקצה לקצה. ההבדלים קובעים מי יכול לגשת לנתונים שלך.
הצפנה בזמן העברה (TLS/SSL)
הנתונים מוצפנים בין המכשיר שלך לשרת. השרת מפענח אותם כשהם מגיעים. זה מגן מפני האזנה בזמן ההעברה, אבל משאיר את הנתונים קריאים בשרת. כל שירותי הענן הגדולים משתמשים בהצפנה בזמן העברה. זה הבסיס, לא הסטנדרט.
הצפנה במנוחה (בצד השרת)
השרת מצפין את הנתונים השמורים עם מפתחות שהוא מנהל. זה מגן מפני גניבה פיזית של חומרת השרת, אבל לא מפני ספק השירות, העובדים שלו או בקשות משפטיות שמופנות לספק. iCloud, Google Drive ו-Dropbox משתמשים כולם בהצפנה במנוחה בצד השרת. המפתחות אצל הספק.
הצפנה מקצה לקצה
הנתונים מוצפנים בנקודת קצה מורשית לפני שספק האחסון מקבל אותם. תכנון תקין משאיר את מפתח התוכן הגלוי מחוץ לחזקה השגרתית של הספק בצד השרת, כך שפריצה לאחסון בלבד או דרישה משפטית לתוכן השמור מניבות טקסט מוצפן ולא תמונות קריאות. הספק עדיין יכול למסור טקסט מוצפן ומטא-נתונים, להפיץ את תוכנת הלקוח או להפעיל מערכות שחזור ושיתוף, וצריך לכלול את כל אלה במודל האיום.
| מודל הצפנה | מי מחזיק את המפתחות | הספק יכול לקרוא את הנתונים? | מגן מפני הספק? |
|---|---|---|---|
| בזמן העברה בלבד (TLS) | השרת | כן | לא |
| במנוחה (בצד השרת) | השרת | כן | לא |
| מקצה לקצה | נקודות קצה מורשות או מחזיקי השחזור | לא מתוך הטקסט המוצפן השמור לבדו | מגן על התוכן מפני מפתחות אחסון שנמצאים אצל הספק |
| הצפנה בצד הלקוח שהספק לא רואה | הלקוח ונתיבי שחזור מתועדים | אין גישה לתוכן גלוי, לפי התכנון | מגן על התוכן; המטא-נתונים והאמון בלקוח נשארים |
איך שירותי אחסון תמונות מטפלים בהצפנה
מודל ההצפנה משתנה מאוד בין שירותי אחסון התמונות. חלקם מפרסמים ״הצפנה״ בלי לציין את המודל, וזה עלול לגרום למשתמשים להאמין שהתמונות שלהם מוצפנות מקצה לקצה כשהן לא.
תמונות iCloud
Apple משתמשת בהצפנה בזמן העברה ובמנוחה. כברירת מחדל, מפתחות ההצפנה אצל Apple. עם בקשה משפטית תקפה, Apple יכולה למסור נתוני תמונות iCloud. חריג: הגנת הנתונים המתקדמת (ADP) של Apple, שזמינה מדצמבר 2022, מוסיפה הצפנה מקצה לקצה לתמונות iCloud. צריך להפעיל את ADP במפורש בהגדרות. כשהיא מופעלת, Apple לא יכולה לגשת לנתוני תמונות iCloud. רוב המשתמשים לא הפעילו את ADP.
Google Photos
Google משתמשת בהצפנה בזמן העברה ובמנוחה עם מפתחות בצד השרת. מפתחות ההצפנה של כל נתוני Google Photos אצל Google, כולל תוכן התיקייה הנעולה. Google יכולה להיענות לבקשות משפטיות לנתונים. Google לא מציעה אפשרות של הצפנה מקצה לקצה ל-Google Photos.
Dropbox
הצפנה בזמן העברה (TLS 1.2 ומעלה) ובמנוחה (AES-256 עם מפתחות שמנוהלים על ידי Dropbox). המפתחות אצל Dropbox, והיא יכולה לגשת לקבצים שלך. Dropbox כבר נפגעה בפריצות נתונים (2012, 68 מיליון חשבונות). Dropbox Vault (תכונה בתשלום) מוסיפה הגנת PIN, אבל לא הצפנה מקצה לקצה.
OneDrive
Microsoft משתמשת בהצפנה בזמן העברה ובמנוחה עם מפתחות שמנוהלים על ידי Microsoft. המפתחות אצל Microsoft. ה-Personal Vault של OneDrive מוסיף אימות זהות (2FA), אבל לא הצפנה מקצה לקצה: Microsoft עדיין יכולה לגשת לנתונים. ללקוחות ארגוניים זמינים מפתחות שהלקוח מנהל.
Vaultaire
הצפנה בצד הלקוח, בלי מפתחות אצל הספק. Vaultaire מצפינה תמונות ומטא-נתונים במכשיר ב-AES-256-GCM לפני כל העלאה לענן. מפתח ראשי אקראי מצפין את נתוני הכספת. מפתח כספת מקומי, שנגזר מהתבנית של המשתמש ומממלח המכשיר, עוטף את המפתח הראשי, ומפתח גיבוי נפרד שנגזר מהתבנית מגן על רשומות גיבוי פרטיות ב-CloudKit. Vaultaire לא מפעילה שרת תוכן ולא מקבלת את המפתחות האלה, ולכן היא לא יכולה להפוך רשומת CloudKit לתוכן גלוי. האפליקציה, iOS ומכשיר פתוח נשארים בתוך גבול האמון, ובקשה משפטית עדיין יכולה להשיג מטא-נתונים של חשבון או שירות שנמצאים אצל הספק הרלוונטי.
| שירות | הצפנה בזמן העברה | הצפנה במנוחה | הצפנה מקצה לקצה | הספק יכול לגשת |
|---|---|---|---|---|
| תמונות iCloud (ברירת מחדל) | כן | כן (מפתחות של Apple) | לא | כן |
| תמונות iCloud (עם ADP) | כן | כן | כן | לא |
| Google Photos | כן | כן (מפתחות של Google) | לא | כן |
| Dropbox | כן | כן (מפתחות של Dropbox) | לא | כן |
| OneDrive | כן | כן (מפתחות של Microsoft) | לא | כן |
| Vaultaire | כן | כן | גיבוי מוצפן בצד הלקוח, פועל כברירת מחדל | אין מפתח תוכן גלוי; מטא-נתונים של CloudKit נשארים |
למה הצפנה מקצה לקצה חשובה לתמונות
תמונות הן נתונים רגישים במיוחד. הן כוללות פנים, מיקומים (מטא-נתוני GPS), חותמות זמן ותיעוד חזותי של רגעים פרטיים. פריצה לספריית התמונות חושפת יותר מידע אישי כמעט מכל סוג נתונים אחר.
פריצות נתונים
כשספק שירות שומר תמונות עם מפתחות בצד השרת, פריצה גם לאחסון וגם לנתיב ניהול המפתחות שלו עלולה לחשוף תוכן קריא. עם E2EE תקינה, פריצה לאחסון בלבד מניבה טקסט מוצפן ואת המטא-נתונים שהשירות שומר. פריצה לנקודת קצה, פרטי שחזור גנובים, תוכנת לקוח זדונית ופגמים בשירות המפתחות נשארים נתיבים נפרדים לתוכן הגלוי.
גישה משפטית וממשלתית
אפשר לחייב ספקי שירות למסור רשומות שנמצאות ברשותם. עם E2EE, הן עשויות לכלול טקסט מוצפן, פרטי חשבון, יומני גישה, גודלי רשומות, תזמון ומטא-נתוני שיתוף, ולא תוכן תמונות קריא. השאלה אם דרישה יכולה להגיע למכשיר, לשיטת שחזור, לנמען או להתנהגות עתידית של הלקוח היא שאלה משפטית וטכנית אחרת.
גישה פנימית
עובדים או תוקפים שיש להם גישה למפתחות אחסון שהספק מנהל עשויים להגיע לתוכן שמוצפן בצד השרת. E2EE מסירה את נתיב מפתחות האחסון הישיר הזה כשאין לספק מפתחות תוכן גלויים. היא לא הופכת שימוש לרעה מבפנים לבלתי אפשרי לחלוטין, כי ספקים עשויים לשלוט בהפצת הלקוח, במצב החשבון, במטא-נתונים, בשיתוף או ברכיבי השחזור.
הגנה על מטא-נתונים
חלק ממימושי E2EE מצפינים רק את תוכן הקבצים ומשאירים מטא-נתונים כמו שמות קבצים ותאריכים בלי הגנה. Vaultaire מגינה על כותרות הקבצים, סוגי MIME, אינדקסים, תמונות ממוזערות ומטא-נתונים אחרים של הכספת בהצפנה מאומתת ב-AES-256-GCM. אורכי הטקסט המוצפן השמור ומספר קובצי האחסון המוצפנים עדיין יכולים לחשוף מידע מבני למי שיש לו גישה למכל האפליקציה, למשל הערכה של כמה כספות מכילות קבצים.
טעויות נפוצות לגבי E2EE
״האחסון שלי בענן מוצפן, אז התמונות שלי בטוחות.״ הצפנה בצד השרת מגינה מפני פריצות חיצוניות לחומרת השרת. היא לא מגינה מפני הספק עצמו, מפני בקשות משפטיות או מפני איומים פנימיים. המפתחות אצל הספק.
״HTTPS אומר שהתמונות שלי מוצפנות מקצה לקצה.״ HTTPS (TLS) מצפין נתונים בזמן ההעברה בין המכשיר שלך לשרת. כשהנתונים מגיעים לשרת, הם מפוענחים. HTTPS מצפין את הצינור, לא את הנתונים.
״הצפנה מקצה לקצה אומרת שאף אחד לא יוכל לראות את התמונות שלי לעולם.״ E2EE אומרת שמי שאין לו את המפתח לא יכול לראות את התמונות. אם למישהו יש את הסיסמה או את המפתח שלך, הוא יכול לפענח את הנתונים. ניהול מפתחות וסיסמאות חזקות עדיין חיוניים.
״Apple ו-Google לא יכולות לראות את התמונות שלי.״ כברירת מחדל, מפתחות ההצפנה של התמונות שלך בענן נמצאים אצל שתי החברות. Apple מציעה את הגנת הנתונים המתקדמת כאפשרות שצריך להפעיל. Google לא מציעה בכלל אפשרות E2EE ל-Google Photos.
איך Vaultaire מממשת הצפנה מקצה לקצה
Vaultaire משתמשת בגישת E2EE שכבתית:
- AES-256-GCM מצפין את כל תוכן הקבצים. כל קובץ מקבל וקטור אתחול ייחודי. ההצפנה המאומתת מזהה שינויים.
- PBKDF2 עם HMAC-SHA512 גוזר מפתח כספת מקומי מהתבנית שהמשתמש צייר ומממלח המכשיר. פקטור העבודה מעלה את העלות של כל ניחוש לא מקוון, בלי להוסיף אנטרופיה לתבנית. מפתח הכספת הזה מאמת את האינדקס המוצפן ופותח את המפתח הראשי האקראי שמשמש לנתוני הקבצים.
- AES-256-GCM למטא-נתונים מגן על שמות קבצים, תאריכים, מידות, אינדקסים ותמונות ממוזערות בהצפנה מאומתת.
- Keychain של iOS והגנת הנתונים מגינים על ממלח המכשיר ועל מסד נתוני השחזור המוצפן. פעולות AES-GCM ומפתחות סימטריים פעילים נשארים בתהליך האפליקציה כשכספת פתוחה.
- הפרדה ממפתחות הספק פירושה ש-Wraxle לא מקבלת מפתח כספת, מפתח ראשי, מפתח גיבוי או מפתח שחזור גלויים. גיבוי CloudKit (פועל כברירת מחדל), הסנכרון והשיתוף שומרים רשומות של טקסט מוצפן ומעטפות מפתחות מוצפנות, ו-Apple עדיין יכולה לראות מטא-נתונים של השירות. Vaultaire לא דורשת חשבון זהות של Vaultaire.
Vaultaire שומרת את מידע השחזור, כולל התבנית, בתוך מסד נתונים שמוצפן ב-AES-GCM ונשמר ב-Keychain של iOS. הוא לא נכתב לקבצים גלויים ולא נשלח לשירות חשבונות של Vaultaire. אם לא נשארו תבנית שמישה, ביטוי שחזור או מכשיר שכבר פתוח, ל-Vaultaire אין מפתח שחזור של הספק שיכול להחזיר את הגישה.
שאלות נפוצות
האם הצפנה מקצה לקצה חוקית?
היחס המשפטי להצפנה, לגישה בכפייה ולשירותים מוצפנים משתנה בין תחומי שיפוט ויכול להשתנות עם הזמן. המדריך הזה מתאר את המודל הטכני ואינו ייעוץ משפטי. בדוק את החוק המקומי העדכני אם השימוש שלך כולל חיפושים במעברי גבול, צווי בית משפט, רשומות מפוקחות או כל מצב אחר בסיכון גבוה.
האם רשויות אכיפת החוק יכולות לשבור הצפנה מקצה לקצה?
תקיפות צריכות לעיתים רחוקות לחפש בכל מרחב המפתחות של AES-256. בודק פורנזי יכול לכוון לסיסמה או לתבנית חלשות, לנקודת קצה פתוחה, לזיכרון, לביטוי שחזור, לנמען, לגיבוי או לפגם במימוש. AES-256-GCM שמומש כראוי עם מפתח אקראי בעל אנטרופיה גבוהה תוכנן לעמוד בחיפוש מפתחות ישיר, אבל זה רק חלק אחד מהמערכת.
מה ההבדל בין E2EE להצפנת zero-knowledge?
E2EE מתארת איפה מתבצעות ההצפנה והפענוח של התוכן הגלוי ומי מחזיק מפתחות תוכן שמישים. ״zero-knowledge״ משמש לעיתים קרובות בשיווק מוצרים להצפנה שהספק לא רואה, אבל לא כדאי לקרוא אותו מילולית: שירות יכול להיות בלי מפתחות גלויים ועדיין לראות טקסט מוצפן, נתוני חשבון, גדלים, תזמון, קשרי שיתוף ומטא-נתונים אחרים. העריך את נתיבי המפתחות והשחזור המתועדים, ולא רק את התווית.
האם הצפנה מקצה לקצה מאטה את הטלפון?
מכשירים מודרניים מטפלים ב-AES-256 ביעילות בעזרת האצת חומרה שנחשפת דרך הספריות הקריפטוגרפיות של המערכת. באייפון, Vaultaire מבצעת AES-GCM בתהליך האפליקציה דרך CryptoKit. ממשקי ה-Secure Enclave הציבוריים של Apple אינם מנוע AES-GCM כללי להצפנת קבצים. התקורה של ההצפנה והפענוח תלויה בגודל הקובץ ובמכשיר, אבל היא תוכננה לא להפריע בשימוש רגיל.
מה קורה אם אני מאבד את מפתח ההצפנה?
אובדן כל נתיבי הפענוח והשחזור השמישים הופך נתונים מוצפנים לבלתי ניתנים לשחזור. לכן מערכות E2EE רבות משתמשות בביטויי שחזור, במכשירים מהימנים, באנשי קשר לשחזור, בערכות חירום או במעטפות מפתחות מוצפנות. המנגנונים האלה שומרים על הגישה, אבל כל אחד מהם הופך גם לחלק ממודל האבטחה.
השורה התחתונה
הצפנה מקצה לקצה יכולה להסיר את נתיב המפתח הגלוי של ספק האחסון כשההצפנה מתבצעת בנקודת קצה מורשית לפני ההעלאה. זו הגנה משמעותית, לא ערובה לגבי המערכת כולה. בדוק את האחריות על מפתח התוכן, את השחזור, את המטא-נתונים, את עדכוני הלקוח, את אבטחת נקודות הקצה ואת השיתוף לפני שאתה מפקיד תמונות פרטיות בידי שירות.
Vaultaire מממשת הצפנה בצד הלקוח ל-iOS. התמונות ומטא-נתוני הכספת מוצפנים במכשיר ב-AES-256-GCM לפני גיבוי או סנכרון. Vaultaire לא מקבלת את מפתחות הפענוח ולא מפעילה שרת שיכול להפוך את הרשומות המוצפנות האלה לתמונות שלך. הגבול הזה מול הספק לא הופך אייפון פרוץ או פתוח לאמין.