זכויות הספק של UICC

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

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

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

כללים בנושא UICC

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

תוכן 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 מופעלים

Android תומך בממשקי ה- 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.

מַתַן תוֹקֵף

כדי לאמת את הביצוע באמצעות בדיקת התאימות 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 מבחן מפרט.

אותו SIM יכול לשמש גם לגרסאות לפני אנדרואיד 12.

שינוי פרופיל ה- SIM CTS

  1. להוסיף: הרשאות Carrier 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
  1. צור: ADF USIM מקדמי הפליטה לא נוכח 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)
      • תוכן: FFFFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF -5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • תוכן: FFFFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    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. שינוי: מחרוזות שם ספק תהיינה CTS אנדרואיד ב מקדמי פליטה בהתאמה המכילות ייעוד זה:
    1. EF_SPN (USIM/6F46)
      • תוכן: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • תוכן: Rec1 430B83413759FE4E934143EA14FF..FF

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

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

ריצות מבחנים

מטעמי נוחות, 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 תחת אותו סיוע; הפלטפורמה מסננת אותם באופן אוטומטי.

מה קורה כאשר הסרת ה- UICC עבור אפליקציה המסתמכת על התעודות עליה?

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

האם יש הגבלה על מספר התעודות ב- UICC?

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

האם יש גבול למספר ממשקי ה- API שנוכל לתמוך בהם בשיטה זו?

ת: לא, אך אנו מגבילים את ההיקף לממשקי API הקשורים למוביל.

האם יש כמה ממשקי API שאסורים להשתמש בשיטה זו? אם כן, כיצד אוכפים אותם? (כלומר, האם יש לך בדיקות לאמת אילו ממשקי API נתמכים בשיטה זו?)

ת: עיין בסעיף "API התנהגות התאימות" של מסמך הגדרת תאימות אנדרואיד (CDD) . יש לנו כמה בדיקות CTS כדי לוודא שמודל ההרשאה של ממשקי ה- API לא משתנה.

איך זה עובד עם תכונת ה- multi-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 לא מספיק כדי למנוע התנגשויות? האם כבר הצעת את השינוי הזה לרופא המשפחה, מכיוון שזה עלול להיות בלתי תואם לאחור עם ARA-M/ARF קיים?

ת: מתן ביטחון בעתיד הוכחה, הרחבה זו מציגה SHA-256 עבור DeviceAppID-REF-DO בנוסף SHA-1, אשר נמצא כעת האפשרות היחידה בתקן GP SEAC. אנו ממליצים בחום להשתמש ב- SHA-256.

אם DeviceAppID הוא 0 (ריק), אתה להחיל את הכלל לכל מכשיר אפליקציות שאינן מכוסות על ידי חוק ספציפי?

ת: APIs Carrier דורשים 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 .