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-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）は、マニフェストで定義された完全なパッケージ名文字列で、最大長 127 バイトの ASCII 文字です。
• AR-DO（E3）は、PERM-AR-DO（DB）を含むように拡張されます。これは、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

• 携帯通信会社のアプリが UICC にチャレンジ / レスポンスを尋ねることを許可するメソッド: getIccAuthentication
• 呼び出し元のアプリに携帯通信会社の権限が付与されているかどうかを確認するメソッド: hasCarrierPrivileges
• ブランドと番号をオーバーライドするメソッド:
  • setOperatorBrandOverride
  • setLine1NumberForDisplay
  • setVoiceMailNumber
• 直接 UICC 通信を行うためのメソッド:
  • iccOpenLogicalChannel
  • iccCloseLogicalChannel
  • iccExchangeSimIO
  • iccTransmitApduLogicalChannel
  • iccTransmitApduBasicChannel
  • sendEnvelopeWithStatus
• デバイスモードをグローバルに設定するメソッド: setPreferredNetworkTypeToGlobal

SmsManager

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

CarrierConfigManager

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

CarrierMessagingService

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

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

電話プロバイダ

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

Android プラットフォーム

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

検証

CtsCarrierApiTestCases.apk を使用して互換性テストスイート（CTS）で実装を検証するには、正しい UICC ルールまたは ARF のサポートを備えたデベロッパー UICC が必要です。このセクションで説明されている適切な ARF を備えたデベロッパー UICC を準備し、その UICC を使用してテストを実行するよう、SIM カードのベンダーに問い合わせることもできます。UICC が CTS テストに合格するためには、有効なモバイル サービスは必要ありません。

UICC の準備

Android 11 以前では、CtsCarrierApiTestCases.apk は aosp-testkey で署名されます。ハッシュ値は 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 です。

Android 12 以降では、CtsCarrierApiTestCases.apk は cts-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 です。

Android 12 で CTS キャリア API テストを実行するには、デバイスで、サードパーティによる GSMA TS.48 テスト プロファイル仕様の最新バージョンで指定されている要件を満たす、CTS 携帯通信会社権限を持った SIM を使用する必要があります。

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

CTS SIM プロファイルの変更

1. 追加: ARA-M または ARF の CTS 携帯通信会社権限。携帯通信会社権限ルールでは、両方の署名をエンコードする必要があります。
   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

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 携帯通信会社権限ルールまたは上記の変更は含まれません。

• GSMA TS.48 汎用テスト プロファイル構造
• eSIM DER 形式のサンプル TS.48 プロファイル

テストの実行

便宜上、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-DO を REF-DO の単一の値項目として設定するオプションは、最新バージョンでは削除されました。PKG-REF-DO は DeviceAppID-REF-DO と組み合わせた場合にのみ発生します。

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

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

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

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