UICC Carrier Privileges

Android 5.1 introducerade en mekanism för att bevilja särskilda privilegier för API:er som är relevanta för ägare av UICC-appar (Universal Integrated Circuit Card). Android-plattformen läser in certifikat som lagras på en UICC och ger appar som är signerade med dessa certifikat tillstånd att ringa anrop till en handfull särskilda API:er.

Android 7.0 utökade denna funktion till att stödja andra lagringskällor för regler för UICC-operatörsprivilegier, vilket dramatiskt ökar antalet operatörer som kan använda API:erna. För en API-referens, se CarrierConfigManager; för instruktioner, se CarrierConfiguration.

Företagen har full kontroll över UICC, så den här mekanismen ger ett säkert och flexibelt sätt att hantera appar från mobilnätsoperatören (MNO) som finns i generiska appdistributionskanaler (t.ex. Google Play), samtidigt som man behåller särskilda privilegier på enheterna och utan att behöva signera appar med plattformscertifikatet för varje enhet eller förinstallera dem som en systemapp.

Regler på UICC

Lagring på UICC är kompatibel med specifikationenGlobalPlatformSecure Element Access Control. Applikationsidentifieraren (AID) på kortet är A00000015141434C00, och standardkommandotGET DATA används för att hämta regler som lagras på kortet. Du kan uppdatera dessa regler genom OTA-uppdateringar (over-the-air) av kortet.

Datahierarki

UICC-regler använder följande datahierarki (kombinationen av två bokstäver och siffror inom parentes är objekttaggen). Varje regel ärREF-AR-DO (E2) och består av en sammankoppling av REF-DO och AR-DO:

• REF-DO (E1) innehåller DeviceAppID-REF-DO eller en sammankoppling av DeviceAppID-REF-DO och PKG-REF-DO.
  • DeviceAppID-REF-DO (C1) lagrar certifikatets SHA-1 (20 byte) eller SHA-256 (32 byte) signatur.
  • PKG-REF-DO (CA) är den fullständiga paketnamnssträngen som definieras i manifestet, ASCII-kodad, maxlängd 127 byte.
• AR-DO (E3) utökas med PERM-AR-DO (DB), som är en 8-byte bitmask som representerar 64 separata behörigheter.

Om PKG-REF-DO inte finns med, får alla program som är signerade av certifikatet tillgång, annars måste både certifikatet och paketnamnet överensstämma.

Regelexempel

Appnamnet på appen är com.google.android.apps.myapp ochSHA-1-certifikatet i hexsträngen är:

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

Regeln på UICC i hexsträngen är:

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

Stöd för ARF-fil (Access rule file)

Android 7.0 lägger till stöd för läsning av regler för bärareprivilegier från accessrulefilen (ARF).

Android-plattformen försöker först välja appleten för åtkomstregler (ARA)applikationsidentifierare (AID) A00000015141434C00. Om den inte hittar AID:n på UICC:n återgår den till ARF genom att välja PKCS15 AIDA000000063504B43532D3135. Android läser sedan ACRF-filen (Access Control Rules File) på 0x4300 och letar efter poster med AID FFFFFFFFFFFF. Inlägg med olika AID ignoreras, och regler för andra användningsområden kan samexistera.

Exempel på ACRF-innehåll i hexsträng:

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

Exempel på ACCF-innehåll (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 exemplet ovan är 0x4310 adressen till ACCF, som innehåller certifikatets hash61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Appar som är signerade med detta certifikat beviljas carrierprivilegier.

Aktiverade API:er

Android stöder följande API:er.

TelephonyManager

• Metod för att tillåta carrierappen att be UICC om en utmaning/ett svar:getIccAuthentication.
• Metod för att kontrollera om den anropande appen har beviljats carrierprivilegier:hasCarrierPrivileges.
• Metoder för att åsidosätta varumärke och nummer:
  • setOperatorBrandOverride
  • setLine1NumberForDisplay
• Metoder för direkt kommunikation med UICC:
  • iccOpenLogicalChannel
  • iccCloseLogicalChannel
  • iccExchangeSimIO
  • iccTransmitApduLogicalChannel
  • iccTransmitApduBasicChannel
  • sendEnvelopeWithStatus
• Metoder för att ställa in enhetsläget till globalt: setPreferredNetworkTypeToGlobal.

SmsManager

Metod för att låta den som ringer skapa nya inkommande SMS-meddelanden: injectSmsPdu.

CarrierConfigManager

Metod för att meddela att konfigurationen har ändrats: notifyConfigChangedForSubId. För instruktioner, seCarrier Configuration.

CarrierMessagingService

Tjänst som tar emot anrop från systemet när nya SMS och MMS skickas eller tas emot. Om du vill utöka den här klassen deklarerar du tjänsten i manifestfilen med android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICEtillstånd och inkluderar ett avsiktsfilter med #SERVICE_INTERFACEåtgärd. Metoderna inkluderar:

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

Telefoniförmedlare

Innehållsleverantörens API:er för att möjliggöra ändringar (infoga, ta bort, uppdatera, fråga) i telefonidatabasen. Värdefält definieras påTelephony.Carriers; för mer information, seTelephony API-referens på developer.android.com.

Android-plattform

På en detekterad UICC konstruerar plattformen interna UICC-objekt sominkluderar regler för operatörsprivilegier som en del av UICC:n.UiccCarrierPrivilegeRules.java laddar in regler, parsar dem från UICC-kortet och cachas dem i minnet. När det behövs en kontroll av privilegier jämför UiccCarrierPrivilegeRules uppringarens certifikat med sina egna regler en efter en. Om UICC-kortet avlägsnas förstörs reglerna tillsammans med UICC-objektet.

Validering

The Compatibility Test Suite (CTS) inkluderar tester för carrier API:er iCtsCarrierApiTestCases.apk. Eftersom den här funktionen är beroende av certifikat på UICC:n måste du förbereda UICC:n för att klara dessa tester.

Förberedelse av UICC:n

Som standard är CtsCarrierApiTestCases.apk signerad av Androidutvecklarens nyckel, med hashvärde61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Testerna skriver också ut det förväntade certifikatets hash om certifikaten på UICC inte stämmer överens.

Exempel på utdata:

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

För att validera implementationen genom CTS med hjälp avCtsCarrierApiTestCases.apk måste du ha en UICC för utvecklare med korrekta UICC-regler eller ARF-stöd. Du kan be den leverantör av SIM-kort som du väljer att förbereda en UICC för utvecklare med rätt ARF enligt beskrivningen i det här avsnittet och använda den UICC:n för att köra testerna. UICC:n kräver ingen aktiv mobiltjänst för att klara CTS-testerna.

Körning av tester

För enkelhetens skull har CTS stöd för en enhetstoken som begränsar testerna till att endast köras på enheter som är konfigurerade med samma token. Carrier API CTS-tester stöder enhetstoken sim-card-with-certs. Till exempel begränsar följande enhetstoken testerna för Carrier API till att endast köras på enhetabcd1234:

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

När du kör ett test utan att använda en enhetstoken körs testet på alla enheter.

FAQ

Hur kan certifikat uppdateras på UICC?

A: Använd det befintliga kortets OTA-uppdateringsmekanism.

Kan UICC samexistera med andra regler?

S: Det går bra att ha andra säkerhetsregler på UICC under samma AID; plattformen filtrerar bort dem automatiskt.

Vad händer när UICC tas bort för en app som är beroende av certifikaten på den?

S: Appen förlorar sina privilegier eftersom de regler som är kopplade till UICC:n förstörs när UICC:n avlägsnas.

finns det en gräns för antalet certifikat på UICC:n?

S: Plattformen begränsar inte antalet certifikat, men eftersom kontrollen är linjär kan för många regler ge upphov till en latenstid för kontrollen.

Ins finns det en gräns för antalet API:er som vi kan stödja med denna metod?

S: Nej, men vi begränsar räckvidden till operatörsrelaterade API:er.

Ins finns det några API:er som är förbjudna att använda denna metod? Om så är fallet, hur upprätthåller ni dem? (Det vill säga, har ni tester för att validera vilka API:er som stöds med denna metod?)

A: Se avsnittet ”API Behavioral Compatibility” (API beteendekompatibilitet) i Android Compatibility DefinitionDocument (CDD). Vi har några CTS-tester för att se till att API:s behörighetsmodell inte ändras.

Hur fungerar detta med multi-SIM-funktionen?

A: Det standard-SIM som användaren anger används.

Har detta någon form av interaktion eller överlappning med andra SE-tillträdestekniker, t.ex. SEEK?

A: SEEK använder till exempel samma AID som på UICC:en. Så reglerna existerar också och filtreras av antingen SEEK eller UiccCarrierPrivileges.

När är det en bra tidpunkt att kontrollera operatörsprivilegier?

S: Efter att SIM-tillståndet laddats sänds.

Kan OEM:er inaktivera en del av operatörens API:er?

A: Nej. Vi anser att de nuvarande API:erna är den minsta möjliga uppsättningen, och vi planerar att använda bitmasken för finare kontroll i framtiden.

Har setOperatorBrandOverride företräde framför ALLA andra former av operatörsnamnsträngar? Till exempel SE13, UICC SPN eller nätverksbaserad NITZ?

S: Se SPN-posten iTelephonyManager

Vad gör metodanropet injectSmsPdu?

S: Denna metod underlättar säkerhetskopiering/återställning av SMS i molnet. injectSmsPdu-anropet aktiverar återställningsfunktionen.

För SMS-filtrering, är onFilterSms-anropet baserat påSMS UDH-portfiltrering? Eller har operatörernas appar tillgång till ALLA inkommande SMS?

S: Operatörerna har tillgång till alla SMS-data.

Utvidgningen av DeviceAppID-REF-DO för att stödja 32 bytes verkar vara inkompatibel med den nuvarande GP-specifikationen (som endast tillåter 0 eller 20 bytes), så varför inför ni denna ändring? Är inte SHA-1 tillräckligt för att undvika kollisioner? Har du redan föreslagit denna ändring till GP, eftersom den kan vara bakåtkompatibel med befintliga ARA-M/ARF?

A: För att ge en framtidssäkrad säkerhet införs genom denna utvidgning SHA-256 för DeviceAppID-REF-DO utöver SHA-1, som för närvarande är det enda alternativet i GP SEAC-standarden. Vi rekommenderar starkt att man använder SHA-256.

Om DeviceAppID är 0 (tom), tillämpar du då regeln på alla appar som inte omfattas av en specifik regel?

S: För att kunna använda API:er från operatörer krävs det att DeviceAppID-REF-DO fylls i. Att vara tomt är avsett för teständamål och rekommenderas inte för driftsättning.

Enligt din specifikation bör PKG-REF-DO som används för sig självt, utan DeviceAppID-REF-DO, inte accepteras. Men den beskrivs fortfarande i tabell 6-4 som en utvidgning av definitionen av REF-DO. Är detta avsiktligt? Hur beter sig koden när endast PKG-REF-DO används i REF-DO?

A: Möjligheten att ha PKG-REF-DO som en enda värdepost i REF-DO togs bort i den senaste versionen. PKG-REF-DO bör endast förekomma i kombination med DeviceAppID-REF-DO.

Vi utgår från att vi kan ge tillgång till alla bärarbaserade behörighetereller ha finare kontroll. Om så är fallet, vad definierar mappningen mellan bitmasken och de faktiska behörigheterna? En behörighet per klass? Ett tillstånd per metod? Är 64 separata behörigheter tillräckligt i längden?

S: Detta är reserverat för framtiden, och vi välkomnar förslag.

Kan ni ytterligare definiera DeviceAppID för Androidspecifikt? Detta är SHA-1-hashvärdet (20 bytes) för det Publisher-certifikat som används för att signera den aktuella appen, så borde inte namnet återspegla detta syfte? (Namnet kan vara förvirrande för många läsare eftersom regeln är tillämplig på alla appar som är signerade med samma Publisher-certifikat.)

S: DeviceAppID för lagring av certifikat stöds av den befintliga specifikationen. Vi försökte minimera specifikationsändringar för att sänka hindret för antagande. För mer information, se Regler för UICC.