UICC Carrier Privileges

Android 5.1 introduceerde een mechanisme om speciale privileges te verlenen voor API’s die relevant zijn voor de eigenaars van universele geïntegreerde circuit kaart (UICC) apps. Het Android-platform laadt certificaten die zijn opgeslagen op een UICC en verleent toestemming aan apps die zijn ondertekend door deze certificaten om aanroepen te doen naar een handvol speciale API’s.

Android 7.0 breidde deze functie uit om andere opslagbronnen voor UICC-carrierprivilege-regels te ondersteunen, waardoor het aantal carriers dat de API’s kan gebruiken drastisch toenam. Voor een API-referentie, zie CarrierConfigManager; voor instructies, zie CarrierConfiguration.

Carriers hebben volledige controle over de UICC, dus dit mechanisme biedt een veilige en flexibele manier om apps van de mobiele netwerkexploitant (MNO) te beheren die worden gehost op generieke app-distributiekanalen (zoals Google Play) met behoud van speciale privileges op apparaten en zonder de noodzaak om apps te ondertekenen met het platformcertificaat per apparaat of vooraf te installeren als een systeem-app.

Regels op UICC

Opslag op de UICC is compatibel met deGlobalPlatformSecure Element Access Control-specificatie. De toepassingsidentifier (AID) op de kaart is A00000015141434C00, en het standaardcommandoGET DATA wordt gebruikt om op de kaart opgeslagen regels op te halen. U kunt deze regels bijwerken door over-the-air (OTA) updates van de kaart.

Gegevenshiërarchie

UICC regels gebruiken de volgende gegevenshiërarchie (de combinatie van twee letters en cijfers tussen haakjes is de objecttag). Elke regel isREF-AR-DO (E2) en bestaat uit een aaneenschakeling van REF-DO en AR-DO:

• REF-DO (E1) bevat DeviceAppID-REF-DO of een aaneenschakeling van DeviceAppID-REF-DO en PKG-REF-DO.
  • DeviceAppID-REF-DO (C1) bevat de SHA-1 (20 bytes) of SHA-256 (32 bytes) handtekening van het certificaat.
  • PKG-REF-DO (CA) is de volledige pakketnaamstring die in het manifest is gedefinieerd, ASCII-gecodeerd, maximale lengte 127 bytes.
• AR-DO (E3) is uitgebreid met PERM-AR-DO (DB), een 8-byte bitmasker dat 64 afzonderlijke permissies vertegenwoordigt.

Als PKG-REF-DO niet aanwezig is, krijgt elke app die door het certificaat is ondertekend, toegang; anders moeten zowel het certificaat als de pakketnaam overeenkomen.

Regelvoorbeeld

De app naam is com.google.android.apps.myapp en hetSHA-1 certificaat in hex string is:

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

De regel op UICC in hex string is:

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

Access rule file (ARF) support

Android 7.0 voegt ondersteuning toe voor het lezen van carrier privilege regels uit het accessrule bestand (ARF).

Het Android platform probeert eerst de access rule applet (ARA)applicatie identifier (AID) A00000015141434C00 te selecteren. Als het de AID op de UICC niet kan vinden, valt het terug op ARF door PKCS15 AIDA000000063504B43532D3135 te selecteren. Android leest dan het Access Control Rules File (ACRF) op 0x4300 en kijkt naar entries met AID FFFFFFFFFFFF. Invoer met verschillende AID’s wordt genegeerd, regels voor andere use-cases kunnen naast elkaar bestaan.

Exemplaar ACRF inhoud in hex string:

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

Exemplaar ACCF inhoud:

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

In het bovenstaande voorbeeld is 0x4310 het adres voor ACCF, dat de hash61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 van het certificaat bevat. Appssigned by this certificate are granted carrierprivileges.

Enabled APIs

Android ondersteunt de volgende APIs.

TelephonyManager

• Method om de carrier app toe te staan UICC om een challenge/response te vragen:getIccAuthentication.
• Method om te controleren of de aanroepende app carrierprivileges heeft gekregen:hasCarrierPrivileges.
• Methodes om merk en nummer te overschrijven:
  • setOperatorBrandOverride
  • setLine1NumberForDisplay
  • setVoiceMailNumber
• Methodes voor directe UICC-communicatie:
  • iccOpenLogicalChannel
  • iccCloseLogicalChannel
  • iccExchangeSimIO
  • iccTransmitApduLogicalChannel
  • iccTransmitApduBasicChannel
  • sendEnvelopeWithStatus
• Methodes om apparaatmodus in te stellen op globaal:setPreferredNetworkTypeToGlobal.

SmsManager

Methode om beller toe te staan nieuwe inkomende sms-berichten te maken: injectSmsPdu.

CarrierConfigManager

Methode om gewijzigde configuratie door te geven: notifyConfigChangedForSubId. Voor instructies, zieCarrierConfig.

CarrierMessagingService

Dienst die oproepen van het systeem ontvangt wanneer nieuwe SMS en MMS worden verzonden of ontvangen. Om deze klasse uit te breiden, declareert u de dienst in uw manifest-bestand met de android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICEpermission en neemt u een intent filter op met de #SERVICE_INTERFACEaction. Methoden omvatten:

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

Telephony provider

Content provider APIs om wijzigingen (insert, delete, update, query)toe te staan aan de telefonie database. Waardenvelden worden gedefinieerd opTelephony.Carriers; voor meer details, zieTelephony API reference op developer.android.com.

Android platform

Op een gedetecteerde UICC, construeert het platform interne UICC objecten die carrier privilege regels als onderdeel van de UICC.UiccCarrierPrivilegeRules.javalaadt regels, parseert ze van de UICC kaart, en slaat ze op in het geheugen. Wanneer een privilege-controle nodig is, vergelijkt UiccCarrierPrivilegeRules het certificaat van de oproeper één voor één met zijn eigen regels. Als de UICC wordt verwijderd, worden de regels samen met het UICC-object vernietigd.

Validatie

De Compatibiliteitstestsuite (CTS) bevat tests voor carrier-API’s inCtsCarrierApiTestCases.apk. Omdat deze functie afhankelijk is van certificaten op de UICC, moet u de UICC voorbereiden om deze tests te doorstaan.

De UICC voorbereiden

Zoals het hoort, is CtsCarrierApiTestCases.apk ondertekend door de sleutel van Androiddeveloper, met hash-waarde61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. De tests drukken ook de verwachte certificaat-hash af als de certificaten op de UICC niet overeenkomen.

Exemplaaruitvoer:

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

Om de implementatie via CTS metCtsCarrierApiTestCases.apk te valideren, moet u een UICC-ontwikkelaar hebben met de juiste UICC-regels of ARF-ondersteuning. U kunt de SIM kaart verkoper van uw keuze vragen om een ontwikkelaar UICC met de juiste ARF zoals beschreven in deze sectie voor te bereiden en die UICC gebruiken om de tests uit te voeren. De UICC vereist geen actieve cellulaire dienst om CTS tests te doorstaan.

Het uitvoeren van tests

Voor het gemak, CTS ondersteunt een apparaat token dat tests beperkt om alleen op apparaten geconfigureerd met hetzelfde token uit te voeren. Carrier API CTS testondersteunt het apparaattoken sim-card-with-certs. Bijvoorbeeld, thefollowing device token restrictions carrier API tests to run only on deviceabcd1234:

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

Wanneer u een test uitvoert zonder een device token te gebruiken, draait de test op alle apparaten.

FAQ

Hoe kunnen certificaten worden geupdate op de UICC?

A: Gebruik het bestaande kaart OTA update mechanisme.

Kan de UICC naast andere regels bestaan?

A: Het is prima om andere veiligheidsregels op de UICC onder dezelfde AID te hebben; het platform filtert ze er automatisch uit.

Wat gebeurt er als de UICC wordt verwijderd voor een app die vertrouwt op de certificaten die erop staan?

A: De app verliest zijn privileges omdat de regels die aan deUICC zijn gekoppeld, bij verwijdering van de UICC worden vernietigd.

Is er een limiet aan het aantal certificaten op de UICC?

A: Het platform stelt geen limiet aan het aantal certificaten; maar omdat de controle lineair is, kunnen te veel regels een vertraging voor de controle veroorzaken.

Is er een limiet aan het aantal API’s dat we met deze methode kunnen ondersteunen?

A: Nee, maar we beperken de scope tot carrier-gerelateerde API’s.

Zijn er API’s die deze methode niet mogen gebruiken? Zo ja, hoe dwingt u dat af? (Dat wil zeggen, hebt u tests om te valideren welke API’s worden ondersteund met deze methode?)

A: Zie de “API Behavioral Compatibility” sectie van deAndroid Compatibility DefinitionDocument (CDD). We hebben een aantal CTS-tests om ervoor te zorgen dat het toestemmingsmodel van de API’s niet wordt gewijzigd.

Hoe werkt dit met de multi-SIM-functie?

A: De door de gebruiker opgegeven standaard-SIM wordt gebruikt.

Heeft dit op enigerlei wijze interactie of overlapping met andere SE-toegangstechnologieën, bijvoorbeeld SEEK?

A: Als voorbeeld, SEEK gebruikt dezelfde AID als op de UICC. Dus de regelsco-bestaan en worden gefilterd door ofwel SEEK of UiccCarrierPrivileges.

Wanneer is het een goed moment om carrier privileges te controleren?

A: Na de SIM-status geladen uitzending.

Kunnen OEM’s een deel van carrier API’s uitschakelen?

A: Nee. Wij zijn van mening dat de huidige API’s zijn de minimale set, en we zijn van plan om het bitmasker te gebruiken voor fijnere granulariteitscontrole in de toekomst.

Overruled setOperatorBrandOverride ALLE andere vormen van operatornaam strings? Bijvoorbeeld SE13, UICC SPN, of netwerk-gebaseerde NITZ?

A: Zie de SPN entry inTelephonyManager

Wat doet de injectSmsPdu methode oproep?

A: Deze methode vergemakkelijkt SMS backup/restore in de cloud. DeinjectSmsPdu oproep maakt de restore functie mogelijk.

Voor SMS filtering, is de onFilterSms oproep gebaseerd opSMS UDH poort filtering? Of hebben apps van carriers toegang tot ALLE inkomende SMS?

A: Carriers hebben toegang tot alle SMS-gegevens.

De uitbreiding van DeviceAppID-REF-DO tot ondersteuning van32 bytes lijkt onverenigbaar met de huidige GP spec (die alleen 0 of 20 bytes toestaat), dus waarom introduceert u deze wijziging? Is SHA-1 niet voldoende om botsingen te voorkomen? Hebt u deze wijziging al aan GP voorgesteld, omdat dit achterwaarts incompatibel zou kunnen zijn met de bestaande ARA-M/ARF?

A: Voor een toekomstvaste beveiliging introduceert deze uitbreiding SHA-256 voor DeviceAppID-REF-DO naast SHA-1, dat momenteel de enige optie is in de GP SEAC-standaard. We raden ten zeerste aan SHA-256 te gebruiken.

Als DeviceAppID 0 (leeg) is, past u de regel dan toe op alle apparaat-apps die niet door een specifieke regel worden gedekt?

A: Carrier-API’s vereisen dat DeviceAppID-REF-DO is ingevuld. Leeg zijn is bedoeld voor testdoeleinden en wordt niet aanbevolen voor operationele implementaties.

Volgens uw spec, PKG-REF-DO alleen gebruikt, zonder DeviceAppID-REF-DO, zou niet moeten worden geaccepteerd. Maar het wordt nog steeds beschreven in Tabel 6-4 als een uitbreiding van de definitie van REF-DO. Is dit met opzet? Hoe gedraagt de code zich wanneer alleen PKG-REF-DO wordt gebruikt in REF-DO?

A: De optie om PKG-REF-DO als een enkel waarde-item in REF-DO te hebben, is verwijderd in de laatste versie. PKG-REF-DO mag alleen voorkomen in combinatie met DeviceAppID-REF-DO.

We gaan ervan uit dat we toegang kunnen verlenen tot alle carrier-gebaseerde permissies of dat we fijnmaziger controle kunnen uitoefenen. Als dat zo is, wat bepaalt dan de mapping tussen het bitmasker en de eigenlijke permissies? Eén toestemming per klasse? Eén permissie per methode? Zijn 64 afzonderlijke toestemmingen op de lange termijn genoeg?

A: Dit is gereserveerd voor de toekomst, en we verwelkomen suggesties.

Kunt u DeviceAppID nader definiëren voor Android specifiek? Dit is de SHA-1 (20 bytes) hash waarde van het Publisher-certificaat gebruikt om de gegeven app te ondertekenen, dus moet de naam niet dat doel weerspiegelen? (De naam zou voor veel lezers verwarrend kunnen zijn, omdat de regel dan van toepassing is op alle apps die met datzelfde Publisher-certificaat zijn ondertekend.)

A: Het DeviceAppID opslaan van certificaten wordt ondersteund door de bestaande spec. We hebben geprobeerd om spec wijzigingen te minimaliseren om de drempel voor adoptie te verlagen. Voor details, zie Regels op UICC.