eSIMのセキュリティとは？PKIと証明書チェーンの仕組みをわかりやすく解説

こんにちは、コモン・クリエーションでIoT・SIMエンジニアリングサービスでプロジェクトマネジメントを担当している比嘉です。 本記事では、eSIM のリモートプロビジョニング(RSP)を支える PKI(公開鍵基盤)と証明書チェーンについて解説します。SM-DP+ と eUICC が初対面でも互いを信頼できるのはなぜか、という問いに仕様ベースで答えていきます。

はじめに

eSIM のプロファイルダウンロードでは、ネットワーク越しに SM-DP+ と eUICC が相互認証を行い、暗号化されたプロファイルをやり取りします。この一連の処理の土台になっているのが、GSMA が運営する eUICC PKI(公開鍵基盤)です。PKI の構造を理解しておくと、RSP の各手順が「なぜその順番で、なぜその証明書を使うのか」を筋道立てて読めるようになります。

本稿では、以下の項目について GSMA SGP.14・SGP.21・SGP.22 に基づいて整理します。

• eSIM の PKI に登場する証明書と鍵の全体像

• GSMA Root CI を起点とする証明書チェーンの構造

• eUICC 側で信頼の起点を保持する ECASD の役割

• プロファイルダウンロード時の相互認証(Common Mutual Authentication)で証明書がどう使われるか

• 証明書の失効と運用ルール

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

eSIM のプロファイルダウンロードでは、世界中のどの SM-DP+(プロファイルを配信するサーバー)と、どのメーカーの eUICC(eSIM 用チップ)が組み合わさっても、初対面のまま安全に通信を始められる必要があります。事前に共通の秘密鍵を配っておく方式では、この「初対面同士」の組み合わせ爆発に対応できません。

そこで使われるのが証明書チェーンです。身近な例で言えばパスポートに近い仕組みです。海外の空港で初対面の入国審査官があなたを信頼できるのは、あなた個人を知っているからではなく、パスポートを発行した政府を信頼しているからです。eSIM の世界では、この「政府」に相当するのが GSMA Root CI(Certificate Issuer。GSMA が統括するルート認証局)です。

• SM-DP+ は、GSMA Root CI が署名した証明書を持っています。

• eUICC は、チップ製造者である EUM(eUICC Manufacturer)が署名した証明書を持ち、その EUM の証明書は GSMA Root CI が署名しています。

つまり両者の証明書をたどると、どちらも同じ GSMA Root CI に行き着きます。互いに相手の証明書の署名を検証し、共通のルートまでさかのぼれれば「GSMA のエコシステムの正規メンバーである」と確認できる。これが eSIM の PKI の骨格です。

この PKI 全体のルールブックが SGP.14(GSMA eUICC PKI Certificate Policy)です。GSMA は PKI のポリシー策定機関(PKI Policy Authority)として、CA の運用条件・証明書の発行手続き・失効ルールを SGP.14 で定めています(SGP.14 v2.3 §2.3.1)。

2. 登場する証明書と鍵の整理

Consumer RSP(SGP.22)で使われる主な証明書を整理します。命名は「CERT.保有者.用途」の形式で、ECDSA(楕円曲線署名)の鍵ペアに対応する証明書には .ECDSA が付きます。

どの証明書がどの鍵で署名されるかをチェーンとして描くと次のようになります(SGP.14 v2.3 Figure 2、SGP.22 v2.6 Figure 30 に基づく構成図)。

ポイントは次の 3 点です。

• eUICC 証明書だけは EUM が署名する。GSMA CI が個々のチップに直接署名するのではなく、CI → EUM → eUICC という 2 段のチェーンになります。eUICC は製造時に鍵ペアと証明書を書き込まれるため、出荷台数分の署名を EUM 側で行える構造です。

• SM-DP+ は役割ごとに証明書を使い分ける。CERT.DPauth.ECDSA は eUICC への認証用、CERT.DPpb.ECDSA はプロファイルを特定の eUICC に結び付ける(バインドする)署名用です(SGP.22 v2.6 §4.5.2)。

• 中間 CA(SubCA)を挟むこともできる。SGP.14 v2.3 では、GSMA CI・EUM・SM-DP+・SM-DS の配下にオプションで SubCA を置くチェーン構成が認められています。また TLS 証明書に限っては、GSMA CI 以外のパブリック CA が発行する構成も許容されています(SGP.14 v2.3 §2.3)。

なお署名アルゴリズムには ECDSA が使われ、各 eUICC は少なくとも 2 種類の楕円曲線パラメータ(NIST P-256、brainpoolP256r1 など)をサポートします。1 本の証明書チェーンの中では、すべての証明書が同じ曲線を使う決まりです(SGP.22 v2.6 §4.5.2)。

厳密には、SGP.22 v3 系では用語と表記が更新されており、GSMA CI は eSIM CA と呼ばれ、証明書名も CERT.EUICC.SIG のように .SIG 表記へ変わっています。本稿では広く使われている v2 系の表記で統一します。

3. eUICC側の信頼の起点 — ECASD

サーバー側の証明書はデータセンターの HSM(ハードウェアセキュリティモジュール)で守られますが、eUICC 側の鍵はどこに置かれるのでしょうか。その答えが ECASD(eUICC Controlling Authority Security Domain。eUICC 内の証明書・鍵管理専用セキュリティドメイン)です。

ECASD は eUICC に 1 つだけ存在し、次の情報を保持します(SGP.22 v2.6 §2.4.2)。

• SK.EUICC.ECDSA — eUICC の秘密鍵。eUICC が署名を作るために使う

• CERT.EUICC.ECDSA — eUICC の証明書(公開鍵 PK.EUICC.ECDSA を含む)

• PK.CI.ECDSA — GSMA CI のルート公開鍵。SM-DP+ など外部エンティティの証明書を検証するために使う。複数の CI の公開鍵を持つこともできる

• CERT.EUM.ECDSA — 自分を製造した EUM の証明書

つまり ECASD は「自分の身分証と秘密鍵」に加えて「相手の身分証を検証するためのルート公開鍵」を保持する、eUICC 側の信頼の起点(トラストアンカー)です。ECASD は EUM が製造時にパーソナライズし、その作業は SAS-UP(GSMA の製造サイト向けセキュリティ認定)を取得した環境で行うことが義務付けられています。SAS-UP を含む認定制度の全体像は eSIMの認証・コンプライアンス制度の記事で扱います。

ECASD 自体は署名の作成と証明書の検証というサービスを提供するだけで、プロファイル管理は行いません。プロファイル管理を担う ISD-R や ISD-P との役割分担は、eUICCアーキテクチャの記事を参照してください。

4. 相互認証で証明書チェーンがどう使われるか

この PKI が実際に働く場面が、プロファイルダウンロードの冒頭で必ず実行される Common Mutual Authentication(共通相互認証)です。SGP.22 v3.1 §3.0.1 の手順を簡略化すると、次の流れになります。

各ステップで証明書チェーンは次のように使われます。

• ルートのすり合わせ: eUICC は euiccInfo1 の中で、自分が対応する CI 公開鍵の識別子リスト(euiccCiPKIdListForVerification / ForSigning)を提示します。SM-DP+ はその中から自分も対応できる CI を選びます。共通の CI が 1 つもなければ、手続きはそこで停止します。

• [1][2] eUICC がサーバーを認証: eUICC は ES10b.AuthenticateServer で受け取った CERT.DPauth.ECDSA を、ECASD 内の PK.CI.ECDSA で検証します。続いてサーバーの署名(serverSignature1)と、自分が発行したチャレンジ(euiccChallenge)の一致を確認します。チャレンジの照合により、過去の通信の再利用(リプレイ)を防ぎます(SGP.22 §5.7.13)。

• [3][4] サーバーが eUICC を認証: eUICC は自分の署名(euiccSignature1)を CERT.EUICC.ECDSA・CERT.EUM.ECDSA とともに返します。SM-DP+ は CERT.EUM を CI 公開鍵で、CERT.EUICC を EUM 公開鍵で検証し、チェーンをルートまでたどってから eUICC の署名を確認します。

双方の検証が通って初めて、その後の鍵合意(ECKA)とプロファイルの暗号化転送に進みます。ダウンロード全体のシーケンスはプロファイルダウンロードフロー詳解の記事で扱います。

5. 失効と運用 — チェーンを維持し続ける仕組み

PKI は「作って終わり」ではなく、鍵の漏えいに備えた失効の仕組みとセットで初めて機能します。

• 各 GSMA CI は自分が発行した証明書の失効情報を CRL(Certificate Revocation List。失効証明書のリスト)として公開します(SGP.22 v2.6 §2.7)。

• eUICC 証明書は 1 枚ずつ失効させません。発行数が膨大であることに加え、個別のチップより「特定モデルや製造ロット全体」が危殆化するケースの方が現実的だからです。この場合は、そのロットの eUICC 証明書に署名した EUM 証明書を失効させます。EUM がモデルやロットごとに EUM 証明書を分けておくのは、このためです。

• SM-DP+ の 2 枚の証明書には連動ルールがあり、CERT.DPpb.ECDSA を失効させる場合は対応する CERT.DPauth.ECDSA も失効させます(SGP.14 v2.3 §5.9)。

また、証明書の発行そのものにも統制があります。EUM や SM-DP+ が証明書を得るには、SGP.14 が定める CSR(証明書署名要求)の手続きに従い、GSMA の認定・監査をクリアしている必要があります。つまり証明書チェーンは、単なる暗号技術ではなく「GSMA のコンプライアンス体系に合格した事業者だけがつながれるチェーン」でもあります。

SGP.22 v3 系では、この運用面がさらに強化されています。CRL をセッション中にサーバー側から添付して eUICC に検証させる仕組み(CRL stapling)や、eUICC 内のルート公開鍵を後から追加・更新する手続き(SGP.22 v3.1 §3.10)が導入され、ルート CA の追加や将来の暗号移行に備えた構造になっています。

まとめ

• eSIM の PKI は GSMA Root CI を信頼の起点とし、SGP.14(GSMA eUICC PKI Certificate Policy)がその運用ルールを定めている。

• 証明書チェーンは 2 系統ある。サーバー側は CI → SM-DP+/SM-DS、カード側は CI → EUM → eUICC で、どちらも同じルートに到達するため相互認証が成立する。

• eUICC 側の鍵と証明書(SK.EUICC.ECDSA、CERT.EUICC.ECDSA、PK.CI.ECDSA、CERT.EUM.ECDSA)は ECASD が保持し、製造時に SAS-UP 認定環境でパーソナライズされる。

• プロファイルダウンロード冒頭の Common Mutual Authentication では、チャレンジと署名の交換を通じて、eUICC とサーバーが互いの証明書チェーンをルートまで検証する。

• 失効は CRL で管理され、eUICC 証明書は個別ではなく EUM 証明書単位(モデル・ロット単位)で失効させる設計になっている。

eSIM のセキュリティは、個々の暗号処理よりもまず「誰の署名をどこまでたどれば信頼できるか」というチェーンの設計で決まっています。RSP の手順書を読むときは、常に「いまどの証明書を、どの公開鍵で検証しているのか」を意識すると、仕様の見通しが一気に良くなります。

参考規格

• GSMA SGP.14 — GSMA eUICC PKI Certificate Policy v2.3

• GSMA SGP.21 — RSP Architecture v2.7

• GSMA SGP.22 — RSP Technical Specification v3.1(証明書定義は v2.6 §2.4.2/§2.7/§4.5.2、相互認証は v3.1 §3.0.1 を参照)

• GSMA SGP.02 — Remote Provisioning Architecture for Embedded UICC Technical Specification v4.2.1(M2M 向け証明書チェーン)

おわりに

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

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