הרשאות ספק UICC

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

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

לספקים יש שליטה מלאה ב-UICC, כך שמנגנון זה מספק דרך מאובטחת וגמישה לנהל אפליקציות ממפעיל הרשת הסלולרית (MNO) המתארחת בערוצי הפצת אפליקציות גנריים (כגון Google Play) תוך שמירה על הרשאות מיוחדות במכשירים וללא צורך כדי לחתום על אפליקציות עם אישור הפלטפורמה לכל מכשיר או להתקין מראש כאפליקציית מערכת.

כללים על UICC

אחסון ב-UICC תואם למפרט GlobalPlatform Secure Element Access Control . מזהה היישום (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 במחרוזת hex היא:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

הכלל על UICC במחרוזת hex הוא:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

תמיכה בקבצי כלל גישה

אנדרואיד 7.0 מוסיפה תמיכה בקריאת כללי הרשאות ספק מקובץ כללי הגישה (ARF).

פלטפורמת אנדרואיד מנסה תחילה לבחור את אפליקציית כלל הגישה (ARA) AID A00000015141434C00 . אם הוא לא מוצא את ה-AID ב-UICC, הוא נופל בחזרה ל-ARF על ידי בחירת PKCS15 AID A000000063504B43532D3135 . לאחר מכן אנדרואיד קורא את קובץ כללי בקרת הגישה (ACRF) ב 0x4300 ומחפש ערכים עם AID FFFFFFFFFFFF . מתעלמים מערכים עם מכשירי AID שונים, כך שכללים למקרי שימוש אחרים יכולים להתקיים במקביל.

תוכן ACRF לדוגמה במחרוזת hex:

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, המכילה את ה-hash של האישור 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . לאפליקציות החתומות על ידי אישור זה מוענקות הרשאות ספק.

ממשקי API מופעלים

אנדרואיד תומך בממשקי ה-API הבאים.

מנהל טלפוניה

טלפוניה התקשרות חוזרת

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

מנהל מנויים

SmsManager

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

CarrierConfigManager

להוראות, ראה תצורת ספק .

BugreportManager

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

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

מנהל אספקה

EuiccManager

שיטה למעבר (לאפשר) את המנוי הנתון: switchToSubscription

CarrierMessagingService

שירות המקבל שיחות מהמערכת כאשר נשלחים או מתקבלים SMS ו-MMS חדשים. כדי להרחיב מחלקה זו, הכריז על השירות בקובץ המניפסט שלך עם ההרשאה android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE וכלול מסנן כוונות עם הפעולה #SERVICE_INTERFACE . השיטות כוללות:

  • שיטה לסינון הודעות SMS נכנסות: onFilterSms
  • שיטה ליירט הודעות SMS שנשלחו מהמכשיר: onSendTextSms
  • שיטה ליירט הודעות SMS בינאריות שנשלחו מהמכשיר: onSendDataSms
  • שיטה ליירט הודעות SMS ארוכות שנשלחות מהמכשיר: onSendMultipartTextSms
  • שיטה ליירט הודעות MMS שנשלחו מהמכשיר: onSendMms
  • שיטה להורדת הודעות MMS שהתקבלו: onDownloadMms

CarrierService

שירות החושף למערכת פונקציות ספציפיות לספק. כדי להרחיב את המחלקה הזו, הכריז על השירות בקובץ המניפסט של האפליקציה עם ההרשאה android.Manifest.permission#BIND_CARRIER_SERVICES וכלול מסנן כוונות עם הפעולה CARRIER_SERVICE_INTERFACE . אם לשירות יש כריכה ארוכת חיים, הגדר את android.service.carrier.LONG_LIVED_BINDING ל- true במטא נתונים של השירות.

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

השיטות ב- CarrierService כוללות:

  • כדי לעקוף ולהגדיר את התצורות הספציפיות לספק: onLoadConfig
  • כדי ליידע את המערכת על שינוי מכוון של רשת הספק על ידי אפליקציית הספק: notifyCarrierNetworkChange

ספק טלפוניה

ממשקי API של ספקי תוכן לאפשר שינויים (הוספה, מחיקה, עדכון, שאילתה) במסד הנתונים של הטלפוניה. שדות ערכים מוגדרים ב- Telephony.Carriers ; לפרטים נוספים, עיין בהפניה למחלקת Telephony

הצעה WifiNetwork

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

פלטפורמת אנדרואיד

ב-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

עבור אנדרואיד 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 .

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

ניתן להשתמש באותו SIM גם עבור גרסאות שקדמו לאנדרואיד 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 אלמנטריים (EFs) שאינם קיימים ב-TS.48 ונדרשים עבור CTS:
    1. EF_MBDN (6FC7), גודל רשומה: 28, מספר רשומה: 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: אפשר שירותים 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 ב-EFs בהתאמה המכילים את הכינוי הזה:
    1. EF_SPN (USIM/6F46)
      • תוכן: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • תוכן: Rec1 430B83413759FE4E934143EA14FF..FF

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

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

הפעלת בדיקות

מטעמי נוחות, 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 במסמך הגדרת תאימות אנדרואיד (CDD). יש לנו כמה בדיקות CTS כדי לוודא שמודל ההרשאה של ממשקי ה-API לא משתנה.

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

ת: נעשה שימוש ב-SIM ברירת המחדל שצוין על ידי המשתמש.

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

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

מתי זה זמן טוב לבדוק את הרשאות הספק?

ת: לאחר שידור מצב ה-SIM נטען.

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

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

האם setOperatorBrandOverride עוקף את כל הצורות האחרות של מחרוזות שם אופרטור? לדוגמה, SE13, UICC SPN או NITZ מבוסס רשת?

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

מה עושה הקריאה לשיטת injectSmsPdu ?

ת: שיטה זו מאפשרת גיבוי/שחזור SMS בענן. הקריאה injectSmsPdu מאפשרת את פונקציית השחזור.

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

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