devsumi発表資料

1. クラウドを支えるこれからの暗号技術
Developers Summit 2015（ 2/19 ）
サイボウズ・ラボ 光成滋生

2. 光成滋生（@herumi, github.com/herumi）
午後のこ～だ
放送型暗号の開発でIPA未踏スーパークリエータ
toyocryptの解読で情報化月間議長表彰
2010年電子情報通信学会（IEICE）論文賞
『「パターン認識と機械学習」の学習』
2012年度ジュンク堂コンピュータ書籍3位
2013年ペアリング暗号の世界最速実装
『クラウドを支えるこれからの暗号技術』
200ページオーバーのfree pdf 近日公開予定
自己紹介
2/36

3. 背景と動機
共通鍵暗号と公開鍵暗号
楕円曲線暗号
様々な要件と暗号技術
前方秘匿性
代理人再暗号
属性ベース暗号
準同型暗号
目次
3/36

4. 背景と動機
共通鍵暗号と公開鍵暗号
楕円曲線暗号
様々な要件と暗号技術
前方秘匿性
代理人再暗号
属性ベース暗号
準同型暗号
目次
4/36

5. 利用シーンの増大
買物、投資、個人情報
クラウドサービス
サーバに重要なデータを置く機会が増える
個人情報の流出の危険性
データ漏洩が怖いのでクラウドは使いたくない
安全にデータを管理するには
インターネットの普及と発展
「電子商取引に関する市場調査の結果」(経済産業省)
http://www.meti.go.jp/press/2014/08/
20140826001/20140826001.html
日本のBtoC-EC市場規模の推移
5/36

6. どうやってデータを守るのか
完全性：データが壊れたり改竄されたりしない
可用性：必要なときにアクセスできる
機密性：許可された人しかアクセスできない
暗号技術は情報セキュリティのごく一部
暗号だけではデータは守れない
情報漏洩の原因の大半は人
情報を扱う人に対する教育、対策などの投資が必要
とはいえ、暗号技術がないと始まらない
情報セキュリティ
6/36

7. 移動中のデータ（Data in Motion）
TLS, IPsec, VPN, ... : 公開鍵暗号
保管データ（Data at Rest）
AES, HMAC, ... : 共通鍵暗号、ハッシュ関数
利用中のデータ（Data in Use）
あまりない
今回は主にData in Useで使えそうな暗号技術の紹介
データの状態に応じた分類
7/36

8. 鍵の漏洩時に影響を減らしたい
前方秘匿性
復号できる人を変更したい
代理人再暗号
復号できる条件を自由に指定したい
属性ベース暗号、関数型暗号
暗号化したまま検索したい、計算したい
検索可能暗号、準同型暗号
暗号に対する要件と対応技術
8/36

9. 背景と動機
共通鍵暗号と公開鍵暗号
楕円曲線暗号
様々な要件と暗号技術
前方秘匿性
代理人再暗号
属性ベース暗号
準同型暗号
目次
9/36

10. 暗号化する鍵 = 復号する鍵
大昔から使われてきた暗号
鍵をどうやって共有するか？
共通鍵暗号
Aさん Bさん
10/36

11. 暗号化する鍵 ≠ 復号する鍵
1970年代に発明される（RSA暗号が有名）
各自が暗号に使う鍵と復号に使う鍵の二つを使う
が公開鍵 が秘密鍵
が公開鍵 が秘密鍵
公開鍵暗号
Aさん Bさん
11/36

12. 鍵長の増大
短い鍵の暗号は破られてしまう危険性
RSA暗号の鍵長が1024bit →2048bitと変化
RSA暗号以外の方式
鍵長が短くて安全な暗号が欲しい
楕円曲線暗号
256bit楕円曲線暗号は3072bit RSA暗号相当
一般でも使われるケースが増えている
ブラウザ、ビットコイン、...
アメリカ国家安全保証局（NSA）の推奨する暗号Suite Bは
楕円曲線暗号のみでRSAはない
RSA暗号から楕円曲線暗号へ
12/36

13. 背景と動機
共通鍵暗号と公開鍵暗号
楕円曲線暗号
様々な要件と暗号技術
前方秘匿性
代理人再暗号
属性ベース暗号
準同型暗号
目次
13/36

14. 上下、左右がつながった平面世界
“楕円”ではない
楕円曲線（EC : Elliptic Curve）
トーラス
14/36

15. 楕円曲線の上を一歩（𝑃）ずつ歩く
10歩でも1000歩でも10100歩でもすぐ移動できる
楕円曲線の中をうろうろする
𝑃
𝑂
2𝑃
3𝑃
4𝑃5𝑃 10100
𝑃
4𝑃
15/36

16. 現在地から何歩歩いたかを求めるのは難しい
計算問題の一方向性
𝑥から𝑥𝑃は簡単 𝑥𝑃から𝑥は難しい
歩数を求めるのは難しい
𝑃
𝑂
2𝑃
3𝑃
𝑥𝑃
どれだけ歩いたっけ？
16/36

17. 楕円曲線を使った鍵共有
𝑎𝑃, 𝑏𝑃からは𝑎𝑏𝑃は求められない
ECDH（EC Diffie-Hellman）
𝑎:秘密 𝑎𝑃:公開
𝑏:秘密𝑏𝑃:公開
𝑎𝑏𝑃 𝑏𝑎𝑃
二人だけの秘密の数字を共有
Aさん Bさん
17/36

18. 鍵生成
Aさんの秘密鍵 𝑎
Aさんの公開鍵 𝐾𝐴 = 𝑎𝑃
メッセージ𝑀の暗号化
乱数𝑟を使って𝐸𝑛𝑐 𝐾𝐴, 𝑀 ≔ 𝑟𝑃, 𝑀 + 𝑟𝐾𝐴
復号
 𝑐1, 𝑐2 ≔ (𝑟𝑃, 𝑀 + 𝑟𝐾𝐴)に対して
𝑐2 − 𝑎𝑐1 = 𝑀 + 𝑟𝐾𝐴 − 𝑎(𝑟𝑃) = 𝑀 + 𝑟𝑎𝑃 − 𝑎𝑟𝑃 = 𝑀
楕円曲線暗号
𝑀 𝑟𝑃, 𝑀 + 𝑟𝐾𝐴
𝐾𝐴
18/36

19. 背景と動機
共通鍵暗号と公開鍵暗号
楕円曲線暗号
様々な要件と暗号技術
前方秘匿性
代理人再暗号
属性ベース暗号
準同型暗号
目次
19/36

20. 盗聴疑惑
NSAがインターネット上の通信を盗聴、記録、分析
スノーデンが通信監視プログラム（PRISM）を告発
FBIがメールサービス提供者にRSAの秘密鍵を要求
一つの秘密鍵でそれまでの暗号文全てを復号できてしまう
前方秘匿性（PFS：Perfect Forward Secrecy）
毎回、使い捨て鍵を使おう
ECDHが使われる
2011年Googleが対応
2013年頃からtwitter, facebookなどが対応
cybozu.comも対応
case 1. 鍵漏洩の被害を減らしたい
20/36

21. Chromeでcybozu.comにアクセス
Ephemeral : はかない、一時的
ECDHE（ECDH Ephemeral）の利用例
21/36

22. Aさんは暗号化したデータをクラウドに置いた
Aの代理でBがそのデータにアクセスしたい
通常の方法
秘密鍵の共有
はしたくない
Aは一度暗号文をダウンロードしてB向けに再暗号化
めんどう
対象者がCさん、Dさんと増えると大変
case 2. 復号対象者を変更したい
22/36

23. 暗号文を復号することなくB向けに再暗号化
クラウド上で処理可能
クラウドには変換鍵𝑟𝐴→𝐵を渡す
クラウドは暗号文の中身を見られない
代理人再暗号
𝑐 𝐴 𝑚 𝑐 𝐵𝑚
𝐸𝑛𝑐 𝐾 𝐴
𝑚
点線内の操作を復号せずに行う
代理人再暗号化
𝐷𝑒𝑐 𝐾 𝐴 𝐸𝑛𝑐 𝐾 𝐵
𝐷𝑒𝑐 𝐾 𝐵
𝑅𝐸𝑛𝑐 𝐴→𝐵
𝑐 𝐴 𝑐 𝐵𝑚
𝐸𝑛𝑐 𝐾 𝐴
𝑚𝐷𝑒𝑐 𝐾 𝐵
𝑅𝐸𝑛𝑐 𝐴→𝐶 𝑐 𝐶
23/36

24. ペアリングを使う
𝑎𝑃と𝑏𝑃から𝑎𝑏𝑃は困難だが別の世界の𝑎𝑏𝑃′は可能
𝑒 𝑎𝑃, 𝑏𝑃 = 𝑎𝑏𝑃′, 𝑃′は別の世界での一歩
代理人暗号の構成
𝑎 𝑎𝑃 𝑏𝑃
容易
無理
𝑎𝑏𝑃 𝑎𝑏𝑃’
別世界（戻って来られない）
24/36

25. 初期化
𝑎 : 秘密鍵, 𝐾𝑎 ≔ 𝑎𝑃 : 公開鍵 ; ユーザごと
暗号化
𝐸𝑛𝑐 𝑀 ≔ (𝑟𝐾𝑎, 𝑀 + 𝑟𝑃′), 𝑟は乱数
通常の復号
𝑒 𝑟𝐾𝑎, 𝑃 = 𝑒 𝑟𝑎𝑃, 𝑃 = 𝑟𝑎𝑃′
𝑀 + 𝑟𝑃′ − 1/𝑎 𝑟𝑎𝑃′ = 𝑀
変換鍵 𝑟𝐴→𝐵 ≔ 1
𝑎 𝐾𝑏 = 𝑏
𝑎 𝑃
再暗号化
𝑅𝑒𝐸𝑛𝑐 𝑟𝐾𝑎 ≔ 𝑒 𝑟𝐾𝑎, 𝑟𝐴→𝐵
= 𝑒 𝑟𝑎𝑃, 𝑏
𝑎 𝑃 = 𝑟𝑏𝑃′
= 𝑟𝐾𝑏
′
代理人暗号の構成（2/2）
25/36

26. 書類を見られる人をコントロールしたい
暗号化zipファイルのメールと別にパスワードメール
複数人だとパスワードの共有
めんどう
多人数だと簡単なパスワードになってしまう
暗号化鍵と復号鍵が1対1なのが不便
アクセスコントロールを暗号に持ち込む
クラウドのアクセスコントロールとは別物
case 3. 復号条件をコントロールしたい
26/36

27. 暗号化時に復号できる人を条件で指定する
1個の暗号鍵に対して多数の復号鍵
and, or, not対応の効率がよい関数型暗号（2010年）
属性ベース暗号（ABE : Attribute-Based Enc.）
人事部か部長だけ
閲覧許可 人事部課長
開発部部長
開発部の新人
読める
読めない
開発部
27/36

28. 視聴したいコンテンツを指定する
コンテンツに属性をつけて暗号化
復号可能条件に応じたプリペイド式課金
コンテンツ配信への応用
SFかアニメか
ホラーでない映画
アニメ映画
SFアニメ
SF ホラー映画
SFアニメ
28/36

29. 秘密分散とペアリングの組み合わせ
秘密分散
一つのデータを複数人でシェア𝑠 = 𝑟1 + 𝑟2
とても複雑なので省略
論文と実装例
Software implimation of an Attribute-Based Encryption
scheme（共著）,IEEE Transactions on Computers, 2014
http://sandia.cs.cinvestav.mx/index.php?n=Site.CPABE
https://github.com/herumi/ate-pairing/
属性ベース暗号の仕組み
29/36

30. クラウドを100%信用できない
データは暗号化しておきたい
しかし、クラウドのリソースを使って計算はしたい
統計情報
個人データは暗号化したい
サーバで暗号化したまま身長や体重の平均値を計算
暗号化したまま結果を受け取りクライアントで復号
case 4. 暗号化したまま処理したい
30/36

31. 準同型 = 暗号化したまま演算する
準同型暗号（HE : Homomorphic Encryption）
123
𝑚1 = 123
𝑚2 = 654
654
777
クラウド上で
暗号化したまま足し算
777
暗号化して
クラウドに委譲
計算結果を取得して復号
31/36

32. 暗号化（再掲）
𝐸𝑛𝑐 𝑀 = 𝑟𝑃, 𝑀 + 𝑟𝐾𝐴 ; 𝐾𝐴はAの公開鍵 𝑟は乱数
二つのメッセージ𝑀1, 𝑀2を暗号化
𝐸𝑛𝑐 𝑀1 = 𝑟1 𝑃, 𝑀1 + 𝑟1 𝐾 𝐴
𝐸𝑛𝑐 𝑀2 = (𝑟2 𝑃, 𝑀2 + 𝑟2 𝐾 𝐴)
暗号文を足してみると
 𝑟1 𝑃 + 𝑟2 𝑃, 𝑀1 + 𝑟1 𝐾𝐴 + 𝑀2 + 𝑟2 𝐾𝐴
= 𝑟1 + 𝑟2 𝑃, 𝑀1 + 𝑀2 + 𝑟1 + 𝑟2 𝐾𝐴
= 𝑟′ 𝑃, 𝑀1 + 𝑀2 + 𝑟′ 𝐾𝐴 , 𝑟′ ≔ 𝑟1 + 𝑟2
= 𝐸𝑛𝑐(𝑀1 + 𝑀2)
楕円曲線暗号によるHEの実現
32/36

33. 加算だけ、乗算だけできるHEは1999年に登場
両方できるものが欲しい
andとxorができると任意の計算が可能
2009年に登場
しかし鍵サイズが数百MB～1GB...
SHE（Somewhat HE : ちょっとだけHE）
加法、乗法のみのHEより高機能
FHEよりは実用的
完全準同型暗号（FHE : Fully HE）
従来の暗号 加法HE SHE FHE
加算回数 × 任意回 十分な回数 任意回
乗算回数 × × 数回 任意回
処理性能 ◎ ○ △ ×
33/36

34. 投票
𝑚𝑖 = 0 𝑜𝑟 1
𝐸𝑛𝑐 𝑚1 + ⋯ + 𝐸𝑛𝑐 𝑚 𝑛 = 𝐸𝑛𝑐 𝑚1 + ⋯ + 𝑚 𝑛
統計計算
平均、分散、相関など
∑𝑥𝑖, ∑ 𝑥𝑖 − 𝑚 2, ∑𝑥𝑖 𝑦𝑖などは複数回の足し算と1回の掛け算
秘匿したままマッチングや検索
指紋、DNAなどの生体情報
加法HE : （産総研）範囲指定型問い合わせに対する
効率的なデータベース秘匿検索プロトコル
CSS2014最優秀デモンストレーション賞
HEの利用例
34/36

35. クラウド側の不正
本当に正しく処理しているのか?
クライアントのリソースをあまり使うことなく検証
クライアント側の不正
電子投票で2票入れてしまう
投票は0か1かはわからないけど2以上ではないことを検証
ゼロ知識証明の応用
「私がある情報を知っている」ことを
その情報を知らせずに証明する
悪意ある人たち
35/36

36. クラウドの発展により暗号の要件が多様化
暗号化鍵と復号鍵の自由度の高い関係
属性ベース暗号、関数型暗号
＋前方秘匿性や代理人再暗号の組み合わせ
秘密を守るだけでなく秘密を制御する暗号
準同型暗号、検索暗号
不正を防ぐ検証技術
ゼロ知識証明
まとめ
36/36