突貫で書いてしまった部分もあるので、大いに誤りを含む可能性があります。誤字・脱字レベルでも構いませんので、ご指摘ください。
また、予告なしに内容の加筆や構成の変更を行うことがありますが、読みやすくするためのものですので、ご容赦ください
自己紹介
秘密計算のスタートアップで働いている社会人１年目です
普段は、秘密計算の研究や社会実装を行なっています
学生時代は、耐量子計算機暗号（特に格子暗号）を研究していました
概要
社内の機密データをクラウドサーバに保存して, 社員の中で地位が高い人物のみにアクセスを許可したい
みたいな状況は多々あると思いますが, これはアクセスコントロールというものによって達成されます。
アクセスコントロールとは, あるデータに対して誰がアクセスできて誰がアクセスできないのかを制御することです。
本記事ではこれを達成するための方法として, まず従来の方法であるホワイトリストを用いたものを紹介します。
その後, ホワイトリストの問題点とそれを解決した属性ベース暗号について語り,
属性ベース暗号の良さを少しでもお伝えできればなと思います。
状況設定
登場人物の整理
本記事には, 以下の人物が登場します。
部署 X
- 部長X
- 平社員X
部署 Y
- 部長Y1
- 部長Y2
その他
- クラウドサーバ
- 認証局
彼, 彼女らは次のように定義されます。
- 部長X, 平社員X, 部長Y1, 部長Y2 は同じ会社の人間
- 下表のようにそれぞれが何らかの『部署』に所属し、何らかの『役職』に就いています。例えば、部長Xは『部署X』に所属する『部長』
- 認証局は、外部の信頼できる機関
ここで,『部署』や『役職』を属性と呼びます。
達成したいこと
ホワイトリストと属性ベース暗号を比較するにあたって, 本記事では次のような状況を考えます。
部長 Y1 は、クラウドサーバに "メッセージ" を保存して、『全ての部署』の『部長』の人物(部長 X, 部長 Y1, 部長 Y2)が "メッセージ" にアクセスできるようにしたい。
逆に言うと, 平社員 X はメッセージにアクセスできないように, アクセスコントロールを行いたい。
ホワイトリストを用いたアクセスコントロール
手順
この方法は次のような手順で行われます。
なお, 事前準備として, 部長 Y1 の "メッセージ" に対して, 全社員の『部署』『役職』をから誰にアクセスを許可して, 誰にアクセスを許可しないのか
を定義する以下の表のようなホワイトリストを作成しているものとする。
- 部長 Y1 がクラウドサーバに "メッセージ" を保存する。
-
部長 X, 部長 Y2, 平社員 X がこれにアクセスを試みるが, アクセス時にホワイトリストが間に挟まることで,
アクセスできる人間(部長 X, 部長 Y1, 部長 Y2)とできない人間(平社員 X)で区別される。
問題点と解決方法
この方法では, とある安全性上の問題が存在する。
それは, クラウドサーバの管理者が "メッセージ" にアクセスして, 内容を知れてしまうことである。
これをどう解決するのか？
単純な話, クラウドサーバに保存する前に 部長 Y1 が "メッセージ" を暗号化して, サーバに保存するものを "メッセージ" の暗号文にしてしまえばいい。
これを達成したのが属性ベース暗号である。
属性ベース暗号を用いたアクセスコントロール
属性ベース暗号は, 次のような手順で進む。
- 認証局が, "マスター公開鍵" と "マスター秘密鍵" を生成する。
その後, "マスター秘密鍵" から, 『部署』や『役職』という属性を用いて人数分の "属性付き秘密鍵" を生成する。
- 認証局は, "属性付き秘密鍵" をそれぞれの登場人物全員に送付する。
この際, 部長 X, 部長 Y2 が持っている秘密鍵の属性はそれぞれ『部署X かつ 部長』『部署Y かつ 部長』であり,
平社員 X が持っている秘密鍵の属性は『部署X かつ 平社員』である。
- "マスター公開鍵" を "メッセージ" の公開者である 部長 Y1 に送る。
-
部長 Y1 は, 自身が公開したい "メッセージ" を "マスター公開鍵" を用いて暗号化し,
「秘密鍵の属性が『全ての部署 かつ 部長』に含まれる場合のみ復号できる」という条件を暗号文に埋め込む。
結果として, 条件を満たす "属性付き秘密鍵"（例：部長 X の "属性付き秘密鍵" など）によってのみ復号できる "属性付き暗号文" が生成される。
- 生成した "属性付き暗号文" をクラウドサーバに保存する。
-
部長 X, 部長 Y2 はクラウドサーバにアクセスし,
自身の持っている "属性付き秘密鍵" でクラウドサーバ上の "属性付き暗号文" を復号することで, 元の "メッセージ" に戻す。
この際, 部長 X, 部長 Y2 が持つ秘密鍵の属性は 部長 Y1 が生成した暗号文の属性『全ての部署 かつ 部長』に含まれるため, 復号は成功する。
なお, このとき 平社員 X が持っている属性付き秘密鍵の属性は, 暗号文の属性『全ての部署 かつ 部長』に含まれないため,
平社員 X は "属性付き暗号文" にアクセスできたとしても復号することはできない。
上記の属性ベース暗号では, クラウドサーバの管理者は "属性付き暗号文" を知っているが,
それを復号できる "属性付き秘密鍵" を持っていないため, クラウドサーバ側に "メッセージ" の内容を知られることはない。
感想
属性ベース暗号に触れてみての個人的な感想ですが, 秘密鍵に付与する属性や暗号文に埋め込む復号成功のための条件がどのように数学的に表現されていて,
どのようにこれらが暗号の中に組み込まれているのかが気になるところです。
調べたところ格子を用いた属性ベース暗号も存在しているようなので, その辺りから暗号の具体的な構成方法について調べてみたいなと思いました。
また, 属性ベース暗号と準同型暗号の性質を組み合わせて, クラウドサーバに保存した暗号文を復号せずに、サーバー内で暗号文に埋め込まれた条件を変えるとかできたら面白そうだなと思いました。
まとめ
アクセスコントロールを達成する方法として, ホワイトリストを用いたものと属性ベース暗号を紹介しました。
ホワイトリストを用いた従来の方法では, クラウドサーバ側に "メッセージ" の内容を知られてしまうという安全性上の問題が存在します。
それに対して, 属性ベース暗号では, "メッセージ" を暗号化することでクラウドサーバから, それの内容を秘匿することができます。
なお, ホワイトリストと比べたときの属性ベース暗号のデメリットとして, 鍵発行機関として認証局が必要になる点が挙げられます。