Closed yanachuwan9sm closed 6 months ago
ハッシュ関数・共通鍵暗号・公開鍵暗号・デジタル署名・デジタル証明書
ハッシュ関数をh()、入力データを A,B.....、算出されたハッシュ値を X,Y....、長さを len() とすると以下の様な特性がある。
有名なハッシュ関数には、MD5(128ビット)、SHA-1(160ビット)、SHA-2(SHA-224、SHA-256など)が存在する。(MD5とSHA-1は今現在非推奨のアルゴリズム)
以下、公開鍵方式を用いた場合のおおまかな流れ。
1.受信者は公開鍵と秘密鍵(鍵ペア)を作る。 2.受信者は公開鍵をみんなに公開・配布し、秘密鍵だけを保管します 3.送信者は公開鍵を暗号鍵として暗号化して、送信します 4.受信者は秘密鍵を復号鍵として復号します
ex ) 南京錠
- 受信者は南京錠(公開鍵)とその鍵(秘密鍵)を作る。
- 受信者は南京錠を全員に公開・配布し、その鍵だけを保管する
- 送信者は南京錠をかけて(公開鍵を暗号鍵として暗号化)送信する
- 受信者は鍵を使って(秘密鍵を復号鍵として復号することで)中身を確認することができる。
👉 これにより、署名者であることを(B)により確認でき、署名は確かに本人の行為によるものであることを(A)により、署名の対象と署名が対応しているものであることは(C)により保証されます。
ex: 鍵の方を配って、南京錠を秘密にするイメージ。 手紙の本文に対して、南京錠を開けたデータも一緒に添付して送付する 受け取った人は、公開されている鍵を使って南京錠を解除した時に、本文と同じものが出てきたら、本文が改竄されていないことはわかる!
「自分が自分であること」を証明するもの。大事なのは、正当性を担保するものは公開鍵。そのため、公開鍵証明書とも呼ばれる。
デジタル証明書の特徴としては以下の通り。
また、デジタル証明書は署名前証明書・ディジタル署名のアルゴリズム・デジタル署名の3つで構成される。
署名前証明書がサーバーやサーバーの所有者の情報であり、サーバーのURLを表すコモンネームや有効期限、公開鍵などが含まれます。また、デジタル署名は、署名前証明書をハッシュ化してできたハッシュ値(メッセージダイジェストとも言う)を、認証局の秘密鍵で暗号化したものです。
サーバー証明書を受け取った受信者は、証明書の中に含まれるデジタル署名を認証局の公開鍵(ルート証明書)で復号し、署名前証明書と比較します。一致していれば、証明書が改ざんされていない、つまりそのサーバーが本物だということがわかります。
下位の認証局(CA)は上位の認証局に証明書を発行してもらうことで、その信頼性を担保しています。階層構造の最上位に位置する認証局をルート認証局と呼び、ルート認証局自身は自分自身に対してディジタル証明書、つまりルート証明書を発行しています。サーバー証明書の場合、クライアントは信頼できる認証局のルート証明書を予め保持しており、信頼する者が発行した証明書は信頼できると考えます。またそれと同様に、「信頼するルート認証局が信頼した子認証局が発行した証明書は信頼できる」と考えるため、サーバー証明書の発行者をたどっていき、ルート証明書をクライアントが信頼している場合、そのサーバー証明書は信頼されます Matsuda Tatsuya. Introduction to TLS Thoroughness: Illustrated explanation Internet Technology (Japanese Edition) (pp.55-56). Kindle 版.
以下の様なアプリケーション層のプロトコルと組み合わせて利用されることが多い。
元プロトコル | ポート番号 | SSLと組み合わせたプロトコル | ポート番号 |
---|---|---|---|
HTTP | 80 | HTTPS | 443 |
SMTP | 25 | SMTPS | 465 |
FTP | 20、21 | FTPS | 989、990 |
IMAP | 143 | IMAPS | 993 |
POP3 | 110 | POP3S | 995 |
(以下は TLS v1.2の場合のシーケンス図になる。v1.3は異なる。)
大雑把に何をやっているかを書くと以下の感じ。(本当はもっと色んなことをしてる)
Keep-Alive
が有効な場合、セッションが持続するため、これ以降のRTTは必要ない)👉 安全性の高い「公開鍵暗号方式」で"共通の鍵"を共通し、処理速度が速い「共通鍵暗号方式」でデータの送受信を行うという「ハイブリッド暗号方式」を利用している。
👉 実際は、RSA の鍵交換において実際に交換されるのは共通鍵そのものではなく、プレマスターシークレットとよばれる乱数のデータやマスターシークレットを扱う事になる。
サーバー証明書を発行するまでの流れは以下の通り。
1.SSL/TLSサーバーで秘密鍵を作成する 2.1で作成した秘密鍵をもとに「CSR(CertificateSigningRequest)」を作成し、認証局に提出する 3.認証局の審査を受ける 4.認証局から受け取ったサーバー証明書をSSL/TLSサーバーにインストールする(サーバー証明書には公開鍵が含まれており、サーバにインストールする際は一緒に秘密鍵もインストールされる)
各シーケンスにおける詳細は以下の記事の解説がめちゃめちゃ分かりやすい。
モチベ
Real World HTTP 読んでたら出てきたトピック。 あんまり理解してなかったのでやる。
文献
SSL/TLS徹底入門: わかりやすい図解解説 インターネット技術 | 松田達也 | コンピュータ・情報処理 | Kindleストア | Amazon
【PKI 応用】SSL/TLS ハンドシェイクをわかりやすく図解 | ねこまるの AD フリーク
【図解】よく分かるデジタル証明書(SSL証明書)の仕組み 〜https通信フロー,発行手順,CSR,自己署名(オレオレ)証明書,ルート証明書,中間証明書の必要性や扱いについて〜 | SEの道標
【図解】TLS v1.3の仕組み ~Handshakeシーケンス,暗号スイートをパケットキャプチャで覗いてみる~ | SEの道標