クラウドを支えるこれからの暗号技術

Developers Summit 2015（ 2/19 ）

サイボウズ・ラボ 光成滋生

光成滋生（@herumi, github.com/herumi）

午後のこ～だ

放送型暗号の開発でIPA未踏スーパークリエータ

toyocryptの解読で情報化月間議長表彰

2010年電子情報通信学会（IEICE）論文賞

『「パターン認識と機械学習」の学習』

2012年度ジュンク堂コンピュータ書籍3位

2013年ペアリング暗号の世界最速実装

『クラウドを支えるこれからの暗号技術』

200ページオーバーのfree pdf 近日公開予定

自己紹介

2/36

背景と動機

共通鍵暗号と公開鍵暗号

楕円曲線暗号

様々な要件と暗号技術

前方秘匿性

代理人再暗号

属性ベース暗号

準同型暗号

目次

3/36

背景と動機

共通鍵暗号と公開鍵暗号

楕円曲線暗号

様々な要件と暗号技術

前方秘匿性

代理人再暗号

属性ベース暗号

準同型暗号

目次

4/36

利用シーンの増大

買物、投資、個人情報

クラウドサービス

サーバに重要なデータを置く機会が増える

個人情報の流出の危険性

データ漏洩が怖いのでクラウドは使いたくない

安全にデータを管理するには

インターネットの普及と発展

「電子商取引に関する市場調査の結果」(経済産業省) http://www.meti.go.jp/press/2014/08/ 20140826001/20140826001.html

日本のBtoC-EC市場規模の推移

5/36

どうやってデータを守るのか

完全性：データが壊れたり改竄されたりしない

可用性：必要なときにアクセスできる

機密性：許可された人しかアクセスできない

暗号技術は情報セキュリティのごく一部

暗号だけではデータは守れない

情報漏洩の原因の大半は人

情報を扱う人に対する教育、対策などの投資が必要

とはいえ、暗号技術がないと始まらない

情報セキュリティ

6/36

移動中のデータ（Data in Motion）

TLS, IPsec, VPN, ... : 公開鍵暗号

保管データ（Data at Rest）

AES, HMAC, ... : 共通鍵暗号、ハッシュ関数

利用中のデータ（Data in Use）

あまりない

今回は主にData in Useで使えそうな暗号技術の紹介

データの状態に応じた分類

7/36

鍵の漏洩時に影響を減らしたい

前方秘匿性

復号できる人を変更したい

代理人再暗号

復号できる条件を自由に指定したい

属性ベース暗号、関数型暗号

暗号化したまま検索したい、計算したい

検索可能暗号、準同型暗号

暗号に対する要件と対応技術

8/36

背景と動機

共通鍵暗号と公開鍵暗号

楕円曲線暗号

様々な要件と暗号技術

前方秘匿性

代理人再暗号

属性ベース暗号

準同型暗号

目次

9/36

暗号化する鍵 = 復号する鍵

大昔から使われてきた暗号

鍵をどうやって共有するか？

共通鍵暗号

Aさん Bさん

10/36

暗号化する鍵 ≠ 復号する鍵

1970年代に発明される（RSA暗号が有名）

各自が暗号に使う鍵と復号に使う鍵の二つを使う

が公開鍵 が秘密鍵

が公開鍵 が秘密鍵

公開鍵暗号

Aさん Bさん

11/36

鍵長の増大

短い鍵の暗号は破られてしまう危険性

RSA暗号の鍵長が1024bit →2048bitと変化

RSA暗号以外の方式

鍵長が短くて安全な暗号が欲しい

楕円曲線暗号

256bit楕円曲線暗号は3072bit RSA暗号相当

一般でも使われるケースが増えている

ブラウザ、ビットコイン、...

アメリカ国家安全保証局（NSA）の推奨する暗号Suite Bは

楕円曲線暗号のみでRSAはない

RSA暗号から楕円曲線暗号へ

12/36

背景と動機

共通鍵暗号と公開鍵暗号

楕円曲線暗号

様々な要件と暗号技術

前方秘匿性

代理人再暗号

属性ベース暗号

準同型暗号

目次

13/36

上下、左右がつながった平面世界

“楕円”ではない

楕円曲線（EC : Elliptic Curve）

トーラス

14/36

楕円曲線の上を一歩（𝑃）ずつ歩く

10歩でも1000歩でも10100歩でもすぐ移動できる

楕円曲線の中をうろうろする

𝑃 𝑂

2𝑃

3𝑃

4𝑃 5𝑃 10100𝑃 4𝑃

15/36

現在地から何歩歩いたかを求めるのは難しい

計算問題の一方向性

𝑥から𝑥𝑃は簡単 𝑥𝑃から𝑥は難しい

歩数を求めるのは難しい

𝑃 𝑂

2𝑃

3𝑃 𝑥𝑃

どれだけ歩いたっけ？

16/36

楕円曲線を使った鍵共有

𝑎𝑃, 𝑏𝑃からは𝑎𝑏𝑃は求められない

ECDH（EC Diffie-Hellman）

𝑎:秘密 𝑎𝑃:公開

𝑏:秘密 𝑏𝑃:公開

𝑎𝑏𝑃 𝑏𝑎𝑃

二人だけの秘密の数字を共有

Aさん Bさん

17/36

鍵生成

Aさんの秘密鍵 𝑎

Aさんの公開鍵 𝐾𝐴 = 𝑎𝑃

メッセージ𝑀の暗号化

乱数𝑟を使って𝐸𝑛𝑐 𝐾𝐴, 𝑀 ≔ 𝑟𝑃,𝑀 + 𝑟𝐾𝐴

復号

𝑐1, 𝑐2 ≔ (𝑟𝑃,𝑀 + 𝑟𝐾𝐴)に対して

𝑐2 − 𝑎𝑐1 = 𝑀 + 𝑟𝐾𝐴 − 𝑎(𝑟𝑃) = 𝑀 + 𝑟𝑎𝑃 − 𝑎𝑟𝑃 = 𝑀

楕円曲線暗号

𝑀 𝑟𝑃,𝑀 + 𝑟𝐾𝐴

𝐾𝐴

18/36

背景と動機

共通鍵暗号と公開鍵暗号

楕円曲線暗号

様々な要件と暗号技術

前方秘匿性

代理人再暗号

属性ベース暗号

準同型暗号

目次

19/36

盗聴疑惑

NSAがインターネット上の通信を盗聴、記録、分析

スノーデンが通信監視プログラム（PRISM）を告発

FBIがメールサービス提供者にRSAの秘密鍵を要求

一つの秘密鍵でそれまでの暗号文全てを復号できてしまう

前方秘匿性（PFS：Perfect Forward Secrecy）

毎回、使い捨て鍵を使おう

ECDHが使われる

2011年Googleが対応

2013年頃からtwitter, facebookなどが対応

cybozu.comも対応

case 1. 鍵漏洩の被害を減らしたい

20/36

Chromeでcybozu.comにアクセス

Ephemeral : はかない、一時的

ECDHE（ECDH Ephemeral）の利用例

21/36

Aさんは暗号化したデータをクラウドに置いた

Aの代理でBがそのデータにアクセスしたい

通常の方法

秘密鍵の共有

はしたくない

Aは一度暗号文をダウンロードしてB向けに再暗号化

めんどう

対象者がCさん、Dさんと増えると大変

case 2. 復号対象者を変更したい

22/36

暗号文を復号することなくB向けに再暗号化

クラウド上で処理可能

クラウドには変換鍵𝑟𝐴→𝐵を渡す

クラウドは暗号文の中身を見られない

代理人再暗号

𝑐𝐴 𝑚 𝑐𝐵 𝑚 𝐸𝑛𝑐𝐾𝐴

𝑚

点線内の操作を復号せずに行う

代理人再暗号化

𝐷𝑒𝑐𝐾𝐴 𝐸𝑛𝑐𝐾𝐵 𝐷𝑒𝑐𝐾𝐵

𝑅𝐸𝑛𝑐𝐴→𝐵 𝑐𝐴 𝑐𝐵 𝑚

𝐸𝑛𝑐𝐾𝐴 𝑚 𝐷𝑒𝑐𝐾𝐵

𝑅𝐸𝑛𝑐𝐴→𝐶 𝑐𝐶

23/36

ペアリングを使う

𝑎𝑃と𝑏𝑃から𝑎𝑏𝑃は困難だが別の世界の𝑎𝑏𝑃′は可能

𝑒 𝑎𝑃, 𝑏𝑃 = 𝑎𝑏𝑃′, 𝑃′は別の世界での一歩

代理人暗号の構成

𝑎 𝑎𝑃 𝑏𝑃

容易

無理

𝑎𝑏𝑃 𝑎𝑏𝑃’

別世界（戻って来られない）

24/36

初期化

𝑎 : 秘密鍵, 𝐾𝑎 ≔ 𝑎𝑃 : 公開鍵 ; ユーザごと

暗号化

𝐸𝑛𝑐 𝑀 ≔ (𝑟𝐾𝑎, 𝑀 + 𝑟𝑃′), 𝑟は乱数

通常の復号

𝑒 𝑟𝐾𝑎, 𝑃 = 𝑒 𝑟𝑎𝑃, 𝑃 = 𝑟𝑎𝑃′

𝑀 + 𝑟𝑃′ − 1/𝑎 𝑟𝑎𝑃′ = 𝑀

変換鍵 𝑟𝐴→𝐵 ≔ 1𝑎 𝐾𝑏 =

𝑏𝑎 𝑃

再暗号化

𝑅𝑒𝐸𝑛𝑐 𝑟𝐾𝑎 ≔ 𝑒 𝑟𝐾𝑎, 𝑟𝐴→𝐵

= 𝑒 𝑟𝑎𝑃, 𝑏𝑎 𝑃 = 𝑟𝑏𝑃′ = 𝑟𝐾𝑏

′

代理人暗号の構成（2/2）

25/36

書類を見られる人をコントロールしたい

暗号化zipファイルのメールと別にパスワードメール

複数人だとパスワードの共有

めんどう

多人数だと簡単なパスワードになってしまう

暗号化鍵と復号鍵が1対1なのが不便

アクセスコントロールを暗号に持ち込む

クラウドのアクセスコントロールとは別物

case 3. 復号条件をコントロールしたい

26/36

暗号化時に復号できる人を条件で指定する

1個の暗号鍵に対して多数の復号鍵

and, or, not対応の効率がよい関数型暗号（2010年）

属性ベース暗号（ABE : Attribute-Based Enc.）

人事部か部長だけ閲覧許可 人事部課長

開発部部長

開発部の新人

読める

読めない

開発部

27/36

視聴したいコンテンツを指定する

コンテンツに属性をつけて暗号化

復号可能条件に応じたプリペイド式課金

コンテンツ配信への応用

SFかアニメか

ホラーでない映画

アニメ映画

SFアニメ

SF ホラー映画

SFアニメ

28/36

秘密分散とペアリングの組み合わせ

秘密分散

一つのデータを複数人でシェア𝑠 = 𝑟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

クラウドを100%信用できない

データは暗号化しておきたい

しかし、クラウドのリソースを使って計算はしたい

統計情報

個人データは暗号化したい

サーバで暗号化したまま身長や体重の平均値を計算

暗号化したまま結果を受け取りクライアントで復号

case 4. 暗号化したまま処理したい

30/36

準同型 = 暗号化したまま演算する

準同型暗号（HE : Homomorphic Encryption）

123 𝑚1 = 123

𝑚2 = 654

654

777

クラウド上で 暗号化したまま足し算

777

暗号化して クラウドに委譲

計算結果を取得して復号

31/36

暗号化（再掲）

𝐸𝑛𝑐 𝑀 = 𝑟𝑃,𝑀 + 𝑟𝐾𝐴 ; 𝐾𝐴は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

加算だけ、乗算だけできるHEは1999年に登場

両方できるものが欲しい

andとxorができると任意の計算が可能

2009年に登場

しかし鍵サイズが数百MB～1GB...

SHE（Somewhat HE : ちょっとだけHE）

加法、乗法のみのHEより高機能

FHEよりは実用的

完全準同型暗号（FHE : Fully HE）

従来の暗号 加法HE SHE FHE

加算回数 × 任意回 十分な回数 任意回

乗算回数 × × 数回 任意回

処理性能 ◎ ○ △ ×

33/36

投票

𝑚𝑖 = 0 𝑜𝑟 1 𝐸𝑛𝑐 𝑚1 +⋯+ 𝐸𝑛𝑐 𝑚𝑛 = 𝐸𝑛𝑐 𝑚1 +⋯+𝑚𝑛

統計計算

平均、分散、相関など

∑𝑥𝑖 , ∑ 𝑥𝑖 −𝑚 2, ∑𝑥𝑖𝑦𝑖などは複数回の足し算と1回の掛け算

秘匿したままマッチングや検索

指紋、DNAなどの生体情報

加法HE : （産総研）範囲指定型問い合わせに対する

効率的なデータベース秘匿検索プロトコル

CSS2014最優秀デモンストレーション賞

HEの利用例

34/36

クラウド側の不正

本当に正しく処理しているのか?

クライアントのリソースをあまり使うことなく検証

クライアント側の不正

電子投票で2票入れてしまう

投票は0か1かはわからないけど2以上ではないことを検証

ゼロ知識証明の応用

「私がある情報を知っている」ことを

その情報を知らせずに証明する

悪意ある人たち

35/36

クラウドの発展により暗号の要件が多様化

暗号化鍵と復号鍵の自由度の高い関係

属性ベース暗号、関数型暗号

＋前方秘匿性や代理人再暗号の組み合わせ

秘密を守るだけでなく秘密を制御する暗号

準同型暗号、検索暗号

不正を防ぐ検証技術

ゼロ知識証明

まとめ

36/36