IDベース暗号（IBE）

IBE が解こうとした問題

通常の公開鍵暗号では、相手に暗号文を送る前に「その相手の公開鍵が本物か」を確かめる必要があります。この本人性を担保する仕組みが 公開鍵基盤（PKI） で、認証局が発行した証明書を検証し、失効も確認する――という一連の手間が前提になります。

1984年、Shamir はこれをひっくり返す発想を提示しました。公開鍵を「計算で作る任意の値」にするのをやめ、相手の識別子（ID）そのものを公開鍵にしてしまうというものです。ID とは、メールアドレス・電話番号・社員番号のような、すでに公知で本人と結びついた文字列です。alice@example.com を暗号化に使えるなら、証明書を取り寄せて検証する必要はありません。これが**IDベース暗号（Identity-Based Encryption, IBE）**です。

4つのアルゴリズムと登場人物

IBE は次の4つの手続きで定義されます。鍵の作り手が本人ではなく信頼された第三者である点が、通常の公開鍵暗号との決定的な違いです。

• Setup：**鍵生成センター（KGC）**が一度だけ実行する。**マスター秘密鍵（master secret key）と、全員で共有する公開パラメータ（public parameters）**の組を生成する。マスター秘密鍵は KGC が厳重に秘匿し、公開パラメータは全ユーザーに配布する。
• Extract（鍵導出）：ユーザーが本人確認を経て KGC に申請すると、KGC がマスター秘密鍵と ID から、そのユーザーの秘密鍵を計算して安全に手渡す。
• Encrypt：送信者が「相手の ID ＋ 公開パラメータ」で平文を暗号化する。相手がまだ秘密鍵を受け取っていなくても暗号化できる。
• Decrypt：受信者が KGC からもらった自分の秘密鍵で復号する。

ここで公開鍵に相当するのが ID、それを本人の秘密鍵に変換する「トラップドア」がマスター秘密鍵です。KGC はいわば PKI の認証局に対応しますが、証明書を署名するのではなく、秘密鍵そのものを生成する点が異なります。

証明書が要らない利点

IBE の最大の効用は、PKI が抱える運用コストの多くを消せることです。従来方式との違いを整理します。

失効については工夫が要ります。ID が固定だと秘密鍵を無効化できないため、実務では ID に日付や有効期間を連結します。たとえば公開鍵として alice@example.com || 2026-06 を使う設計にすると、KGC は毎月分の秘密鍵だけを配布すればよく、失効は「翌月分の鍵を渡さない」ことで実現できます。CRL や OCSP のような失効リストの配布・照会が不要になるわけです。

鍵預託（key escrow）という構造的課題

利点の裏返しが、IBE で最も重要な弱点です。秘密鍵を作るのは本人ではなく KGC であり、KGC はマスター秘密鍵を握っている以上、任意のユーザーの秘密鍵をいつでも生成できます。これは「KGC が全員の暗号文を復号し得る」ことを意味し、鍵預託（key escrow）問題と呼ばれます。

• 信頼の集中：KGC は全ユーザーの復号能力を潜在的に持つ、単一の絶大な信頼点になる。マスター秘密鍵の漏洩はシステム全体の崩壊を意味する。
• 否認防止との相性の悪さ：署名版（IDベース署名）では、KGC が本人になりすまして署名を偽造できてしまうため、否認防止が本質的に弱くなる。
• 前方秘匿性の限界：ID が固定なら秘密鍵も固定で、鍵更新の設計を別途入れないと前方秘匿性を確保しにくい。

緩和策として、複数の機関がマスター秘密鍵を分割保有し、全員（または閾値以上）が協力しないと個人鍵を導出できないようにする分散 KGC が知られています。これは Shamir 秘密分散 の考え方をマスター秘密鍵に適用し、単一の信頼点を複数に薄める設計です。それでも「本人以外が鍵を作れる」構造自体は残るため、預託が許容できない用途では素の PKI に軍配が上がります。

ペアリングによる実現（Boneh-Franklin）

Shamir が1984年に概念を示した後、実用的で安全性を証明できる IBE は長く未解決でした。2001年、Boneh と Franklin が**楕円曲線ペアリング（双線形写像）**を用いて初めて具体的に構成し、IBE を実用段階へ押し上げました。

ペアリングとは、2つの楕円曲線上の点を入力し、別の群の元を返す写像 e(P, Q) で、次の双線形性を満たします（P は生成元、a・b は整数）。

双線形性:  e(aP, bQ) = e(P, Q)^(ab)
# 片方の点をスカラー倍すると、結果がそのべき乗になる。
# → 掛ける順序を入れ替えても同じ値に到達できる。
e(aP, bQ) = e(bP, aQ) = e(P, Q)^(ab)

この「スカラーを入れ替えても同じ値になる」性質が IBE の心臓部です。Boneh-Franklin の枠組みを、群演算を隠して概念だけ示すと次のようになります。

Setup:
  s        = マスター秘密鍵（KGC だけが持つ整数）
  P        = 公開の生成点
  P_pub    = s * P            # 公開パラメータ（s は逆算できない = ECDLP）

Extract(ID):                  # KGC が本人の秘密鍵を作る
  Q_ID     = HashToPoint(ID)  # ID 文字列を曲線上の点に写す
  d_ID     = s * Q_ID         # ← マスター秘密鍵 s を掛けたものが個人鍵

Encrypt(ID, m):               # 送信者は s を知らずに暗号化
  Q_ID     = HashToPoint(ID)
  r        = 乱数
  g        = e(Q_ID, P_pub)   # = e(Q_ID, P)^s
  暗号文    = ( r*P ,  m XOR Hash( g^r ) )

Decrypt(d_ID, 暗号文=(U, V)):  # 受信者は個人鍵で復号
  共有値    = e(d_ID, U)       # = e(s*Q_ID, r*P) = e(Q_ID, P)^(s*r)
  m        = V XOR Hash(共有値)

なぜ復号できるのかが要点です。送信者側は g^r = e(Q_ID, P)^(s*r) を計算し、受信者側は e(d_ID, U) = e(s*Q_ID, r*P) を計算します。双線形性により両者は同じ値 e(Q_ID, P)^(s*r) に一致するため、送信者は s を知らずに、受信者は r を知らずに、同じ鍵を共有できます。安全性は、この値を第三者が求めるのが困難であること（双線形 Diffie-Hellman 仮定）に依存します。

HashToPoint は ID を曲線上の点へ決定的に写すハッシュで、暗号学的ハッシュとして扱えるようモデル化されます。ここが「文字列 ID を鍵材料に変える」橋渡しであり、任意の ID を公開鍵化できる仕掛けの本体です。

いつ使い、いつ避けるか

IBE は「証明書配布のコストが高く、かつ管理主体を一元的に信頼できる」閉じた環境で光ります。企業内・組織内のメール暗号化、IoT デバイス群への鍵配布、送信者側の準備を最小化したいシステムなどが典型です。

一方、鍵預託が許されないエンドツーエンド秘匿（個人間メッセージング等）や、否認防止を厳格に求める署名用途には向きません。そうした領域では、鍵を本人以外が作れない PKI と証明書、あるいは前方秘匿性を持つ鍵交換が選ばれます。

まとめ

IBE は「ID 文字列そのものを公開鍵にする」ことで、証明書の発行・検証・失効という PKI の運用コストを大きく削減する方式です。鍵の作り手を本人から**鍵生成センター（KGC）**へ移し、マスター秘密鍵から ID ごとの秘密鍵を導出します。この設計ゆえに、送信者は相手の ID だけで暗号化でき、失効も ID への有効期限埋め込みで扱えます。

代償が鍵預託（key escrow）――KGC が全員の秘密鍵を作れるという構造的な信頼集中で、用途を選ぶ最大の理由です。実現面では、2001年の Boneh-Franklin が楕円曲線ペアリングの双線形性 e(aP, bQ) = e(P, Q)^(ab) を使い、送信者と受信者が同じ鍵に到達する仕組みを与えました。鍵の作り手を誰が担うかという設計思想は 鍵管理ライフサイクル と、公開鍵の本人結合という論点は PKI と併せて捉えると、IBE が「信頼の置き方を付け替えた暗号」であることが立体的に見えてきます。