UICC Carrier Privileges

Android 5.1 zavedl mechanismus pro udělování zvláštních oprávnění pro rozhraní APIvýznamné pro vlastníky aplikací pro univerzální karty integrovaných obvodů (UICC). Platforma Android načítá certifikáty uložené na UICC a uděluje aplikacím podepsaným těmito certifikáty oprávnění k volání několika speciálních API.

Android 7.0 rozšířil tuto funkci o podporu dalších zdrojů ukládání pravidel pro privilegia nosičů UICC, čímž dramaticky zvýšil počet nosičů, kteří mohou API používat. Odkaz na API naleznete v části CarrierConfigManager; návod naleznete v části CarrierConfiguration.

Provozovatelé mají plnou kontrolu nad UICC, takže tento mechanismus poskytuje bezpečný a flexibilní způsob správy aplikací od operátora mobilní sítě (MNO) umístěných na obecných distribučních kanálech aplikací (jako je Google Play) při zachování zvláštních oprávnění v zařízeních a bez nutnosti podepisovat aplikace certifikátem platformy pro jednotlivá zařízení nebo je předinstalovávat jako systémové aplikace.

Pravidla na UICC

Uložení na UICC je kompatibilní se specifikací GlobalPlatformSecure Element Access Control. Identifikátor aplikace(AID) na kartě je A00000015141434C00 a k načtení pravidel uložených na kartě se používá standardní příkazGET DATA. Tato pravidla lze aktualizovatprostřednictvím aktualizací karty over-the-air (OTA).

Hierarchie dat

Pravidla UICC používají následující hierarchii dat (kombinace dvou znaků písmene a čísla v závorce je značka objektu). Každé pravidlo jeREF-AR-DO (E2) a skládá se ze spojení REF-DO a AR-DO:

• REF-DO (E1) obsahuje DeviceAppID-REF-DO nebo spojení DeviceAppID-REF-DO a PKG-REF-DO.
  • DeviceAppID-REF-DO (C1) ukládá podpis SHA-1 (20 bajtů) nebo SHA-256 (32 bajtů) certifikátu.
  • PKG-REF-DO (CA) je úplný řetězec názvu balíčku definovaný v manifestu, kódovaný ASCII, maximální délka 127 bajtů.
• AR-DO (E3) je rozšířen o PERM-AR-DO (DB), což je 8bajtová bitová maska představující 64 samostatných oprávnění.

Pokud PKG-REF-DO není přítomen, je každé aplikaci podepsané certifikátem povolen přístup; v opačném případě se musí shodovat certifikát i název balíčku.

Příklad pravidla

Název aplikace je com.google.android.apps.myapp a certifikátSHA-1 v hexadecimálním řetězci je:

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

Pravidlo na UICC v hexadecimálním řetězci je:

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

Podpora souboru pravidel přístupu (ARF)

Android 7.0 přidává podporu pro čtení pravidel oprávnění nosiče ze souboru přístupových pravidel (ARF).

Platforma Android se nejprve pokusí vybrat applet přístupových pravidel (ARA)identifikátor aplikace (AID) A00000015141434C00. Pokud nenajde AID na UICC, vrátí se zpět k ARF výběrem PKCS15 AIDA000000063504B43532D3135. Systém Android poté načte soubor pravidel řízení přístupu (ACRF) na adrese 0x4300 a vyhledá položky s AID FFFFFFFFFFFF. Záznamy s různými AID jsou ignorovány, sory pro jiné případy použití mohou existovat současně.

Příklad obsahu ACRF v hexadecimálním řetězci:

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

Příklad obsahu souboru podmínek řízení přístupu (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

V uvedeném příkladu je 0x4310 adresa ACCF, kteráobsahuje hash certifikátu61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Aplikacím podepsaným tímto certifikátem jsou udělena práva operátora.

Povolená API

Android podporuje následující API.

TelephonyManager

• Metoda umožňující aplikaci operátora požádat UICC o výzvu/odpověď:getIccAuthentication.
• Metoda pro kontrolu, zda volající aplikaci byla udělena práva operátora:hasCarrierPrivileges.
• Metody pro přepsání značky a čísla:
  • setOperatorBrandOverride
  • setLine1NumberForDisplay
  • setVoiceMailNumber
• Metody pro přímou komunikaci s UICC:
  • iccOpenLogicalChannel
  • iccCloseLogicalChannel
  • iccExchangeSimIO
  • iccTransmitApduLogicalChannel
  • iccTransmitApduBasicChannel
  • sendEnvelopeWithStatus
• Metody pro nastavení režimu zařízení na globální:setPreferredNetworkTypeToGlobal.

SmsManager

Metoda umožňující volajícímu vytvářet nové příchozí SMS zprávy: injectSmsPdu.

CarrierConfigManager

Metoda pro oznámení změny konfigurace: notifyConfigChangedForSubId. Pokyny naleznete v částiKonfigurace operátora.

CarrierMessagingService

Služba, která přijímá volání ze systému při odesílánínebo přijímání nových SMS a MMS. Chcete-li tuto třídu rozšířit, deklarujte službu ve svém souboru manifests android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICEoprávněním a zahrňte filtr záměrů s #SERVICE_INTERFACEakcí. Metody zahrnují:

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

Telephony provider

Poskytovatel obsahu API umožňující úpravy (vkládání, mazání, aktualizace, dotazy)telefonní databáze. Pole hodnot jsou definována na adreseTelephony.Carriers; další podrobnosti naleznete v referenciTelephony API na developer.android.com.

Platforma Android

Platforma při detekci UICC konstruuje interní objekty UICC, kterézahrnují pravidla oprávnění operátora jako součást UICC.UiccCarrierPrivilegeRules.java Načte pravidla, analyzuje je z karty UICC a ukládá je do mezipaměti. Když je potřeba provést kontrolu oprávnění, UiccCarrierPrivilegeRules porovná certifikát volajícího se svými vlastními pravidly jedno po druhém. Pokud je karta UICC odstraněna, jsou pravidla zničena spolu s objektem UICC.

Validace

Sada Compatibility Test Suite (CTS) obsahuje testy pro API nosiče vCtsCarrierApiTestCases.apk. Protože tato funkce závisí na certifikátech UICC, musíte UICC připravit, aby těmito testy prošel.

Příprava UICC

Ve výchozím nastavení je CtsCarrierApiTestCases.apk podepsán klíčem Androiddeveloper s hodnotou hash61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Testy také vypíší očekávaný hash certifikátu, pokud se certifikáty na UICC neshodují.

Výstupní příklad:

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

Pro ověření implementace prostřednictvím CTS pomocíCtsCarrierApiTestCases.apk musíte mít vývojářský UICC se správnými pravidly UICC nebo podporou ARF. Můžete požádat vybraného prodejce SIM karet o přípravu vývojářského UICC se správným ARF, jak je popsáno v této části, a použít tento UICC ke spuštění testů. UICC nevyžaduje aktivní mobilní službu, aby prošly testy CTS.

Spouštění testů

Pro pohodlí podporuje CTS token zařízení, který omezujespouštění testů pouze na zařízeních nakonfigurovaných se stejným tokenem. Carrier API CTS testypodporuje token zařízení sim-card-with-certs. Například následující token zařízení omezuje spuštění testů carrier API pouze na zařízeníabcd1234:

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

Při spuštění testu bez použití tokenu zařízení se test spustí na všechzařízeních.

FAQ

Jak lze aktualizovat certifikáty na UICC?

A: Použijte stávající mechanismus aktualizace karty OTA.

Může UICC koexistovat s jinými pravidly?

O: Je v pořádku mít na UICC jiná bezpečnostní pravidla pod stejným AID; platforma je automaticky filtruje.

Co se stane, když je UICC odstraněna pro aplikaci, která se spoléhá na certifikáty na ní?

A: Aplikace ztratí svá oprávnění, protože pravidla spojená s UICC jsou při odstranění UICC zničena.

Je počet certifikátů na UICC omezen?

A: Platforma počet certifikátů neomezuje; ale protože kontrola je lineární, příliš mnoho pravidel může způsobit zpoždění kontroly.

Je nějak omezen počet API, které můžeme touto metodou podporovat?

O: Ne, ale omezujeme rozsah na API související s operátorem.

Jsou některá API zakázána pro použití této metody? Pokud ano, jak je prosazujete? (tj. máte testy pro ověření, která API jsou touto metodou podporována?)

A: Viz část „Kompatibilita chování API“ v dokumentu CDD (Android Compatibility DefinitionDocument). Máme několik testů CTS, abychom se ujistili, že se nezmění model oprávnění API.

Jak to funguje s funkcí multi-SIM?

A: Používá se výchozí SIM karta zadaná uživatelem.

Překrývá se to nějak s jinými přístupovými technologiemi SE, například SEEK?

A: Jako příklad lze uvést, že SEEK používá stejné AID jako na UICC. Takže pravidlaco-existují a jsou filtrována buď SEEK, nebo UiccCarrierPrivileges.

Kdy je vhodné zkontrolovat oprávnění operátora?

A: Po nahrání stavu SIM vysílání.

Mohou OEM zakázat část API operátora?

O: Ne. Domníváme se, že současná API jsou minimální sadou, a do budoucna plánujeme používat bitovou masku pro jemnější kontrolu granularity.

Přepisuje setOperatorBrandOverride VŠECHNY ostatní formy řetězců jmen operátorů? Například SE13, UICC SPN nebo síťový NITZ?

O: Viz položka SPN vTelephonyManager

Co dělá volání metody injectSmsPdu?

O: Tato metoda usnadňuje zálohování/obnovení SMS v cloudu. Volání metodyinjectSmsPdu umožňuje funkci obnovy.

Při filtrování SMS je volání onFilterSms založeno na filtrování portůSMS UDH? Nebo mají aplikace operátorů přístup ke VŠEM příchozím SMS?

O: Operátoři mají přístup ke všem datům SMS.

Rozšíření DeviceAppID-REF-DO o podporu32 bajtů se zdá být neslučitelné se současnou specifikací GP (která umožňuje pouze 0 nebo 20 bajtů), proč tedy zavádíte tuto změnu? Není SHA-1 dostatečný k tomu, aby se zabránilo kolizím? Navrhli jste již tuto změnu GP, protože by to mohlo být zpětně nekompatibilní se stávajícím ARA-M/ARF?

A: Pro zajištění budoucí bezpečnosti toto rozšíření zavádí SHA-256 pro DeviceAppID-REF-DO navíc k SHA-1, což je v současné době jediná možnost ve standardu GP SEAC. Důrazně doporučujeme používat SHA-256.

Pokud je DeviceAppID 0 (prázdný), použijete pravidlo na všechny aplikace zařízení, na které se nevztahuje konkrétní pravidlo?

A: API operátora vyžaduje, aby byl DeviceAppID-REF-DO vyplněn. to, že je prázdný, je určeno pro testovací účely a nedoporučuje se pro provozní nasazení.

Podle vaší specifikace by PKG-REF-DO použitý jen sám o sobě, bez DeviceAppID-REF-DO, neměl být akceptován. V tabulce 6-4 je však stále popsán jako rozšíření definice REF-DO. Je to záměrně? Jak se kód chová, když je v REF-DO použito pouze PKG-REF-DO?

O: Možnost mít PKG-REF-DO jako jedinou položku hodnoty v REF-DO byla v poslední verzi odstraněna. PKG-REF-DO by se měla vyskytovat pouze v kombinaci s DeviceAppID-REF-DO.

Předpokládáme, že můžeme udělit přístup ke všem oprávněním založeným na nosiči nebo mít jemnější kontrolu. Pokud ano, co definuje mapování mezi bitovou maskou a skutečnými oprávněními? Jedno oprávnění pro každou třídu? Jedno oprávnění na jednu metodu? Stačí dlouhodobě 64 samostatných oprávnění?“

O: Toto je vyhrazeno pro budoucnost a uvítáme návrhy.

Můžete blíže definovat DeviceAppIDkonkrétně pro Android? Jedná se o hodnotu hashe SHA-1 (20 bajtů) certifikátu Publishercertificate použitého k podpisu dané aplikace, neměl by tedy název odrážet tentoúčel? (Název by mohl být pro mnoho čtenářů matoucí, protože pravidlo je pak použitelné pro všechny aplikace podepsané stejným certifikátem Publisher)

A: Ukládání certifikátů DeviceAppID je podporováno stávající specifikací. Snažili jsme se minimalizovat změny specifikace, abychom snížili bariéru pro přijetí. Podrobnosti naleznete v Pravidlech pro UICC.