動画配信サービスにも応用できる暗号とは――アクセス権を制御する「属性ベース暗号」：クラウド時代の暗号化技術論（6）（2/2 ページ）

アクセス木

　ABEを実現するアイデアを紹介しましょう。ポリシーはANDとORを組み合わせた木構造で表現できます。この木のことを「アクセス木」といいます。

　図4は(A∧B)∨((C∨D)∧E)という条件を表すアクセス木です。ここで∧はANDを、∨はORを表します。例えばAとBの条件を満たしているときはこのポリシーを満たすので復号できます。

図4 ポリシーを表すアクセス木

　AとBがそろったときに秘密鍵sを復元できるようにするには、Aに乱数r1を、Bにはs+r1を渡しておきます。すると二つの情報があれば(s+r1)-r1=sでsを復元できます。同様にC、Dに乱数r2を、Eにs+r2を渡しておくことで、CとE、あるいはDとEがそろえばsを復元できます。AとE、あるいはBとCだけがあっても、sを復元できません。

　このように秘密鍵をアクセス木に基づいて分散させる方法を、「線形秘密分散法（LSSS：Linear Secret Sharing Scheme）」といいます。LSSSと第5回で紹介したIDベース暗号（つまりペアリング）を組み合わせることで、ABEを実現できます。

秘密分散

　秘密分散について少し紹介しておきましょう。秘密分散とは、あるデータをn個に分割し、そのうちのk個が集まれば元のデータを復元できるという技術です。n個のうちどのk個からでも元のデータを復元できるのですが、k-1個しか集まらなければ元の情報は何も得られません。図4のアクセス木のAとBや、CとEからsを復元するのは、秘密分散のn=2、k=2のときの例です。

　秘密分散は、「n個の異なる点を通るn-1次関数はただ一つに決まる」という性質を使います。例えば、2個の点を通る直線はただ一つに決まります。図5は3次曲線の場合の例です。曲線上の異なる5点のうち、どの4個を選んでも元の3次曲線が決まります。例えば5人に秘密（=r0）を分散した場合、そのうちどの4人でもよいので集まると元の曲線が決まり、r0を復元できます。

図5 3次曲線上の異なる5点のうち、どの4個を選んでも元の3次曲線が決まる

　秘密分散自体は古典的な技術なのですが、今でもさまざまなところで利用される重要な技術です。最近ではさまざまな企業が秘密分散を利用したストレージの情報漏えい対策やデータ消失対策サービスを提供しています（参考リンク1、参考リンク2）。

関数型暗号

　前述のABEでは復号条件を細かく指定できましたが、指定された属性の情報は暗号文とは別に存在するため、第三者が知ることができてしまいます。例えばある暗号文に「社外秘」や「神経内科」といった属性が付与されていることが分かってしまう可能性があります。

　そこで、このリスクを回避するために、属性も一緒に暗号化してしまう方式が考えられています。このような方式は属性を隠すので「attribute-hiding」と呼ばれ、より一般的な概念である「関数型暗号（FE：Functional Encryption）」の特殊系の一つと捉えられることが多いようです。

　関数型暗号の定義はここでは省略しますが、自由度の高い暗号ということで、高機能（functional）暗号、インテリジェント暗号と呼ばれることもあります（参考リンク）。

　2013年に三菱電機の川合豊氏、高島克幸氏は、「代理人再暗号化」の機能と組み合わせることでポリシーをクラウド上で変更できるようにした関数型暗号の方式を提案しています。前回紹介した代理人再暗号化では、暗号文の復号先を変更可能にしましたが、この方式ではポリシーを変更可能にしています。この技術は複数のペアリング写像を組み合わせた非常に複雑な枠組みを用いて実現されています（参考リンク：高安全な関数型代理人再暗号化（pdf））。

ABEの今後

　ABEや関数型暗号により暗号化、復号の組み合わせの自由度が大きく増しています。これらの暗号は従来のファイルやデータベースのアクセス権によるコントロールを、鍵発行機関と運用サーバーに分けたものと考えることができます。例えば社内に鍵発行サーバーを置き、暗号化されたデータは社外のクラウドに置くという運用が想定できます。鍵発行サーバーは信頼のおけるものが必要ですが、運用サーバーは既存のものでよくなります。

　前回のIDベース暗号の部分でも述べましたが、強い権限を持つ鍵発行機関の存在には問題や制約もあります。また、鍵発行機関を外部サービス化してしまうのは不安があるかもしれません。しかし、現在の公開鍵基盤でも、例えば認証局やタイムスタンプによる時刻の証明書を発行する機関はかなり信頼されています。そう考えると、ABE用に適切に管理された鍵発行機関を前提にした運用も十分に考えられます。システム全体を考慮した今後の進展が望まれるところです。