LASSIC Media らしくメディア
共通鍵暗号と公開鍵暗号の違い｜暗号化の基礎
暗号化とは
システムやアプリケーションでやり取りする情報には、顧客の個人情報や取引データ、認証情報など、第三者に読み取られると困る内容が数多く含まれます。暗号化とは、こうした元のデータ（平文）を特定の「鍵」を使って第三者には意味の分からない形（暗号文）に変換し、正しい鍵を持つ側だけが元の内容に戻す「復号」を行う仕組みのことです。通信経路での盗聴や、保存先からのデータ漏えいが起きた場面でも、内容そのものを読み取られにくくする狙いで使われています。
似た用語にハッシュ関数がありますが、仕組みは別物です。暗号化は鍵を使って暗号文と平文を行き来できる「双方向」の処理であるのに対し、ハッシュ関数はデータを一定長の値へ要約するだけで、その値から元のデータへ戻すことはできません。パスワードの照合にはハッシュ関数、通信内容やファイルの中身を後から読める状態にしておきたい場面には暗号化と、用途がそれぞれ分かれるものです（ハッシュ関数の仕組みは別記事で扱っています）。
暗号化の方式は大きく分けて2種類あります。共通鍵暗号（対称暗号）と公開鍵暗号（非対称暗号）です。両者は鍵の使い方という発想の根本が異なり、実務で使われるTLS／HTTPSの仕組みも、この2方式を組み合わせて成り立っています。本記事では特定のプログラミング言語やOS・製品固有の実装手順ではなく、言語や製品を問わず共通する暗号化方式の考え方と使い分けを整理する内容です。
暗号化の巧拙は、システムの企画・設計段階で決まる部分が大きいと言えます。実装を担当するエンジニアだけでなく、要件を定義する発注者やPMの立場でも、どのような暗号化方式がどのような場面に向いているのかを押さえておくと、要件定義やベンダーとのやり取りで確認すべき論点が見えやすくなるでしょう。
個人情報保護法や業界ごとのガイドラインでも、個人情報や決済情報など機密度の高いデータについて、暗号化を含む適切な管理措置を講じることが求められる場面があります。法令対応そのものは法務・コンプライアンス部門の判断が必要ですが、システム側で「どこを、どの方式で暗号化しているか」を説明できる状態にしておくことは、監査対応や取引先からの問い合わせに答える際の土台になるものです。
B2Bのシステム開発では、自社で開発する機能だけでなく、外部のSaaSやAPIと連携する場面でも暗号化の考え方が顔を出します。連携先の通信がTLSで暗号化されているか、預けるデータが保存時にも暗号化される仕組みかどうかは、ベンダー選定や委託先とのやり取りで事前に確認しておきたい項目の一つでしょう。
共通鍵暗号（対称暗号）
共通鍵暗号は、データを暗号化するときと復号するときに同じ鍵を使う方式です。送信側がその鍵でデータを暗号化し、受信側が同じ鍵を使って元のデータに戻します。代表的なアルゴリズムがAES（Advanced Encryption Standard）で、現在幅広く採用されている標準的な共通鍵暗号方式です。
たとえるなら、同じ合鍵を持つ者同士だけが、同じ鍵で施錠と解錠を行える関係に近いものです。鍵の種類自体は1つで済むためシンプルですが、その1本の鍵が相手に渡るまでの経路や、渡した後の保管状態にリスクが集中する点も、この方式の性質から来ています。
共通鍵暗号の特長は処理の速さです。演算の仕組みが比較的シンプルなため、大量のデータをやり取りする場面や、繰り返し暗号化・復号を行う処理に向いています。データベースに保存する大量のレコードを暗号化する場合や、動画・ファイルなど容量の大きいデータを扱う場合には、共通鍵暗号が選ばれる傾向にあるものです。
一方で課題となるのが「鍵配送」です。暗号化と復号に同じ鍵を使うため、通信を始める前にその鍵を相手と共有しておく必要があります。しかしこの鍵自体を届ける手段が整っていなければ、鍵が途中で第三者の手に渡り、暗号化そのものの意味が失われてしまいます。離れた相手と初めてやり取りする場面では、この鍵配送をどう行うかが実務上の悩みどころになりやすいところです。
共通鍵暗号を検討する際には、鍵の長さ（鍵長）も論点になります。AESでは128ビット・192ビット・256ビットといった鍵長が選べ、鍵長が長いほど総当たりで鍵を割り出す解読の手間は大きくなる一方、暗号化・復号にかかる処理時間はわずかに増える傾向があります。ディスク全体を暗号化する機能やVPN通信の暗号化なども、内部的にはこの共通鍵暗号を土台にしているケースが多く、身近な場面で広く使われている方式です。
公開鍵暗号（非対称暗号）
公開鍵暗号は、共通鍵暗号が抱える鍵配送の課題を解決するために考え出された方式です。「公開鍵」と「秘密鍵」という対になる2つの鍵を使い、公開鍵で暗号化したデータは、対応する秘密鍵でなければ復号できないという性質を持っています。公開鍵は誰に知られても構わない鍵で、秘密鍵は本人だけが保持する鍵です。
たとえるなら、開いたままの南京錠を相手に配っておき、相手はその南京錠で荷物を施錠してから送り返す関係に近いものです。南京錠（公開鍵）は誰に持ち出されても差し支えありませんが、施錠された荷物を開ける鍵（秘密鍵）は、南京錠を配った本人しか持っていません。この構造によって、事前に秘密の鍵をどうにかして届けておくという作業そのものが要らなくなります。
相手に暗号化したデータを送りたい場合、相手の公開鍵を使って暗号化すれば、対応する秘密鍵を持つ本人以外は内容を読み取れません。公開鍵は事前に広く知られていても差し支えないため、秘密の鍵をあらかじめ届けておく手順そのものが不要になります。代表的なアルゴリズムにRSAや楕円曲線暗号（ECC）があり、いずれも数学的な計算の難しさを利用して、秘密鍵なしでは復号に現実的な時間では終わらない設計になっているものです。
公開鍵暗号は暗号化・復号だけでなく、デジタル署名にも使われています。秘密鍵で署名したデータは対応する公開鍵で検証できるため、「その送信者本人が作成したデータであること」や「途中で改ざんされていないこと」を確かめる用途にも応用されているのが特徴です。
課題となるのは処理の重さです。公開鍵暗号は複雑な数学的計算を伴うため、共通鍵暗号に比べて処理に時間がかかります。大量データのやり取りすべてを公開鍵暗号だけでまかなおうとすると、通信や処理の負荷が無視できない水準になりやすい点は留意しておきたいところでしょう。
もう一つ押さえておきたいのが、公開鍵そのものの正当性をどう確かめるかという論点です。公開鍵は誰でも作成でき、誰にでも配布できるからこそ、「この公開鍵は本当にその相手のものか」を裏付ける仕組みが必要になります。この役割を担うのが電子証明書と、証明書を発行する認証局（CA）です。Webサイト向けのTLS証明書も、認証局が発行者の身元を確認したうえで公開鍵に電子署名を付与したもので、ブラウザはこの証明書を検証してから通信を始めます。証明書の期限切れや発行元の不備は、通信そのものより先に信頼性の確認でつまずく典型的な原因です。
使い分けとハイブリッド方式
ここまで見てきた共通鍵暗号と公開鍵暗号は、どちらか一方が優れているという関係ではなく、それぞれ得意な役割が異なります。特徴を整理すると次のとおりです。
| 比較項目 | 共通鍵暗号（対称暗号） | 公開鍵暗号（非対称暗号） |
|---|---|---|
| 鍵の数 | 1つ（暗号化・復号に同じ鍵） | 2つ（公開鍵と秘密鍵のペア） |
| 処理速度 | 速い（大量データ向き） | 遅い（計算負荷が高い） |
| 鍵配送 | 事前共有が必要で難しい | 公開鍵は広く配布してよく容易 |
| 主な用途 | 大量データの暗号化、保存データの暗号化 | 鍵交換、デジタル署名、認証 |
| 代表的なアルゴリズム | AES | RSA、楕円曲線暗号（ECC） |
実務のシステムでは、どちらか一方だけを使うのではなく、双方の長所を組み合わせた「ハイブリッド方式」が広く使われています。代表例が、Webサイトの通信を暗号化するTLS（HTTPSの基盤となる仕組み）です。
TLSの通信では、まず公開鍵暗号を使って、その後のやり取りに使う共通鍵（セッション鍵）を相手と交換します。この鍵交換さえ済めば、以降の実際のデータ送受信は処理の速い共通鍵暗号で行う流れです。公開鍵暗号の「鍵配送を簡潔に済ませられる」という長所と、共通鍵暗号の「処理が速い」という長所を、役割分担によって両立させている仕組みと言えます。
この一連の流れは「TLSハンドシェイク」と呼ばれています。ブラウザとサーバが通信を始める最初の数百ミリ秒の間に、使用するTLSのバージョンや暗号方式のすり合わせ、サーバ証明書の検証、共通鍵の元になる情報の交換までが完了する仕組みです。近年は楕円曲線暗号のように、RSAと同程度の解読の難しさをより短い鍵長で実現できるアルゴリズムの採用も進んでおり、鍵交換にかかる処理負荷を抑える工夫も重ねられています。
鍵長の目安として、RSAの2048ビットと楕円曲線暗号の256ビット前後が近い水準の解読の難しさを持つとされ、後者の方が同水準の解読の難しさをより短い鍵長・より軽い処理で得やすいとされています。外部のAPI連携やモバイルアプリなど、処理性能に制約のある環境でTLS通信を組み込む場合、こうしたアルゴリズムの選択肢が処理速度の実感に影響することもあるため、インフラ担当者だけでなくアプリ側の設計者にとっても押さえておく価値のある論点です。
この役割分担のおかげで、Webブラウザで鍵マークのついたサイトを開くたびに重い公開鍵暗号だけで大量のページデータをやり取りしているわけではありません。最初の鍵交換だけ公開鍵暗号に任せ、その後の実データは共通鍵暗号で高速に処理するという設計が、ふだん意識せずに使っているHTTPS通信の裏側で動いているものです。
実務での関わり
暗号化の考え方は、システムの設計・実装・レビューのさまざまな場面で関わってきます。新規開発の要件定義段階だけでなく、既存システムの保守・改修や、外部サービスとの連携を新たに追加する場面でも、暗号化の方式や範囲を見直す機会は少なくありません。代表的な関わり方を整理すると次のとおりです。
- 通信の暗号化（TLS／HTTPS）：Webサイトやアプリのバックエンド、外部APIとの通信をTLSで暗号化しておくと、通信経路上での盗聴によって内容を読み取られるリスクを下げられます。証明書の有効期限や対応プロトコルのバージョンを定期的に確認しておくことも運用上の実務です。
- 保存データの暗号化（データベース／ディスク）：通信だけでなく、データベースの特定カラムやディスク全体を暗号化しておくと、保存先が不正に持ち出された場合でも中身をそのまま読み取られにくくなります。個人情報や認証情報など機密度の高い項目から優先して対象にする考え方が一般的です。
- 鍵管理の重要性：暗号化方式そのものがどれだけ工夫されていても、鍵が漏れてしまえば暗号化の意味は失われます。鍵をソースコードや設定ファイルに直書きせず、クラウド事業者が提供する鍵管理サービス（KMS）などを使い、鍵のローテーションやアクセス権限を管理する運用が求められます。
- レビューの観点：設計・実装レビューでは、扱うデータの機密度に対して適切な方式・鍵長を選んでいるか、鍵のライフサイクル管理まで設計に含まれているかを確認します。暗号化のアルゴリズム自体を独自に実装せず、広く検証された標準ライブラリを使っているかどうかも、あわせて見ておきたい点でしょう。
- 暗号化の範囲を洗い出す：通信経路・データベース・ファイルストレージ・バックアップ・ログなど、機密情報が存在しうる場所を棚卸ししたうえで、どこまでを暗号化の対象とするかを整理しておくと、対策の抜け漏れを減らせるはずです。バックアップデータやログファイルは、暗号化の対象から漏れやすい代表例と言えます。
特に「独自実装を避ける」という点は見落とされがちなポイントです。暗号のアルゴリズムを自前で書き起こす行為は、たとえ動作しているように見えても、想定していない弱点を含んだままになりやすいもの。言語やフレームワークが提供する標準ライブラリ、あるいは実績のある暗号ライブラリを利用し、実装よりも「どの方式を、どの場面に、どんな鍵長で使うか」という設計判断に力点を置く進め方が実務では堅実でしょう。開発を外部に委託する場合も、この観点は仕様書やレビュー基準に含めておくと、成果物の品質確認がしやすくなります。
まとめ
暗号化とは、平文を鍵によって暗号文へ変換し、正しい鍵を持つ側だけが復号して元に戻す仕組みです。元に戻せない一方向の要約であるハッシュ関数とは異なり、暗号化はあくまで復号を前提とした双方向の処理という点が土台になります。共通鍵暗号は同じ鍵で暗号化・復号を行い処理が速い一方、鍵配送が課題です。公開鍵暗号は公開鍵と秘密鍵のペアで鍵配送の課題を解決しますが、処理は重くなります。実務のシステムでは両者を組み合わせたハイブリッド方式が広く使われており、TLS／HTTPSはその代表例です。
どちらの方式を選ぶかという判断は、扱うデータの性質や通信量、処理性能の制約によって変わるものであり、一律の正解があるわけではありません。方式そのものの理解に加えて、鍵の生成・保管・更新・破棄といったライフサイクルをどう運用するか、暗号化の対象範囲に抜け漏れがないかまで含めて検討することが、暗号化を実効性のあるものにする鍵になるでしょう。
相談するメリット
LASSICでは、通信・保存データの暗号化方式の選定や鍵管理の設計について、ニアショア開発体制を活かした受託支援を行っています。「TLSの設定は済んでいるが保存データの暗号化まで手が回っていない」「鍵管理の運用ルールが担当者任せになっている」といった相談から、既存システムの暗号化方式・鍵長・鍵管理の現状を棚卸しし、標準ライブラリを用いた実装への置き換えまで伴走することも可能です。社内に専任のセキュリティ担当者を置きにくい体制でも、必要な工程だけを切り出して依頼できる点も相談しやすいポイントです。設計段階からの壁打ちだけでなく、実装・テスト・運用ルールの整備までまとめて相談を受け付けています。
よくある質問
共通鍵暗号と公開鍵暗号はどちらを使うべきですか。
方式そのものの優劣というより、役割が異なります。共通鍵暗号は鍵さえ守られていれば機密性を保ちやすく処理も速い一方、鍵配送に難があるのが弱点です。公開鍵暗号は鍵配送の課題を解決できますが処理が重く、単独で大量データをやり取りする用途には向きません。実務のシステムの多くは、鍵交換を公開鍵暗号、実データのやり取りを共通鍵暗号が担うハイブリッド方式を採用し、双方の弱点を補い合っています。
ハッシュと暗号化の違いは何ですか。
暗号化は鍵を使って暗号文と平文を行き来できる双方向の処理で、正しい鍵があれば元のデータに戻せます。一方のハッシュ関数はデータを一定長の値に要約するだけの一方向の処理で、その値から元のデータを復元することはできません。パスワードの照合にはハッシュ関数、通信内容やファイルを後から読める状態にしておく場面には暗号化と、目的によって使い分けるものです。
AESとRSAはどう使い分けますか。
AESは共通鍵暗号の代表的なアルゴリズムで、処理が速く大量データの暗号化に向いています。RSAは公開鍵暗号の代表的なアルゴリズムで、鍵交換やデジタル署名など、鍵配送の課題を解決したい場面で使われるものです。TLSのようなハイブリッド方式では、鍵交換にRSAや楕円曲線暗号、実データの暗号化にAESを組み合わせる構成がよく見られます。
暗号化の実装で気をつけることはありますか。
暗号のアルゴリズム自体を独自に実装するのは避け、言語やフレームワークが提供する標準ライブラリ、または実績のある暗号ライブラリを使うことが基本です。あわせて、鍵をソースコードに直書きせず鍵管理サービスなどで管理すること、扱うデータの機密度に応じた鍵長を選ぶことも欠かせない観点になります。設計・実装のレビューでは、この2点が押さえられているかを確認するとよいでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
暗号化方式や鍵管理のご相談
通信・保存データの暗号化方式の選定や鍵管理の設計・運用について、設計段階からの壁打ちや実装支援が必要な際は、LASSICまでお気軽にお問い合わせください。
