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

Android 5.1, evrensel tümleşik devre kartı (UICC) uygulamalarının sahipleriyle ilgili API'ler için özel ayrıcalıklar sağlayan 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 operatör ayrıcalığı kuralları için diğer depolama kaynaklarını destekleyecek şekilde genişletti ve API'leri kullanabilen operatörlerin sayısını önemli ölçüde artırdı. Bir API başvurusu için bkz. CarrierConfigManager ; talimatlar için bkz. Taşıyıcı Yapılandırması .

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

UICC ile ilgili kurallar

UICC'deki depolama , GlobalPlatform Secure Element Access Control belirtimi ile uyumludur. Karttaki uygulama tanımlayıcısı (AID) A00000015141434C00 ve kartta depolanan kuralları getirmek için standart GET DATA komutu kullanılır. Bu kuralları havadan kart (OTA) güncellemeleriyle 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 kural REF-AR-DO ( E2 ) ve REF-DO -DO ile AR-DO birleşiminden oluşur:

  • REF-DO ( E1 ) DeviceAppID-REF-DO veya DeviceAppID-REF-DO ile PKG-REF-DO birleşimini içerir.
    • DeviceAppID-REF-DO ( C1 ), sertifikanın SHA-1 (20 bayt) veya SHA-256 (32 bayt) imzasını saklar.
    • PKG-REF-DO ( CA ), bildirimde tanımlanan tam paket adı dizesidir, ASCII kodludur, maksimum uzunluk 127 bayttır.
  • AR-DO ( E3 ), 64 ayrı izni temsil eden 8 baytlık bir bit maskesi olan PERM-AR-DO ( DB ) içerecek şekilde genişletildi.

PKG-REF-DO mevcut değilse, sertifika tarafından imzalanan herhangi bir uygulamaya erişim izni verilir; aksi takdirde hem sertifikanın hem de paket adının eşleşmesi gerekir.

Kural örneği

Uygulama adı com.google.android.apps.myapp ve hex dizesindeki SHA-1 sertifikası:

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

Onaltılı dizide UICC'deki kural şudur:

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

Erişim kuralı dosyası desteği

Android 7.0, erişim kuralı dosyasından (ARF) taşıyıcı ayrıcalığı kurallarını okuma desteği ekler.

Android platformu önce erişim kuralı uygulamasını (ARA) AID A00000015141434C00 seçmeye çalışır. UICC'de AID'yi bulamazsa, PKCS15 AID A000000063504B43532D3135 seçerek ARF'ye geri döner. Android daha sonra erişim kontrol kuralları dosyasını (ACRF) 0x4300 okur ve AID FFFFFFFFFFFF ile girişleri arar. Farklı AID'lere sahip girişler yoksayılır, böylece diğer kullanım durumları için kurallar bir arada bulunabilir.

Onaltılı dizide ö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 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 sertifika karmasını içeren ACCF'nin adresidir. 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

TelefonGeri Arama

TelephonyCallback kayıtlı durumlar değiştiğinde çağıran uygulamayı bilgilendirmek için bir geri arama yöntemiyle arayüzlere sahiptir:

Abonelik Yöneticisi

Sms Yöneticisi

Taşıyıcı Yapılandırma Yöneticisi

Talimatlar için bkz. Taşıyıcı Yapılandırması .

Hata Raporu Yöneticisi

Hata raporunun yalnızca bağlantıyla ilgili sorunların hatalarını gidermeye yönelik bilgileri içeren özel bir sürümü olan bir bağlantı hata raporu başlatma yöntemi: startConnectivityBugreport

Ağ İstatistikleri Yöneticisi

ImsMmTelManager

ImsRcsManager

Tedarik Yöneticisi

EuiccManager

Belirli bir aboneliğe geçme (etkinleştirme) yöntemi: switchToSubscription

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ı genişletmek için, android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE izniyle bildirim dosyanızdaki hizmeti bildirin ve #SERVICE_INTERFACE eylemiyle bir niyet filtresi ekleyin. Yöntemler şunları içerir:

  • Gelen SMS mesajlarını filtreleme yöntemi: onFilterSms
  • Cihazdan gönderilen metin SMS mesajlarını engelleme yöntemi: onSendTextSms
  • Cihazdan gönderilen ikili SMS mesajlarını engelleme yöntemi: onSendDataSms
  • Cihazdan gönderilen uzun SMS mesajlarını engelleme yöntemi: onSendMultipartTextSms
  • Cihazdan gönderilen MMS mesajlarını yakalama yöntemi: onSendMms
  • Alınan MMS mesajlarını indirme yöntemi: onDownloadMms

Taşıyıcı Hizmeti

Taşıyıcıya özgü işlevleri sisteme sunan hizmet. Bu sınıfı genişletmek için, android.Manifest.permission#BIND_CARRIER_SERVICES izniyle uygulama bildirim dosyasında hizmeti bildirin ve CARRIER_SERVICE_INTERFACE eylemiyle bir niyet filtresi ekleyin. Hizmetin uzun ömürlü bir bağlaması varsa, hizmetin meta verilerinde android.service.carrier.LONG_LIVED_BINDING öğesini true olarak ayarlayın.

Platform, taşıyıcı hizmet sürecinin özel bir uygulama bekleme grubunda çalışmasına izin vermek için CarrierService özel işaretlerle bağlar. Bu, operatör hizmeti uygulamasını uygulama boşta kalma kısıtlamasından muaf tutar ve cihaz belleği düşük olduğunda hayatta kalma olasılığını artırır. Ancak operatör hizmeti uygulaması herhangi bir nedenle çökerse, uygulama yeniden başlayana ve bağlantı yeniden kurulana kadar yukarıdaki tüm ayrıcalıkları kaybeder. Bu nedenle, operatör hizmeti uygulamasını sabit tutmak çok önemlidir.

CarrierService yöntemler şunları içerir:

  • Taşıyıcıya özgü yapılandırmaları geçersiz kılmak ve ayarlamak için: onLoadConfig
  • Taşıyıcı uygulaması tarafından kasıtlı olarak yaklaşmakta olan bir taşıyıcı ağ değişikliği hakkında sistemi bilgilendirmek için: notifyCarrierNetworkChange

telefon sağlayıcı

Telefon veri tabanında değişikliklere (ekleme, silme, güncelleme, sorgulama) izin veren içerik sağlayıcı API'leri. Değer alanları Telephony.Carriers tanımlanır; daha fazla ayrıntı için Telephony sınıfı referansına bakın

WifiAğ Önerisi

Bir WifiNetworkSuggestion nesnesi oluştururken, bir abonelik kimliği veya abonelik grubu ayarlamak için aşağıdaki yöntemleri kullanın:

android platformu

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

Doğrulama

CtsCarrierApiTestCases.apk kullanarak Compatibility Test Suite (CTS) aracılığıyla uygulamayı doğrulamak için doğru UICC kurallarına veya ARF desteğine sahip bir geliştirici UICC'ye sahip olmanız 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ı isteyin. UICC, CTS testlerini geçmek için aktif hücresel hizmet gerektirmez.

UICC'yi hazırlayın

Android 11 ve önceki sürümler için CtsCarrierApiTestCases.apk , aosp-testkey 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 .

Android 12'den itibaren CtsCarrierApiTestCases.apk , cts-uicc-2021-testkey , hash 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

CTS operatör API testlerini Android 12'de çalıştırmak için cihazın, üçüncü taraf GSMA TS.48 Test Profili spesifikasyonunun en son sürümünde belirtilen gereksinimleri karşılayan CTS taşıyıcı ayrıcalıklarına sahip bir SIM kullanması gerekir.

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

CTS SIM Profilini Değiştirme

  1. Ekle: Erişim kuralı uygulama yöneticisinde (ARA-M) veya ARF'de CTS taşıyıcı ayrıcalıkları. Her iki imza da taşıyıcı ayrıcalığı kurallarında kodlanmalıdır:
    1. 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. 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
  2. Oluşturun: TS.48'de bulunmayan ve CTS için gerekli olan ADF USIM temel dosyaları (EF'ler):
    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: Rec1: 01010101
        1. EF_MWIS (6FCA), kayıt boyutu: 5, kayıt numarası: 1
      • İçerik: 0000000000
  3. Değiştir: USIM hizmet tablosu: Hizmetleri etkinleştir n°47, n°48
    1. EF_UST (6F38)
      • İçerik: 9EFFBF1DFFFE0083410310010400406E01
  4. Değiştir: DF-5GS ve DF-SAIP dosyaları
    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
  5. Değiştir: Bu atamayı içeren ilgili EF'lerde Android CTS taşıyıcı adı dizisini kullanın:
    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

Aşağıdaki genel test profili yapılarının en son sürümünü indirin ve eşleştirin. 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. Carrier API CTS testleri sim-card-with-certs destekler. Örneğin, aşağıdaki cihaz belirteci, taşıyıcı API testlerini yalnızca abcd1234 cihazında çalışacak şekilde kısıtlar:

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?

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

UICC diğer kurallarla bir arada bulunabilir mi?

C: UICC'de aynı AID altında başka güvenlik kurallarının olması sorun değil; platform bunları otomatik olarak filtreler.

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

Y: UICC'nin kaldırılmasıyla UICC ile ilişkili kurallar yok edildiğinden uygulama ayrıcalıklarını kaybeder.

UICC'de sertifika sayısında bir sınırlama var mı?

C: Platform, sertifika sayısını sınırlamaz; ancak kontrol doğrusal olduğu için çok fazla kural kontrol 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ırlıyoruz.

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

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

Bu çoklu SIM özelliği ile 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 bunlarla örtüşüyor mu?

C: Örnek olarak, SEEK, UICC'dekiyle aynı AID'yi kullanır. Böylece kurallar bir arada bulunur ve SEEK veya UiccCarrierPrivileges tarafından filtrelenir.

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

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

OEM'ler operatör API'lerinin bir bölümünü devre dışı bırakabilir mi?

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

setOperatorBrandOverride diğer TÜM operatör adı dizilerini geçersiz kılar mı? Örneğin, SE13, UICC SPN veya ağ tabanlı NITZ?

Evet, operatör marka geçersiz kılma en yüksek önceliğe sahiptir. Ayarlandığında, diğer TÜM operatör adı dizilerini geçersiz kılar.

injectSmsPdu yöntem çağrısı ne yapar?

Y: Bu yöntem, bulutta SMS yedekleme/geri yüklemeyi kolaylaştırır. injectSmsPdu çağrısı geri yükleme işlevini etkinleştirir.

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

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

DeviceAppID-REF-DO 32 baytı destekleyecek şekilde genişletilmesi, geçerli GP spesifikasyonuyla (yalnızca 0 veya 20 bayta izin verir) uyumsuz görünüyor, öyleyse neden bu değişikliği getiriyorsunuz? Çarpışmaları önlemek için SHA-1 yeterli değil mi? Mevcut ARA-M/ARF ile geriye dönük olarak uyumsuz olabileceğinden, bu değişikliği GP'ye zaten önerdiniz mi?

C: Geleceğe dönük güvenlik sağlamak için bu uzantı, şu anda GP SEAC standardındaki tek seçenek olan SHA-1'e ek olarak DeviceAppID-REF-DO için SHA-256'yı sunar. SHA-256 kullanmanızı önemle tavsiye ederiz.

DeviceAppID 0 (boş) ise, kuralı belirli bir kuralın kapsamadığı tüm cihaz uygulamalarına uyguluyor musunuz?

Y: Taşıyıcı API'leri DeviceAppID-REF-DO doldurulmasını gerektirir. Boş olmak, test amaçlıdır ve operasyonel dağıtımlar için önerilmez.

Spesifikasyonunuza göre, DeviceAppID-REF-DO olmadan tek başına kullanılan PKG-REF-DO kabul edilmemelidir. Ancak yine de spesifikasyonun Tablo 6-4'ünde REF-DO tanımını genişletiyor olarak tanımlanmaktadır. Bu kasıtlı mı? REF-DO yalnızca PKG-REF-DO kullanıldığında kod nasıl davranır?

C: PKG-REF-DO REF-DO DO'da tek değerli öğe olarak bulunması seçeneği en son sürümde kaldırılmıştır. PKG-REF-DO yalnızca DeviceAppID-REF-DO ile birlikte gerçekleşmelidir.

Operatör tabanlı tüm izinlere erişim verebileceğimizi veya daha ayrıntılı denetime 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 mi? Uzun vadede 64 ayrı izin yeterli mi?

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

Özellikle Android için DeviceAppID daha fazla tanımlayabilir misiniz? Bu, verilen uygulamayı imzalamak için kullanılan Yayıncı sertifikasının SHA-1 (20 bayt) hash değeridir, dolayısıyla adın bu amacı yansıtması gerekmez mi? (Kural o zaman 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.)

Y: Sertifikaları saklayan DeviceAppID mevcut spesifikasyon tarafından desteklenir. Benimseme engelini azaltmak için özellik değişikliklerini en aza indirmeye çalıştık. Ayrıntılar için bkz. UICC ile ilgili Kurallar .