eSIMの認証試験とテストとは？SGP.23とGCF/PTCRBを詳しく解説

こんにちは、コモン・クリエーションでIoT・SIMエンジニアリングサービスの事業責任者をしている山本です。 本記事では、eSIMの「テスト」と「相互接続性(インターオペラビリティ)」を取り上げます。仕様書どおりに作ったはずのeUICC・端末・サーバーが、なぜ現場でつながらないことがあるのか。それを防ぐために、どのようなテスト仕様と認証制度が用意されているのかを整理します。

はじめに

eSIMのエコシステムは、eUICCを作るEUM、端末を作るOEM、SM-DP+やeIMを運用する事業者など、多数のプレイヤーの実装が組み合わさって初めて動きます。それぞれがGSMAの仕様(SGP.22やSGP.32)を読んで実装しても、解釈の揺れや実装差は必ず生まれます。この差を吸収する仕組みが、テスト仕様と認証・相互接続性試験です。

本稿では、以下の項目を整理します。

• eSIMのテストが「誰の・何を」対象にしているかの全体像

• GSMAのテスト仕様 SGP.23(Consumer向け)と SGP.33(IoT向け)の構成

• テストを支える周辺文書(SGP.24、SGP.26、TS.48)

• 端末認証スキームである GCF と PTCRB の位置づけ

• 相互接続性試験(interop試験)の実際と、現場でつまずきやすいポイント

1. まず全体像から — eSIMのテストをざっくり理解する

eSIMの仕様書は、いわば「楽譜」です。同じ楽譜でも演奏者によって解釈が分かれるように、同じSGP.22を読んでも、eUICCベンダーと端末メーカーとサーバー事業者で実装の細部は微妙に違ってきます。プロファイルのダウンロードは、この3者(IoTではeIMを加えた4者)の実装がプロトコルの1往復ごとに噛み合って初めて成功します。どこか1か所の解釈違いで、ダウンロードは途中で止まります。

そこでeSIMの世界では、コンポーネントごとに「単体で仕様どおり動くか」を検証するテスト仕様が定義され、さらに実機同士を組み合わせた相互接続性の確認が行われます。登場するテストは、大きく次の3層に分けられます。

• (1) は「各コンポーネントが仕様書どおりのメッセージを返すか」を機械的に確認する層です。

• (2) は (1) の試験結果を第三者が認定し、市場に出してよいと保証する層です。

• (3) は、それでも残る実装差を実機の組み合わせで洗い出す層です。

「認証を通ったのだから interop は不要では?」と思われるかもしれません。しかし適合性試験はあくまで「テストツール相手」の試験であり、実機同士の組み合わせで初めて顕在化する問題が残ります。この点は後半で具体例を挙げます。

2. GSMAのテスト仕様 — SGP.23とSGP.33の構成

2-1. Consumer向け: SGP.23シリーズ

SGP.23(RSP Test Specification)は、Consumer RSP仕様である SGP.22 に対応するテスト仕様です。当初は1冊の文書でしたが、現在は試験対象ごとに3部構成に分割されています。

各テストケースは「初期条件→手順→期待結果」の形式で記述され、SGP.22の該当セクションへの参照を持ちます。つまりSGP.23は、SGP.22の要求事項を「合否判定できる形」に書き直した文書だと捉えられます。SGP.22のインターフェース体系そのものはSM-DP+とESインターフェースの解説記事で整理しています。

2-2. IoT向け: SGP.33シリーズ

SGP.33(eSIM IoT Test Specification)は、IoT RSP仕様である SGP.32 に対応するテスト仕様で、SGP.23と同様に試験対象ごとの分冊構成が取られています。現時点で公開されているのは、eUICCを試験対象とする SGP.33-1(eSIM IoT Test Specification for the eUICC)で、ES10系コマンドへの応答やeUICC Packageの処理などIoT向けeUICCの動作を検証します。IoTデバイス(IPA)やサーバー側(eIM/SM-DP+)を対象とする分冊についても整備が進められています。

IoT RSPはConsumer RSPを土台にしているため、SGP.33もSGP.23と重複する部分が多く、IoT固有の要素(eIM、ESipa、IPA)の試験が上乗せされる構造です。SGP.32の全体像はSGP.31/SGP.32の解説記事を参照してください。

2-3. M2M向け: SGP.11

参考までに、M2M RSP(SGP.02)には SGP.11(Remote Provisioning Architecture for Embedded UICC Test Specification)が対応します。M2M/Consumer/IoTのいずれのアーキテクチャにも、本体仕様とテスト仕様が対になって存在する、という対応関係を押さえておくと文書体系が見通しやすくなります。

3. テストを支える周辺文書 — SGP.24・SGP.26・TS.48

テスト仕様単体では試験は回りません。実務では次の文書が組み合わさります。

• SGP.24(RSP Compliance Process) — 「何をもって適合(コンプライアント)と認めるか」の手続きを定めた文書です。eUICCやSM-DP+がGSMAのエコシステムに参加するには、このプロセスに沿った試験・宣言が必要になります。eUICC適合性試験に使うテストツール自体の品質確保は、GlobalPlatformのコンプライアンスプログラムが担っており、SGP.23をベースにした「GSMA eUICC Test Suite」に基づいてテストツールが認定(qualification)されます。

• SGP.26(RSP Test Certificates Definition) — 試験専用のPKI証明書一式を定義します。本番のGSMA Root CIにぶら下がる証明書を試験に使うわけにはいかないため、テスト用CIを起点とする証明書チェーンが別途用意されています。

• TS.48(Generic eUICC Test Profile) — 試験用の汎用テストプロファイルを定義した文書です。eSIM専用端末では「物理テストSIMを挿す」ことができないため、無線性能試験などで使う共通のテスト用プロファイルが必要になり、GCF/PTCRBの試験環境でも利用されています。

なお、機能適合性とは別の軸として、eUICC製造サイトやSM-DP+運用サイトのセキュリティを監査する SAS(Security Accreditation Scheme)、eUICC製品自体のセキュリティ評価である eSA(eUICC Security Assurance)があります。この認証・コンプライアンス制度の全体像はSAS認証の解説記事で扱っているため、本稿では機能テストに焦点を絞ります。

4. 端末認証 — GCFとPTCRB

eUICCやサーバーはGSMAのコンプライアンスプロセスで扱われますが、端末(スマートフォンやIoTデバイス)の認証は、業界団体の認証スキームに組み込まれています。

GCF と PTCRB は、もともと3GPPのプロトコル適合性試験や無線性能試験を束ねる端末認証スキームです。eSIM対応端末の普及に伴い、SGP.23系のテストケース(端末=LPA側の試験)が両スキームの認証項目に取り込まれました。端末メーカーから見ると、「GCF/PTCRB認証を取る過程で、LPAの仕様適合性も検証される」という建て付けです。

試験は認定テストラボが認定済みテストツールを使って実施します。ここで前述のTS.48テストプロファイルやSGP.26テスト証明書が使われます。試験環境では本番のSM-DP+ではなく、テストツールが模擬するSM-DP+(テストCI配下の証明書を持つ)に接続する、という点が実務上のポイントです。

5. 相互接続性試験(interop)の実際

適合性試験と認証を通っても、実機の組み合わせ試験(interop試験)は依然として重要です。弊社がSM-DP+やeUICCを扱う中でも、次のような「仕様適合しているのに噛み合わない」ケースは珍しくありません。

• プロファイル内容の解釈差 — プロファイルはTCA eUICC Profile Package形式で記述されますが、eUICCのOSによってサポートするテンプレートや任意項目の扱いに差があります。あるeUICCではインストールできるプロファイルが、別のeUICCではエラーになることがあります。

• メタデータとLPAのUI差 — プロファイル名やアイコンなどのメタデータの表示・扱いは端末のLPA実装に依存し、端末ごとに挙動が異なります。

• TLS設定の不一致 — SM-DP+と端末間のHTTPS通信で、TLSバージョンや暗号スイートの対応範囲がずれていると、RSP以前の接続段階で失敗します。

• バージョン混在 — SGP.22 v2系の端末とv3系のサーバーなど、世代の混在時のネゴシエーションは想定漏れが起きやすい領域です。

このため実務では、(1)テストツールでの適合性試験、(2)SGP.26テスト証明書を使ったテスト環境での組み合わせ試験、(3)本番相当の証明書・実プロファイルを使ったフィールド試験、と段階を踏んで検証します。GSMAや業界団体が主催する相互接続性テストイベントで、複数ベンダーの実装を持ち寄って一斉に検証する取り組みも行われています。

新しい仕様であるSGP.32のエコシステムでは、eIM・IPA・eUICCの組み合わせがまだ発展途上であり、interop試験の重要性はConsumer RSP以上に高いのが現状です。

まとめ

• eSIMのテストは「テスト仕様への適合性試験」「認証スキーム」「相互接続性試験」の3層で構成される。

• SGP.23はConsumer RSP(SGP.22)、SGP.33はIoT RSP(SGP.32)のテスト仕様で、いずれも試験対象(eUICC・端末・サーバー)ごとの分冊構成が取られている。

• 試験の実務は、コンプライアンス手続きのSGP.24、テスト用証明書のSGP.26、汎用テストプロファイルのTS.48が支えている。

• 端末側のeSIM試験はGCF/PTCRBという既存の端末認証スキームに組み込まれている。

• 適合性試験を通過しても実装差は残るため、実機を組み合わせたinterop試験とフィールド試験が欠かせない。

仕様書を正しく読むことと同じくらい、「他社実装と本当につながるか」を検証する体制がeSIMビジネスの品質を左右します。テスト仕様の体系を知っておくことは、その第一歩です。

参考規格

• GSMA SGP.22 v3.1 — RSP Technical Specification

• GSMA SGP.23-1/-2/-3 — RSP Test Specification

• GSMA SGP.24 — RSP Compliance Process

• GSMA SGP.26 — RSP Test Certificates Definition

• GSMA SGP.32 v1.3 — eSIM IoT Technical Specification

• GSMA SGP.33-1 — eSIM IoT Test Specification for the eUICC

• GSMA SGP.11 — Remote Provisioning Architecture for Embedded UICC Test Specification

• GSMA TS.48 — Generic eUICC Test Profile for Device Testing

おわりに

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

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