【情報セキュリティマネジメント】共通鍵暗号と公開鍵暗号の違い、見分ける軸は「誰の鍵か」｜ハイブリッド暗号・鍵管理・危殆化・ストレージ暗号化

暗号の問題では、「公開鍵と秘密鍵のどちらを使うか」だけを暗記すると、機密性を守る暗号化とデジタル署名を混同しやすくなります。

最初に確認するのは、何を守りたいのかです。

• 内容を第三者に読ませたくない：暗号化による機密性
• 改ざんされていないことを確認したい：ハッシュ、MAC（Message Authentication Code：メッセージ認証符号）、デジタル署名
• メッセージの生成元や署名者を確認したい：MAC、デジタル署名など（公開鍵と所有者の対応確認には証明書を用いる）
• 大量データを効率よく暗号化し、安全に鍵を届けたい：ハイブリッド暗号

この記事では、共通鍵暗号方式、公開鍵暗号方式、AES、RSA暗号、ハイブリッド暗号に加えて、鍵管理、鍵の危殆化、暗号技術の危殆化、ストレージ暗号化までを一本で整理します。

読み終えるころには、事例を見て誰の鍵をどの目的で使うべきかを自分で判断でき、鍵そのものが漏れたのか方式・鍵長が古くなったのかを切り分けられるようになります。整理に使う軸は、目的・鍵の所有者・データ量の三つです。

先に結論：目的・鍵・データ量で方式を選ぶ

機密性を確保する公開鍵暗号の基本関係は、次のとおりです。

送信者が受信者の公開鍵で暗号化し、受信者が自分の秘密鍵で復号する。

大量データでは、共通鍵暗号と公開鍵暗号を組み合わせるハイブリッド暗号が利用されます。SGで扱う代表的な構成では、データ本体を共通鍵で暗号化し、その共通鍵を受信者の公開鍵で保護します。

1．暗号化と復号

暗号化は、読める状態のデータである平文を、鍵と暗号アルゴリズムを使って暗号文へ変換することです。

復号は、対応する鍵を使って暗号文を平文へ戻すことです。

暗号方式の安全性は、アルゴリズム名だけでは決まりません。

• 適切なアルゴリズム
• 十分な鍵長
• 安全な利用モード・設定
• 予測されにくい乱数
• 鍵の生成・保管・更新
• 安全な実装
• 適切な運用

が組み合わさって初めて保護が成立します。

安全性が確認された暗号方式を採用していても、鍵を平文メールで送信したり、誰でも読める場所へ保存したりすれば、暗号化の効果は失われます。

2．共通鍵暗号方式：同じ秘密鍵で暗号化・復号する

共通鍵暗号方式では、送信者と受信者が共有する同じ秘密鍵を、暗号化と復号に使用します。

代表例はAESです。

長所

• 処理が比較的高速
• 大容量ファイルを暗号化しやすい
• 大量の通信データを保護しやすい
• ストレージ暗号化にも利用される

課題

• 通信前に共通鍵を安全に共有する必要がある
• 鍵を知る者は暗号化と復号の双方を行える
• 相手ごとに異なる鍵を使う場合、相手が増えるほど管理する鍵も増える
• 鍵が漏えいすると、その鍵で保護した情報を解読される可能性がある

AES

AESはAdvanced Encryption Standardの略で、代表的な共通鍵暗号方式です。

名称にStandardと付いていても、公開鍵暗号方式ではありません。

AESは共通鍵暗号方式、RSAは公開鍵暗号方式の代表例として区別します。

ただし、「AESを使っている」という事実だけで安全性が保証されるわけではありません。鍵長、利用方法、鍵管理、実装なども適切である必要があります。

3．共通鍵を安全に受け渡す

共通鍵暗号方式では、暗号化する前に、送信者と受信者が同じ鍵を安全に共有する必要があります。

別の電子メールで平文送信しても十分ではない

次の方法は、安全な鍵配送とはいえません。

暗号化ファイルを送った後、同じメール環境から別の電子メールで共通鍵を平文送信する。

メールを二通に分けても、

• 同じメールアカウントが侵害される
• メールボックス全体を閲覧される
• 両方を同じ相手へ誤送信する
• 通信経路・保存環境が同じである

場合には、ファイルと鍵を一緒に取得されます。

異なる連絡手段を使うことが常に無意味なわけではありません。組織が承認した独立性の高い安全な経路を用い、本人確認とアクセス制御を行えば、リスクを低減できる場合があります。

しかし、単に「別メールにした」だけでは、平文送信の問題は解決しません。

鍵のハッシュ値を送っても復元できない

共通鍵のハッシュ値を送信しても、受信者はそこから元の鍵を復元できません。

ハッシュ関数は、入力から固定長の値を求める一方向性の仕組みです。鍵配送の代わりにはなりません。

ハッシュ関数の性質は「ハッシュ関数とメッセージ認証」の記事で扱います。

4．公開鍵暗号方式：公開鍵と秘密鍵の組を使う

公開鍵暗号方式では、数学的に対応する公開鍵と秘密鍵の組を使用します。

• 公開鍵：他者へ配布できる
• 秘密鍵：所有者だけが厳重に管理する

代表例としてRSAがあります。

受信者だけに読ませる基本関係

受信者だけが復号できるようにする場合は、次の順です。

1. 送信者が受信者の公開鍵を入手する
2. 送信者が受信者の公開鍵で暗号化する
3. 受信者が自分の秘密鍵で復号する

秘密鍵を保有する受信者だけが復号できるため、機密性を確保できます。

公開鍵の真正性も確認する

公開鍵は秘密にする必要はありません。

しかし、入手した公開鍵が本当に受信者のものかを確認する必要があります。

攻撃者が自分の公開鍵へすり替えた場合、送信者は攻撃者だけが復号できるように情報を暗号化してしまう可能性があります。

公開鍵と所有者の対応を第三者が証明する仕組みが、デジタル証明書やPKI（Public Key Infrastructure：公開鍵基盤）です。詳しくは「PKIとデジタル証明書」の記事で扱います。

5．暗号化とデジタル署名を混同しない

教材によっては、デジタル署名を「送信者の秘密鍵で暗号化する」と説明する場合がありますが、本教材では機密性を確保する暗号化と区別します。

• 機密性：受信者の公開鍵で暗号化し、受信者の秘密鍵で復号する
• デジタル署名：署名鍵で署名を生成し、検証鍵で検証する

送信者の署名鍵を使う処理は、受信者だけに内容を読ませるための暗号化ではありません。

デジタル署名の詳しい仕組みは「デジタル署名とタイムスタンプ」の記事で扱います。

6．共通鍵暗号と公開鍵暗号の違い

公開鍵暗号方式は、共通鍵暗号方式より計算負荷が大きく、RSAなどでは一度に処理できるデータの長さにも制限があります。

そのため、大容量ファイルを公開鍵暗号だけで直接処理するのではなく、二つの方式を組み合わせます。

7．ハイブリッド暗号：データ本体と鍵で方式を使い分ける

ハイブリッド暗号は、共通鍵暗号方式の高速性と、公開鍵暗号技術による安全な鍵配送を組み合わせる考え方です。SGでは、受信者の公開鍵で共通鍵を保護する代表的な構成を押さえます。

なお、公開鍵暗号技術には、共通鍵を暗号化して届ける方式のほかに、双方が計算して同じ鍵を得る鍵共有・鍵確立の方式もあります。ただしSGシラバスに用語名の明示はないため、この記事では名称の紹介にとどめます。

基本的な流れ

1. データ本体を暗号化するための共通鍵を用意する
2. 共通鍵でデータ本体を暗号化する
3. その共通鍵を受信者の公開鍵で暗号化・保護する
4. 受信者が自分の秘密鍵で共通鍵を取り出す
5. 取り出した共通鍵でデータ本体を復号する

大きなデータ本体は高速な共通鍵暗号、比較的小さな共通鍵は公開鍵暗号で保護する。

複数の受信者へ送る場合

同じ暗号化ファイルを複数の受信者へ渡す場合は、データ本体を暗号化した共通鍵のコピーを、各受信者の公開鍵でそれぞれ保護できます。

• データ本体を何度も暗号化し直す必要はない
• 各受信者は自分の秘密鍵で共通鍵を取り出す
• 受信者同士で秘密鍵を共有しない
• 各公開鍵が本当に受信者のものか確認する

よくある誤り

問題では、誰の公開鍵を使ったかを必ず確認します。

8．鍵管理：生成から廃棄までのライフサイクル

暗号鍵管理は、鍵を安全な場所へ保存することだけではありません。

鍵の用途・所有者・有効期間を含め、ライフサイクル全体を管理します。

代表的な管理項目

1. 安全な方法による鍵の生成
2. 鍵の所有者・用途・対象システムの登録
3. 安全な配布・共有
4. アクセスを制限した保管
5. 許可された目的での利用
6. 有効期間に応じた更新・ローテーション
7. 必要に応じたバックアップ・復旧
8. 漏えい、退職、用途終了などに伴う失効・利用停止
9. 復元できない方法による廃棄
10. 操作記録、棚卸し、監査

鍵の種類によって管理方法は異なる

全ての鍵を同じ方法でバックアップ・復旧するわけではありません。

例えば、長期保存データを復号する暗号化鍵では、災害・障害に備えたバックアップや復旧手段が必要になる場合があります。

一方、デジタル署名用の秘密鍵を第三者が容易に復旧・利用できるようにすると、「本人だけが署名できる」という前提を損なう可能性があります。

次を踏まえて管理方法を決めます。

• 鍵の用途
• 保護する情報の重要度
• 利用期間・保存期間
• 復旧の必要性
• 不正利用時の影響
• 法令・契約・組織規程

9．鍵の危殆化：鍵そのものが安全でなくなる

鍵の危殆化は、共通鍵又は秘密鍵が、漏えい、盗難、不正利用などによって安全ではなくなった状態です。

漏えいが確定していなくても、合理的な疑いがある場合には利用停止を検討します。

署名用秘密鍵が危殆化した場合の例

1. 該当秘密鍵の利用を停止する
2. 証明書で公開鍵と所有者を対応付けている場合は、対応する証明書の失効を依頼する
3. 不正利用の有無と影響範囲を調査する
4. 安全な環境で新しい鍵ペアを生成する
5. 証明書を利用している場合は、新しい証明書へ移行する
6. 関係者へ必要な通知を行う

パスワードを変更しても、秘密鍵ファイルそのものが漏えいしていれば解決しません。

共通鍵・暗号化鍵が危殆化した場合

• 該当鍵の利用を停止する
• 新しい鍵へ更新する
• 影響を受けるデータ・通信・利用者を特定する
• 必要に応じて既存データを新しい鍵で再保護する
• 漏えい原因を除去する
• 不正な復号・持出しの有無を調査する

鍵を更新するだけでなく、旧鍵によって保護されていた情報の影響も確認します。

10．暗号技術の危殆化：方式・鍵長の安全性が低下する

SGシラバスでは「危殆化」が用語例として示されています。本記事では学習上、鍵そのものの漏えい等による危殆化と、暗号方式・鍵長の安全性低下を切り分けます。

暗号方式・鍵長の安全性低下は、計算能力の向上、解析技術の進展、新しい攻撃手法などによって生じます。鍵そのものが漏えいした場合とは、原因と対応が異なります。

CRYPTREC暗号リストを確認する

組織は、CRYPTREC暗号リスト、暗号強度要件、製品提供者や公的機関の情報などを継続的に確認します。

CRYPTREC暗号リストは、2026年3月30日に更新されています。

リストへアルゴリズム名が掲載されていても、どの鍵長・設定でも安全という意味ではありません。利用期間と必要なセキュリティ強度に応じて、適切なアルゴリズムと鍵長を選択します。

推奨方式への移行

安全性低下が判明してから初めて利用箇所を調査すると、移行に時間がかかります。

平常時から次を把握します。

• 使用中の暗号方式・鍵長
• 利用しているシステム・製品
• 保護対象の情報
• 情報の保存期間
• 鍵・証明書の有効期間
• 代替方式への切替方法
• 取引先・委託先との互換性

特定方式へ固定せず、必要に応じて方式・鍵長を変更できる設計と移行計画を準備します。

鍵の変更頻度を上げるだけでは解決しない

安全性が低下した方式又は短い鍵長を使い続けたまま、鍵だけを頻繁に変更しても、方式自体の弱点は解消しません。

既存データをどうするか

新規データだけを新方式で暗号化し、既存データを旧方式のまま残すと、保存期間の長い機密情報が将来解読される可能性があります。

ただし、全ての既存データを必ず直ちに再暗号化するとは限りません。

次を踏まえて、再暗号化・再保護の優先度を判断します。

• 情報の重要性
• 機密性を維持する必要がある期間
• 旧方式の安全性低下の程度
• 攻撃者が暗号文を既に取得している可能性
• 再保護に必要な費用・停止時間
• 法令・契約上の要求

11．ストレージ暗号化：保存中のデータを守る

ストレージ暗号化は、ディスク、SSD、記憶装置などに保存されたデータを暗号化する対策です。

装置全体又はボリューム全体を対象にする方式は、全ディスク暗号化と呼ばれることがあります。

現行SGシラバスでは「ストレージ暗号化」が用語例として明示されています。全ディスク暗号化は、その具体的な形として理解します。

効果を発揮する場面

• 電源を切った端末を紛失・盗難された
• 暗号化ボリュームが未解錠の状態で記憶装置を取り外された
• 廃棄・修理時に記憶装置を直接読み取られようとした
• 認証を経ず、別の装置から保存データを読み取られようとした

ストレージ暗号化は、主に保存中のデータ、すなわちデータ・アット・レストを保護します。

自動的には防げない場面

ストレージ暗号化は、端末の全ての情報漏えいを防ぐ万能策ではありません。

12．ファイル暗号化との違い

ファイル暗号化は、特定のファイル又はフォルダ単位で暗号化します。

ファイル暗号化の特徴

• 外部へ渡す特定ファイルを保護しやすい
• 保護対象を限定できる
• ファイルごとに鍵・権限を分けられる場合がある
• 鍵又はパスワードの受渡し・保管が必要になる

ストレージ暗号化の特徴

• 記憶装置へ保存されるデータを広く保護する
• 端末紛失・盗難時のオフライン読出し対策に有効
• 利用者がログインして正規に復号された後の操作は別途保護する必要がある

両者は排他的ではなく、情報の重要性と利用場面に応じて組み合わせます。

13．科目Bでの使われ方

科目Bでは、暗号アルゴリズムの仕組みそのものではなく、業務場面での対応が妥当かを判断する材料として使われます。

事例文に次の言葉が出てきたら、この記事の内容が判断材料になります。

担当者としては、まず該当する鍵の利用を停止し、上位者や関係部署へ連絡して指示を仰ぎます。影響範囲の調査、証明書の失効依頼、関係者への通知は、その指示の下で優先順位を付けて進めます。委託先が保有する鍵や契約条件に関わる場合は、契約担当者と協力して対応します。

14．暗号の事例を読む手順

暗号の事例では、次の順に確認します。

1. 何を守りたいか

機密性、完全性、真正性のどれかを確認します。

1. 暗号化する対象は大きなデータか、小さな鍵か

大量データは共通鍵、鍵配送は公開鍵暗号を中心に考えます。

1. 誰の鍵を使っているか

機密性なら、受信者の公開鍵で暗号化し、受信者の秘密鍵で復号します。

1. 公開鍵が本当に受信者のものか

公開鍵の真正性を証明する仕組みはPKI・証明書です。

1. 鍵そのものが漏えいしたのか、方式・鍵長が古くなったのか

鍵の危殆化と暗号技術の危殆化を区別します。

1. 保存中のデータか、ログイン後の操作か

ストレージ暗号化の効果範囲を確認します。

1. 安全な鍵配送になっているか

平文の別メールや、復元できないハッシュ値を鍵配送として扱っていないか確認します。

よくある取り違え

まとめ

• 暗号方式を選ぶ前に、機密性・完全性・真正性のどれを守るか確認する
• 共通鍵暗号方式は、暗号化と復号に同じ秘密鍵を使う
• 共通鍵暗号方式は比較的高速で、大量データの暗号化に適する
• AESは共通鍵暗号方式の代表例
• 共通鍵暗号の課題は、鍵の安全な受渡し・保管・更新
• 別の電子メールで共通鍵を平文送信するだけでは、安全な鍵配送にならない
• ハッシュ値から元の共通鍵は復元できない
• 公開鍵暗号方式は、公開鍵と秘密鍵の組を使用する
• RSAは公開鍵暗号方式の代表例
• 機密性を確保する場合、受信者の公開鍵で暗号化し、受信者の秘密鍵で復号する
• 公開鍵は秘密ではないが、本当に受信者のものか確認する必要がある
• デジタル署名は、秘密鍵で文書を暗号化する仕組みとして説明しない
• ハイブリッド暗号は、データ本体を共通鍵で暗号化し、その共通鍵を受信者の公開鍵で保護する
• 鍵管理は、生成、登録、配布、保管、利用、更新、バックアップ、失効、廃棄、監査までを含む
• 鍵の危殆化と、暗号技術の危殆化（方式・鍵長の安全性低下）を区別する
• 鍵の危殆化には利用停止・失効・新しい鍵への移行・影響調査を行う
• 方式・鍵長の危殆化には、推奨方式への計画的移行と必要なデータの再保護を行う
• CRYPTREC暗号リストと暗号強度要件を継続的に確認する
• ストレージ暗号化は保存中のデータを保護するが、ログイン後の不正操作まで自動的に防ぐものではない
• 科目Bでは、目的、データ量、鍵の所有者、危殆化の種類、暗号化の効果範囲を順に確認する

関連記事

• C2-T03：ハッシュ関数とメッセージ認証
• C2-T04：デジタル署名とタイムスタンプ
• C2-T05：PKIとデジタル証明書
• C2-T06：利用者認証の3要素と生体認証
• C2-T07：認証方式の仕組み
• C5-T10：データ保護とバックアップ
• C5-T11：セキュアプロトコルと実装技術
• C8-T06：通信・電子取引に関する法律

本記事は、2026年8月3日時点のSGシラバスVer.4.1を基準に作成しています。

参考資料

• IPA「情報セキュリティマネジメント試験（レベル2）シラバス Ver.4.1」
• CRYPTREC「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）CRYPTREC LS-0001-2022R2」
• CRYPTREC「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」
• IPA「暗号鍵管理システム設計指針（基本編）第1.1版」
• IPA「暗号鍵管理ガイダンス Part 1 第1.1版」
• IPA「暗号鍵管理ガイダンス Part 2 第1版」
• NIST SP 800-57 Part 1 Rev.5「Recommendation for Key Management: Part 1 – General」

関連する問題

• 情報セキュリティマネジメント 暗号・認証・PKI 択一式（応用） 第1問〜第5問
• 情報セキュリティマネジメント 暗号・認証・PKI 択一式（応用） 第6問〜第10問
• 情報セキュリティマネジメント 暗号・認証・PKI 一問一答 第1問〜第5問
• 情報セキュリティマネジメント 暗号・認証・PKI 一問一答 第6問〜第10問
• 情報セキュリティマネジメント 暗号・認証・PKI 一問一答 第21問〜第25問

---