1.4暗号技術（共通鍵・公開鍵・ハイブリッド暗号・ハッシュ・鍵管理）

暗号技術は「誰にも読まれたくない情報を守る技術」というイメージが強いですが、管理者にとって重要なのはアルゴリズムの実装ではなく、どの方式をいつ使い、鍵をどう管理するかという運用の観点です。強力な暗号方式を選んでも、鍵の管理がずさんであれば意味がありません。この節では暗号方式の基本的な使い分けと、SGで特に重視される鍵管理・危殆化への対応を学びます。

1.4.1共通鍵暗号・公開鍵暗号・ハイブリッド暗号

• 共通鍵暗号＝暗号化と復号に同一の鍵を使う方式（例: AES）。処理が高速だが、通信相手ごとに鍵を安全に共有する鍵配送問題が課題。公開鍵暗号＝対になる公開鍵と秘密鍵を使う方式（例: RSA）。公開鍵で暗号化した内容は対応する秘密鍵でしか復号できないため鍵配送問題を解消するが、処理は共通鍵暗号より低速。
• ハイブリッド暗号＝実務での主流方式。データ本体は高速な共通鍵暗号で暗号化し、その共通鍵（セッション鍵）だけを公開鍵暗号で暗号化して送ることで、鍵配送問題の解消と処理速度を両立させる。SSL/TLSの鍵交換もこの方式に基づく（詳細は次節）。

1.4.2ハッシュ関数・暗号の危殆化・鍵管理

• ハッシュ関数＝任意長のデータから固定長の値（ハッシュ値）を生成する一方向関数（復号不可・元データの復元は不可能）。同じ入力からは必ず同じハッシュ値が得られるため、改ざん検知やパスワードの安全な保管（平文で保存せずハッシュ値を保存）に使われる。
• 暗号の危殆化＝計算機の性能向上や新たな解読手法の発見により、過去は安全だった暗号方式・鍵長が時間の経過とともに解読可能になる現象（例: 古いハッシュ関数MD5・SHA-1は衝突が発見され新規利用が非推奨）。管理者は「導入時に安全だったから今も安全」と考えず、危殆化情報を継続的に把握し、暗号方式・鍵長を計画的に更新（クリプトアジリティ）する責任がある。
• 鍵管理のライフサイクル＝生成（十分な強度の鍵を安全な方法で生成）→保管（HSM（ハードウェアセキュリティモジュール）等での安全な保管、秘密鍵の漏えい防止）→更新（ローテーション）（定期的に鍵を新しくし、漏えい時の被害範囲を限定）→廃棄（不要になった鍵を復元不可能な形で確実に削除）。秘密鍵が漏えいすれば、それを使った暗号化・署名すべての信頼性が失われるため、保管の管理策が特に重要。

あるSaaS企業のセキュリティ担当者が、自社サービスで長年使ってきた暗号方式の棚卸しを行う場面を想定しましょう。まず利用者のパスワードを保管する仕組みを確認したところ、古いハッシュ関数を使っていたものの、平文で保存せずハッシュ値として保管しており、万一データベースが漏えいしてもパスワード自体は直接読み取れない設計になっていたことが分かります。しかし利用しているハッシュ関数を調査すると、近年の研究で衝突（異なる入力から同じハッシュ値が生成される事象）が発見され、新規利用が推奨されなくなっている方式であることが判明しました。これは典型的な暗号の危殆化であり、「導入時には安全だった」という理由だけで放置してよいものではありません。担当者は現行の推奨方式へ移行する計画を立て、影響範囲（既存利用者のパスワード再ハッシュ化のタイミング等）を含めて経営層に報告します。次に、APIキーや署名用の秘密鍵の管理状況を確認したところ、開発者の個人PC上に暗号化されないまま長期間保管されている秘密鍵が見つかり、鍵管理のライフサイクルのうち保管の工程に重大な不備があることが分かりました。秘密鍵が漏えいすれば、その鍵で行われた署名・暗号化すべての信頼性が損なわれるため、担当者はHSMまたは専用のシークレット管理サービスへ移行し、加えて定期的な鍵の更新（ローテーション）を運用ルール化します。このように、暗号方式そのものの強度だけでなく、「危殆化に追随して更新し続けているか」「鍵を安全に保管・廃棄するプロセスがあるか」という運用面の管理が、実務上の暗号技術の要点です。

1.4.3この節のまとめ

• 共通鍵=高速だが鍵配送問題／公開鍵=鍵配送問題を解消するが低速。実務はハイブリッド暗号
• 暗号の危殆化＝時間経過で古い方式が解読可能になる現象。継続的な把握と更新が管理者の責任
• 鍵管理のライフサイクル＝生成→保管→更新→廃棄。秘密鍵の漏えいは全信頼性の喪失につながる