eSIMプロファイルのダウンロードとは？相互認証とBPPの仕組みを解説

こんにちは、コモン・クリエーションでIoT・SIMエンジニアリングサービスでプロジェクトマネジメントを担当している比嘉です。本記事では、Consumer eSIM で QR コードを読み取ってから回線が使えるようになるまでの裏側、すなわち SGP.22 が定めるプロファイルダウンロードフローを詳解します。

はじめに

スマートフォンで eSIM を開通するとき、ユーザーの操作は「QR コードを読み取って、確認ボタンを押す」だけです。しかしその数十秒の間に、端末・eUICC・SM-DP+ の三者は暗号学的に緻密な手順を実行しています。この手順を理解すると、ダウンロード失敗時の切り分けや SM-DP+ 側の実装判断が格段にやりやすくなります。

本稿では、GSMA SGP.22 v3.1 の Section 3 に基づいて以下を整理します。

• ダウンロードフロー全体の 3 フェーズ構成

• Common Mutual Authentication(共通相互認証)の仕組み

• BPP(Bound Profile Package)の構造とセグメント暗号化

• ダウンロードセッションからインストール完了までのシーケンス

SM-DP+/LPA/eUICC の役割分担は、Consumer RSPアーキテクチャの記事と ESインターフェースの記事を先にお読みいただくと理解がスムーズです。

1. まず全体像から — プロファイルダウンロードをざっくり理解する

プロファイルダウンロードは、たとえるなら「本人限定受取の書留郵便」です。差出人(SM-DP+)は、受取人(特定の eUICC)としか開けられない封筒に中身(プロファイル)を封入します。配達員(LPA)は封筒を運ぶだけで、中身を開けることはできません。そして受け渡しの前には、差出人と受取人が互いに身分証(電子証明書)を提示し合います。

フローは大きく 3 つのフェーズに分かれます。

1. 相互認証 — eUICC と SM-DP+ が電子証明書で互いを本物と確認する

2. バインド — この eUICC 専用の暗号鍵を合意し、プロファイルを「その eUICC でしか開けない」形(BPP)に変換する

3. 転送・インストール — LPA が BPP を小分けにして eUICC へ流し込み、eUICC 内部で復号・インストールする

重要なのは、LPA(端末側のソフトウェア)は最後までプロファイルの中身を見られないという点です。

「プロファイルを守るのは端末ではなく、SM-DP+ と eUICC の間のエンドツーエンド暗号」

2. Common Mutual Authentication — すべてはここから始まる

Common Mutual Authentication(共通相互認証。SGP.22 v3.1 Section 3.0.1)は、ダウンロードに限らず SM-DP+/SM-DS との全セッションに共通する入口の手続きです。チャレンジレスポンスと ECDSA 署名を双方向に行います。

ポイントを順に押さえます。

• LPA はまず eUICC から 16 バイトの乱数 euiccChallenge を取得し、ES9+.InitiateAuthentication で SM-DP+ に渡します。

• SM-DP+ は euiccChallenge を含むデータに署名した serverSigned1 と認証用証明書 CERT.DPauth を返します。eUICC はこの署名を検証し、「GSMA Root CI につながる正規の SM-DP+ が、いま自分の出した乱数に応答した」と確認できます。

• 逆方向では、eUICC が SM-DP+ の出したチャレンジに対して euiccSigned1 に署名し、eUICC 証明書と EUM 証明書を添えて返します。SM-DP+ は証明書チェーンをたどって eUICC の真正性と EID を確認します。検証に失敗すると eidMismatch、noEligibleProfile などのエラーコードが返るため、失敗時の切り分けはまずここを見ます。

認証が成功すると、SM-DP+ は Activation Code の MatchingID に対応するプロファイルを特定し、その Profile Metadata(ICCID、プロバイダ名、アイコンなど)と、ダウンロード内容に対する署名 smdpSigned2 を返します。LPA はここでユーザーに「このプロファイルをダウンロードしますか」という確認画面を表示できます。

3. BPP — プロファイルは4段階に姿を変える

ダウンロードの対象となるプロファイルは、SM-DP+ の内部で 4 つの形態を経ます(SGP.22 v3.1 Section 2.5.1)。

• UPP(Unprotected Profile Package) — PE(Profile Element。ファイルシステム、鍵、アプレット等の構成要素)の TLV を並べた平文列。フォーマットは TCA eUICC Profile Package 仕様で定義される

• PPP(Protected Profile Package) — UPP を最大 1,020 バイトのセグメントに分割し、暗号化・MAC 付与したもの

• BPP(Bound Profile Package) — PPP の前に鍵合意情報・ISD-P 設定・メタデータを付加し、特定の eUICC に紐付けたもの

• SBPP(Segmented Bound Profile Package) — LPA が BPP を STORE DATA APDU のスクリプトに再分割したもの

3-1. BPPの内部構造 — ブロックごとに保護レベルが違う

BPP は「Profile Package Binding」機能で生成され、PPP を特定の eUICC に暗号学的に結び付けます(SGP.22 v3.1 Section 2.5.4)。BPP は 5 種類のブロックが順に並ぶ TLV 列で、ブロックごとに保護方式が異なる点が設計の要です。

このセグメント暗号化には 2 つの狙いがあります。

• 一括生成と個別バインドの両立 — SM-DP+ はプロファイルを事前に大量生成し、ランダム鍵(PPK: Profile Protection Keys)で保護した PPP として保管できます。ダウンロード時は eUICC と合意したセッション鍵で PPK を包んで送る(ReplaceSessionKeys)だけでよく、本体の再暗号化が不要です。

• メタデータだけは検証可能に — StoreMetadata は MAC のみで保護されるため、eUICC はインストール前に PPR(Profile Policy Rules)等を検証できます。

なお v2 系ではこの保護方式を SCP03t(GlobalPlatform SCP03 の TLV 版)と呼び、v3 系では暗号スイートを一般化した BSP(BPP Security Protocol)という呼称に整理されました。

4. ダウンロードセッション詳解 — 鍵合意からインストール結果まで

相互認証後のダウンロード本体(SGP.22 v3.1 Section 3.1.3)を追います。

4-1. 鍵合意の準備 — ワンタイム鍵ペア

LPA が ES10b.PrepareDownload を呼ぶと、eUICC は smdpSigned2 の署名を検証したうえで、このセッション限りのワンタイム鍵ペア(otPK.EUICC.KA/otSK.EUICC.KA)を生成し、公開鍵側を署名付き(euiccSigned2)で返します。Confirmation Code(ユーザーが入力する確認コード)が要求される場合、LPA はそのハッシュ値をここで渡します。コード不一致や規定回数超過は SM-DP+ 側で confirmationCodeRefused 等のエラーとして拒否されます。

4-2. バインドとダウンロード

LPA は eUICC の応答を ES9+.GetBoundProfilePackage で SM-DP+ に転送します。SM-DP+ は eUICC の署名を検証し、自身のワンタイム鍵と otPK.EUICC.KA から鍵合意でセッション鍵(S-ENC/S-CMAC)を導出し、前章の構造どおり BPP を組み立てて返します。この瞬間、プロファイルは世界でただ 1 つの eUICC 専用データになります。

4-3. インストール — LoadBoundProfilePackageの繰り返し

LPA は BPP を SBPP に再分割し、ES10b.LoadBoundProfilePackage を繰り返し呼んで eUICC に流し込みます(SGP.22 v3.1 Section 3.1.3.3)。eUICC 内部の処理順は次の通りです。

1. InitialiseSecureChannel を検証し、鍵合意アルゴリズムでセッション鍵を生成

2. ConfigureISDP を復号し、プロファイルの入れ物となる ISD-P(Issuer Security Domain - Profile)を作成

3. StoreMetadata の MAC を検証し、PPR 等のメタデータを検査

4. (PPK がある場合)ReplaceSessionKeys でセッション鍵を PPK に差し替え

5. '86' セグメントを順次復号し、PE を解釈してファイルや鍵をインストール

6. 署名付きの Profile Installation Result を生成して LPA に返却

途中でエラーが起きた場合も、eUICC はエラー内容を含む Profile Installation Result を不揮発メモリに保存してから LPA へ報告します。LPA はこの結果を ES9+.HandleNotification で SM-DP+ に届け、SM-DP+ は ES2+ 経由で MNO に通知します。インストール後の有効化(Enable)は「プロファイルの状態管理と通知」で扱います。

まとめ

• プロファイルダウンロードは「相互認証 → バインド(鍵合意) → 転送・インストール」の 3 フェーズで構成される

• Common Mutual Authentication では、eUICC と SM-DP+ が乱数チャレンジと ECDSA 署名・証明書チェーンで互いを検証する(SGP.22 v3.1 Section 3.0.1)

• プロファイルは UPP → PPP → BPP → SBPP と姿を変え、BPP 生成(バインド)によって特定の eUICC 専用になる

• BPP はブロックごとに保護レベルが異なり、本体は最大 1,020 バイトのセグメント単位で暗号化・MAC 保護される

• 暗号化の終端は SM-DP+ と eUICC であり、LPA・端末 OS はプロファイルの中身に触れられない

「なぜ eSIM は安全にネット経由で配れるのか」という問いへの答えは、このフローそのものです。SGP.22 v3.1 のシーケンス図を読む際の地図として、本稿をご活用ください。

参考規格

• GSMA SGP.22 v3.1 — RSP Technical Specification(Section 2.5 Profile Protection and Delivery、Section 3 Procedures)

• GSMA SGP.21 v2.7 — RSP Architecture

• TCA eUICC Profile Package: Interoperable Format Technical Specification v3.4.1

• GlobalPlatform Card Specification v2.3.1(SCP03)

おわりに

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

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