यूआईसीसी कैरियर विशेषाधिकार

एंड्रॉइड 5.1 ने यूनिवर्सल इंटीग्रेटेड सर्किट कार्ड (यूआईसीसी) ऐप्स के मालिकों के लिए प्रासंगिक एपीआई के लिए विशेष विशेषाधिकार प्रदान करने के लिए एक तंत्र पेश किया। एंड्रॉइड प्लेटफॉर्म यूआईसीसी पर संग्रहीत प्रमाणपत्रों को लोड करता है और इन प्रमाणपत्रों द्वारा हस्ताक्षरित ऐप्स को मुट्ठी भर विशेष एपीआई को कॉल करने की अनुमति देता है।

एंड्रॉइड 7.0 ने यूआईसीसी वाहक विशेषाधिकार नियमों के लिए अन्य भंडारण स्रोतों का समर्थन करने के लिए इस सुविधा को बढ़ाया, नाटकीय रूप से उन वाहकों की संख्या में वृद्धि की जो एपीआई का उपयोग कर सकते हैं। API संदर्भ के लिए, कैरियरकॉन्फ़िगमैनेजर देखें; निर्देशों के लिए, कैरियर कॉन्फ़िगरेशन देखें।

वाहकों के पास UICC का पूर्ण नियंत्रण होता है, इसलिए यह तंत्र उपकरणों पर विशेष विशेषाधिकार बनाए रखते हुए और आवश्यकता के बिना जेनेरिक ऐप वितरण चैनलों (जैसे Google Play) पर होस्ट किए गए मोबाइल नेटवर्क ऑपरेटर (MNO) से ऐप्स को प्रबंधित करने का एक सुरक्षित और लचीला तरीका प्रदान करता है। प्रति-डिवाइस प्लेटफ़ॉर्म प्रमाणपत्र वाले ऐप्स पर हस्ताक्षर करने या सिस्टम ऐप के रूप में प्रीइंस्टॉल करने के लिए।

यूआईसीसी पर नियम

UICC पर संग्रहण GlobalPlatform Secure Element Access Control विनिर्देश के साथ संगत है। कार्ड पर एप्लिकेशन आइडेंटिफायर (AID) A00000015141434C00 है, और मानक GET DATA कमांड का उपयोग कार्ड पर संग्रहीत नियमों को लाने के लिए किया जाता है। आप इन नियमों को कार्ड ओवर-द-एयर (OTA) अपडेट के माध्यम से अपडेट कर सकते हैं।

डेटा पदानुक्रम

यूआईसीसी नियम निम्नलिखित डेटा पदानुक्रम का उपयोग करते हैं (कोष्ठक में दो-वर्ण अक्षर और संख्या संयोजन ऑब्जेक्ट टैग है)। प्रत्येक नियम 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 प्रमाणपत्र है:

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

एक्सेस रूल फाइल (एआरएफ) सपोर्ट

एंड्रॉइड 7.0 एक्सेस रूल फाइल (एआरएफ) से कैरियर विशेषाधिकार नियमों को पढ़ने के लिए समर्थन जोड़ता है।

Android प्लेटफ़ॉर्म पहले एक्सेस रूल एप्लेट (ARA) एप्लिकेशन आइडेंटिफ़ायर (AID) A00000015141434C00 का चयन करने का प्रयास करता है। यदि इसे UICC पर AID नहीं मिलता है, तो यह PKCS15 AID A000000063504B43532D3135 का चयन करके ARF पर वापस आ जाता है। Android फिर 0x4300 पर एक्सेस कंट्रोल रूल्स फ़ाइल (ACRF) को 0x4300 है और AID FFFFFFFFFFFF के साथ प्रविष्टियों की तलाश करता है। विभिन्न AID वाली प्रविष्टियों को अनदेखा कर दिया जाता है, इसलिए अन्य उपयोग के मामलों के नियम सह-अस्तित्व में हो सकते हैं।

हेक्स स्ट्रिंग में उदाहरण ACRF सामग्री:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

उदाहरण अभिगम नियंत्रण शर्तें फ़ाइल (एसीसीएफ) सामग्री:

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 का पता है, जिसमें प्रमाणपत्र हैश 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . इस प्रमाणपत्र द्वारा हस्ताक्षरित ऐप्स को वाहक विशेषाधिकार दिए गए हैं।

सक्षम एपीआई

एंड्रॉइड निम्नलिखित एपीआई का समर्थन करता है।

टेलीफोनी प्रबंधक

• एक चुनौती/प्रतिक्रिया के लिए वाहक ऐप को UICC से पूछने की अनुमति देने की विधि: getIccAuthentication ।
• यह जांचने की विधि कि क्या कॉलिंग ऐप को वाहक विशेषाधिकार दिए गए हैं: hasCarrierPrivileges ।
• ब्रांड और नंबर को ओवरराइड करने के तरीके:
  • setOperatorBrandOverride
  • setLine1NumberForDisplay
  • setVoiceMailNumber
• सीधे यूआईसीसी संचार के लिए तरीके:
  • iccOpenLogicalChannel
  • iccCloseLogicalChannel
  • iccExchangeSimIO
  • iccTransmitApduLogicalChannel
  • iccTransmitApduBasicChannel
  • sendEnvelopeWithStatus
• डिवाइस मोड को ग्लोबल पर सेट करने के तरीके: setPreferredNetworkTypeToGlobal ।

एसएमएस प्रबंधक

कॉल करने वाले को नए आने वाले एसएमएस संदेश बनाने की अनुमति देने की विधि: injectSmsPdu ।

कैरियरकॉन्फ़िगरेशनप्रबंधक

कॉन्फ़िगरेशन को सूचित करने का तरीका बदल गया: notifyConfigChangedForSubId । निर्देशों के लिए, कैरियर कॉन्फ़िगरेशन देखें।

कैरियर मैसेजिंग सेवा

सेवा जो नए एसएमएस और एमएमएस भेजे या प्राप्त होने पर सिस्टम से कॉल प्राप्त करती है। इस वर्ग का विस्तार करने के लिए, android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE अनुमति के साथ अपनी मेनिफेस्ट फ़ाइल में सेवा की घोषणा करें और #SERVICE_INTERFACE क्रिया के साथ एक इंटेंट फ़िल्टर शामिल करें। विधियों में शामिल हैं:

• onFilterSms
• onSendTextSms
• onSendDataSms
• onSendMultipartTextSms
• onSendMms
• onDownloadMms

टेलीफोनी प्रदाता

सामग्री प्रदाता एपीआई टेलीफोनी डेटाबेस में संशोधन (सम्मिलित करें, हटाएं, अपडेट करें, क्वेरी) की अनुमति दें। मान फ़ील्ड को Telephony.Carriers पर परिभाषित किया गया है; अधिक जानकारी के लिए, developer.android.com पर टेलीफोनी एपीआई संदर्भ देखें।

एंड्रॉइड प्लेटफॉर्म

पहचाने गए UICC पर, प्लेटफ़ॉर्म आंतरिक UICC ऑब्जेक्ट बनाता है जिसमें UICC के हिस्से के रूप में वाहक विशेषाधिकार नियम शामिल होते हैं। UiccCarrierPrivilegeRules.java नियमों को लोड करता है, उन्हें UICC कार्ड से पार्स करता है, और उन्हें मेमोरी में कैश करता है। जब एक विशेषाधिकार जांच की आवश्यकता होती है, UiccCarrierPrivilegeRules एक-एक करके अपने स्वयं के नियमों के साथ कॉलर प्रमाणपत्र की तुलना करता है। यदि UICC को हटा दिया जाता है, तो UICC ऑब्जेक्ट के साथ नियम नष्ट हो जाते हैं।

मान्यकरण

CtsCarrierApiTestCases.apk का उपयोग करके संगतता परीक्षण सूट (CTS) के माध्यम से कार्यान्वयन को मान्य करने के लिए, आपके पास सही UICC नियमों या ARF समर्थन के साथ एक डेवलपर UICC होना चाहिए। आप अपनी पसंद के सिम कार्ड विक्रेता से इस खंड में वर्णित सही एआरएफ के साथ एक डेवलपर यूआईसीसी तैयार करने के लिए कह सकते हैं और परीक्षण चलाने के लिए उस यूआईसीसी का उपयोग कर सकते हैं। यूआईसीसी को सीटीएस परीक्षण पास करने के लिए सक्रिय सेलुलर सेवा की आवश्यकता नहीं है।

यूआईसीसी की तैयारी

Android 11 और इसके बाद के संस्करण के लिए, CtsCarrierApiTestCases.apk पर aosp-testkey द्वारा हस्ताक्षरित है, हैश मान 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 के साथ 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 हैश मान 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 .

Android 12 में CTS वाहक API परीक्षण चलाने के लिए, डिवाइस को तृतीय-पक्ष GSMA TS.48 परीक्षण प्रोफ़ाइल विनिर्देश के नवीनतम संस्करण में निर्दिष्ट आवश्यकताओं को पूरा करने वाले CTS वाहक विशेषाधिकारों के साथ एक सिम का उपयोग करने की आवश्यकता है।

उसी सिम का उपयोग Android 12 से पहले के संस्करणों के लिए भी किया जा सकता है।

सीटीएस सिम प्रोफाइल को संशोधित करना

1. जोड़ें : एआरए-एम या एआरएफ में सीटीएस कैरियर विशेषाधिकार। दोनों हस्ताक्षर वाहक विशेषाधिकार नियमों में एन्कोड किए जाने चाहिए:
   1. हैश1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
   2. हैश2(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

नोट: यदि ARF का उपयोग कर रहे हैं, तो AID के साथ ACRF: FFFFFFFFFFFFFF को एक एकल ACCF को इंगित करना चाहिए जो हैश 1 और हैश 2 दोनों को एन्कोड करता है।

2. बनाएँ : ADF USIM EFs TS.48 में मौजूद नहीं हैं और CTS के लिए आवश्यक हैं:
   1. EF_MBDN (6FC7), रिकॉर्ड आकार: 28, रिकॉर्ड संख्या: 4
      • विषय
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. आरई 2-एन: एफएफ ... एफएफ
   2. EF_EXT6 (6FC8), रिकॉर्ड आकार:13, रिकॉर्ड संख्या: 1
      • सामग्री: 00FF…FF
        1. EF_MBI (6FC9), रिकॉर्ड आकार: 4, रिकॉर्ड संख्या: 1
      • सामग्री: Rec1: 01010101
        1. EF_MWIS (6FCA), रिकॉर्ड आकार: 5, रिकॉर्ड संख्या: 1
      • सामग्री: 000000000000
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. संशोधित करें : इस पदनाम वाले संबंधित ईएफ में कैरियर नाम स्ट्रिंग एंड्रॉइड सीटीएस होगी:
   1. EF_SPN (USIM/6F46)
      • सामग्री: 01416E64726F696420435453FF..FF
   2. EF_PNN (USIM/6FC5)
      • सामग्री: Rec1 430B83413759FE4E934143EA14FF..FF

परीक्षण प्रोफ़ाइल संरचना का मिलान

निम्न सामान्य परीक्षण प्रोफ़ाइल संरचनाओं के नवीनतम संस्करण को डाउनलोड करें और उनका मिलान करें। इन प्रोफ़ाइलों में CTS कैरियर विशेषाधिकार नियम वैयक्तिकृत या ऊपर सूचीबद्ध अन्य संशोधन नहीं होंगे।

• GSMA TS.48 सामान्य परीक्षण प्रोफ़ाइल संरचना
• उदाहरण TS.48 eSIM DER प्रारूप में प्रोफ़ाइल

चल रहे परीक्षण

सुविधा के लिए, सीटीएस एक उपकरण टोकन का समर्थन करता है जो परीक्षणों को केवल उसी टोकन के साथ कॉन्फ़िगर किए गए उपकरणों पर चलाने के लिए प्रतिबंधित करता है। कैरियर API CTS परीक्षण डिवाइस टोकन sim-card-with-certs का समर्थन करते हैं। उदाहरण के लिए, निम्न डिवाइस टोकन वाहक API परीक्षणों को केवल डिवाइस abcd1234 पर चलने के लिए प्रतिबंधित करता है:

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

डिवाइस टोकन का उपयोग किए बिना परीक्षण चलाते समय, परीक्षण सभी उपकरणों पर चलता है।

सामान्य प्रश्न

UICC पर प्रमाणपत्रों को कैसे अद्यतन किया जा सकता है?

ए: मौजूदा कार्ड ओटीए अपडेट तंत्र का प्रयोग करें।

क्या यूआईसीसी अन्य नियमों के साथ सह-अस्तित्व में है?

ए: यूआईसीसी पर एक ही सहायता के तहत अन्य सुरक्षा नियमों का होना ठीक है; प्लेटफ़ॉर्म उन्हें स्वचालित रूप से फ़िल्टर कर देता है।

क्या होता है जब यूआईसीसी को उस ऐप के लिए हटा दिया जाता है जो उस पर प्रमाण पत्र पर निर्भर करता है?

ए: ऐप अपने विशेषाधिकार खो देता है क्योंकि यूआईसीसी से जुड़े नियम यूआईसीसी को हटाने पर नष्ट हो जाते हैं।

क्या UICC पर प्रमाणपत्रों की संख्या की कोई सीमा है?

ए: प्लेटफ़ॉर्म प्रमाणपत्रों की संख्या को सीमित नहीं करता है; लेकिन क्योंकि चेक रैखिक है, बहुत से नियमों में चेक के लिए विलंब हो सकता है।

क्या एपीआई की संख्या की कोई सीमा है जिसे हम इस पद्धति से समर्थन कर सकते हैं?

उ: नहीं, लेकिन हम इसके दायरे को कैरियर-संबंधित API तक सीमित करते हैं।

क्या कुछ एपीआई इस पद्धति का उपयोग करने से प्रतिबंधित हैं? यदि हां, तो आप उन्हें कैसे लागू करते हैं? (अर्थात, क्या आपके पास यह सत्यापित करने के लिए परीक्षण हैं कि कौन से API इस पद्धति से समर्थित हैं?)

उ: Android संगतता परिभाषा दस्तावेज़ (CDD) का "API व्यवहार संगतता" अनुभाग देखें। हमारे पास यह सुनिश्चित करने के लिए कुछ सीटीएस परीक्षण हैं कि एपीआई का अनुमति मॉडल नहीं बदला गया है।

यह मल्टी-सिम फीचर के साथ कैसे काम करता है?

ए: उपयोगकर्ता द्वारा निर्दिष्ट डिफ़ॉल्ट सिम का उपयोग किया जाता है।

क्या यह किसी भी तरह से अन्य SE एक्सेस तकनीकों के साथ इंटरैक्ट या ओवरलैप करता है, उदाहरण के लिए, SEEK?

उ: उदाहरण के तौर पर, SEEK UICC की तरह ही AID का उपयोग करता है। इसलिए नियम सह-अस्तित्व में हैं और SEEK या UiccCarrierPrivileges द्वारा फ़िल्टर किए जाते हैं।

वाहक विशेषाधिकारों की जांच करने का यह एक अच्छा समय कब है?

ए: सिम राज्य लोड होने के बाद प्रसारण।

क्या ओईएम कैरियर एपीआई के हिस्से को अक्षम कर सकते हैं?

उ: नहीं। हम मानते हैं कि वर्तमान एपीआई न्यूनतम सेट हैं, और हम भविष्य में बारीक ग्रैन्युलैरिटी नियंत्रण के लिए बिट मास्क का उपयोग करने की योजना बना रहे हैं।

क्या setOperatorBrandOverride ऑपरेटर नाम स्ट्रिंग के अन्य सभी रूपों को ओवरराइड करता है? उदाहरण के लिए, SE13, UICC SPN, या नेटवर्क-आधारित NITZ?

उ: TelephonyManager में SPN प्रविष्टि का संदर्भ लें

injectSmsPdu विधि कॉल क्या करता है?

ए: यह विधि क्लाउड में एसएमएस बैकअप/पुनर्स्थापना की सुविधा प्रदान करती है। injectSmsPdu कॉल पुनर्स्थापना फ़ंक्शन को सक्षम करता है।

एसएमएस फ़िल्टरिंग के लिए, एसएमएस यूडीएच पोर्ट फ़िल्टरिंग पर आधारित onFilterSms एसएमएस कॉल है? या क्या कैरियर ऐप्स के पास आने वाले सभी एसएमएस तक पहुंच है?

ए: वाहक के पास सभी एसएमएस डेटा तक पहुंच है।

32 बाइट्स का समर्थन करने के लिए DeviceAppID-REF-DO का विस्तार वर्तमान GP युक्ति (जो केवल 0 या 20 बाइट्स की अनुमति देता है) के साथ असंगत प्रतीत होता है, तो आप यह परिवर्तन क्यों पेश कर रहे हैं? टकराव से बचने के लिए SHA-1 पर्याप्त नहीं है? क्या आपने इस परिवर्तन को जीपी में पहले ही प्रस्तावित कर दिया है, क्योंकि यह मौजूदा एआरए-एम/एआरएफ के साथ पिछड़ा असंगत हो सकता है?

उ: भविष्य में सुरक्षित सुरक्षा प्रदान करने के लिए, यह एक्सटेंशन SHA-1 के अलावा DeviceAppID-REF-DO के लिए SHA-256 पेश करता है, जो वर्तमान में GP SEAC मानक में एकमात्र विकल्प है। हम SHA-256 का उपयोग करने की अत्यधिक अनुशंसा करते हैं।

यदि DeviceAppID 0 (खाली) है, तो क्या आप उन सभी डिवाइस ऐप्स पर नियम लागू करते हैं जो किसी विशिष्ट नियम के अंतर्गत नहीं आते हैं?

उ: कैरियर API के लिए DeviceAppID-REF-DO को पॉप्युलेट करना आवश्यक है। खाली होने का उद्देश्य परीक्षण उद्देश्यों के लिए है और परिचालन परिनियोजन के लिए अनुशंसित नहीं है।

आपकी युक्ति के अनुसार, PKG-REF-DO केवल स्वयं के द्वारा उपयोग किया जाता है, बिना DeviceAppID-REF-DO के, स्वीकार नहीं किया जाना चाहिए। लेकिन यह अभी भी तालिका 6-4 में REF-DO की परिभाषा को विस्तारित करने के रूप में वर्णित है। क्या यह उद्देश्य पर है? जब REF-DO में केवल PKG-REF-DO REF-DO उपयोग किया जाता है तो कोड कैसे व्यवहार करता है?

उ: REF-DO में PKG-REF-DO REF-DO एकल मान आइटम के रूप में रखने का विकल्प नवीनतम संस्करण में हटा दिया गया था। PKG-REF-DO केवल DeviceAppID-REF-DO के संयोजन में होना चाहिए।

हम मानते हैं कि हम सभी वाहक-आधारित अनुमतियों तक पहुंच प्रदान कर सकते हैं या बेहतर नियंत्रण रख सकते हैं। यदि हां, तो बिट मास्क और वास्तविक अनुमतियों के बीच मानचित्रण को क्या परिभाषित करता है? प्रति वर्ग एक अनुमति? प्रति विधि एक अनुमति? क्या लंबे समय में 64 अलग-अलग अनुमतियां पर्याप्त हैं?

ए: यह भविष्य के लिए आरक्षित है, और हम सुझावों का स्वागत करते हैं।

क्या आप Android के लिए विशेष रूप से DeviceAppID को परिभाषित कर सकते हैं? यह प्रकाशक प्रमाणपत्र का SHA-1 (20 बाइट्स) हैश मान है जिसका उपयोग दिए गए ऐप पर हस्ताक्षर करने के लिए किया जाता है, तो क्या नाम उस उद्देश्य को नहीं दर्शाता है? (नाम कई पाठकों के लिए भ्रमित करने वाला हो सकता है क्योंकि नियम तब उसी प्रकाशक प्रमाणपत्र से हस्ताक्षरित सभी ऐप्स पर लागू होता है।)

उ: DeviceAppID सर्टिफिकेट मौजूदा स्पेक द्वारा समर्थित है। हमने गोद लेने की बाधा को कम करने के लिए विशिष्ट परिवर्तनों को कम करने का प्रयास किया। विवरण के लिए, UICC पर नियम देखें।