Download as PDF, PPTX
暗号技術入門
- 1.
- 2.
- 3.
- 4. 情報セキュリティ ▌情報を正しく安全に扱うための考え方 機密性 許可された人だけがその情報を見られるようにすること 完全性 情報が壊されないようにすること 可用性 アクセスしたいときにアクセスできるようにすること 4/56
- 5. SSL/TLS ▌暗号通信プロトコル HTTPなどのプロトコルを安全に送受信可能にする仕組み 暗号化、改竄（かいざん）検知、認証などをサポート ▌現在TLS1.2が最新 TLS1.3が策定中（ドラフトはほぼ確定） 5/56
- 6. ▌ある部分が動かないとシステム全体が止まる箇所 データは複数のディスクにコピー 一つが壊れても大丈夫 ▌暗号アルゴリズムは冗長化しにくい 単一障害点（SPOF: Single Point of Failure） PKI デジタル署名 ハッシュ関数 公開鍵暗号 乱数 共通鍵暗号 実装 安全な通信 一つでも破られるとアウト プロトコル 運用 複製 6/56
- 7. 暗号 ▌（狭義）第三者に内容を知られないように変換する手法 ▌他に （改竄検知）内容が第三者に書き換えられたことを知る （認証）相手の身元を確認する ... ▌暗号（技術） 、暗号プロトコルともいう ▌情報セキュリティの土台となる技術の一つ 7/56
- 8.
- 9. 共通鍵暗号 ▌平文（ひらぶん） やりとりしたい内容 ▌暗号化 私とあなた（以下、慣例によりAliceとBob）のやりとりを 第三者が見ても分からないようにする手順（アルゴリズム） ▌秘密鍵 暗号化に使う二人だけの秘密の情報 ▌暗号文 暗号化された平文 ▌復号 秘密鍵を使って暗号文からもとの平文を復元すること 9/56
- 10. 古典的な方法 ▌アルファベットをずらす暗号 秘密鍵 =ずらす文字数 すぐ破られてしまう 10/56
- 11. 情報理論的に安全な暗号 ▌平文の種類 平文の大きさが𝑛ビットなら2 𝑛通り ▌2𝑛 通り試せばどれかは当たる でたらめに答えて一度で当たる確率は1/2 𝑛 ▌このとき情報理論的に安全という 2 𝑛 通り調べなくても分かる暗号は情報理論的安全ではない 11/56
- 12. 計算量 ▌ある手順に必要なざっくりとした計算回数 𝑛が大きくなったときの傾向を見たい ▌𝑂(𝑛)という記法がよく使われる 対数時間で増える𝑂(log 𝑛) 多項式時間で増える𝑂(𝑛2) 指数関数時間で増える𝑂(2 𝑛) ▌𝑛 = 100のとき log 𝑛 : 𝑛2: 2 𝑛 = 4.6: 10000: 1267650600228229401496703205376 𝑛2 log( 𝑛) 2 𝑛 12/56
- 13. 計算量的安全性 ▌情報理論的安全ではないが、暗号の攻撃に必要な計算量が 秘密鍵サイズ𝑛に関する𝑂(𝑛 𝑐)より大きいもの（𝑐は定数） その評価は経験的なものが多い 現在知られている最も高速な攻撃アルゴリズム つまりそれが変われば暗号の安全性の評価も変わる 13/56
- 14. 暗号の危殆化（きたいか） ▌安全とされていた暗号が攻撃の研究やコンピュータの性能向上によ り安全でなくなること 例 :MD5, SHA-1, RC4, RSA1024は禁止 ▌CRYPTRECでは電子政府で推奨される暗号技術の評価を行う http://www.cryptrec.go.jp/list.html 14/56
- 15. ブロック暗号 ▌秘密鍵が小さい固定長のサイズ ▌平文をたとえば128ビットのブロックに分けて暗号化する方式 メッセージ b1 b2 b3b4 b5 b6 ... ブロックに分割 c1 c2 c3 c4 c5 c6 ... ブロック単位で暗号化 15/56
- 16.
- 17.
- 18. 暗号に望まれる性質 ▌一方向性 暗号文から元の平文が分かってはいけない ▌頑強性 暗号文から（元の平文が分からなくても）いじられてはいけない ▌強秘匿性 暗号文から元の平文の情報が少しももれない 18/56
- 19. 確率的アルゴリズム ▌教科書的RSA暗号は乱数を使っていない 𝐸𝑛𝑐 𝑚= 𝑚 𝑒mod𝑛 同じ平文はいつも同じ暗号文になる 暗号文がyesかnoのどちらかと分かっていたらばれてしまう 暗号アルゴリズムは確率的（毎回異なる暗号文）である必要 19/56
- 20. 頑強性 ▌RSA暗号は暗号文を2乗すると平文の2乗になる 𝐸𝑛𝑐 𝑚= 𝑚 𝑒mod𝑛→ 𝐸𝑛𝑐 𝑚2 = 𝑚2𝑒mod𝑛 100円を借りたつもりがいつの間にか10000円！ ▌改竄されないような暗号が望ましい 20/56
- 21. 強秘匿性 ▌ある極秘指令の返事を盗聴してがんばって解読 「私○、 ○の提案に賛○で○。」 ○は解読できなかった部分。 ▌しかしこれは多分「賛成」 理想は部分的にも解読できないこと ▌強秘匿性 = 元の平文の情報が1ビットももれない性質 仮に平文が「0」と「1」のどちらかであると知っていても 暗号文を見てどちらか分からない（当たる確率が1/2） 21/56
- 22. 乱数 ▌直感的には「再現性のないでたらめな数の列」 定義はなかなか難しい ▌暗号論的擬似乱数 「どれだけ過去の数の列を見ても次の1ビットを当てられない」 あの店はよく当たる（わけはない） 当たる確率1/2 22/56
- 23. 暗号にとって乱数はとても大事 ▌安全な暗号アルゴリズムを使っても秘密鍵を推測できるならアウト 秘密鍵の作り方がお粗末（1996年Netscape Navigator） 素数が9種類しかない（2012年IBM Remote Server card） デフォルト鍵を使ってるサーバ（2012年で5%?） http://www.jnsa.org/seminar/pki-day/2012/data/PM02_suga.pdf 23/56
- 24. 公開鍵暗号の動機 ▌安全な共通鍵暗号を手に入れた ▌秘密鍵をどうやって相手と共有しよう 共通鍵暗号だけでは解決できない ▌公開鍵暗号 暗号化に使う秘密鍵と 復号に使う公開鍵の2種類を使う暗号 秘密鍵は誰にも見せてはいけない 公開鍵は誰に見せてもよい 24/56
- 25. 公開鍵暗号 ▌暗号化に使う公開鍵と復号に使う秘密鍵の2種類を使う暗号 秘密鍵は誰にも見せてはいけない 公開鍵は誰に見せてもよいAlice Bob が公開鍵𝐾𝐴 が公開鍵𝐾 𝐵 が秘密鍵𝐾𝐴 ′ が秘密鍵𝐾 𝐵 ′ 25/56
- 26.
- 27. 盗聴されても大丈夫 ▌公開鍵𝐾 𝑝𝑢𝑏 から秘密鍵𝐾 𝑝𝑟𝑣 を求められないため他人は盗聴できない AliceBob s 公開鍵𝐾 𝐵 𝑝𝑢𝑏 秘密鍵𝐾 𝐵 𝑝𝑟𝑣 s ？ 𝐸𝑛𝑐 𝐾 𝐵 𝑝𝑢𝑏(𝑠) 27/56
- 28. 改竄（かいざん）されると辛い ▌BobがAliceに公開鍵𝐾 𝐵 𝑝𝑢𝑏 を渡すときに第三者が介入して𝐾′ 𝐵 𝑝𝑢𝑏 を渡す ▌MITM（Man InThe Middle）中間者攻撃 ▌改竄を検知したい Alice Bob s 公開鍵𝐾 𝐵 𝑝𝑢𝑏 𝐸𝑛𝑐 𝐾 𝐵 ′𝑝𝑢𝑏(𝑠) X 𝐾′ 𝐵 𝑝𝑢𝑏 𝑠をゲット 28/56
- 29.
- 30. 暗号用ハッシュ関数𝑯に望まれる性質 ▌𝐻(𝑚)から𝑚を復元できてはいけない ▌より詳しくは ℎに対して𝐻 𝑚= ℎとなる𝑚が分からない 𝑚1に対して𝐻 𝑚1 = 𝐻 𝑚2 なる𝑚2 ≠ 𝑚1が分からない 𝐻 𝑚1 = 𝐻 𝑚2 となる 𝑚1, 𝑚2 , 𝑚1 ≠ 𝑚2が分からない GoogleのSHA-1のはなし https://www.slideshare.net/herumi/googlesha1 30/56
- 31. ハッシュ関数の安全性 ▌サーバにユーザのパスワードを保存するとき A. うちはSHA-1(pass)を保存している B. だめだよSHA-1は廃止だよ。うちはSHA-2(pass)だよ ▌そのサーバのデータが漏洩したときどっちが安全? 31/56
- 32. 辞書攻撃 ▌答えはどちらもたいして変わらない よくあるパスワード一覧のハッシュを取って一致するか確認する ハッシュ関数自体の安全性とは無関係 近年GPGPUを使ったハッシュ計算は凄まじく速い ▌Q. 11桁のマイナンバーのSHA256が分かっているときの攻撃時間 32/56
- 33. 対策 ▌ハッシュ関数を繰り返す H(salt, H(salt,H(salt, ... )))を保存する saltは適当な長さの乱数 Microsoft Office 2013～は10万回繰り返してる ▌パスワード用ハッシュ関数でGPGPU耐性のあるものも研究されている argon2など 33/56
- 34. ハッシュ関数のセキュリティ ▌256ビットハッシュ関数の衝突困難性を破るには何回試せばよいか 𝑚1 ≠𝑚2なる𝐻 𝑚1 = 𝐻(𝑚2)を見つける ▌中身を知らなくても平均的に2128 回試すと見つかる 誕生日のパラドックス ▌理想のNビットハッシュ関数はN/2ビットセキュリティ 強度は概ねAES128 = SHA256 = RSA3072 34/56
- 35. メッセージ認証符号（MAC : MessageAuthentication Code） ▌あるメッセージ（データ）が改竄されていないことを検証する 秘密鍵𝑘とメッセージ𝑚に対してある値𝑡 = ℳ(𝑘, 𝑚)を出力 𝑡をMAC値という ▌AがBに(𝑚, 𝑡 = ℳ 𝑘, 𝑚 )を送る ▌Bは𝑡 = ℳ(𝑘, 𝑚)を確認する 35/56
- 36. ハッシュ関数で作るMAC : HMAC ▌ℋ𝑘, 𝑚 = 𝐻((𝑘 ⊕ 𝑜𝑝𝑎𝑑)||𝐻((𝑘 ⊕ 𝑖𝑝𝑎𝑑)| 𝑚 ) 𝑜𝑝𝑎𝑑, 𝑖𝑝𝑎𝑑はある定数 𝐻を2回使うのがポイント 𝐻(𝑘||𝑚)としてはいけない ▌MACを使うには秘密鍵を相手に送る必要がある 36/56
- 37.
- 38. デジタル署名アルゴリズム（DSA） ▌あるメッセージを作った人が当人であることを検証する 他人はその当人に成りすましてメッセージに署名をつけられない 別のメッセージに対する偽の署名をつけられない ▌デジタル署名とメッセージ認証符号（MAC）の違い MACは盗聴されないように秘密鍵を送る必要がある 𝑛人とやりとりするときは全員で𝑛(𝑛 − 1)/2個の秘密鍵を送りあう デジタル署名は改竄されないように署名鍵を送る必要がある 𝑛人とやりとりするときは全員で𝑛個の署名鍵を公開する 38/56
- 39.
- 40.
- 41. 公開鍵基盤（PKI : PublicKey Infrastructure） ▌ループを断ち切るための信頼の枠組み 公開鍵証明書 Aの公開鍵が本当にAのものであると証明するもの 認証局 公開鍵証明書の発行や失効手続きを担う機関 認証局も公開鍵証明書を持つ 証明書を検証するときには有効期間や失効していないかも確認する 41/56
- 42.
- 43. PKIや証明書への攻撃 ▌認証局が攻撃を受けて不正な証明書を発行（2011年～） DigiNotar, COMODO,Digicert, etc. ▌Lenovoのsuperfish（2015年） パソコンのプレインストールソフトに不正な証明書 ▌広告差し替えソフト Privdog（2015年） ブラウザの証明書の検証機能の不備で無効化 43/56
- 44. 認証付き暗号 ▌通信には秘匿化するための暗号と改竄防止のためのMACが必要 それぞれは安全でも組み合わせ方に問題が見つかることがある 最初から両方の機能を持ったものが欲しい ▌AEAD（AuthenticatedEncryption with Associated Data） 暗号化と改竄検知を同時に行う ▌AES-GCM（Galois/Counter Mode） ブロック暗号のCTRモードに認証機構を組み込んだもの GoogleはChaCha20-Poly1305も採用（TLS1.3） 44/56
- 45.
- 46. 楕円曲線暗号（Elliptic Curve cryptography） ▌"楕円曲線"と呼ばれる数学的な対象物を用いた暗号全般 「暗号文のままで計算しよう 準同型暗号入門」 http://www.slideshare.net/herumi/ss-59758244 ▌ECDSA デジタル署名DSAの楕円曲線版 ビットコインでも用いられている 46/56
- 47.
- 48.
- 49. 楕円曲線暗号のメリット ▌同程度のRSA暗号比べて鍵サイズが小さい ▌RSAを使った署名とECDSAの比較 クライアント側はRSAの方がある程度軽い サーバ側の認証はECDSAの方がずっと軽い そのせいで最近はECDSAが好まれる セキュリティパラメータ RSA暗号 楕円曲線暗号 80 1024 160 128 3072 256～384 256 15360 512 49/56
- 50. 前方秘匿性（FS : ForwardScrecy） ▌公開鍵暗号の秘密鍵が漏洩（ろうえい）しても それまでの通信の安全性が保証される仕組み 公開鍵暗号の秘密鍵は長期間使う ▌2013年アメリカ国家安全保障局（NSA）の盗聴・監視が暴露される Snowdenが利用していたサーバの秘密鍵を裁判所が要求 FS非対応だったため過去のメールの内容が分かってしまう FSの重要性が強く意識される 50/56
- 51.
- 52. EC Diffie-Hellman鍵共有 ▌AliceとBobが二人だけの秘密の数値を共有する仕組み 𝑃は公開情報,Aliceは𝑎, Bobは𝑏を秘密に決める ▌他人は𝑃, 𝑎𝑃, 𝑏𝑃から𝑎𝑏𝑃を計算できない（と信じられている） 𝑎𝑃 𝑏𝑃 𝑎 𝑏𝑃 = 𝑎𝑏𝑃 𝑏 𝑎𝑃 = 𝑎𝑏𝑃 二人だけの秘密の数字 ？ 52/56
- 53. EC DH鍵共有を使ったFS ▌EC DH鍵共有で使い捨ての秘密鍵を使う（Ephemeral; 一時的な） ECDHE 𝑎′ 𝑏′ 𝑃が漏れても過去の𝑎𝑏𝑃は分からない Aさん Bさん 𝑎𝑃 𝐸𝑛𝑐 𝑎𝑏𝑃(𝑚) 𝐸𝑛𝑐 𝑎′ 𝑏′ 𝑃(𝑚′) いつも異なる鍵 セッション鍵の共有 本文の暗号化 セッション鍵の共有 本文の暗号化 𝑏𝑃 𝑏′ 𝑃𝑎′ 𝑃 53/56
- 54.
- 55. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ▌TLS1.2のプロトコルにおいて ECDHE ;ECDHにより前方秘匿性を持つ ECDSA ; サーバ認証でECDSAによるデジタル署名を使う AES_128 ; 共通鍵暗号は128ビットAES GCM ; 認証付き暗号はGCM SHA256 ; ハッシュ関数は256ビットSHA 完全性検証ではなくHMACを使った擬似乱数生成で使われる cf. TLS1.3ではTLS_AES_128_GCM_SHA256という表記 55/56
- 56. 参考文献 ▌SSL/TLS 20年の歩みと動向（JPNIC 2015年3月発行） https://www.nic.ad.jp/ja/newsletter/No59/0800.html ▌TLSの動向（IIR Vol. 31 Jun.2016） http://www.iij.ad.jp/company/development/report/iir/pdf/iir_v ol31_trend.pdf ▌いくつかの画像は『クラウドを支える暗号技術』と「いらすとや」 http://herumi.github.io/ango/ http://www.irasutoya.com/ 56/56