189
150

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

IPA試験問題不備(令和6年春期ネットワークスペシャリスト午後2)

Last updated at Posted at 2024-05-12

はじめに

背景

去る2024年4月21日に、令和6年度春期の情報処理技術者試験の各試験が実施されました。
その中でネットワークスペシャリストの午後2で、デジタル署名に関する記述式の出題があったことを小耳に挟み「あーまた『秘密鍵で暗号化』って不適切な解説が出回るやつだなー」と思って問題を見てみたところ、それ以上に問題自体に不備があると分かったため、記事としてまとめたものです。

IPAの対応状況

流石にこれは試験自体の瑕疵となる問題と捉えているため、IPAにも報告を行い、どのような対応がとられていくか、本記事に追記していっております。

  • 2024/5/12(記事公開)時点 … これから本記事のURLをIPAに通知する予定です
  • 同日 … IPAお問い合わせページの「情報処理技術者試験(iパスを除く)」より、不備の存在と本記事URLを通知し、筆者メールアドレスへの自動受付通知を確認しました。( 回答は3営業日以内目安、内容によりそれ以上とのことです )
  • 2024/5/15 … 「内容を確認します」と連絡受付のメールが来ました。が、現時点で具体的な見解が示されたわけではありません。訂正等があった場合はIPAのページで案内するということなので、今後私に直接連絡が来ることは多分ないと思います。( 私からも、個別の連絡は不要とも伝えてますし )
    どの程度のペースかは分かりませんが、IPAのページを定期的に確認して対応状況を追記していこうと思います。
  • 2024/6/9 … @cactuaroid氏にコメントいただいた通り、6/7付けで設問5の不備とその対応についてが発表されました。問題不備とちゃんと認識されたということで安心しました。なお、当該大問選択者は件の小問に関して全員正解という扱いになるようです。
  • 2024/7/2 … 当初のスケジュール通り、解答例が公開されました。件の問題については「不備により設問が成立しない。」との表記になっています。不備の詳細については特に触れられていません。
  • 2024/7/19 … 今回の試験情報としては最後となる採点講評も公開されました。が、不備のあった問題への言及はなく、結果としてIPAがなぜどこを不備と判断したのかは闇のままという状態です。今春の問題不備として別途発覚した情報処理安全確保支援士試験の記載と比べるとアンバランスと言わざるを得ません。

補足(2024/6/10追記)

これまで見落としていたのですが、今回の問題不備は令和5年秋期応用情報技術者試験の午後問1 ( 問題文PDF ) でも、S/MIMEの署名に関して同様の不備があったものです。
※S/MIMEの暗号化に関しては、大まかに問題ないところです

同一内容となるため、改めてIPAに指摘は行いませんが、過去問を参考にされる方はご注意ください。

問題の内容

該当箇所と参照先

該当箇所は、令和6年春期ネットワークスペシャリスト午後2、問2 (大問の2番目)、電子メールの運用に関わる問題です。こちらの設問5 (1)~(3) がS/MIMEに関する小問となっていますが、小問全体が不適切なものとなっています。
※試験自体は、問1,2 (大問) の内1つを選択なので、受験者によっては全く関わりがない場合もありますし、受験者によっては答えに困ることになった、ということになるでしょう。

以下、問題の内容は、IPAの過去問題のページに掲載があるものを参照しています。
念のため、記事公開時点のPDFスナップショットも辿れるようにしました。

具体的な内容

問題は、まず問題文でS/MIMEに関するちょっとした説明が載っていて、その中の話題に関して記述式で答えるという体裁をとっています。

まずは、その説明の該当箇所から紹介します。
※なお、表の体裁および下線修飾に関してはQiitaの記事書式で再現できなかったので、セル結合部分を「(同上)」の補足にした上で下線部分をブレース {} での範囲指定に替えています。

(略)そこで,X主任は,追加で実施する対策について調査した結果,S/MIME(Secure/MIME)の導入が有効であることが分かった。

[S/MIMEの調査と実施策]
S/MIMEでは,受信者のMUA(Mail User Agent)によるメールに付与された電子署名の真正性の検証で,なりすましやメール内容の改ざんが検知できる。
MUAによる電子署名の付与および電子署名の検証の手順を表4に示す。

表4 MUAによる電子署名の付与及び電子署名の検証の手順

処理MUA 手順 処理内容
送信者のMUA  1  ハッシュ関数hによってメール内容のハッシュ値aを生成する
(同上)  2  {⑨ハッシュ値aを基に,電子署名データを作成する}。
(同上)  3  送信者の電子証明書と電子署名付きのメールを送信する。
受信者のMUA  4  {⑩受信したメール中の電子署名データからハッシュ値aを取り出す}。
(同上)  5  ハッシュ関数hによってメール内容のハッシュ値bを生成する。
(同上)  6  {⑪ハッシュ値を比較する}。

続いて、上記説明文を受けての設問内容です。

設問5 [S/MIMEの調査と実施策] について答えよ
(1) 表4中の下線⑨の電子署名データの作成方法を,25字以内で答えよ。
(2) 表4中の下線⑩のハッシュ値 aを取り出す方法を,20次以内で答えよ。
(3) 表4中の下線⑪について,どのような状態になれば改ざんされていないと判断できるかを,25字以内で答えよ。

不備の内容

S/MIMEについての基礎

ここで、不備の説明に移る前に、S/MIMEに関する基本事項について触れておきます。
S/MIMEは公開鍵暗号(守秘/署名/鍵共有)を用いてメールの暗号化や署名を行う技術およびその規格です。
最新はRFC8551のv4(2019年)ですが、アプリの対応状況は不明なところがあるので、一つ前のRFC5751のv3.2(2010年)を参照した方が無難かも知れません。
そして、S/MIMEで使用するデータは、昔のPKCS#7に由来するCMS(最新はRFC5652および更新版RFC8933)に基づきます。

今回の問題に鑑み、署名機能に絞って説明しますと、メールに対して署名を施す場合、分離型 ( multipart/signed形式で、メール内容と SignedData 部分が分離 ) と、同梱型 ( pkcs7-mime として SignedData がメール内容も含む ) の2種類の形式があります。(次図、同一のメールメッセージでの比較例)

image.png

しかしながら、両者の違いは SignedData がメール内容を含むかどうかに過ぎないため、左の分離型に絞って説明することで齟齬を生じません。
さて、その上で S/MIME の文脈で言う「署名」が何を指すのか。SignedDataそのものを指すとも、SignedData に含まれるデジタル署名データ部分のみを指すのか、文脈に依るものですが、今回の問題では「送信者の電子証明書と電子署名付きのメールを送信する」という説明がある以上、分離型・同梱型のどちらを想定しているにせよ、証明書を含んだデータである SignedData ではなく、デジタル署名データ部分のみを指しているものと解するのが妥当です。
上記、CMS規格に基づき、S/MIME署名を施したメールのデータ内訳概要を図示すると次のようになります。
image.png

なお、上図に関して幾つか注意事項があります

  • 今回の問題に関連の薄い項目は省いています
  • 具体的に規格に記載のある、上記CMS規格上の章番号を記載しています
  • 日本語で書いている部分は、筆者による意訳であり厳密な用語ではありません
  • signerInfosは複数形の用語となっている通り、CMS上複数のsignerInfoを含むことが可能となっています。しかし、メールの通常の運用の上では送信者のみが署名を施すのが一般的であるため、図上ではsignerInfo 1つのケースに限定しています。
  • certificates, signedAttrs は CMS規格上 OPTIONAL、すなわち存在しない形態も許容されています。しかし、次の理由からSignedDataに含まれる前提としています。
    • メール送信先は、署名者から提供がなければ証明書を持ちえない以上、certificatesとして常に証明書を含める運用が一般的であること。
    • S/MIME規格2.5章で、送信側に signedAttrs を設けることが要請されていること。

不備内容

デジタル署名に関する基礎知識の欠如

設問5では、署名に関わる処理である「署名(作成)」「(署名)検証」の詳細を説明させることを意図した問題と見ることができます。

ここで、問題文中以下の内容より、RSA署名による署名を想定しているものと判断できます。

⑩受信したメール中の電子署名データからハッシュ値aを取り出す

実際、RSA署名は次図に示す処理概要の通り、署名から元のハッシュ値を取り出す操作が存在します。
※図中 RSASP1, RSAVP1 は、PKCS#1(RFC8017) にある署名/検証プリミティブ(この場合、核となる処理を指す)を表しており、これはそれぞれRSA暗号における復号/暗号化プリミティブ RSADP, RSAEP と同一処理となっています。

image.png

しかしながら、デジタル署名はRSAのみが該当するものではなく、この「ハッシュ値を取り出す」という性質は一般的なものではありません。以下に ECDSA ( 参考: SEC1 v2 ) の処理概要を図示しますが、ハッシュ値を復元するような処理はないことが確認できます。

image.png

実際 S/MIME v4 でも ECDSA や EdDSA といった RSA 以外の署名方式への対応が謳われており、アプリケーションとしてもMicrosoft社の暗号関連パラメータシートにあるように ECDSA への対応が、S/MIME用証明書データとしてもssl.comで ECC (ECDSAを含む技術総称) の対応があり、RSA前提とした問題内容は視野の狭いものです。
殊に、高校生向けへも知識提供が進む中で記事「やはり俺の情報教科書はまちがっている。」にあるような、デジタル署名と暗号化機能とを混同するようなデマが懸念されていることを鑑みても、作問者のデジタル署名の基本的な特性への理解が怪しいと言わざるをえません。

なお、「署名の方式としてRSAを想定している」という前提が問題文にあれば問題はなかったのかというと、そうとも言えません。

(1) 表4中の下線⑨の電子署名データの作成方法を,25字以内で答えよ。
(2) 表4中の下線⑩のハッシュ値 aを取り出す方法を,20次以内で答えよ。

この問題文に対し、RSA前提ならば(1)は「秘密鍵を用いてRSASP1を適用する」旨、(2)は「公開鍵を用いてRSAVP1を適用する」旨解答が考えられますが、RSAの内部処理に関わる、一種重箱の隅的な雑学に相当するもので、ネットワークスペシャリストとしての見識を問う試験内容として適切とは言えません。
かと言って「署名作成用の手順を適用する」「署名検証用の手順を適用する」ではおうむ返しに過ぎず説明になりません。受験者として記述をためらう内容となるでしょう。
邪推になりますが、「秘密鍵を用いて暗号化する」「公開鍵を用いて復号する」という、広く流通しているデマを前提知識として想定していたのだとすれば、やはり作問者の基礎知識の欠如が問題になるでしょう。
※「秘密鍵を用いて復号する」「公開鍵を用いて暗号化する」であれば、RSASP1, RSAVP1 がそれぞれ RSADP, RSAEP と同一処理であることから、不適切な説明にはなりませんが、やはり重箱の隅的な雑学に過ぎないという点は変わりません。

総じて、以下の点が問題であったと言えます。

  • 作問者(レビュー者含む)のデジタル署名の基礎知識の欠如
    • 基本的な特性への理解不足、様々な方式への意識のなさ
    • 特定方式の詳細という、全体的な教養からすれば重箱の隅にあたる部分を答えさせようとする作問バランスの悪さ
    • (おそらく)デマ知識に基づいて作問するという、あるいはデマに関する意識の薄さからくる不用意さ

S/MIMEの仕様に関する不理解と調査不足

前章ではRSA前提と思われる処理説明を焦点としていました。それは、問題文の以下の部分から読み取れたものです。

⑩受信したメール中の電子署名データからハッシュ値aを取り出す

しかし、S/MIME仕様に照らし合わせると、RSAを前提としてもこの記述は誤りです。
なぜなら、S/MIME(CMS)における署名対象のデータは、メール内容そのものではなく、S/MIMEについての基礎で挙げた「署名対象属性群(signedAttrs)」であるからです。次図に示す通り、メール内容のハッシュ値は一属性に過ぎず、署名日時等の他の属性を含めたデータに対して署名値を計算することになります。
image.png

このことに基づき、S/MIMEにおける署名検証を整理すると、次図の通りとなります。

image.png

ポイントとしては次の2点です。

  • メール内容のハッシュ値と、署名対象属性群にあるハッシュ値とが一致すること
  • 署名対象属性群のデータおよび証明書に含まれる公開鍵に対して、デジタル署名が妥当であること

しかるに、問題文中にある「電子署名データからハッシュ値aを取り出す」「⑪ハッシュ値を比較する」は署名対象属性群の存在を認識できておらず、S/MIMEの仕様に沿った説明としては不適切です。
※念のためですが、「『電子署名データからハッシュ値aを取り出す』は『SignedDataから属性の1つであるハッシュ値を取り出す』という意図だったのではないか」と擁護しようとしても、今度は手順の中から公開鍵を使った署名検証が欠けることになるため、不適切であることには変わりません。

なお、筆者の見解を補足するならば、試験としてS/MIMEの仕様を細かく記述する必要性があるとは考えていません。しかし、「メールの内容に基づき署名を作成する」「メールの内容に基づき署名を検証する」といった詳細に触れない説明であれば十分適切であるところを、仕様の確認を怠り想像だけでウソの詳細手順を問題にしてしまったこと。これは中国の故事にある蛇足そのものであり、非常に大きな問題であると考えます。

まとめると、以下の点が問題であったと言えます。

  • 作問者(レビュー者含む)のS/MIME仕様への不理解と調査不足
    • S/MIME仕様に対して理解が不足していたこと、不足している点を認識していなかったこと
    • 詳細を問題化する際に、仕様への適合性の調査を怠ったこと
    • 詳細部分を空想で賄って作問したこと

各社速報

参考までに、資格取得・教育系の企業で解答速報を挙げているところが、この設問をどう捉えているか調査しました。
記事執筆時点での速報を以下に挙げます。

  • TAC
    TAC解答速報のスナップショット
    • 解答内容
      (1) 送信者の秘密鍵でハッシュ値 a を暗号化する。
      (2) 送信者の公開鍵で電子署名を復号する。
      (3) ハッシュ値 a とハッシュ値 b の値が一致した場合
  • ITEC
    ITEC解答速報のスナップショット
    • 解答内容
      (1) ハッシュ値 a を,送信者の秘密鍵で暗号化する。
      (2) 署名データを送信者の公開鍵で復号する。
      (3) ハッシュ値 a とハッシュ値 b が一致すること

いずれも、S/MIME仕様への誤謬が指摘できていないのは ( 問題文への信用に基づくものと判断できるため ) 仕方がないにしても、デジタル署名に関する基礎知識の欠如により、デマに基づく解答となっているのは大きな問題と言えます。

おわりに

筆者自身今回の試験は受験していないため、当該設問への扱いに関して直接の利害関係はありません。しかしながら、過去の受験経験と資格保有者としての立場から、IT技術者の高度資格としての本試験におけるこのような瑕疵は、技術者全体の信用低下にもつながる、看過し得ない問題と認識しています。
試験運用の主体であるIPAにおかれては、是非とも適切な対処を行われるよう、切に希望するものです。
※(6/9追記)今回の問題については対処が確認でき、再発防止に努められるということで安心しました。

189
150
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
189
150

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?