UICC Carrier Privileges

Posted on by admin

Android 5.1 では、UICC (Universal integrated circuit card) アプリの所有者に関連する API に特別な権限を付与するメカニズムが導入されました。 Android プラットフォームは、UICC に保存された証明書をロードし、これらの証明書によって署名されたアプリに、少数の特別な API への呼び出しを許可します。

Android 7.0 では、UICC キャリア特権ルールの他のストレージ ソースをサポートするためにこの機能を拡張し、API を使用できるキャリアの数を大幅に増加させました。 API リファレンスについては CarrierConfigManager を、手順については CarrierConfiguration を参照してください。

キャリアは UICC を完全に制御できるため、このメカニズムにより、デバイス上の特別な特権を維持しながら、汎用のアプリ配布チャネル (Google Play など) でホストされるモバイル ネットワーク オペレーター (MNO) のアプリを管理する安全で柔軟な方法が提供されます。

Rules on UICC

Storage on the UICC is compatible with theGlobalPlatformSecure Element Access Control specification. カード上のアプリケーション識別子（AID）はA00000015141434C00であり、カード上に保存されたルールを取得するために標準のGET DATAコマンドが使用されます。

データ階層

UICCルールは、次のデータ階層を使用します（括弧内の2文字の文字と数字の組み合わせがオブジェクトタグです）。 各ルールはREF-AR-DO（E2）で、REF-DOとAR-DOの連結で構成されています：

  • REF-DO （E1）にはDeviceAppID-REF-DOまたはDeviceAppID-REF-DOとPKG-REF-DOの連結が含まれています。
    • DeviceAppID-REF-DO (C1) には、証明書のSHA-1 (20 バイト) またはSHA-256 (32 バイト) 署名が格納されます。
    • PKG-REF-DO (CA) はマニフェストで定義された完全なパッケージ名文字列で、ASCII エンコードされており、最大長 127 バイトです。
  • AR-DO (E3) は PERM-AR-DO (DB) を含むように拡張されており、これは 8 バイトのビットマスクで、64 の個別のパーミッションに相当します。

    ルール例

    アプリ名は com.google.android.apps.myapp で、SHA-1 証明書の 16 進数の文字列は:

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

    UICC上のルールの 16 進数の文字列は：

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

    Access rule file (ARF) サポート

    Android 7.X では、UICCにアクセスするためのルールとして、ARFの使用を許可しています。0は、アクセスルールファイル（ARF）からキャリア権限ルールを読み取るためのサポートを追加します。

    Androidプラットフォームは、最初にアクセスルールアプレット（ARA）アプリケーション識別子（AID）A00000015141434C00を選択しようと試みます。 UICCでAIDが見つからない場合、PKCS15 AIDA000000063504B43532D3135を選択してARFにフォールバックします。 Androidは、0x4300にあるアクセス制御ルールファイル（ACRF）を読み、AID FFFFFFFFFFFFを持つエントリーを探します。

    16進数で表したACRFの内容例：

    30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

    アクセス制御条件ファイル（ACCF）の内容例：

    30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

    上記の例では、0x4310がACCFのアドレスで、そこには証明書ハッシュ61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81が格納されています。 この証明書によって署名されたアプリは、キャリア特権を付与されます。

    Enabled APIs

    Androidは以下のAPIをサポートしています。

    TelephonyManager

    • キャリアアプリからUICCへチャレンジ/レスポンスを要求できるメソッド：getIccAuthentication.
    • 呼び出し側アプリにキャリア特権が与えられているかをチェックするメソッド：hasCarrierPrivileges.
    • ブランドと番号を上書きする方法：
      • setOperatorBrandOverride
      • setLine1NumberForDisplay
      • setVoiceMailNumber
    • 直接UICC通信するための方法です。
      • iccOpenLogicalChannel
      • iccCloseLogicalChannel
      • iccExchangeSimIO
      • iccTransmitApduLogicalChannel
      • iccTransmitApduBasicChannel
      • sendEnvelopeWithStatus
    • Device modeをグローバルにセットする方法：setPreferredNetworkTypeToGlobal.

    SmsManager

    発信者が新しい着信SMSメッセージを作成できるようにするメソッド。 injectSmsPdu.

    CarrierConfigManager

    Method to notify configuration changed（構成変更を通知するためのメソッド）。 notifyConfigChangedForSubId. 手順については、キャリアコンフィギュレーションを参照してください。

    CarrierMessagingService

    新しいSMSおよびMMSを送信または受信したときにシステムからの呼び出しを受信するサービス。 このクラスを拡張するには、マニフェスト ファイルでサービスを android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE パーミッションで宣言し、#SERVICE_INTERFACEアクションでインテント フィルタを含めます。 メソッドは次のとおりです。

    • onFilterSms
    • onSendTextSms
    • onSendDataSms
    • onSendMultipartTextSms
    • onSendMms
    • onDownloadMms

    Telephony provider

    Telephony データベースへの変更（挿入、削除、更新、問合せ）許可のコンテンツ プロバイダ API です。 詳細については、developer.android.com.のTelephony API referenceを参照してください。

    Android platform

    検出されたUICCでは、UICCの一部としてキャリア権限ルールを含む内部UICCオブジェクトが構築されます。 特権チェックが必要な場合、UiccCarrierPrivilegeRulesは発信者証明書と自身のルールを1つずつ比較する。

    検証

    The Compatibility Test Suite (CTS) には、CtsCarrierApiTestCases.apkのキャリア API に対するテストが含まれています。

    Preparing the UICC

    デフォルトでは、CtsCarrierApiTestCases.apkはAndroiddeveloper keyで署名されており、ハッシュ値は61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81です。

    出力例： 

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

    CtsCarrierApiTestCases.apk を使用して CTS による実装を検証するには、正しい UICC 規則または ARF サポートのある開発者用 UICC を用意する必要があります。 このセクションで説明されているように、正しいARFを持つ開発者用UICCを用意するようにSIMカードベンダーに依頼し、そのUICCを使用してテストを実行することができます。 UICCは、CTSテストに合格するためにアクティブな携帯電話サービスを必要としません。

    Running tests

    便宜上、CTSは、同じトークンで構成されたデバイス上でのみテストを実行するように制限するデバイストークンをサポートしています。 Carrier API CTS テストは、デバイス・トークン sim-card-with-certs をサポートしています。 たとえば、次のデバイス トークンは、キャリア API テストが deviceabcd1234 上でのみ実行されるように制限します。

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

    デバイス トークンを使用せずにテストを実行すると、テストはすべてのデバイス上で実行されます。

    FAQ

    証明書は UICC でどのようにして更新できますか。

    UICC は他のルールと共存できますか。

    A: 同じ AID の UICC で他のセキュリティ ルールを使用することは問題ありません。

    A: UICC に関連付けられたルールは UICC の削除時に破棄されるため、アプリはその権限を失います。

    UICC 上の証明書の数に制限はありますか?

    この方式でサポートできるAPIの数に制限はありますか?

    A: ありませんが、キャリア関連のAPIに範囲を限定しています。 その場合、どのように強制しているのでしょうか。 (つまり、このメソッドでサポートされるAPIを検証するテストはありますか?)

    A: TheAndroid Compatibility DefinitionDocument (CDD) の “API Behavioral Compatibility” の項をご参照ください。 API の許可モデルが変更されていないことを確認するために、いくつかの CTS テストがあります。

    マルチ SIM 機能ではどのように動作しますか?

    キャリア特権を確認する良いタイミングはいつですか。

    A: SIM の状態がブロードキャストロードされた後です。

    OEM はキャリア API の一部を無効にすることはできますか。

    A: いいえ。現在の API は最小限のセットであり、将来的にはビット マスクを使用してより細かい粒度の制御を行う予定だと考えています。 たとえば、SE13、UICC SPN、またはネットワークベースの NITZ などです。

    A: TelephonyManager

    の SPN エントリを参照してください。

    injectSmsPdu のメソッド呼び出しで何をするのでしょうか。

    SMS フィルタリングの場合、onFilterSms コールは SMS UDH ポートフィルタリングに基づいていますか?

    32 バイトをサポートするための DeviceAppID-REF-DO の拡張は、現在の GP 仕様 (0 または 20 バイトのみを許可) と互換性がないように見えますが、なぜこの変更を導入するのですか? 衝突を避けるにはSHA-1で十分ではないでしょうか。

    A: 将来にわたるセキュリティを提供するために、この拡張機能では、現在GP SEAC標準の唯一のオプションであるSHA-1に加えて、DeviceAppID-REF-DO用にSHA-256を導入しています。

    DeviceAppID が 0 (空) の場合、特定のルールが適用されていないすべてのデバイス アプリにルールを適用しますか?

    A: キャリア API は DeviceAppID-REF-DO に入力する必要があります。空はテスト目的のため、運用展開にはお勧めしません。 しかし、表6-4では、REF-DOの定義を拡張するものとして、まだ記述されています。 これは意図的なものなのでしょうか？

    A: REF-DOでPKG-REF-DOを単一の値項目として持つというオプションは、最新版では削除されました。 PKG-REF-DOはDeviceAppID-REF-DOとの組み合わせでのみ発生するはずです。

    すべてのキャリアベースのアクセス許可またはより細かい制御が可能であると想定しています。 その場合、ビットマスクと実際のパーミッションのマッピングはどのように定義されるのでしょうか? 1 つのクラスにつき 1 つのパーミッションですか? メソッドごとに1つのパーミッション?

    A: これは将来のために予約されており、提案を歓迎します。

    Android 特有の DeviceAppID についてさらに定義できますか? これは、指定されたアプリの署名に使用された発行者証明書の SHA-1 (20 バイト) ハッシュ値であり、名前はその目的を反映すべきではないでしょうか。 (ルールがその同じパブリッシャー証明書で署名されたすべてのアプリに適用されるため、この名前は多くの読者を混乱させる可能性があります。)

    A: 証明書を格納する DeviceAppID は既存の仕様でサポートされています。 採用の障壁を低くするために、仕様の変更を最小限にするよう努めました。 詳しくは、UICCのルール

    を参照してください。

コメントを残す

メールアドレスが公開されることはありません。