公開鍵暗号とは？RSA・ECCの仕組みとSSL/TLSでの活用をわかりやすく解説

「SSL/TLSで暗号化しているらしいけど、なぜ公開鍵を誰に見せても安全なの？」
「RSAとECCって何が違うの？どちらを選べばいい？」

こんな疑問を抱えながら、「なんとなく分かったふり」をしてきた方は少なくないと思います。公開鍵暗号はHTTPS通信、SSH接続、電子署名など、現代のセキュリティインフラのあらゆる場面で使われています。仕組みを正しく理解することで、証明書の設定ミスや弱い暗号の見落としを防げるようになります。

この記事では、公開鍵暗号の基本概念からRSA・ECCの仕組みの違い、実際のSSL/TLSハンドシェイクでの使われ方まで、現場で使えるレベルで解説します。OpenSSLコマンドも交えながら、今日から確認できる実践的な内容でお届けします。

公開鍵暗号とは？（概要・なぜ重要か）

公開鍵暗号（Public Key Cryptography）とは、暗号化と復号に異なる2つの鍵を使う暗号方式です。

・公開鍵（Public Key）: 誰に見せても構わない鍵。相手がこの鍵でデータを暗号化する
・秘密鍵（Private Key）: 自分だけが厳重に保管する鍵。公開鍵で暗号化されたデータはこの鍵でのみ復号できる

「公開鍵を公開しても安全なの？」と思うかもしれません。答えは「数学的に一方向の関数」を使っているからです。暗号化（公開鍵を使う方向）は誰でも簡単にできますが、逆方向（秘密鍵なしに復号）は現代のコンピュータでも現実的な時間内に解くことが不可能な問題に依存しています。

共通鍵暗号との違い：鍵配送問題を解決した革命

AES等の共通鍵暗号は高速ですが「同じ鍵を安全に相手に渡す手段」が必要です。これを「鍵配送問題」と呼びます。インターネット上で初対面の相手に安全に鍵を渡すことはできません。

公開鍵暗号はこの問題をそもそも回避します。相手の公開鍵（誰でも入手可能）でデータを暗号化すれば、対応する秘密鍵を持つ相手だけが復号できます。安全な事前の鍵共有が不要になるのです。

実際のHTTPS通信では、公開鍵暗号で共通鍵を安全に交換し、以降の通信はAES等の高速な共通鍵暗号で行うというハイブリッド方式が使われています。

RSAの仕組み（素因数分解の困難さを利用する）

RSA（Rivest–Shamir–Adleman）は1977年に発明された、最もよく知られた公開鍵暗号方式です。

RSAのセキュリティの根拠

RSAの安全性は「大きな数の素因数分解が計算困難である」という数学的事実に依存しています。

・2つの大きな素数 p と q を掛けて N = p × q を作るのは一瞬
・しかし N だけを見せられて p と q を求めるのは、数百桁の数では現代のコンピュータでも何兆年もかかる

この非対称性を利用して、N（公開情報）と p, q の知識（秘密）から公開鍵・秘密鍵のペアを生成します。

OpenSSLでRSA鍵を生成する

# 2048ビットのRSA秘密鍵を生成
openssl genrsa -out private.pem 2048

# 秘密鍵から公開鍵を抽出
openssl rsa -in private.pem -pubout -out public.pem

# 鍵の詳細情報を確認（鍵長・モジュラス等）
openssl rsa -in private.pem -text -noout | head -20

# 公開鍵の確認
openssl rsa -in public.pem -pubin -text -noout

RSA鍵長の目安

RSAの弱点は処理が重いことです。大きなデータをRSAで直接暗号化するのは非効率で、実際のTLS通信でも「AES等の共通鍵をRSAで暗号化して渡す」という役割分担をしています。

ECCの仕組み（楕円曲線暗号）

ECC（Elliptic Curve Cryptography、楕円曲線暗号）はRSAより短い鍵長で同等以上の安全性を実現する、より新しい公開鍵暗号方式です。

ECCのセキュリティの根拠

ECCは「楕円曲線上の点の加算演算」という数学的構造を利用します。楕円曲線上の点Pをk回加算した点Qを求めること（P × k = Q）は簡単ですが、その逆、つまりPとQから整数kを求めることは計算困難です。これを「楕円曲線離散対数問題」と呼びます。

RSAの「素因数分解の困難さ」より数学的に強固で、短い鍵長でより高い安全性を実現できます。

RSAとECCの比較

代表的な楕円曲線

・P-256（secp256r1）: NISTが推奨する標準曲線。TLS証明書で最も広く使われている
・Curve25519: 設計がシンプルで高速・安全性が高いと評価される。WireGuardやOpenSSHの最新版で採用
・P-384（secp384r1）: P-256よりさらに高いセキュリティマージンが必要な場面に

# ECC（P-256）秘密鍵を生成
openssl ecparam -name prime256v1 -genkey -noout -out ec-private.pem

# 公開鍵を抽出
openssl ec -in ec-private.pem -pubout -out ec-public.pem

# 利用可能な曲線一覧を確認
openssl ecparam -list_curves | grep -E "prime256|384|25519"

# 鍵の詳細確認
openssl ec -in ec-private.pem -text -noout

SSL/TLSでの活用（TLSハンドシェイクの実際）

ブラウザで「https://」に接続するとき、バックグラウンドでは公開鍵暗号を使った精巧な鍵交換が行われています。

TLS 1.3ハンドシェイクの流れ

公開鍵暗号がTLSで果たす2つの役割

・サーバー認証: 証明書に含まれる公開鍵と、CAによるデジタル署名を検証することで「本物のサーバーか」を確認する。なりすましサーバーへの誘導を防ぐ根幹
・前方秘匿性（PFS）の担保: ECDHEでは通信ごとに一時的な鍵ペアを生成するため、仮に秘密鍵が後日漏洩しても過去の通信は解読できない

TLS 1.3では前方秘匿性が必須となっており、RSAによる直接の鍵交換（旧来のRSA Key Exchange）は廃止されています。これはセキュリティ上の大きな前進です。

TLS証明書と認証局（CA）の信頼チェーンについては、PKI（公開鍵基盤）とは？で詳しく解説しています。

# サーバーのTLS証明書情報を確認（鍵アルゴリズム・有効期限）
openssl s_client -connect www.example.com:443 -brief 2>/dev/null | \
  openssl x509 -noout -text | grep -E "Subject:|Issuer:|Not (Before|After)|Public Key Algorithm"

# 暗号スイートの確認（どの曲線が使われているか）
openssl s_client -connect www.example.com:443 2>/dev/null | grep -E "Cipher|Curve"

具体的な防御手順

1. 使用中の証明書の鍵強度を確認する

自社サーバーや管理下のWebサービスで、RSA 1024ビット等の弱い鍵が使われていないか確認します。

# 証明書ファイルの公開鍵情報確認
openssl x509 -in server.crt -noout -text | grep -A3 "Public Key Algorithm"

# 鍵長が2048ビット以上か確認（RSAの場合）
openssl x509 -in server.crt -noout -text | grep "Public-Key:"

# RSA 1024ビットの証明書を検出（危険なので要更新）
openssl x509 -in server.crt -noout -text | grep -E "Public-Key: .1024"

2. Webサーバーで弱い暗号スイートを無効化する

古いRSA鍵交換（PKCS#1 v1.5）や、DH 1024ビット等の弱い鍵交換を無効化します。

# /etc/nginx/nginx.conf の例
# TLS 1.3 + 1.2のみ許可（1.0・1.1は廃止）
ssl_protocols TLSv1.3 TLSv1.2;

# TLS 1.2用の安全な暗号スイートのみ許可（ECDHEを優先）
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

# DH鍵交換のパラメータを強化（2048ビット以上）
# openssl dhparam -out /etc/nginx/dhparam.pem 2048
ssl_dhparam /etc/nginx/dhparam.pem;

3. SSH鍵をECCに移行する

SSH接続で使うクライアント鍵も、RSA 1024ビット等の古い鍵は新しいECCベースの鍵に移行しましょう。

# Ed25519（Curve25519ベース）の鍵を生成（推奨）
ssh-keygen -t ed25519 -C "your_email@example.com"

# ECDSA P-256の鍵を生成
ssh-keygen -t ecdsa -b 256

# 既存の鍵のタイプを確認
ssh-keygen -l -f ~/.ssh/id_rsa
# RSA 1024ビットが表示されたら要更新

LinuxサーバーのSSH設定全般については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

中小企業でも今日からできること

公開鍵暗号の概念は複雑に見えますが、実際に情シスが確認すべきことはシンプルです。

・自社Webサイトの証明書確認: ブラウザの鍵マークをクリックして証明書情報を確認。RSAなら2048ビット以上、ECCなら256ビット以上が目安
・TLS 1.0・1.1の無効化: 古いTLSは弱い暗号を許してしまう。SSLLabsのSSL Server Test（無料）でサーバーをスキャンし、Aグレードになるよう設定を修正する
・秘密鍵のパーミッション確認: Linuxサーバーで ls -la /etc/ssl/private/ を実行し、.pem/.keyファイルが 600（所有者のみ読み書き）になっているか確認する
・Let’s Encrypt証明書の自動更新: certbotを導入して90日更新を自動化。手動更新では期限切れが起きやすく、証明書エラーでサイトが閲覧不能になるリスクがある
・VPNをECC対応に: WireGuardはECCベース（Curve25519）で高速かつ安全。OpenVPNを使っている場合は暗号スイートの設定を見直す

よくある誤解と注意点

「公開鍵で暗号化したものを公開鍵で復号できる」→ 誤り

公開鍵で暗号化したデータは秘密鍵でのみ復号できます。逆に、秘密鍵でデジタル署名を作成し、公開鍵で検証します。暗号化と署名は方向が逆になります。この混同が設計ミスの原因になることがあります。デジタル署名の仕組みはデジタル署名とは？で詳しく解説しています。

「鍵が長いほど常に安全で正解」→ 一概に言えない

RSA 4096ビットは理論上安全ですが、TLSハンドシェイクごとに重い計算が発生し、高負荷サーバーではパフォーマンス問題を引き起こすことがあります。ECC P-256の方が同等以上の安全性を高速に実現できる場面が多く、現在の主流です。

「量子コンピュータで今すぐ全部解読される」→ 現時点では過大評価

現在の量子コンピュータはRSAを実用的に解読できる規模ではありません。ただし2030年代以降を見越した耐量子暗号（PQC、Post-Quantum Cryptography）への移行準備は今から計画しておくべきです。NISTはPQCの標準化を進めており、CRYSTALS-KyberやDilithiumが有力候補となっています。

「自己署名証明書でも公開鍵暗号は使われる」→ 正しいが、信頼性は別の話

暗号化通信そのものはできますが、「その公開鍵が本物の相手のものか」を保証するCA署名がないため、ブラウザ警告が出ます。開発・テスト環境でのみ使用し、本番には認証局（CA）が署名した証明書を使いましょう。

本記事のまとめ

公開鍵暗号の基礎から実践的な確認手順まで解説しました。要点をまとめます。

今日から試せる確認ポイント3点：

・SSL Server Test: SSLLabsで自社サーバーをスキャンし、A以上を目指す
・証明書の鍵長確認: openssl s_client -connect ドメイン:443 で現在の暗号スイートを確認
・SSH鍵の棚卸し: ssh-keygen -l -f 鍵ファイル で全鍵のタイプと長さを確認。RSA 1024ビットがあれば即更新

公開鍵暗号を理解することで、TLS設定のレビュー、証明書管理、SSH鍵ポリシーの策定など、日常的なセキュリティ業務の質が確実に上がります。「なんとなく暗号化されてる」から「仕組みを理解して適切に設定できる」へのステップアップに、この記事が役立てば幸いです。