Az Android 5.1 bevezetett egy mechanizmust, amely különleges jogosultságokat biztosít az univerzális integrált áramköri kártya (UICC) alkalmazások tulajdonosai számára releváns API-khoz. AzAndroid platform betölti az UICC-n tárolt tanúsítványokat, és engedélyt ad az ezen tanúsítványok által aláírt alkalmazásoknak, hogy egy maroknyi speciális API-t hívjanak.
Az Android 7.0 kiterjesztette ezt a funkciót, hogy más tárolási forrásokat is támogasson az UICC hordozói jogosultsági szabályokhoz, drámaian megnövelve az API-kat használó szolgáltatók számát. API-hivatkozásért lásd CarrierConfigManager; utasításokért lásd CarrierConfiguration.
A szolgáltatók teljes mértékben ellenőrzik az UICC-t, így ez a mechanizmus biztonságos és rugalmas módot biztosít a mobilhálózat-üzemeltető (MNO)általános alkalmazásforgalmazási csatornákon (például Google Play) elhelyezett alkalmazásainak kezelésére, miközben megtartja a különleges jogosultságokat az eszközökön, és nincs szükség az alkalmazások aláírására a készülékenkénti platform tanúsítványával vagy a rendszeralkalmazásként történő előtelepítésre.
Szabályok az UICC-n
Az UICC-n lévő tárolás kompatibilis a GlobalPlatformSecure Element Access Control specifikációval. A kártyán lévő alkalmazásazonosító(AID) A00000015141434C00, és a kártyán tárolt szabályok lekérdezésére a szabványosGET DATAparancs használható. Ezeket a szabályokat a kártya fedélzeti (OTA) frissítése révén frissítheti.
Adathierarchia
Az UICC-szabályok a következő adathierarchiát használják (a zárójelben lévő kétkarakteres betű-szám kombináció az objektumcímke). Minden szabályREF-AR-DO (E2) és a REF-DO és AR-DO láncolásából áll:
-
REF-DO(E1)DeviceAppID-REF-DOvagy aDeviceAppID-REF-DOésPKG-REF-DOláncolásából áll.-
DeviceAppID-REF-DO(C1) tárolja a tanúsítvány SHA-1 (20 bájt) vagy SHA-256 (32 bájt) aláírását. -
PKG-REF-DO(CA) a manifesztben meghatározott teljes csomagnévsor, ASCII kódolva, maximális hossza 127 bájt.
-
-
AR-DO(E3) kibővül aPERM-AR-DO(DB)-vel, amely egy 8 bájtos bitmaszk, amely 64 különálló jogosultságot képvisel.
Ha a PKG-REF-DO nincs jelen, minden, a tanúsítvány által aláírt alkalmazásnak hozzáférést biztosít; egyébként a tanúsítványnak és a csomagnévnek is meg kell egyeznie.
Szabálypélda
Az alkalmazás neve com.google.android.apps.myapp és aSHA-1 tanúsítvány hexa karakterláncban:
AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4
A szabály az UICC-n hexa karakterláncban:
E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001
Access rule file (ARF) support
Android 7.0 támogatja a hordozói jogosultsági szabályok olvasását az accessrule fájlból (ARF).
Az Android platform először megpróbálja kiválasztani az access rule applet (ARA)application identifier (AID) A00000015141434C00. Ha nem találja az AID-t az UICC-n, akkor a PKCS15 AIDA000000063504B43532D3135 kiválasztásával visszatér az ARF-hez. Az Android ezután beolvassa a hozzáférési szabályfájlt (ACRF) a 0x4300 címen, és az AID FFFFFFFFFFFF azonosítóval rendelkező bejegyzéseket keresi. Az eltérő AID-vel rendelkező bejegyzéseket figyelmen kívül hagyja, a más felhasználási esetekhez tartozó sorok egymás mellett létezhetnek.
Példa ACRF tartalom hexa karakterláncban:
30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10
Példa hozzáférés-vezérlési feltételek fájl (ACCF) tartalom:
30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81
A fenti példában a 0x4310 az ACCF címe, amely a tanúsítvány hash61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81-t tartalmazza. Az ezzel a tanúsítvánnyal aláírt alkalmazások hordozói jogosultságokat kapnak.
Enabled APIs
Android a következő API-kat támogatja.
TelephonyManager
- Módszer, amellyel a hordozó alkalmazás kérheti az UICC-től a kihívást/választ:
getIccAuthentication. - Módszer annak ellenőrzésére, hogy a hívó alkalmazás kapott-e hordozói jogosultságokat:
hasCarrierPrivileges. - Módszerek a márka és a szám felülírására:
-
setOperatorBrandOverride -
setLine1NumberForDisplay -
setVoiceMailNumber
-
- Módszerek a közvetlen UICC kommunikációhoz:
-
iccOpenLogicalChannel -
iccCloseLogicalChannel -
iccExchangeSimIO -
iccTransmitApduLogicalChannel -
iccTransmitApduBasicChannel -
sendEnvelopeWithStatus
-
- Módszerek az eszköz módjának globálisra állítására:
setPreferredNetworkTypeToGlobal.
SmsManager
Módszer a hívó fél számára új bejövő SMS üzenetek létrehozásának engedélyezésére: injectSmsPdu.
CarrierConfigManager
Módszer a konfiguráció megváltozásának bejelentésére: notifyConfigChangedForSubId. Az utasításokat lásd: Carrier Configuration.
CarrierMessagingService
Szolgáltatás, amely hívásokat fogad a rendszertől, amikor új SMS és MMS küldése vagy fogadása történik. Ennek az osztálynak a kiterjesztéséhez deklarálja a szolgáltatást a manifeszt fájlban a android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICEengedéllyel, és tartalmazzon egy szándékszűrőt a #SERVICE_INTERFACEakcióval. A metódusok a következők:
-
onFilterSms -
onSendTextSms -
onSendDataSms -
onSendMultipartTextSms -
onSendMms -
onDownloadMms
Telefónia szolgáltató
Tartalomszolgáltató API-k a telefonos adatbázis módosításának (beszúrás, törlés, frissítés, lekérdezés)lehetővé tételéhez. Az értékek mezőitTelephony.Carriers definiálják; további részletekért lásd aTelephony API reference on developer.android.com.
Android platform
A felismert UICC-n a platform belső UICC objektumokat konstruál, amelyek az UICC részeként tartalmazzák a hordozói jogosultsági szabályokat.UiccCarrierPrivilegeRules.javabetölti a szabályokat, elemzi őket az UICC kártyáról, és a memóriában gyorsítótárba helyezi őket. Ha jogosultsági ellenőrzésre van szükség, a UiccCarrierPrivilegeRules egyenként összehasonlítja a hívó tanúsítványát a saját szabályaival. Ha az UICC-t eltávolítják, a szabályok az UICC objektummal együtt megsemmisülnek.
Hitelesítés
A kompatibilitási tesztcsomag (CTS) tartalmazza a hordozó API-k tesztjeitCtsCarrierApiTestCases.apk. Mivel ez a funkció az UICC tanúsítványaitól függ, elő kell készíteni az UICC-t, hogy átmenjen ezeken a teszteken.
Az UICC előkészítése
A CtsCarrierApiTestCases.apk alapértelmezés szerint az Androiddeveloper kulcsával van aláírva, hash értékkel61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. A tesztek kiírják a várt tanúsítvány hash-t is, ha a tanúsítványok az UICC-n nem egyeznek.
Példa kimenet:
junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81
A megvalósítás CTS-en keresztül történő érvényesítéséhez aCtsCarrierApiTestCases.apk használatával, rendelkeznie kell egy fejlesztői UICC-vel a megfelelő UICC szabályokkal vagy ARF támogatással. Megkérheti a választott SIM-kártya szállítóját, hogy készítsen egy fejlesztői UICC-t a megfelelő ARF-fel az ebben a szakaszban leírtak szerint, és használja ezt az UICC-t a tesztek futtatásához. Az UICC nem igényel aktív mobilszolgáltatást a CTS-tesztek teljesítéséhez.
Tesztek futtatása
A kényelem érdekében a CTS támogat egy eszköz-token-t, amely a tesztek futtatását csak az azonos tokennel konfigurált eszközökre korlátozza. A Carrier API CTS tesztjei támogatják az eszköz tokent sim-card-with-certs. Például az alábbi eszköz-token korlátozza a hordozó API tesztek futtatását, hogy csak aabcd1234 eszközön fussanak:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
A tesztek eszköz-token használata nélküli futtatása esetén a teszt minden eszközön fut.
Kérdés
Hogyan frissíthetők a tanúsítványok az UICC-n?
A: A meglévő kártya OTA frissítési mechanizmusát használja.
Létezhet-e az UICC más szabályokkal együtt?
Válasz: Rendben van, ha az UICC-n más biztonsági szabályok is vannak ugyanazon AID alatt; a platform automatikusan kiszűri őket.
Mi történik, ha az UICC-t eltávolítják egy olyan alkalmazásból, amely a rajta lévő tanúsítványokra támaszkodik?
A: Az alkalmazás elveszíti jogosultságait, mert az UICC-hez kapcsolódó szabályok az UICC eltávolításakor megsemmisülnek.
Van-e korlátozás az UICC-n lévő tanúsítványok számára?
A: A platform nem korlátozza a tanúsítványok számát; de mivel az ellenőrzés lineáris, a túl sok szabály késedelmet okozhat az ellenőrzésnél.
Létezik-e korlátozás az ezzel a módszerrel támogatható API-k számát illetően?
A: Nincs, de a hatályát a hordozóval kapcsolatos API-kra korlátozzuk.
Vannak olyan API-k, amelyek számára tilos ezt a módszert használni? Ha igen, hogyan érvényesítik ezeket? (azaz vannak-e tesztek annak ellenőrzésére, hogy mely API-k támogatottak ezzel a módszerrel?)
A: Lásd az Android Compatibility DefinitionDocument (CDD) “API Behavioral Compatibility” szakaszát. Van néhány CTS tesztünk annak biztosítására, hogy az API-k jogosultsági modellje ne változzon.
Hogyan működik ez a multi-SIM funkcióval?
A: A felhasználó által megadott alapértelmezett SIM-et használjuk.
Ez bármilyen módon kölcsönhatásba lép vagy átfedésben van más SE hozzáférési technológiákkal, például a SEEK-kel?
A: A SEEK például ugyanazt az AID-t használja, mint az UICC-n. Tehát a szabályokko-léteznek, és vagy a SEEK vagy a UiccCarrierPrivileges alapján kerülnek szűrésre.
Mi a megfelelő időpont a hordozói jogosultságok ellenőrzésére?
A: Miután a SIM állapot betöltötte az adást.
Az OEM-ek letilthatják a hordozói API-k egy részét?
A: Nem. Úgy gondoljuk, hogy a jelenlegi API-k a minimális készletet jelentik, és a jövőben a bitmaszkot tervezzük használni a finomabb granularitású ellenőrzéshez.
A setOperatorBrandOverride felülírja az operátornévsorok MINDEN más formáját? Például SE13, UICC SPN vagy hálózati alapú NITZ?
A: Lásd az SPN bejegyzést aTelephonyManagerben
Mire szolgál a injectSmsPdu módszerhívás?
A: Ez a módszer megkönnyíti az SMS mentését/visszaállítását a felhőben. AinjectSmsPdu hívás engedélyezi a visszaállítási funkciót.
Az SMS-szűrésnél a onFilterSms hívás azSMS UDH port szűrésen alapul? Vagy a szolgáltatók alkalmazásai hozzáférnek MINDEN bejövő SMS-hez?
A: A szolgáltatók hozzáférnek az összes SMS-adathoz.
A DeviceAppID-REF-DO kiterjesztése a 32 bájt támogatására úgy tűnik, hogy nem kompatibilis a jelenlegi GP specifikációval (amely csak 0 vagy 20 bájtot engedélyez), ezért miért vezeti be ezt a változtatást? Az SHA-1 nem elegendő az ütközések elkerülésére? Javasolta már ezt a módosítást a GP-nek, mivel ez visszafelé inkompatibilis lehet a meglévő ARA-M/ARF-fel?
A: A jövőbiztos biztonság érdekében ez a kiterjesztés az SHA-256-ot vezeti be a DeviceAppID-REF-DO számára az SHA-1 mellett, amely jelenleg az egyetlen lehetőség a GP SEAC szabványban. Nagyon ajánljuk az SHA-256 használatát.
Ha a DeviceAppID értéke 0 (üres), akkor a szabályt minden olyan eszközalkalmazásra alkalmazza, amelyre nem vonatkozik egy adott szabály?
A: A fuvarozói API-k megkövetelik a DeviceAppID-REF-DO kitöltését.Az üresség tesztelési célokra szolgál, és nem ajánlott az üzemszerű telepítésekhez.
A specifikáció szerint a PKG-REF-DO önmagában, DeviceAppID-REF-DO nélkül nem fogadható el. De a 6-4. táblázatban még mindig úgy van leírva, mint aREF-DO definíciójának kiterjesztése. Ez szándékos? Hogyan viselkedik a kód, ha a REF-DO-ben csak PKG-REF-DO szerepel?
A: A PKG-REF-DO egyetlen értékelemként való szerepeltetésének lehetőségét a REF-DO-ben a legújabb verzióban eltávolítottuk. A PKG-REF-DO csak a DeviceAppID-REF-DO értékkel együtt fordulhat elő.
Feltételezzük, hogy az összes hordozó alapú jogosultsághoz hozzáférést tudunk adni, vagy finomabb ellenőrzéssel rendelkezünk. Ha igen, mi határozza meg a bitmaszk és a tényleges jogosultságok közötti leképezést? Osztályonként egy engedély? Egy engedély metódusonként? Hosszú távon 64 különálló jogosultság elegendő?
A: Ezt a jövőre tartogatjuk, és szívesen fogadjuk a javaslatokat.
Az Androidra specifikusan DeviceAppID tovább tudod definiálni? Ez az adott alkalmazás aláírásához használt Publishercertificate SHA-1 (20 bájt) hash értéke, így a névnek nem ezt a célt kellene tükröznie? (A név sok olvasó számára zavaró lehet, mivel a szabály az összes, ugyanazzal a Publisher-tanúsítvánnyal aláírt alkalmazásra alkalmazható.)
A: A tanúsítványok tárolására szolgáló DeviceAppID-t a meglévő specifikáció támogatja. Igyekeztünk minimalizálni a specifikáció módosításait, hogy csökkentsük az elfogadás akadályát. A részletekért lásd az UICC-re vonatkozó szabályokat.