属性ベース暗号（ABE）

解きたい問題：宛先を決めずに暗号化したい

公開鍵暗号は「特定の受信者の公開鍵」で暗号化します。RSA でも楕円曲線でも、暗号文は 1 人の鍵に紐づき、暗号化の時点で宛先を確定させねばなりません。ところが実務では「誰に渡すか」を先に決められない状況が多くあります。医療記録を「担当医または当該科の指導医なら読める」形でクラウドに置きたい、社内文書を「人事部かつ課長以上」に共有したい――こうした要求を素朴な公開鍵暗号で満たすには、条件を満たす全員の鍵で個別に暗号化し、メンバーが増減するたびに暗号化し直すしかありません。

この矛盾を解くのが**属性ベース暗号（Attribute-Based Encryption, ABE）です。ABE は復号可否を受信者の識別子ではなく、属性の集合とアクセスポリシー（属性に関する論理式）**で決めます。データ所有者は「人事 AND (課長 OR 部長)」のようなポリシーを暗号文に埋め込み、各ユーザーは自分の属性に対応する秘密鍵を持ちます。属性がポリシーを満たすときだけ復号でき、満たさなければ暗号文からは何も分かりません。宛先を列挙する必要はなく、1 つの暗号文が「条件を満たす全員」に同時に届きます。土台となる公開鍵の考え方は 暗号の基礎 を前提とします。

IBE から ABE へ：識別子から属性へ

ABE の直接の祖先が**IDベース暗号（Identity-Based Encryption, IBE）**です。IBE では「メールアドレスなどの任意の文字列」をそのまま公開鍵に使え、秘密鍵は信頼できる鍵生成センター（KGC / PKG）がマスター秘密鍵から属性文字列に対して発行します。事前の鍵配布や証明書が不要になる代わりに、KGC が全ユーザーの鍵を作れる（鍵預託, key escrow）という前提を負います。

ABE は IBE の「単一の識別子」を「複数の属性の集合」へ、さらに「完全一致」を「論理式による部分一致」へ一般化したものと理解できます。IBE が id == "alice@example.com" の一致だけを判定するのに対し、ABE は (役職 == 医師) AND (診療科 == 循環器) のような閾値・論理条件を暗号のレベルで評価します。この一般化により、細粒度（fine-grained）なアクセス制御を鍵配布や再暗号化なしに実現できます。

二つの型：KP-ABE と CP-ABE

ABE にはポリシーと属性を、鍵と暗号文のどちらに埋めるかで二つの型があります。この配置の違いが「誰が共有条件を決めるか」を決定づけます。

KP-ABE では、暗号文は「このデータは {"部門":"財務", "機密度":"高", "年度":"2026"} である」といった属性のタグを持ちます。ユーザーの鍵には「財務 AND 機密度=高」のようなポリシーが焼き込まれ、暗号文のタグがそのポリシーを満たすものだけを復号できます。データ側は自分がどんなデータかを宣言するだけで、誰が読めるかは鍵発行時に決まる――監査担当に「財務かつ高機密のログだけ読める鍵」を配る、といった運用に向きます。

CP-ABE はこれを逆にします。暗号文が「財務 AND (課長 OR 部長)」というポリシーを持ち、ユーザーの鍵にはそのユーザーの属性集合（例 {"部門":"財務", "役職":"課長"}）が入ります。暗号化する人＝データ所有者が、その場で共有条件を書けるため、クラウドにファイルを置く際に「この条件の人に見せる」と宣言するデータ共有のメンタルモデルにそのまま合致します。実務でクラウド共有といえば通常 CP-ABE を指します。この属性・ポリシーによる判定は、認可の世界でいう ABAC（属性ベースアクセス制御） を暗号のレイヤーで強制したものと位置づけられます。

ペアリングベースの構成：なぜ復号できるのか

ABE の中核は**楕円曲線ペアリング（双線型写像, bilinear map）**です。位数 p の群 G と G_T、生成元 g に対し、写像 e: G × G -> G_T が次の双線型性を満たします。この数理の詳細は 楕円曲線暗号（ECC）の内部 を参照してください。

双線型性:  e(g^a, g^b) = e(g, g)^(a*b)     # 指数を写像の外に括り出せる
非退化性:  e(g, g) ≠ 1                      # 自明でない値を返す

この「指数どうしを掛け合わせて G_T の指数に写す」性質が、秘密分散した値をペアリング計算の中で相殺・復元することを可能にします。CP-ABE の骨格を単純化すると次のようになります。

Setup   : マスター秘密 alpha を選び、公開鍵に e(g,g)^alpha を含める
Encrypt : メッセージ M を M * e(g,g)^(alpha*s) で隠す（s は暗号化ごとの乱数）
          さらにポリシーを LSSS 行列に変換し、乱数 s を各属性の成分へ秘密分散して暗号文へ
KeyGen  : ユーザーの各属性に対応する鍵成分を、マスター秘密 alpha を織り込んで生成
Decrypt : 属性がポリシーを満たすなら、対応する鍵成分と暗号文成分をペアリングし、
          線形結合して e(g,g)^(alpha*s) を再構成 → M を割り出して復号

要点は、M を覆う目隠し e(g,g)^(alpha*s) が、マスター秘密 alpha（鍵側）と暗号化乱数 s（暗号文側）の両方を含む点です。ユーザーの鍵成分と暗号文成分をペアリングすると、双線型性によって alpha と s が積の形で現れ、属性がポリシーを満たすときだけ秘密分散の線形結合が成立して目隠しをちょうど再構成できます。属性が足りなければ線形結合が閉じず、e(g,g)^(alpha*s) は決して復元できません。

クラウドでのデータ共有と実務上の課題

ABE がとりわけ映えるのがクラウドストレージでのデータ共有です。素朴なやり方では、ファイルを共有相手ごとの鍵で暗号化し、メンバー変更のたびに再暗号化とアップロードが要ります。CP-ABE なら、データ所有者はファイルを「条件付き」で一度暗号化してクラウドに置くだけでよく、クラウド事業者は暗号文を保管・配信するだけで中身も復号可否も判断しない。条件を満たす属性鍵を持つ利用者だけが、後からでも復号できます。

実運用では ABE を単体で使うより、ハイブリッド構成にするのが定石です。大きな本文は高速な共通鍵（AES-GCM など）で暗号化し、そのデータ暗号鍵（DEK）を CP-ABE で包む。ABE はペアリング計算を伴い重いので、暗号化対象を短い鍵に限定して性能を稼ぎます。これは エンベロープ暗号化と KMS と同じ発想で、KMS が「特定の鍵で DEK を包む」のに対し、ABE は「ポリシーで DEK を包む」点だけが異なります。

まとめ

属性ベース暗号（ABE）は、「宛先を確定せずに、条件を満たす人だけが復号できる」形の公開鍵暗号です。復号可否を属性の集合とアクセスポリシーで決めるため、1 つの暗号文を条件に合う全員へ一斉に届けられ、細粒度アクセス制御を鍵配布や再暗号化なしに実現します。**鍵ポリシー型（KP-ABE）**は鍵にポリシー・暗号文に属性を、**暗号文ポリシー型（CP-ABE）**は暗号文にポリシー・鍵に属性を配置し、データ所有者が共有条件を握りたいクラウド共有では CP-ABE が自然です。

構成は楕円曲線ペアリングを土台に、ポリシーを線形秘密分散に落とし込み、属性がポリシーを満たすときだけペアリング計算が相殺されて目隠し e(g,g)^(alpha*s) を再構成できる仕組みで復号を制御します。最大の攻撃である結託は、鍵ごとのランダム値を全属性成分に織り込むことで封じます。実務では本文を共通鍵で、そのデータ暗号鍵を CP-ABE で包むハイブリッド構成が定石で、失効・鍵預託・性能が実用上の壁として残ります。暗号のレベルでポリシーを強制する ABE は、アプリ層での 認可モデル（ABAC ほか） と、鍵で DEK を包む エンベロープ暗号化と KMS、数理の土台である 楕円曲線暗号の内部 と併せて押さえると、アクセス制御と暗号の接点がつかめます。