UICC Carrier Privileges

Posted on by admin

Android 5.1 introducerede en mekanisme til at tildele særlige privilegier til API’er, der er relevante for ejere af UICC-apps (Universal Integrated Circuit Card). Android-platformen indlæser certifikater, der er gemt på et UICC, og giver apps, der er underskrevet af disse certifikater, tilladelse til at foretage kald til en håndfuld særlige API’er.

Android 7.0 udvidede denne funktion til at understøtte andre lagringskilder til regler for UICC-operatørprivilegier, hvilket dramatisk øger antallet af operatører, der kan bruge API’erne. For en API-reference, se CarrierConfigManager; for instruktioner, se CarrierConfiguration.

Selskaberne har fuld kontrol over UICC’en, så denne mekanisme giver en sikker og fleksibel måde at administrere apps fra mobilnetværksoperatøren (MNO), der er hostet på generiske app-distributionskanaler (f.eks. Google Play), samtidig med at de bevarer særlige rettigheder på enhederne, og uden at det er nødvendigt at signere apps med platformcertifikatet pr. enhed eller forudinstallere dem som en systemapp.

Regler på UICC

Lagring på UICC’en er kompatibel med specifikationen forGlobalPlatformSecure Element Access Control. Applikationsidentifikatoren (AID) på kortet er A00000015141434C00, og standardkommandoenGET DATA anvendes til at hente regler, der er lagret på kortet. Du kan opdatere disse regler via OTA-opdateringer (over-the-air) på kortet.

Datahierarki

UICC-regler anvender følgende datahierarki (kombinationen af to bogstaver og tal i parentes er objektmærket). Hver regel erREF-AR-DO (E2) og består af en sammenkædning af REF-DO og AR-DO:

  • REF-DO (E1) indeholder DeviceAppID-REF-DO eller en sammenkædning af DeviceAppID-REF-DO og PKG-REF-DO.
    • DeviceAppID-REF-DO DeviceAppID-REF-DO (C1) gemmer certifikatets SHA-1- (20 bytes) eller SHA-256- (32 bytes) signatur.
    • PKG-REF-DO (CA) er den fulde pakke-navnsstreng defineret i manifestet, ASCII-kodet, maks. længde 127 bytes.
  • AR-DO (E3) er udvidet til at omfatte PERM-AR-DO (DB), som er en 8-byte bitmaske, der repræsenterer 64 separate tilladelser.

Hvis PKG-REF-DO ikke er til stede, gives der adgang til enhver app, der er underskrevet af certifikatet; ellers skal både certifikatet og pakkenavnet passe sammen.

Regleeksempel

Appnavnet er com.google.android.apps.myapp, ogSHA-1-certifikatet i hex-streng er:

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

Reglen på UICC i hex-streng er:

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

Understøttelse af adgangsregelfil (ARF)

Android 7.0 tilføjer understøttelse af læsning af regler for carrierprivilegier fra accessrule-filen (ARF).

Android-platformen forsøger først at vælge access rule applet (ARA)application identifier (AID) A00000015141434C00. Hvis den ikke kan finde AID’en på UICC’en, går den tilbage til ARF ved at vælge PKCS15 AIDA000000063504B43532D3135. Android læser derefter ACRF-filen (Access Control Rules File) på 0x4300 og leder efter poster med AID FFFFFFFFFFFF. Indtastninger med andre AID’er ignoreres, og der kan eksistere regler for andre anvendelsestilfælde.

Eksempel på ACRF-indhold i hex-streng:

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

Eksempel på indhold i ACCF (Access Control Conditions File):

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

I eksemplet ovenfor er 0x4310 adressen for ACCF, som indeholder certifikatets hash61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Apps, der er signeret af dette certifikat, er tildelt carrierprivilegier.

aktiverede API’er

Android understøtter følgende API’er.

TelephonyManager

  • Metode til at tillade carrier-appen at bede UICC om en udfordring/svar:getIccAuthentication.
  • Metode til at kontrollere, om den kaldende app er blevet tildelt carrierprivilegier:hasCarrierPrivileges.
  • Metoder til at tilsidesætte mærke og nummer:
    • setOperatorBrandOverride
    • setLine1NumberForDisplay
    • setVoiceMailNumber
  • Metoder til direkte UICC-kommunikation:
    • iccOpenLogicalChannel
    • iccCloseLogicalChannel
    • iccExchangeSimIO
    • iccTransmitApduLogicalChannel
    • iccTransmitApduBasicChannel
    • sendEnvelopeWithStatus
  • Metoder til at indstille enhedstilstand til global:setPreferredNetworkTypeToGlobal.

SmsManager

Metode til at give opkalder mulighed for at oprette nye indgående SMS-beskeder: injectSmsPdu.

CarrierConfigManager

Metode til at underrette om ændret konfiguration: injectSmsPdu: notifyConfigChangedForSubId. Du kan finde instruktioner underCarrier Configuration.

CarrierMessagingService

Tjeneste, der modtager opkald fra systemet, når der sendeseller modtages nye SMS og MMS. Hvis du vil udvide denne klasse, skal du erklære tjenesten i din manifestfil med android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICEtilladelse og inkludere et intenstfilter med #SERVICE_INTERFACEhandling. Metoderne omfatter:

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

Telefoniudbyder

Indholdsudbyder-API’er til at tillade ændringer (indsæt, slet, opdatering, forespørgsel)i telefonidatabasen. Værdifelter er defineret påTelephony.Carriers; for flere detaljer henvises tilTelephony API-reference på developer.android.com.

Android-platform

På et detekteret UICC konstruerer platformen interne UICC-objekter, derinkluderer regler for operatørprivilegier som en del af UICC.UiccCarrierPrivilegeRules.javaindlæser regler, analyserer dem fra UICC-kortet og lagrer dem i hukommelsen. Når der er behov for en privilegiekontrol, sammenligner UiccCarrierPrivilegeRules opkaldercertifikatet med sine egne regler en efter en. Hvis UICC-kortet fjernes, ødelægges reglerne sammen med UICC-objektet.

Validering

The Compatibility Test Suite (CTS) inkluderer test for carrier API’er iCtsCarrierApiTestCases.apk. Da denne funktion afhænger af certifikater på UICC’en, skal du forberede UICC’en for at bestå disse tests.

Forberedelse af UICC’en

Som standard er CtsCarrierApiTestCases.apk signeret af Androiddeveloper-nøglen med hash-værdi61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Testene udskriver også den forventede certifikathashværdi, hvis certifikater på UICC’en ikke stemmer overens.

Eksempel på output:

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

For at validere implementeringen via CTS ved hjælp afCtsCarrierApiTestCases.apk skal du have en udvikler-UICC med de korrekte UICC-regler eller ARF-understøttelse. Du kan bede din SIM-kortleverandør om at forberede en udvikler-UICC med den rigtige ARF som beskrevet i dette afsnit og bruge denne UICC til at udføre testene. UICC’en kræver ikke aktiv mobiltjeneste for at bestå CTS-testene.

Kørsel af testene

For nemheds skyld understøtter CTS et enhedstoken, som begrænser testene til kun at køre på enheder, der er konfigureret med samme token. Carrier API CTS-tests understøtter enhedstokenet sim-card-with-certs. F.eks. begrænser følgende enhedstoken carrier API-tests til kun at køre på enhedabcd1234:

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

Når en test køres uden brug af et enhedstoken, kører testen på alle enheder.

FAQ

Hvordan kan certifikater opdateres på UICC’en?

A: Brug den eksisterende OTA-opdateringsmekanisme til kortet.

Kan UICC eksistere side om side med andre regler?

S: Det er fint at have andre sikkerhedsregler på UICC’en under samme AID; platformen filtrerer dem automatisk fra.

Hvad sker der, når UICC’en fjernes for en app, der er afhængig af certifikaterne på den?

A: Appen mister sine rettigheder, fordi de regler, der er knyttet til UICC’en, ødelægges ved fjernelse af UICC’en.

Er der en grænse for antallet af certifikater på UICC’en?

A: Platformen begrænser ikke antallet af certifikater; men da kontrollen er lineær, kan for mange regler medføre en forsinkelse i forbindelse med kontrollen.

Er der en grænse for antallet af API’er, som vi kan understøtte med denne metode?

SA: Nej, men vi begrænser anvendelsesområdet til carrier-relaterede API’er.

Er der nogle API’er, der er forbudt mod at bruge denne metode? Hvis ja, hvordan håndhæver I dem så? (dvs. har I test til at validere, hvilke API’er der er understøttet med denne metode?)

S: Se afsnittet “API Behavioral Compatibility” iAndroid Compatibility DefinitionDocument (CDD). Vi har nogle CTS-tests for at sikre, at tilladelsesmodellen for API’erne ikke ændres.

Hvordan fungerer dette med multi-SIM-funktionen?

SA: Det standard-SIM, som brugeren har angivet, anvendes.

Har dette på nogen måde interaktion eller overlapning med andre SE-adgangsteknologier, f.eks. SEEK?

SA: Som eksempel bruger SEEK det samme AID som på UICC’en. Så reglerne eksisterer også og filtreres af enten SEEK eller UiccCarrierPrivileges.

Hvornår er det et godt tidspunkt at kontrollere operatørens privilegier?

SA: Efter SIM-tilstandens indlæste udsendelse.

Kan OEM’er deaktivere en del af operatørens API’er?

A: Nej. Vi mener, at de nuværende API’er er det minimale sæt, og vi planlægger at bruge bitmasken til finere granularitetskontrol i fremtiden.

Har setOperatorBrandOverride forrang for ALLE andre former for operatørnavnestrenge? F.eks. SE13, UICC SPN eller netværksbaseret NITZ?

S: Se SPN-posten iTelephonyManager

Hvad gør injectSmsPdu-metodekaldet?

S: Denne metode letter backup/gendannelse af SMS i skyen. injectSmsPdu-opkaldet aktiverer gendannelsesfunktionen.

Er onFilterSms-opkaldet til SMS-filtrering baseret påSMS UDH-portfiltrering? Eller har udbyderapps adgang til ALLE indgående SMS’er?

A: Udbydere har adgang til alle SMS-data.

Udvidelsen af DeviceAppID-REF-DO til at understøtte32 bytes synes at være uforenelig med den nuværende GP-specifikation (som kun tillader 0 eller 20 bytes), så hvorfor indfører du denne ændring? Er SHA-1 ikke tilstrækkeligt til at undgå kollisioner? Har du allerede foreslået denne ændring til GP, da den kan være bagudkompatibel med eksisterende ARA-M/ARF?

A: For at give fremtidssikret sikkerhed introducerer denne udvidelse SHA-256 for DeviceAppID-REF-DO ud over SHA-1, som i øjeblikket er den eneste mulighed i GP SEAC-standarden. Vi anbefaler stærkt at bruge SHA-256.

Hvis DeviceAppID er 0 (tom), anvender du så reglen på alle enhedsapps, der ikke er omfattet af en specifik regel?

SA: Carrier API’er kræver, at DeviceAppID-REF-DO er udfyldt.At være tom er beregnet til testformål og anbefales ikke til operationelle implementeringer.

I henhold til dine specifikationer bør PKG-REF-DO, der anvendes alene uden DeviceAppID-REF-DO, ikke accepteres. Men den er stadig beskrevet i tabel 6-4 som en udvidelse af definitionen afREF-DO. Er det med vilje? Hvordan opfører koden sig, når kun PKG-REF-DO anvendes i REF-DO?

A: Muligheden for at have PKG-REF-DO som et enkelt værdielement i REF-DO blev fjernet i den seneste version. PKG-REF-DO bør kun forekomme i kombination med DeviceAppID-REF-DO.

Vi antager, at vi kan give adgang til alle carrier-baserede tilladelsereller har en mere finkornet kontrol. Hvis det er tilfældet, hvad definerer så mappingen mellem bitmasken og de faktiske tilladelser? En tilladelse pr. klasse? En tilladelse pr. metode? Er 64 separate tilladelser nok i det lange løb?

S: Dette er forbeholdt fremtiden, og vi modtager gerne forslag.

Kan du yderligere definere DeviceAppID for Androidspecifikt? Dette er SHA-1-hashværdien (20 bytes) af det Publisher-certifikat, der er brugt til at underskrive den givne app, så bør navnet ikke afspejle dette formål? (Navnet kan være forvirrende for mange læsere, da reglen gælder for alle apps, der er signeret med det samme Publisher-certifikat.)

A: DeviceAppID til lagring af certifikater understøttes af den eksisterende specifikation. Vi har forsøgt at minimere specifikationsændringer for at sænke barrieren for vedtagelse. For nærmere oplysninger, se Regler om UICC.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.