情報処理安全確保支援士(情報セキュリティスペシャリスト) 試験情報＆徹底解説

自営CAの秘密鍵が漏洩すると、グループ販社と御社に被害が及ぶこととなるという文章から
どのような被害が考えられるか？という問ですがいまいちよくわかりません。

なぜ、秘密鍵が漏洩すると証明書が偽造され、偽の注文書が送られる可能性があるのでしょうか？
原理について教えていただけないでしょうか？

証明書の発行とは、
「利用者の公開鍵にCAの秘密鍵でディジタル署名を付与」することです。
そのため自営CAの秘密鍵が漏えいされると、第三者によって
証明書が発行されてしまいます。

又、文中からS/MIMEで注文書を送付するとあります。
文意からS/MIME経由での注文書は本物とみなすと思われます。
偽造された証明書があると、対になる偽の秘密鍵でディジタル署名が付与され、
偽造された証明書でディジタル署名の検証が成功してしまいます。

ご返信ありがとうございます。
時系列で表記すると下記のような流れになるのでしょうか？

①自営CAの秘密鍵が漏洩
②第三者が自営CAの秘密鍵を入手
③第三者が入手した秘密鍵を使用して自営CAから証明書を発行  
→ここがよくわからないです。入手した秘密鍵があれば偽の証明書が発行できる？
  CAから証明書を発行するには秘密鍵と対になる公開鍵(CSR)が必要になるという認識
④第三者が自営CAから発行した証明書をハッシュ関数にてハッシュ化、注文書(データ)に
  入手した秘密鍵でデジタル署名を付与
⑤第三者がS/MIMEにて注文書(データ)を標的に送信
⑥受信者は自営CAの公開鍵でデジタル署名を検証する
  (自営CAの秘密鍵なのでルート証明書をインストール済みの受信者は検証に成功する)

もう少しで理解できそうなのですが、上記内容を見て誤っている箇所等あれば
ご指摘して頂けると助かります。

よろしくお願いします。

>③第三者が入手した秘密鍵を使用して自営CAから証明書を発行  
>→ここがよくわからないです。入手した秘密鍵があれば偽の証明書が発行できる？

第三者が入手した秘密鍵を使用して、偽の自営CAを構築。
偽の自営CAから偽造された証明書を発行する。
証明書の知識があれば、CAはopensslなどで構築可能です。

>  CAから証明書を発行するには秘密鍵と対になる公開鍵(CSR)が必要になるという認識
CAの秘密鍵とクライアントの秘密鍵を混同されているようです

CSRの中身は以下の2つです
・クライアントの秘密鍵を基に生成されたクライアントの公開鍵
・クライアント情報(コモンネームなど）

証明書の発行とはクライアントからのCSRにCAの秘密鍵で署名することを指します。
CSR = クライアント情報 + クライアントの公開鍵
証明書 = (クライアント情報 + クライアントの公開鍵)に対してCAの秘密鍵で署名

>④第三者が自営CAから発行した証明書をハッシュ関数にてハッシュ化、注文書(データ)に
>  入手した秘密鍵でデジタル署名を付与

メールの内容をハッシュ化して、それに対して送信者の秘密鍵でディジタル署名を
付与します。
受信者は送信者の偽造された証明書内の公開鍵でディタル署名を検証します。
この時に、偽造された証明書は本物の自営CAの秘密鍵で署名されているため、
本物の証明書とみなされ、その内部の公開鍵も本物とみなされてしまいます。

ご返信ありがとうございます。
本当に勉強になります。

先ほどのご教授して頂いた内容を元に再度流れを考え直しました。

①自営CAの秘密鍵が漏洩
②第三者が自営CAの秘密鍵を入手
③第三者が自営CAの秘密鍵を使用して偽の自営CAを構築(opensslなど)
④第三者が自営CAから偽のデジタル証明書を発行
--->発行した偽のデジタル証明書に含まれる公開鍵は自営CAから入手した秘密鍵から生成した公開鍵
⑤正規の送信者が偽の自営CAに接続し(フィッシング等で)、偽のデジタル証明書を取得
⑥正規の送信者が自身の注文書データを自身の秘密鍵で暗号化し注文書データに署名
⑦署名された注文書に取得した偽のデジタル証明書を付与し、S/MIMEを使用して送信
⑧受信者はCAのルート証明書を使用してデジタル証明書を検証
--->自営CAから入手した秘密鍵で暗号化されているので復号及び検証が成功
⑨復号したデジタル証明書から公開鍵を取り出し、注文書データの署名を検証
--->入手した秘密鍵と対になる公開鍵なので検証に成功

上記流れで、再度誤っている箇所がありましたらご指摘頂けると助かります。
よろしくお願い致します。

上記のように流れを考えてみましたが、本投稿の趣旨である、「偽の注文票が送信される可能性がある」という答えに結びつかないですね。

正規の送信者ではなく、注文書データを送信するのは第三者ということになりますね・・。
となると、上記の⑤は不要なります。

①自営CAの秘密鍵が漏洩
②第三者が自営CAの秘密鍵を入手
③第三者が自営CAの秘密鍵を使用して偽の自営CAを構築(opensslなど)
④第三者が自営CAから偽のデジタル証明書を発行
--->発行した偽のデジタル証明書に含まれる公開鍵は自営CAから入手した秘密鍵から生成した公開鍵
⑤第三者が自身の偽の注文書データを自身の秘密鍵で暗号化し注文書データに署名
⑥署名された注文書に取得した偽のデジタル証明書を付与し、S/MIMEを使用して送信
⑦受信者はCAのルート証明書を使用してデジタル証明書を検証
--->自営CAから入手した秘密鍵で暗号化されているので復号及び検証が成功
⑨復号したデジタル証明書から公開鍵を取り出し、注文書データの署名を検証
--->入手した秘密鍵と対になる公開鍵なので検証に成功

多少違うと思われます。

>④第三者が自営CAから偽のデジタル証明書を発行
> --->発行した偽のデジタル証明書に含まれる公開鍵は自営CAから入手した秘密鍵から
> 生成した公開鍵

CSRを作成する時に使用する鍵ペア（秘密鍵・公開鍵）は第三者が独自に生成したものです。
本物の自営CAから漏えいした秘密鍵は偽の自営CAを作成するために使われるだけです。

>⑤第三者が自身の偽の注文書データを自身の秘密鍵で暗号化し注文書データに署名
>⑥署名された注文書に取得した偽のデジタル証明書を付与し、S/MIMEを使用して送信

暗号化・署名はS/MIMEのプロトコル内で自動で行われます。
メール送信者が手動で明示的には行いません。

論点をまとめます
・自営CAの秘密鍵があれば、偽の自営CAを構築できる。
・偽の自営CAは第三者が作成した不適切なCSRに対しても署名でき、
  偽造証明書を発行できる。
です。

pixさん

本件についてご回答ありがとうございました。
よく理解することができました。

また何かわからないことがありましたらご回答頂けますと幸いです。
本当にありがとうございました。