情報処理安全確保支援士 2013年 秋期 午後1 問02

解答の論理構成

• 本文で B さんは
  「スマートフォンには、IMEI（International Mobile Equipment Identity） などの固有の端末識別番号が付与されていますので、これを用いて利用者を認証することを考えています。」
  と発言し、端末識別番号を認証用識別子に流用しようとしました。
• これに対し C 課長は
  「①端末識別番号の値をそのまま利用者認証に使うわけにはいかないな。」
  と否定しています。
• 否定の理由は、端末識別番号が機器に刻印されるなどして既に多くの関係者に知られている可能性があり、外部から容易に取得・模倣できるからです。本人しか知り得ない情報（パスワードやトークン）とは違い、秘密に保たれていないため、番号を盗用されれば「なりすまし」が発生します。
• よって C 課長の判断は「端末識別番号は秘密情報ではない」という特性を問題視したものです。

誤りやすいポイント

• 「固有番号＝安全」と短絡的に考え、番号が公開情報になり得る点を見落とす。
• 盗聴リスクや通信路の暗号化の有無と混同し、識別子そのものの公開性を評価対象から外してしまう。
• SIM カードの ICCID などと混同し、「通信事業者しか読めない」と誤認する。

FAQ

解答の論理構成

• 本文では、Bさんが「端末識別番号を基にスマホアプリ内で②鍵付きハッシュ関数で算出したハッシュ値を使う」と発言しています。ここで求められているのは“鍵（キー）を用いてハッシュ値を生成する方式”です。
• 鍵付きハッシュ関数の代表例は HMAC（Keyed‐Hash Message Authentication Code）であり、メッセージと秘密鍵を入力にして MAC（Message Authentication Code）を生成します。
• 解答群の候補を機能で整理すると
  • 「ア：AES」…共通鍵暗号方式（ハッシュではない）
  • 「イ：HMAC」…鍵付きハッシュ関数
  • 「ウ：RIPEMD」「エ：SHA-256」…いずれも鍵を用いない通常のハッシュ関数
• したがって、②に該当するのは「イ：HMAC」と導けます。

誤りやすいポイント

• 「SHA-256 もハッシュだから鍵を付ければ良いのでは」と誤解しやすいですが、SHA-256 単体は“鍵付き”ではありません。
• AES を“鍵を使う＝鍵付き”と早合点するケース。AES は暗号アルゴリズムであってハッシュ関数ではありません。
• 「RIPEMD は HMAC-RIPEMD として使えるからウでもよい」と考えるのは早計です。問題文は“鍵付きハッシュ関数そのもの”を問うており、純粋なアルゴリズム名として HMAC が正答になります。

FAQ

解答の論理構成

• 【問題文】には、端末識別番号をハッシュ化する案に対し、C課長が「③鍵を秘密にしておくことが難しい」と指摘しています。
• 鍵をスマホアプリ内に格納する場合、攻撃者は配布されたアプリを自由に解析できます。
• スマートフォンアプリは Java bytecode や ARM ネイティブコードなどに変換されており、逆コンパイル・デバッガ・動的トレーサを使えばプログラム内部の文字列や定数を抽出できます。
• したがって、攻撃者はアプリの実行ファイルを解析して埋め込まれた鍵を取得できるため、「秘密にしておくことが難しい」という結論に至ります。
• この一連の行為は一般に「リバースエンジニアリング」と呼ばれるため、解答は「スマホアプリをリバースエンジニアリングする」となります。

誤りやすいポイント

• ネットワーク盗聴やパケットキャプチャを想定してしまう。鍵は通信に流れず、実行ファイル内部にある点が見落とされやすいです。
• スマートフォンの root 化や物理解析を答えてしまう。root 権限が無くても APK 解析ツールで十分に鍵を抽出できます。
• 「コード改ざん」と答えるケース。改ざんは結果であり、鍵を得るための主な手段はリバースエンジニアリングです。

FAQ

解答の論理構成

1. 現行案の問題点
   表1の予約案内では「スマートフォン内のアドレス帳の全件データをWebAPに送信」していました。
2. プロジェクトメンバの指摘
   「アドレス帳の全件データがR社に送信されることについては利用者に説明していないので問題である」と多数が指摘しました。
3. Bさんの対応方針
   説明と同意確認だけでは不十分として「“アドレス帳の全件データの送信”が行われない別の案（以下、A案という）が提示」され、採用されました。
4. 要求される機能
   A案は“全件送信しない”ことが本質です。必要なのは予約案内に使うメールアドレスだけであり、スマートフォン上で利用者に選択させれば十分です。
5. したがって、スマホアプリ側で選択したメールアドレスだけをWebAPへ渡す方式が最小限の情報提供となり、プライバシー問題を解決できます。
6. 以上より模範解答「スマホアプリでメールアドレスを選択して、それをWebAPに送信する。」が導かれます。

誤りやすいポイント

• 「確認画面に説明を追加するだけで良い」と思い込み、実装変更を忘れる。
• 部分送信ではなく“予約に関係しそうな連絡先だけ”など曖昧な基準で抽出しようとする。全件送信と大差なく、要件を満たさない。
• WebAP側でアドレス帳を保持し続けてしまい、目的外利用のリスクを残す。

FAQ

解答の論理構成

1. 図3の動作概要では、 　・「YoyakuCode の値が DBサーバに保持されている予約明細コードと一致しない場合はアプリケーションエラーを返す。」
   　・「DateTime の値とサーバ側の時刻とのずれが 5 分以上の場合はアプリケーションエラーを返す。」
   　と明記されています。
2. 表2を見ると、 　・「YoyakuCode パラメタの値を 201310000071 に変更」⇒「YoyakuCode が 201310000071 の予約情報の表示」
   　・「DateTime パラメタの値を現在から 4 分前の時刻に変更」⇒「YoyakuCode の値に該当する予約情報の表示」
   　・「DateTime パラメタの値を現在から 5 分前の時刻に変更」⇒「アプリケーションエラー」
   　となっており、YoyakuCode と DateTime を適切に改ざんすれば他人の予約情報を取得できる事実が示されています。
3. したがって利用者Vは、図4のリクエスト中の
   　① YoyakuCode を利用者Wの値（例：201310000071 等）に変更
   　② DateTime を送信時刻との差が 5 分未満となる値（例：現在から 4 分前）に変更
   　することで図5相当の応答を得られました。

誤りやすいポイント

• AuthKey を別利用者のものに変えれば十分だと誤解しやすいですが、表2では AuthKey を改ざんしても YoyakuCode が変わらなければ V 自身の予約情報が返っており、必須なのは YoyakuCode と DateTime の組合せです。
• DateTime は「5 分未満」であれば何でも良い点を見落としやすく、具体的な値を固定的に答えてしまうと減点の恐れがあります。
• YoyakuCode と予約番号の関係（「月ごとに全利用者の予約を000001から順番に割り振る」）を読み飛ばし、他人のコードが類推可能である点に気付かないケースが多いです。

FAQ

解答の論理構成

1. 既存仕様では
   “(c) AuthKeyの値がWebAPに保持されている利用者認証用の値と一致しない場合は認証エラー”
   “(d) YoyakuCodeの値がDBサーバに保持されている予約明細コードと一致しない場合はアプリケーションエラー”
   と個別チェックしか行っていません。
2. 表2では
   “AuthKey パラメタの値を別利用者の値に変更” → “YoyakuCode が 201310000034 の予約情報の表示”
   “YoyakuCode パラメタの値を 201310000071 に変更” → “YoyakuCode が 201310000071 の予約情報の表示”
   となっており、異なる利用者の AuthKey と YoyakuCode の組合せでも正常応答してしまうことが分かります。
3. 問題点は、図3の2.(c)(d)だけでは「同一利用者の組合せであること」を確認していないことです。
4. そこで “④利用者Vが…二つの値を変更して送信すると…利用者W…の応答を得られる” という不正取得を防ぐため、 AuthKey に紐づく予約明細コード以外が指定された場合はエラーにする仕様を追加する必要があります。
5. 以上より模範解答の
   “YoyakuCode の値が AuthKey に対応する予約明細コードでないときはアプリケーションエラーを返す。”
   が論理的帰結となります。

誤りやすいポイント

• AuthKey と YoyakuCode を「どちらかが正しければよい」と誤解し、組合せチェックの必要性を見落としがちです。
• “LANG” や “DateTime” の制御ミスに気を取られ、本質的な認可不備（水平権限チェック漏れ）を指摘しない答案を作成しやすいです。
• “予約番号は月ごとに全利用者の予約を000001から順番に割り振る” という仕様から「推測容易性」を答えに混ぜてしまうと設問意図から外れて減点されます。

FAQ