הרשאות של ספק UICC

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

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

לספקים יש שליטה מלאה על 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 של אפליקציית כלל הגישה (ARA)‏ A00000015141434C00. אם ה-AID לא נמצא ב-UICC, המערכת חוזרת ל-ARF על ידי בחירת ה-AID של PKCS15‏ 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 יש ממשקים עם שיטת קריאה חוזרת (callback) כדי להודיע לאפליקציה הקוראת כשהמצבים הרשומים משתנים:

SubscriptionManager

SmsManager

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

CarrierConfigManager

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

הוראות מופיעות במאמר הגדרת ספק.

BugreportManager

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

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

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.

אימות

כדי לאמת את ההטמעה באמצעות Compatibility Test Suite‏ (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.

כדי להריץ בדיקות CTS של ממשק API לספק שירותי סלולר ב-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) של ADF USIM שלא נמצאים ב-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: הפעלת השירותים מס' 47, מס' 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' במסמך ההגדרה של תאימות Android‏ (CDD). יש לנו כמה בדיקות CTS כדי לוודא שמודל ההרשאות של ממשקי ה-API לא השתנה.

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

תשובה: נעשה שימוש בכרטיס ה-SIM שמוגדר כברירת מחדל על ידי המשתמש.

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

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

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

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

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

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

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

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

מה עושה קריאת ה-method‏ 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.

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

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

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

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