【要約】ITエンジニアのための暗号技術入門
こちらは、先日参加したStudyCoさん開催の勉強会(ITエンジニアのための暗号技術入門)の要約を備忘録がてらにまとめた記事になります。
暗号の要素
- アルゴリズム ⇒ 暗号化、複合化する仕組み（鍵穴のイメージ）
- キー ⇒ そのまんま鍵のこと。鍵穴を開けるためのもの
我々、エンジニアは秘匿情報が取られないようにセキュアなデータは暗号化しておく必要がある。
アルゴリズムが公開されていても、安全なの？？
「アルゴリズムが公開されている = 鍵穴の仕組みが公開されている」と考えると、「泥棒的には、どのメーカーのどの型番の鍵を使ってるか事前にわかるってことでしょ？？なんか、怖くない？？」ってなりますよね。
どんな暗号でも、仕組みが公開されていれば、総当たりで探していけば突破できそうですよね。
この総当たりで解読していく攻撃を、「ブルート・フォース・アタック」と言います。(カッコ良い)
現代の暗号化技術では、シンプルにめっっっっっっっっっちゃ時間がかかるようにして対策しています。
具体的には、128ビットAESという暗号化で 9兆年 、256ビットAESで 39兆年 かかると言われています。
アメリカの終身刑ウン百年みたいなノリですね。
暗号化が担保するもの
暗号技術は以下の4つを提供しています。
- 「機密性」 そのデータ、外に漏れてないよね？
- 「完全性」 そのデータ、本物だよね？(改ざんされてないよね？)
- 「認証」 このやり取りする相手、正しいよね？（誰かがなりすましとかしてないよね？）
- 「署名」 そのデータの送り主、本物だよね？
どういう仕組みで担保しているの？？
暗号化でよく聞く、「共通鍵暗号方式」と「公開鍵暗号方式」の2つをざっくり補足します。(わかる方は読み進めてください >< )
共通鍵暗号方式
暗号化する鍵と複合化する鍵が同じ方式
[AさんがBさんに暗号化してデータを送る場合]
- (事前にAさんはBさんに鍵を渡しておく)
- Aさんが鍵を使ってデータを暗号化してBさんに送る
- Bさんは、1の工程でAさんからもたっら鍵を使って復号化する
[メリット]
- 公開鍵暗号より安全(コスパが良い)
- 詳しくは省略するが、公開鍵暗号方式で使われる「使い捨てパッド」方式は数学的に絶対に解かれないことが証明されたらしい。。。
[デメリット]
- 鍵配送問題(どうやって、事前に安全に鍵渡すねん問題)
- デカい鍵を安全に送らないといけないが、それが安全にできるって無理ゲーじゃね？？といった具合に、どデカいデメリットがある
公開鍵暗号方式
暗号化する鍵と複合化する鍵が違う方式
[AさんがBさんに暗号化してデータを送る場合]
(AさんやBさんは、暗号化用の鍵(公開鍵)と複合化用の鍵(秘密鍵)をそれぞれ持っていて、暗号化用の鍵(公開鍵)は誰でも使うことができる)
- Aさんは、Bさんの公開鍵を使ってデータを暗号化して送信
- Bさんは、Aさんから受け取ったデータを秘密鍵で複合化(秘密鍵は自分しか知らないので安全)
[メリット]
-
- 鍵配送問題を解決できる
[デメリット]
- 共通鍵暗号方式より、処理が遅い
- 共通鍵暗号方式と同じくらいの安全性と担保するには、よりデータが大きい鍵を使う必要がある
- 入手した鍵が正しい公開鍵かがわからない(認証問題)
共通鍵暗号方式と公開鍵暗号方式では、それぞれ以下のデメリットがあります。
[共通鍵暗号方式]
- 鍵配送問題(どうやって、事前に安全に鍵渡すねん問題)
[公開鍵暗号方式]
- 共通鍵暗号方式より、処理が遅い(共通鍵暗号方式と同じくらいの安全性と担保するには、よりデータが大きい鍵を使う必要がある)
- 入手した鍵が正しい公開鍵かがわからない問題(認証問題)
これらの課題を受けて、以下の方式ができました。
ハイブリッド型(共通鍵 × 公開鍵)
共通鍵と公開鍵の良いとこどりをした方式
[AさんがBさんに暗号化してデータを送る場合]
(AさんやBさんは、暗号化用の鍵(公開鍵)と複合化用の鍵(秘密鍵)をそれぞれ持っていて、暗号化用の鍵(公開鍵)は誰でも使うことができる)
- Aさんは、共通鍵を生成し、その共通鍵でデータを暗号化する(共通鍵で暗号化したので同じ共通鍵でないと復号できない)
- Aさんは、生成した共通鍵をBさんの公開鍵で暗号化
- Aさんは、①共通鍵で暗号化したデータ と、②公開鍵で暗号化した共通鍵 の2つをBさんに送る
- Bさんは、受け取った②を自分の秘密鍵で復号し、複合した共通鍵で、①を復号
[メリット]
- 公開鍵暗号方式のデメリットを改善
- 暗号化するのは共通鍵(軽量)なので、計算も楽()
[デメリット]
- 入手した鍵が正しい公開鍵かがわからない問題(認証問題) が解決されていない
ハイブリッド方式を持ってしても、途中で、公開鍵がすり替えられる(中間者攻撃)と気づかない。。。
対策には、 「認証」 (通信相手が正しいと いう証明)が必要
認証のための暗号化技術
一方向ハッシュ関数 (完全性(改ざんされていないこと)を担保)
ファイルをハッシュ関数でハッシュ化したハッシュ値を保管し、ファイル同士のハッシュ値を比較して、正しいファイルかを検証
⇒ しかし、「中間者攻撃」「なりすまし」 を検出することができない
ハッシュの性質
- 対衝突性
- 異なる入力データに対して、同じハッシュ値が生成される（衝突する）ことが非常に困難であること
- どのビット列からも同じくらいのハッシュ値になる
- SHA-256というハッシュ関数は256ビットで出てくる
- ハッシュ値からビット列を再現できない
- パスワードの入力などは、パスワードを直接比較しているのではなく、ハッシュ値を比較している
- 高速に計算できる
メッセージ認証コード(完全性(改ざんされていないか)、認証(なりすましされていないか)を担保)
受信者と送信者で、MAC(Message Authentication Code)呼ばれる共有の鍵を使って、一方向ハッシュ値を計算する値(MAC値)が一致するかを確認
⇒
[AさんがBさんに暗号化してデータを送る場合]
- Aさんは、データと秘密鍵を用いて認証タグ(MAC)を生成します。
- Aさんは、生成した認証タグ(MAC)とデータをBさんに送信します。
- Bさんは、受信したデータと共通の秘密鍵を用いて認証タグ(MAC)を生成します。
- Bさんは、Aさんから受け取った認証タグと自分で生成した認証タグ(MAC)を比較し、一致しているかどうかを検証します。
Aさんが生成した認証タグ(MAC)とBさんが生成した認証タグ(MAC)が一致している場合、メッセージは改ざんされていないことが確認できる
デジタル署名(署名(データの送り主が正しいか)を担保)
データの送り主が正しいかを判別するには、その送り主しか知っていない情報を知っていれば良いです。(サスペンスでいう、犯人しか知っているはずがない情報を知っていればそいつが犯人的なノリです)
デジタル署名では、当人かを判別する情報として、「秘密鍵」を使います。確かにその人しか知っていない情報ですね。
具体的な手順は以下になります。
- Aさんは、署名対象のデータをハッシュ関数にかけて、ハッシュ値を計算します。
- Aさんは、自分の秘密鍵を用いて、ハッシュ値を暗号化します。(ハッシュ値に対する署名が生成)
- Aさんは、署名対象のデータと、暗号化した署名を一緒に送信します。
- Bさんは、受け取ったデータに対してハッシュ関数を適用してハッシュ値を計算します。
- Bさんは、Aさんの公開鍵を用いて、受け取った署名を復号化します。これによって、Aさんがハッシュ値に対して署名したことが確認。
Bさんが計算したハッシュ値と、Aさんから受け取ったハッシュ値が一致していたら本物、違う値なら偽物
公開鍵暗号方式の逆verをするイメージです。
| Head | 公開鍵暗号方式 | デジタル署名 |
|---|---|---|
| 暗号化 | 公開鍵 | 秘密鍵 |
| 復号化 | 秘密鍵 | 公開鍵 |
ざっくり要約すると、「デジタル署名 = データを一方向ハッシュ関数でハッシュ化したものを秘密鍵で暗号化したもの」です。
デジタル署名の課題
- 公開鍵が本物かわからない (公開鍵がすり替えられて、中間者攻撃が使える)
堂々巡り問題
色々な対策を講じて、暗号化技術は発展したが、結局は、「この公開鍵は、正しいの？」 の問題に行き着く。
共通鍵暗号方式と公開鍵暗号方式のハイブリッド型を使っても、公開鍵が正しいか(なりすましされていないか)を確かめるため、「認証」が必要です。
暗号化アルゴリズムで「機密性」を、メッセージ認証で「認証」を、一方向ハッシュ化で「完全性」を担保しても、デジタル署名で「署名」を担保するには、「公開鍵」が必要になります。
署名で使う公開鍵がなりすましされていないかをメッセージ認証で確かめるとなると、この一連の流れを永遠にループすることになります。
この負のループを止めるため(正しい公開鍵を入手するため)に、「証明書」 が必要になります。
証明書とは？？
- 信頼できる第三者にデジタル署名をしてもらう
- でも、そのデジタル署名は正しくできてるの？？で堂々巡りになる
- デジタル署名の社会基盤(PKI: 公開鍵基盤)が必要 ⇒ 第3者機関である認証局で担保
要約すると、「堂々巡りになるから、第三者機関を置いて、もうこいつは正しいってことにしようぜ」って感じです。
みんなで認証局を作って、こいつは正しいってことでよろしく！的な感じです。
Discussion