UICC operatör ayrıcalıkları

Android 5.1, evrensel entegre devre kartı (UICC) uygulamalarının sahipleriyle alakalı API'ler için özel ayrıcalıklar verme mekanizması sunmuştur. Android platformu, UICC'de depolanan sertifikaları yükler ve bu sertifikalarla imzalanan uygulamalara, bir avuç özel API'yi çağırma izni verir.

Android 7.0, bu özelliği genişleterek UICC operatör ayrıcalığı kuralları için diğer depolama kaynaklarını desteklemeye başladı. Bu sayede, API'leri kullanabilen operatörlerin sayısı önemli ölçüde arttı. API referansı için CarrierConfigManager'a, talimatlar için Carrier Configuration'a bakın.

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

UICC ile ilgili kurallar

UICC'deki depolama alanı, GlobalPlatform Secure Element Access Control spesifikasyonu 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ı kart kablosuz (OTA) güncellemeleriyle güncelleyebilirsiniz.

Veri hiyerarşisi

UICC kurallarında aşağıdaki veri hiyerarşisi kullanılır (parantez içindeki iki karakterli harf ve sayı kombinasyonu, nesne etiketidir). Her kural REF-AR-DO (E2) olup REF-DO ve AR-DO birleşiminden oluşur:

  • REF-DO (E1), DeviceAppID-REF-DO veya DeviceAppID-REF-DO ile PKG-REF-DO'ün birleştirilmiş halini içerir.
    • DeviceAppID-REF-DO (C1), sertifikanın SHA-1 (20 bayt) veya SHA-256 (32 bayt) imzasını depolar.
    • PKG-REF-DO (CA), manifestte tanımlanan tam paket adı dizesidir, ASCII kodludur ve maksimum uzunluğu 127 bayttır.
  • AR-DO (E3), 64 ayrı izni temsil eden 8 baytlık bit maskesi olan PERM-AR-DO (DB) ile genişletilir.

PKG-REF-DO yoksa sertifikayla imzalanan tüm uygulamalara 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ı:

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

Onaltılık dizedeki UICC kuralı şöyledir:

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

Erişim kuralı dosyası desteği

Android 7.0, operatör ayrıcalığı kurallarının erişim kuralı dosyasından (ARF) okunması için destek ekler.

Android platformu, önce erişim kuralı uygulaması (ARA) AID'yi A00000015141434C00 seçmeye çalışır. UICC'de AID bulunamazsa PKCS15 AID A000000063504B43532D3135 seçilerek ARF'ye geri dönülür. Android daha sonra 0x4300 konumundaki erişim kontrolü kuralları dosyasını (ACRF) okur ve AID'si FFFFFFFFFFFF olan girişleri arar. Farklı AID'lere sahip girişler yoksayılır. Böylece diğer kullanım alanlarıyla ilgili kurallar bir arada bulunabilir.

Onaltılık dizede ö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 denetimi 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, 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 sertifikayla imzalanan uygulamalara operatör ayrıcalıkları verilir.

Etkinleştirilen API'ler

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

TelephonyManager

TelephonyCallback

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

SubscriptionManager

SmsManager

CarrierConfigManager

Talimatlar için Operatör Yapılandırması başlıklı makaleye bakın.

Derle

Donanım seri numarasını alma yöntemi (varsa): getSerial

BugreportManager

Bağlantı hata raporunu başlatma yöntemi. Bu, hata raporunun yalnızca bağlantıyla ilgili sorunların hata ayıklaması için bilgi içeren özel bir sürümüdür: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

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

CarrierMessagingService

Yeni SMS ve MMS gönderildiğinde veya alındığında sistemden gelen aramaları alan hizmet. Bu sınıfı genişletmek için hizmeti manifest dosyanızda android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE izniyle beyan edin ve #SERVICE_INTERFACE işlemiyle bir amaç filtresi ekleyin. Yöntemler şunlardır:

CarrierService

Operatöre özel işlevleri sisteme sunan hizmet. Bu sınıfı genişletmek için hizmeti uygulama manifest dosyasında android.Manifest.permission#BIND_CARRIER_SERVICES izniyle beyan edin ve CARRIER_SERVICE_INTERFACE işlemiyle bir intent filtresi ekleyin. Hizmetin uzun süreli bir bağlaması varsa hizmetin meta verilerinde android.service.carrier.LONG_LIVED_BINDING değerini true olarak ayarlayın.

Platform, CarrierService öğesini özel işaretlerle bağlayarak operatör hizmeti sürecinin özel bir uygulama bekleme grubunda çalışmasına olanak tanır. Bu, operatör hizmeti uygulamasını uygulama boşta kalma kısıtlamasından muaf tutar ve cihaz belleği azaldığında uygulamanın çalışmaya devam etme olasılığını artırır. Ancak operatör hizmeti uygulaması herhangi bir nedenle kilitlenirse uygulama yeniden başlatılıp bağlama yeniden kurulana kadar yukarıdaki tüm ayrıcalıklarını kaybeder. Bu nedenle, operatör hizmeti uygulamasının kararlı kalması kritik önem taşır.

CarrierService bölgesindeki yöntemler şunlardır:

  • Operatöre özel yapılandırmaları geçersiz kılmak ve ayarlamak için: onLoadConfig
  • Operatör uygulamasının, operatör ağında yapacağı planlı değişiklik hakkında sistemi bilgilendirmek için: notifyCarrierNetworkChange

Telefon hizmeti sağlayıcı

Telefon veritabanında değişiklik (ekleme, silme, güncelleme, sorgulama) yapılmasına izin veren içerik sağlayıcı API'leri. Değer alanları Telephony.Carriers konumunda tanımlanır. Daha fazla bilgi için Telephony sınıf referansına bakın.

WifiNetworkSuggestion

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

Android platformu

Platform, algılanan bir UICC'de 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. Ayrıcalık kontrolü gerektiğinde UiccCarrierPrivilegeRules, arayan sertifikasını kendi kurallarıyla tek tek karşılaştırır. UICC kaldırılırsa kurallar, UICC nesnesiyle birlikte yok edilir.

Doğrulama

CtsCarrierApiTestCases.apk kullanarak Compatibility Test Suite (CTS) aracılığıyla uygulamayı doğrulamak için CtsCarrierApiTestCases.apk, doğru UICC kurallarına veya ARF desteğine sahip bir geliştirici UICC'niz olmalıdır. 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'nin CTS testlerini geçmesi için etkin hücresel hizmet gerekmez.

UICC'yi hazırlama

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

Android 12'den itibaren CtsCarrierApiTestCases.apk, cts-uicc-2021-testkey tarafından imzalanı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'si testlerini çalıştırmak için cihazın, GSMA TS.48 Test Profili spesifikasyonunun en son sürümünde belirtilen koşulları karşılayan CTS operatör ayrıcalıklarına sahip bir SIM kullanması gerekir. Bu SIM, sabit bir ADM1 ile birlikte gelir ve anahtar = 55555555 / 0x3535353535353535 şeklindedir.

Aynı SIM, Android 12'den önceki sürümlerde de kullanılabilir.

CTS SIM profilini değiştirme

  1. Ekleme: CTS operatör ayrıcalıkları access rule app master (ARA-M) veya ARF'de. Her iki imza da kargo şirketi ayrıcalık kurallarında kodlanmalıdır:
    1. Karma1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Karma2(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
  2. Oluşturma: 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: 47 ve 48 numaralı hizmetleri etkinleştirin.
    1. EF_UST (6F38)
      • İçerik: 9EFFBF1DFFFE0083410310010400406E01
  4. Değiştirme: 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ımlamayı 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ıyla eşleşme

Aşağıdaki genel test profili yapılarının en yeni sürümünü indirip eşleştirin. Bu profillerde CTS Carrier Privilege kuralı kişiselleştirilmez veya yukarıda listelenen diğer değişiklikler yapılmaz.

Testler yapın

CTS, kolaylık sağlamak için testlerin yalnızca aynı jetonla yapılandırılmış cihazlarda çalışmasını kısıtlayan bir cihaz jetonunu destekler. Operatör API'si CTS testleri, cihaz jetonunu sim-card-with-certs destekler. Örneğin, aşağıdaki cihaz jetonu, operatör API testlerinin yalnızca abcd1234 cihazında çalıştırılmasını kısıtlar:

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

Cihaz jetonu kullanılmadan test çalıştırıldığında test tüm cihazlarda çalışır.

SSS

UICC'deki sertifikalar nasıl güncellenebilir?

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

Kullanıcı tarafından başlatılan içerik kriterleri diğer kurallarla birlikte kullanılabilir mi?

Y: Aynı AID altında UICC'de başka güvenlik kuralları olması sorun değildir. Platform bunları otomatik olarak filtreler.

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

Y: UICC ile ilişkili kurallar, UICC çıkarıldığında yok edildiğinden uygulama ayrıcalıklarını kaybeder.

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

Y: 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ı sınırlı mı?

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

Bu yöntemin kullanılması yasak olan API'ler var mı? Bu durumda, bu kuralları nasıl uyguluyorsunuz? (Yani, bu yöntemle hangi API'lerin desteklendiğini doğrulamak için testleriniz var mı?)

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

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

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

Bu özellik, SEEK gibi diğer SE erişim teknolojileriyle herhangi bir şekilde etkileşime giriyor veya çakışıyor mu?

Y: Örneğin, SEEK, UICC'dekiyle aynı AID'yi kullanır. Bu nedenle kurallar birlikte bulunur ve SEEK veya UiccCarrierPrivileges tarafından filtrelenir.

Operatör ayrıcalıklarını kontrol etmek için en uygun zaman hangisidir?

Y: SIM durumu yüklendikten sonra yayınlanır.

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

Y: Hayır. Mevcut API'lerin minimum düzeyde olduğunu düşünüyoruz ve gelecekte daha ayrıntılı kontrol için bit maskesini kullanmayı planlıyoruz.

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

Evet, operatör markası geçersiz kılma en yüksek önceliğe sahiptir. Bu ayar yapıldığında, diğer TÜM operatör adı dizelerini geçersiz kılar.

injectSmsPdu yöntemi çağrısı ne işe yarar?

Y: Bu yöntem, SMS'lerin bulutta yedeklenmesini/geri yüklenmesini 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ı filtrelemeye mi dayanıyor? Yoksa operatör uygulamaları TÜM gelen SMS'lere erişebilir mi?

Y: Operatörler tüm SMS verilerine erişebilir.

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

Y: Bu uzantı, geleceğe yönelik güvenlik sağlamak için DeviceAppID-REF-DO'de SHA-1'in yanı sıra SHA-256'yı kullanıma sunar. SHA-1, şu anda GP SEAC standardındaki tek seçenektir. SHA-256 kullanmanızı önemle tavsiye ederiz.

If DeviceAppID is 0 (empty), do you apply the rule to all device apps not covered by a specific rule?

Y: Operatör API'leri için DeviceAppID-REF-DO alanının doldurulması gerekir. Boş olması test amaçlıdır ve operasyonel dağıtımlar için önerilmez.

Spesifikasyonunuza göre PKG-REF-DO, DeviceAppID-REF-DO olmadan tek başına kullanıldığında kabul edilmemelidir. Ancak, spesifikasyonun Tablo 6-4'ünde REF-DO tanımını genişlettiği belirtilmektedir. Bunu bilerek mi yaptınız? REF-DO içinde yalnızca PKG-REF-DO kullanıldığında kod nasıl davranır?

Y: REF-DO içinde PKG-REF-DO öğesinin tek bir değer olarak kullanılması seçeneği son sürümde kaldırıldı. PKG-REF-DO yalnızca DeviceAppID-REF-DO ile birlikte kullanılmalıdır.

Tüm operatör tabanlı izinlere erişim izni verebileceğimizi veya daha ayrıntılı kontrol sağlayabileceğimizi varsayıyoruz. Bu durumda, 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?

Y: Bu özellik gelecekte kullanıma sunulacak. Önerilerinizi bekliyoruz.

Android için DeviceAppID'ı daha ayrıntılı bir şekilde tanımlayabilir misiniz? Bu, söz konusu 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 imzalanan tüm uygulamalar için geçerli olduğundan bu ad birçok okuyucu için kafa karıştırıcı olabilir.)

Y: DeviceAppID sertifikalarının depolanması mevcut spesifikasyon tarafından desteklenir. Kabul edilme sürecini kolaylaştırmak için spesifikasyon değişikliklerini en aza indirmeye çalıştık. Ayrıntılar için UICC ile ilgili kurallar başlıklı makaleyi inceleyin.