Transcript

• 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とorができると任意の計算が可能 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