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

Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

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 bkz. CarrierConfigManager ; talimatlar için, bkz. Taşıyıcı Yapılandırması .

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'deki depolama, GlobalPlatform Güvenli Öğe Erişim Kontrolü 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ı kablosuz 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 ve AR-DO bir birleşiminden oluşur:

  • REF-DO ( E1 ), DeviceAppID-REF-DO veya DeviceAppID-REF-DO ve PKG-REF-DO bir 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 kodlu, 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şletilir.

PKG-REF-DO mevcut değilse, sertifika tarafından imzalanmış 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ı:

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ı 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 platformu önce erişim kuralı uygulamasını (ARA) AID A00000015141434C00 . UICC'de AID'yi bulamazsa, PKCS15 AID A000000063504B43532D3135 seçilerek ARF'ye geri döner. Android daha sonra erişim denetimi kuralları dosyasını (ACRF) 0x4300 ve AID FFFFFFFFFFFF ile girişleri arar. 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 , 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 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 arayan uygulamayı bilgilendirmek için bir geri arama yöntemine sahip arabirimlere sahiptir:

Abonelik Yöneticisi

SMS Yöneticisi

CarrierConfigManager

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

Hata RaporuYöneticisi

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

Ağİstatistikleri Yöneticisi

ImsMmTelYöneticisi

ImsRcsYöneticisi

Sağlama Yöneticisi

EuiccManager

Belirtilen aboneliğe geçiş (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, bildirim dosyanızda android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE izniyle hizmeti 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 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ı engelleme yöntemi: onSendMms
  • Alınan MMS mesajlarını indirme yöntemi: onDownloadMms

TaşıyıcıHizmet

Taşıyıcıya özgü işlevleri sisteme sunan hizmet. Bu sınıfı genişletmek için, uygulama bildirim dosyasında hizmeti android.Manifest.permission#BIND_CARRIER_SERVICES izniyle 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ı hizmeti sürecinin özel bir uygulama bekleme paketinde çalışmasına izin vermek için CarrierService özel bayraklarla 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, taşıyıcı hizmeti uygulaması herhangi bir nedenle çökerse, uygulama yeniden başlatılana ve bağlama 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 özel yapılandırmaları geçersiz kılmak ve ayarlamak için: onLoadConfig
  • Taşıyıcı uygulaması tarafından kasıtlı olarak yaklaşan bir taşıyıcı ağ değişikliği hakkında sistemi 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ğerler alanları Telephony.Carriers tanımlanmıştır; daha fazla ayrıntı için , Telephony sınıfı referansına bakın

WifiAğÖneri

Bir WifiNetworkSuggestion nesnesi oluştururken, bir abonelik kimliği veya bir 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 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. Bir 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 Uyumluluk Test Paketi (CTS) aracılığıyla uygulamayı doğrulamak için, 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 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 hizmet gerektirmez.

UICC'yi hazırlayın

Android 11 ve önceki sürümler için, CtsCarrierApiTestCases.apk , aosp-testkey tarafından 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 ile imzalanmıştır. 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 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 taşıyıcı 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 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. Ekleyin: 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ı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
  2. Oluşturma: ADF USIM temel dosyaları (EF'ler) TS.48'de mevcut değildir ve CTS için gereklidir:
    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
  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 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ı 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. Taşıyıcı API CTS testleri, aygıt belirteci sim-card-with-certs destekler. Örneğin, aşağıdaki cihaz belirteci, taşıyıcı API testlerinin yalnızca abcd1234 cihazında çalışmasını 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?

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

UICC diğer kurallarla bir arada var olabilir mi?

C: Aynı AID altında UICC'de 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?

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ı?)

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 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. Bu nedenle kurallar bir arada bulunur ve SEEK veya UiccCarrierPrivileges tarafından filtrelenir.

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.

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 biçimlerini geçersiz kılar.

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

C: 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ı filtrelemesini mi temel alıyor? 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.

DeviceAppID-REF-DO 32 baytı destekleyecek şekilde uzantısı, mevcut GP spesifikasyonuyla (yalnızca 0 veya 20 bayta izin veren) uyumsuz görünüyor, öyleyse 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 uyumsuz olabileceğinden, bu değişikliği GP'ye zaten önerdiniz mi?

Y: Geleceğe yönelik 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ı şiddetle öneririz.

DeviceAppID 0 (boş) ise, kuralı belirli bir kuralın kapsamına girmeyen tüm cihaz uygulamalarına mı uyguluyorsunuz?

C: Taşıyıcı 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 yalnızca kendi başına kullanılan PKG-REF-DO kabul edilmemelidir. Ancak yine de spesifikasyonun Tablo 6-4'ünde REF-DO tanımını genişleterek açıklanmaktadır. Bu kasıtlı mı? REF-DO'da yalnızca PKG-REF-DO REF-DO kod nasıl davranır?

C: REF-DO'da tek bir değer öğesi olarak PKG-REF-DO REF-DO olma 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 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.

DeviceAppID for Android'i özel olarak tanımlayabilir misiniz? 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 depolama sertifikaları, mevcut teknik özellikler 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ı .