Google is committed to advancing racial equity for Black communities. See how.
Bu sayfa, Cloud Translation API ile çevrilmiştir.
Switch to English

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 vermek için bir mekanizma sunmuştur. Android platformu, bir UICC'de depolanan sertifikaları yükler ve bu sertifikalarla imzalanan uygulamalara, bir avuç özel API'ye çağrı yapmak için izin verir.

Android 7.0, bu özelliği UICC operatör ayrıcalık 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 referansı için, bkz. CarrierConfigManager ; talimatlar için Taşıyıcı Yapılandırması'na bakın.

Taşıyıcılar, UICC üzerinde tam kontrole 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önetmek için güvenli ve esnek bir yol 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 üzerindeki depolama, GlobalPlatform Güvenli Öğe Erişim Kontrolü spesifikasyonuyla uyumludur. Karttaki uygulama tanımlayıcısı (AID) A00000015141434C00 ve kartta depolanan kuralları almak için standart GET DATA komutu kullanılır. Bu kuralları kablosuz kart (OTA) güncellemeleri ile 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 birleşimini 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, 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 ) 'yu içerecek şekilde genişletilmiştir.

PKG-REF-DO yoksa, sertifika ile imzalanan herhangi bir uygulamaya erişim izni verilir; aksi takdirde hem sertifika 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 dizede UICC'nin kuralı şöyledir:

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) operatör ayrıcalık kurallarını okumak için destek ekler.

Android platformu ilk olarak erişim kuralı uygulaması (ARA) uygulama tanımlayıcısını (AID) A00000015141434C00 . A000000063504B43532D3135 AID A000000063504B43532D3135 seçerek A000000063504B43532D3135 geri A000000063504B43532D3135 . Android daha sonra erişim denetimi kuralları dosyasını (ACRF) 0x4300 ve AID FFFFFFFFFFFF içeren girişleri arar. Farklı AID'lere sahip girişler göz ardı edilir, böylece diğer kullanım durumları için kurallar bir arada var olabilir.

Hex dizesinde ö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 için adresidir. 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Bu sertifika ile imzalanan uygulamalara operatör ayrıcalıkları verilir.

Etkin API'ler

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

TelephonyManager

SmsManager

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

CarrierMessagingService

Yeni SMS ve MMS gönderildiğinde veya alındığında sistemden çağrı alan servis. Bu sınıfı genişletmek için, manifest dosyanızdaki hizmeti android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE izniyle android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE ve #SERVICE_INTERFACE eylemiyle bir amaç filtresi #SERVICE_INTERFACE . Yöntemler şunları içerir:

Telefon sağlayıcı

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 ; daha fazla ayrıntı için, developer.android.com adresindeki Telephony 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ı içeren dahili UICC nesneleri oluşturur. UiccCarrierPrivilegeRules.java , kuralları yükler, UICC kartından ayrıştırır ve bunları 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, UICC nesnesiyle birlikte kurallar da yok edilir.

Doğrulama

Uyumluluk Test Paketi (CTS) , CtsCarrierApiTestCases.apk taşıyıcı API'leri için testler içerir. Bu özellik UICC'deki sertifikalara bağlı olduğundan, bu testleri geçmek için UICC'yi hazırlamanız gerekir.

UICC'yi hazırlama

Varsayılan olarak, 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 Android geliştirici anahtarı tarafından imzalanmıştır. 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Testler ayrıca, UICC uyumsuzluğundaki sertifikalar durumunda beklenen sertifika karmasını da yazdırır.

Örnek çıktı:

junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.
Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81

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

Koşu testleri

Kolaylık sağlamak için CTS, testleri yalnızca aynı jetonla yapılandırılmış cihazlarda çalıştırılacak şekilde kısıtlayan bir cihaz jetonunu destekler. Carrier API CTS testleri, sim-card-with-certs cihaz belirteci sim-card-with-certs destekler. Örneğin, aşağıdaki cihaz jetonu, taşıyıcı API testlerini yalnızca abcd1234 cihazında çalıştırılacak şekilde abcd1234 :

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

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

C: Aynı AID altında UICC'de başka güvenlik kurallarına sahip olmak sorun değil; platform bunları otomatik olarak filtreler.

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

Y: Uygulama, UICC ile ilişkili kurallar UICC kaldırıldığında ortadan kalktığı için 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 kontrol doğrusal olduğundan, çok fazla kural kontrol için bir 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, onları 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ış 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 diğer SE erişim teknolojileri ile etkileşime giriyor mu veya örtüşüyor mu, örneğin SEEK?

C: Örnek olarak, SEEK, UICC ile aynı AID'yi kullanır. Dolayısıyla kurallar bir arada var olur ve SEEK veya UiccCarrierPrivileges tarafından filtrelenir.

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

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

OEM'ler, taşıyıcı API'lerinin bir bölümünü devre dışı bırakabilir mi?

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

setOperatorBrandOverride diğer TÜM işleç adı dizeleri 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 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ı filtrelemesine mi dayanıyor? Veya taşıyıcı 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 uzantısı, mevcut GP spesifikasyonuyla uyumsuz görünüyor (yalnızca 0 veya 20 bayta izin verir), öyleyse neden bu değişikliği getiriyorsunuz? SHA-1 çarpışmaları önlemek için 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?

C: 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- DeviceAppID-REF-DO . SHA-256 kullanmanızı önemle tavsiye ederiz.

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

C: Carrier 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 DeviceAppID-REF-DO başına kullanılan PKG-REF-DO kabul edilmemelidir. Ancak yine de Tablo 6-4'te REF-DO tanımını genişletiyor olarak açıklanmaktadır. Bu kasıtlı mı? Nasıl yalnızca kod davranan ne zaman PKG-REF-DO kullanılır REF-DO ?

C: sahip seçeneği PKG-REF-DO tek değer öğesi olarak REF-DO son sürümünde çıkarıldı. PKG-REF-DO yalnızca DeviceAppID-REF-DO .

Tüm taşıyıcı tabanlı izinlere erişim verebileceğimizi veya daha ince bir 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 mi?

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

DeviceAppID for Android için özel olarak daha fazla tanımlayabilir DeviceAppID ? 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ıtmaması gerekir mi? (Kural, aynı Publisher sertifikasıyla imzalanmış tüm uygulamalar için geçerli olacağından, ad birçok okuyucu için kafa karıştırıcı olabilir.)

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