UICCとは？SIMの論理チャネルとAIDによるアプリ選択の仕組みを解説

こんにちは、コモン・クリエーションでIoT・SIMエンジニアリングサービスの事業責任者をしている山本です。 本記事では、端末が UICC(SIM カード)の中身をどうやって操作しているのか — ファイル選択、読み書き、アプリケーション選択、論理チャネル — という「UICC の論理構造」を解説します。

はじめに

前回の ISO 7816とAPDU入門 では、端末と UICC が APDU というコマンド/レスポンスの単位で会話することを説明しました。本稿はその続きとして、APDU で「何を」操作しているのか — UICC 内部の論理的な世界 — を扱います。

本稿では、以下の項目について ETSI TS 102 221 と TS 101 220 に基づいて整理します。

• カレントディレクトリとカレントファイルという「状態」の考え方

• SELECT コマンドによるファイル選択(5 つの選択方法)

• READ BINARY / READ RECORD などファイル構造ごとの基本コマンド

• AID によるアプリケーション(USIM 等)の選択

• 論理チャネル — 複数アプリケーションを同時に使う仕組み

1. まず全体像から — UICCの論理構造をざっくり理解する

UICC の中身は、SIMカードのファイルシステムで説明したとおり、MF(Master File。ルートディレクトリに相当)を頂点とするツリー構造です。ディレクトリに相当するのが DF(Dedicated File)、データ本体が EF(Elementary File)、USIM などのアプリケーション専用ディレクトリが ADF(Application Dedicated File)です。

端末からこのツリーを操作する様子は、コマンドラインだけで操作するファイルサーバーに似ています。操作は次の 2 段階です。

1. cd に相当する SELECT コマンドで目的のファイルまで移動する

2. cat に相当する READ BINARY / READ RECORD コマンドで中身を読む(書き込みは UPDATE 系)

重要なのは、UICC が**「いま、どこにいるか」という状態を持つ**ことです。シェルにカレントディレクトリがあるように、UICC にはカレント DF とカレント EF があります。READ BINARY は「カレント EF を読む」という意味しか持たないため、先に SELECT で対象を選んでおく必要があります。

さらに UICC は、USIM・ISIM・eSIM 管理用アプリ(ISD-R)など複数のアプリケーションを 1 枚に持てます。どれを使うかを指定するのが AID(Application Identifier。アプリケーションの世界共通の識別名)による選択で、複数のアプリケーションを同時に使う仕組みが論理チャネル(1 枚のカードに複数のターミナルウィンドウを開くようなもの)です。

以降、この 3 点セット(SELECT、基本コマンド、AID と論理チャネル)を仕様レベルで整理します。

2. SELECTコマンド — ファイル選択の5つの方法

2-1. 選択方法はP1で切り替える

SELECT は TS 102 221 §11.1.1 で定義される、ファイル選択のためのコマンドです。パラメータ P1 の値によって「何を手がかりに選ぶか」が切り替わります(TS 102 221 Table 11.1)。

P1 = '00'(FID 指定)では、どこからでも任意のファイルに飛べるわけではありません。曖昧さを避けるため、カレント DF の直下の子 → 親 DF → 親 DF の直下の子、という探索順序が決められています。離れた場所のファイルは P1 = '08' のパス指定で選びます。

2-2. レスポンスはFCPテンプレート

SELECT が成功すると、UICC は選択したファイルの属性情報を FCP(File Control Parameters。ファイルの管理情報)テンプレート(タグ '62')として返します。EF の場合、FCP にはファイルサイズ、アクセス条件、EF の構造(後述)、レコード長などが含まれます。端末はこれを見て「何バイト読めるのか」「PIN 検証が必要か」を判断します。なお、SELECT 直後はレコードポインタが未定義になるため、レコード構造のファイルでは続く READ RECORD で読む位置を明示的に指定します。

2-3. SFI — SELECTを省略できる近道

頻繁にアクセスする EF には SFI(Short File Identifier。5 ビットの短縮ファイル識別子)が割り当てられていることがあります。READ BINARY や READ RECORD のパラメータに SFI を含めると、SELECT を送らずに 1 コマンドで読み出しができ、対象の EF がカレント EF になります(TS 102 221 §8.4)。端末の起動時など初期化シーケンスの高速化に効きます。

3. ファイル構造と基本コマンドの対応

EF には 4 種類の構造があり、構造ごとに使うコマンドが異なります(TS 102 221 §8.2、§11.1)。

READ BINARY / UPDATE BINARY はオフセット(P1/P2)と長さを指定してバイト列を読み書きします(例: EF_IMSI)。READ RECORD / UPDATE RECORD はレコード番号または「次/前」の相対指定でレコード単位に読み書きします(例: 電話帳)。Cyclic EF は「最新 N 件」の用途に使われます。このほか STATUS や VERIFY PIN などがあり、PIN 検証が済んでいないと、アクセス条件で保護されたファイルの読み書きは拒否されます(ステータスワード '69 82' など)。

このコマンドセットは端末からだけでなく、OTA 経由の RFM(Remote File Management。遠隔ファイル管理)でも同じものが使われます(TS 102 226 §7.1)。カードの論理構造を一度押さえれば、遠隔管理の理解にもそのまま使えます。

4. AIDによるアプリケーション選択

4-1. AIDの構造(TS 101 220)

UICC 上のアプリケーション(USIM、ISIM、ISD-R など)は、AID という 1〜16 バイトの識別子で一意に識別されます。AID の構造は ETSI TS 101 220 で定義されており、次の 2 要素から成ります。

AID (最大16バイト) = RID (5バイト) + PIX (最大11バイト)

カード上のアプリケーション一覧は、MF 直下の EF_DIR(FID '2F00')に記録されています。端末は起動時にこれを読み、見つけた AID に SELECT を発行します。

4-2. SELECT by DF name — アプリケーションの活性化

アプリケーションの選択には、SELECT の P1 = '04'(DF 名 = AID による選択)を使います(TS 102 221 §8.5)。AID で明示的に選択すると、そのアプリケーションの ADF がカレント ADF になり、アプリケーションセッションが始まります。以後、カレント ADF は特別な FID '7FFF' で暗黙的に参照できます。端末が「いま有効な USIM 配下の EF」を選ぶパスに '7FFF' が現れるのはこのためです。

AID は右側を省略した部分 DF 名でも選択できます。P2 で「最初/次/前/最後」の出現を指定でき、同じ RID を持つ複数アプリケーションを順に列挙する、といった使い方をします。マルチアプリケーションカードでは部分 DF 名選択のサポートが必須です(TS 102 221 §8.5.1.2)。セッションの終了も SELECT で行い、P2 のセッション制御ビットで「活性化/リセット」と「終了」を指定します(TS 102 221 Table 11.2)。

USIM や ISIM の ADF 配下に何があるかは、次回の USIM/ISIMアプリケーション詳解で掘り下げます。

5. 論理チャネル — 複数アプリケーションを同時に使う

5-1. チャネル番号はCLAバイトに埋め込まれる

論理チャネルは、1 枚の UICC と複数の独立した会話を並行して行う仕組みです。各 APDU がどのチャネル宛かは、CLA バイトに埋め込まれたチャネル番号で示されます(TS 102 221 §10.3)。CLA の下位 2 ビットがチャネル 0〜3 を、拡張 CLA の下位 4 ビットがチャネル 4〜19(拡張論理チャネル)を表します。

チャネル 0 は基本チャネルと呼ばれ、常に利用可能で閉じられません。端末が TERMINAL CAPABILITY で拡張論理チャネル対応を申告しない限り、UICC が開くのは基本チャネル + 最大 3 本までです。

5-2. MANAGE CHANNELによる開閉

チャネルの開閉には MANAGE CHANNEL コマンドを使います(TS 102 221 §11.1.17)。P1 = '00' で開き(チャネル番号は UICC が割り当ててレスポンスで返す)、P1 = '80' で閉じます。開いた直後のカレント DF は、基本チャネルから開いた場合は MF、それ以外のチャネルから開いた場合は元のチャネルのカレント DF を引き継ぎます。

開いた後は、チャネルごとにカレント DF / カレント EF が完全に独立します。チャネル間でコマンドとレスポンスが交錯することはなく、活性なのは常に 1 チャネルだけです。ただし、同じファイルを複数チャネルから同時に触れるかどうかは、ファイル記述子の Shareable ビットで決まります(TS 102 221 §8.8)。Not-shareable のファイルがあるアプリケーションのカレントファイルになっている間、他のアプリケーションはそのファイルを操作できません。

5-3. 実務でどう使われているか

論理チャネルは、現代のスマートフォンでは日常的に使われています。基本チャネルで USIM を通信・認証に使いながら、別チャネルで ISIM(IMS 認証用)を並行して使うのが代表例です。eSIM 対応端末の LPA も、eUICC 内の ISD-R を専用の論理チャネルで SELECT し、ES10 コマンド(プロファイルの一覧取得や有効化)を送っています。「チャネルを開く → AID で SELECT → アプリ固有の APDU をやり取りする → チャネルを閉じる」というパターンは、UICC を扱うソフトウェアに共通する基本形です。

まとめ

• UICC はカレント DF / カレント EF という状態を持ち、SELECT で選んでから READ/UPDATE 系で読み書きする 2 段階操作が基本です

• SELECT は P1 で 5 通りの選択方法を切り替え、成功時は FCP テンプレート(タグ '62')でファイル属性を返します

• EF は Transparent / Linear Fixed / Cyclic / BER-TLV の 4 構造で、構造ごとに対応コマンドが決まっています

• アプリケーションは RID + PIX から成る AID で識別され、SELECT by DF name(P1 = '04')で活性化します。カレント ADF は FID '7FFF' で参照できます

• 論理チャネルは CLA バイトでチャネル番号を運び、MANAGE CHANNEL で開閉します。チャネルごとにカレント DF / EF が独立します

APDU の文法(前回)と本稿の論理構造を押さえると、USAT・OTA・LPA と eUICC のやり取りまで、カード関連技術の大半が「SELECT と基本コマンドの応用」として読めるようになります。

参考規格

• ETSI TS 102 221 V18.3.0 — Smart Cards; UICC-Terminal interface; Physical and logical characteristics

• ETSI TS 101 220 — Smart Cards; ETSI numbering system for telecommunication application providers

• ETSI TS 102 226 V19.0.0 — Smart Cards; Remote APDU structure for UICC based applications

• ISO/IEC 7816-4 — Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange

• 3GPP TS 31.101 — UICC-terminal interface; Physical and logical characteristics

おわりに

弊社では「LibeSIM」として、SM-DP+やMVNO回線、eIM(eSIM IoT Remote Manager)、eUICC、IPA/LPAのご提供を行っております。 ご興味がございましたら、デモやPoC等行っておりますので、ぜひお問い合わせください。

https://common-creation.com/service/libesim