Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

バックドア耐性のあるパスワード暗号化の提案

1,517 views

Published on

SCIS2016発表資料

Published in: Technology
  • Be the first to comment

バックドア耐性のあるパスワード暗号化の提案

  1. 1. バックドア耐性のある (パスワード)暗号化の提案 SCIS2016 2016/1/21 光成滋生
  2. 2. • 背景と動機 • パスワード暗号化 • バックドアつきパスワード暗号化 • バックドア耐性のあるパスワード暗号化の提案 • その安全性 • ハイブリッド暗号 • OpenPGPやIPSecで考える • BR-secureの定義と構成 • まとめ • (注記)発表後にXagawaさんから先行研究の紹介 • https://eprint.iacr.org/2014/438 ; ありがとうございます 目次 2/20
  3. 3. • 様々なフォーマットで利用できる • ZIP • pdf • Microsoft Office file • 基本的な構造 • パスワード(𝑝)に𝑠𝑎𝑙𝑡を合わせて Hashを繰り返し適用する(stretch) • 𝑠𝑎𝑙𝑡 : rainbowテーブル攻撃への耐性 • stretch : Brute-force攻撃への耐性 パスワード暗号化 𝑝 𝐻𝑎𝑠ℎ 𝑠𝑎𝑙𝑡 𝑆 𝐾 𝑚 𝐸𝑛𝑐 𝑚 𝑖𝑣 𝑛 3/20
  4. 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. 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. 6. • 信頼できるフォーマットって何だろう? • 暗号化アルゴリズムはOpenで安全性は広く研究されている • しかし実装はOpenであるとは限らない • 大抵の暗号化モジュールはバイナリ提供 • ベンダーにとって • ソースは公開したくないが私は悪いことはしていないと信用 してほしい • ユーザにとって • バイナリ提供でも信用するしかない? 動機 6/20
  7. 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. • 暗号文のみを考える • 暗号時に外部と通信しない • 暗号器の中身は分からない(ブラックボックス) 考察対象 暗号器 𝑚 (𝑠𝑎𝑙𝑡, 𝑐) 𝑝 外部 8/20 バックドアがある?
  9. 9. • 𝐻 : パスワードベースの鍵導出関数(PBKDF) • 𝐸𝑛𝑐, 𝐷𝑒𝑐 : ブロック暗号の暗号化・復号関数 標準的なパスワード暗号化 Encryption Input 𝑝 : password, 𝑚 : plaintext 𝑖𝑣 : random(or given) 𝑠𝑎𝑙𝑡 : random 𝑠 𝑘 ← 𝐻 𝑝, 𝑠𝑎𝑙𝑡 𝑐 ← 𝐸𝑛𝑐(𝑖𝑣,𝑠 𝑘)(𝑚) Output (𝑠𝑎𝑙𝑡, 𝑖𝑣, 𝑐) Decryption Input 𝑝 : password, (𝑠𝑎𝑙𝑡, 𝑖𝑣, 𝑐) : ciphertext 𝑠 𝑘 ← 𝐻 𝑝, 𝑠𝑎𝑙𝑡 𝑚 ← 𝐷𝑒𝑐 𝑖𝑣,𝑠 𝑘 (𝑐) Output 𝑚 9/20
  10. 10. • 攻撃者 Eve は秘密鍵 𝑋 を持っている • 𝑋 は暗号器の中に埋め込まれている • 𝑠𝑎𝑙𝑡は𝑝を𝑋で暗号化したもの ( 𝑝 ∼ |𝑠𝑎𝑙𝑡|を仮定). • Eveは𝑋を使って𝑠𝑎𝑙𝑡から 𝑝を復号し𝑠 𝑘を得られる • 𝑋を知らない人にとって𝑠𝑎𝑙𝑡は普通の乱数と区別できない バックドアつき暗号化 Backdoor Encryption Input 𝑝 : password, 𝑚 : plaintext 𝑖𝑣 : random(or given) 𝑠𝑎𝑙𝑡 ← 𝐸𝑛𝑐 𝑖𝑣,𝑋 (𝑝) 𝑠 𝑘 ← 𝐻 𝑝, 𝑠𝑎𝑙𝑡 𝑐 ← 𝐸𝑛𝑐(𝑖𝑣,𝑠 𝑘)(𝑚) Output (𝑠𝑎𝑙𝑡, 𝑖𝑣, 𝑐) 10/20 バックドア あり暗号器𝑚 (𝑠𝑎𝑙𝑡, 𝑐) 𝑝
  11. 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. 12. • バックドアつき暗号器は 𝑟1, 𝑟2を制御しようとする • Eve が 𝑟1, 𝑟2 を固定化していたら • Eveにとって 𝐻(𝑝, 𝑟𝑖||𝑚) から𝑝を求める難しさは パスワードベースの鍵導出関数の難しさに依存 • 復号者は乱数𝑟1, 𝑟2がいつも同じだと気づく • Eveは 𝑟1, 𝑟2 をたくさん用意しないといけない • バックドアつき暗号器は予め準備された𝑟1, 𝑟2のどれかを利用 • Eveにとってもどの 𝑟1, 𝑟2 が使われたのか調べるのが難しい 提案手法の安全性 𝑠𝑎𝑙𝑡 ← 𝐻(𝑝, 𝑟1||𝑚) 𝑖𝑣 ← 𝐻 𝑝, 𝑟2||𝑚 12/20
  13. 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. 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. 15. • 𝑠 𝑘 : secret key, 𝑚 : message • 𝑐 = 𝐷𝐸𝑀. 𝐸𝑛𝑐 𝑠 𝑘, 𝑚 , 𝐷𝐸𝑀. 𝐷𝑒𝑐 𝑠 𝑘, 𝑐 = 𝑚 • 𝐷𝐸𝑀. 𝐸𝑛𝑐 は通常確率的多項式(PPT)アルゴリズム • いくつかのDEMアルゴリズムはパスワード暗号化と同 様のバックドアに対して”弱い”構造を持っている DEMについては 15/20
  16. 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. 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. 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. 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. 20. • 既存のパスワード暗号化やDEMには暗号器にバックド アが入れられても検出できない問題の指摘 • バックドア耐性のある(BR)安全性の定義 • BR安全な方式の構成 • 今後の課題 • 定義したBR安全はwell-definedなのか? • “区別できない”ための条件が強すぎないか • 構成方法がBR安全であることの証明 まとめ 20/20

×