מהי הצפנת zero-knowledge? מדריך פשוט
הצפנת zero-knowledge פירושה שהספק לא יכול לגשת לנתונים שלך.
הצפנת zero-knowledge היא ארכיטקטורה שתחומה מול הספק, שבה השירות לא מחזיק את המפתח שדרוש כדי לפענח את תוכן המשתמש השמור. בניגוד להצפנה רגילה בענן, שבה הספק שולט במפתח התוכן, הצפנה בצד הלקוח יכולה להשאיר את היכולת הזאת במכשירי המשתמש. בקשה משפטית, פריצה או גורם פנימי עדיין יכולים לחשוף טקסט מוצפן, רשומות חשבון, נתוני תעבורה או מטא-נתונים אחרים שהספק שומר. ההנחיות של NIST לניהול מפתחות שמות את האחריות על המפתחות במרכז שאלת הגישה, אבל אפליקציית הלקוח, מערכת ההפעלה והמכשיר הפתוח נשארים חלק מגבול האמון.
איך הצפנת zero-knowledge עובדת
האנלוגיה הפשוטה ביותר: כספת במלון שרק אתה קובע את הצירוף שלה, והמלון אף פעם לא לומד אותו. אם שכחת את הצירוף, המלון לא יכול לפתוח לך את הכספת. זה לא פגם בתכנון. זה התכנון.
במונחים טכניים, הצפנת zero-knowledge עובדת בשלושה שלבים:
גזירת מפתח במכשיר. המשתמש מספק פרט גישה כמו סיסמה, משפט סיסמה או תבנית. פונקציית גזירת מפתח מבוססת סיסמה משלבת אותו עם ממלח כדי ליצור מפתח במכשיר של המשתמש. תכנון עם הפרדה טובה יכול להשתמש במפתח הזה כדי לפתוח מפתח הצפנת תוכן אקראי, במקום להצפין כל קובץ ישירות עם פרט הגישה האנושי.
הצפנה לפני שליחה. כל הנתונים מוצפנים במכשיר עם המפתח הנגזר לפני שהם יוצאים ממנו לאחסון בענן או לגיבוי. מה שעולה לענן הוא הפלט המוצפן (הטקסט המוצפן).
הספק לא מקבל מפתח תוכן גלוי. מפתחות תוכן קיימים בהכרח בזיכרון הלקוח בזמן השימוש, ועשויים להישמר גם מקומית או מרחוק בתוך מעטפות מוצפנות מאומתות. הספק יכול לשמור טקסט מוצפן ומפתחות עטופים בלי להחזיק את סוד המשתמש שדרוש כדי לפתוח אותם. מטא-נתונים של חשבון, תעבורה, גודל רשומות ותזמון עדיין עשויים להיות גלויים.
המגבלה הקריטית: אם המשתמש מאבד את כל פרטי הגישה התקפים ואת כל נתיבי השחזור, התוכן המוצפן הופך לבלתי נגיש. שחזור עדיין יכול להתקיים, אבל צריך להסביר מי אחראי על המפתחות שלו. אם איפוס במייל לבדו מחזיר תוכן קריא, בלי אישור ממכשיר ישן, ביטוי שחזור, מפתח שחזור או סוד מקביל שנמצא אצל המשתמש, הספק שמר לעצמו דרך אפקטיבית חזרה לתוכן הגלוי.
הצפנת zero-knowledge מול סוגי הצפנה אחרים
המונח ״הצפנה״ מופיע בחומרי השיווק של כמעט כל שירות ענן. ההבדלים בין הסוגים משמעותיים.
| סוג | מי מחזיק את המפתח | הספק יכול לקרוא את הנתונים | שורד פריצה אצל הספק | דוגמה |
|---|---|---|---|---|
| ללא הצפנה | לא רלוונטי | כן | לא | Dropbox (מסלול רגיל) |
| הצפנה בזמן העברה (TLS) | הספק | כן (במנוחה בשרתים שלו) | לא | Google Photos |
| הצפנה במנוחה בצד השרת | הספק | כן (הוא מחזיק את מפתח הפענוח) | חלקית (תלוי בהיקף הפריצה) | iCloud (רגיל) |
| הצפנה מקצה לקצה של הפלטפורמה | מכשירי הלקוח ומערכת שחזור החשבון | לא דרך נתיב השירות הרגיל | תלוי בלקוח, בשחזור ובחשיפת המטא-נתונים | iCloud עם הגנת נתונים מתקדמת |
| הצפנה בצד הלקוח שהספק לא רואה | הלקוח ונתיב שחזור בשליטת המשתמש | אין מפתח תוכן גלוי אצל הספק | התוכן יכול להישאר מוצפן; מטא-נתונים וטקסט מוצפן עדיין עלולים לדלוף | מערכות כספת וגיבוי מוצפנות |
ההבחנה בין ״הצפנה במנוחה״ ל״הצפנת zero-knowledge״ היא הנפוצה ביותר בבלבול. בהצפנה במנוחה, הספק מצפין את הנתונים בשרתים שלו עם מפתחות שהוא שולט בהם. זה מגן מפני גניבה פיזית של חומרת השרת. זה לא מגן מפני קריאת הנתונים על ידי הספק, מפני צו ממשלתי לנתונים ולמפתחות או מפני איום פנימי. יכולת הפענוח נמצאת אצל הספק.
בהצפנה בצד הלקוח שהספק לא רואה, השירות לא מקבל את מפתח התוכן הגלוי דרך הפרוטוקול המתועד. טקסט מוצפן שמור יכול להישאר אטום לספק, אבל תוכנת הלקוח, נתיב השחזור, מטא-נתוני החשבון וערוץ אספקת התוכנה עדיין דורשים אמון ובדיקה.
למה הצפנת zero-knowledge חשובה
פריצות נתונים חושפות מיליארדי רשומות בכל שנה
ה-Identity Theft Resource Center דיווח על 3,205 אירועי פגיעה בנתונים בארצות הברית ב-2023, שהשפיעו על כ-353 מיליון אנשים. כשהספק מחזיק את מפתחות התוכן, פריצה אחת עלולה לחשוף גם את הנתונים השמורים וגם נתיב לפענח אותם. הצפנה שהספק לא רואה מפרידה בין הנכסים האלה: פריצה לשרת עדיין עלולה לחשוף טקסט מוצפן ומטא-נתונים, אבל לא מפתח תוכן גלוי שנמצא אצל הספק. ניחוש פרטי גישה ופריצה ללקוח נשארים סיכונים נפרדים.
כפייה משפטית היא איום אמיתי
אפשר לחייב ספקים למסור נתונים שהם שומרים. תכנון שבו הספק לא רואה את התוכן יכול להגביל את המסירה לטקסט מוצפן ולמטא-נתונים זמינים של חשבון, תעבורה, חיוב או שירות, כי הספק לא מחזיק את מפתח התוכן הגלוי. השאלה אם גורם אחר יכול להשיג את פרטי הגישה של המשתמש, לנצל חולשה בלקוח או לחייב מסירת מידע היא שאלה נפרדת. Apple הציגה את הגנת הנתונים המתקדמת ב-iOS 16.2 כהרחבה אופציונלית של ההצפנה מקצה לקצה לנתוני iCloud.
״סמוך עלינו״ היא לא ארכיטקטורת אבטחה
הצפנה בצד השרת נשענת על מפתחות ומדיניות בשליטת הספק. הצפנה שהספק לא רואה משנה את האחריות על המפתחות, כך שבנתיב השירות המתועד אין מפתח תוכן גלוי. זה גבול ארכיטקטוני חזק יותר, אבל כוחו עדיין תלוי בקוד לקוח נכון, באספקת תוכנה מאומתת, בשחזור תקין, במכשירים מאובטחים ובמימוש שתואם את המפרט.
תקן NIST שמאחורי הקריפטוגרפיה
AES-GCM תוקנן על ידי המכון הלאומי לתקנים וטכנולוגיה (NIST) ב-SP 800-38D (2007). AES עצמו נבחר על ידי NIST בתחרות פומבית ב-2001. ה-״256״ ב-AES-256 מתייחס למפתח של 256 ביט. חיפוש ממצה על מפתח אקראי אחיד אינו אפשרי חישובית, אבל סיסמה או תבנית שאדם בחר יכולות לספק הרבה פחות אנטרופיה, גם כשפונקציית גזירת המפתח מוציאה 256 ביט.
GCM (Galois/Counter Mode) מוסיף הצפנה מאומתת, כלומר תהליך הפענוח מזהה כל שינוי בטקסט המוצפן. אם אפילו ביט אחד בנתונים המוצפנים שונה, הפענוח נכשל במקום להפיק פלט פגום. זה מונע מתוקפים לשנות נתונים מוצפנים בלי שיתגלו.
PBKDF2 (Password-Based Key Derivation Function 2), שמוגדר ב-RFC 8018, ממיר פרט גישה שאדם סיפק לחומר מפתח באורך קבוע באמצעות קריאות חוזרות לפונקציה פסאודו-אקראית. יותר איטרציות מעלות את העלות של כל ניחוש. הן לא מוסיפות אנטרופיה לתבנית או לסיסמה צפויות, ולכן בחירת פרטי הגישה והאימות הלא מקוון עדיין חשובים.
איך Vaultaire מממשת הפרדה ממפתחות הספק
Vaultaire היא כספת עם הצפנה בצד הלקוח לאייפון. במובן המוצרי שמשווקים לעיתים קרובות כ-״zero knowledge״, הטענה המתועדת והמצומצמת יותר שלה היא ש-Wraxle לא מקבלת תוכן כספת גלוי או את המפתחות שדרושים כדי לפענח אותו. כך המימוש וגבולות האמון שנשארים עובדים בכל שכבה.
גזירת מפתח. המשתמש מצייר תבנית על רשת 5x5 של 25 נקודות. PBKDF2-HMAC-SHA512 משלב את הרצף הזה עם ממלח Keychain אחד שמשותף לכל המכשיר, ב-600,000 איטרציות, כדי לגזור מפתח כספת של 256 ביט. מפתח הכספת מאמת את האינדקס המוצפן ועוטף מפתח ראשי אקראי נפרד של 256 ביט. מידע השחזור, כולל התבנית, נשמר במסד נתונים של Keychain שמוצפן ב-AES-GCM, ולא בקבצים גלויים או בחשבון Vaultaire.
הצפנת קבצים. כל קובץ מיובא מוצפן ב-AES-256-GCM תחת המפתח הראשי האקראי. CryptoKit יוצר קופסאות חתומות מאומתות עם nonce חדש, ופורמט הזרימה גוזר nonce נפרד לכל מקטע לפי הסדר.
הצפנת מטא-נתונים. שמות קבצים, סוגי MIME, תאריכים, רשומות אינדקס ונתוני תמונות ממוזערות מוגנים גם הם ב-AES-256-GCM. Vaultaire לא משתמשת ב-ChaCha20 למטא-נתוני הכספת.
ניהול מפתחות. Vaultaire שומרת את ממלח המכשיר ואת מסד נתוני השחזור המוצפן כפריטי סיסמה גנריים רגילים ב-Keychain של iOS, מוגנים במחלקת הנגישות WhenUnlockedThisDeviceOnly. מפתחות כספת שנגזרו מהתבנית ומפתחות ראשיים אקראיים מעובדים בזיכרון האפליקציה דרך CryptoKit. נעילה מוחקת את מצב המפתחות הפעיל, אבל Swift ו-iOS לא מאפשרים להבטיח שכל עותק זמני נדרס.
גילוי כספות. הממשק הרגיל לא מציג רשימת כספות. הדפים של כל הכספות נמצאים בתיקייה אחת בשמות אקראיים, כך ששמות הקבצים לא מראים לאיזו כספת שייך כל קובץ, והם לא חושפים תבניות, שמות או תוכן גלוי. מי שיש לו גישה למכל האפליקציה עדיין יכול להעריך כמה כספות יש לך, כי מספר ה-arenas של האחסון מגביל את המספר הזה. ראה את ארכיטקטורת האבטחה המלאה ואת ההסבר על הצפנת התבנית.
איך לדעת אם אפליקציה משתמשת בהצפנת zero-knowledge אמיתית
התחל בשלוש בדיקות מהירות, ואז אמת את הארכיטקטורה שפורסמה:
בדיקת ״שכחתי סיסמה״. אם איפוס במייל לבדו מחזיר נתונים קריאים, שאל איזה מנגנון שנמצא אצל הספק שחזר את מפתח התוכן בפועל. ביטויי שחזור שנמצאים אצל המשתמש, אישור ממכשיר ישן ואיפוס בשליטת הספק הם תכנונים שונים.
בדיקת המכשיר החדש. אם מכשיר חדש משחזר תוכן קריא, זהו את הסוד או את המכשיר המהימן שאישר את זה. התחברות לחשבון לבדה מרמזת על נתיב שחזור בשליטת הספק; ביטוי שחזור יחד עם רשומות גיבוי מוצפנות יכולים לשמור על ההפרדה ממפתחות הספק.
בדיקת החשבון. כתובת מייל או מספר טלפון מקשרים זהות למטא-נתוני השירות, אבל הם לבדם לא מוכיחים שהספק יכול לפענח תוכן. בדוק את היררכיית המפתחות, את תכנון השחזור, את קוד הלקוח או ביקורת עליו, את מדיניות המטא-נתונים, והאם טקסט מוצפן מאומת מאפשר בדיקת פרטי גישה במצב לא מקוון.
הבדיקות האלה הן מסננות, לא הוכחת אבטחה. מפרט קוהרנטי צריך לציין את מפתח התוכן, את מפתח הפתיחה, את הממלחים, את פרמטרי הגזירה, את פורמט ההצפנה המאומתת, את כללי ה-nonce, את מעטפות השחזור, את אחסון הסודות המקומי, את מטא-נתוני הענן ואת הנקודה שבה קיימים מפתחות גלויים. בדיקה עצמאית היא ראיה חזקה יותר מתווית מוצר.
שאלות נפוצות
האם הצפנת zero-knowledge זהה להצפנה מקצה לקצה?
יש ביניהן חפיפה, אבל הן לא זהות. הצפנה מקצה לקצה (E2EE) פירושה שהנתונים מוצפנים במכשיר השולח ומפוענחים רק במכשיר הנמען. הצפנת zero-knowledge פירושה שהספק לא יכול לגשת לנתונים. שירות יכול להיות מוצפן מקצה לקצה בלי להיות zero-knowledge, אם הספק יצר את המפתחות או שיש לו גישה אליהם בשלב כלשהו. הצפנת zero-knowledge היא הסטנדרט המחמיר יותר.
מה קורה אם אני מאבד את הסיסמה בהצפנת zero-knowledge?
הנתונים שלך הופכים לבלתי נגישים לתמיד אם כל פרטי הגישה התקפים וכל מעטפות השחזור אובדים. איפוס בשליטת הספק או מפתח ראשי היו מחלישים את הגבול מול הספק, ולכן צריך לתכנן את השחזור בנפרד. Vaultaire יוצרת ביטוי ייעודי בן תשע מילים, ומפתח השחזור שנגזר ממנו פותח מעטפה מוצפנת של מפתח הכספת. הביטוי לא יוצר מחדש את המפתח ולא מקודד אותו, ושחזור במכשיר חדש דורש גם את רשומות CloudKit המוצפנות המתאימות.
האם רשויות אכיפת החוק יכולות לגשת לנתונים בהצפנת zero-knowledge?
ייתכן שספק יצטרך למסור טקסט מוצפן שמור ומטא-נתונים של חשבון, תעבורה, חיוב או שירות שהוא שומר. בלי מפתח תוכן גלוי שנמצא אצלו, הספק לא יכול להשתמש בנתיב השירות הרגיל שלו כדי לפענח את התוכן. ניצול חולשות במכשיר, גילוי פרטי גישה, עותקי שחזור וחיוב למסור מידע הם נתיבים נפרדים, והחוקיות והיעילות שלהם משתנות לפי תחום השיפוט והנסיבות.
האם הצפנת zero-knowledge איטית יותר מהצפנה רגילה?
הביצועים של AES-256-GCM לא תלויים במי שמחזיק את המפתח. גזירה מבוססת סיסמה מוסיפה עבודה בזמן הפתיחה, ומשך הזמן שלה תלוי באלגוריתם, במספר האיטרציות, במכשיר ובמימוש. אפליקציות צריכות למדוד את העלות הזאת בחומרה נתמכת ולאזן בין מהירות התגובה לבין העלות שהיא כופה על כל ניחוש לא מקוון.
האם zero-knowledge אומר שהאפליקציה לא אוספת נתונים בכלל?
לא בהכרח. המונח עוסק בגבול של מפתח התוכן מול הספק, לא בכל זרימת נתונים. אפליקציה עדיין יכולה לעבד נתוני חשבון, אנליטיקה, דוחות קריסה, כתובות IP, גודלי רשומות, תזמון או מטא-נתונים אחרים של השירות. Vaultaire לא דורשת חשבון זהות. האנליטיקה ואבחון הקריסות של האפליקציה מופעלים כברירת מחדל, ואפשר לכבות אותם עם ״שיתוף שגיאות באופן אנונימי״ בהגדרות. מדיניות האירועים המתועדת לא כוללת את תוכן הכספת, תבניות, ביטויים ומפתחות פענוח; מדיניות הפרטיות מתארת את כללי האיסוף והשמירה הנוכחיים.
איך הצפנת zero-knowledge משתווה להגנת הנתונים המתקדמת של Apple?
הגנת הנתונים המתקדמת (ADP) של Apple, שהוצגה ב-iOS 16.2, מרחיבה את ההצפנה מקצה לקצה לקטגוריות נוספות של iCloud ומשתמשת במודל השחזור של חשבון Apple. Vaultaire מצפינה את תוכן הכספת במכשיר ולא דורשת חשבון זהות של Vaultaire; גיבוי ה-iCloud שלה, שפועל כברירת מחדל, וגם הסנכרון והשיתוף, משתמשים ברשומות CloudKit שהוצפנו בצד הלקוח בחשבון Apple של המשתמש. Vaultaire מציעה גם גישה לכספות שמופרדות לפי תבנית ומצב כפייה (Pro), עם מגבלות האחסון והשחזור שמתוארות בתיעוד ההכחשה הסבירה שלה.
סיכום
הכי נכון להתייחס להצפנת zero-knowledge כטענה על הפרדה ממפתחות הספק: השירות לא מחזיק את המפתח הגלוי שדרוש כדי לפענח את התוכן השמור. זה חזק יותר מהצפנה בצד השרת תחת מפתחות בשליטת הספק, אבל זו לא טענה שהמפתחות קיימים רק בזיכרון, שהמטא-נתונים נעלמים או שכל פריצה ללקוח ולמכשיר נבלמת. שפוט את המוצר לפי היררכיית המפתחות, תכנון השחזור, המימוש והבדיקה העצמאית.