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 veren 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şleterek API'leri kullanabilen operatörlerin sayısını önemli ölçüde artırdı. API referansı için bkz. CarrierConfigManager ; talimatlar için bkz. Taşıyıcı Yapılandırması .

Operatörler, UICC üzerinde tam kontrole sahiptir; dolayısıyla 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ı korur ve uygulamaları cihaz başına platform sertifikasıyla imzalamak veya sistem uygulaması olarak önceden yüklemek için.

UICC'ye ilişkin kurallar

UICC'deki depolama, GlobalPlatform Güvenli Öğe Erişim Denetimi spesifikasyonuyla 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ı kablosuz kart (OTA) güncellemeleri aracılığıyla güncelleyebilirsiniz.

Veri hiyerarşisi

UICC kuralları aşağıdaki veri hiyerarşisini kullanır (parantez içindeki iki karakterli harf ve sayı birleşimi, 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, ASCII kodlu, maksimum uzunluk 127 bayt olan tam paket adı dizesidir.
  • 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 onaltılık dizedeki SHA-1 sertifikası şöyledir:

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

Onaltılı dizede UICC'ye ilişkin 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) operatör ayrıcalık kurallarının okunmasına yönelik destek ekler.

Android platformu ilk olarak erişim kuralı uygulaması (ARA) AID A00000015141434C00 seçmeye çalışır. UICC'de AID'yi bulamazsa PKCS15 AID A000000063504B43532D3135 seçilerek ARF'ye geri döner. Android daha sonra 0x4300 erişim kontrolü kuralları dosyasını (ACRF) okur ve AID FFFFFFFFFFFF olan girişleri arar. Farklı AID'lere sahip girişler göz ardı edilir, dolayısıyla diğer kullanım durumlarına yönelik kurallar bir arada bulunabilir.

Onaltılı 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 , 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 adresidir 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Bu sertifikayla 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 arayan uygulamayı bilgilendirmek için geri arama yöntemine sahip arayüzlere sahiptir:

Abonelik Yöneticisi

Sms Yöneticisi

CarrierConfigManager'ı

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

Hata Raporu Yöneticisi

Yalnızca bağlantıyla ilgili sorunlarda hata ayıklamaya yönelik bilgileri içeren, hata raporunun özel bir sürümü olan bağlantı hata raporunu başlatma yöntemi: startConnectivityBugreport

Ağ İstatistikleri Yöneticisi

ImsMmTelYönetici

ImsRcs Yöneticisi

Provizyon Yöneticisi

Euicc Yöneticisi

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

  • Gelen SMS mesajlarını filtreleme yöntemi: onFilterSms
  • Cihazdan gönderilen kısa SMS mesajlarına müdahale etme yöntemi: onSendTextSms
  • Cihazdan gönderilen ikili SMS mesajlarına müdahale etme yöntemi: onSendDataSms
  • Cihazdan gönderilen uzun SMS mesajlarını engelleme yöntemi: onSendMultipartTextSms
  • Cihazdan gönderilen MMS mesajlarına müdahale etme 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, hizmeti android.Manifest.permission#BIND_CARRIER_SERVICES izniyle uygulama manifest dosyasında bildirin ve CARRIER_SERVICE_INTERFACE eylemiyle bir amaç filtresi ekleyin. Hizmetin uzun ömürlü bir bağlaması varsa, hizmetin meta verilerinde android.service.carrier.LONG_LIVED_BINDING değerini true olarak ayarlayın.

Platform, taşıyıcı hizmet sürecinin özel bir uygulama bekleme paketinde yürütülmesine olanak sağlamak 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 azaldığında hayatta kalma olasılığını artırır. Ancak operatör hizmeti uygulaması herhangi bir nedenle çökerse, uygulama yeniden başlatılana ve bağlama yeniden kurulana kadar yukarıdaki ayrıcalıkların tümünü kaybeder. Bu nedenle, operatör hizmeti uygulamasını istikrarlı tutmak çok önemlidir.

CarrierService yöntemler şunları içerir:

  • Taşıyıcıya özel yapılandırmaları geçersiz kılmak ve ayarlamak için: onLoadConfig
  • Operatör uygulaması tarafından sistemi yaklaşan kasıtlı bir operatör ağı değişikliği konusunda bilgilendirmek için: notifyCarrierNetworkChange

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ğer alanları Telephony.Carriers tanımlanmıştır; daha fazla ayrıntı için Telephony sınıfı referansına bakın

WifiAğÖnerisi

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

Android platformu

Platform, tespit edilen bir UICC üzerinde, UICC'nin bir parçası olarak taşıyıcı ayrıcalık kurallarını içeren dahili UICC nesneleri oluşturur. UiccCarrierPrivilegeRules.java kuralları yükler, bunları UICC kartından ayrıştırır ve bellekte önbelleğe alır. Ayrıcalık kontrolüne ihtiyaç duyulduğunda UiccCarrierPrivilegeRules arayan sertifikasını kendi kurallarıyla tek tek karşılaştırır. UICC kaldırılırsa kurallar da UICC nesnesiyle birlikte yok edilir.

Doğrulama

Uygulamayı CtsCarrierApiTestCases.apk kullanarak Uyumluluk Test Paketi (CTS) aracılığıyla doğrulamak için doğru UICC kurallarına veya ARF desteğine sahip bir geliştirici UICC'sine 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'si hazırlamasını isteyin ve testleri çalıştırmak için bu UICC'yi kullanın. UICC, CTS testlerini geçmek için aktif hücresel hizmete ihtiyaç duymaz.

UICC'yi hazırlayın

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

Android 12'den başlayarak, CtsCarrierApiTestCases.apk cts-uicc-2021-testkey tarafından imzalanmıştır, 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 operatör API testlerini ç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 operatör 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 imzanın da operatör ayrıcalığı kurallarında kodlanması gerekir:
    1. Hash1(SHA1) 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ştirin: USIM hizmet tablosu: Hizmetleri etkinleştirin n°47, n°48
    1. EF_UST (6F38)
      • İçerik: 9EFFBF1DFFFE0083410310010400406E01
  4. Değiştirin: 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ştirin: Bu tanımı içeren ilgili EF'lerde Android CTS operatör adı dizesini kullanın:
    1. EF_SPN (USIM/6F46)
      • İçerik: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • İçerik: Rec1 430B83413759FE4E934143EA14FF..FF

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

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.

Testleri çalıştırma

Kolaylık sağlamak amacıyla CTS, testleri yalnızca aynı belirteçle yapılandırılmış cihazlarda çalışacak şekilde kısıtlayan bir aygıt belirtecini destekler. Taşıyıcı API CTS testleri sim-card-with-certs cihaz jetonunu destekler. Örneğin, aşağıdaki cihaz belirteci, operatör 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 test çalıştırıldığında 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 bir arada var olabilir mi?

C: UICC'de aynı AID kapsamında başka güvenlik kurallarının bulunmasında sorun yoktur; platform bunları otomatik olarak filtreler.

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

C: UICC'nin kaldırılması sırasında UICC ile ilişkili kurallar ortadan kaldırıldığı için uygulama ayrıcalıklarını kaybeder.

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

C: Platform sertifika sayısını sınırlamaz; ancak kontrol doğrusal olduğundan ç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ırlandırıyoruz.

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

C: Android Uyumluluk Tanımı Belgesinin (CDD) API Davranışsal Uyumluluğu 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ğiyle nasıl çalışır?

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

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

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

Operatör ayrıcalıklarını kontrol etmek için ne zaman iyi bir zaman?

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

OEM'ler operatör API'lerinin bir kısmını devre dışı bırakabilir mi?

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

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

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

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

C: Bu yöntem, bulutta SMS yedeklemeyi/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ı filtrelemesini temel alıyor mu? Yoksa operatör uygulamalarının TÜM gelen SMS'lere erişimi var mı?

C: Operatörlerin tüm SMS verilerine erişimi vardır.

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

C: Geleceğe yönelik güvenlik sağlamak amacıyla 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'yı kullanmanızı kesinlikle öneririz.

DeviceAppID 0 (boş) ise, kuralı belirli bir kural kapsamında olmayan tüm cihaz uygulamalarına mı uygularsınız?

C: Operatör API'leri DeviceAppID-REF-DO doldurulmasını gerektirir. Boş olması 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ın genişletilmesi 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 tek değerli öğe olarak bulunması seçeneği en son sürümde kaldırıldı. PKG-REF-DO yalnızca DeviceAppID-REF-DO ile birlikte gerçekleşmelidir.

Tüm operatör tabanlı izinlere erişim verebileceğimizi veya daha ayrıntılı kontrole sahip olabileceğimizi varsayıyoruz. Eğer ö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 midir?

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

Özellikle Android için DeviceAppID daha ayrıntılı olarak tanımlayabilir misiniz? Bu, verilen uygulamayı imzalamak için kullanılan Yayıncı sertifikasının SHA-1 (20 bayt) karma değeridir; dolayısıyla adın bu amacı yansıtması gerekmez mi? (Kural aynı Yayımcı sertifikasıyla imzalanan tüm uygulamalara uygulanacağından bu ad birçok okuyucu için kafa karıştırıcı olabilir.)

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