UICCキャリア特権

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Android 5.1 では、ユニバーサル IC カード (UICC) アプリの所有者に関連する API に特別な権限を付与するメカニズムが導入されました。 Android プラットフォームは、UICC に保存されている証明書を読み込み、これらの証明書によって署名されたアプリに、いくつかの特別な API を呼び出す権限を付与します。

Android 7.0 では、この機能を拡張して、UICC 携帯通信会社の特権ルールの他のストレージ ソースをサポートし、API を使用できる携帯通信会社の数を劇的に増やしました。 API リファレンスについては、 CarrierConfigManagerを参照してください。手順については、キャリア構成を参照してください。

通信事業者は UICC を完全に制御できるため、このメカニズムにより、一般的なアプリ配布チャネル (Google Play など) でホストされているモバイル ネットワーク オペレーター (MNO) からのアプリを安全かつ柔軟に管理できると同時に、デバイス上で特別な権限を保持する必要がなくなります。デバイスごとのプラットフォーム証明書でアプリに署名するか、システム アプリとしてプレインストールします。

UICCのルール

UICC のストレージは、 GlobalPlatform Secure Element Access Control 仕様と互換性があります。カードのアプリケーション識別子 (AID) はA00000015141434C00で、標準のGET DATAコマンドを使用して、カードに保存されているルールをフェッチします。これらのルールは、カードの無線 (OTA) 更新を通じて更新できます。

データ階層

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

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

PKG-REF-DOが存在しない場合、証明書によって署名されたすべてのアプリにアクセスが許可されます。それ以外の場合は、証明書とパッケージ名の両方が一致する必要があります。

ルールの例

アプリ名はcom.google.android.apps.myappで、16 進文字列の SHA-1 証明書は次のとおりです。

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

16 進文字列の UICC のルールは次のとおりです。

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

アクセス ルール ファイルのサポート

Android 7.0 では、アクセス ルール ファイル (ARF) からキャリア権限ルールを読み取るためのサポートが追加されています。

Android プラットフォームは、最初にアクセス ルール アプリケーション (ARA) AID A00000015141434C00の選択を試みます。 UICC で AID が見つからない場合は、PKCS15 AID A000000063504B43532D3135を選択して ARF にフォールバックします。次に、Android は0x4300にあるアクセス コントロール ルール ファイル (ACRF) を読み取り、AID FFFFFFFFFFFFのエントリを探します。異なる AID を持つエントリは無視されるため、他のユース ケースのルールが共存できます。

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が含まれています。 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 。この証明書によって署名されたアプリには、携帯通信会社の権限が付与されます。

有効な API

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

テレフォニーマネージャー

テレフォニーコールバック

TelephonyCallbackには、登録された状態が変化したときに呼び出し元のアプリに通知するためのコールバック メソッドとのインターフェイスがあります。

サブスクリプションマネージャー

SMSマネージャー

  • 発信者が新しい着信 SMS メッセージを作成できるようにするメソッド: injectSmsPdu
  • SMS プロバイダーに書き込まずにテキスト ベースの SMS メッセージを送信するメソッド: sendTextMessageWithoutPersisting

CarrierConfigManager

  • 構成の変更を通知するメソッド: notifyConfigChangedForSubId
  • デフォルトのサブスクリプションのキャリア構成を取得するメソッド: getConfig
  • 指定されたサブスクリプションのキャリア構成を取得するメソッド: getConfigForSubId

手順については、キャリア構成を参照してください。

BugreportManager

接続関連の問題をデバッグするための情報のみを含むバグ レポートの特殊なバージョンである接続バグ レポートを開始するメソッド: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

プロビジョニングマネージャー

EuiccManager

指定されたサブスクリプションに切り替える (有効にする) メソッド: switchToSubscription

CarrierMessagingService

新着SMSやMMSの送受信時にシステムから着信を受けるサービス。このクラスを拡張するには、マニフェスト ファイルでandroid.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE #SERVICE_INTERFACEを使用してサービスを宣言し、#SERVICE_INTERFACE アクションを含むインテント フィルタを含めます。方法は次のとおりです。

  • 受信 SMS メッセージをフィルタリングするメソッド: onFilterSms
  • デバイスから送信されたテキスト SMS メッセージを傍受する方法: onSendTextSms
  • デバイスから送信されたバイナリ SMS メッセージを傍受する方法: onSendDataSms
  • デバイスから送信された長い SMS メッセージを傍受する方法: onSendMultipartTextSms
  • デバイスから送信された MMS メッセージを傍受するメソッド: onSendMms
  • 受信した MMS メッセージをダウンロードするメソッド: onDownloadMms

キャリアサービス

通信事業者固有の機能をシステムに公開するサービス。このクラスを拡張するには、アプリ マニフェスト ファイルでandroid.Manifest.permission#BIND_CARRIER_SERVICES権限を使用してサービスを宣言し、 CARRIER_SERVICE_INTERFACEアクションを含むインテント フィルタを含めます。サービスに長期間有効なバインディングがある場合は、サービスのメタデータでandroid.service.carrier.LONG_LIVED_BINDINGtrueに設定します。

プラットフォームはCarrierServiceを特別なフラグでバインドして、キャリア サービス プロセスを特別なアプリ スタンバイ バケットで実行できるようにします。これにより、キャリア サービス アプリがアプリのアイドル状態の制限から除外され、デバイスのメモリが少なくなってもアプリが動作し続ける可能性が高くなります。ただし、運送業者サービス アプリが何らかの理由でクラッシュした場合、アプリが再起動してバインディングが再確立されるまで、上記のすべての権限が失われます。そのため、キャリア サービス アプリを安定した状態に保つことが重要です。

CarrierServiceのメソッドは次のとおりです。

  • キャリア固有の構成をオーバーライドして設定するには: onLoadConfig
  • キャリア アプリケーションによる今後のキャリア ネットワークの意図的な変更をシステムに通知するには: notifyCarrierNetworkChange

テレフォニー プロバイダー

テレフォニー データベースへの変更 (挿入、削除、更新、クエリ) を許可するコンテンツ プロバイダー API。値フィールドはTelephony.Carriersで定義されています。詳細についてはTelephonyクラスのリファレンスを参照してください。

Wifi ネットワークの提案

WifiNetworkSuggestionオブジェクトを作成するときは、次のメソッドを使用してサブスクリプション ID またはサブスクリプション グループを設定します。

Android プラットフォーム

検出された UICC で、プラットフォームは、UICC の一部としてキャリア特権ルールを含む内部 UICC オブジェクトを構築します。 UiccCarrierPrivilegeRules.javaは、ルールをロードし、UICC カードから解析して、メモリにキャッシュします。権限チェックが必要な場合、 UiccCarrierPrivilegeRulesは呼び出し元の証明書を独自のルールと 1 つずつ比較します。 UICC が削除されると、ルールは UICC オブジェクトと共に破棄されます。

検証

CtsCarrierApiTestCases.apkを使用して互換性テスト スイート (CTS)で実装を検証するには、正しい UICC ルールまたは ARF サポートを備えた開発者 UICC が必要です。選択した SIM カード ベンダーに、このセクションで説明されているように適切な ARF を使用して開発者 UICC を準備するよう依頼し、その UICC を使用してテストを実行します。 UICC は、CTS テストに合格するためにアクティブなセルラー サービスを必要としません。

UICC を準備する

Android 11 以前の場合、 CtsCarrierApiTestCases.apkaosp-testkeyによって署名され、ハッシュ値は61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 .

Android 12 以降、 CtsCarrierApiTestCases.apkcts-uicc-2021-testkey 、ハッシュ値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によって署名されています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 で CTS キャリア API テストを実行するには、サードパーティのGSMA TS.48 テスト プロファイル仕様の最新バージョンで指定されている要件を満たす CTS キャリア権限を持つ SIM をデバイスで使用する必要があります。

Android 12 より前のバージョンでも同じ SIM を使用できます。

CTS SIM プロファイルの変更

  1. 追加:アクセス ルール アプリケーション マスター (ARA-M) または ARF の CTS キャリア特権。両方の署名は、キャリア特権ルールでエンコードする必要があります。
    1. ハッシュ 1 (SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. ハッシュ 2 (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. 作成: TS.48 には存在せず、CTS に必要な ADF USIM 基本ファイル (EF):
    1. EF_MBDN (6FC7)、レコード サイズ: 28、レコード数: 4
      • コンテンツ
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8)、レコードサイズ:13、レコード番号:1
      • 内容:00FF…FF
        1. EF_MBI (6FC9)、レコードサイズ: 4、レコード番号: 1
      • コンテンツ: Rec1: 01010101
        1. EF_MWIS (6FCA)、レコード サイズ: 5、レコード番号: 1
      • 内容: 0000000000
  3. 変更: USIM サービス テーブル: サービス n°47、n°48 を有効にする
    1. EF_UST (6F38)
      • 内容: 9EFFBF1DFFFE0083410310010400406E01
  4. 変更: DF-5GS および DF-SAIP ファイル
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • コンテンツ: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • コンテンツ: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • 内容: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • 内容: A0020000FF…FF
  5. 変更:この指定を含むそれぞれの EF でキャリア名文字列Android CTSを使用します。
    1. EF_SPN (USIM/6F46)
      • 内容: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • コンテンツ: Rec1 430B83413759FE4E934143EA14FF..FF

テスト プロファイル構造の一致

次の一般的なテスト プロファイル構造の最新バージョンをダウンロードして一致させます。これらのプロファイルには、パーソナライズされた CTS Carrier Privilege ルールや上記のその他の変更はありません。

テストの実行

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

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

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

よくある質問

UICC で証明書を更新するにはどうすればよいですか?

A: 既存のカード OTA 更新メカニズムを使用します。

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

A: 同じ AID の下で UICC に他のセキュリティ ルールを設定しても問題ありません。プラットフォームはそれらを自動的に除外します。

証明書に依存するアプリで UICC が削除されるとどうなりますか?

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

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

A: プラットフォームは証明書の数を制限しません。ただし、チェックは線形であるため、ルールが多すぎると、チェックの待ち時間が発生する可能性があります。

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

A: いいえ。ただし、範囲を通信事業者関連の API に限定しています。

このメソッドの使用が禁止されている API はありますか?もしそうなら、どのようにそれらを強制しますか? (つまり、このメソッドでサポートされている API を検証するテストはありますか?)

A: Android Compatibility Definition Document (CDD) のAPI Behavioral Compatibilityセクションを参照してください。 API のアクセス許可モデルが変更されていないことを確認するための CTS テストがいくつかあります。

これはマルチ SIM 機能とどのように連携しますか?

A: ユーザーが指定したデフォルトの SIM が使用されます。

これは、SEEK などの他の SE アクセス テクノロジと何らかの形で相互作用または重複しますか?

A: 例として、SEEK は UICC と同じ AID を使用します。そのため、ルールは共存し、 SEEK またはUiccCarrierPrivilegesによってフィルター処理されます。

運送業者の特権を確認するのに適した時期はいつですか?

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

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

A: いいえ。現在の API は最小限のセットであると考えており、将来的にはビット マスクを使用してより細かい粒度を制御する予定です。

setOperatorBrandOverrideは、他の形式のオペレーター名文字列をすべてオーバーライドしますか?たとえば、SE13、UICC SPN、またはネットワークベースの NITZ?

はい、オペレーターのブランドのオーバーライドが最も優先されます。設定すると、他のすべての形式のオペレーター名文字列をオーバーライドします。

injectSmsPduメソッド呼び出しは何をしますか?

A: この方法は、クラウドでの SMS のバックアップ/復元を容易にします。 injectSmsPdu呼び出しは、復元機能を有効にします。

SMS フィルタリングの場合、 onFilterSms呼び出しは SMS UDH ポート フィルタリングに基づいていますか?それとも、キャリア アプリはすべての着信 SMS にアクセスできますか?

A: 携帯通信会社はすべての SMS データにアクセスできます。

32 バイトをサポートするためのDeviceAppID-REF-DOの拡張は、現在の GP 仕様 (0 または 20 バイトのみを許可) と互換性がないように見えますが、なぜこの変更を導入するのですか? SHA-1 は衝突を回避するのに十分ではありませんか?この変更は、既存の ARA-M/ARF と下位互換性がない可能性があるため、既に GP に提案しましたか?

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

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

A: キャリア API では、 DeviceAppID-REF-DOを設定する必要があります。空であることはテスト目的のためのものであり、運用展開には推奨されません。

あなたの仕様によると、 DeviceAppID-REF-DOなしで単独で使用されるPKG-REF-DOは受け入れられません。ただし、仕様の表 6-4 では、 REF-DOの定義を拡張するものとしてまだ説明されています。これはわざとですか? REF-DO でPKG-REF-DO REF-DOが使用されている場合、コードはどのように動作しますか?

A: PKG-REF-DOREF-DO -DO の単一値アイテムとして持つオプションは、最新バージョンで削除されました。 PKG-REF-DOは、 DeviceAppID-REF-DOと組み合わせてのみ発生する必要があります。

すべてのキャリアベースのアクセス許可へのアクセスを許可するか、よりきめ細かい制御を行うことができると想定しています。その場合、ビット マスクと実際のアクセス許可の間のマッピングを定義するものは何ですか?クラスごとに1つの許可?メソッドごとに 1 つの権限?長い目で見れば、64 個の個別のアクセス許可で十分でしょうか?

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

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

A: 証明書を格納するDeviceAppIDは、既存の仕様でサポートされています。仕様の変更を最小限に抑えて採用のハードルを下げようとしました。詳細については、 UICC に関する規則を参照してください。