הרשאות ספק 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

תמיכה בקובץ כלל גישה (ARF).

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

מנהל טלפוניה

SmsManager

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

CarrierConfigManager

שיטה להודיע ​​על שינוי תצורה: notifyConfigChangedForSubId . להנחיות, ראה תצורת ספק .

CarrierMessagingService

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

ספק טלפוניה

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

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

ב-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 Carrier Privileges ב-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
  1. צור : 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
  2. שנה: טבלת שירות USIM: אפשר שירותים n°47, n°48
    1. EF_UST (6F38)
      • תוכן: 9EFFBF1DFFFE0083410310010400406E01
  3. שנה : קבצי DF-5GS ו-DF-SAIP
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • תוכן: FFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • תוכן: FFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    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
  4. שנה : מחרוזות שמות הספק יהיו 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 מבוסס רשת?

ת: עיין בערך SPN ב- TelephonyManager

מה עושה הקריאה לשיטת 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 .