令和4年度 春期 午後Ⅰ（旧試験）

本文の根拠

表1 項番1 検査の方法

利用者の入力を基に HTTP レスポンスヘッダを生成する処理において，

表1 項番1 検査の方法

改行コードを意味する文字列を入力したときに，HTTP ヘッダフィールドが追加されないことを確認する。

項番1の脆弱性は HTTP ヘッダインジェクションで，利用者の入力が HTTP レスポンスヘッダの値に使われるとき，その入力に改行コードが含まれていると，そこでヘッダフィールドが区切られ，攻撃者が任意のヘッダフィールドを追加できてしまう。HTTP/1.1 では，ヘッダフィールドの行は CRLF（キャリッジリターン CR＝0x0D と ラインフィード LF＝0x0A）で終わると定められている（RFC 9112）。URL やフォームの値の中では，この CR と LF が %0D%0A と書かれるので，下線①の“改行コードを意味する文字列”の例はアである。

イの %20 は URL エンコードで空白を表す。ウの <br> と エの <p> は HTML の改行タグ・段落タグで，ブラウザが表示するときに意味をもつだけであり，HTTP ヘッダの行を区切る働きはない。表1の検査は“HTTP レスポンスヘッダ”の話なので，HTML の文書の中身ではなく，HTTP のメッセージの区切りを選ぶ。

解答群から記号を選ぶ設問なので字数は関係しないが，採点講評のとおり，ウ（<br>）を選ぶ誤りが多かった。HTML のタグと HTTP の区切りを混同しないようにする。

採点講評（IPA）

設問1(1)は，正答率がやや低かった。ウのHTML改行タグの解答が多かった。HTTPとHTMLの理解が不十分である結果と想定される。

本文の根拠

表1 項番2 対策方法

SQL 文の組立てにおいて，SQL 文のひな形の中に

表1 項番2 対策方法

変数の場所を示す？記号を置く技法を利用する。

図2 7行目

String sql = "SELECT 情報番号, 情報名 FROM 情報管理テーブル WHERE プロジェクト ID = ?";

項番2は SQL インジェクションの対策である。SQL 文のひな形の中に，値が入る場所を“?”で示しておき，値は後から別に渡す方法は，プレースホルダ（バインド機構）と呼ばれる。ひな形の構文を先に確定させ，値は文字列などのデータとして扱われるので，値に含まれる記号が SQL 文の構造を変えることがない。

図2の7行目にある WHERE プロジェクト ID = ? の“?”がそれに当たり，後で setInt などで値が設定される。設問の“変数の場所を示す？記号”とは，この“?”のことである。値を文字列として連結して SQL 文を組み立てる方法の対極にあたる。

名称を10字以内で答える設問で，“プレースホルダ”は7字である。“エスケープ処理”のように，別の対策（値の記号を無害化する方法）の名前を答えないようにする。

本文の根拠

表1 項番3 対策方法

(3) 外部からの入力の全てについて，a を削除する。

表1 項番3

メールヘッダインジェクション

メールヘッダインジェクションは，メール送信の機能に渡す利用者の入力（宛先や件名など）に改行コードを紛れ込ませ，メールヘッダに Bcc などのヘッダフィールドを追加して，迷惑メールの送信などに悪用する攻撃である。メールのヘッダも，HTTP ヘッダと同じく行の区切りが改行（CRLF）であり，設問1(1)と原理は同じである。

項番3の対策(1)と(2)は，ヘッダを固定値にするか，入力を適切に処理する API を使うというものである。対策(3)は，外部からの入力の全てから，ヘッダの区切りとなる改行コードを取り除くことで，入力がヘッダフィールドを増やせないようにする。したがって a は“改行コード”である。

5字以内の指定は，“改行コード”（5字）にちょうど合う。“CRLF”でも意味は通るが，解答例は“改行コード”である。

本文の根拠

〔S システムの改修におけるアクセス制御要件の追加〕

方法 1：ログイン時にその利用者 ID に対して登録されているプロジェクト ID を取得し，GET リクエストのクエリ文字列に，“id=プロジェクト ID”の形式で指定する。

〔情報選択機能の脆弱性〕

情報選択機能においてクエリ文字列で受け取ったプロジェクト ID をチェックせずに利用していることに起因していた。

方法1では，ログイン後に取得したプロジェクト ID を，GET リクエストのクエリ文字列の“id=プロジェクト ID”として画面から情報選択機能に渡す。情報選択機能はこの値をチェックせずにそのまま使うので，利用者が自分でクエリ文字列の id の値を書き換えれば，書き換えた値のプロジェクトの情報を取得できる。これは，利用者が改変できる値を信頼してアクセス制御に使ったために起きる脆弱性である。

そこで，攻撃者は，クエリ文字列の id に，自分が参加していない（未参加の）プロジェクトのプロジェクト ID を指定して要求を送る。プロジェクト ID は連番で採番されているので，数を変えるだけで他のプロジェクトの ID を推測できる点も，この攻撃を容易にする。ブラウザのアドレス欄の編集でも，プロキシツールでの書換えでもできる。

40字以内に，①どの部分を（クエリ文字列の id）②何を指定するか（未参加のプロジェクトのプロジェクト ID）の2点を入れる。解答例は36字である。“URL を改ざんする”だけでは，具体的な操作を答えていないことになる。

本文の根拠

〔情報選択機能の脆弱性〕

方法 2：情報選択機能の利用時に，セッション情報から利用者情報を取得する。情報選択機能は，当該利用者情報からプロジェクト ID を取得する。

表2 注記

セッション ID は，ログイン時に発行される推測困難な値であり，secure 属性が付与された cookie に格納される。

方法1の脆弱性は，プロジェクト ID を利用者が書き換えられるクエリ文字列で受け取ることにあった。方法2では，情報選択機能がセッション情報から利用者情報を取得し，そこに登録されたプロジェクト ID を使う。セッション情報はサーバ側で管理され，利用者はセッション ID（推測困難な値）でそれを参照するだけなので，プロジェクト ID の値を書き換えることができない。

解答例は，二つの言い方のどちらでもよい。（1）プロジェクトを示すパラメタを外部から指定できないから，（2）セッション情報からプロジェクト ID を取得するから。どちらも，攻撃者が値を指定する余地がなくなったという同じ内容を，原因側と仕組み側から述べたものである。

30字以内なので，“プロジェクト ID を利用者が指定できなくなるから”のように，なぜ解決するか（利用者が値を指定できない）の理由を一つ入れる。“セッション管理をしているから”だけでは，何が解決の決め手かが不明確である。

本文の根拠

図2 8行目

java.sql.b stmt = con.prepareStatement(sql);

図2 7行目

String sql = "SELECT 情報番号, 情報名 FROM 情報管理テーブル WHERE プロジェクト ID = ?";

7行目の SQL 文は“?”を含むプレースホルダ付きのひな形で，これを con.prepareStatement(sql) に渡して作られるオブジェクトの型は，java.sql.PreparedStatement である。図2・図3の stmt の宣言には，どちらも b として PreparedStatement が入る（ウ）。PreparedStatement は Statement のサブインターフェースで，setInt や setString のように，? に値を設定するメソッドをもつ。

アの Connection は，3行目の con の型で，データベースへの接続を表す。イの DriverManager は，5行目で getConnection を呼び出しているクラスである。エの Statement は，プレースホルダをもたない SQL 文を実行するためのもので，setInt は無い。採点講評も，Statement でも SQL の実装はできるが，プレースホルダの実装には PreparedStatement が必要だと述べている。

記号を選ぶ設問なので字数は関係しない。続く9行目の c.setInt(1, projectId) で値を設定していることも，PreparedStatement の使用の裏付けになる。

採点講評（IPA）

設問2(3)は，正答率がやや低かった。StatementでもSQLの実装は可能であるが，本文に示されているプレースホルダの実装にはStatementを継承したPreparedStatementが必要である。脆弱性対策手法については，理論や用語だけではなく，その具体的な方法を理解してほしい。

本文の根拠

図2 8〜9行目

java.sql.b stmt = con.prepareStatement(sql);

図2 9行目

c.setInt(1, projectId);

9行目は，7行目の“?”に projectId の値を設定する処理で，setInt(1, projectId) は“1番目の?に int の値 projectId を設定する”という意味である。setInt は PreparedStatement のメソッドで，8行目で PreparedStatement のオブジェクトを格納している変数は stmt である。したがって c は stmt となる。

10行目の stmt.executeQuery() は，値が設定された stmt で SQL 文を実行する。変数 con は Connection で，setInt というメソッドをもたない。rs は結果を受け取る ResultSet である。

c には変数名を答える。大文字小文字を含めて stmt と書く。b に入れた型名の PreparedStatement と取り違えない。

本文の根拠

図3 3行目

int documentNo = Integer.parseInt(request.getParameter("no"));

図3 7〜8行目

int projectId = （省略）; // 利用者の参加プロジェクトのプロジェクト ID を利用者テーブルから取得し，代入する処理

図1

情報管理テーブル（情報番号（主キー），プロジェクト ID（外部キー），情報名，情報内容，…）

図3 注記

注記 10 行目より後の（省略）に，projectId，documentNo を用いた処理はない。

情報表示機能は，3行目でクエリ文字列の no から documentNo（情報番号）を受け取り，7行目で利用者の参加プロジェクトの projectId をセッション情報から取得している。10行目より後には projectId と documentNo を使う処理が無いので，この2つの値は9行目と10行目の間の“SQL 文のひな型に変数を代入する処理”で SQL 文にバインドされる，つまり WHERE の条件に入る。

情報管理テーブルでは，情報番号が主キー，プロジェクト ID が外部キーである。情報番号だけを条件にすると，利用者が no の値を書き換えたとき，別のプロジェクトの情報も表示できてしまう。そこで，情報番号 = ? と同時に，利用者のプロジェクト ID と一致するという条件も付ける。したがって d は 情報番号 = ? AND プロジェクトID = ? となる。

プレースホルダ（?）を使うので値そのものは書かず，AND でつなぐ。属性名は図1のとおりに書き，“プロジェクト ID”の空白の有無など，表記を変えない。“OR”と書くと，どちらかが合えば表示されてしまう。採点講評は，SQL の構文が誤っている解答があったと述べている。

採点講評（IPA）

設問3は，正答率がやや低かった。SQLの構文が誤っている解答が見受けられた。データベースのアクセス制御の設計，実装及びレビューを行うために，SQLの構文やE-R図の表記法を知っておいてほしい。

本文の根拠

〔NAS-A 及びルータ-A の調査〕

ルータ-A のグローバル IP アドレスが変更された場合，Z 社の DNS サーバの設定でホスト名 nas-a に割り当てている IP アドレスを変更するために，a レコードを更新する。

〔NAS-A 及びルータ-A の調査〕

そのレコードの b は，300 秒に設定されていた。

DNS で，ホスト名に IPv4 アドレスを対応付けるリソースレコードは A レコードである。ルータ-A のグローバル IP アドレスが変わったとき，DDNS-Z はホスト名 nas-a の A レコードの値を新しいアドレスに更新する。したがって a はア（A）である。

レコードには，その内容を DNS キャッシュサーバが保持してよい時間を秒で示す値があり，これが TTL（Time To Live）である（RFC 1035）。TTL が 300 秒なら，アドレスが変わってもキャッシュが切れる最長 300 秒の間は古いアドレスが返されることがある。DDNS のように IP アドレスが頻繁に変わる用途では TTL を短くしておく。したがって b はエ（TTL）である。

イの MX はメールの配送先，カの TXT は任意の文字列を載せるレコードの種類で，ホスト名と IP アドレスを結ぶものではない。ウの TLS は通信の暗号化の方式，オの TTY は端末で，DNS のレコードの種類ではない。解答群は記号で答える。

本文の根拠

表2 UPnP 機能

LAN 側の機器から受け付けたリクエストの内容で，ポートフォワーディングの設定とファイアウォール機能の設定を行う。

表1 注1

認証なしでリクエストを受け付ける仕様のプロトコルである。

表2 ファイアウォール機能

インバウンド通信：全て拒否（注1）

表2 注1

UPnP 機能による設定が優先される。

ルータ-A の UPnP 機能は，LAN 側の機器からのリクエストを受け付け，その内容でポートフォワーディングとファイアウォール機能の設定を行う。UPnP は認証なしでリクエストを受け付ける仕様なので，WAN 側からもこの機能が使えるとすると，インターネット上の誰でも，認証なしでルータ-A の設定を操作できることになる。

ファイアウォール機能はインバウンド通信を全て拒否しているが，表2の注1のとおり UPnP による設定が優先される。したがって，攻撃者が UPnP のリクエストを送れば，外部から LAN 側の機器（NAS-A など）への通信を許可する設定に変えられてしまう。UPnP の仕様が“LAN 側のみ有効”になっているのは，このような外部からの操作を防ぐためである。

30字以内なので，“誰が”“何を”の2点（外部から，LAN 側への通信の許可設定の変更）を入れる。解答例は24字である。“ファイアウォールが無効になる”のように，ファイアウォール機能そのものが止まるとは本文に書かれていないので，言い切らない。

本文の根拠

〔NAS-A 及びルータ-A の調査〕

ファイル共有機能でも Web 操作機能でもアクセスできない /root ディレクトリ配下のファイルも暗号化されていた。

表1 ファイル共有機能

有効に設定したプロトコルで，ファイルを共有する。

A 社の PC がランサムウェアに感染して NAS-A のファイルを暗号化した場合，PC から NAS-A に対してできる操作は，ファイル共有機能（SMB）や Web 操作機能の範囲に限られる。暗号化できるのは，それらの機能でアクセスできるファイルだけである。

ところが，今回は“ファイル共有機能でも Web 操作機能でもアクセスできない /root ディレクトリ配下のファイル”まで暗号化されていた。これは，NAS-A の OS 上でマルウェア自体が動作し，OS の権限でファイルを読み書きしたと考えるのが自然である。したがって，NAS-A 自体が感染した可能性が高いと判断できる。

40字以内なので，“PCからのファイル操作ではアクセスできない領域のファイルが暗号化されたから”（37字）のように，①PC からはアクセスできない領域 ②そのファイルが暗号化された，の2点を書く。“アクセスできない”の主語（PC からの操作）を落とさない。

本文の根拠

図2 脆弱性1

例えば，http://192.168.0.1/images/..%2fstatus.cgi の URL にアクセスすると，http://192.168.0.1/status.cgi に認証なしでアクセスできてしまう。

“..%2f”の %2f は，URL エンコードされた“/”である。“../”は一つ上のディレクトリを表すので，/images/..%2fstatus.cgi は，デコードされると /images/../status.cgi，つまり /status.cgi を指す。製品 X は，パス名が /images で始まることを見て除外リストに載っていると判断し，認証を省いてしまう。このように，“../”などを使って，公開を意図していないディレクトリのファイルへ到達する攻撃手法をパストラバーサル（ディレクトリトラバーサルとも呼ぶ）という。

除外リストには /css，/images，/js が指定されていて，リストに無いディレクトリのファイルは本来認証が要る。この攻撃では，除外リストの判定を通った後に実際のパスが変わるため，認証が省かれる。

c は15字以内で，“パストラバーサル”（8字）が解答例である。入力検証の不備で起きる別の攻撃（OS コマンドインジェクションなど）と取り違えない。

本文の根拠

図2 脆弱性2

この IP アドレスの処理に脆弱性があり，任意の OS コマンドを実行できてしまう。

図2 脆弱性2

“ping 127.0.0.1;whoami”というコマンドが実行される。

脆弱性2は，ping を実行する機能に渡す IP アドレスの処理に不備があり，利用者が入力した文字列の中の OS コマンド（図の例では whoami）が実行されてしまうものである。入力した addr=127.0.0.1;whoami は，“ping 127.0.0.1”の後ろに“;”を挟んで別のコマンドをつなげたものとして実行される。“;”はシェルでコマンドの区切りに使われる記号である。外部からの入力を OS のコマンドに渡すとき，入力の中のシェルの特殊文字を無害化しないと起きる。

このように，外部からの入力を利用して OS コマンドを不正に実行させる攻撃手法を OS コマンドインジェクションという。同じインジェクションでも，SQL 文に紛れ込ませるのは SQL インジェクションで，今回の“;”とコマンドの例は OS コマンドである。

15字以内で，解答例の“OSコマンドインジェクション”は14字で収まる。

本文の根拠

〔脆弱性の調査〕

パッチ M では，脆弱性 1 の対策として，認証なしアクセスの処理の流れにパス名の正規化の処理を加え，さらに，図3に示す順序にした。

〔脆弱性の調査〕

パス名の正規化とは，相対パスで記述されたパス名を，相対パス記法を含まない形式に変換することである。

図2 脆弱性1

除外リストに指定されていないディレクトリ配下のファイルにも認証なしでアクセスできてしまう。

脆弱性1が起きるのは，“..%2f”のように符号化されたままのパス名を除外リストと比べているからである。正しい順序は，まず URL デコードで %2f を“/”に戻し（e＝ア），次にパス名の正規化で“/images/../status.cgi”を“/status.cgi”に直し（f＝ウ），最後に正規化したパス名を除外リストと比較する（g＝イ）。この順序なら，/status.cgi は除外リストに載っていないので認証が要求される。

順序を変えると失敗する。デコードの前に正規化すると，“..%2f”は“../”と認識されず，そのまま残る。正規化の前に除外リストと比較すると，“/images/../status.cgi”は /images で始まるため，除外リストに当たってしまう。採点講評も，URL デコードを行った上で“../”などを含んだパス名を正規化してから，除外リストとの比較を行う必要があると述べている。

解答群から記号を選ぶ設問で，e～g の順序は ア→ウ→イ である。

採点講評（IPA）

設問2(3)は，正答率が平均的であった。本文に示した認証なしでアクセスできるURLでは除外リストとの比較に漏れがないように，URLデコードを行った上で，“../”などを含んだパス名を正規化してから，除外リストとの比較を行う必要があることを理解してほしい。

本文の根拠

表3 No.18

GET /images/shell.cgi?cmd=whoami HTTP/1.1

表3 No.89

POST /images/shell.cgi HTTP/1.1

表3

No.，時刻，リクエスト，ステータスコード，応答バイト数の5列の表。

図2 脆弱性2

addr=127.0.0.1;whoami

WebShell のアクセスログには，リクエスト（メソッド，パス，クエリ文字列，HTTP のバージョン），ステータスコード，応答バイト数が記録されている。GET メソッドでは，コマンドが URL のクエリ文字列（?cmd=whoami）に入るので，リクエストの記録から内容が分かる。

POST メソッドでは，コマンドは HTTP リクエストのボディ（図2の addr=127.0.0.1;whoami のような部分）で送られる。表3にはリクエスト行しか記録されておらず，ボディが残っていないので，No.89 の POST /images/shell.cgi の中身は分からない。

35字以内なので，“ボディ（送信内容）がアクセスログに残らない”ことを書く。解答例は34字である。“ログが改ざんされた”のように，本文に書かれていない事情を答えない。

本文の根拠

図4

www ALL=NOPASSWD: /bin/tar

図5

sudo tar -cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=whoami

〔アクセスログの調査〕

この tar コマンドには，任意の OS コマンドを実行できるオプションがある。ただし，ファームウェアのアップデート時にこのオプションは使用していない。

図4の sudo の設定は，www アカウントがパスワード無しで /bin/tar を root 権限で実行してよい，という意味である。コマンドの後ろに引数を書いていないので，どのような引数（オプション）でも許可される。攻撃者は，WebShell から www アカウントの権限で，図5のように --checkpoint-action=exec= のオプションを付けて tar を実行し，root 権限で任意の OS コマンドを動かして，書込み不可のディレクトリを書込み可能に変更できる。

対策は，sudo の設定でこのコマンドの使い方を制限することである。sudoers では，コマンドに引数を指定すると，利用者が指定する引数が一致するものだけが許可される（sudoers のマニュアル）。ファームウェアの更新に必要な最小限の引数だけを許可し，任意のオプションを渡せないようにすればよい。採点講評も，sudo の設定でオプションの使用を制限するなど，具体的に答えるよう求めている。

50字以内で，“どの設定ファイルで”“何を”“どうするか”を入れる。解答例は45字。“tar コマンドを使わない”のような，更新の機能そのものをなくす答えは，製品 X の運用と合わない。

採点講評（IPA）

設問3(2)は，正答率が平均的であった。ファームウェアのアップデート時にアーカイブファイルを展開するために使っているtarコマンドが，製品Xでは不要なオプションも使える設定であり，本設問は，そのようなオプションの悪用を防ぐ対策を問うているので，sudoの設定でオプションの使用を制限するなど，具体的に解答してほしい。

本文の根拠

〔DDNS-Z の調査〕

インターネットの検索エンジンで検索されないようにするために，

〔DDNS-Z の調査〕

攻撃対象になりやすいことが分かった。

検索エンジンのクローラ向けに，Web ページの HTML の head に <meta name="robots" content="…"> と書くと，そのページの扱いを指定できる。content に noindex を指定すると，そのページを検索結果に載せないよう求めることになる。DDNS-Z の URL が検索で見つかりにくくなれば，攻撃者が検索エンジンで製品 X の URL を探して攻撃対象にするのを難しくできる。

解答例は noindex と none のどちらも正解である。none は noindex と nofollow を合わせた指定である（Google の検索セントラルの説明）。解答群を使わない設問で，英字10字以内なので noindex（7字）か none（4字）のどちらを書いてもよい。

なお，この指定は検索エンジンに登録しないよう求めるものであり，アクセス自体を禁止する仕組みではない。認証や接続元の制限の代わりにはならない。講評は，インターネット上で IoT 機器を検出する方法と抑止する方法を知っておいてほしいと述べている。

採点講評（IPA）

設問4は，正答率が低かった。インターネット上でIoT機器を検出する方法と，それを抑止する方法を知っておいてほしい。

本文の根拠

〔本人確認〕

身元確認は，“登録する氏名・住所・生年月日等が正しいことを証明／確認すること”と定義されている。

〔本人確認〕

当人認証は，“認証の 3 要素のいずれかの照合で，その人が作業していることを示すこと”と定義されている。

表1 アカウント作成

Q サービスのアカウント情報として，利用者 ID とパスワード，氏名，生年月日，携帯電話番号を登録する。

表1 Q サービスへのログイン

利用者 ID とパスワードで Q サービスにログインする。

本人確認は，身元確認（登録する氏名・生年月日などが正しいことの確認）と，当人認証（その人が今操作していることの確認）に分けられる。表1で，氏名・生年月日などを登録するのは“アカウント作成”の時なので，身元確認はこの時に行う（a＝イ）。

“Q サービスへのログイン”は，利用者 ID とパスワードという認証の要素（知識）を照合して，その人が操作していることを示す手順なので，当人認証に当たる（b＝ア）。アカウント作成で登録した情報が正しいかを確かめるのが身元確認，その後に毎回，本人が操作していることを確かめるのが当人認証，と分けて考える。

解答群から記号を選ぶ設問で，a と b を逆にしやすい。a は“登録する氏名・住所・生年月日等が正しい”の確認という定義から選ぶ。

本文の根拠

表1 銀行口座とのひも付け

利用者は，口座番号，キャッシュカードの数字 4 桁の暗証番号を入力する。

〔身元確認〕

表1の銀行口座とのひも付けでは，キャッシュカードの所持が確認されず，暗証番号で照合されるだけなので，攻撃者が他人の氏名でアカウント作成を行い，

表1の銀行口座とのひも付けでは，Q サービスが銀行に氏名を提供し，利用者が口座番号とキャッシュカードの暗証番号（4桁）を入力して，両方が正しければ認証に成功する。キャッシュカードの所持は確認されず，口座番号と暗証番号という知識だけで照合される。このため，攻撃者が他人の氏名でアカウントを作成しても，その人の口座番号と暗証番号を知っていれば，その人の口座とのひも付けができてしまう。

口座番号と暗証番号を入手する方法として，解答例は二つを挙げる。（1）他のサービスなどから漏えいしている口座番号と暗証番号を悪用する，（2）口座番号と暗証番号を，だまして（フィッシングなどで）聞き出し，悪用する。どちらも，攻撃者が知識を何らかの手段で手に入れる点では同じだが，入手の経路が違う。

二つ挙げ，それぞれ30字以内で書く。“暗証番号を推測する”は，連続 5 回の認証失敗でひも付けができなくなる（表1）ので，現実的な方法としては挙げにくい。入手の経路が違う二つを書き，同じ内容の言い換えにしない。

本文の根拠

表2 項番1

・c 付き本人確認書類の画像，・容貌の画像。

表2 項番2

・c 付き本人確認書類の IC チップ情報，・容貌の画像。

表2 項番3

・本人確認書類の画像又は IC チップ情報，・銀行等への顧客情報の照会。

項番1と2は，本人確認書類と“容貌の画像”の2点を用いる方法である。容貌の画像は，書類に載っている顔の写真と見比べて，書類の持ち主がその場にいることを確認するために使う。したがって，書類は顔写真が載っているものでなければならず，c は“写真”である。

項番3と4は，本人確認書類に加えて，銀行などへの顧客情報の照会や顧客名義口座への振込みで，本人の所在を確かめる方法で，容貌の画像は使わない。そのため“写真付き”という限定が書かれていない。

5字以内の設問で，“写真”（2字）が解答例である。“顔写真”でも意味は通じるが，解答例は“写真”である。

本文の根拠

C 課長の説明

入力されたパスワードが正しい場合，マイナンバーカード内の d で Q サービスの申込用のデータにデジタル署名し，当該デジタル署名，当該データ本体，署名用電子証明書を Q サービスに送付する。

C 課長の説明

デジタル署名が利用者本人のものであり，改ざんされていないことを Q サービスの利用者の e を用いて確認した後，

デジタル署名は，署名する側が自分だけが持つ秘密鍵でデータの署名値を作り，検証する側が，対応する公開鍵でその署名値を確かめる仕組みである。マイナンバーカードには，利用者の秘密鍵が格納され，その鍵は取り出せない。したがって d は秘密鍵（ウ）である。

署名用電子証明書には，利用者の公開鍵が含まれている。Q サービスは，送付された署名用電子証明書の公開鍵で署名を検証し，署名が利用者本人のものであること（秘密鍵の持ち主が署名した）と，データが改ざんされていないことを確かめる。したがって e は公開鍵（イ）である。

共通鍵（ア）は暗号化と復号に同じ鍵を使う方式の鍵で，電子署名には使わない。d と e を逆にしない（署名は秘密鍵，検証は公開鍵）。

本文の根拠

C 課長の説明

地方公共団体情報システム機構に f を確認する。

C 課長の説明

署名用電子証明書などが格納されている。

電子署名の検証で署名が正しいと分かっても，その署名用電子証明書そのものが有効でなければ，本人確認の根拠にならない。署名用電子証明書は，マイナンバーカードの紛失や，記載事項の変更，有効期間の満了などで失効する。署名時点で証明書が失効していないかは，証明書を発行した側に問い合わせないと分からない。

証明書の発行者側（ここでは地方公共団体情報システム機構，J-LIS）が提供する方法には，失効した証明書の一覧（CRL，RFC 5280）を取得して調べる方法と，証明書ごとの状態を問い合わせる OCSP（RFC 6960）がある。採点講評も，J-LIS が OCSP による方法と CRL による方法を提供していると述べている。したがって f は“署名用電子証明書の有効性”，又は“失効の有無”である。

15字以内なので，“署名用電子証明書の有効性”（12字）か“署名用電子証明書の失効の有無”（14字）で収まる。“本人かどうか”のように，署名の検証（e）の内容を答えない。

採点講評（IPA）

設問2(4)は，正答率が低かった。公開鍵暗号の仕組みにおいて，電子証明書の有効性を確認する方法が必要となるが，このことを理解していないと思われる解答が多かった。公的個人認証サービスでは，地方公共団体情報システム機構（J-LIS）がOCSPによる方法とCRLによる方法を提供している。これらの方法について知っておいてほしい。

本文の根拠

C 課長の説明

項番 1 では事前に準備した他人の画像を用いられないようにする必要がある。

C 課長の説明

Q アプリが毎回ランダムな数字を表示し，利用者が g して，直ちに送信することによって，L 社では提出された画像が事前に準備されたものではないことを確認する

項番1は，本人確認書類の画像と容貌の画像を送ってもらう方法であり，攻撃者が事前に入手した他人の画像を送ると，なりすませてしまう。そこで，Q アプリが毎回違うランダムな数字を表示し，利用者がそれを使って，その場で撮影した画像であることを示す。数字は毎回変わるので，事前に準備しておくことはできない。

問題は，数字をどう撮影させるかである。数字だけを撮影した画像では，撮ったのが本人かどうか分からない。そこで，その数字を紙に書き，その紙と一緒に，容貌や本人確認書類を撮影して送る。こうすれば，その場で本人が写っていることを確認できる。採点講評も，“当該数字を撮影する”という解答が多かったが，それでは撮影したのが本人なのか確認できないと述べている。

40字以内に，①数字を紙に書く ②その紙と一緒に容貌や本人確認書類を撮影する，の2点を入れる。解答例は34字である。

採点講評（IPA）

設問2(5)は，正答率がやや低かった。Qアプリが表示するランダムな数字について，“当該数字を撮影する”という解答が多かった。そういった方法では，撮影したのが本人なのかを確認できない。オンラインにおける本人確認手法は，今後も様々な手法が提案されると思われるが，現在使われている最新の手法を理解しておいてほしい。

本文の根拠

〔当人認証〕

ログインが成功した場合は，1 か月間，ログイン状態を保持することを考えた。

表1 注記

銀行口座とのひも付け，チャージ，決済，利用者間の送金を行うには，Q サービスへのログインが必要である。

ログイン状態を1か月間保持すると，その間は Q アプリを開くだけで，Q サービスの決済，チャージ，（将来は）送金などができる。スマートフォンに画面ロックがなければ，端末を手にした第三者は，そのまま Q アプリを開いて，利用者の残高で決済などができてしまう。

したがって，不正利用が行われるのは，スマートフォンを盗まれた場合である。紛失して他人に拾われた場合も同じ理屈だが，解答例は“盗まれた場合”である。

20字以内なので，“スマートフォンを盗まれた場合”（14字）のように，端末が第三者の手に渡る場合を具体的に書く。“ログイン状態の保持が長いと危ない”のように，条件ではなく性質を答えない。採点講評は，オンラインサービスの設計では，どのような不正が発生するのかを洗い出して対策を検討することを心掛けてほしいと述べている。

採点講評（IPA）

設問3(1)は，正答率が平均的であった。オンラインサービスの設計では，どのような不正が発生するのかを洗い出して，対策を検討することを心掛けてほしい。

本文の根拠

〔当人認証〕

そこで，Q サービスにログインした状態を保持することにした上で，

〔当人認証〕

Q サービスにログインした状態で，スマートフォンの画面ロックを設定していないと，Q サービスが不正利用されることがある

画面ロックがなくても，端末を拾った第三者に Q アプリを使わせない方法は，Q アプリ自体に，利用者本人かどうかを確かめる処理を持たせることである。Q サービスへのログイン状態は保持したまま，Q アプリの起動時（又は決済などの操作の前）に，あらかじめ利用者が設定した PIN コードなどで利用者を再度認証する機能を追加する。

これなら，ログイン状態を保持しても，端末を盗んだ人は PIN コードを知らないと Q アプリを使えない。画面ロックの有無という利用者の設定に頼らずに，サービス側で対策できる点が，下線③の“Q アプリに追加する機能”の狙いである。

30字以内なので，“いつ”（Q アプリの起動時）と，“何で何をするか”（PIN コードで利用者を認証する）を入れる。解答例は27字。“ID とパスワードを毎回入力させる”では，ログイン状態を保持して利便性を向上させるという目的に反する。