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

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

ב-Android 7.0, התכונה הזו הורחבה כדי לתמוך במקורות אחסון אחרים לכללי הרשאות של ספקי 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. אם המערכת לא מוצאת את מזהה האפליקציה ב-UICC, היא חוזרת ל-ARF על ידי בחירת מזהה האפליקציה 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 יש ממשקי API עם שיטת קריאה חוזרת כדי להודיע לאפליקציה ששולחת את הקריאה כשמצבי הרישום משתנים:

SubscriptionManager

SmsManager

CarrierConfigManager

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

פיתוח פתרונות

שיטה לקבלת המספר הסידורי של החומרה, אם הוא זמין: getSerial

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 שכוללים כללים של הרשאות ספק כחלק מה-UICC. UiccCarrierPrivilegeRules.java טוען כללים, מנתח אותם מכרטיס ה-UICC ומאחסן אותם במטמון בזיכרון. כשנדרשת בדיקת הרשאות, UiccCarrierPrivilegeRules משווה את האישור של המתקשר לכללים שלו בזה אחר זה. אם כרטיס ה-UICC מוסר, הכללים נהרסים יחד עם אובייקט ה-UICC.

אימות

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

הכנת כרטיס ה-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 carrier API ב-Android 12, המכשיר צריך להשתמש בכרטיס SIM עם הרשאות CTS carrier שעומדות בדרישות שצוינו בגרסה האחרונה של מפרט GSMA TS.48 Test Profile של צד שלישי עם ADM1 קבוע, מפתח = 55555555 / 0x3535353535353535.

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

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

  1. הוספה: הרשאות של ספק CTS ב-access rule app master (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 
      • Content
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…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 ב-EF המתאימים שמכילים את הסימון הזה:
    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 במסמך ההגדרה של תאימות (CDD) של Android. יש לנו כמה בדיקות CTS כדי לוודא שמודל ההרשאות של ממשקי ה-API לא השתנה.

איך זה עובד עם תכונת ה-Multi-SIM?

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

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

תשובה: לדוגמה, SEEK משתמש באותו מזהה אפליקציה כמו ב-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 (ריק), האם הכלל חל על כל האפליקציות במכשיר שלא מכוסות על ידי כלל ספציפי?

תשובה: ממשקי API של ספקי תקשורת דורשים מילוי של 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 לאנדרואיד באופן ספציפי? זהו ערך הגיבוב (hash) של אישור בעל האפליקציה (20 בייט) בפורמט SHA-1 שמשמש לחתימה על האפליקציה הנתונה, אז לא צריך להיות שיקוף של המטרה הזו בשם? (השם עלול לבלבל הרבה קוראים כי הכלל חל על כל האפליקציות שנחתמו באותו אישור של מפרסם).

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