UICC の携帯通信会社の権限

Android 5.1 では、Universal Integrated Circuit Card(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-DOE2)のように、REF-DOAR-DO が連結した形で構成されます。

  • REF-DOE1)には、DeviceAppID-REF-DO が、または DeviceAppID-REF-DOPKG-REF-DO の連結が含まれます。
    • DeviceAppID-REF-DOC1)は、証明書の SHA-1(20 バイト)署名または SHA-256(32 バイト)署名を格納します。
    • PKG-REF-DOCA)は、マニフェストで定義された完全なパッケージ名文字列で、最大長 127 バイトの ASCII 文字です。
  • AR-DOE3)は、PERM-AR-DODB)を含むように拡張されます。これは、64 件の個別のアクセス許可を表す 8 バイトのビット マスクです。

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
    

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

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

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

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 は、証明書ハッシュ 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 を含む ACCF のアドレスです。この証明書で署名されたアプリには通信事業者の権限が付与されます。

有効な API

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

TelephonyManager

SmsManager

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

CarrierConfigManager

設定の変更を通知するメソッド: notifyConfigChangedForSubId。手順については、携帯通信会社の設定をご覧ください。

CarrierMessagingService

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

電話プロバイダ

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

Android プラットフォーム

検出された UICC では、UICC の一部として携帯通信会社の権限ルールを含む内部 UICC オブジェクトが作成されます。UiccCarrierPrivilegeRules.java は UICC カードからルールを読み込んで解析して、メモリにキャッシュします。権限の確認が必要な場合、UiccCarrierPrivilegeRules は発信者証明書をルールに照らし合わせ、1 つずつ比較します。UICC が削除された場合、UICC オブジェクトとともにルールが破棄されます。

検証

互換性テストスイート(CTS)では、CtsCarrierApiTestCases.apk に携帯通信会社 API のテストが含まれています。この機能は UICC の証明書に依存するため、テストに合格するよう UICC を準備する必要があります。

UICC の準備

デフォルトでは CtsCarrierApiTestCases.apk は Android デベロッパー キーで署名されており、ハッシュ値は 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 です。テストでは、UICC の証明書が一致しない場合、推定される証明書ハッシュも出力します。

出力例:

    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 を準備し、その UICC を使用してテストを実行するよう、SIM カードのベンダーに問い合わせることもできます。UICC が CTS テストに合格するためには、有効なモバイル サービスは必要ありません。

テストの実行

便宜上、CTS は、同一のトークンで構成されたデバイス上だけでテストを実行するように制限するデバイス トークンをサポートしています。携帯通信会社の API の CTS テストでは、デバイス トークン sim-card-with-certs をサポートします。たとえば、次のデバイス トークンは、携帯通信会社の API テストをデバイス abcd1234 でのみ実行するように制限します。

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

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

よくある質問

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

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

UICC は他のルールとともに使用できますか。

A: UICC に対して同じ AID の他のセキュリティ ルールを設定しても問題ありません。自動的に除外されます。

証明書に依存するアプリによって UICC が削除された場合はどうなりますか。

A: UICC の削除時に UICC に関連するルールが破棄されるため、アプリの権限が失われます。

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

A: プラットフォームでは証明書の数に制限はありません。ただし、チェック処理は順番に行われるため、証明書が多いとチェックに遅延が発生する可能性があります。

このメソッドでサポートされる API の数に制限はありますか。

A: いいえ。ただし、携帯通信会社に関連する API に限定されます。

このメソッドを使用できない API はありますか。また、その場合、どのように実行しますか(言い換えると、このメソッドがサポートされている API を検証するテストがありますか)。

A: Android Compatibility Definition Document(CDD) の「API の動作互換性」のセクションをご覧ください。API の権限モデルが変更されていないことを確認するための CTS テストが用意されています。

マルチ SIM 機能を使用した場合はどうなりますか。

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

SEEK など他の SE アクセス テクノロジーとの互換性や重複はありますか。

A: たとえば、SEEK などは UICC と同じ AID を使用するため、ルールは共存し、SEEK または UiccCarrierPrivileges でフィルタリングされます。

携帯通信会社の権限を確認するのに適したタイミングはいつですか。

A: SIM のステータスがブロードキャストで読み込まれた後です。

携帯通信会社 API の一部を OEM で無効化することはできますか。

A: いいえ。現在の API は最小限の設定であると考えており、今後はビットマスクを使用してさらに細かく制御する予定です。

setOperatorBrandOverride は他のすべての形式の演算子名の文字列をオーバーライドしますか(SE13、UICC SPN、ネットワークベースの NITZ など)。

A: TelephonyManager の SPN エントリをご覧ください。

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 の定義を拡張するものとして説明されています。これは意図的なものでしょうか。PKG-REF-DO のみが REF-DO で使用されている場合、コードはどのような働きをしますか。

A: PKG-REF-DOREF-DO の単一の値項目として持たせるオプションは、最新バージョンでは削除されました。PKG-REF-DODeviceAppID-REF-DO と組み合わせた場合にのみ発生します。

すべての携帯通信会社ベースの権限へのアクセスを許可するか、より細かい制御を行うことができる環境を想定しています。この場合、ビットマスクと実際の権限との間のマッピングを定義するものは何ですか。クラスごとに 1 つの権限、あるいは、メソッドごとに 1 つの権限でしょうか。長期的には 64 件の個別のアクセス許可を行うことで十分ですか。

A: これは将来のために予約されているものですが、ご提案についてはありがたく受け止めさせていただきます。

Android の DeviceAppID をさらに具体的に定義することはできますか。これは、指定されたアプリの署名に使用された発行者証明書の SHA-1(20 バイト)ハッシュ値であるため、名前にその目的を反映させるべきではないでしょうか(ルールは、同じ発行者証明書で署名されたアプリにすべてに適用されるため、わかりやすい名前が必要です)。

A: 証明書を格納する DeviceAppID は、既存の仕様でサポートされています。変更は最小限に抑えて、仕様の適用範囲を高めるようにしています。詳しくは、UICC に関するルールをご覧ください。