UICC Taşıyıcı Ayrıcalıkları

Android 5.1, evrensel tümleşik devre kartı (UICC) uygulamalarının sahipleriyle ilgili API'lere özel ayrıcalıklar vermek için bir mekanizma sundu. Android platformu, bir UICC'de depolanan sertifikaları yükler ve bu sertifikalar tarafından imzalanan uygulamalara bir avuç özel API'ye çağrı yapma izni verir.

Android 7.0, bu özelliği, UICC taşıyıcı ayrıcalık kuralları için diğer depolama kaynaklarını destekleyecek şekilde genişletti ve API'leri kullanabilen taşıyıcıların sayısını önemli ölçüde artırdı. API referans için bakınız CarrierConfigManager ; Talimatlar için, bkz Taşıyıcı Yapılandırma .

Taşıyıcılar UICC üzerinde tam kontrole sahiptir, bu nedenle bu mekanizma, genel uygulama dağıtım kanallarında (Google Play gibi) barındırılan mobil ağ operatöründen (MNO) gelen uygulamaları yönetmek için güvenli ve esnek bir yol sağlarken, cihazlarda özel ayrıcalıkları korurken ve ihtiyaç duymadan uygulamaları cihaz başına platform sertifikasıyla imzalamak veya sistem uygulaması olarak önceden yüklemek için.

UICC ile ilgili kurallar

UICC Depolama uyumlu Eleman Erişim Kontrolü şartname sabitleyin GlobalPlatform . Karttaki uygulama tanımlayıcı (YARDIM) 'dir A00000015141434C00 ve standart GET DATA komutu kartında depolanan kuralları getirmek için kullanılır. Bu kuralları havadan kart (OTA) güncellemeleri yoluyla güncelleyebilirsiniz.

Veri hiyerarşisi

UICC kuralları aşağıdaki veri hiyerarşisini kullanır (parantez içindeki iki karakterli harf ve sayı kombinasyonu, nesne etiketidir). Her kuraldır REF-AR-DO ( E2 ) ve bir arkaya gelmesini kapsayan REF-DO ve AR-DO :

  • REF-DO ( E1 ) içeren DeviceAppID-REF-DO veya bir birleştirme DeviceAppID-REF-DO ve PKG-REF-DO .
    • DeviceAppID-REF-DO ( C1 ) depolar belgesi SHA-1 (20 bayt) SHA-256 (32 bayt) bir imza.
    • PKG-REF-DO ( CA ), maksimum uzunluk 127 byte kodlanmış tezahür, ASCII tanımlanan tam paket adı dizedir.
  • AR-DO ( E3 ) kapsayacak şekilde genişletilir PERM-AR-DO ( DB 64 ayrı izin temsil eden bir 8-bit bit maskesi).

Eğer PKG-REF-DO bulunmadığı, sertifika tarafından imzalanmış herhangi uygulama erişim izni verilir; aksi takdirde hem sertifikanın hem de paket adının eşleşmesi gerekir.

Kural örneği

Uygulamanın adıdır com.google.android.apps.myapp ve altıgen dizesinde SHA-1 belgesi geçerli:

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

UICC'deki onaltılı dizedeki kural:

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

Erişim kuralı dosyası (ARF) desteği

Android 7.0, erişim kuralı dosyasından (ARF) taşıyıcı ayrıcalık kurallarını okumak için destek ekler.

Android platformunun ilk girişimleri erişim kuralı uygulaması (ARA) uygulaması tanımlayıcı (AID) seçmek için A00000015141434C00 . O UICC üzerinde YARDIM bulamazsa, bu PKCS15 YARDIM seçerek geri yetmezliğine düşüyor A000000063504B43532D3135 . Android ardından erişim kontrol kurallarını en dosyası (ACRF) okur 0x4300 YARDIM içeren girişleri ve görünüm FFFFFFFFFFFF . Farklı AID'lere sahip girişler yoksayılır, bu nedenle diğer kullanım durumları için kurallar bir arada bulunabilir.

Onaltılık dizedeki örnek ACRF içeriği:

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

Örnek erişim kontrol koşulları dosyası (ACCF) içeriği:

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

Yukarıdaki örnekte, 0x4310 belgesi karma içeren ACCF için adresi, 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Bu sertifika tarafından imzalanan uygulamalara operatör ayrıcalıkları verilir.

Etkin API'ler

Android, aşağıdaki API'leri destekler.

Telefon Yöneticisi

SMS Yöneticisi

Yöntem arayan yeni gelen SMS mesajları oluşturmak için izin: injectSmsPdu .

CarrierConfigManager

Yöntem değiştirildi yapılandırma bildirmek için: notifyConfigChangedForSubId . Talimatlar için bkz Taşıyıcı Yapılandırma .

TaşıyıcıMesajlaşma Hizmeti

Yeni SMS ve MMS gönderildiğinde veya alındığında sistemden çağrı alan servis. Bu sınıf uzatmak için, ile manifest dosyasında hizmet beyan android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE izni ve bir amaç filtresini içermektedir #SERVICE_INTERFACE eylem. Yöntemler şunları içerir:

Telefon sağlayıcısı

Telefon veritabanında değişikliklere (ekleme, silme, güncelleme, sorgulama) izin veren içerik sağlayıcı API'leri. Değerler alanları tanımlanır Telephony.Carriers ; Daha fazla detay için, bakınız Telefon developer.android.com API referansı.

Android platformu

Algılanan bir UICC'de platform, UICC'nin bir parçası olarak taşıyıcı ayrıcalık kurallarını içeren dahili UICC nesneleri oluşturur. UiccCarrierPrivilegeRules.java yükler kuralları, UICC kartından onları ayrıştırır ve bellekte bunları önbelleğe alır. Bir ayrıcalık kontrolü gerektiğinde, UiccCarrierPrivilegeRules kendi kurallarına tek tek ile arayan sertifikasını karşılaştırır. UICC kaldırılırsa, kurallar UICC nesnesiyle birlikte yok edilir.

doğrulama

Kadar uygulanması doğrulamak için Uyumluluk Testi Suite (CTS) kullanarak CtsCarrierApiTestCases.apk , doğru UICC kuralları veya ARF desteği olan bir geliştirici UICC olması gerekir. Seçtiğiniz SIM kart satıcısından bu bölümde açıklandığı gibi doğru ARF'ye sahip bir geliştirici UICC hazırlamasını ve testleri çalıştırmak için bu UICC'yi kullanmasını isteyebilirsiniz. UICC, CTS testlerini geçmek için aktif hücresel hizmet gerektirmez.

UICC'nin hazırlanması

Android 11 için ve, düşük CtsCarrierApiTestCases.apk tarafından imzalanır aosp-testkey karma değeri ile, 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 .

Android 12 itibaren, CtsCarrierApiTestCases.apk tarafından imzalanır cts-uicc-2021-testkey karma değeri CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0 .

Android 12'de CTS taşıyıcı API testler için cihaz CTS taşıyıcı ayrıcalıkları üçüncü taraf son sürümünde belirtilen gereksinimleri karşılayan bir SIM kullanması gerekir GSMA TS.48 Testi Profili şartname.

Aynı SIM, Android 12'den önceki sürümler için de kullanılabilir.

CTS SIM Profilini Değiştirme

  1. Ekleyin: CTS Taşıyıcı Ayrıcalıklar ARA-M veya ABY'de. Her iki imza da taşıyıcı ayrıcalık kurallarında kodlanmalıdır:
    1. Hash1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Hash2(SHA256): CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1 :94:A8:2C:9B:F1:5D:49:2A:A0
  1. Oluşturun: ADF USIM EF'lerine TS.48 mevcut ve CTS için gerekli değildir:
    1. EF_MBDN (6FC7), Kayıt Boyutu: 28, Kayıt numarası: 4
      • İçerik
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), Kayıt boyutu:13, Kayıt numarası: 1
      • İçerik: 00FF…FF
        1. EF_MBI (6FC9), Kayıt Boyutu: 4, Kayıt numarası: 1
      • İçerik: Kayıt1: 01010101
        1. EF_MWIS (6FCA), Kayıt Boyutu: 5, Kayıt numarası: 1
      • İçerik: 00000000000
  2. Değiştir: USIM Servis Tablo: Hizmetler n ° 47, n ° 48 etkinleştirme
    1. EF_UST (6F38)
      • İçerik: 9EFFBF1DFFFE0083410310010400406E01
  3. Değiştirin: DF-5GS ve DF-SAIP Files
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • İçerik: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • İçerik: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • İçerik:A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • İçerik:A0020000FF…FF
  4. Değiştirin: Taşıyıcı Adı dizeleri bu ataması içeren ilgili EFS Android CTS olacaktır:
    1. EF_SPN (USIM/6F46)
      • İçerik: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • İçerik: Rec1 430B83413759FE4E934143EA14FF..FF

Test profili yapısını eşleştirme

İndirin ve aşağıdaki genel test profil yapıların en son sürümle uyumlu. Bu profiller, kişiselleştirilmiş CTS Taşıyıcı Ayrıcalığı kuralına veya yukarıda listelenen diğer değişikliklere sahip olmayacaktır.

Koşu testleri

Kolaylık sağlamak için CTS, testleri yalnızca aynı belirteçle yapılandırılmış cihazlarda çalışacak şekilde kısıtlayan bir cihaz belirtecini destekler. Taşıyıcı API CTS testleri belirteç cihaz desteği sim-card-with-certs . Örneğin, kısıtlar taşıyıcı API testleri belirteci aşağıdaki cihaz sadece cihaz üzerinde çalıştırmak için abcd1234 :

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

Cihaz belirteci kullanmadan bir test çalıştırırken, test tüm cihazlarda çalışır.

SSS

UICC'de sertifikalar nasıl güncellenebilir?

C: Mevcut kart OTA güncelleme mekanizmasını kullanın.

UICC diğer kurallarla birlikte var olabilir mi?

C: Aynı AID kapsamında UICC'de başka güvenlik kurallarına sahip olmakta sorun yok; platform bunları otomatik olarak filtreler.

Üzerindeki sertifikalara dayanan bir uygulama için UICC kaldırıldığında ne olur?

C: UICC ile ilişkili kurallar UICC kaldırıldığında yok edildiğinden uygulama ayrıcalıklarını kaybeder.

UICC'deki sertifika sayısında bir sınır var mı?

C: Platform, sertifika sayısını sınırlamaz; ancak denetim doğrusal olduğundan, çok fazla kural denetim için gecikmeye neden olabilir.

Bu yöntemle destekleyebileceğimiz API sayısında bir sınır var mı?

C: Hayır, ancak kapsamı operatörle ilgili API'lerle sınırlandırıyoruz.

Bu yöntemi kullanması yasak olan bazı API'ler var mı? Eğer öyleyse, bunları nasıl uygularsınız? (yani, bu yöntemle hangi API'lerin desteklendiğini doğrulamak için testleriniz var mı?)

A: "API Davranışsal Uyumluluğu" bölümüne bakın Android Uyumluluk Tanımı Belgesi (CDD) . API'lerin izin modelinin değişmediğinden emin olmak için bazı CTS testlerimiz var.

Bu, çoklu SIM özelliğiyle nasıl çalışır?

C: Kullanıcı tarafından belirtilen varsayılan SIM kullanılır.

Bu, SEEK gibi diğer SE erişim teknolojileriyle herhangi bir şekilde etkileşime giriyor veya örtüşüyor mu?

C: Örnek olarak, SEEK, UICC'deki ile aynı AID'yi kullanır. Kurallar arada var Yani ve ARAMA veya biri tarafından filtrelenen UiccCarrierPrivileges .

Taşıyıcı ayrıcalıklarını kontrol etmek için iyi bir zaman ne zaman?

A: SIM durumu yüklendikten sonra yayın.

OEM'ler, taşıyıcı API'lerinin bir kısmını devre dışı bırakabilir mi?

C: Hayır. Mevcut API'lerin minimum küme olduğuna inanıyoruz ve gelecekte daha hassas ayrıntı denetimi için bit maskesini kullanmayı planlıyoruz.

Mu setOperatorBrandOverride operatör adı dizeleri TÜM diğer formları geçersiz? Örneğin, SE13, UICC SPN veya ağ tabanlı NITZ?

C: in SPN girişine bakın TelephonyManager

Ne gelmez injectSmsPdu yöntem çağrısı yapmak?

C: Bu yöntem, bulutta SMS yedekleme/geri yüklemeyi kolaylaştırır. injectSmsPdu çağrı fonksiyonu geri sağlar.

SMS filtreleme için, bir onFilterSms SMS UDH liman filtreleme dayalı çağrı? Veya operatör uygulamalarının TÜM gelen SMS'lere erişimi var mı?

C: Taşıyıcıların tüm SMS verilerine erişimi vardır.

Uzantısı DeviceAppID-REF-DO 32 bayt desteklemek için, neden bu değişikliği sunuyoruz (0 veya 20 bayt sadece verir) geçerli GP spec ile uyumlu görünmüyor? Çarpışmaları önlemek için SHA-1 yeterli değil mi? Mevcut ARA-M/ARF ile geriye dönük uyumsuz olabileceğinden, bu değişikliği GP'ye zaten önerdiniz mi?

C: geleceğe dönük güvenlik sağlama için, bu uzantı için SHA-256 tanıtır DeviceAppID-REF-DO SHA-1, şu anda GP SEAC standardında tek seçenektir ek olarak. SHA-256 kullanmanızı şiddetle öneririz.

Eğer DeviceAppID 0 (boş) 'dir, tüm cihaza kural belirli bir kural kapsamına girmeyen apps başvurabilirim?

C: Taşıyıcı API'ler gerektiren DeviceAppID-REF-DO doldurulur. Boş olması test amaçlıdır ve operasyonel dağıtımlar için önerilmez.

Senin özelliklerine göre PKG-REF-DO olmadan, sadece kendisi tarafından kullanılan DeviceAppID-REF-DO , kabul edilmemelidir. Ama yine de tanımını uzanan, Tablo 6-4 bölümde açıklanan REF-DO . Bu kasıtlı mı? Nasıl yalnızca kod davranan ne zaman PKG-REF-DO kullanılır REF-DO ?

C: sahip seçeneği PKG-REF-DO tek değer öğesi olarak REF-DO son sürümünde çıkarıldı. PKG-REF-DO sadece birlikte gerçekleşmesi gereken DeviceAppID-REF-DO .

Tüm taşıyıcı tabanlı izinlere erişim verebileceğimizi veya daha ayrıntılı kontrole sahip olabileceğimizi varsayıyoruz. Öyleyse, bit maskesi ile gerçek izinler arasındaki eşlemeyi ne tanımlar? Sınıf başına bir izin mi? Yöntem başına bir izin? Uzun vadede 64 ayrı izin yeterli mi?

C: Bu gelecek için ayrılmıştır ve önerileri memnuniyetle karşılıyoruz.

Eğer daha fazla tanımlayabilir DeviceAppID özellikle Android için? Bu, verilen uygulamayı imzalamak için kullanılan Yayıncı sertifikasının SHA-1 (20 bayt) karma değeridir, bu nedenle adın bu amacı yansıtması gerekmez mi? (Kural, aynı Yayıncı sertifikasıyla imzalanmış tüm uygulamalar için geçerli olduğundan, ad birçok okuyucu için kafa karıştırıcı olabilir.)

C: DeviceAppID saklanması sertifikaları mevcut spec tarafından desteklenmektedir. Benimseme engelini azaltmak için spesifikasyon değişikliklerini en aza indirmeye çalıştık. Ayrıntılar için bkz UICC üzerinde Kuralları .