情報処理安全確保支援士過去問題 平成29年秋期 午後Ⅰ 問3
⇄問題PDFと解説を画面2分割で開く⇱問題PDF
設問1
解答入力欄
解答例・解答の要点
- 正規のECサイトのURLでアクセスしたときに，偽のECサイトに誘導する。
解説
- 〔aについて〕
サーバ証明書の検証に用いるのは「ディジタル署名」です。
サーバ証明書には、サーバの公開鍵とサーバに関する情報（例えばコモンネームや組織名など）を含むデータ※1（以後、Dとする）と、そのDから得られるハッシュ値と認証局の秘密鍵から生成した署名（以後、Sとする）が含まれています。
サーバ証明書が正規のものであるかを検証するためには、認証局の公開鍵によってSを復号して得られたハッシュ値と、受信側でDをもとに計算したハッシュ値が等しくなることを確認します。認証局の公開鍵で復号できたということは、署名はそれに対応する認証局の秘密鍵で生成されたことが明らかであり、サーバ証明書が認証局で作成されたものであると判断できます。また、ハッシュ値の一致により改ざんされていないことがわかります。このように、公開鍵暗号方式とハッシュ値の組み合わせによって送信データを検証する方法は「ディジタル署名」と呼ばれます。
∴a＝コ：ディジタル署名
※1 サーバ証明書の発行申請に記載された情報であり、CSR（Certificate Signing Request）とも呼ばれます。
〔bcについて〕
SSL/TLSでは、共通鍵暗号と公開鍵暗号を組み合わせたハイブリット暗号方式を採用しています。これは、暗号化通信に使用する共通鍵を、公開鍵暗号を使用して安全に共有するというものです。公開鍵暗号方式はセキュリティ面で共通鍵暗号方式よりも優れていますが、その代わりに暗号化と復号に係る計算量が多く、処理速度が遅いという欠点があります。一方、共通鍵暗号方式は鍵を第三者に見られないように受け渡す必要がありますが、暗号化と復号の処理を高速に行うことができます。SSL/TLSでは、この両者を組み合わせることで、安全に鍵を共有しつつ、高速な暗号化通信を実現しています。
SSL/TLSでは、データの送受信時の暗号化・復号に「共通鍵暗号」を使用します。また、SSL/TLSにおいて、公開鍵暗号（DH法など）を使用して共通鍵を共有する手順は「鍵交換」と呼ばれます。したがって、空欄bには「カ」、空欄cには「オ」が当てはまります。
∴b＝カ：共通鍵暗号
c＝オ：鍵交換
〔dについて〕
サーバ証明書には、DV（ドメイン認証：Domain Validation）、OV（組織認証：Organization Validation）、EV（組織認証拡張：Extended Validation）の3種類があります。- DV証明書
- ドメインの使用権利を認証する
- OV証明書
- DVに加え、ドメインの所有者、住所などサーバの運営組織の存在も認証する
- EV証明書
- OVに加え、組織の事業の継続期間や電話による申請者の雇用状況確認などの事業実態の確認が行われる
これら3つのうち解答群の中にある「EV証明書」が正解となります。
∴d＝イ：EV証明書
不正解の証明書についてはそれぞれ次のようなものです。- CA証明書
- サーバ証明書が正しいことを証明するためにCAが発行するディジタル証明書。中間CA証明書とも呼ばれる
- 相互認証証明書
- 2つの認証局が相互に認証するために発行するディジタル証明書
- ルート証明書
- 公開鍵基盤の起点となる認証局が発光するディジタル証明書。自己署名がされていて、認証パスの起点となる
- DNSキャッシュポイズニング攻撃の役割が問われています。
DNSキャッシュポイズニング攻撃は、DNSサーバに誤った情報をキャッシュさせ、ユーザーがアクセスしたい正規のサイトではなく、攻撃者が用意した偽のサイトへ誘導する攻撃です。通常、利用者がECサイトなどの正規のURLをWebブラウザに入力すると、そのURLがDNSサーバを介して正しいIPアドレスに変換されます。この攻撃では、DNSサーバに誤ったIPアドレスをキャッシュしていることから、利用者が正規のURLを入力しても、偽のキャッシュ情報によって攻撃者の用意したサーバのIPアドレスに変換され、偽サイトに誘導されてしまいます。つまり、利用者を偽サイトに誘導する役割を果たします。
特に攻撃者が秘密鍵を不正に取得している場合は注意が必要です。秘密鍵を持っていると、正規のサーバ証明書を偽サイトに流用できるため、ユーザーはSSL/TLSによる暗号化通信が行われている正規サイトであるかのように信じてしまいます。これは、偽サイトであってもブラウザが「安全なサイト」として表示してしまう原因となります。今回、秘密鍵の漏えいが発覚したのもこの手口です。DNSキャッシュポイズニング攻撃と、このような正規のサーバ証明書を悪用する手法を組み合わせることで、フィッシング攻撃が成立する危険性が高まります。
∴正規のECサイトのURLでアクセスしたときに，偽のECサイトに誘導する。
- 暗号化と復号に用いる鍵は乱数をもとに生成されます。最も優れた乱数はランダムな数値（真の乱数）ですが、コンピュータ上では完全に実現することが難しいため、通常は特定のアルゴリズムによって計算される「擬似乱数」が使用されています。擬似乱数は、一見ランダムに見える数値の列を生成しますが、初期条件（シード値）やアルゴリズムが同じであれば、常に同じ乱数列が生成されるという特性を持ちます。鍵の安全性の観点から考えると、乱数に規則性があったり、同じパターンが短い周期で繰り返されるようなものは、鍵の生成に使用する乱数生成器としてふさわしくありません。
本問のZソフトのように脆弱性のある乱数生成器を使用している場合、攻撃者に鍵を推定されてしまうおそれがあります。鍵の生成に使用される乱数は予測不可能でなければなりません。乱数が一様分布していること（すべての値が等しい確率で出現する）も望ましい性質ですが、より重要なのは「次にどの乱数が出現するかを予測できない」ことです。この予測不可能性こそが、同じ鍵を生成させないために最も重要な性質です。
∴エ：予測不可能である。
設問2
解答入力欄
解答例・解答の要点
- ①：鍵が危たい化したWebサイトのFQDN
- ②：鍵が危たい化したと思われる日時
解説
- 鍵が危たい化した場合は、直ちに自ら鍵の利用を停止するとともに、周囲にその鍵が使えなくなったことを知らせる必要があります。
サーバ証明書には公開鍵が含まれているので、自ら取る行動としてはサーバ証明書の「利用」停止、周囲に周知するには認証局にサーバ証明書の「失効」申請を行います。失効申請がされると、認証局はCRL（証明書失効リスト）に失効した証明書のシリアル番号を登録します※2。利用者が失効したサーバ証明書を利用しようとしても、証明書の検証プロセスで失効が判明し、Webブラウザは警告を表示します。この警告により、利用者はその証明書が安全ではないことを認識できます。したがって、空欄アには「利用」、空欄イには「失効」がそれぞれ当てはまります。
※2 CRL(Certificate Revocation List)には、失効したディジタル証明書の番号、失効日時、失効理由などが記載されます。失効理由はコード化されており、その一つに「鍵の危たい化（keyCompromise）」があります。
∴ア＝利用
イ＝失効
- 秘密鍵が漏えいしてから、利用者が失効情報を参照できるようになるまでには、❶検知するまでのタイムラグ、❷検知してから失効申請を行うまでのタイムラグ、❸失効情報が登録され配信されるまでのタイムラグが存在します。この期間、攻撃者が秘密鍵を使用して通信の盗聴やなりすまし、データの改ざんなどの不正を行うリスクが高まります。利用者が自身の被害の可能性を適切に判断したり被害を未然に防止したりするためには、事実関係を整理したうえで、適切な情報を速やかに利用者に開示することが極めて重要です。
まず、必要となる情報の1つ目は、鍵の危たい化の影響を受けるサーバやサービスです。サーバ証明書にはコモンネームとしてFQDNかIPアドレスを記載できますが、C社は独自ドメイン名を取得してECサイトを運用していたことや、H氏が「サーバ証明書には、サーバのFQDNと公開鍵が記載されます」と説明していることから、ECサイトのFQDNを公開することが適切です。
次に、サーバがいつから安全ではない状態になっていたかが重要です。これにより、利用者は自分が影響を受けた期間やその間に行われた取引や通信が、どの程度リスクにさらされたかを評価することができます。したがって、鍵が危たい化したと思われる具体的な時期を明示する必要があります。
∴①鍵が危たい化したWebサイトのFQDN
②鍵が危たい化したと思われる日時
- 暗号鍵が危殆化した場合には、当該暗号鍵の利用を停止し、新しい暗号鍵に置き換える必要があります。サーバ証明書は公開鍵暗号方式を利用した技術であり、公開鍵暗号方式では秘密鍵と公開鍵は一対のペアとして生成されます。したがって、新しい鍵を用意する際は「鍵ペア」を生成する必要があります（もしくは「秘密鍵と公開鍵」）。
∴e＝鍵ペア
設問3
解答入力欄
解答例・解答の要点
- ドメイン認証証明書ではサーバの運営者がC社であることを確認できないから
解説
- 図2によるとECサイトは「SSL3.0, TLS1.0, TLS1.1, TLS1.2」のプロトコルが利用可能です。図4「POODLE攻撃の概要」には次の2つの説明があります。
- SSL3.0プロトコルのパディングチェックの脆弱性を利用して攻撃する※3
- TLS1.0以降のプロトコルについて（中略）実装上の問題がなければ成功は困難と考えられている
図2を見るとECサイトでは「SSL3.0, TLS1.0, TLS1.1, TLS1.2」が利用可能となっています。このため、暗号スイートにSSL3.0が含まれていればPOODLE攻撃の脆弱性があります。また、バージョンロールバック攻撃の脆弱性が存在する場合には暗号スイートに関係なくSSL3.0を強制されてしまい、攻撃を受ける可能性があります。
POODLEはSSL3.0の脆弱性を突く攻撃なので、根本的な対策はSSL3.0を無効化することです。したがって、解答は「SSL3.0を利用しない設定にする」となります。
∴SSL3.0を利用しない設定にする。
※3 POODLEはPadding Oracle On Downgraded Legacy Encryptionの略で、SSL3.0のブロック暗号のCBCモードにおける「パディングの最終1バイト分だけをチェックして正しければメッセージ全体が正しいと判断する」という欠陥を突いて、通信内容の解読を試みる攻撃です。
- PFS(Perfect Forward Secrecy)とは完全前方秘匿性のことで、『暗号化鍵の共有に使われている秘密鍵が漏えいしたとしても、過去に暗号化された通信データは解読されない』という鍵交換プロトコルの性質です。
図2の暗号スイートを見ると、鍵交換にRSAが使用されています。RSAでは長期的に同じ秘密鍵が使用するため、秘密鍵が漏えいした場合、過去の通信内容からセッション鍵を復号することが可能となります。これにより、その暗号化通信のデータを解読できてしまいます。このため、RSAを使用した鍵交換は前方秘匿性を有しません。
PFSを有する鍵交換プロトコルとして、DHE（ディフィー・ヘルマン鍵共有）とECDHE（楕円曲線ディフィー・ヘルマン鍵共有）があります。これらのプロトコルでは、各セッションごとに新しい一時的な鍵ペアを生成するため、仮に秘密鍵が漏えいしたとしても、過去の通信データが解読されることはありません。TLS1.3では鍵交換は上記2つに限定されています。
なお、AESは共通鍵暗号、CFBはブロック暗号のモード、DSAとECDSAは署名プロトコル、PKCSは公開鍵暗号に関する技術仕様をまとめた標準です。
∴ウ，オ（DHE，ECDHE）
- RSAの秘密鍵が漏えいした場合、その鍵を使って行われた暗号化通信で交換された共通鍵も解読されてしまいます。これにより、攻撃者が通信データを取得していた場合、共通鍵によって暗号化された通信データも復元されてしまいます。このため、RSA鍵が漏えいした時点以降に行われた通信はもちろん、その前に行われた通信データも危険にさらされます。
このように、たとえ過去の通信データが暗号化されていたとしても、攻撃者がその通信データを保存しておけば、鍵が漏えいした後に過去の通信内容すべてが復号されてしまう可能性があります。これがRSAの鍵の危たい化が通信内容に及ぼすリスクです。
∴エ：取得された通信データの全てを復元されるおそれがある。
- 問題文冒頭には「C社はECモールに出店したオンラインショップでの販売量が増えており，（中略）新たに独自のドメイン名を取得し，C社専用の販売サイト(以下，ECサイト)を立ち上げた」とあります。利用者の間では、C社と言えばECモール内で展開しているという認識が強いと考えられ、そのような中で新たに立ち上げるECサイトは、本当にC社の運営であるのか判別しづらい状況に置かれることになります。
ドメイン認証証明書が証明する情報はコモンネーム（ドメイン）であり、組織名の情報は含まれていないため、この証明書からはC社が運営しているかどうかを確認することができません。これがドメイン認証証明書を使用することの弊害となります。特にECサイトでは運営者の信用が重要となるため、新たなECサイトが利用者から信用を得るための方策の一つとして、組織の実在性を確認できるOV証明書やEV証明書を導入することは理にかなっています。
∴ドメイン認証証明書ではサーバの運営者がC社であることを確認できないから
