まず全体像（出題の狙い）
この問題は「スマホ決済」を題材に、(1) なりすまし防止の設計（メッセージ認証/HMAC）と (2) パスワードリスト攻撃の“スクリーニング”対策、さらに (3) 店舗Wi‑Fiやサーバ証明書検証の基本を総合的に問う構成です。モバイル決済では設計を誤ると不正決済のリスクが高く、QR/バーコードやアプリ側に適切な対策を入れる必要がある、というのが出題趣旨です。
物語（システムの舞台設定）
-
N社（外食チェーン、500店舗）が、既存の「ポイントアプリ（会員番号をバーコード表示→店員が読み取ってポイント付与）」を拡張し、自社決済システム Nシステムを導入します。構成要素は①店員用「店舗アプリ」、②利用者用「決済アプリ」、③WebサーバN（決済・ログ取得・アラート通知の中枢）。通信はHTTPSです。
-
決済アプリの主要機能：会員登録（メールをログインIDとして登録→会員番号が自動発番）、ログイン、会員番号（16桁）をバーコード表示、決済完了画面の表示、など。
-
WebサーバNの主要機能：決済/メッセージ中継、ログ取得（会員登録・ログイン・アプリ起動・決済）、アラート（同一IPからの連続ログイン失敗・存在しないIDへの連続試行）を通知。
-
決済処理（もともとの仕組み）：利用者が事前ログイン→金額提示→決済アプリがバーコード（会員番号）を提示→店舗アプリが読み取り→その会員番号に対して決済→双方に完了通知。バーコードの中身は“会員番号”。
-
店舗Wi‑Fi提供：各店の無線LANルータは同一機種で、管理者が手動初期設定。管理画面パスワード、DNSプロキシ（参照DNSのIP）、DHCP、パケットフィルタ等の項目がある。
セキスペYさんの指摘（表6）＝“どこが危ない？”
-
なりすまし決済が可能（ポイントは金銭を直接扱わないが、決済はリスク大）。
-
管理画面パスワードが出荷時のままの可能性（店内から管理画面に入れてしまう）。
-
サーバ証明書の検証が不備（アプリの証明書検証が甘い）。
-
会員登録の挙動からスクリーニング可能（攻撃者がリストから“無効”を事前にふるい落とせる）。
項番1の対策：HMAC入りQRコードで“本人性”を担保
-
方針：単なる会員番号のバーコードでは永続・固定で再利用されやすく、推測/盗用でなりすましされる恐れ。そこで、会員番号＋乱数＋時刻＋HMACをQRコードに入れて都度生成する方式に変更。
-
生成手順（図3の前半）：WebサーバNが持つ秘密鍵Kで、〔会員番号・乱数・時刻〕からHMACを計算→これらをまとめてQRに封入。
-
検証手順（図3の後半）：受け取ったQRの内容から再計算したHMACと整合するか（改ざん検出）をチェックし、さらに時刻が5分以内＆同一QRの再利用なし（リプレイ防止）を確認。要は改ざん不可・使い回し不可・使い切りにする狙いです。
項番2〜4の対策：店舗Wi‑Fiと証明書検証の“穴”を塞ぐ
-
何が起こり得るか（下線①）：もしルータ設定を攻撃者に変えられると、利用者スマホは攻撃者用サーバへ誘導されても気づきにくい（例えばDNSを書き換えられれば、正規FQDNでも偽サイトに連れていける）。
-
具体対策
① ファーム更新で既知脆弱性を解消（外部から管理画面へ入れないようにする）。
② 初期パスワード変更の運用徹底（店内からの勝手な設定変更を防止）。
③ アプリのサーバ証明書検証を厳格化（証明書の名前と接続先が一致・有効期限内をチェック）。 -
証明書検証の中身（図4）：
-
証明書にSubject Alternative Name（dNSName）があれば、それが接続先WebサーバNのホスト名（FQDN）と合致すること。
-
SANが無ければ、subjectのcommonNameと合致すること。
-
もちろん有効期間内であること。
この“名前一致＋期限”の基本を外さない実装が要求されています。
-
-
**ルータ側の“どこを変えられると危険？”**のヒント：DNSプロキシ（参照DNSのIP）を改ざんされると、店内Wi‑Fiにいる利用者の名前解決の行き先を攻撃者のDNSに向けられる＝偽サイト誘導の基盤になります。項目定義は表5参照。
項番5の対策：スクリーニング（IDふるい分け）を封じる
-
問題の本質：会員登録の挙動が“登録済みか否か”を露骨に教える仕様になっていると、攻撃者はメールアドレス候補リストを登録済み/未登録でスクリーニングできます。未登録を除外した“当たりIDリスト”でパスワード攻撃を仕掛けると、サーバのアラート（同一IPでの連続失敗など）に引っかかりにくくなります。
-
対策の方向性：
① 登録時の応答メッセージを統一（“登録済みです”のような情報を漏らさない）。
② 二段階認証の追加（パスワードバイパスの難易度を上げる）。
③ アラート条件の見直し（スクリーニング済みリストによる静かな攻撃も捉えられるように）。
設問は“どこを読ませて、何を書かせるか？”
-
設問1（項番1）
① どうやってなりすまし決済ができるか（具体手段）／② それが成立してしまうアプリ側の問題点。→ “固定バーコード＝会員番号そのもの”の脆弱性に気づけるかが肝。さらに図3のaは、QR内の情報からHMACを検証する処理のことを言わせる設計です。 -
設問2（項番2〜4）
① 下線①の状況で攻撃者が変える設定項目と変更内容（→ 表5のどれか＋具体内容）。
② 図4の空欄（b,c,d）に入る語（証明書のdNSName/SAN、FQDN、commonName等の名称を正しく指摘）。 -
設問3（項番5）
① どんな挙動を利用してスクリーニングできたか（→ 登録フォームの応答差）。
② 表3のどの処理をどう直すか（→ 応答を同一メッセージにする等）。
用語のかんたん解説（本文で出てくるもの）
-
HMAC：メッセージと秘密鍵から作る“改ざん検出用のタグ”。同じ材料で再計算して一致すれば正当。本文ではQR内の会員番号・乱数・時刻と秘密鍵Kで計算。
-
QRコード：バーコードより情報量を持てる2次元コード。本文では会員番号・乱数・時刻・HMACを封入して使い切りトークン化。
-
dNSName（SAN）/ commonName（CN）/ FQDN：証明書の“この証明書はどのホスト名のものか”を示す欄。近年はSAN優先、SANが無ければCNで照合。本文はその基本に沿って照合させる指示。
-
DNSプロキシ：ルータが参照する外部DNSサーバのIP設定。ここを書き換えられると偽サイト誘導の温床に。本文の表5に設定項目として登場。
-
スクリーニング：攻撃前に“有効なIDだけ”を抽出するふるい分け。本文では登録画面のエラーメッセージ差がヒントを与えてしまう。
