SCIS2016発表資料

1. バックドア耐性のある
（パスワード）暗号化の提案
SCIS2016 2016/1/21
光成滋生

2. • 背景と動機
• パスワード暗号化
• バックドアつきパスワード暗号化
• バックドア耐性のあるパスワード暗号化の提案
• その安全性
• ハイブリッド暗号
• OpenPGPやIPSecで考える
• BR-secureの定義と構成
• まとめ
• （注記）発表後にXagawaさんから先行研究の紹介
• https://eprint.iacr.org/2014/438 ; ありがとうございます
目次
2/20

3. • 様々なフォーマットで利用できる
• ZIP
• pdf
• Microsoft Office file
• 基本的な構造
• パスワード（𝑝）に𝑠𝑎𝑙𝑡を合わせて
Hashを繰り返し適用する（stretch）
• 𝑠𝑎𝑙𝑡 : rainbowテーブル攻撃への耐性
• stretch : Brute-force攻撃への耐性
パスワード暗号化
𝑝
𝐻𝑎𝑠ℎ
𝑠𝑎𝑙𝑡
𝑆 𝐾 𝑚
𝐸𝑛𝑐
𝑚
𝑖𝑣
𝑛
3/20

4. • 8文字パスワードのBrute-force攻撃時間
• GeForce GTX860M 1019MHz
各種フォーマットの強度
File format # of tries/sec hash stretching days
ZIP(96-bit) 230000000 none 10 days
Office2003 doc 11000000 ? 220 days
ZIP(256-bit AES) 370000 1000 x HMAC SHA1 18 years
Office2007 docx 16000 50000 x SHA1 430 years
Office2010 docx 8100 100000 x SHA1 854 years
Office2013 docx 337 100000 x SHA512 20000 years
4/20

5. • ある条件下でパスワードを回避して復号可能
• 2015/7に見つけた（10月に修正済み : CODE BLUE 2015）
• もちろんこれはバックドアではなく単なるバグだが
見かけは普通の暗号化ファイルと全く区別がつかない
Microsoft Excelのちょっとしたバグ
master file
with pass
with pass1
with pass2
with pass3
save as...
have same secret key
5/20

6. • 信頼できるフォーマットって何だろう？
• 暗号化アルゴリズムはOpenで安全性は広く研究されている
• しかし実装はOpenであるとは限らない
• 大抵の暗号化モジュールはバイナリ提供
• ベンダーにとって
• ソースは公開したくないが私は悪いことはしていないと信用
してほしい
• ユーザにとって
• バイナリ提供でも信用するしかない？
動機
6/20

7. • 開発環境
• 2015/9 AppleのXcodeの海賊版XcodeGhost
• 2015/11 BaiduのMoplus SDK
• 企業向けfirewall製品
• 2015/12. SSH/telnet in Juniper Networks firewalls
• 攻撃者はVPNの通信を復号可能
• http://www.wired.com/2015/12/juniper-networks-
hidden-backdoors-show-the-risk-of-government-
backdoors/
• 2016/1. SSH in Fortinet FortiOS firewalls
• http://forums.juniper.net/t5/Security-Incident-
Response/Advancing-the-Security-of-Juniper-
Products/ba-p/286383
製品のバックドア
7/20

8. • 暗号文のみを考える
• 暗号時に外部と通信しない
• 暗号器の中身は分からない（ブラックボックス）
考察対象
暗号器
𝑚
(𝑠𝑎𝑙𝑡, 𝑐)
𝑝
外部
8/20
バックドアがある?

9. • 𝐻 : パスワードベースの鍵導出関数（PBKDF）
• 𝐸𝑛𝑐, 𝐷𝑒𝑐 : ブロック暗号の暗号化・復号関数
標準的なパスワード暗号化
Encryption
Input 𝑝 : password, 𝑚 : plaintext
𝑖𝑣 : random（or given）
𝑠𝑎𝑙𝑡 : random
𝑠 𝑘 ← 𝐻 𝑝, 𝑠𝑎𝑙𝑡
𝑐 ← 𝐸𝑛𝑐(𝑖𝑣,𝑠 𝑘)(𝑚)
Output (𝑠𝑎𝑙𝑡, 𝑖𝑣, 𝑐)
Decryption
Input 𝑝 : password, (𝑠𝑎𝑙𝑡, 𝑖𝑣, 𝑐) : ciphertext
𝑠 𝑘 ← 𝐻 𝑝, 𝑠𝑎𝑙𝑡
𝑚 ← 𝐷𝑒𝑐 𝑖𝑣,𝑠 𝑘
(𝑐)
Output 𝑚
9/20

10. • 攻撃者 Eve は秘密鍵 𝑋 を持っている
• 𝑋 は暗号器の中に埋め込まれている
• 𝑠𝑎𝑙𝑡は𝑝を𝑋で暗号化したもの ( 𝑝 ∼ |𝑠𝑎𝑙𝑡|を仮定).
• Eveは𝑋を使って𝑠𝑎𝑙𝑡から 𝑝を復号し𝑠 𝑘を得られる
• 𝑋を知らない人にとって𝑠𝑎𝑙𝑡は普通の乱数と区別できない
バックドアつき暗号化
Backdoor Encryption
Input 𝑝 : password, 𝑚 : plaintext
𝑖𝑣 : random(or given)
𝑠𝑎𝑙𝑡 ← 𝐸𝑛𝑐 𝑖𝑣,𝑋 (𝑝)
𝑠 𝑘 ← 𝐻 𝑝, 𝑠𝑎𝑙𝑡
𝑐 ← 𝐸𝑛𝑐(𝑖𝑣,𝑠 𝑘)(𝑚)
Output (𝑠𝑎𝑙𝑡, 𝑖𝑣, 𝑐)
10/20
バックドア
あり暗号器𝑚
(𝑠𝑎𝑙𝑡, 𝑐)
𝑝

11. • 𝑠𝑎𝑙𝑡/𝑖𝑣 を直接乱数にしない
Backdoor-resistant(BR) encryption
バックドア耐性のある暗号化
Input 𝑝 : password, 𝑚 : plaintext
𝑟1, 𝑟2 : random
𝑠𝑎𝑙𝑡 ← 𝐻(𝑝, 𝑟1||𝑚)
𝑖𝑣 ← 𝐻 𝑝, 𝑟2||𝑚
𝑠 𝑘 ← 𝐻 𝑝, 𝑠𝑎𝑙𝑡
𝑐 ← 𝐸𝑛𝑐 𝑖𝑣,𝑠 𝑘
(𝑟1| 𝑟2 |𝑚)
Output (𝑠𝑎𝑙𝑡, 𝑖𝑣, 𝑐)
復号
Input 𝑝 : password, (𝑠𝑎𝑙𝑡, 𝑖𝑣, 𝑐) : ciphertext
𝑠 𝑘 ← 𝐻 𝑝, 𝑠𝑎𝑙𝑡
(𝑟1| 𝑟2| 𝑚) ← 𝐷𝑒𝑐(𝑖𝑣,𝑠 𝑘)(𝑐)
Output 𝑚 if 𝑠𝑎𝑙𝑡 == 𝐻(𝑝, 𝑟1| 𝑚 and 𝑖𝑣 == 𝐻(𝑝, 𝑟2||𝑚)
11/20
検証

12. • バックドアつき暗号器は 𝑟1, 𝑟2を制御しようとする
• Eve が 𝑟1, 𝑟2 を固定化していたら
• Eveにとって 𝐻(𝑝, 𝑟𝑖||𝑚) から𝑝を求める難しさは
パスワードベースの鍵導出関数の難しさに依存
• 復号者は乱数𝑟1, 𝑟2がいつも同じだと気づく
• Eveは 𝑟1, 𝑟2 をたくさん用意しないといけない
• バックドアつき暗号器は予め準備された𝑟1, 𝑟2のどれかを利用
• Eveにとってもどの 𝑟1, 𝑟2 が使われたのか調べるのが難しい
提案手法の安全性
𝑠𝑎𝑙𝑡 ← 𝐻(𝑝, 𝑟1||𝑚)
𝑖𝑣 ← 𝐻 𝑝, 𝑟2||𝑚
12/20

13. • Password Based Key Derivation Function
• RFC2898でPBKDF2が規定されている
• 𝑠𝑎𝑙𝑡とhash stretchingを利用する
• 最近のPBKDF
• SHAシリーズは PBKDFとして使うには軽すぎる
• SHA-1 4.2 × 1010times/sec on 8x NVidia Titan X
• Argon2 by A. Biryukov, D. Dinu, D. Khovratovich
• Password Hashing Competition 2015で優勝
• https://password-hashing.net/
• maximizes resistance to GPU cracking attacks
PBKDF
13/20

14. • Hybrid encryption = KEM + DEM
• KEM ; Key Encapsulation Mechanism
• DEM ; Data Encapsulation Mechanism
• KEM
• 𝐾 𝑝𝑢𝑏, 𝐾 𝑝𝑟𝑣 ← 𝐾𝐸𝑀. 𝐺𝑒𝑛(1 𝑘), 𝑠 𝑘, 𝑐 𝑘 ← 𝐾𝐸𝑀. 𝐸𝑛𝑐 𝐾 𝑝𝑢𝑏 ,
𝑠 𝑘 = 𝐾𝐸𝑀. 𝐷𝑒𝑐 𝐾 𝑝𝑟𝑣, 𝑐 𝑘 .
• 例 : ElGamal暗号タイプ
• 𝐺 : cyclic gr., 𝑔 ∈ 𝐺, 𝑥 : private key, 𝑦 = 𝑔 𝑥 : public key
• 𝑚 : plaintext, 𝑟 : random
• ciphertext : (𝑚𝑦 𝑟, 𝑔 𝑟) ; Eveが 𝑔 𝑟を制御するのは難しそう
ハイブリッド暗号
KEM
𝑠 𝑘
DEM𝑚 𝑐
14/20

15. • 𝑠 𝑘 : secret key, 𝑚 : message
• 𝑐 = 𝐷𝐸𝑀. 𝐸𝑛𝑐 𝑠 𝑘, 𝑚 , 𝐷𝐸𝑀. 𝐷𝑒𝑐 𝑠 𝑘, 𝑐 = 𝑚
• 𝐷𝐸𝑀. 𝐸𝑛𝑐 は通常確率的多項式（PPT）アルゴリズム
• いくつかのDEMアルゴリズムはパスワード暗号化と同
様のバックドアに対して”弱い”構造を持っている
DEMについては
15/20

16. • IPsec ESP内のGCM（RFC4106）
• ESP ; Encapsulating Security Payload
• ESP payload data
• 𝑖𝑣 (8 bytes) + ciphertext
• Nonce format
• 𝑠𝑎𝑙𝑡 (4 bytes) + 𝑖𝑣 (8 bytes)
• 𝑠𝑎𝑙𝑡 : random
• 𝑖𝑣 : 一意性さえ満たせばIVの生成方法は暗号器まかせ
• Eveは 𝐸𝑛𝑐 𝑋 𝑠 𝑘 を𝑠𝑎𝑙𝑡や 𝑖𝑣の中に埋め込める
• SSHにおけるGCMの𝑖𝑣（RFC5647）
• 𝑖𝑣 = 𝐻𝑎𝑠ℎ 𝑠 𝑘 | ℎ 𝑐 ||𝑠𝑒𝑠𝑠𝑖𝑜𝑛_𝑖𝑑)
• ℎ : exchange hash, 𝑐 : ‘A’ or ‘B’
• 𝑖𝑣の作り方が決められている→バックドアを入れられない
AES-GCMに対するバックドア
16/20

17. • RFC4880 13.9で規定される
• 𝑠 𝑘 : secret key given by KEM
• 𝑖𝑣 : all zeros
• 平文 𝑚 の先頭に16+2バイトのデータを付与する
• 𝑟0, … , 𝑟15 ; random data. 𝑟14, 𝑟15 are repeated.
• バックドアを入れる
• 暗号器が 𝑟: = 𝐸𝑛𝑐 𝑠 𝑘
0 ⊕ 𝐸𝑛𝑐 𝑋(𝑠 𝑘) とすると
𝑐0 = 𝐸𝑛𝑐 𝑠 𝑘
0 ⊕ 𝐸𝑛𝑐 𝑠 𝑘
0 ⊕ 𝐸𝑛𝑐 𝑋 𝑠 𝑘 = 𝐸𝑛𝑐 𝑋(𝑠 𝑘).
• Eve can get 𝑠 𝑘 from 𝑐0 by 𝑋.
OpenPGP CFBモード
𝑟0 𝑟1 𝑟2 𝑟3 𝑟4 … 𝑟14 𝑟15 𝑟14 𝑟15 𝑚0 𝑚1 …
𝑐0 ≔ 𝐸𝑛𝑐 𝑠 𝑘
0 ⊕ [𝑟0 … 𝑟15]
𝐸𝑛𝑐
17/20

18. • (𝐸, 𝐷) : CPA安全な共通鍵暗号
• 𝑠 𝑘 : secret key, 𝑚 : plaintext
• c0 ≔ 𝐸 𝑠 𝑘, 𝑚 , 𝐷 𝑠 𝑘, 𝑐0 = 𝑚
• 次の性質を満たすPPTアルゴリズムとパラメータの組
(𝐸′, 𝐷′, 𝑋)が存在しないとき(𝐸, 𝐷)をBR安全という
• バックドア𝑋を用いて作った𝑐1: = 𝐸′
𝑋, 𝑠 𝑘, 𝑚 に対して
• 𝐷 𝑠 𝑘, 𝑐1 = 𝑚 ; 𝑐0 ≔ 𝐸(𝑠 𝑘, 𝑚)と同様に𝐷, 𝑠 𝑘で復号できる
• 𝐷′ 𝑋, 𝑐1 = 𝑚 ; 𝑋があれば 𝑠 𝑘を使わずに𝐷′で復号できる
• 𝑋がなければ𝑐0と𝑐1を区別できない :
• adversaryが𝑐𝑖が𝐸′で作られたと判定する確率を 𝑃𝑖とすると
𝐴𝑑𝑣 𝑘 ≔ 𝑃0 − 𝑃1 = 𝑛𝑒𝑔𝑙(𝑘) for security parameter 𝑘
BR（Backdoor-Resistant）安全の定義
18/20

19. • (𝐸0, 𝐷0) : 決定的ブロック暗号
• 𝐻 : target collision resistant hash function
• 𝑠 𝑘 : secret key, 𝑚 : plaintext
• Define (𝐸𝑛𝑐, 𝐷𝑒𝑐) algorithm such that
• 𝐸𝑛𝑐
• 𝑟 : random number
• 𝑖𝑣 ≔ 𝐻(𝑟||𝑠 𝑘)
• 𝐸𝑛𝑐 𝑠 𝑘, 𝑚 ∶= (𝑖𝑣, 𝐸0 𝑠 𝑘, 𝑖𝑣, 𝑟 𝑚
• 𝐷𝑒𝑐
• 𝑟||𝑚 ∶= 𝐷0(𝑠 𝑘, 𝑐)
• 𝐷𝑒𝑐 𝑠 𝑘, 𝑐 : =
𝑚 if 𝑖𝑣 = 𝐻(𝑟||𝑠 𝑘)
⊥ otherwise
• この構成はBR安全?
BR安全なDEM
19/20

20. • 既存のパスワード暗号化やDEMには暗号器にバックド
アが入れられても検出できない問題の指摘
• バックドア耐性のある(BR)安全性の定義
• BR安全な方式の構成
• 今後の課題
• 定義したBR安全はwell-definedなのか？
• “区別できない”ための条件が強すぎないか
• 構成方法がBR安全であることの証明
まとめ
20/20