הרשאות ספק ב-UICC

ב-Android 5.1 הושק מנגנון להענקת הרשאות מיוחדות לממשקי API שרלוונטיים לבעלים של אפליקציות לכרטיס מעגלים משולב אוניברסלי (UICC). פלטפורמת Android טוענת אישורים שמאוחסנים ב-UICC ומעניקה הרשאה לאפליקציות שנחתמו באמצעות האישורים האלה לביצוע קריאות למספר ממשקי API מיוחדים.

מערכת Android 7.0 הרחיבה את התכונה הזו כדי לתמוך במקורות אחסון אחרים עבור כללי הרשאות של ספקים ב-UICC, ועלייה משמעותית במספר הספקים שיכולים להשתמש בממשקי ה-API. למידע נוסף, ראו CarrierConfigManager. להוראות, ראו הגדרת הספק.

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

כללים לגבי UICC

האחסון ב-UICC תואם ל מפרט בקרת הגישה לרכיב מאובטח של GlobalPlatform. מזהה האפליקציה (AID) בכרטיס הוא A00000015141434C00, והפקודה הרגילה GET DATA משמשת לאחזור כללים שמאוחסנים בכרטיס. אפשר לעדכן את הכללים האלה באמצעות עדכוני כרטיסים אלחוטיים (OTA).

היררכיית נתונים

כללי UICC משתמשים בהיררכיית הנתונים הבאה (השילוב של האות והמספר בן שתי התווים בסוגריים הוא תג האובייקט). כל כלל הוא REF-AR-DO (E2) והוא מורכב משרשור של REF-DO ו-AR-DO:

  • REF-DO (E1) מכיל DeviceAppID-REF-DO או שרשור של DeviceAppID-REF-DO ו-PKG-REF-DO.
    • DeviceAppID-REF-DO (C1) מאחסן את החתימה SHA-1 (20 בייטים) או SHA-256 (32 בייטים) של האישור.
    • PKG-REF-DO (CA) היא המחרוזת המלאה של שם החבילה שמוגדרת במניפסט, בקידוד ASCII, באורך מקסימלי של 127 בייטים.
  • השדה AR-DO (E3) מורחב כך שיכלול את השדה PERM-AR-DO (DB), שהוא מסכת ביט של 8 בייטים שמייצגת 64 הרשאות נפרדות.

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

דוגמה לכלל

שם האפליקציה הוא com.google.android.apps.myapp ואישור SHA-1 במחרוזת ההקסדצימלית הוא:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

הכלל לגבי UICC במחרוזת הקסדצימלית הוא:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

תמיכה בקובצי כללי גישה

ב-Android 7.0 נוספה תמיכה בקריאת כללי הרשאות של ספק מקובץ כללי הגישה (ARF).

פלטפורמת Android מנסה קודם לבחור את מזהה ה-AID A00000015141434C00 של אפליקציית כלל הגישה (ARA). אם הוא לא מוצא את ה-AID ב-UICC, הוא חוזר ל-ARF על-ידי בחירה של PKCS15 AID A000000063504B43532D3135. לאחר מכן, Android קוראת את קובץ כללי בקרת הגישה (ACRF) ב-0x4300 ומחפשת רשומות עם AID‏ FFFFFFFFFFFF. המערכת מתעלמת מהרשאות עם מזהי AID שונים, כך שאפשר להשתמש בו-זמנית בכללים לתרחישי שימוש אחרים.

דוגמה לתוכן ACRF במחרוזת הקסדצימלית:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

דוגמה לתוכן של קובץ תנאי בקרת גישה (ACCF):

30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

בדוגמה שלמעלה, 0x4310 היא הכתובת של ACCF, שמכילה את גיבוב האישור 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. אפליקציות שחתומות על האישור הזה מקבלות הרשאות ספק.

ממשקי API מופעלים

Android תומך בממשקי ה-API הבאים.

TelephonyManager

TelephonyCallback

ב-TelephonyCallback יש ממשקים עם שיטת קריאה חוזרת כדי להודיע לאפליקציית הקריאה כשהמצבים הרשומים משתנים:

SubscriptionManager

SmsManager

  • שיטה שמאפשרת למבצע השיחה ליצור הודעות SMS נכנסות חדשות: injectSmsPdu.
  • שיטה לשליחת הודעת טקסט ב-SMS בלי לכתוב לספק ה-SMS: sendTextMessageWithoutPersisting

CarrierConfigManager

  • השיטה לשליחת ההודעה שונתה: notifyConfigChangedForSubId.
  • שיטה לקבלת הגדרות הספק עבור המינוי שמוגדר כברירת מחדל: getConfig
  • איך מוצאים את ההגדרות של הספק למינוי שצוין: getConfigForSubId

להוראות, ראו הגדרת הספק.

BugreportManager

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

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

מנהל הקצאת הרשאות

EuiccManager

שיטת מעבר למינוי הנתון: switchToSubscription

CarrierMessagingService

שירות שמקבל שיחות מהמערכת כששולחים או מקבלים הודעות SMS ו-MMS חדשות. כדי להרחיב את הכיתה הזו, מגדירים את השירות בקובץ המניפסט עם ההרשאה android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE וכוללים מסנן Intent עם הפעולה #SERVICE_INTERFACE. השיטות כוללות:

  • שיטת סינון של הודעות SMS נכנסות: onFilterSms
  • שיטה ליירוט הודעות SMS שנשלחות מהמכשיר: onSendTextSms
  • שיטה ליירט הודעות SMS בינאריות שנשלחות מהמכשיר: onSendDataSms
  • שיטה ליירוט הודעות SMS ארוכות שנשלחות מהמכשיר: onSendMultipartTextSms
  • שיטה ליירוט הודעות MMS שנשלחות מהמכשיר: onSendMms
  • שיטה להורדת הודעות MMS שהתקבלו: onDownloadMms

CarrierService

שירות שחושף למערכת פונקציות ספציפיות לספק. כדי להרחיב את המחלקה הזו, מגדירים את השירות בקובץ המניפסט של האפליקציה עם ההרשאה android.Manifest.permission#BIND_CARRIER_SERVICES וכוללים מסנן Intent עם הפעולה CARRIER_SERVICE_INTERFACE. אם לשירות יש קישור לטווח ארוך, צריך להגדיר את android.service.carrier.LONG_LIVED_BINDING לערך true במטא-נתונים של השירות.

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

השיטות ב-CarrierService כוללות:

  • כדי לשנות את ההגדרות הספציפיות לספק ולהגדיר אותן: onLoadConfig
  • כדי להודיע למערכת על שינוי מכוון שעומד להתבצע ברשת הספק על ידי אפליקציית הספק: notifyCarrierNetworkChange

ספק טלפוניה

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

WifiNetworkSuggestion

כשיוצרים אובייקט WifiNetworkSuggestion, משתמשים בשיטות הבאות כדי להגדיר מזהה מינויים או קבוצת מינויים:

פלטפורמת Android

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

אימות

כדי לאמת את ההטמעה באמצעות חבילת בדיקת התאימות (CTS) באמצעות CtsCarrierApiTestCases.apk, צריך להיות לכם מפתח UICC עם כללי UICC מתאימים או תמיכה ב-ARF. מבקשים מהספק של כרטיס ה-SIM להכין UICC למפתחים עם ה-ARF הנכון, כפי שמתואר בקטע הזה, ומשתמשים ב-UICC הזה כדי להריץ את הבדיקות. כדי לעבור את בדיקות ה-CTS, לא נדרש שירות סלולרי פעיל ב-UICC.

הכנת ה-UICC

ב-Android מגרסה 11 ומטה, CtsCarrierApiTestCases.apk חתום על ידי aosp-testkey, עם ערך גיבוב 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81.

החל מגרסה Android 12, הקובץ CtsCarrierApiTestCases.apk חתום על ידי cts-uicc-2021-testkey, ערך הגיבוב CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0.

כדי להריץ בדיקות API של ספק CTS ב-Android 12, המכשיר צריך להשתמש בכרטיס SIM עם הרשאות CTS של ספק שעומד בדרישות שמפורטות בגרסה האחרונה של מפרט GSMA TS.48 Test Profile של הצד השלישי.

אפשר להשתמש באותו כרטיס SIM גם בגרסאות של Android שקדמו ל-Android 12.

שינוי פרופיל ה-SIM של CTS

  1. הוספה: הרשאות של ספק CTS במאסטר של כלל הגישה לאפליקציה (ARA-M) או ב-ARF. צריך לקודד את שני החתימות בכללי ההרשאות של הספק:
    1. Hash1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Hash2(SHA256): CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
  2. יצירה: קבצים בסיסיים (EF) של USIM ב-ADF שלא נמצאים ב-TS.48 ונדרשים ל-CTS:
    1. EF_MBDN (6FC7), גודל רשומה: 28, מספר רשומה: 4.
      • תוכן
        1. רשומה 1: 566F696365204D61696CFFFFFFFF0691515555555FF…FF
        2. Rec2-n: ‏ FF…FF
    2. EF_EXT6‏ (6FC8), גודל רשומה:13, מספר רשומה: 1 
      • תוכן: 00FF…FF
        1. EF_MBI‏ (6FC9), גודל רשומה: 4, מספר רשומה: 1
      • תוכן: Rec1: ‏ 01010101
        1. EF_MWIS‏ (6FCA), גודל רשומה: 5, מספר רשומה: 1
      • תוכן: 0000000000
  3. שינוי: טבלת שירותי USIM: הפעלת שירותים n°47, n°48
    1. EF_UST‏ (6F38)
      • תוכן: 9EFFBF1DFFFE0083410310010400406E01
  4. שינוי: קובצי DF-5GS ו-DF-SAIP
    1. DF-5GS - EF_5GS3GPPLOCI‏ (USIM/5FC0/4F01)
      • תוכן: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • תוכן: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • תוכן: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM‏ (USIM/5FD0/4F01)
      • תוכן: A0020000FF…FF
  5. שינוי: משתמשים במחרוזת של שם הספק Android CTS ב-EFs הרלוונטיים שמכילים את הסימון הזה:
    1. EF_SPN‏ (USIM/6F46)
      • תוכן: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • תוכן: Rec1 430B83413759FE4E934143EA14FF..FF

התאמה למבנה של פרופיל הבדיקה

צריך להוריד ולהתאים את הגרסה העדכנית של המבנים הבאים של פרופיל הבדיקה הכללי. בפרופילים האלה לא תתבצע התאמה אישית של הכלל CTS Carrier Privilege או שינויים אחרים שצוינו למעלה.

הרצת בדיקות

לנוחותכם, ב-CTS יש תמיכה בטוקן של מכשיר שמגביל את הפעלת הבדיקות רק במכשירים שהוגדרו עם אותו אסימון. בדיקות CTS של Carrier API תומכות באסימון המכשיר sim-card-with-certs. לדוגמה, הטוקן הבא של המכשיר מגביל את בדיקות ה-API של הספק כך שיפעלו רק במכשיר abcd1234:

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

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

שאלות נפוצות

איך אפשר לעדכן אישורים ב-UICC?

תשובה: משתמשים במנגנון הקיים לעדכון כרטיסים ב-OTA.

האם אפשר לשלב בין UICC לכללים אחרים?

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

מה קורה כשמסירים את ה-UICC מאפליקציה שמסתמכת על האישורים שבתוכו?

תשובה: האפליקציה מאבדת את ההרשאות שלה כי הכללים שמשויכים ל-UICC נמחקים כשה-UICC מוסר.

האם יש הגבלה על מספר האישורים ב-UICC?

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

האם יש הגבלה על מספר ממשקי ה-API שאפשר לתמוך בהם בשיטה הזו?

תשובה: לא, אבל אנחנו מגבילים את ההיקף לממשקי API שקשורים לספק.

האם יש ממשקי API שאסור להשתמש בהם בשיטה הזו? אם כן, איך אתם אוכפים אותן? (כלומר, האם יש לך בדיקות לאימות אילו ממשקי API נתמכים בשיטה הזו?)

תשובה: בקטע API Behavioral Compatibility במסמך ההגדרה של תאימות ל-Android (CDD). יש לנו כמה בדיקות CTS כדי לוודא שמודל ההרשאות של ממשקי ה-API לא השתנה.

איך זה עובד עם התכונה 'כמה כרטיסי SIM'?

א: כרטיס ה-SIM שמוגדר כברירת מחדל שהמשתמש ציין.

האם יש אינטראקציה או חפיפה כלשהי עם טכנולוגיות גישה אחרות של SE, למשל SEEK?

תשובה: לדוגמה, SEEK משתמש באותו AID כמו ב-UICC. כך הכללים יכולים להתקיים זה לצד זה, והם מסוננים על ידי SEEK או על ידי UiccCarrierPrivileges.

מתי כדאי לבדוק את הרשאות הספק?

תשובה: אחרי השידור של סטטוס כרטיס ה-SIM שהוטען.

האם יצרני ציוד מקורי יכולים להשבית חלק מממשקי ה-API של ספקי הסלולר?

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

האם הערך setOperatorBrandOverride מבטל את כל שאר הפורמטים של מחרוזות שמות של אופרטורים? לדוגמה, SE13,‏ UICC SPN או NITZ מבוסס-רשת?

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

מה עושה השיטה injectSmsPdu?

א: השיטה הזו מאפשרת גיבוי/שחזור של הודעות SMS בענן. הקריאה injectSmsPdu מפעילה את פונקציית השחזור.

במסגרת סינון הודעות SMS, האם הקריאה ל-onFilterSms מבוססת על סינון יציאות UDH של SMS? או האם לאפליקציות של ספקי הסלולר יש גישה לכל הודעות ה-SMS הנכנסות?

תשובה: לספקים יש גישה לכל נתוני ה-SMS.

הרחבת DeviceAppID-REF-DO לתמיכה ב-32 בייטים לא תואמת למפרט הנוכחי של GP (שמאפשר 0 או 20 בייטים בלבד). למה אתם משיקים את השינוי הזה? האם SHA-1 לא מספיק כדי למנוע התנגשויות? האם כבר הצעת את השינוי הזה ל-GP, כי יכול להיות שהוא לא תואם לאחור ב-ARA-M/ARF הקיימים?

תשובה: כדי לספק אבטחה שתהיה עמידת לאורך זמן, התוסף הזה כולל את SHA-256 עבור DeviceAppID-REF-DO בנוסף ל-SHA-1, שהיא האפשרות היחידה כרגע בתקן GP SEAC. מומלץ מאוד להשתמש ב-SHA-256.

אם הערך של DeviceAppID הוא 0 (ריק), האם הכלל חל על כל האפליקציות במכשיר שלא חלות עליהן כללים ספציפיים?

תשובה: כדי להשתמש ב-Carrier APIs, צריך לאכלס את השדה DeviceAppID-REF-DO. השדה הזה מיועד למטרות בדיקה ולא מומלץ להשתמש בו לפריסות תפעוליות.

לפי המפרט שלך, לא צריך לקבל PKG-REF-DO שמשמש רק בפני עצמו, ללא DeviceAppID-REF-DO. עם זאת, הוא עדיין מתואר בטבלה 6-4 במפרט כמרחיב את ההגדרה של REF-DO. האם זה מכוון? איך הקוד מתנהג כשמשתמשים רק ב-PKG-REF-DO ב-REF-DO?

תשובה: האפשרות להציג את PKG-REF-DO כפריט ערך יחיד ב-REF-DO הוסרה בגרסה האחרונה. השדה PKG-REF-DO צריך להופיע רק בשילוב עם השדה DeviceAppID-REF-DO.

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

תשובה: אנחנו שומרים את האפשרות הזו לעתיד, ונשמח לקבל הצעות.

האם אפשר להגדיר עוד יותר את DeviceAppID ל-Android באופן ספציפי? זהו ערך הגיבוב (hash) של SHA-1 (20 בייטים) של אישור בעל התוכן הדיגיטלי ששימש לחתימה על האפליקציה הנתונה, אז האם השם לא צריך לשקף את המטרה הזו? (השם עלול לבלבל קוראים רבים, כי הכלל יחול על כל האפליקציות עם אותו אישור של בעל תוכן דיגיטלי).

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