Address
:
[go:
up one dir
,
main page
]
Include Form
Remove Scripts
Accept Cookies
Show Images
Show Referer
Rotate13
Base64
Strip Meta
Strip Title
Session Cookies
More Web Proxy on the site http://driver.im/
Submit Search
クラウドを支えるこれからの暗号技術
•
143 likes
•
64,145 views
MITSUNARI Shigeo
Follow
devsumi発表資料
Read less
Read more
1 of 36
Download now
Downloaded 374 times
More Related Content
クラウドを支えるこれからの暗号技術
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
Download