סקירה כללית
Android 13 תומך ב-APK Signature Scheme v3.1, שיפור של APK Signature Scheme v3 הקיים. הסכימה v3.1 מטפלת בחלק מהבעיות הידועות ב-APK Signature Scheme v3 שקשורות לרוטציה. באופן ספציפי, הסכימה של החתימה בגרסה 3.1 תומכת בטירגוט של גרסת SDK, שמאפשרת לעבור לגרסת הפלטפורמה שיצאה מאוחר יותר.
בסכימת החתימה v3.1 נעשה שימוש במזהה בלוק שלא מזוהה ב-Android בגרסה 12 ומטה. לכן, הפלטפורמה מחילה את התנהגות החתימה הבאה:
- במכשירים עם Android מגרסה 13 ואילך נעשה שימוש בחתימה של הגורם המשתנה בבלוק v3.1.
- במכשירים עם גרסאות ישנות יותר של Android, המערכת מתעלמת מהחתימה המנוהלת ומשתמשת במקום זאת בחתימה המקורית בבלוק v3.
לא צריך לבצע פעולה נוספת לגבי אפליקציות שעדיין לא ביצעת בהן רוטציה של מפתח החתימה. בכל פעם שהאפליקציות האלה בוחרות לבצע רוטציה, המערכת מחילה את סכמת החתימה של גרסה 3.1 כברירת מחדל.
בלוק חתימה בגרסה 3.1
לבלוק החתימה בגרסה 3.1 יהיה תוכן זהה לזה של בלוק החתימה בגרסה 3, אבל עם מזהה הבלוק החדש, החתימות האלה יזוהו רק במכשירים עם Android מגרסה 13 ואילך. כך אפשר לבצע רוטציה של מפתחות החתימה של אפליקציות בצורה בטוחה בלי לדאוג לגבי קובצי APK למספר מטרות, כי אפשר להשתמש בחתימה המקורית כדי לחתום על קובץ ה-APK בבלוק החתימה של גרסה 3, ובחתימה שסובבה בבלוק החתימה של גרסה 3.1. כך אפשר גם לעשות שימוש חוזר בכל קודי האימות הקיימים של בלוק החתימה בגרסה 3, כשמאמתים חתימה בגרסה 3.1.
כברירת מחדל, הספרייה apksig תשתמש בבלוק החתימה של גרסה 3.1 בכל פעם שמספקים מפתח מסובב ושושלת אב בהגדרות החתימה. אם הערך של minSdkVersion של האפליקציה נמוך מ-Android 13 ונעשה שימוש במפתח שהופעל בו רוטציה, צריך לציין גם את מפתח החתימה המקורי כדי שניתן יהיה להשתמש בו כדי לחתום על ה-APK בבלוק החתימה של גרסה 3. ההתנהגות הזו דומה להתנהגות הנוכחית, שבה נדרש החתום המקורי אם קובץ ה-APK מטרגט גרסה ישנה יותר מ-Android 9.
כדי לתמוך בהחלפה של מפתחות טירגוט החל מגרסה מסוימת של SDK, ספריית apksig תציג ממשקי API חדשים שיאפשרו להגדיר גרסה מינימלית של SDK לצורך החלפה. אם יצוין גרסה של SDK שקטנה מ-Android 13 כגרסה המינימלית לתמיכה בהחלפה, המערכת תשתמש בבלוק המקורי של גרסה 3. בלוק החתימה של גרסה 3.1 משמש רק במקרה של רוטציה, כאשר גרסת ה-SDK המינימלית לרוטציה מוגדרת ל-Android מגרסה 13 ואילך. בבלוק החתימה של גרסה 3 יהיה מאפיין חדש להגנה מפני הסרת גרסת ה-SDK המינימלית בזמן רוטציה.
| חבילת ה-APK כוללת את Lineage | הערך של rotation-min-sdk-version | בלוק חתימה של גרסה 3 | בלוק חתימה בגרסה 3.1 |
|---|---|---|---|
| לא | ברירת מחדל או כל ערך אחר (המיוצג על ידי x בהמשך) | חתום על ידי החתום המקורי, טירגוט ל-Android 9 ואילך | לא נמצא |
| כן | ברירת מחדל | חתום על ידי החתום המקורי, מטרגט ל-Android 9 עד 12L | חתימה על ידי חתום שהוחליף, טירגוט ל-Android 13 ואילך |
| כן | x < 33 (Android 13) | חתימה על ידי חתום חלופי, טירגוט ל-Android 9 ואילך | לא נמצא |
| כן | x >= 33 (Android 13) | חתימה על ידי החתום המקורי, טירגוט ל-Android 9 - (x-1) | חתימה על ידי חותם שהופנה, טירגוט x+ |
בעיות שקשורות לסיבוב
הבעיות הבאות שקשורות לתנועה בזווית נפתרו בפלטפורמה:
תיקונים ל-Android 12
- הפלטפורמה תעניק הרשאת חתימה לאפליקציה מבקשת רק אם הגורם החתום הנוכחי של אחת מהאפליקציות נמצא בשרשרת החתימה, או שהוא הגורם החתום הנוכחי של האפליקציה השנייה. כך לא תהיה אפשרות להעניק הרשאת חתימה לאפליקציה מבקשת אם שתי האפליקציות פועלות לפי השיטות המומלצות לשימוש במפתחות חתימה ומבצעות רוטציה למפתחות חתימה שונים.
- תכונת החזרה לאחור של ה-APK בפלטפורמה לא הצליחה לבצע החזרה לאחור של APK שרק בוצעה בו רוטציית מפתחות, אלא אם למפתח הקודם בשושלת החתימות הייתה יכולת החזרה לאחור. עם זאת, היכולת הזו מבטלת את מטרת הרוטציה, כי היא מאפשרת לעדכן חבילה חדשה באמצעות מפתח החתימה הקודם ולבצע החזרה לאחור של המפתח שעבר רוטציה.
- חבילת APK שנחתמה רק עם המפתח המסובב ועדכנתם אותה מאוחר יותר עם חבילת APK שנחתמה עם המפתח המקורי ועם המפתח המסובב בשושלת, תציג רק את המפתח המסובב בשושלת במכשירים עם Android מגרסה 11 ואילך.
תיקונים ל-Android 11
PackageManager#checkSignaturesלא עודכן כראוי כדי לבדוק את מפתחות החתימה המקוריים של שתי חבילות. כתוצאה מכך, כלי המדידה לא עבדו באפליקציות שמשתמשות במפתח חתימה שעבר רוטציה, עם חבילת ה-APK של כלי המדידה שמשתמשת במפתח החתימה המקורי.- חבילות שנמצאות ב-
sharedUserIdמשתפות את שרשרת החתימה שלהן. בכל פעם שמתקינים או מעדכנים אפליקציה עם שושלת חתימה מעודכנת ב-sharedUiserId, שושלת האפליקציה הזו מחליפה את השושלת המשותפת של ה-sharedUserId(כלומר, אם שושלת החתימה של אפליקציה הייתה A -> B, והאפליקציה מתעדכנת ב-sharedUserIdעם שושלת B -> C, שושלת ה-sharedUserIdתוחלף בשושלת B -> C). באופן דומה, לא ניתן לעדכן את היכולות של חותם קודם בשרשרת החתימה, אלא אם משנים את שרשרת החתימה.
שילוב של גרסה 4
סכמת החתימה v4 משתמשת בהגדרת החתימה שסופקה ל-apksigner. במקרה של כמה הגדרות חתימה שסופקו לצורך רוטציה, המערכת משתמשת בהגדרת החתימה האחרונה שהוחלפה. לפני ההשקה של גרסה 3.1, גרסה 3 כללה רק את הגדרת החתימה האחרונה שהופיעה בה, כך שגרסה 4 הצליחה להשתמש בהגדרה הזו כפי שהיא. כתוצאה מכך, סכמת החתימה של גרסה 4 הצליחה לתמוך בסבב חתימה כי היא השתמשה במפתח החתימה שהופיע בה ב-SigningInfo. SigningInfo בגרסה 4 לא כולל את שרשרת החתימה המלאה, אבל הוא יכול למשוך אותה מבלוק החתימה בגרסה 3 כדי לאפשר לפלטפורמה גישה לשרשרת לכל שאילתות החתימה. כשמשתמשים ב-v3.1 כדי לטרגט רוטציה של הגרסה שצוינה ב-rotation-min-sdk-version, קובץ התצורה הכללי של v3 יכלול גם את קובץ התצורה המקורי לחתימה וגם את קובץ התצורה העדכני ביותר לחתימה לאחר הרוטציה. נוצרה תוספת לסכמת החתימה בגרסה 4, שכוללת עוד בלוקים של פרטי חתימה לכל אחת מההגדרות של החתימה מהבלוק בגרסה 3.1.
אימות
כדי לבדוק את ההטמעה של גרסה 3.1, מריצים את בדיקות PkgInstallSignatureVerificationTest.java CTS ב-cts/hostsidetests/appsecurity/src/android/appsecurity/cts/.
מידע נוסף על בדיקה זמין בקטע אימות בגרסה 3.