GlobalPlatformとセキュリティドメインとは?カード管理の仕組みを詳しく解説

無料ウェビナーのご案内
SIM・eSIMの基本を、動画でも学んでみませんか?
本ウェビナーでは、SIMカードとeSIMの違い、eUICC・プロファイル・SM-DP+の関係、プロファイルを遠隔で書き込む仕組みなどを、図を交えて約15分で解説します。
記事とあわせて全体像を整理したい方や、業務でeSIMを扱い始めた方におすすめです。学び直しや社内での情報共有にもご活用ください。
今すぐ申し込む(無料)
こんにちは、コモン・クリエーションでIoT・SIMエンジニアリングサービスの事業責任者をしている山本です。 本記事では、SIMカードを含むスマートカードの「カード管理の共通基盤」である GlobalPlatform と、その中心概念であるセキュリティドメインを解説します。SCP03/SCP11 といったセキュアチャネルや鍵管理まで、eUICC の理解に必要な範囲を整理します。
はじめに
前回のJavaCardとアプレットの記事では、カード上でアプリケーション(アプレット)を動かす実行環境を扱いました。しかし JavaCard 仕様だけでは「誰がアプレットをインストールしてよいのか」「その権限をどう分けるのか」が決まりません。この「カード上のコンテンツ管理と権限分離」を定めるのが GlobalPlatform です。eUICC の ISD-R/ISD-P/ECASD も、すべて GlobalPlatform のセキュリティドメインとして実装されています。
本稿では、以下の項目を GlobalPlatform Card Specification v2.3.1(以下 GPC)に基づいて整理します。
GlobalPlatform とは何か、JavaCard との役割分担
セキュリティドメイン(ISD/SSD/CASD)と特権(Privilege)
カードとアプリケーションのライフサイクル
セキュアチャネルプロトコル(SCP03/SCP11)と鍵管理
1. まず全体像から — GlobalPlatformをざっくり理解する
GlobalPlatform(スマートカードのコンテンツ管理を標準化する業界団体、およびその仕様群)は、一言でいうと「カードという建物の管理規則」です。
カードを1棟の貸しビルにたとえると、次のような対応になります。
ビルの所有者(カード発行者)は、ビル全体の管理権限を持つ
テナント(アプリケーション提供者)は、自分の区画だけの鍵を持つ
テナントの区画には所有者でも勝手に入れない(鍵が違うため)
入居・退去(アプレットのインストール・削除)には所有者の許可がいる
この「区画と鍵」に相当するのがセキュリティドメイン(Security Domain: カード上で鍵を保持し、暗号サービスとコンテンツ管理を担う特別なアプリケーション)です。カード発行者の鍵とアプリケーション提供者の鍵を別々のセキュリティドメインに分離することで、1枚のカードを複数の事業者が「互いの秘密を見せずに」共用できます。
JavaCard との役割分担はシンプルです。JavaCard がアプレットの「実行」を担い、GlobalPlatform がアプレットの「搬入・設置・撤去と、その権限管理」を担います。厳密には GlobalPlatform はカード OS の種類に依存しない仕様ですが、SIM/eUICC の世界では JavaCard との組み合わせが事実上の標準です。
2. GlobalPlatformカードの構成要素
GPC が定めるカード内部の主な構成要素は次の通りです。
構成要素 | 正式名称 | 役割 |
|---|---|---|
OPEN | GlobalPlatform Environment | コマンド振り分け、コンテンツ管理、特権の検査を行うカード内の中枢 |
GP レジストリ | GlobalPlatform Registry | アプリケーションと SD の AID・状態・特権を記録する台帳 |
ISD | Issuer Security Domain | カード発行者の SD。カードに必ず 1 つ存在 |
SSD | Supplementary Security Domain | 発行者以外の事業者向けの追加 SD(APSD とも呼ぶ) |
CASD | Controlling Authority Security Domain | 第三者機関の鍵・証明書を保持する特別な SD |
OPEN は受信した APDU を適切なアプリケーションへ届け、カードコンテンツの変更要求(ロード・インストール・削除など)が正当かどうかを GP レジストリの特権情報で検査します(GPC §6.6.3)。
2-1. セキュリティドメインの3種類
ISD は「ビルの所有者」です。カードの発行時に存在し、カード全体のライフサイクルを管理します。
SSD は「テナントの区画」です。アプリケーション提供者(AP)ごとに作成され、自分の鍵で自分のアプレットを管理します。
CASD は「中立の立会人」です。カード発行者からも独立した認証局(Controlling Authority)の鍵を保持します。
eUICC ではこの構造がそのまま使われています。ISD-R(RSP を司る SD)、ISD-P(プロファイルを収容する SD)、ECASD(eUICC の証明書・秘密鍵を保持する SD)は、いずれも GlobalPlatform の SD をベースに SGP.22 が役割を定義したものです。詳しくはeUICCアーキテクチャの記事を参照してください。
2-2. 特権(Privilege)による権限分離
SD やアプリケーションの「できること」は特権(Privilege: GP レジストリに登録される権限ビット)で決まります。代表的なものを挙げます(GPC §6.6)。
特権 | 意味 |
|---|---|
Authorized Management(AM) | 発行者の権限でカードコンテンツを直接管理できる |
Delegated Management(DM) | 発行者の事前承認(Token)付きで、SSD が自らコンテンツを管理できる |
Token Verification | DM の際に提示される Token(発行者の署名)を検証できる |
Receipt Generation | DM の実行結果に対する Receipt(証跡)を生成できる |
DAP Verification | ロードされるコードの署名(DAP)を検証できる |
Card Lock / Card Terminate | カードのロック・終了を要求できる |
AM を持つ SD は自律的に、DM を持つ SSD は「発行者が署名した Token の範囲内で」コンテンツ管理を行います。この 2 段構えにより、発行者は主導権を保ったまま管理作業を外部事業者へ委譲できます。
3. カードとアプリケーションのライフサイクル
GlobalPlatform はカード全体とアプリケーションのそれぞれに状態遷移を定義しています(GPC §5)。

OP_READY: 実行環境が動作可能で、ISD が発行前処理を受けられる状態
INITIALIZED: 発行前処理(パーソナライゼーション等)が進行した状態。OP_READY へは戻れない
SECURED: 発行後の通常運用状態。セキュリティポリシーが完全に施行される
CARD_LOCKED: カード機能を一時停止した状態。SECURED へ復帰できる
TERMINATED: カードの寿命終了。いかなる状態からも遷移でき、戻ることはできない
アプリケーション(アプレット)側は INSTALLED → SELECTABLE → (アプリ固有状態) → LOCKED、SD は INSTALLED → SELECTABLE → PERSONALIZED → LOCKED という遷移を持ちます。「インストールされただけではまだ選択できず、SELECTABLE になって初めて外部から SELECT できる」という点は、OTAによるリモートアプレット管理を行う際にも重要です。
4. セキュアチャネルプロトコル — SCP03とSCP11
SD に対する管理コマンド(鍵の投入、アプレットのロード等)は、平文では送れません。外部エンティティと SD の間で相互認証し、コマンドを保護する仕組みがセキュアチャネルプロトコル(SCP: Secure Channel Protocol)です。
4-1. SCP03 — 共通鍵(AES)ベース
SCP03(GPC Amendment D で定義される AES ベースの SCP)は、現在のカード管理の主力です。TDES ベースの旧世代 SCP02 は解読リスクが指摘されており、新規設計では SCP03 を使います。
SD には静的鍵 3 本(暗号用 ENC、MAC 用 MAC、鍵暗号用 DEK)を格納しておき、セッションごとに次の手順でチャネルを確立します。

INITIALIZE UPDATE の P1 ではキーバージョン番号(Key Version Number: SD 内の鍵セットを指す番号)を指定し、どの鍵セットでチャネルを開くかを選びます。確立後の保護レベルは C-MAC のみ、C-MAC+コマンド暗号化、さらにレスポンス側の R-MAC/R-暗号化と、要件に応じて選択できます。
4-2. SCP11 — 公開鍵(ECC)ベース
SCP11(GPC Amendment F で定義される楕円曲線暗号ベースの SCP)は、証明書による認証と鍵合意(ECKA)でセッション鍵を作ります。SCP03 と違い、事前に共通鍵を共有しておく必要がありません。
観点 | SCP03 | SCP11 |
|---|---|---|
暗号方式 | AES(共通鍵) | ECC(公開鍵)+ AES セッション鍵 |
事前共有 | 静的鍵 3 本の共有が必要 | 証明書チェーンの信頼点のみ |
認証 | チャレンジレスポンス | 証明書検証 + 鍵合意 |
主な用途 | 発行後のカード管理、OTA | 事前の鍵共有が難しい相手との管理 |
SCP11 には 3 方式があります(Amendment F §2.1)。OCE(Off-Card Entity)とカードが相互認証する SCP11a、カード側のみを OCE が認証する SCP11b(OCE 側の認証は別手段で担保)、そしてカードの認証に静的鍵のみを使うことで、カード群向けのパーソナライズスクリプトをオフラインで事前生成できる SCP11c です。
なお、eSIM のプロファイルダウンロードで使われる SCP03t(SGP.22 が定義する SCP03 の派生)や、SMS/HTTP ベースの OTA で使われる SCP80/SCP81(ETSI TS 102 225)も、この SCP ファミリーの一員です。GlobalPlatform を押さえておくと、RSP 仕様に登場する暗号処理の大半が「既視感のある構造」として読めるようになります。
4-3. 鍵管理
SD への鍵投入には PUT KEY コマンドまたは STORE DATA コマンドを使います。鍵はキーバージョン番号と鍵識別子の組で一意に参照され、投入時の鍵データは DEK で暗号化して保護されます(GPC §D.3)。運用では「輸送鍵で発行し、現場で本番鍵へ置き換える」といった鍵の世代管理をキーバージョン番号で実現します。
まとめ
GlobalPlatform は、JavaCard が担う「実行」に対して、カードコンテンツの「管理と権限分離」を標準化する仕様である
セキュリティドメイン(ISD/SSD/CASD)は鍵の分離境界であり、eUICC の ISD-R/ISD-P/ECASD もこの仕組みの上に定義されている
特権(AM/DM/Token/Receipt/DAP)により、発行者が主導権を保ったまま管理作業を委譲できる
カードは OP_READY → INITIALIZED → SECURED → CARD_LOCKED/TERMINATED というライフサイクルを持つ
管理コマンドは SCP03(共通鍵)や SCP11(公開鍵)のセキュアチャネルで保護され、鍵はキーバージョン番号で世代管理される
eSIM/RSP の仕様書を読むとき、GlobalPlatform は「行間の前提知識」として頻繁に現れます。SD・特権・SCP という 3 点を押さえておけば、SGP.22 や SGP.02 の暗号関連の記述をずっと読み解きやすくなります。
参考規格
GlobalPlatform Card Specification v2.3.1 — GPC_SPE_034
GlobalPlatform Card Specification Amendment D — Secure Channel Protocol '03'
GlobalPlatform Card Specification Amendment F — Secure Channel Protocol '11'
GSMA SGP.22 v3.1 — RSP Technical Specification
ETSI TS 102 225 / TS 102 226 — Secured packet structure / Remote APDU structure for UICC
おわりに
弊社では「LibeSIM」として、SM-DP+やMVNO回線、eIM(eSIM IoT Remote Manager)、eUICC、IPA/LPAのご提供を行っております。 ご興味がございましたら、デモやPoC等行っておりますので、ぜひお問い合わせください。

山本 真基
コモン・クリエーション株式会社
執行役員 LibeSIM事業責任者
当社にて、eSIM Tech Partner「LibeSIM」の立ち上げ・事業推進を主導。SM-DP+・eIM・MVNOをワンストップで提供し、eSIMの運用に必要なすべてをオープンに選択できる環境の実現を目指す。国内唯一のeIMプロバイダーとして、SGP.32時代のIoT接続管理の最前線に立つ。
