הרשאות ספק ב-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.
    • ה-SHA-1 נשמר על ידי DeviceAppID-REF-DO (C1) (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 מנסה לבחור את האפליקציה של כלל הגישה (ARA) AID A00000015141434C00. אם לא מוצאים את את ה-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 הבאים.

מנהל טלפוניה

התקשרות חזרה בטלפון

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

מנהל המינויים

SmsManager

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

CarrierConfigManager

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

מנהל הדיווחים

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

מנהל סטטיסטיקות רשת

ImsMmTelManager

imsRcsManager

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

מנהל EuiccManager

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

שירות העברת הודעות של ספק

שירות שמקבל שיחות מהמערכת כאשר נשלחות הודעות 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

הצעת רשת Wi-Fi

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

פלטפורמת Android

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

אימות

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

הכנת ה-UICC

ב-Android מגרסה 11 ומטה, CtsCarrierApiTestCases.apk היא נחתם על ידי aosp-testkey, עם ערך גיבוב (hash) 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, ערך גיבוב (hash) 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 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. יצירה: קבצים בסיסיים של ADF USIM שלא קיימים ב TS.48 והנדרש עבור CTS:
    1. EF_MBDN (6FC7), גודל רשומה: 28, מספר רשומה: 4
      • תוכן
        1. Rec1: 566F696365204D61696CFFFFFF06915155555555FF...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 ב-EF בהתאמה, המכיל את הסיווג הזה:
    1. EF_SPN (USIM/6F46)
      • תוכן: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • תוכן: Rec1 430B83413759FE4E934143EA14FF..FF

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

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

הרצת בדיקות

מטעמי נוחות, CTS תומך באסימון מכשיר שמגביל את הגישה פועלות רק במכשירים שהוגדרו עם אותו אסימון. CTS של ממשק 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 מבוסס-רשת?

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

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

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