【CISSP演習問題】非対称鍵暗号を完全マスター！機密性・完全性・認証を問う10問【専門家が徹底解説】

正解：2. ボブの公開鍵

【解説】 これは基本中の基本ですが、非常に重要な問題です。 機密性とは、「許可された人だけが情報を閲覧できること」を指します。今回のケースでは、受信者であるボブだけがメッセージを読めるようにしなければなりません。

• ボブの公開鍵で暗号化されたメッセージは、対となるボブの秘密鍵でしか復号できません。
• ボブの秘密鍵を持っているのはボブ本人だけです。
• したがって、アリスがボブの公開鍵でメッセージを暗号化すれば、ボブだけがその内容を読むことができ、機密性が保証されます。

なぜ他の選択肢は間違いか？

• 1. アリスの秘密鍵: アリスの秘密鍵で暗号化（これはデジタル署名に相当）すると、対となるアリスの公開鍵で誰でも復号できてしまうため、機密性は全く保たれません。
• 3. アリスの公開鍵: アリスの公開鍵で暗号化すると、復号できるのはアリスの秘密鍵を持つアリス本人だけです。これではボブはメッセージを読めません。
• 4. ボブの秘密鍵: アリスはそもそもボブの秘密鍵を知り得ませんし、使うこともできません。

正解：2. 完全性と否認防止

【解説】 デジタル署名は、CISSP試験で必ず問われる重要トピックです。デジタル署名は以下の3つを主に保証します。

• 完全性 (Integrity): メッセージが途中で改ざんされていないこと。
• 認証 (Authentication): そのメッセージが確かに本人から送られたものであること。
• 否認防止 (Non-repudiation): 送信者が後から「送っていない」と言い逃れできないこと。

選択肢の中で、これらの要素を最も適切に含んでいるのは「2. 完全性と否認防止」です。（認証も含まれますが、選択肢の組み合わせとして最も適切です）

なぜ他の選択肢は間違いか？

• 1, 3. 機密性: デジタル署名はメッセージを暗号化して隠すものではありません。あくまで「誰が」「何を」送ったかを証明する技術です。機密性が必要な場合は、別途暗号化のプロセスが必要です。
• 1, 4. 可用性: 可用性（システムがいつでも使える状態にあること）は、デジタル署名が直接保証する範囲ではありません。

正解：2. 送信者の公開鍵

【解説】 デジタル署名のプロセスを思い出してみましょう。

1. 送信者: メッセージのハッシュ値を計算し、自身の秘密鍵で署名を作成する。
2. 受信者:
   1. 受け取ったメッセージから、同じハッシュ関数でハッシュ値を計算する。
   2. 署名を送信者の公開鍵で復号し、元のハッシュ値を取り出す。
   3. 1と2のハッシュ値が一致すれば、メッセージは改ざんされておらず（完全性）、確かにその送信者から来たものである（認証）ことが確認できます。

つまり、「送信者の秘密鍵で署名し、送信者の公開鍵で検証する」というペアが鉄則です。

正解：1. 送信者の秘密鍵

【解説】 否認防止とは、「やったことを後からやっていないと否定させない」ことです。 これを実現するためには、「その行為が本人にしかできないこと」を証明する必要があります。

非対称鍵暗号の世界で「本人にしかできないこと」とは、秘密鍵を使うことです。 送信者が自身の秘密鍵でハッシュ値に署名することで、「この秘密鍵を持つ私本人がこのメッセージの内容に同意し、署名しました」という強力な証拠が残ります。これにより、送信者は後から「私は署名していない」と言い逃れることができなくなります。

正解：3. メッセージのハッシュを計算し、アリスの秘密鍵で署名し、その署名と元のメッセージをボブの公開鍵で暗号化する。

【解説】 これは今までの知識を総動員する応用問題です。一つずつ分解して考えましょう。

• 完全性・認証・否認防止の確保
  • → デジタル署名が必要です。
  • → メッセージのハッシュをアリスの秘密鍵で署名します。
• 機密性の確保
  • → メッセージ全体の暗号化が必要です。
  • → 受信者であるボブだけが読めるように、ボブの公開鍵で暗号化します。

この2つのプロセスを組み合わせたのが、正解の選択肢3です。 実務で使われるS/MIMEなどのメールセキュリティ技術も、このハイブリッドなアプローチに基づいています。

正解：3. 認証局（CA）

【解説】 **公開鍵基盤（PKI）は、インターネット上で安全に通信を行うための信頼の仕組みです。その中心的な役割を担うのが認証局（CA: Certificate Authority）**です。

CAは、利用者の身元を確認した上で、その利用者の公開鍵に対してCA自身の秘密鍵でデジタル署名を行います。この署名がなされたものが「デジタル証明書」です。 私たちは、信頼できるCA（ルートCA）を予め信頼しておくことで、そのCAが発行した証明書を信用し、証明書に含まれる公開鍵の持ち主が本人であることを確認できるのです。

• RA (Registration Authority): CAの代わりに本人確認を行う受付窓口のような存在です。
• CRL (Certificate Revocation List): 有効期限切れの前に無効になった証明書のリストです。
• VA (Validation Authority): OCSPなどを使い、証明書の有効性をリアルタイムで確認するサービスを提供します。

正解：2. 証明書を発行したCAのデジタル署名を、信頼されたルートCAの公開鍵まで遡って（チェインして）検証する。

【解説】 WebサイトのSSL/TLS証明書をイメージすると分かりやすいです。 私たちがブラウザでWebサイトにアクセスした際、ブラウザは以下の手順で証明書の正当性を検証しています。

1. Webサーバーから提示された証明書を受け取る。
2. その証明書に署名した中間CAの証明書を辿る。
3. 中間CAの証明書に署名した、さらに上位のルートCAの証明書に辿り着く。
4. このルートCAが、ブラウザ（やOS）に予め信頼できるCAとして登録されているかを確認する。
5. 信頼できるルートCAの公開鍵を使って、下位の証明書の署名を順に検証していく。

この一連の信頼の連鎖を**証明書チェーン（Chain of Trust）**と呼びます。このチェーンを辿り、最終的に信頼の起点（トラストアンカー）であるルートCAにたどり着くことで、証明書の信頼性を確認します。

正解：2. 長いメッセージを、計算負荷の低い固定長のデータに変換するため

【解説】 非対称鍵暗号の演算（署名や暗号化）は、共通鍵暗号に比べて非常に処理が重く、時間がかかります。 もし長文のメッセージ全体に直接デジタル署名を行おうとすると、膨大な計算コストがかかってしまいます。

そこで、まずハッシュ関数を使って、どんなに長いメッセージでも**固定長の短いデータ（ハッシュ値またはメッセージダイジェスト）**に変換します。そして、この短いハッシュ値に対してデジタル署名を行います。 これにより、処理を高速化しつつ、メッセージが1ビットでも変わればハッシュ値が全く異なる値になるという特性を活かして、完全性を担保できるのです。

正解：2. 共通鍵暗号

【解説】 SSL/TLS通信など、現在の暗号通信のほとんどはハイブリッド暗号方式を採用しています。

これは、処理が高速な共通鍵暗号と、安全に鍵交換ができる非対称鍵暗号の「良いとこ取り」をした方式です。

1. まず、通信のたびに使い捨ての**共通鍵（セッションキー）**を生成します。
2. データ本体（Webページのコンテンツなど）は、この高速な共通鍵で暗号化します。
3. そして、この共通鍵自体を、安全な**非対称鍵暗号（受信者の公開鍵）**で暗号化して相手に渡します。

これにより、大容量のデータを効率的に暗号化しつつ、通信経路上で共通鍵が盗聴されるリスクを防ぐことができます。

正解：1. ボブが使用したアリスの公開鍵が古かった、または間違っていた。

【解説】 デジタル署名の検証が失敗する主な原因は、以下の2つです。

• メッセージが改ざんされている（完全性が損なわれている）。
• 検証に使用した公開鍵が、署名に使われた秘密鍵とペアではない。

選択肢の中で、このいずれかに該当するのは1です。 アリスが鍵ペアを更新したにもかかわらず、ボブが古い公開鍵を使って検証しようとすれば、当然ながら検証は失敗します。

なぜ他の選択肢は間違いか？

• 2. 共通鍵の漏洩: これは機密性の問題であり、署名検証とは直接関係ありません。
• 3. 秘密鍵の失効: 失効前に作成された署名であれば、検証自体は成功する可能性があります。検証が「失敗する」のは、データか鍵の不一致が原因です。
• 4. メッセージの重複: メッセージ内容が同じであれば、何度検証しても結果は同じはずです。