サーバ認証とメッセージ認証

① SSL/TLS

SSL（Secure Sockets Layer）およびその後継のTLS（Transport Layer Security）は、インターネット上の通信を保護するためのプロトコルです。Webブラウザでの安全な通信（HTTPS）はHTTP over SSL/TLSの略称であり、以下の2つの機能を提供します。

機能1: データ暗号化（セッション鍵方式）

通信データの盗聴を防ぐため、セッション鍵暗号方式で通信内容を暗号化します。Theme 1で学んだハイブリッド暗号の仕組みがここで使われています。サーバの公開鍵でセッション鍵を安全に共有し、以降のデータ通信は高速な共通鍵暗号で保護します。

機能2: サーバ認証（デジタル証明書）

接続先のサーバが本物であることを確認する仕組みです。認証局（CA）が発行したデジタル証明書を使って、サーバの正当性を検証します。

② ハッシュ関数

ハッシュ関数は、任意の長さのデータを入力として受け取り、固定長の出力値（メッセージダイジェスト/ハッシュ値）を生成する関数です。以下の重要な性質を持ちます。

• 一方向性: ハッシュ値から元のデータを復元することは計算上不可能
• 衝突耐性: 異なるデータから同じハッシュ値が生成される確率が極めて低い
• 固定長出力: 入力データの大きさに関係なく、出力は常に同じ長さ
• 高感度: 入力データが1ビットでも変わると、ハッシュ値が大きく変化する

代表的なハッシュ関数としてSHA-256（出力256ビット）があります。これらの性質により、データの改ざん検知に利用されます。送信前と受信後のハッシュ値を比較し、一致すれば改ざんなし、不一致であれば改ざんの可能性があると判断できます。

③ デジタル署名

デジタル署名は、電子文書の送信者の正当性とデータの改ざんがないことを証明する技術です。公開鍵暗号の仕組みを暗号化通信とは逆方向で使用するのが特徴です。

暗号化通信では「受信者の公開鍵で暗号化→受信者の秘密鍵で復号」でしたが、デジタル署名では「送信者の秘密鍵で署名→送信者の公開鍵で検証」という逆の方向で鍵を使います。

デジタル署名の手順を6つのステップで見ていきましょう。

ステップ1: 送信者が送信データ（平文）を準備する

ステップ2: 送信データのハッシュ値（メッセージダイジェスト）を生成する

ステップ3: ハッシュ値を送信者の秘密鍵で暗号化する（これが署名データ）

ステップ4: 元の送信データと署名データをセットにして受信者に送る

ステップ5: 受信者は受け取った署名データを送信者の公開鍵で復号し、ハッシュ値Aを得る。同時に、受け取った元データから自分でもハッシュ値Bを計算する

ステップ6: ハッシュ値Aとハッシュ値Bを比較する。一致すれば「送信者が本物であること」と「データが改ざんされていないこと」が確認できる

デジタル署名で保証できるのは送信者の真正性（なりすまし防止）とデータの完全性（改ざん検知）です。通信内容の秘匿（機密性）は保証しない点に注意しましょう。

④ 認証局（CA: Certificate Authority）

公開鍵暗号やデジタル署名を使うには、「この公開鍵は本当にその人（サーバ）のものか？」を保証する仕組みが必要です。この役割を担うのが認証局（CA）です。

認証局は以下の機能を提供します。

• デジタル証明書の発行: 公開鍵の所有者情報をCAの秘密鍵で署名した電子文書
• 公開鍵の正当性保証: 証明書を検証することで、公開鍵が本物であることを確認
• 証明書失効リスト（CRL）の管理: 無効になった証明書の一覧を公開

階層型の認証局構造（ルートCA→中間CA→サーバ証明書）をPKI（公開鍵基盤: Public Key Infrastructure）と呼びます。

デジタル証明書の検証は以下の流れで行われます。

1. ブラウザがサーバからデジタル証明書を受信する

2. 証明書に記載されたCAの情報を確認する

3. CAの公開鍵を使って証明書のデジタル署名を検証する

4. 署名が正しければ、証明書に含まれるサーバの公開鍵は信頼できると判断する

5. ブラウザのアドレスバーに鍵マークが表示され、安全な通信が開始される

ルートCAの公開鍵（ルート証明書）は、ブラウザやOSにあらかじめ組み込まれています。このため、ユーザーが特別な操作をしなくても自動的にサーバ証明書の信頼性を検証できる仕組みになっています。