【解説】公開鍵、秘密鍵、共通鍵とは何か分かりやすく解説します

はじめに

インターネットでのやり取りは、見知らぬ相手や経路を経て届きます。もし内容が途中で盗み見られたり、改ざんされたら困ります。そこで登場するのが「鍵」と「暗号」です。

本記事では、暗号の基本である共通鍵、公開鍵、そしてそれと対になる秘密鍵について、専門用語をできるだけ避けながら丁寧に解説します。

動画編集の素材共有やクラウドでのやり取りなど、日常的なケースを想定しながら理解できる構成にしています。

暗号の基礎イメージ

暗号は、読める文章を特別な手順で読めない形に変える技術です。その特別な手順を実行するために使う短いデータが「鍵」です。鍵を知っている人だけが元の内容に戻せます。

鍵は大きく二種類あります。

送る側と受け取る側が同じ鍵を共有する方式が「共通鍵暗号」。

片方は公開しても良い鍵、片方は自分だけが持つ鍵に分かれている方式が「公開鍵暗号」で、その非公開の鍵を「秘密鍵」と呼びます。

共通鍵暗号とは

共通鍵暗号は、同じ鍵で暗号化と復号を行います。イメージとしては、同じ合鍵を持つ人たちだけが開け閉めできる金庫です。鍵そのものは比較的短く、処理が高速で、大量のデータの暗号化に向いています。

代表的なアルゴリズム

代表例はAESやChaCha20などです。どちらも、動画や写真のような大きなファイルを素早く安全に暗号化できます。AESは多くのハードウェアで高速化され、ChaCha20はモバイル環境での安定した速度が特長です。

メリットとデメリット

メリット

1. とても速いので大容量データに向いています
2. 実装がこなれており、広く使われています

デメリット

1. 事前に鍵を安全に共有する手段が必要です
2. 鍵が漏れたら、やり取りした双方のデータがすべて読まれてしまいます

具体例

社内で共有サーバーに置くファイルを暗号化したいとき、あらかじめ決めた共通鍵でまとめて暗号化する、といった使い方が考えられます。ストレージ暗号化やVPN内部のトンネルの暗号も、内部では共通鍵が主役です。

公開鍵暗号とは

公開鍵暗号では、鍵が二本ワンセットになっています。誰に見られても構わない「公開鍵」と、自分だけが厳重に守る「秘密鍵」です。公開鍵で暗号化したデータは、対応する秘密鍵でしか復号できません。逆に、秘密鍵で作った「署名」は、公開鍵で正当性を確認できます。

代表的なアルゴリズム

代表例はRSA、楕円曲線暗号（ECC）、ElGamalなどです。最近の実務では鍵長が短くても強度を確保しやすいECCが広く利用され、曲線としてはsecp256r1やEd25519がよく登場します。

メリットとデメリット

メリット

1. 鍵の事前共有が不要です。相手の公開鍵を入手できれば暗号化を始められます
2. 署名によって「なりすまし防止」や「改ざん検知」が可能です

デメリット

1. 計算コストが高く、大きなデータの暗号化には向きません
2. 公開鍵が本当に相手のものか確認する仕組みが必要です

具体例

メールの暗号化で知られるOpenPGPや、サーバーに安全に入るためのSSH、そしてWebのHTTPSの入り口（ハンドシェイク）で使われています。例えばSSHでは、サーバー側は公開鍵を配布し、クライアントはそれに基づいて安全な接続を開始します。

秘密鍵とは

秘密鍵は、公開鍵暗号の二本のうちの非公開側の鍵です。これが漏れると、受け取った暗号文を第三者に解かれたり、あなたになりすまして署名を作られたりします。取り扱いは最重要事項であり、次のポイントを守るのが基本です。

秘密鍵の守り方

1. 端末の安全な領域に保存する。可能であればスマートカードやセキュアエレメント、ハードウェアセキュリティキーを使います
2. 強いパスフレーズで保護し、二要素認証と組み合わせます
3. バックアップは暗号化して別の安全な場所へ。紛失時のリカバリー手順も用意します
4. 不要になったら安全に破棄します

鍵交換の課題と解決

共通鍵は速い反面、鍵をどうやって安全に渡すかが課題です。ここで公開鍵暗号が活躍します。まず公開鍵暗号で、共通鍵を相手に安全に届けます。その後の大量データは共通鍵で素早く暗号化する。この組み合わせを「ハイブリッド暗号」と呼び、現代の通信の定番です。

Diffie–HellmanとECDH

Diffie–Hellmanは、事前に秘密を共有しなくても、通信の中で安全に共通鍵を合意する方法です。楕円曲線版のECDHは、同じ考え方を軽量に実現します。これらは盗聴されていても、途中で得られる情報から鍵を再現できない設計になっています。

デジタル署名の役割

暗号化が「読めなくする技術」だとすると、署名は「確かにこの人が作ったと示す技術」です。送信者は秘密鍵でデータに署名し、受信者は公開鍵で検証します。改ざんがあれば検証は失敗しますし、秘密鍵の持ち主でなければ正しい署名を作れません。

証明書と認証局

公開鍵が本当に相手のものかは重要な論点です。ここで登場するのが証明書と認証局です。認証局は、申請者を審査して「この公開鍵は確かにこの組織のもの」と証明する電子的な書類を発行します。ブラウザやOSは信頼できる認証局の一覧を持ち、証明書の有効性を自動で確認します。これにより、偽サイトになりすますのが難しくなっています。

HTTPSの流れをやさしく

1. ブラウザがサーバーに接続し、サーバーは証明書と公開鍵を見せます
2. ブラウザは証明書を確認し、正当な相手かどうかを判断します
3. 問題なければ、ブラウザは共通鍵（またはその素材）をサーバーの公開鍵で安全に共有します
4. 以後のやり取りは高速な共通鍵暗号で保護されます
5. 必要に応じて、サーバーやクライアントは署名で相手の正当性を示します

この仕組みにより、動画のアップロードやダウンロード、決済情報の入力などが第三者に盗み見られにくくなっています。

どれをいつ使うべきか

目的別にざっくり整理すると次の通りです。

1. 大きなデータを素早く守りたい場合は共通鍵暗号
2. 相手に安全に鍵を渡したい、あるいは署名したい場合は公開鍵暗号
3. 実務では両者を組み合わせるのが普通

例として、クラウド共有リンクにパスワードを付けて送るとき、事前に安全なルートでパスワードを伝えられないなら、相手の公開鍵で共通鍵を包んで送る方法が考えられます。

よくある誤解の整理

1. 公開鍵は秘密にすべきだという誤解
   公開鍵は配ってこそ意味があります。秘密にするのは秘密鍵です
2. パスワードと鍵は同じだという誤解
   パスワードは人が覚える文字列で、鍵は計算機が扱うバイナリデータです。役割も強度も異なります
3. 長い鍵なら絶対安全だという誤解
   鍵長は重要ですが、実装の不備や乱数の弱さ、端末の乗っ取りなど他の要因でも破られます
4. 署名は暗号化と同じだという誤解
   署名は内容を隠しません。改ざん検知となりすまし防止が主目的です

安全に使うための実践ポイント

1. 更新を怠らない。OSやブラウザ、ライブラリを最新に保ちます
2. 鍵の期限を決め、定期的にローテーションします
3. 乱数生成器は信頼できる方法を選びます
4. 二要素認証やハードウェアトークンで秘密鍵へのアクセスを強化します
5. バックアップ鍵の所在を最小限の関係者だけが知るようにします
6. 共有は最小権限で。必要な相手にだけ公開鍵や共通鍵を渡します

暗号化、認証、完全性の違い

暗号の目的は三つに整理できます。機密性は「第三者に読まれないこと」。認証は「相手が誰かを確かめること」。完全性は「途中で改ざんされていないこと」。共通鍵と公開鍵は、これらを役割分担しながら実現します。共通鍵は高速な機密性に優れ、公開鍵は認証や鍵配布に強みがあり、完全性は署名やメッセージ認証コードで担保します。

AEADとタグの考え方

現在主流のAES-GCMやChaCha20-Poly1305は、暗号化と改ざん検知を一体化したAEAD方式です。暗号文には「タグ」と呼ばれる短い値が付き、受信側はタグ検証に失敗した時点でデータを破棄します。安全に使うには、同じ鍵と初期化ベクトルを二度使わないこと、検証に失敗したデータを絶対に処理しないことが重要です。

初期化ベクトルとノンス

同じ鍵を使い続けても安全性を保つために、毎回異なる初期値（ノンス）を使います。ノンスは秘密である必要はなく暗号文と一緒に送れますが、使い回しは厳禁です。生成はライブラリに任せ、長さと品質を確保してください。

前方秘匿性という安心

前方秘匿性は、将来秘密鍵が漏れても過去の通信が解読されにくい性質です。TLS 1.3はECDHEなどの一時鍵交換を標準化し、この性質を確保します。設計では「長期鍵が漏れても被害を最小化できるか」を常に意識しましょう。

証明書の失効とピン留め

証明書は途中で無効化されることがあり、OCSPやCRLで失効が配布されます。モバイルアプリでは特定の公開鍵を許可するピン留めを使う場合がありますが、更新計画がないピン留めは接続不能の原因になります。ロールオーバー手順を必ず用意してください。

鍵長の目安

共通鍵はAESなら128ビット以上、長期保護が必要なら256ビット。RSAは2048ビット以上、余裕を見て3072ビットも選択肢です。ECCは256ビット級が主流で、署名用途のEd25519は扱いやすさと性能で人気があります。数字だけで決めず、互換性と性能のバランスを見極めてください。

量子計算時代への備え

量子計算が実用化すると一部の公開鍵方式が弱くなる可能性があります。まずは資産棚卸しを行い、どのシステムでどの鍵と証明書が使われ、どの程度の耐用年数が求められるかを把握しておくと、将来の移行が容易になります。

公開鍵を安全に受け取るには

PKIの証明書で正当性を確認する方法が王道です。個人間では、公開鍵の指紋（ハッシュ値）を別経路で確認したり、名刺やQRコードに指紋を載せて対面で照合する方法が現実的です。複数の独立した経路で確かめるほど安心度は高まります。

設計や運用で起きやすい落とし穴

1. 同じノンスを再利用する
2. 鍵をメール本文で送ってしまう
3. 設定ファイルに鍵やパスフレーズを書いてしまう
4. 自己署名証明書を本番で使い、警告無視を前提にする
5. バックアップの暗号化や復旧テストを忘れる
6. 開発用のテスト鍵を本番へ持ち込む

実務導入のロードマップ

1. 目的の明確化。どの場面で機密性、認証、完全性が必要かを定義します
2. キー管理方針。生成、配布、保管、ローテーション、失効、監査を文書化します
3. 安全な実装選定。実績あるライブラリと安全な既定値を採用し、定期的に検証します

もう一歩踏み込んだ理解

公開鍵暗号では、暗号化と署名は別の操作です。暗号化は公開鍵で行い、復号は秘密鍵で行います。署名は秘密鍵で行い、検証は公開鍵で行います。

ハイブリッド暗号では、本文は共通鍵で暗号化し、その共通鍵だけを相手の公開鍵で包むのが定石です。これにより速度と安全性を両立できます。

まとめの前の要点チェック

1. 共通鍵は速く、鍵配布が課題
2. 公開鍵は配布と署名に強いが重い
3. 秘密鍵の保護がすべての土台
4. AEADで機密性と完全性を同時に確保
5. 前方秘匿性と失効運用を忘れない

まとめ

共通鍵暗号は速くて大量データ向き、公開鍵暗号は鍵配布や署名に強い。現代の通信は両者を組み合わせて、素早さと安全性を両立させています。

そして、その中心にあるのが秘密鍵の適切な管理です。仕組みを正しく理解し、用途に応じて選択すれば、日々の仕事や生活の中で安全性と利便性を両立できます。

まずは、重要なやり取りに公開鍵基盤を導入し、実際のファイル転送やストレージでは共通鍵を活用する、といったハイブリッドの考え方から始めてみてください。