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 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 'dir ve kartta depolanan kuralları getirmek için standart GET DATA komutu 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 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, 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şletilir.

PKG-REF-DO yoksa, sertifika tarafından imzalanmış herhangi bir uygulamaya erişim izni verilir; aksi halde 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ı (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 platformu önce erişim kuralı uygulamasını (ARA) uygulama tanımlayıcısını (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 var olabilir.

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 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

SMS Yöneticisi

Arayanın yeni gelen SMS mesajları oluşturmasına izin verme yöntemi: injectSmsPdu .

CarrierConfigManager

Yapılandırmayı bildirme yöntemi değişti: notifyConfigChangedForSubId . Talimatlar için, bkz. Taşıyıcı Yapılandırması .

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:

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 geliştirici.android.com adresindeki Telefon API referansına bakı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. 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ı 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 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 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 : 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
  1. Oluştur : ADF USIM EF'leri 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
  2. Değiştir: USIM Hizmet Tablosu: Hizmetleri Etkinleştir n°47, n°48
    1. EF_UST (6F38)
      • İçerik: 9EFFBF1DFFFE0083410310010400406E01
  3. 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
  4. Değiştir : Taşıyıcı Adı dizeleri, bu atamayı içeren ilgili EF'lerde 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

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.

Çalışan testler

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 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 birlikte var olabilir mi?

C: Aynı AID altı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ının 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: Android Uyumluluk Tanımı Belgesinin (CDD) "API Davranış 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?

A: TelephonyManager'daki SPN girişine bakın

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ı filtrelemesine mi dayalı? 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 kapsamadığı 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 Tablo 6-4'te REF-DO tanımını genişleterek açıklanmıştı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, yani 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ı .