ネットワーク暗号化自分的まとめ(証明書,デジタル署名...)
この記事について
ネットワーク暗号化について雑にまとめていく
参照文献
このSEの道標というブログにめちゃくちゃお世話になりました。
公開鍵暗号方式について
まずは一番基礎の公開鍵暗号方式についてまとめてみる。参考にしたページ
公開鍵暗号方式にもさまざまな種類があり、「RSA」,「DSA」,「Diffie Hellman(DH)」などが有名。
RSA
暗号化→公開鍵で暗号化して、秘密鍵で複合する。BitLocker,Windows EFS,OpenPGP,S/MIMEなどで使われる。挙げた例は全て共通鍵を暗号化するハイブリッド方式。
デジタル署名→秘密鍵で暗号化(署名)して、公開鍵で複合(検証)する。各種通信及びデジタル証明書(SSL/TLS,IPsec等)で利用される。
鍵交換→昔はSSL/TLSで使用されていたが、現在は実質廃止状態
DSA(ECDSA,EdDSA)
デジタル署名→秘密鍵で署名して公開鍵で検証する。RSAのように暗号化、複合するわけではない。各種通信及びデジタル証明書で利用される。
Diffie Hellman(DH)
鍵交換→互いの公開鍵を交換し、自分の秘密鍵/公開鍵と相手の公開鍵から「共通鍵」を生成する。SSL/TLSやIPsecで利用される。
RSA公開鍵/秘密鍵について
・公開鍵で暗号化すると、秘密鍵でのみ複合化できる。これにより機密性が確保できる。
・秘密鍵で暗号化すると公開鍵でのみ複合できる。これにより機密性の確保ができるわけではないが、発信源の保証と、内容が改ざんされていない、つまり完全性・真正性が確保できる。主にデジタル署名で利用される。
ちなみにDSA,ECDSA,EdDSAでデジタル署名を行う場合、これらは署名専用のアルゴリズムのため、暗号化、複合化の機能がなく、秘密鍵で署名して公開鍵で検証する機能のみ。
Diffie Hellman(DH)鍵共有について
IPsec,SSL/TLS,SSH等は、共通鍵暗号方式での暗号化のための共通鍵の共有を、DHのアルゴリズムで実現している。参照ページ
デジタル署名について
電子データに対して印鑑を押す行為に似ていて、改ざん検知と否認防止に使用される。参照ページ
デジタル署名は、ハッシュ関数と署名用の公開鍵暗号方式を組み合わせたものになる。
※ハッシュ関数の元データに戻せない性質を利用しているため、ハッシュ関数は暗号化するものにはならない(暗号化と呼ぶのは復号化できる必要があるため)
署名フェーズ(RSAの場合)
1,電子データのサイズを縮小し、かつ改ざん検知できるようにハッシュ化する
2,ハッシュ値をRSA秘密鍵により暗号化する
検証フェーズ(RSAの場合)
3,公開鍵を使用して複号する
4,データが改ざんされていない場合、複合したものと、電子データをハッシュ化したものは一致する。
盗聴への保証は？
保証はない。というより必要がない
使用されるアルゴリズム
ハッシュ関数→SHA-256,SHA-384,SHA-1(危殆化。rhel9でも非推奨)
デジタル証明書について
参照ページ
デジタル証明書とは、サーバやNW機器へ高セキュリティで通信するために使用される電子ファイルのこと。デジタル証明書は認証局と呼ばれる機能を持つサーバが生成する。
一番有名なhttpsで利用されるSSL証明書があるが、それ以外でもデジタル証明書の仕組みは利用される。IPsec認証用やメール送信元の証明、Windows EFS暗号化など。
SSL証明書で行われるHTTPS通信の仕組み
前提として、認証局から通信先のサーバ(サーバAとする)のデジタル証明書を生成してもらう。デジタル証明書には「サブジェクト代替名(DNS name):a.example.com」と記載されている。デジタル証明書には公開鍵が含まれており、サーバにインストールする際は一緒に秘密鍵をインストールする。
1,クライアントがブラウザに「https://a.example.com」と入力する。
2,ブラウザはDNSサーバにa.example.comのIPを聞きに行き、回答をもらう。
3,ブラウザはそのIPにTCPコネクションを確立し、その直後にSSL/TLSによる通信をするためのネゴシエーションを開始する。デジタル証明書はこのネゴシエーション最中に提示される。
4,クライアントは証明書のサブジェクト代替名(SANs)と入力したURLのFQDNが一致するか確認する。これが一致した場合&&証明書自体が信頼できると判断された場合、証明書の内容は正しいと認識される(証明書に、認証局のデジタル署名がある)
ただし、デジタル証明書は一般的にインターネット上で公開されるため、まだ保証できない。
5,通信の暗号化をするための共通鍵の交換はDH方式が使われるが、DH公開鍵をサーバaの秘密鍵で署名することでサーバを認証できる。(証明書にサーバaの公開鍵がついているため)
デジタル(SSL)証明書の信頼モデルについて
デジタル証明書を発行する中間認証局がその中間認証局の秘密鍵で証明書にデジタル署名する。
中間認証局の身元の保証はさらに上位の認証局が行う。このプロセスの最上位はルート認証局になるが、ルート認証局の身元は自分自身で署名する**(オレオレ証明書)**。で、どのルート証明書を信頼すべきかは、OSやブラウザにあらかじめインストールされている。ユーザ自身が付け加えることもできる(オフライン環境の現場でよく行われる)
OpenPGPやS/MIMEとの違い
OpenPGPやS/MIMEはともにメールを暗号化しつつ、署名により改ざん検知と否認防止をする技術。
基本的な仕組み(RSA)
送信者の処理
1,ユーザa(送信者)は署名検証用の公開鍵をユーザb(受信者)にわたし、ユーザbは暗号化用の公開鍵をユーザaにわたす。
2,ユーザaは送りたいメール本文のハッシュ値を署名用の秘密鍵で暗号化し、デジタル署名を生成する。
3,ユーザaはセッションキーを生成し、メール本文をセッションキーで暗号化する
4,ユーザaはセッションキーをユーザbの暗号化用の公開鍵で暗号化する。
5,ユーザaはデジタル署名、暗号化されたメール本文、暗号化されたセッションキーをセットでメールでユーザーbに送る。
受信者の処理
1,ユーザbは暗号化(復号化)用の秘密鍵でセッションキーを複合する。
2,ユーザbはセッションキーを使用して暗号化されたメール本文を複合する。
3,ユーザbはメール本文をハッシュ化する。
4,ユーザbはデジタル署名をユーザaの署名検証用の公開鍵で複合する。
5,3で生成したものと4を比較して一致すれば検証成功になり、完全性と真正性が保証。
この過程で、ユーザaの署名鍵が信頼できるものでなければいけないが、その信頼モデルがOpenPGPとS/MIMEでは異なる。
S/MIME→ユーザaの署名鍵に対して第三者機関の認証局(PKI)が署名する(SSL/TLS)と同じ。
OpenPGP→ユーザaの署名鍵に対して、ユーザaを知るユーザが善意で署名する。
デジタル証明書発行手順
1,OpenSSLの証明書発行コマンド等でCSRと秘密鍵が発行される。CSRとは、証明書発行要求と呼ばれるもので、これを生成する際に秘密鍵と公開鍵も作られる。CSRには公開鍵が含まれている。
2,CSRを認証局にメール等で送付する。デジタル証明書本体はインターネット上に公開して使用するのが一般的で、そのもとになるCSRは公開されて構わない情報になる。
3,認証局がCSRをハッシュ化したものに秘密鍵で暗号化したもの(電子署名)をCSRの末尾に付け加えることでデジタル証明書が出来上がる。
ルート証明書(自己署名証明書、オレオレ証明書)発行手順
自分の秘密鍵を使用して電子署名する。
誤解されがちだが、自分でADサーバ等でルート認証局を立て、そのCAの秘密鍵でデジタル署名した証明書は自己署名証明書とは呼ばない。
SSHについて
ホスト認証の場合
1,クライアントはクライアント側のDH公開鍵を送信する。(最初に共有鍵を共有し、以降の通信のすべてを暗号化するため。)
2,サーバは、サーバ側のDH公開鍵を送信するが、同時にRSA公開鍵とRSA秘密鍵による署名(サーバ側のDH公開鍵を元にする)も送信する。
3,クライアントはサーバからの署名をRSA公開鍵で検証し、正しい通信相手だと認証する(ホスト認証)。また、クライアントは初回アクセスであればサーバのIPと紐づけてそのRSA公開鍵をインストールする。teratermでよくあるセキュリティ警告のあれですね。
クライアント認証の場合
IDパスワードと公開鍵認証の二つがある。
IDパスワード認証は、ホスト認証にある記載の通り、共通鍵で通信が暗号化されるため、IDやパスワードは暗号化された状態でサーバに送付される。
公開鍵認証は、IDパスワードを使わず、クライアントの公開鍵による認証を行う。
これを行うにはｍ事前にRSA等の公開鍵/秘密鍵のペアを生成し、公開鍵をサーバにインストールする必要がある。(サーバの/home/ユーザー名/.ssh/authorized_keysに公開鍵情報を書き込む必要がある。)
そして、クライアントが秘密鍵による署名をサーバへ送信するのみ。
Discussion