ב-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 בייטים.
- ה-SHA-1 נשמר על ידי
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 הבאים.
מנהל טלפוניה
- שיטה שמאפשרת לאפליקציית הספק לבקש מ-UICC לאתגר או לתשובה:
getIccAuthentication
- שיטה לבדיקה אם לאפליקציית השיחות ניתנה הרשאה לספק הסלולר
הרשאות:
hasCarrierPrivileges
- שיטות לשינוי המותג ומספר הטלפון:
- שיטות לתקשורת ישירה עם UICC:
- שיטה להגדרת מצב המכשיר כגלובלי:
setPreferredNetworkTypeToGlobal
- שיטות לקבלת הזהויות של המכשיר או הרשת:
- IMEI (International Mobile Equipment Identity):
getImei
- מזהה ציוד נייד (MEID):
getMeid
- מזהה גישה לרשת (NAI):
getNai
- המספר הסידורי של ה-SIM:
getSimSerialNumber
- IMEI (International Mobile Equipment Identity):
- שיטה לקבלת הגדרות הספק:
getCarrierConfig
- שיטה לקבלת סוג הרשת להעברת נתונים:
getDataNetworkType
- שיטה לקבלת סוג הרשת לשירות קולי:
getVoiceNetworkType
- שיטות לקבלת מידע על אפליקציית UICC SIM (USIM):
- המספר הסידורי של ה-SIM:
getSimSerialNumber
- פרטי הכרטיס:
getUiccCardsInfo
- GID1 (מזהה קבוצה 1):
getGroupIdLevel1
- מחרוזת מספר טלפון לשורה 1:
getLine1Number
- רשת סלולרית ציבורית (PLMN) אסורה:
getForbiddenPlmns
- הערך המקביל של PLMN לבית:
getEquivalentHomePlmns
- המספר הסידורי של ה-SIM:
- שיטות קבלה או הגדרה של מספר דואר קולי:
- שיטה לשליחת קוד חייגן מיוחד:
sendDialerSpecialCode
- שיטה לאיפוס מודם הרדיו:
rebootModem
- שיטות להפעלה או להגדרה של מצבי בחירת רשת:
- הדרך לבקש סריקת רשת:
requestNetworkScan
- שיטות קבלה או הגדרה של סוגי הרשתות המותרים/המועדפים:
- שיטות לבדיקה אם חבילת הגלישה או הנדידה מופעלות לפי הגדרות המשתמש:
- שיטות לבדיקה או להגדרה של חבילת גלישה לפי סיבה:
- שיטה לאיתור רשימת מספרי החירום:
getEmergencyNumberList
- שיטות לשליטה ברשתות ההזדמנויות:
- שיטות להגדרה או לניקוי של בקשה לעדכון עוצמת האות הסלולרי:
התקשרות חזרה בטלפון
ל-TelephonyCallback
יש ממשקים עם שיטת קריאה חוזרת כדי
שליחת התראות לאפליקציית השיחות כשהמצבים הרשומים משתנים:
- האינדיקטור של ההודעה בהמתנה השתנה:
onMessageWaitingIndicatorChanged
- האינדיקטור של העברת השיחות השתנה:
onCallForwardingIndicatorChanged
- הגורם לניתוק השיחה ממערכת המולטימדיה (IMS) של IP השתנה:
onImsCallDisconnectCauseChanged
- המצב המדויק של חיבור הנתונים השתנה:
onPreciseDataConnectionStateChanged
- הרשימה הנוכחית של מספרי החירום השתנתה:
onEmergencyNumberListChanged
- מזהה המינוי לנתונים פעילים השתנה:
onActiveDataSubscriptionIdChanged
- רשת הספק השתנתה:
onCarrierNetworkChange
- רישום הרשת או עדכון של אזור המעקב או המיקום, הניתוב או האזור
נכשל:
onRegistrationFailed
- השינוי במידע על החסימה:
onBarringInfoChanged
- התצורה הנוכחית של הערוץ הפיזי השתנתה:
onPhysicalChannelConfigChanged
מנהל המינויים
- שיטות לקבלת מידע על מינויים שונים:
- שיטה לקבלת מספר המינויים הפעילים:
getActiveSubscriptionInfoCount
- שיטות לניהול קבוצות מינויים:
- שיטות לקבלת התיאור של תוכנית היחסים לחיוב או להגדרת התיאור שלה בין ספק למנוי ספציפי:
- שיטה לביטול זמני את תוכנית היחסים של החיוב בין
ספק ומנוי ספציפי כדי להיחשב כחיוב ללא חיוב:
setSubscriptionOverrideUnmetered
- שיטה לביטול זמני את תוכנית היחסים של החיוב בין
ספק ומנוי ספציפי ייחשבו עמוסים:
setSubscriptionOverrideCongested
- שיטה לבדיקה אם האפליקציה עם ההקשר הנתון
מורשה לנהל את המינוי הנתון בהתאם למטא-נתונים שלו:
canManageSubscription
SmsManager
- שיטה שמאפשרת למתקשר ליצור הודעות SMS נכנסות חדשות:
injectSmsPdu
- שיטה לשליחת הודעת SMS מבוססת-טקסט בלי לכתוב אל ה-SMS
ספק:
sendTextMessageWithoutPersisting
CarrierConfigManager
- השיטה לשליחת התראה שונתה:
notifyConfigChangedForSubId
- שיטה להצגת הגדרה של ספק למינוי ברירת המחדל:
getConfig
- שיטה לאחזור הגדרות הספק למינוי שצוין:
getConfigForSubId
הוראות מופיעות הגדרות הספק.
מנהל הדיווחים
שיטה ליצירת דוח על באג בקישוריות, שהוא גרסה מיוחדת של
דוח איתור באגים שכולל רק מידע על ניפוי באגים שקשור לקישוריות
בעיות:
startConnectivityBugreport
מנהל סטטיסטיקות רשת
- שיטה לשליחת שאילתה על סיכום השימוש ברשת:
querySummary
- שיטה לשליחת שאילתה על היסטוריית השימוש ברשת:
queryDetails
- שיטות לרישום או לביטול הרישום של קריאה חוזרת (callback) של שימוש ברשת:
ImsMmTelManager
- שיטות לרישום או לביטול הרישום של רישום IMS MmTel:
imsRcsManager
- שיטות לרישום או לביטול הרישום של קריאה חוזרת לרישום IMS RCS:
- שיטות לקבלת מצב הרישום של IMS או סוג ההעברה:
מנהל הקצאת הרשאות
- שיטות לרישום וביטול רישום של עדכונים להקצאת תכונות IMS קריאה חוזרת:
- שיטות שקשורות לסטטוס ההקצאה של יכולת IMS MmTel או RCS:
מנהל 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
, צריך להשתמש בתנאים הבאים
שיטות להגדרת מזהה מינוי או קבוצת מינויים:
- השיטה להגדרת מזהה מינוי:
setSubscriptionId
- Metohd כדי להגדיר קבוצת מינויים:
setSubscriptionGroup
פלטפורמת 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
- הוספה: הרשאות ספק CTS ב:
ראשי אפליקציות של כלל גישה (ARA-M) או ARF. שתי החתימות חייבות להיות
מקודדים בכללי ההרשאות של הספק:
- Hash1(SHA1):
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
- 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
- Hash1(SHA1):
- יצירה: קבצים בסיסיים של ADF USIM שלא קיימים ב
TS.48 והנדרשים עבור CTS:
- EF_MBDN (6FC7), גודל רשומה: 28, מספר רשומה: 4
- תוכן
- Rec1: 566F696365204D61696CFFFFFF06915155555555FF...FF
- Rec2-n: FF...FF
- תוכן
- EF_EXT6 (6FC8), גודל רשומה:13, מספר רשומה: 1
- תוכן: 00FF...FF
- EF_MBI (6FC9), גודל רשומה: 4, מספר רשומה: 1
- תוכן: Rec1: 01010101
- EF_MWIS (6FCA), גודל רשומה: 5, מספר רשומה: 1
- תוכן: 0000000000
- תוכן: 00FF...FF
- EF_MBDN (6FC7), גודל רשומה: 28, מספר רשומה: 4
- שינוי: טבלת השירות של USIM: הפעלת שירותים n°47, n°48
- EF_UST (6F38)
- תוכן:
9EFFBF1DFFFE0083410310010400406E01
- תוכן:
- EF_UST (6F38)
- שינוי: קובצי DF-5GS ו-DF-SAIP
- DF-5GS – EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- תוכן:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- תוכן:
- DF-5GS – EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
- תוכן:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- תוכן:
- DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
- תוכן:
A0020000FF…FF
- תוכן:
- DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
- תוכן:
A0020000FF…FF
- תוכן:
- DF-5GS – EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- שינוי: שימוש במחרוזת שם הספק Android CTS
ב-EF בהתאמה, המכיל את הסיווג הזה:
- EF_SPN (USIM/6F46)
- תוכן:
01416E64726F696420435453FF..FF
- תוכן:
- EF_PNN (USIM/6FC5)
- תוכן:
Rec1 430B83413759FE4E934143EA14FF..FF
- תוכן:
- EF_SPN (USIM/6F46)
התאמה למבנה של פרופיל הבדיקה
צריך להוריד ולהתאים את הגרסה האחרונה של המבנים הבאים של פרופיל הבדיקה הכללי. הכללים של הרשאות הספק 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 מבוסס-רשת?
כן, השינוי של מותג המפעיל נמצא בעדיפות הגבוהה ביותר. אם הוא מוגדר, הוא מבטל את כל הערכים צורות אחרות של מחרוזות שמות אופרטורים.
מה עושה השיטה 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.