Envelope Encryption מול SQLCipher באפליקציות Android

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

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

הבעיה: מידע רגיש באחסון המכשיר

אפליקציות בנקאות שומרות מידע ב-cache כדי להישאר מהירות ושמישות גם בלי חיבור: פרטי חשבון, תנועות אחרונות, פרטי פרופיל. אם המידע הזה יושב על המכשיר בטקסט גלוי, טלפון עם root, גיבוי או העתק פורנזי עלולים לחשוף אותו. ב-OWASP Mobile Top 10 (2024), זה נופל תחת M9: Insecure Data Storage ו-M10: Insufficient Cryptography.

אפשרות 1: SQLCipher

SQLCipher הוא fork של SQLite שמצפין את כל קובץ מסד הנתונים.

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

אפשרות 2: Envelope Encryption

הצפנת מעטפה עובדת עם שתי רמות של מפתחות:

מפתח הצפנת מידע (DEK) מצפין את הערכים הרגישים באמצעות צופן מאומת כמו AES-GCM.
מפתח הצפנת מפתחות (KEK) ב-Android Keystore עוטף את ה-DEK. קוד האפליקציה אף פעם לא רואה את ה-KEK, ובמכשירים נתמכים הוא מגובה חומרה.

📌 תובנה מרכזית:

בשתי הגישות, ההגנה האמיתית מגיעה מה-Keystore. הבחירה היא מה מצפינים בעזרתו: את כל הקובץ, או רק את הערכים שחשובים.

למה הצפנת מעטפה התאימה לאפליקציה הזו

1. רוב המידע השמור לא היה רגיש

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

2. נפח האפליקציה היה חשוב

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

3. מחיר הביצועים היה מדיד וקטן

מדדנו את התקורה של פענוח הערכים שכל מסך מציג: כ-1 ms לכל מסך — הרבה מתחת לכל מה שמשתמש יכול להרגיש.

4. מודל מפתחות אחד לכל דבר

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

הפשרות שקיבלנו

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

השוואה צד לצד

היבט	SQLCipher	Envelope Encryption
מה מוצפן	כל קובץ מסד הנתונים	ערכים רגישים נבחרים
שאילתות על מידע מוצפן	כן	לא
השפעה על נפח האפליקציה	נוספות ספריות native	כ-6.5 MB פחות באפליקציה הזו
מחיר בזמן ריצה	הצפנה בכל עמוד של מסד הנתונים	כ-1 ms לכל מסך, לפי מדידה
מאמץ תכנון	נמוך	נדרש סיווג מידע
מתאים במיוחד ל	מידע שרובו רגיש ודורש שאילתות	מעט ערכים רגישים בתוך מאגר מידע גדול יותר

איך Mobian ניגשת להחלטות כאלה

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

סיכום

גם SQLCipher וגם הצפנת מעטפה נשענים על ה-Android Keystore לצורך ההגנה האמיתית. באפליקציה שבה רק חלק מהמידע המקומי רגיש, הצפנה ישירה של הערכים האלה חסכה 6.5 MB ועלתה כ-1 ms לכל מסך — בתמורה לסיווג מידע קפדני ולוויתור על שאילתות על שדות מוצפנים. התשובה הנכונה תלויה במידע שלכם, וההחלטה ראויה להיות מתועדת בכתב.

שאלות נפוצות

מה זה Envelope Encryption (הצפנת מעטפה)?

הצפנת מעטפה משתמשת בשתי רמות של מפתחות. המידע מוצפן באמצעות מפתח הצפנת מידע (DEK), וה-DEK עצמו מוצפן, או עטוף, באמצעות מפתח הצפנת מפתחות (KEK). ב-Android, ה-KEK יכול להישמר ב-Android Keystore, שם הוא אף פעם לא נחשף לקוד האפליקציה.

האם SQLCipher הוא בחירה גרועה?

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

מה חסכה הצפנת המעטפה בפרויקט הזה?

הוויתור על SQLCipher חסך כ-6.5 MB של קוד native באפליקציה, בעלות מדודה של כ-1 ms לכל מסך להצפנה ולפענוח של הערכים הרגישים שהוא מציג.

מה החיסרון העיקרי של הצפנת מעטפה ברמת השדה?

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

האם הצפנת מעטפה עומדת בדרישות OWASP?

כשהיא ממומשת נכון, עם מפתחות מגובי חומרה היכן שהם זמינים ועם צופן מאומת כמו AES-GCM, היא נותנת מענה לקטגוריות של אחסון מידע לא מאובטח וקריפטוגרפיה לא מספקת ב-OWASP Mobile Top 10 (2024). האם היא עומדת בדרישות של אודיט מסוים תלוי בדרישות של אותו אודיט.

למה בחרנו ב-Envelope Encryption ולא ב-SQLCipher לאפליקציית בנקאות