UICC Carrier Privileges

Posted on by admin

Android 5.1:ssä otettiin käyttöön mekanismi, jonka avulla UICC-sovellusten (Universal Integrated Circuit Card) omistajille voidaan myöntää erityiset oikeudet API-rajapintoihin. Android-alusta lataa UICC-kortille tallennettuja varmenteita ja myöntää näillä varmenteilla allekirjoitetuille sovelluksille luvan kutsua kourallista erityisiä API:ita.

Android 7.0 laajensi tätä ominaisuutta tukemaan muita UICC-kortin operaattoreiden etuoikeussääntöjä tukevia tallennuslähteitä, mikä lisäsi huomattavasti niiden operaattoreiden lukumäärää, jotka voivat käyttää näitä API:ita. API-viittaus löytyy kohdasta CarrierConfigManager; ohjeet löytyvät kohdasta CarrierConfiguration.

UICC on täysin operaattoreiden hallinnassa, joten tämä mekanismi tarjoaa turvallisen ja joustavan tavan hallita matkaviestinverkko-operaattorin (MNO) sovelluksia, joita isännöidään yleisissä sovellusten jakelukanavissa (kuten Google Play), samalla kun laitteilla säilytetään erityiset käyttöoikeudet ilman, että sovelluksia tarvitsee allekirjoittaa laitekohtaisella alustavarmennuksella tai esiasentaa järjestelmäsovelluksena.

Säännöt UICC:ssä

Tallennus UICC:ssä on yhteensopivaGlobalPlatformSecure Element Access Control -määrittelyn kanssa. Kortin sovellustunniste(AID) on A00000015141434C00, ja kortille tallennettujen sääntöjen noutamiseen käytetään vakiomuotoistaGET DATAkäskyä. Voit päivittää näitä sääntöjä kortin OTA-päivityksillä.

Tietohierarkia

UICC-säännöt käyttävät seuraavaa tietohierarkiaa (suluissa oleva kaksimerkkinen kirjain- ja numeroyhdistelmä on objektitunniste). Jokainen sääntö onREF-AR-DO (E2) ja koostuu REF-DO:n ja AR-DO:n ketjusta:

  • REF-DO (E1) sisältää DeviceAppID-REF-DO tai DeviceAppID-REF-DO:n ja PKG-REF-DO:n ketjusta.
    • DeviceAppID-REF-DO (C1) tallentaa varmenteen SHA-1- (20 tavua) tai SHA-256- (32 tavua) allekirjoituksen.
    • PKG-REF-DO (CA) on manifestissa määritelty täydellinen paketin nimijono, ASCII-koodattu, pituus enintään 127 tavua.
  • AR-DO (E3) laajennetaan sisältämään PERM-AR-DO (DB), joka on kahdeksan tavun bittinen maski, joka edustaa 64 erillistä käyttöoikeutta.

Jos PKG-REF-DO:tä ei ole, mikä tahansa varmenteella allekirjoitettu sovellus saa käyttöoikeuden; muussa tapauksessa sekä varmenteen että pakettinimen täytyy täsmätä.

Sääntöesimerkki

Sovelluksen nimi on com.google.android.apps.myapp jaSHA-1-varmenne hex-merkkijonossa on:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

Sääntö UICC:ssä hex-merkkijonossa on:

E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001

Käyttösääntötiedoston (ARF) tuki

Android 7.0 lisää tuen operaattorin etuoikeussääntöjen lukemiselle accessrule-tiedostosta (ARF).

Android-alusta yrittää ensin valita access rule applet (ARA)application identifier (AID) A00000015141434C00. Jos se ei löydä AID:tä UICC:stä, se palaa ARF:ään valitsemalla PKCS15 AIDA000000063504B43532D3135. Android lukee sitten ACRF-tiedoston (Access Control Rules File) osoitteessa 0x4300 ja etsii merkintöjä, joiden AID FFFFFFFFFFFF. Merkinnät, joilla on eri AID:t, jätetään huomiotta, ja muiden käyttötapausten säännöt voivat olla rinnakkain.

Esimerkki ACRF:n sisällöstä hex-merkkijonona:

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

Esimerkki ACCF:n (access control conditions file, access control conditions file, ACCF) sisällöstä:

30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

Ylläolevassa esimerkissä 0x4310 on ACCF:n osoite, joka sisältää varmenteen hash61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Tämän varmenteen allekirjoittamille sovelluksille myönnetään operaattorin oikeudet.

Ohjattuja sovellusrajapintoja

Android tukee seuraavia sovellusrajapintoja.

TelephonyManager

  • Menetelmä, jolla operaattorisovellus voi pyytää UICC:ltä haastetta/vastausta:getIccAuthentication.
  • Menetelmä, jolla voidaan tarkastaa, onko kutsuvalle sovellukselle myönnetty operaattorin oikeudet:hasCarrierPrivileges.
  • Menetelmät merkin ja numeron ohittamiseksi:
    • setOperatorBrandOverride
    • setLine1NumberForDisplay
    • setVoiceMailNumber
  • Menetelmät suoraa UICC-viestintää varten:
    • iccOpenLogicalChannel
    • iccCloseLogicalChannel
    • iccExchangeSimIO
    • iccTransmitApduLogicalChannel
    • iccTransmitApduBasicChannel
    • sendEnvelopeWithStatus
  • Menetelmät laitetilan asettamiseksi globaaliksi:setPreferredNetworkTypeToGlobal.

SmsManager

Menetelmä, jolla soittaja voi luoda uusia saapuvia tekstiviestejä: injectSmsPdu.

CarrierConfigManager

Menetelmä, jolla ilmoitetaan muuttuneesta kokoonpanosta: notifyConfigChangedForSubId. Ohjeet, katsoCarrier Configuration.

CarrierMessagingService

Palvelu, joka vastaanottaa kutsuja järjestelmästä, kun uusia tekstiviestejä ja MMS:iä lähetetään tai vastaanotetaan. Jos haluat laajentaa tätä luokkaa, ilmoita palvelu manifestitiedostossasi android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICEluvalla ja sisällytä intent-suodatin #SERVICE_INTERFACEtoiminnolla. Metodeja ovat mm:

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

Telefoonipalveluntarjoaja

Sisällöntarjoaja-API:t, jotka mahdollistavat puhelintietokannan muokkaamisen (lisääminen, poistaminen, päivittäminen, kysely). Arvokentät on määriteltyTelephony.Carriers; lisätietoja on osoitteessaTelephony API reference on developer.android.com.

Android-alusta

Havaitulla UICC:llä alusta rakentaa sisäisiä UICC-objekteja, jotkasisällyttävät operaattorin etuoikeussäännöt osana UICC:tä.UiccCarrierPrivilegeRules.javaLataa säännöt, jäsentää ne UICC-kortilta ja tallentaa ne välimuistiin. Kun tarvitaan etuoikeustarkistusta, UiccCarrierPrivilegeRules vertaa soittajan todistusta omiin sääntöihinsä yksi kerrallaan. Jos UICC-kortti poistetaan, säännöt tuhoutuvat UICC-olion mukana.

Validointi

Yhteensopivuustestipaketti (CTS) sisältää testejä operaattorin API-rajapinnoille CtsCarrierApiTestCases.apk. Koska tämä ominaisuus riippuu UICC:n varmenteista, sinun on valmisteltava UICC läpäisemään nämä testit.

UICC:n valmistelu

Vakiossa CtsCarrierApiTestCases.apk on allekirjoitettu Androiddeveloper-avaimella, jonka hash-arvo on61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Testit tulostavat myös odotetun varmenteen hash-arvon, jos UICC:ssä olevat varmenteet poikkeavat toisistaan.

Esimerkkitulosteet:

junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81

Voidaksesi validoida toteutuksen CTS:n kautta käyttäenCtsCarrierApiTestCases.apk, sinulla on oltava kehittäjän UICC, jossa on oikeat UICC-säännöt tai ARF-tuki. Voit pyytää valitsemaasi SIM-korttitoimittajaa valmistelemaan kehittäjä-UICC:n, jossa on oikea ARF tässä jaksossa kuvatulla tavalla, ja käyttää tätä UICC:tä testien suorittamiseen. UICC ei vaadi aktiivista matkapuhelinpalvelua läpäistäkseen CTS-testit.

Testien suorittaminen

Mukavuuden vuoksi CTS tukee laitetunnusta, joka rajoittaa testien suorittamisen vain laitteisiin, jotka on konfiguroitu samalla tunnuksella. Carrier API CTS-testit tukevat laitetunnusta sim-card-with-certs. Esimerkiksi seuraava laitetunniste rajoittaa operaattori-API-testit suorittamaan vain laitteessaabcd1234:

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

Kun testi suoritetaan ilman laitetunnistetta, testi suoritetaan kaikilla laitteilla.

Kysymys

Miten varmenteita voidaan päivittää UICC:ssä?

A: Käytä nykyistä kortin OTA-päivitysmekanismia.

Voidaanko UICC:llä käyttää rinnakkain muita sääntöjä?

V: UICC:llä voi olla muita turvallisuussääntöjä samassa AID:ssä; alusta suodattaa ne automaattisesti pois.

Mitä tapahtuu, kun UICC poistetaan sovellukselta, joka on riippuvainen sen varmenteista?

V: Sovellus menettää oikeutensa, koska UICC:hen liittyvät säännöt tuhoutuvat UICC:n poistamisen yhteydessä.

Onko UICC:ssä olevien varmenteiden lukumäärää rajoitettu?

V: Alusta ei rajoita varmenteiden lukumäärää, mutta koska tarkistus on lineaarinen, liian monista säännöistä voi aiheutua viive tarkistuksessa.

Onko olemassa rajoitus niiden API:iden määrälle, joita voimme tukea tällä menetelmällä?

A: Ei, mutta rajoitamme soveltamisalan operaattoriin liittyviin API:iin.

Onko joitakin API:ita kielletty käyttämästä tätä menetelmää? Jos on, miten valvotte niiden noudattamista? (eli onko teillä testejä, joilla validoitte, mitkä API:t tukevat tätä menetelmää?)

V: KatsoAndroidin yhteensopivuusmäärittelyasiakirjan (CDD) kohta ”API Behavioral Compatibility”. Meillä on joitakin CTS-testejä varmistaaksemme, että API:iden käyttöoikeusmalli ei muutu.

Miten tämä toimii multi-SIM-ominaisuuden kanssa?

A: Käyttäjän määrittelemää oletus SIM-korttia käytetään.

Meneekö tämä millään tavalla vuorovaikutukseen tai päällekkäisyyksiin muiden SE-käyttötekniikoiden, esimerkiksi SEEKin, kanssa?

A: Esimerkkinä mainittakoon, että SEEKissä käytetään samaa AID-tunnistautumistunnistetta (AID-tunnistetta) kuin UICC:ssä. Joten säännötko-olevat olemassa ja suodatetaan joko SEEKin tai UiccCarrierPrivileges mukaan.

Milloin on hyvä aika tarkistaa operaattorin oikeudet?

A: Kun SIM-tila on ladattu lähetyksen jälkeen.

Voivatko OEM-valmistajat poistaa osan operaattorin API:ista käytöstä?

A: Ei. Uskomme, että nykyiset API:t ovat minimaalinen joukko, ja aiomme käyttää bittimaskia hienojakoisemman rakeisuuden hallintaan tulevaisuudessa.

Osaako setOperatorBrandOverride ohittaa KAIKKI muut operaattorinimijonojen muodot? Esimerkiksi SE13, UICC SPN tai verkkopohjainen NITZ?

A: Katso SPN-merkintäTelephonyManagerissa

Mitä tekee injectSmsPdu-menetelmäkutsu?

A: Tämä menetelmä helpottaa tekstiviestien varmuuskopiointia/palauttamista pilvessä. injectSmsPdu-kutsu ottaa palautustoiminnon käyttöön.

Tekstiviestien suodatuksessa onFilterSms-kutsu perustuuSMS UDH-portin suodatukseen? Vai pääsevätkö operaattorin sovellukset käsiksi KAIKKIIN saapuviin tekstiviesteihin?

A: Operaattorit pääsevät käsiksi kaikkeen tekstiviestidataan.

DeviceAppID-REF-DO:n laajentaminen tukemaan 32 tavua näyttää olevan yhteensopimaton nykyisten GP-spektifikaattien kanssa (jotka sallivat vain 0 tai 20 tavua), joten miksi otatte tämän muutoksen käyttöön? Eikö SHA-1 riitä välttämään törmäyksiä? Oletko jo ehdottanut tätä muutosta GP:lle, koska se voisi olla taaksepäin yhteensopimaton nykyisten ARA-M/ARF:ien kanssa?

A: Tulevaisuuden turvallisuuden varmistamiseksi tämä laajennus ottaa käyttöön SHA-256:n DeviceAppID-REF-DO:lle SHA-1:n lisäksi, joka on tällä hetkellä ainoa vaihtoehto GP SEAC-standardissa. Suosittelemme SHA-256:n käyttöä.

Jos DeviceAppID on 0 (tyhjä), sovelletaanko sääntöä kaikkiin laitesovelluksiin, jotka eivät kuulu tietyn säännön piiriin?

A: Operaattoreiden API:t edellyttävät, että DeviceAppID-REF-DO on täytetty.Tyhjänä oleminen on tarkoitettu testitarkoituksiin, eikä sitä suositella toiminnallisiin käyttöönottoihin.

Spesifikaatioiden mukaan PKG-REF-DO:tä, jota käytetään pelkästään ilman DeviceAppID-REF-DO:aa, ei pitäisi hyväksyä. Se on kuitenkin kuvattu taulukossa 6-4 REF-DO:n määritelmän laajentamisena. Onko tämä tarkoituksella? Miten koodi käyttäytyy, kun REF-DO:ssä käytetään vain PKG-REF-DO:tä?

A: Viimeisimmässä versiossa poistettiin mahdollisuus käyttää PKG-REF-DO:tä yksittäisenä arvoelementtinä REF-DO:ssä. PKG-REF-DO pitäisi esiintyä vain yhdessä DeviceAppID-REF-DO:n kanssa.

Edellytämme, että voimme myöntää pääsyn kaikkiin kantajiin perustuviin käyttöoikeuksiintai hallita niitä tarkemmin. Jos näin on, mikä määrittelee bittimaskin ja todellisten oikeuksien välisen yhdistelmän? Yksi oikeus per luokka? Yksi lupa per menetelmä? Riittääkö 64 erillistä lupaa pitkällä aikavälillä?

V: Tämä on varattu tulevaisuutta varten, ja otamme mielellämme vastaan ehdotuksia.

Voitteko määritellä tarkemmin DeviceAppID Android-kohtaisesti? Tämä on kyseisen sovelluksen allekirjoittamiseen käytetyn Publishersertifikaatin SHA-1 (20 tavua) hash-arvo, joten eikö nimen pitäisi heijastaa tätä tarkoitusta? (Nimi voi hämmentää monia lukijoita, koska sääntö koskee kaikkia sovelluksia, jotka on allekirjoitettu samalla Publisher-varmenteella.)

A: Varmenteiden tallentamista DeviceAppID tuetaan nykyisessä speksissä. Yritimme minimoida spekseihin tehtävät muutokset, jotta käyttöönoton esteet olisivat pienemmät. Lisätietoja on kohdassa UICC:n säännöt.

Vastaa

Sähköpostiosoitettasi ei julkaista.