![• 20バイトの内部状態（CV）を持つ
• ブロック（64バイト）毎にCVを更新する（round）
• それより前の情報は持たない
• 最後にCVを出力
SHA-1のアルゴリズム
update CV[5] by Block0
メッセージ
ブロック0
ブロック1
...
SHA-1
uint32_t CV[5] = {初期状態};
update CV[5] by Block1
CV[5]; // 最終出力
9 / 21](https://image.slidesharecdn.com/sha1-170225012949/85/Google-SHA-1-9-320.jpg)
GoogleのSHA-1のはなし
- 3. • ファイルサイズは同じ（422435バイト） • 違いは192バイト目からの256バイト中62バイトのみ PDFのどこが違う？ shatterd-1.pdf shatterd-2.pdf 違いはここだけ PDFのヘッダ PDFの中身 3 / 21
- 4. • 復習 • セキュリティビット • 理想のハッシュ関数 • Googleがやったこと • 詳細 概要 4 / 21
- 5. • その暗号技術がどのぐらい安全かを表す大雑把な指標 • nビットセキュリティは2 𝑛 回攻撃が必要 • 1回あたりの攻撃コストはあまり気にしない • 𝑂 2 𝑛 という表記 セキュリティビット 𝑛 直線 :𝑂(𝑛) 3次関数 : 𝑂(𝑛3 ) 指数関数 : 𝑂(2 𝑛) 𝑂(log 𝑛) 5 / 21
- 6. • 第二原像計算困難性（弱衝突耐性） • 𝑚1に対して𝐻 𝑚2 = 𝐻 𝑚1 となる𝑚2 ≠ 𝑚1が分からない • 同じじゃなくてもいいから何か一つ見つけるのが困難 • 𝑂(2 𝑛 )回トライ ; nビットセキュリティ • 衝突困難性（強衝突耐性） • 𝐻 𝑚1 = 𝐻(𝑚2)となる𝑚1 ≠ 𝑚2を見つけるのが困難 • 𝑂(2 𝑛/2 )回トライ ; 𝑛/2ビットセキュリティ • 第二原像を見つけるのは単なる衝突より2 𝑛/2 倍難しい 理想のnビット出力ハッシュ関数 ？ 𝑚1 ℎ 𝑚1 𝑚2 ℎ 6 / 21
- 7. • 160ビット出力 • （理想）衝突について80ビットセキュリティ • （現実）261程度の回数で衝突が見つかると言われている • 先週の勉強会（2017/2/13）では • 10年ぐらい前からもうすぐといいつつ見つかってない • Amazon EC2で1500万円ほどかければ見つかる（らしい） • 多分まだ誰も試していない • と言っていた SHA-1 7 / 21
- 8. • 衝突を実際に見つけた • identical-prefix collision attack • あるヘッダP（後述）に対して異なる𝑀1, 𝑀2を選び SHA-1(𝑃 𝑀1 =SHA-1(𝑃 𝑀2 となるものを見つけた • 𝑃|𝑀𝑖はデータの連結 • (𝑀1, 𝑀2)をnear-collision block pairという • 労力 • 263個のSHA-1を計算 • 6500年分のCPUと110年分のGPUリソース Googleがやったこと 8 / 21
- 9. • 20バイトの内部状態（CV）を持つ • ブロック（64バイト）毎にCVを更新する（round） • それより前の情報は持たない • 最後にCVを出力 SHA-1のアルゴリズム update CV[5] by Block0 メッセージ ブロック0 ブロック1 ... SHA-1 uint32_t CV[5] = {初期状態}; update CV[5] by Block1 CV[5]; // 最終出力 9 / 21
- 10. • CVは現在の状態からブロックによって次の状態に移る • 一度CVが同じになるとその後同じデータならずっと同じ • 先頭320バイトを切り出して確認 一度衝突すると shatterd-1.pdf shatterd-2.pdf ここで衝突したら 残りが同じだから ハッシュ値も同じ >dd bs=1 count=320 < shatterd-1.pdf|sha1sum f92d74e3874587aaf443d1db961d4e26dde13e9c >dd bs=1 count=320 < shatterd-2.pdf|sha1sum f92d74e3874587aaf443d1db961d4e26dde13e9c 10 / 21
- 11. • Pとして192バイトのPDFのヘッダ（+α）を採用 • 異なる𝑀1, 𝑀2でSHA-1(𝑃|𝑀1)=SHA-1(𝑃|𝑀2)を探す • すると任意のデータSについて SHA-1(𝑃|𝑀1|𝑆)=SHA-1(𝑃|𝑀2|𝑆) • SにPDFのデータを入れる • ハッシュ値は同じだが 𝑀1と𝑀2の選び方で 見え方が異なるPDF • 実際にはJPEGの構造を利用 • 詳細を最後に追加 同じハッシュ値を持つ異なる2個のPDF P=PDFのヘッダ+α 𝑀 = 𝑀1 or 𝑀2 S=「if (M == 𝑀1) { show 本物 } else{ show 偽物 } 」 11 / 21
- 12. • 勝手なものに対して同じになるようにするのは難しい • 同じもの（P）から出発し 少しだけ値を変えて 元に戻るようにする • roundが2回なので1ブロック（=64バイト）2個使う 𝑀1と𝑀2の探し方 12 / 21
- 13. • Marc Stevens , ‘’New collision attacks on SHA-1 based on optimal joint local-collision analysis,’’ EUROCRYPT 2013 • 2個のブロック𝑀1, 𝑀2をうまく選ぶ • 𝑀1 𝑖 で少しだけCVを変えて、𝑀2 𝑖 でその差を戻す • OSS実装が提供される ; Googleはこれをベースに利用 2個のブロックを使ってすり合わせる 𝐶𝑉0 𝑀1 (1) 𝐶𝑉1 1 𝐶𝑉1 2 𝑀1 (2) 𝑀2 (1) 𝑀2 (2) 𝐶𝑉2 完全一致 少し違う 13 / 21
- 14. • Pは192バイトなので3 round回したところがスタート 実際に見つかったパターン 𝐶𝑉0=4ea96269 7c876e26 74d107f0 fec67984 14f5bf45 7f 46 dc 93 a6 b6 7e 01 3b 02 9a aa 1d b2 56 0b 45 ca 67 d6 88 c7 f8 4b 8c 4c 79 1f e0 2b 3d f6 14 f8 6d b1 69 09 01 c5 6b 45 c1 53 0a fe df b7 60 38 e9 72 72 2f e7 ad 72 8f 0e 49 04 e0 46 c2 73 46 dc 91 66 b6 7e 11 8f 02 9a b6 21 b2 56 0f f9 ca 67 cc a8 c7 f8 5b a8 4c 79 03 0c 2b 3d e2 18 f8 6d b3 a9 09 01 d5 df 45 c1 4f 26 fe df b3 dc 38 e9 6a c2 2f e7 bd 72 8f 0e 45 bc e0 46 d2 8d64d617 ffed5352 ebc85915 5ec7eb34 f38a5a7b 8d64c821 ffed52e2 ebc85915 5ec7eb36 738a5a7b 30 57 0f e9 d4 13 98 ab e1 2e f5 bc 94 2b e3 35 42 a4 80 2d 98 b5 d7 0f 2a 33 2e c3 7f ac 35 14 e7 4d dc 0f 2c c1 a8 74 cd 0c 78 30 5a 21 56 64 61 30 97 89 60 6b d0 bf 3f 98 cd a8 04 46 29 a1 3c 57 0f eb 14 13 98 bb 55 2e f5 a0 a8 2b e3 31 fe a4 80 37 b8 b5 d7 1f 0e 33 2e df 93 ac 35 00 eb 4d dc 0d ec c1 a8 64 79 0c 78 2c 76 21 56 60 dd 30 97 91 d0 6b d0 af 3f 98 cd a4 bc 46 29 b1 𝐶𝑉2=1eacb25e d5970d10 f1736963 5771bc3a 17b48ac5 𝑀1 1 𝑀1 2 𝑀2 1 𝑀2 2 14 / 21
- 15. • near-collision block pairがあることを検知する技法 • Marc Stevens（2013） • 既存の衝突攻撃では探索効率をあげるために disturbance vector（DV）という特別なデータを選ぶ • 入力メッセージにDVが入っていないか走査する • 今回のGoogleが作ったペアはこれで検出できる • Flame（2012） • Windows Updateに対するなりすまし攻撃するマルウェア • MD5の衝突が使われた • この検知手法で検知できるが未知の攻撃手法が使われていた と思われる部分も見つかった counter-cryptanalysis 15 / 21
- 16. • あるPDFがあったときに同じハッシュをもつ別のPDF を作ったわけではない（第二原像は見つけてない） • 中身をみればおかしなデータが入っていることはわかる • PDFは可変長データで見えないデータをいろいろ入れられる • Gitはデータをサイズ込みで管理している • 攻撃対象リポジトリにそんなデータを入れるのは難しいはず • cf . http://marc.info/?l=git&m=148787047422954 Gitへの影響は？ 16 / 21
- 17. • JPEGのファイルフォーマット • SOIとEOIの間に複数のセグメントが入ってる • FF D8 ; イメージ開始（SOI） • FF D9 ; イメージ終了（EOI） • FF E0 ; アプリデータ開始セグメント（APP0） • コメントセグメント • FF FEに続く2バイトがコメントの長さ-2を表す • 例）FF FE 00 24 ; 0x24 = 36なので34バイトがコメント • コメントは好きなだけ並べられる JPEGの構造を使ったハック 17 / 21
- 18. • P = PDFのヘッダ+SOI+コメント+コメントの一部 作られたPDFの構造詳細 %PDF-1.3... FF D8 FF FE（SHA-1 is dead!!!!!） ... FF FE 01 P 46 dc ...M JPEGデータ + PDFフォーマットの残りS 73 PDF開始 Mの先頭バイトはコメントの長さの残り JPEG開始 コメントの始まり 18 / 21
- 19. • 𝑀1と𝑀2の最初のバイト（7Fと73）はコメントの一部 • google1.pdfはFF FE 01 73 ; 369バイトスキップ • google2.pdfはFF FE 01 7F ; 381バイトスキップ • 互いのデータをスキップさせる コメントの長さの違いで画像を変える FF FE 00 06 FF FE 27 F4 FF DA... FF FE 00 06 FF FE 27 F4 FF DA... ここに入ると赤がスキップ ここに入ると青がスキップ 19 / 21
- 20. • 2個の画像が互いのコメントに入っている • コメントを飛ばしながらJPEGを取り出すコード • https://github.com/herumi/misc/blob/master/extract-jpeg.py • python extract-jpeg.py google1.pdf a.jpg • python extract-jpeg.py google2.pdf b.jpg Sのイメージ 20 / 21 S
- 21. • The first collision for full SHA-1 • https://shattered.io/static/shattered.pdf • New collision attacks on SHA-1 based on optimal joint local-collision analysis • https://marc-stevens.nl/research/papers/EC13-S.pdf • Counter-cryptanalysis • https://eprint.iacr.org/2013/358 • 検知ツール • https://github.com/cr-marcstevens/sha1collisiondetection/ 参考 21 / 21