暗号化通信の目的
暗号化通信の主な目的は、インターネットなどの誰でも使用できるネットワーク上で、データを保護することです。
具体的には以下の3つの要素を保証します。
機密性（Confidentiality）: データの中身を第三者に盗み見られないようにする。
完全性（Integrity）: データが途中で改ざんされないように、または改ざんに気づくようにする。
認証（Authentication）: インターネット上では相手が見えないので通信相手が本当に信頼できる相手であるかを確認する（なりすましの防止）。
暗号化通信に必要な要素
安全な通信を確立するためには、主に以下の要素が必要です。
鍵交換方式: 共通鍵（セッション鍵）をどうやって作るかの方法
共通鍵暗号方式: 作った共通鍵（セッション鍵）を使ってデータをどうやって暗号化するかの方法
公開鍵暗号方式: サーバ証明書の署名確認する為とRSA鍵暗号方式のプリマスタシークレットを交換するための方法
ハッシュ関数:署名やMACや共通鍵に使用するハッシュ値
デジタル署名: TLSハンドシェイクをハッシュ化した物
デジタル証明書: サーバの身分証明書
主な流れ
暗号スイート フォーマット
TLS1.2以前のフォーマット
TLS_鍵交換方式認証アルゴリズム_WITH‗暗号アルゴリズム鍵長モード_ハッシュアルゴリズム
例：TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
・TLS:TLSプロトコルを使用 ・ECDSA：サーバ証明書の署名とTLSハンドシェイクのハッシュ化に使う
・AES_128：共通鍵暗号アルゴリズムがAESで、鍵長が128ビット
・GCM：AESが使用するブロック暗号の運用モード ・SHA256：メッセージ認証用の際に使うハッシュ値
例２：TLS_RSA_WITH_AES_128_GCM_SHA256
・TLS:TLSプロトコルを使用 ・RSA：鍵交換方式と交換方式の両方を兼ねている
例３：DHE-RSA-AES128-SHA256
AESにモードが記載されていない場合は、TLS 1.2以前の暗号スイートでは、「CBCモードがデフォルト」なのでCBCモードとなります
TLS1.3のフォーマット
TLS_暗号アルゴリズム鍵長モード_ハッシュアルゴリズム
TLS 1.3接続で鍵交換方式はDHEかECDHEが必須となり、認証付き暗号（AEAD: Authenticated Encryption with Associated Data）が使われることが前提となっているので、フォーマットがシンプルになり鍵交換と認証アルゴリズムは無くなりました
例：TLS_AES_128_GCM_SHA256
・TLS:TLSプロトコルを使用 ・AES_128：共通鍵暗号アルゴリズムがAESで、鍵長が128ビット
・GCM：AESが使用するブロック暗号の運用モード ・SHA256：メッセージ認証用の際に使うハッシュ値
鍵交換方式
共通鍵暗号方式
公開鍵暗号方式
共通鍵を安全に交換したり、デジタル署名を行ったりするための方法。
暗号化と復号化に異なる鍵（公開鍵と秘密鍵のペア）を使用する。
公開鍵: 誰にでも公開され、暗号化や署名の検証に使う。
秘密鍵: 所有者のみが持ち、復号化や署名の生成に使う。
役割:
鍵交換: 共通鍵を安全に交換するために使われる（RSA鍵交換、DH/ECDHの基盤）。
デジタル署名: データの作成者を認証し、データの完全性を保証するために使われる。
種類:
RSA暗号方式: 広く使われている。鍵交換（TLS 1.2まで）やデジタル署名に利用。
ECDSA (Elliptic Curve Digital Signature Algorithm): 楕円曲線暗号に基づくデジタル署名。RSAより短い鍵長で同等以上の強度を持つため、近年普及。
ハッシュ関数
データの完全性を検証するためのもので、任意の長さのデータから、固定長の短いデータ（ハッシュ値、ダイジェスト、フィンガープリントとも呼ばれる）を生成する一方向の関数。
特徴:
一方向性: ハッシュ値から元のデータを復元することは非常に困難。
衝突耐性: 異なるデータから同じハッシュ値が生成されること（衝突）が非常に起こりにくい。
改ざん検知: わずかなデータの変更でもハッシュ値が大きく変わるため、データの改ざんを検知できる。
役割:
データ完全性の保証: 通信中のメッセージやファイルの改ざんを検知する。
デジタル署名: 署名対象のデータ全体ではなく、そのハッシュ値に対して署名を行う。
（サーバー証明書の検証や、TLS 1.3でのハンドシェイクメッセージの署名など）
種類:
SHA-2 (Secure Hash Algorithm 2): SHA-256, SHA-384, SHA-512など。現在の主流。
SHA-3 (Secure Hash Algorithm 3): SHA-2の後継として開発。
MD5, SHA-1: 過去に使われたが、衝突が見つかっているため、現在では非推奨。
データ完全性の保証
データの改ざんを検出する鍵（MAC鍵など）を生成
KDF「鍵導出関数 (Key Derivation Function) 」は、プリマスターシークレット、クライアント乱数、サーバー乱数、そしてTLSプロトコルの特定のラベルなどを使う
メッセージ認証コード (MAC（Message Authentication Code）)
データが途中で改ざんされていないこと（完全性）と、データが正規の送信者から送られたものであること（メッセージ認証）を保証する
送信者は、送りたいデータと、事前に共有した秘密の鍵・MAC鍵を準備
データと秘密のMAC鍵を、特定のハッシュ関数（HMAC-SHA256など）に通して、「MAC値」を計算いて送信する
デジタル署名 (Digital Signature)
公開鍵暗号とハッシュ関数を組み合わせて、データの作成者認証とデータ完全性を保証する技術。
仕組み:
１ 送信者がメッセージのハッシュ値を計算する。
２ 送信者がそのハッシュ値を自身の秘密鍵で暗号化（署名）する。
３ メッセージと署名を一緒に受信者に送る。
４ 受信者は、受信したメッセージのハッシュ値を自身で計算する。
５ 受信者は、送信者の公開鍵を使って署名を復号し、署名されたハッシュ値を取得する。
６ ４で計算したハッシュ値と５で得られたハッシュ値が一致すれば、メッセージは改ざんされておらず、かつその秘密鍵を持つ正当な送信者から送られたものと確認できる。
役割:
サーバー認証（CertificateVerifyメッセージ）、証明書の信頼性検証など。
秘密鍵で暗号化されたデータを公開鍵で復号することによって、サーバーが証明書に対応する秘密鍵を本当に所有しているか（認証）出来る。
この検証がOKなら、「このサーバーは、提示した証明書（公開鍵）に対応する秘密鍵を持っている」と確認でき、サーバーが正当であることの証拠になる
クライアントは、サーバと同じアルゴリズムでハッシュ値を計算し、サーバーから送られてきたハッシュ値（署名）と、自身で計算したハッシュ値が一致するかを確認。
一致すれば、ハンドシェイクメッセージは改ざんされていないことが保証できる
デジタル証明書 (Digital Certificate)
公開鍵と所有者を紐付け、信頼性を証明するもの。
公開鍵とその所有者（サーバー、個人、組織など）の身元情報を紐付け、信頼できる第三者機関（認証局: CA）がデジタル署名したもの。
構成:
公開鍵
所有者の情報（ドメイン名、組織名など）
発行者（CA）の情報
有効期限
CAのデジタル署名
役割:
身元保証: サーバーやクライアントが「私は〇〇です」と主張する際に、その主張が正しいことを証明する。
公開鍵の配布: 認証された公開鍵を安全に配布する。
信頼の鎖（Chain of Trust）:
多くの証明書は、ルート認証局（自己署名証明書）から中間認証局、そしてエンドエンティティ証明書へと続く「信頼の鎖」によって署名されています。
クライアントは、この鎖をたどって、最終的に自分が信頼しているルートCAにたどり着けば、その証明書は信頼できると判断します。
１．ルート認証局の公開鍵でルート証明書の署名を検証
①クライアントはルート認証局の証明書から公開鍵を取り出します。
（ルート証明書はパソコンの証明書ストアに入ってます）
②取り出した公開鍵[ルート]を使ってルート証明書の署名を検証する。
③問題が無ければ、ルート証明書は正常と判断する
２．ルート証局の公開鍵で中間認証局の証明書の署名を検証
①クライアントはルート認証局の公開鍵で中間証明書の署名を検証する。
（中間認証局の証明書はサーバから取得します）
③問題が無ければ、中間証明書は正常と判断する
３．中間認証局の公開鍵でサーバ証明書の署名を検証
①クライアントは中間認証局の証明書から公開鍵を取り出します。
②取り出した公開鍵[中間]を使ってサーバ証明書の署名を検証する。
③問題が無ければ、サーバ証明書は正常と判断する
メモ
クライアントはRSAの認証アルゴリズムしか使えない場合で、サーバ証明書の認証アルゴリズムがECDSAで作られていたらTLSハンドシェイクは失敗し、安全な接続は確立できません。
クライアントは証明書に含まれるECDSA公開鍵を見て、自分がサポートする認証アルゴリズム（RSAのみ）とは異なる為、クライアントはECDSA署名を検証する能力がないため、サーバーの身元を認証できない
コメント