Android 5.1 a introdus un mecanism de acordare de privilegii speciale pentru API-uri relevante pentru proprietarii de aplicații pentru carduri de circuit integrat universal (UICC). PlatformaAndroid încarcă certificatele stocate pe un UICC și acordă permisiuneaaplicațiilor semnate de aceste certificate de a efectua apeluri către o mână de API-uri speciale.
Android 7.0 a extins această caracteristică pentru a suporta alte surse de stocare pentru regulile de privilegii ale purtătorilor UICC, crescând în mod dramaticnumărul de purtători care pot utiliza API-urile. Pentru o referință API,a se vedea CarrierConfigManager; pentru instrucțiuni,a se vedea CarrierConfiguration.
Transportatorii dețin controlul deplin al UICC, astfel încât acest mecanism oferă o modalitate sigură și flexibilă de a gestiona aplicațiile operatorului de rețea mobilă (MNO)găzduite pe canalele generice de distribuție a aplicațiilor (cum ar fi Google Play), păstrând în același timp privilegii speciale pe dispozitive și fără a fi nevoie de a semna aplicațiile cucertificatul de platformă pentru fiecare dispozitiv sau de a le preinstala ca aplicație de sistem.
Reguli pe UICC
Stocarea pe UICC este compatibilă cu specificațiaGlobalPlatformSecure Element Access Control. Identificatorul aplicației (AID) de pe card este A00000015141434C00, iar comanda standardGET DATA este utilizată pentru a prelua regulile stocate pe card. Aceste reguli pot fi actualizate prin intermediul actualizărilor over-the-air (OTA) ale cardului.
Hierarhia datelor
Regulile UICC utilizează următoarea ierarhie de date (combinația de două caractere litere ș i numere între paranteze reprezintă eticheta obiect). Fiecare regulă esteREF-AR-DO (E2) și constă dintr-o concatenare de REF-DO și AR-DO:
-
REF-DO(E1) conțineDeviceAppID-REF-DOsau o concatenare deDeviceAppID-REF-DOșiPKG-REF-DO.-
DeviceAppID-REF-DO(C1) stochează semnătura SHA-1 (20 de octeți) sau SHA-256 (32 de octeți) a certificatului. -
PKG-REF-DO(CA) este șirul complet al numelui pachetului definit în manifest, codificat ASCII, cu o lungime maximă de 127 de octeți.
-
-
AR-DO(E3) este extins pentru a includePERM-AR-DO(DB), care este o mască de 8 octeți reprezentând 64 de permisiuni separate.
Dacă PKG-REF-DO nu este prezent, orice aplicație semnată de certificat are acces; în caz contrar, atât certificatul, cât și numele pachetului trebuie să corespundă.
Exemplu de regulă
Numele aplicației este com.google.android.apps.myapp, iar certificatulSHA-1 în șirul hexazecimal este:
AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4
Regula pe UICC în șirul hexazecimal este:
E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001
Suport pentru fișierul de reguli de acces (ARF)
Android 7.0 adaugă suport pentru citirea regulilor de privilegii ale purtătorului din fișierul de reguli de acces (ARF).
Platforma Android încearcă mai întâi să selecteze appletul de reguli de acces (ARA)identificatorul de aplicație (AID) A00000015141434C00. Dacă nu găsește AID-ul pe UICC, revine la ARF prin selectarea PKCS15 AIDA000000063504B43532D3135. Android citește apoi fișierul de reguli de control al accesului (ACRF) la 0x4300 și caută intrări cu AID FFFFFFFFFFFF. Intrările cu AID-uri diferite sunt ignorate, sorțile pentru alte cazuri de utilizare pot coexista.
Exemplu de conținut ACRF în șir hexagonal:
30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10
Exemplu de conținut al fișierului de condiții de control al accesului (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
În exemplul de mai sus, 0x4310 este adresa pentru ACCF, careconține hash-ul certificatului61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Aplicațiilor semnate de acest certificat li se acordă privilegii de purtător.
Apps activate
Android acceptă următoarele API-uri.
TelephonyManager
- Metodă pentru a permite aplicației de purtător să ceară UICC o provocare/un răspuns:
getIccAuthentication. - Metodă pentru a verifica dacă aplicației apelante i-au fost acordate privilegii de purtător:
hasCarrierPrivileges. - Metode pentru a suprascrie marca și numărul:
-
setOperatorBrandOverride -
setLine1NumberForDisplay -
setVoiceMailNumber
-
- Metode pentru comunicarea directă cu UICC:
-
iccOpenLogicalChannel -
iccCloseLogicalChannel -
iccExchangeSimIO -
iccTransmitApduLogicalChannel -
iccTransmitApduBasicChannel -
sendEnvelopeWithStatus
-
- Metode de setare a modului dispozitivului la global:
setPreferredNetworkTypeToGlobal.
SmsManager
Metodă pentru a permite apelantului să creeze noi mesaje SMS primite: injectSmsPdu.
CarrierConfigManager
Metodă pentru a notifica modificarea configurației: notifyConfigChangedForSubId. Pentru instrucțiuni, consultațiCarrier Configuration.
CarrierMessagingService
Serviciu care primește apeluri de la sistem atunci când sunt trimise sau primite noi SMS și MMS. Pentru a extinde această clasă, declarați serviciul în fișierul manifest cu permisiunea android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICEpermission și includeți un filtru de intenție cu acțiunea #SERVICE_INTERFACEaction. Metodele includ:
-
onFilterSms -
onSendTextSms -
onSendDataSms -
onSendMultipartTextSms -
onSendMms -
onDownloadMms
Furnizor de telefonie
Furnizor de conținut API pentru a permite modificări (inserare, ștergere, actualizare, interogare)la baza de date de telefonie. Câmpurile de valori sunt definite laTelephony.Carriers; pentru mai multe detalii, consultațiReferința API de telefonie pe developer.android.com.
Platforma Android
Pe un UICC detectat, platforma construiește obiecte interne UICC careinclude reguli de privilegii ale operatorului ca parte a UICC.UiccCarrierPrivilegeRules.javaîncarcă regulile, le analizează de pe cardul UICC și le memorează în cache. Atunci când este necesară o verificare a privilegiilor, UiccCarrierPrivilegeRules compară certificatul apelantului cu propriile reguli, una câte una. Dacă UICC este îndepărtată, regulile sunt distruse împreună cu obiectul UICC.
Validare
Compatibility Test Suite (CTS) include teste pentru API-urile de purtător înCtsCarrierApiTestCases.apk. Deoarece această caracteristică depinde de certificatele de pe UICC, trebuie să pregătiți UICC pentru a trece aceste teste.
Pregătirea UICC
În mod implicit, CtsCarrierApiTestCases.apk este semnat de cheia Androiddeveloper, cu valoarea hash61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Testele tipăresc, de asemenea, hash-ul așteptat al certificatului în cazul în care certificatele de pe UICC nu corespund.
Exemplu de ieșire:
junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81
Pentru a valida implementarea prin CTS folosindCtsCarrierApiTestCases.apk, trebuie să aveți un UICC de dezvoltator cu regulile UICC corecte sau cu suport ARF. Puteți cere furnizorului de cartele SIM ales de dumneavoastră să pregătească un UICC de dezvoltare cu ARF corect, așa cum este descris în această secțiune, și să utilizați acel UICC pentru a efectua testele. UICC nu necesită un serviciu celular activ pentru a trece testele CTS.
Executarea testelor
Pentru comoditate, CTS suportă un token de dispozitiv care restricționează testele pentru a fi executate numai pe dispozitive configurate cu același token. Testele CTS Carrier API CTSsusțin token-ul de dispozitiv sim-card-with-certs. De exemplu, următorul token de dispozitiv restricționează testele API pentru operatorii de transport să ruleze numai pe dispozitivulabcd1234:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
Când se execută un test fără a utiliza un token de dispozitiv, testul rulează pe toate dispozitivele.
FAQ
Cum pot fi actualizate certificatele pe UICC?
A: Utilizați mecanismul de actualizare OTA al cardului existent.
Poate coexista UICC cu alte reguli?
R: Este în regulă să aveți alte reguli de securitate pe UICC sub același AID; platforma le filtrează automat.
Ce se întâmplă atunci când UICC este îndepărtat pentru o aplicație care se bazează pe certificatele de pe acesta?
R: Aplicația își pierde privilegiile deoarece regulile asociate cu UICC sunt distruse la eliminarea UICC.
Există o limită a numărului de certificate de pe UICC?
R: Platforma nu limitează numărul de certificate; dar deoarece verificarea este liniară, prea multe reguli pot genera o latență pentru verificare.
Există o limită a numărului de API-uri pe care le putem susține cu această metodă?
A: Nu, dar limităm domeniul de aplicare la API-urile legate de operator.
Există unele API-uri cărora le este interzisă utilizarea acestei metode? Dacă da, cum le aplicați? (adică, aveți teste pentru a valida ce API-uri sunt acceptate cu această metodă?)
A: Consultați secțiunea „API Behavioral Compatibility” dinAndroid Compatibility DefinitionDocument (CDD). Avem câteva teste CTS pentru a ne asigura că modelul de permisiune al API-urilor nu este modificat.
Cum funcționează acest lucru cu caracteristica multi-SIM?
R: Se utilizează SIM-ul implicit specificat de utilizator.
A: Se utilizează SIM-ul implicit specificat de utilizator.
Acest lucru interacționează sau se suprapune în vreun fel cu alte tehnologii de acces SE, de exemplu, SEEK?
R: Ca exemplu, SEEK utilizează același AID ca pe UICC. Deci, regulilecoexistă și sunt filtrate fie de SEEK, fie de UiccCarrierPrivileges.
Când este un moment bun pentru a verifica privilegiile operatorului?
A: După difuzarea statului SIM încărcat.
Poate OEM să dezactiveze o parte din API-urile operatorului?
A: Nu. Credem că API-urile actuale reprezintă setul minim, iar în viitor plănuim să folosim masca de biți pentru un control de granularitate mai fină.
Aceasta setOperatorBrandOverride anulează TOATE celelalte forme de șiruri de nume de operator? De exemplu, SE13, UICC SPN sau NITZ bazat pe rețea?
R: Consultați intrarea SPN dinTelephonyManager
Ce face apelul metodei injectSmsPdu?
R: Această metodă facilitează salvarea/restaurarea SMS-urilor în cloud. ApelulinjectSmsPdu activează funcția de restaurare.
Pentru filtrarea SMS-urilor, apelul onFilterSms se bazează pe filtrarea portului UDH al SMS-urilor? Sau aplicațiile operatorilor au acces la TOATE SMS-urile primite?
R: Operatorii au acces la toate datele SMS.
Extinderea lui DeviceAppID-REF-DO pentru a suporta32 de octeți pare a fiincompatibilă cu specificația actuală a GP (care permite doar 0 sau 20 de octeți), deci de ce introduceți această modificare? Nu este SHA-1 suficient pentru a evita coliziunile? Ați propus deja această modificare la GP, deoarece aceasta ar putea fi incompatibilă cu ARA-M/ARF existente?
A: Pentru a oferi o securitate sigură pentru viitor, această extensie introduce SHA-256 pentru DeviceAppID-REF-DO în plus față de SHA-1, care este în prezent singura opțiune din standardul GP SEAC. Recomandăm cu insistență utilizarea SHA-256.
Dacă DeviceAppID este 0 (gol), aplicați regula tuturor aplicațiilor de dispozitiv care nu sunt acoperite de o regulă specifică?
A: API-urile operatorilor necesită ca DeviceAppID-REF-DO să fie completat.Faptul că DeviceAppID-REF-DO este gol este destinat testării și nu este recomandat pentru implementări operaționale.
Conform specificațiilor dumneavoastră, PKG-REF-DO folosit doar ca atare, fără DeviceAppID-REF-DO, nu ar trebui să fie acceptat. Dareste în continuare descris în tabelul 6-4 ca extinzând definiția luiREF-DO. Este acest lucru intenționat? Cum se comportă codul atunci când doar PKG-REF-DO este utilizat în REF-DO?
A: Opțiunea de a avea PKG-REF-DO ca un singur element de valoare în REF-DO a fost eliminată în ultima versiune. ar trebui să apară numai în combinație cu DeviceAppID-REF-DO.
Să presupunem că putem acorda acces la toate permisiunile bazate pe purtător sau să avem un control mai fin. Dacă este așa, ce definește corespondența dintre masca de biți și permisiunile reale? O permisiune pentru fiecare clasă? O permisiune pe metodă? Sunt 64 de permisiuni separate suficiente pe termen lung?
R: Acest lucru este rezervat pentru viitor și salutăm sugestiile.
Puteți să definiți mai bine DeviceAppID pentru Android în mod specific? Aceasta este valoarea hash SHA-1 (20 de octeți) a certificatului de publicare folosit pentru a semna aplicația dată, deci nu ar trebui ca numele să reflecte acest scop? (Denumirea ar putea crea confuzie pentru mulți cititori, deoarece regula este aplicabilă tuturor aplicațiilor semnate cu același certificat Publisher.)
R: DeviceAppID pentru stocarea certificatelor este susținută de specificația existentă. Am încercat să minimizăm modificările specificațiilor pentru a reduce bariera pentru adoptare. Pentru detalii, consultați Reguli privind UICC.
.