APK signature scheme v3.2

ב-Android 17 (רמת API‏ 37) הוצגה APK Signature Scheme v3.2, סכמת חתימה היברידית שנועדה לתמוך במעבר של מערכת Android לשימוש בהצפנה פוסט-קוונטית (PQC).

בזמן שהתעשייה פורסת אלגוריתמי PQC בהיקף נרחב, ערכת הכלים בגרסה 3.2 מספקת הגנה מעמיקה. היא מחייבת אתכם לחתום על קובצי APK באמצעות אלגוריתם קלאסי, כמו RSA או ECDSA, וגם באמצעות אלגוריתם PQC. הגישה ההיברידית הזו משתמשת בקריפטוגרפיה קלאסית כדי להגן על ה-APK שלכם, ובו-זמנית מתגוננת מפני איומים ממחשבים קוונטיים.

מטרה ופרטים

הסכימה של גרסה 3.2 פועלת כמנגנון מעבר סטנדרטי שתואם לתקנים בתעשייה. הגישה ההיברידית הזו מאפשרת לכם ליהנות מיתרונות ה-PQC שחסין בפני קוונטים, ובו-זמנית להמשיך להסתמך על האבטחה המוכחת של אלגוריתמים קלאסיים לחתימה. אחרי שאלגוריתמי ה-PQC החדשים והמתוקננים יגיעו לרמת בשלות תפעולית בקנה מידה גדול, תוכלו לעבור מההגדרה ההיברידית הזו למפתח חתימה יחיד של PQC. התמיכה בפלטפורמה בפורמט החתימה v3.2 מתחילה ב-Android 17. בגרסאות Android ישנות יותר, הבלוק v3.2 נדלג ונעשה שימוש בסכימות קודמות לאימות חתימה.

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

• חומר מפתח חדש: כדי לעבור לבלוק היברידי, צריך ליצור מפתחות קלאסיים ו-PQC חדשים. לא מומלץ להשתמש מחדש בחומרי מפתח בין תצורות היברידיות לבין תצורות לא היברידיות.
• רוטציה מרומזת: הפלטפורמה מתייחסת לבלוק ההיברידי כאל רוטציה מרומזת של מפתחות. הפלטפורמה מוסיפה את המפתח הקלאסי החדש לשושלת החתימה הקיימת של האפליקציה כמפתח הלפני האחרון, ומתייחסת למפתח ה-PQC החדש כזהות החתימה הנוכחית של האפליקציה.
• שושלת משותפת: כדי לבצע בהצלחה את הרוטציה המרומזת, גם המפתח הקלאסי החדש וגם מפתח ה-PQC החדש בתוך בלוק ההיברידי צריכים להיות מאותה שושלת חתימה. צריך לשכפל את היסטוריית החתימות הקיימת של האפליקציה – בין אם מדובר במפתח מקורי יחיד או בסדרת מפתחות שעברו סבב בעבר – עבור שני החותמים ההיברידיים החדשים. הפלטפורמה משתמשת בשושלת המשותפת הזו כדי לוודא שהגורם שמעביר את האפליקציה לתוכנית ההיברידית הוא הבעלים הלגיטימי של זהות החתימה הנוכחית של האפליקציה.
• הגבלה על חתימה יחידה ב-PQC: במהלך ההשקה הראשונית של PQC, מערכת Android מגבילה באופן מפורש את השימוש באלגוריתמים של PQC לבלוק ההיברידי v3.2. הפלטפורמה לא מאמתת הגדרת PQC עם חותם יחיד באמצעות סכמות חתימה קודמות, כמו v2,‏ v3.0 או v3.1.
• מעבר חזרה: כשעוברים מחסימת היברידית בגרסה 3.2 חזרה לחסימה עם חותם יחיד – חותם קלאסי או חותם PQC, אם נתמך בגרסה עתידית – הפלטפורמה מאמתת שגם המפתחות הקלאסיים וגם מפתחות ה-PQC מהחסימה ההיברידית נמצאים בשושלת החתימה החדשה, ומאשרת את החותם היחיד החדש.

שיטות מומלצות למעבר

כדי לשמור על תאימות לגרסאות Android ישנות יותר ולספק נתיב שדרוג בטוח במהלך המעבר לחתימת PQC, קובצי APK צריכים להמשיך לכלול בלוק חתימה סטנדרטי v3.0 או v3.1 שחתום על ידי מפתח קלאסי יחיד. רק Android 17 (רמת API‏ 37) ומעלה תומכות בסכימת הגיבוב ההיברידית v3.2, ולכן הדרישה הזו מאפשרת למכשירים עם גרסאות נמוכות יותר לאמת ולהתקין את האפליקציה.

הגדרת חזרה למצב ראשוני

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

• אפליקציות קיימות: חתימת האפליקציה הנוכחית, K0, משמשת כבסיס טבעי לנסיגה הזו.
• אפליקציות חדשות: כדי ליצור את הזהות הראשונית, יוצרים מפתח חתימה קלאסי בסיסי, K0, לצד המפתחות ההיברידיים החדשים, C_K1 ו-PQC_K1.

בשני התרחישים, קובץ ה-APK צריך לכלול בלוק חתימה רגיל בגרסה 3.0 או 3.1 שחתום על ידי המפתח הקלאסי, K0, לצד בלוק היברידי בגרסה 3.2 שחתום על ידי המפתחות ההיברידיים החדשים, C_K1 ו-PQC_K1.

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

דרישות להגדרות לטווח ארוך

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

בלוק APK signature scheme v3.2

בלוק החתימה על ה-APK שומר את בלוק החתימה v3.2 לצד בלוקי החתימה v2,‏ v3.0 ו-v3.1.

המבנה של בלוק בגרסה 3.2 דומה לזה של גרסה 3.0, אבל נעשה בו שימוש במזהה בלוק חדש, 0x70e1c89f, כדי לציין שמדובר בבלוק היברידי. בלוק תקין בגרסה 3.2 חייב להכיל שני חותמים בדיוק.

אלגוריתמים נתמכים

בשלב הראשון, ערכת הכללים v3.2 תומכת באלגוריתמים הבאים של חתימות PQC:

• ML-DSA-65
• ML-DSA-87

הם משולבים עם אלגוריתמים קלאסיים רגילים לחתימה, כמו אלה שנתמכים בגרסאות 3.0 ו-3.1, כדי ליצור את הבלוק ההיברידי.

פורמט

בלוק החתימה על ה-APK מאחסן את הבלוק APK Signature Scheme v3.2 תחת המזהה 0x70e1c89f.

הפורמט של בלוק v3.2 זהה לפורמט של בלוק v3.0, אבל הרצף ברמה העליונה של רכיבי החותם חייב להכיל בדיוק שני ערכים שמכוונים לאותה גרסת SDK:

• רצף עם קידומת אורך של חותם עם קידומת אורך:
  
  • חתימה עם קידומת אורך (קלאסי)
  • חתימה עם אורך קבוע מראש (PQC)

כל חותם משתמש בפורמט v3 הרגיל:

• נתונים חתומים עם קידומת אורך:
  
  • רצף עם קידומת אורך של תקצירים עם קידומת אורך:
  • מזהה אלגוריתם החתימה (4 בייט)
  • digest (length-prefixed)
  • רצף של אישורים עם קידומת אורך:
  • אישור X.509 עם קידומת אורך (טופס ASN.1 DER)
  • minSDK (uint32)
  • maxSDK (uint32)
  • רצף של מאפיינים נוספים עם קידומת אורך:
  • מזהה (uint32)
  • ערך (אורך משתנה: אורך המאפיין הנוסף פחות 4 בייטים)
• minSDK ‏ (uint32)
• maxSDK (uint32)
• רצף עם קידומת אורך של חתימות עם קידומת אורך:
  
  • מזהה אלגוריתם החתימה (4 בייט)
  • חתימה עם קידומת אורך על נתונים חתומים
• מפתח ציבורי עם קידומת אורך (SubjectPublicKeyInfo, בפורמט ASN.1 DER)

אימות

ב-Android 17 (API ברמה 37) ואילך, כדי לאמת את החתימה בגרסה 3.2, הפלטפורמה מאמתת את החותמים הקלאסיים ואת חותמי ה-PQC, מוודאת שהם תואמים ובודקת את שושלת הרוטציה המרומזת. בגרסאות פלטפורמה מ-Android 16 (רמת API 36) ומטה, הפלטפורמה לא מעבדת את בלוק החתימה ההיברידי הזה ומשתמשת במקום זאת בסכימות קודמות.

התהליך הכולל הוא כזה:

1. מחפשים את הבלוק APK Signature Scheme v3.2 (מזהה 0x70e1c89f).
2. מוודאים שהבלוק מכיל שני חותמים בדיוק. אם יש פחות משני קווים או יותר משני קווים, האימות ייכשל.
3. מוודאים שחותם אחד משתמש באלגוריתם חתימה קלאסי והשני משתמש באלגוריתם חתימה של PQC. אם שניהם קלאסיים או שניהם PQC, האימות ייכשל.
4. מוודאים ששני החותמים מכוונים לאותו טווח SDK בדיוק (minSdkVersion ו-maxSdkVersion).
5. לכל אחד משני החותמים, מבצעים אימות רגיל בגרסה 3:
   
   1. בוחרים את מזהה אלגוריתם החתימה החזק ביותר מבין אלה שנתמכים בחתימות.
   2. מאמתים את החתימה המתאימה מתוך החתימות מול הנתונים החתומים באמצעות המפתח הציבורי.
   3. מוודאים שערכי minSdkVersionוmaxSdkVersion בנתונים החתומים זהים לערכים של minSdkVersionוmaxSdkVersion בנתונים הלא חתומים.
   4. מנתחים את האישורים ומוודאים שהאישור הראשון תואם למפתח הציבורי.
   5. ניתוח מאפיינים נוספים כדי לחלץ מבני הוכחת סבב מפתחות.
6. אימות היסטוריית החתימות (הוכחת סבב מפתחות):
   
   1. בודקים שלשני החותמים יש היסטוריית חתימה זהה.
   2. אורכי השושלת צריכים להיות זהים, וכל האישורים ודגלי היכולות שמובילים לחותמים הנוכחיים צריכים להיות זהים.
   3. אם ההיסטוריה תואמת, צריך למזג את שרשראות האישורים: להתייחס לאישור של החותם הקלאסי כאל האישור הקודם לאישור של החותם PQC, ולהקצות את החותם PQC כצומת הקצה הנוכחי.
7. אימות סיכומי תוכן:
   
   1. חוזרים על הפעולה במפת התקצירים עבור שני החותמים.
   2. מוודאים שכל האלגוריתמים של ה-digest זהים, ושהערכים המחושבים של ה-digest זהים בין חותמי ה-PQC והחותמים הקלאסיים.
8. משתמשים בתקצירים התואמים מהחותמים המאומתים כדי לאמת את התקינות של תוכן ה-APK (בדומה ל-v2 ול-v3).
1. אם האפליקציה כבר מותקנת, מאמתים את שושלת העדכונים של החבילה:
2. עדכון מאפליקציה שנחתמה על ידי חותם יחיד: אם האפליקציה המותקנת נחתמה באמצעות חתימה קלאסית יחידה, החתימה הזו צריכה להופיע בשושלת החתימות של בלוק החתימה ההיברידי החדש כחתימה קודמת לחתימות ההיברידיות.
3. עדכון מחותם היברידי כדי להמשיך להשתמש בחותם היברידי: אם האפליקציה המותקנת נחתמה באמצעות בלוק היברידי v3.2, גם המפתחות הקלאסיים הקודמים וגם מפתחות ה-PQC צריכים להישאר החותמים הפעילים הנוכחיים בבלוק v3.2 של קובץ ה-APK של העדכון, או ששניהם צריכים להיות נוכחים בשושלת החתימה החדשה שמאשרת את המפתחות ההיברידיים החדשים שהוחלפו.
4. מעבר מחותם היברידי: אם האפליקציה שהותקנה נחתמה עם בלוק היברידי v3.2 וה-APK של העדכון חוזר לחותם יחיד (PQC או קלאסי), שני החותמים ההיברידיים הקודמים צריכים להיות נוכחים בשושלת החתימה של ה-APK של העדכון ולהעיד על מפתח החתימה היחיד החדש.
5. נתיבי עדכון לא תקינים: אם מפתח מנסה לעדכן אפליקציה עם חתימה היברידית באמצעות רק אחד מהמפתחות ההיברידיים כחתימה יחידה ללא רוטציה מתאימה, העדכון נכשל. כדי למנוע התקפות שדרוג, שני המפתחות צריכים להיות מעורבים באופן מפורש בכל מעבר.
9. אם אחד מהשלבים נכשל, האימות נכשל.

Stripping protection

כדי למנוע מתקפות שדרוג לאחור לתוכניות חתימה נמוכות יותר, התוכנית v3.2 כוללת מאפייני הגנה מפני הסרה, בדומה לגרסאות קודמות של התוכנית.

כלי החתימה כותב שני מאפיינים ספציפיים של הגנה היברידית מפני הסרה לתוך המאפיינים הנוספים של בלוקי החתימה בגרסאות 3.0 ו-3.1. המאפיינים האלה מגדירים את הגבולות המדויקים של גרסת ה-SDK שבהם צריך להציג ולאמת את בלוק ה-Hybrid v3.2:

• מאפיין גרסת ה-SDK המינימלית (מזהה 0xbf940529): הערך של המאפיין הזה קובע את גרסת ה-SDK המינימלית שנתמכת על ידי בלוק החתימה ההיברידי.
• מאפיין גרסת ה-SDK המקסימלית (מזהה 0x9f06b79c): הערך של המאפיין הזה קובע את גרסת ה-SDK המקסימלית שבלוק החתימה ההיברידי תומך בה. המאפיין הזה מאפשר לכם לעבור להגדרה של חתימה יחידה כשגרסאות פלטפורמה מתקדמות יותר לא דורשות את החתימה ההיברידית.

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

• אימות הנוכחות והטווח: אם בלוק החתימה v3.0 או v3.1 מכיל את מאפיין ה-SDK המינימלי (מזהה 0xbf940529, ערך X) או את מאפיין ה-SDK המקסימלי (מזהה 0x9f06b79c, ערך Y), הפלטפורמה דורשת שבלוק ההיברידי v3.2 יופיע ב-APK. הפלטפורמה קוראת את הבלוק ההיברידי כדי לוודא שטווח גרסאות ה-SDK שמטורגט תואם לגבולות שצוינו במאפיינים האלה. אם חסר הבלוק v3.2, או אם ערכי היעד הפנימיים של המינימום והמקסימום של SDK לא שווים ל-X ול-Y, הפלטפורמה דוחה את ההתקנה.
• אכיפה בטווח: אם גרסת ה-SDK של המכשיר נמצאת בטווח התקין שצוין במאפיינים האלה – כלומר, גדולה מ-X או שווה לה, וקטנה מ-Y או שווה לה כשמספקים את מאפיין המקסימום – הפלטפורמה דורשת באופן מחמיר את הבלוק ההיברידי v3.2 לאימות החתימה. אם הפלטפורמה מאמתת בלוק v3.0 או v3.1 במכשיר בטווח היעד של ערכת ה-SDK, הפלטפורמה דוחה את ההתקנה כי בלוק v3.2 עקף או הוסר בזדון.

באמצעות אכיפת הגבולות האלה, הפלטפורמה קובעת מתי קובץ APK צריך להכיל בלוק v3.2. אם הבלוק הוסר, הפלטפורמה דוחה את ההתקנה כדי למנוע מתקפת downgrade.

אימות ההטמעה

כדי לבדוק את ההטמעה של תוכנית החתימה v3.2, מריצים את HybridSignatureVerificationTest.java בדיקות ה-CTS שנמצאות ב-cts/hostsidetests/appsecurity/src/android/appsecurity/cts/.

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