הרשאות של ספק 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 יש ממשקים עם שיטת קריאה חוזרת כדי להודיע לאפליקציה ששולחת את הקריאה כשהמצבים הרשומים משתנים:

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 או שינויים אחרים שמפורטים למעלה.

הרצת בדיקות

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

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