概要
IBE (Identity Based Encryption)
について簡単では有りますが備忘録的にまとめます。
そのあと、ossベースのライブラリで実際にどんな感じなのか調べてみようと思います。
また、PBCとはペアリングベースの暗号を実装したライブラリのことです。
https://crypto.stanford.edu/pbc/download.html
ここがリンクとなりますので、興味のある方はご覧ください。
IBE
は、ID-Based-Encryptionと呼ばれ、
Certificate Authority を介して、関与するパーティ間で公開鍵の交換なしに、
個人のIDベースで（IBE）
もしくは属性ベースで（ABE）
暗号化、もしくは復号化を行うことができます。
ペアリングベースの暗号を用いて実装することが研究されているようです。
考えられ得るユースケース
ユースケースとしては
ID-Based-Encryption では、
- 個人のメールアドレスや、電話番号、名前など個人特有のもの（ストリングなど）を用いて暗号化などを行いたい。
- 関与するパーティ（例えば５人が関与するシステムであればその５人）がそれぞれ全員に公開鍵を配布するのがシステム上難しい。
などが挙げられます。
流れとしては、
CA（マスターサーバー、もしくは秘密鍵生成サーバと考えてください。）が
マスターキーペアを生成。
関与パーティはマスター公開鍵を取得。
関与パーティはIDをCAに送信。
CAはIDベースの秘密鍵を生成、そのIDをもつパーティへと送り返します。
関与パーティが暗号化を行うときは、ID、マスター公開鍵、平文を入力とし、暗号文を出力。
復号時にはCAからもらったIDベースの秘密鍵を使い、暗号を復号します。
これにより、
例えばA,B,CAというシステム構成のとき、
本来のPKI（Public Key Infrastructure）であれば、
A->Bへ暗号によりメッセージを送信したい場合、
AはまずBの公開鍵を取得ー＞取得した公開鍵を用いて暗号化ー＞送信ー＞Bは自身の秘密鍵で復号
という流れが必要でしたが、IBEの枠組みでは
Aー＞ｂへ暗号によりメッセージを送信したい場合、
AはBのIDを取得ー＞BのIDとマスター公開鍵で暗号化ー＞送信ー＞Bは自身のID秘密鍵で復号
が可能となり、A->B, B->A の相互の公開鍵の配布が不要となります。
一つの制約として、信頼できるCAが必要となります。
なぜならCAはIDをベースとして各IDベースの秘密鍵を生成、各IDの持ち主へと配布する必要があるためです。
配布後にCAはこのIDベース秘密鍵を破棄することで、CAがずっと秘密鍵を保持しないようにすることも可能ですが、
生成ー＞配布のプロセスがあるのでその際はもちろんCAが信頼できるサーバとして機能する必要が有ります。
解説としては
http://bennycheung.github.io/attribute-based-encryption-for-healthcare-blockchain
ここなどが詳細に書かれており読み込んでみても良いかと思います。
ABE
ABE とは Attribute Based Encryption の略であり、
IBEの拡張版です。
ベースとして、公開鍵の相互交換なしにPKIインフラを作ります。
このとき、IBEと違うところは、
先程のように個人のIDベースで暗号化を行うのではなく、
属性をベースにして暗号化を行います。
例として、
例えば会社のデパートメント「部署A」「部署B」「部署C」、
会社の役職「役職A」「役職B」
があるとします。
このときに、暗号化を行う際、
(部署A && 役職A) or (役職B）
という属性をベースにして暗号化を行い、
その属性を持った人だけ（この属性を基にした秘密鍵はまたCAから生成、配布をしてもらいます）
所持している鍵を使って復号できる、ということになります。
かなりユースケースによっては面白いことができるのではないでしょうか。
試してみる
今回はOSSのライブラリを使ってABEを試してみたいと思います。
この実装を使ってみます。
https://github.com/sagrawal87/ABE
charm-crypto というCベースのライブラリに依存関係があるので、それらをまずはビルドする必要が有ります。
charm のビルドはこちらから。
https://github.com/JHUISI/charm
charm には３つの依存関係が有り、
- GMP 5.x
- PBC
- OPENSSL
となっています。PBCだけ少しビルドに詰まったので
その時役に立ったリンクを下に貼っておきます。
とりあえずこれに従ってみます。
https://written.4403.biz/archives/2009/04/pbc-library-on-ubuntu.html
pbc のダウンロードはこちらから。
https://crypto.stanford.edu/pbc/download.html
これが済むと、charm のビルドができるはずです。
charmがビルドできれば、ABEライブラリが難なくビルドできるかと思います。
その後、exampleとして載っているコードを走らせてみます。
'''
:Authors: Shashank Agrawal
:Date: 5/2016
'''
from charm.toolbox.pairinggroup import PairingGroup, GT
from ABE.ac17 import AC17CPABE
def main():
# instantiate a bilinear pairing map
pairing_group = PairingGroup('MNT224')
# AC17 CP-ABE under DLIN (2-linear)
cpabe = AC17CPABE(pairing_group, 2)
# run the set up
(pk, msk) = cpabe.setup()
# generate a key
attr_list = ['ONE', 'TWO', 'THREE']
key = cpabe.keygen(pk, msk, attr_list)
# choose a random message
msg = pairing_group.random(GT)
# generate a ciphertext
policy_str = '((ONE and THREE) and (TWO OR FOUR))'
ctxt = cpabe.encrypt(pk, msg, policy_str)
# decryption
rec_msg = cpabe.decrypt(pk, ctxt, key)
if debug:
if rec_msg == msg:
print ("Successful decryption.")
else:
print ("Decryption failed.")
if __name__ == "__main__":
debug = True
main()
ここでは実際に、
ユーザが
attr_list = ['ONE', 'TWO', 'THREE']
という属性を持っており、
policy_str = '((ONE and THREE) and (TWO OR FOUR))'
というポリシーを暗号文に持たせています。
よって、attr_list は policy を満足していることから、
この条件では復号が可能です。このような出力が出るかと思います。
Successful decryption.
しかしながら、
例えば
attr_list = ['ONE', 'TWO']
と仮にしてみると、今回はポリシーを満足しないので、
復号に失敗し、
Policy not satisfied.
Decryption failed.
となるはずです。
まとめ
今回は、IBE、ABEに関してまとめてみました。
従来の公開鍵システムに縛られない柔軟なシステム構築が可能となり、
ユースケースによってはこの構成が非常に適する状況があると考えています。
今回はこのへんで。
kenmaro