הרשאות של ספק 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. אם המערכת לא מוצאת את ה-AID ב-UICC, היא חוזרת ל-ARF על ידי בחירת ה-AID של PKCS15‏ A000000063504B43532D3135. מערכת Android קוראת את קובץ הכללים של בקרת הגישה (ACRF) בנתיב 0x4300 ומחפשת רשומות עם AID‏ FFFFFFFFFFFF. מערכת AdSense מתעלמת מכללים עם מזהי כללים שונים, כך שכללים לתרחישי שימוש אחרים יכולים להתקיים במקביל.

דוגמה לתוכן 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

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

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 של צד שלישי.

אפשר להשתמש באותו כרטיס 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), record size: 28, record number: 4 
      • תוכן
        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.