暗号技術入門

20181130 adishエンジニア勉強会でお話ししたスライドです

Transcript

1. 暗号技術入門 2018.11.30 坪井有花 @__kyrieleison__ adishエンジニア勉強会
2. - 大学では暗号技術を専門とする研究室に所属していま した(研究テーマは違う) - 基本情報、応用情報持ってます(セスペは落ちた) - ブロックチェーン技術にドハマリしてました 坪井有花 @__kyrieleison__
3. 目的 - それぞれの暗号技術で何を防げるのかを知る - 業務でたまに登場する暗号技術関連のワードを自分でググって理解できる - 業務でたまにOpenSSLとか触らなきゃいけなくなっても「よくわからないけどまあ鍵生成・ 暗号化・復号・署名とかできるはずだよね」という想像ができる 本発表を通じて、こんな目的が達成できたらよいなと考えております よろしくお願いいたします
4. 今日の内容 - 共通鍵暗号・公開鍵暗号・ハイブリッド暗号 - 一方向性ハッシュ関数 - メッセージ認証コード - デジタル署名 - SSL/TLS 今日の内容はざっくりこんな感じです 少し足早に進めるかも知れませんが、気にせずいつでも質問してください
5. アリスとボブ 情報の送信者と受信者がメッセージを通信する様子を、以下のような図で解説する 本発表中は、送信者をアリス、受信者をボブと呼ぶ アリス （送信者） ボブ （受信者） メッセージ
6. セキュリティ4大脅威 - 盗聴 - ボブ以外にメッセージが漏れる - 改ざん - メッセージが書き換えられる - なりすまし - アリスのふりをする - 否認 - アリスが後から「送っていない」と言う
7. 暗号技術の道具箱 - 暗号: 鍵を持つ人以外からメッセージを秘匿する技術 - 一方向性ハッシュ関数: メッセージを要約する技術、変化を検出する技術 - メッセージ認証コード: メッセージが正しいものなのか、誰から送られたものか確認する技術 - デジタル署名: メッセージが正しいものか、誰から送られたものか確認する技術 - 疑似乱数生成器: 予測しにくい鍵を作れる乱数を作る技術
8. セキュリティ4大脅威に対する防衛 - 盗聴 → 暗号で守る!!! - ボブ以外にメッセージが漏れる - 改ざん → 一方向性ハッシュ関数・メッセージ認証コード・デジタル署名で守る!!! - メッセージが書き換えられる - なりすまし → メッセージ認証コード・デジタル署名で守る!!! - アリスのふりをする - 否認 → デジタル署名で守る!!! - アリスが後から「送っていない」と言う
9. 暗号 鍵を持つ人以外からメッセージを秘匿する技術 メッセージ(平文)の代わりに、メッセージを暗号化したもの(暗号文)を送る 盗聴されても暗号文からはもとの平文に戻せない 暗号文 平文 暗号文 平文 暗号文 アリス （送信者） ボブ （受信者） 暗号化 復号 暗号文を盗聴しても もとの平文が分からない 暗号化鍵 復号鍵 暗号鍵を持っている アリスは 平文を暗号化する 復号鍵を持っている ボブだけが もとの平文に戻せる
10. 共通鍵暗号 暗号化鍵と復号鍵に同じ鍵を使用する方式 事前に鍵を生成し、アリスとボブで共有して保管しておく 暗号化も復号もその鍵を使う 暗号文 平文 暗号文 平文 暗号文 アリス （送信者） ボブ （受信者） 暗号化 復号 共通鍵 共通鍵 事前に鍵を生成・共有 厳重に保管 厳重に保管
11. 共通鍵暗号のメリットとデメリットは何でしょう？ Question
12. 共通鍵暗号のメリットとデメリット メリット: 暗号化と復号の処理が高速 デメリット: 事前に安全な経路で鍵を共有するのが難しい(鍵配送問題) 管理する鍵の数が多い 暗号文 平文 暗号文 平文 暗号文 アリス （送信者） ボブ （受信者） 暗号化 復号 共通鍵 共通鍵 盗聴されたら鍵が盗まれてしまう N人いるグループで 通信しあうには N-1個の鍵を管理 処理が高速 事前に鍵を生成・共有 N人いるグループで 通信しあうには N-1個の鍵を管理
13. 公開鍵暗号 暗号化鍵と復号鍵に違う鍵を使用する方式 2つの鍵はペアになっていて、片方で暗号化したものは片方で復号できる 復号に使う鍵を秘密に管理して(秘密鍵)、暗号化に使う鍵は公開する(公開鍵) 暗号文 平文 暗号文 平文 暗号文 アリス （送信者） ボブ （受信者） 暗号化 復号 ボブの公開鍵 ボブの秘密鍵 誰もが使えるように 公開された ボブ専用の暗号化鍵 ボブが 厳重に保管する ボブ専用の復号鍵 アリスはボブの公開鍵を取得
14. では、公開鍵暗号のメリットとデメリットは？ (共通鍵暗号と比較して) Question
15. 公開鍵暗号のメリットとデメリット メリット: 鍵は公開できるので鍵配送問題が解決されている 1ペアの鍵で複数の相手からの受信が可能 デメリット: 暗号化と復号の処理に時間がかかる 暗号文 平文 暗号文 平文 暗号文 アリス （送信者） ボブ （受信者） 暗号化 復号 ボブの公開鍵 ボブの秘密鍵 アリスはボブの公開鍵を取得 鍵配送問題クリア N-1個の鍵を保管 でも厳重管理する 必要はない 処理に時間がかかる 自分の秘密鍵だけ 厳重管理
16. ハイブリッド暗号 共通鍵暗号と公開鍵暗号のいいとこどりをした方式 暗号化と復号は処理の高速な共通鍵暗号で行う 共通鍵暗号の鍵を公開鍵暗号で暗号化して共有する 暗号文 平文 暗号文 平文 暗号文 アリス ボブ 暗号化 復号 暗号化 共通鍵 共通鍵 ボブの公開鍵 暗号化した共通鍵 暗号化した共通鍵 復号 ボブの秘密鍵 暗号化した共通鍵 ※多くの場合、ハイブリッド暗号で使う共通鍵は 　使い捨てなのでセッション鍵とも呼ばれる
17. 暗号まとめ 共通鍵暗号 公開鍵暗号 ハイブリッド暗号 特徴 - 処理が高速 - 鍵の配送問題あり - 管理する鍵が多い - 処理が低速 - 鍵の配送問題なし - 管理する鍵は少ない - 処理が高速 - 鍵の配送問題なし - 管理する鍵は少ない 代表例 AES, DES RSA, ECC PGP, S/MIME, SSL/TLS
18. 小話: どの暗号アルゴリズムを採用すべきか 考案された当時には十分な安全性を持っていた暗号アルゴリズムも 新しい攻撃手法の発見やコンピュータの性能向上によって、安全性が低下する(=危殆化) そのため、公的機関では暗号技術の標準規格を作成している - NIST FIPS 140-2 "Security Requirements for Cryptographic Modules" - 2001年に公開。暗号モジュールのセキュリティ要件を規定したもの - CRYPTREC 暗号リスト - 2013年に公開。日本国内における電子政府で推奨される暗号技術リスト - NIST SP 800-131A Rev. 1 "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths" - 2015年に公開。より長い鍵長とより強力な暗号アルゴリズムへの移行を目指した、暗号ア ルゴリズムの選定等に関する実践的なガイドライン
19. 小話: NIST SP800シリーズとFIPS 米国国立標準技術研究所(NIST)が発行する代表的な公式文書 いずれも米国政府向けだが参考になる FIPSは標準規格の詳細な基準等が記述されている物が多く、 SP800シリーズはガイドライン等の実践的なものが多い
20. メッセージを要約する技術、変化を検出する技術 メッセージが1bitでも違うとまったく違うハッシュ値が出力されるので ハッシュ値同士を比較することで、メッセージの改ざんを検知できる 一方向性ハッシュ関数 ハッシュ値 メッセージ ハッシュ値 メッセージ ハッシュ値 アリス （送信者） ボブ （受信者） 一方向性 ハッシュ関数 一方向性 ハッシュ関数 比較 一致しなければ 改ざんされている!!!
21. 任意長のメッセージから固定長のハッシュ値を出力する 与えられた入力が同じなら出力も同じだが、1bitでも違えば出力も全く異なる ハッシュ値から元のメッセージを得ることが困難(一方向性) 代表例はMD5, SHA-1, SHA-2, SHA-3 こんにちは、今日はいい天気ですね 入力（メッセージ） 出力（ハッシュ値） こんにちは、今朝はいい天気ですね こんにちは、今日はいい天気ですね 天気 d2fa74e8e5712a8df65fad169b4655b8 d2fa74e8e5712a8df65fad169b4655b8 1b7dd2d7519ead2d27c13137fb9b2615 e082c9d81567377667df4568a3c73b72 一方向性 ハッシュ関数 一方向性ハッシュ関数
22. HTTPにおける認証方式の一つ ユーザ名とパスワードをBase64エンコードして送信するBasic認証に対して、 ユーザ名とパスワードのMD5ハッシュを送信することで盗聴や改ざんを防ぐ 小話: Digest認証 ハッシュ値 ユーザ名,パスワード ハッシュ値 ユーザ名,パスワード ハッシュ値 クライアント サーバ MD5 MD5 比較 一致しなければ ユーザ名かパスワードが 違う ハッシュ値を盗聴しても もとの値が分からない
23. メッセージ認証コード メッセージが正しいものなのか、誰から送られたものか確認する技術 任意長のメッセージと共通鍵をもとに固定長のMAC値が出力されるので MAC値同士を比較して改ざん検知となりすまし検知が行える 代表例はHMAC ハッシュ値 メッセージ MAC値 メッセージ MAC値 アリス （送信者） ボブ （受信者） メッセージ 認証コード メッセージ 認証コード 比較 メッセージ 一致しなければ 改ざんされている!! またはアリスじゃない!! 共通鍵 共通鍵
24. メッセージ認証コードにおける問題は？ Question
25. 鍵配送問題を解決しなければならない 第三者に証明することができない(ボブだって同じMAC値を作れる) アリスは否認できる(ボブだって同じMAC値を作れるし、ボブが鍵を盗まれたのかも) →デジタル署名で解決 ハッシュ値 メッセージ MAC値 メッセージ MAC値 アリス （送信者） ボブ （受信者） メッセージ 認証コード メッセージ 認証コード 比較 メッセージ メッセージ認証コードで解決できない問題 共通鍵 共通鍵
26. メッセージが正しいものなのか、誰から送られたものなのか確認する技術 公開鍵暗号を使い、秘密鍵でメッセージを暗号化したものを署名として扱う 署名は公開鍵で復号できることを以て検証する デジタル署名 メッセージ 署名 メッセージ 署名 アリス （送信者） ボブ （受信者） 暗号化 復号 比較 メッセージ 署名 アリスの秘密鍵 アリスの公開鍵 一致しなければ 改ざんされている!! またはアリスじゃない!!
27. デジタル署名における問題は？ Question
28. 署名を検証する際に使う公開鍵は、本物のアリスのものでなければならない →PKIで解決 デジタル署名で解決できない問題 メッセージ 署名 メッセージ 署名 アリス （送信者） ボブ （受信者） 暗号化 復号 比較 メッセージ 署名 アリスの秘密鍵 アリスの公開鍵
29. 公開鍵の持ち主が間違いなく本人であると確認するための基盤 信頼できる認証局(CA)に、公開鍵の持ち主を確認して証明書を発行してもらう 認証局が署名した証明書であれば、その公開鍵は本物の持ち主のものと分かる PKI アリス (送信者) ボブ (受信者) 認証局 暗号文 ボブの公開鍵 ボブの証明書 ボブの公開鍵 認証局の署名 認証局の公開鍵で 署名検証できれば ボブの公開鍵は正しい! 認証局は ボブかどうかを確かめ 証明書を作る
30. 認証局同士の信頼関係のモデルを 信頼モデルという 最も代表的なものは階層モデル 上位のCAが下位のCAの証明書を発行し、 信頼のチェーンを構成する 最も上位のCAはルートCAといい、 トラストアンカーともいう ルートCAの証明書は自身で発行する (自己署名) 署名検証の際は、ルートCAに向かって 信頼のチェーンを順に検証していく PKIの信頼モデル ルート CA 中間 CA1 中間 CA2 中間 CA3 利用者 利用者 利用者 利用者 ルート証明書 ルートCAの公開鍵 ルートCAの署名 中間CA1の 証明書 中間CA1の 公開鍵 ルートCAの署名 中間CA3の 証明書 中間CA3の 公開鍵 中間CA1の署名 信頼の起点 トラストアンカー 中間CA2の 証明書 中間CA2の 公開鍵 ルートCAの署名
31. これで道具がだいたい揃いました 暗号通信プロトコル SSL/TLS は これまで説明したような暗号技術を組み合わせています どの暗号技術を、どのように使っていると思いますか？ Question keyword: 共通鍵暗号、公開鍵暗号、一方向性ハッシュ関数、メッセージ認証コード、デジタル署名 盗聴、改ざん、なりすまし、否認
32. 世界で最も多く使われている暗号通信プロトコル 他のアプリケーション層プロトコル(HTTP, SMTP等)と組み合わせることができる SSL/TLS アプリケーション層 アリス （送信者） SSL/TLS HTTP トランスポート層 インターネット層 リンク層 アプリケーション層 ボブ （受信者） HTTP SSL/TLS トランスポート層 インターネット層 リンク層 暗号化 復号 通信路
33. - データの盗聴防止: 共通鍵暗号を使った暗号化 - 鍵交換: 公開鍵暗号を使った暗号化 (またはDiffie Hellman鍵交換) - なりすまし防止: PKIとデジタル署名を使ったサーバの認証 - 否認防止: PKIとデジタル署名を使ったクライアントの認証 - データの改ざん検知: データのハッシュ値に対するメッセージ認証コード SSL/TLSで使われている暗号技術
34. TLSレコードプロトコルとTLSハンドシェイクプロトコルという 2つのプロトコルで構成される SSL/TLSで使われている暗号技術 SSL/TLS TLSハンドシェイクプロトコル 暗号スイートの合意と通信相手の認証、鍵交換の取り決め TLSレコードプロトコル データの暗号化と認証, 改ざん検知の取り決め ハンドシェイク プロトコル 暗号仕様変更 プロトコル アラートプロトコル アプリケーションデータ プロトコル - 使用する暗号スイートの合意 - PKIとデジタル署名を使った認証 - 共通鍵の生成 - 公開鍵暗号またはDiffie-Hellman 鍵交換を使った鍵交換 - 共通鍵暗号を使った暗号化と復号 - メッセージ認証コードを使ったパケット毎 の認証と改ざん検知
35. TLSハンドシェイクプロトコル クライアント サーバ 認証局 Server:「私の証明書を作ってください、公開鍵はこれです」 サーバの証明書を 生成・署名 https://… でサーバにアクセス CA:「あなたの証明書はこれです」 Client:「私が使える暗号スイートのリストはこれです」 Server:「ではこの暗号スイートで通信しましょう」 Server:「私のサーバ証明書はこれです」 サーバの共通鍵と公開鍵を生成 証明書を設置 Client:「認証局の公開鍵をください」 CA:「はい、認証局の公開鍵はこれです」 認証局の公開鍵で サーバ証明書の署名検証 サーバ証明書の公開鍵で 共通鍵を暗号化 Client:「これが暗号化した共通鍵です」 暗号化された共通鍵を サーバの秘密鍵を使い復号 Server:「OK, それでは暗号通信をはじめましょう」 ハンドシェイクが終わったら TLSレコードプロトコルによる通信が 行えるようになる!
36. TLSレコードプロトコル クライアント サーバ ハンドシェイクで やりとりした共通鍵 ハンドシェイクで やりとりした共通鍵 メッセージ 圧縮文 ハッシュ値 一方向性ハッシュ関数 MAC値 メッセージ認証コード 圧縮 暗号文 暗号化 Server:「暗号化したデータはこれです」
37. $ openssl cryper -v 小話: どの暗号スイートを利用するか ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 … 暗号スイート名 プロトコル 鍵交換 アルゴリズム 認証 アルゴリズム 暗号アルゴリズム MACアルゴリズム
38. https://www.ssllabs.com/ssltest/ 小話: Webサーバの暗号スイート設定は安全かどうか
39. 小話: Webサーバの暗号スイート設定のテンプレート https://mozilla.github.io/server-side-tls/ ssl-config-generator/
40. 暗号アルゴリズムはどのような仕組みになっているのか？ DESとAESのアルゴリズムを見てみよう おまけ
41. DES (Data Encryption Standard) 1977年にNBS(現NIST)によって標準化された共通鍵暗号アルゴリズム IBMのLuciferというアルゴリズムがもととなった 広く採用されていたが1994年に解読が成功、その後も次々と解読が成功する 2000年にAESが標準化されるまでは、 DESを3回かけるTriple DESの使用が推奨された 現在では総当たり攻撃で解読できるほどに安全性が低下(危殆化)しているため 使用すべきではない 鍵長は56bit ブロック長は64bit
42. DES (Data Encryption Standard) 1. 平文を64bitごとのブロックに分割する 64bitの平文 64bitの暗号文 左の32bit 右の32bit 関数f サブ鍵1 XOR 暗号化された左の32bit 右の32bit 2. 左右で32bitずつに分割する 3. あらかじめ鍵から16個のサブ鍵を生成している。 1個目のサブ鍵と右32bitを関数fに入力し、 その出力と左32bitとの排他的論理和を取る 4. 左右を入れ替える 5. 2-4が1ラウンド。これを16ラウンド繰り返す
 (NラウンドごとにN個目のサブ鍵が使われる) 6. 最終的な左右を合わせた64bitが暗号文 部分を16ラウンド繰り返す 右の32bit 暗号化された左の32bit
43. DES (Data Encryption Standard) 平文ブロックを半分ずつかき混ぜて暗号化する ではどのように復号するか 同じサブ鍵を与えてラウンドを繰り返すと 関数fがどんな関数であっても元に戻る
44. DES (Data Encryption Standard) 1. 暗号文を64bitごとのブロックに分割する 64bitの暗号文 64bitの平文 16ラウンド目で暗号化された左の32bit 右の32bit 関数f サブ鍵16 XOR 左の32bit 右の32bit 2. 左右で32bitずつに分割すると、左は16ラウ ンドで暗号化された32bitのはずである 3. 同じ鍵からは16個の同じサブ鍵を生成できる。 16個目のサブ鍵と右32bitを関数fに入力し、 その出力と左32bitとの排他的論理和を取る。 すると、元の左の32bitが取れる!!!
 4. 右は15ラウンドで暗号化された32bitのはずな ので、左右を入れ替える 5. 2-4が1ラウンド。これを16ラウンド繰り返す
 (Nラウンドごとに16-N個目のサブ鍵が使われる) 6. 最終的な左右を合わせた64bitが平文 部分を16ラウンド繰り返す 15ラウンド目で暗号化された右の32bit 左の32bit
45. Feistal構造 こうした同じラウンドを繰り返す構造は DESを開発したホルスト・ファイステルの名をとってFeistal構造と呼ばれる 1. ラウンド数をいくら増やしても復号できる →TripleDESのような応用が可能 2. 関数fにどんな関数を使っても復号できる →新たな暗号アルゴリズムを考えるときは、複雑な関数fだけを考えればよい 3. 暗号化と復号が同じ構造で実現できる →実装が少なくなるので実装コストが低い、コードのサイズが少なく済む
46. AES (Advanced Encryption Standard) 1997年にNISTが新たな標準となる共通鍵暗号アルゴリズムを公募 最終候補として残った5つの中で 2000年にRijndael(ラインダール)というアルゴリズムが採用された 鍵長は128bit~256bit ブロック長は128bit(16bytes)
47. AES (Advanced Encryption Standard) 16bytesの平文 Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes Sub Bytes MixColumns MixColumns MixColumns MixColumns ラウンド鍵とのXOR 16bytesの暗号文 1. 暗号文を16bytesごとのブロックに分割する 2. SubBytes: 1bytesごとの値(0~255)をイン デックスとした換字表Sから得た値に変換する 3. ShiftRows: SubBytesの値を1bytesごとに 混ぜて、4bytesのまとまりにする 4. MixColumns: 4bytesのまとまりにビット演算 をかけて、別の4bytesに変換する 5. AddRoundKey: 鍵から生成したラウンド鍵と の排他的論理和を取る 部分を10~14ラウンド繰り返す 6. 2-5が1ラウンド。これを10-14回繰り返す 7. 最終的な16bytesが暗号文
48. SPN構造 換字と転置を組み合わせた構造のため Substitution(換字)-Permutation(転置) Network構造と名付けられた 1ブロックを半分ずつかき混ぜるFeistal構造と比べると 一度にブロック全体をかき混ぜているので効率がよく、ラウンド数を減らすことができる また、SubBytesはbitesごと、ShiftRowsは行ごと、MixColumnsでは列ごとに 並列処理ができる 換字と転置を逆変換することで復号を実現するため Feistal構造と違い、同じ構造で暗号化と復号を行うことはできない
49. 小話: ブロック暗号とストリーム暗号 平文をブロックごとに暗号化するのがブロック暗号 平文を順次暗号化していくのがストリーム暗号 ストリーム暗号では、1bit/8bit/32bitなどの単位で暗号化や復号が行われる ストリーム暗号専用のアルゴリズムもあるが ブロック暗号でも、暗号モードのOFB, CFB, CTRを利用すると 1bitずつの暗号化が実現できるのでストリーム暗号として利用できる
50. 参考図書 暗号技術入門 秘密の国のアリス 第3版 結城浩