ארכיטקטורת אבטחה: הסטק הטכני המלא

Vaultaire משתמש ב-AES-256-GCM להצפנה מאומתת של אינדקסי הכספת, מפתחות עטופים, כותרות קבצים, תוכן, תמונות ממוזערות ומטא-דאטה. PBKDF2-HMAC-SHA512 גוזר מפתח כספת מקומי מהתבנית ומ-salt ב-Keychain המשותף לכל המכשיר. מפתח הכספת הזה עוטף מפתח ראשי אקראי נפרד בן 256 ביט, שמבצע את הצפנת הקבצים דרך CryptoKit בתהליך האפליקציה.

הסטק הקריפטוגרפי

Vaultaire משתמש בכמה מנגנוני הצפנה שעובדים יחד, וכל אחד נבחר לתפקיד מסוים. PBKDF2 הופך פרטי גישה אנושיים למפתח כספת או למפתח שחזור. AES-256-GCM מגן על אינדקסים, עטיפות מפתח, מטא-דאטה, תמונות ממוזערות ותוכן קבצים. מפתח ראשי אקראי מפריד בין הצפנת הקבצים לטווח ארוך לבין תבנית שאפשר לשנות. Keychain והגנת הנתונים של iOS מגנים על ה-salt הקשור למכשיר ועל רשומות השחזור כשהמכשיר נעול. אין מפתח פענוח בידי ספק שנותן למפתח האפליקציה גישה שגרתית לתוכן הכספת הגלוי.

זו לא מורכבות לשם מורכבות. כל שכבה מטפלת במשטח תקיפה אחר. AES-256-GCM משלב סודיות עם אימות, כך שטקסט מוצפן ששונה נכשל באימות. PBKDF2 מייקר את הבדיקה של כל תבנית או ביטוי. המפתח הראשי האקראי מאפשר לשינוי תבנית לעטוף מחדש מפתח אחד במקום להצפין מחדש כל קובץ. הגנת הנתונים של Keychain שומרת על ה-salt ועל רשומות השחזור המקומיות, והאפליקציה עדיין מצהירה שההצפנה הסימטרית מתבצעת בזיכרון התהליך.

יחד, השכבות האלה יוצרות ארכיטקטורת הגנה לעומק, אבל לא כולן מחסומים עצמאיים. אפשר לבדוק ניחוש של תבנית מול שם קובץ האינדקס ואימות ה-AES-GCM, ומכשיר פרוץ ופתוח יכול לראות מפתחות או תוכן גלוי בתהליך האפליקציה. לכן הארכיטקטורה תלויה באנטרופיה של פרטי הגישה, בעלות PBKDF2, בהגנת המכשיר של iOS ובטיפול נכון בהצפנה מאומתת, ולא רק בחוזק של AES עצמו.

AES-256-GCM: הצפנת קבצים

כל תמונה, סרטון ומסמך שנשמרים ב-Vaultaire מוצפנים ב-AES-256-GCM: תקן ההצפנה המתקדם עם מפתח של 256 ביט במצב Galois/Counter. Vaultaire משתמש ב-AES-GCM גם לאינדקסי הכספת, לכותרות הקבצים, לתמונות הממוזערות ולעטיפות המפתח. האלגוריתם וגודל המפתח הם סטנדרטיים. האבטחה של Vaultaire עדיין תלויה בטיפול ב-nonce, בניהול המפתחות, בחוזק פרטי הגישה ובנכונות המימוש.

ה-“256” ב-AES-256 מתייחס לאורך המפתח בביטים. למפתח 256-ביט יש 2²⁵⁶ ערכים אפשריים. כדי לשים את המספר הזה בפרספקטיבה: יש בערך 10⁸⁰ אטומים ביקום הנצפה. אם כל אטום היה מחשב-על שבודק מיליארד מפתחות בשנייה, פועל מאז המפץ הגדול, הם היו חוקרים פחות מטריליונית של טריליונית של אחוז אחד ממרחב המפתחות. AES-256 לא יישבר בכוח גס. לא היום. לא במאה הזאת. לא לפני שהכוכבים ייכבו.

מדוע מצב GCM חשוב

AES הוא צופן בלוקים, הוא מצפין נתונים בנתחים של 128-ביט. ה-“מצב” קובע כיצד נתחים אלה משולבים. GCM (Galois/Counter Mode) מספק שני דברים שמצבים פשוטים יותר כמו CBC לא מספקים: הצפנה מקבילה ואימות מובנה.

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

PBKDF2: גזירת מפתחות

Vaultaire גוזר מפתחות שונים לתפקידים שונים. התבנית וה-salt ב-Keychain המשותף לכל המכשיר עוברים 600,000 איטרציות של PBKDF2-HMAC-SHA512 כדי לייצר את מפתח הכספת המקומי. גזירה דטרמיניסטית נפרדת מהתבנית מייצרת את מפתח גיבוי הענן. ביטוי השחזור המנורמל עובר עד 800,000 איטרציות של PBKDF2 כדי לגזור את המפתח למעטפת השחזור. אף אחת מהגזירות האלה לא הופכת פרטי גישה אנושיים ל-256 ביט של אנטרופיה רק כי הפלט באורך 256 ביט.

כיצד PBKDF2 מגן על התבנית שלך

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

Vaultaire מגדיר את PBKDF2 עם 600,000 איטרציות למפתחות שנגזרים מהתבנית. זה מייקר כל ניחוש, אבל הערכת תקיפה אחראית חייבת לציין זמן מדוד לכל מועמד ואת הנחות החומרה. באלפית שנייה בדיוק לכל מועמד, מיליארד ניחושים סדרתיים לוקחים כ-11.6 ימים, לא שנים. פלט של 256 ביט לא מרחיב את האנטרופיה של תבנית צפויה.

הגזירה המקומית מהתבנית משתמשת ב-salt אקראי קריפטוגרפי אחד למכשיר, שנשמר כפריט Keychain מסוג WhenUnlockedThisDeviceOnly. ה-salt אינו סודי והוא משותף לכל הכספות במכשיר. הוא מונע מטבלה שנבנתה למכשיר אחד לפעול ישירות על מכשיר אחר עם salt אחר, אבל לא מכריח תוקף להתחיל מחדש לכל כספת באותו מכשיר.

AES-256-GCM: הגנה על מטא-דאטה

הצפנת תוכן הקבצים אינה מספיקה. שמות קבצים, תאריכי יצירה, מידות תמונות ממוזערות, ומבנה הכספת כולם מטאדאטה, ומטאדאטה יכולה להיות חשיפתית לא פחות מהנתונים עצמם. קובץ בשם “tax-return-2025.pdf” אומר לתוקף בדיוק מה בפנים גם אם התוכן מוצפן. חותמת זמן מציגה מתי השתמשת בכספת. גודל תמונה ממוזערת חושף אם משהו הוא תמונה או וידאו.

Vaultaire מגן על המטא-דאטה הזאת ב-AES-256-GCM, לא ב-ChaCha20. שמות קבצים וסוגי MIME מקודדים בכותרות קבצים מוצפנות. אינדקס הכספת המוצפן מכיל את רשומות הקבצים, תאריכים, מידע על גודל, פריסת האחסון ואת המפתח הראשי העטוף. גם נתוני התמונות הממוזערות מוצפנים תחת המפתח הראשי האקראי.

למה הצפנה מאומתת למטא-דאטה?

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

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

ארכיטקטורת ידע אפס

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

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

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

מה ידע אפס אומר בפועל

אם רשות אכיפת חוק מגישה ל-Vaultaire צו שדורש את התוכן הגלוי של כספת, לחברה אין את התבנית, ביטוי השחזור, מפתח הכספת, מפתח הגיבוי או המפתח הראשי שנדרשים לפענוח. רשומות iCloud מוצפנות נמצאות במסד הנתונים הפרטי של המשתמש ב-CloudKit. עם זאת, במכשיר עצמו חומר השחזור נשמר במסד נתונים מוצפן ב-Keychain, ומפתחות סימטריים נמצאים בזיכרון האפליקציה בזמן ש-CryptoKit מצפין או מפענח כספת פתוחה.

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

Keychain וגבול תהליך האפליקציה

ה-Secure Enclave של Apple יכול להגן על מפתחות פרטיים נתמכים ומשתתף בחלקים מארכיטקטורת האבטחה של הפלטפורמה, אבל ממשקי ה-API הציבוריים שלו לא מקבלים מפתח סימטרי שרירותי שנגזר ב-PBKDF2 ולא מבצעים את פעולות ה-AES-GCM של Vaultaire על קבצים בתוך המעבד הייעודי. לכן Vaultaire לא מתאר את צופן הכספת שלו כ-AES של Secure Enclave.

Vaultaire משתמש בפריטי סיסמה גנריים רגילים של Keychain ב-iOS עבור ה-salt האקראי של המכשיר, מסד נתוני השחזור המוצפן והמפתח האקראי שמגן על מסד הנתונים הזה. הפריטים משתמשים במחלקת הנגישות WhenUnlockedThisDeviceOnly. Keychain והגנת הנתונים יוצרים גבול מכשיר משמעותי, במיוחד כשהטלפון נעול, אבל הארכיטקטורה הזאת שונה ממפתח Secure Enclave שאי אפשר לייצא.

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

מערכת הפעלה שעברה jailbreak או נפרצה בדרך אחרת יכולה לכוון לקלט התבנית, לזיכרון האפליקציה, לתצוגות מקדימות מפוענחות, לייצוא או למסך. Vaultaire ממליץ על iPhone עדכני בלי jailbreak, כי התכנון נשען על בידוד התהליכים של iOS, על Keychain ועל הגנת הנתונים. הוא לא טוען שפריצה ברמת root משאירה את המפתחות הסימטריים של כספת פתוחה מחוץ להישג יד.

וקטורי אתחול לכל קובץ

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

Vaultaire מונע טקסט מוצפן דטרמיניסטי בכך שהוא יוצר nonce קריפטוגרפי חדש לכל פעולת חתימה של AES-256-GCM. כותרות הקבצים ותוכן הקבצים נחתמים בנפרד, וקבצים גדולים משתמשים בפורמט זרימה מאומת עם nonce בסיס אקראי ו-nonce נפרד לכל מקטע ממוספר. לכן שני עותקים של אותה תמונה לא מייצרים את אותו ייצוג מוצפן.

ערכי ה-nonce נשמרים לצד הטקסט המוצפן ואינם סודיים. דרישת האבטחה שלהם היא ייחודיות תחת מפתח נתון. Vaultaire מבקש ערכי nonce בני 96 ביט ממחולל המספרים האקראיים הקריפטוגרפי של Apple להצפנה בפעולה אחת, ורושם את ה-nonce הבסיסי בכותרת הזרימה. סיכון ההתנגשות נקבע לפי מספר ההצפנות תחת מפתח אחד, ולכן המימוש יוצר ערך חדש בכל פעם ולא מציג את גודל 96 הביט כהבטחה קבועה של אחד ל-2⁹⁶ לכל החיים.

ניהול זיכרון: ניקוי מצב מפתח פעיל

כשל נפוץ בתוכנות אבטחה הוא השארת נתונים רגישים בזיכרון לאחר שאינם נדרשים עוד. מפתחות הצפנה, סיסמאות גזורות, ונתונים מפוענחים יכולים להישאר ב-RAM זמן רב לאחר שהאפליקציה סיימה להשתמש בהם. כלים פורנזיים יכולים לבצע dump לזיכרון המכשיר ולחפש שרידים אלה, טכניקה הידועה כהתקפת cold boot או ניתוח dump זיכרון.

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

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

בפעם הבאה ש-Vaultaire נפתח במצב נעול, אתה מצייר את התבנית והאפליקציה גוזרת שוב את מפתח הכספת לפני שהיא יכולה לאמת את האינדקס ולפרוק את המפתח הראשי. זה ניקוי הפעלה, לא טענה שכל עותק זמני בזיכרון עבר מחיקה מרובת מעברים שאפשר להוכיח או שהפניה למפתח ב-Secure Enclave הושמדה. קריסה גורמת ל-iOS לשחרר את התהליך, אבל קוד הניקוי לא יכול לרוץ אחרי כל סיום פתאומי.