午前I問題

スマートフォンアプリケーションのセキュリティ上の特性に関する記述のうち、最も適切なものはどれか。

ア）モバイルアプリはサーバ側のWebアプリケーションと異なり、実行環境（端末）が攻撃者の管理下に置かれる可能性を考慮する必要はない

イ）モバイルアプリは配布パッケージ（APK・IPA等）を端末にインストールする性質上、逆コンパイルや静的解析による内部ロジック・埋め込み情報の解析リスクを考慮した設計が必要である

ウ）App StoreやGoogle Playの審査を通過したアプリは、脆弱性が存在しないことが保証されている

エ）モバイルアプリはネイティブコードで実装されるため、Webアプリケーションと異なりネットワーク盗聴のリスクは存在しない

午前I の解答・解説を見る

正解： イ）モバイルアプリは配布パッケージ（APK・IPA等）を端末にインストールする性質上、逆コンパイルや静的解析による内部ロジック・埋め込み情報の解析リスクを考慮した設計が必要である

解説：

  • ア）不正解。モバイルアプリはエンドユーザの端末（攻撃者が完全に制御できる可能性がある環境）で動作するクライアントサイドのソフトウェアであり、サーバのようにインフラを事業者が管理できない。ルート化・脱獄された端末や改ざんされた端末で動作する前提の設計（脅威モデル）が必要。
  • イ）正解。APKやIPAなどの配布パッケージは端末にダウンロードされるため、攻撃者が入手して逆コンパイル・逆アセンブルし、ソースコードに近い形で内部ロジックやハードコードされたAPIキー・シークレットを解析できてしまう。これを前提にコード難読化やシークレットの非埋め込み設計が求められる。
  • ウ）不正解。ストア審査はマルウェア混入などの明白な不正の検知が主目的であり、個々のアプリのロジック脆弱性（認可不備、暗号化不備等）まで保証するものではない。
  • エ）不正解。ネイティブコードであってもHTTP/HTTPS通信を行う以上、Wi-Fi環境等でのネットワーク盗聴・中間者攻撃のリスクはWebアプリケーションと同様に存在する。

午前II問題

モバイルアプリにおける証明書ピニング（Certificate Pinning）の説明として、最も適切なものはどれか。

ア）アプリ内にサーバの正規証明書（またはその公開鍵のハッシュ値）を組み込み、通信時にサーバから提示された証明書と照合することで、不正な証明書を用いた中間者攻撃を検知・遮断する仕組みである

イ）端末のOS標準の証明書ストアに信頼済みのルート証明書を追加登録する操作のことである

ウ）証明書ピニングを実装すれば、TLSのバージョンを問わず暗号化強度が自動的に最高水準になる

エ）証明書ピニングは主にサーバ証明書の有効期限切れを自動検出・通知するための仕組みである

午前II の解答・解説を見る

正解： ア）

解説：

  • ア）正解。証明書ピニングは、アプリにあらかじめ信頼すべきサーバの証明書またはその公開鍵のハッシュ値を組み込んでおき、実際の通信時にサーバから提示された証明書と照合する仕組み。CA（認証局）が発行した不正な証明書や、端末にインストールされた悪意あるルート証明書を用いたプロキシ経由の中間者攻撃を検知・遮断できる。
  • イ）不正解。これは証明書ストアへの登録操作の説明であり、証明書ピニングとは別の概念（むしろ攻撃者が中間者攻撃用の証明書を端末に信頼させる手口として悪用されることがある）。
  • ウ）不正解。証明書ピニングは通信相手の正当性を検証する仕組みであり、TLSの暗号化強度（暗号スイート等）を自動的に引き上げるものではない。
  • エ）不正解。証明書ピニングの主目的は中間者攻撃対策であり、有効期限切れの自動通知機能ではない。むしろピン留めした証明書が更新期限切れになった際にアプリ側での更新（ピンのローテーション）を怠ると、正規通信までブロックしてしまう運用上の注意点がある。

午後問題

金融系スマートフォンアプリを提供するF社は、ある日「アプリ内に埋め込まれたAPIキーが第三者のブログで公開され、そのキーを用いて非公式クライアントからAPIが呼び出されている」との報告を受けた。

調査の結果、次の事実が判明した。

  • Androidアプリ（APKファイル）にはバックエンドAPI呼び出し用のAPIキーが、文字列リソースとしてそのまま埋め込まれていた
  • APKファイルはAPKツール等で誰でも容易に逆コンパイルでき、埋め込まれた文字列リソースはそのまま平文で読み取れる状態だった
  • アプリはTLS通信を行っていたが、証明書ピニングは実装されておらず、プロキシツールを用いた通信内容の解析も比較的容易であった
  • バックエンドAPIは、リクエストにAPIキーさえ含まれていれば正規のアプリからのリクエストとして処理する実装になっていた

設問1

APIキーの平文埋め込みとバックエンドAPI側の実装に起因する問題を踏まえ、F社が講じるべき恒久対策を、クライアント側とサーバ側それぞれの観点から述べよ。

設問1の解答・解説を見る

正解例：

クライアント側： APIキーのような固定シークレットをアプリ内に平文で埋め込む設計自体を見直し、ユーザ認証（ID・パスワードやOAuth 2.0等）に基づいて発行される、有効期限付きのアクセストークンを都度サーバから取得する方式に変更する。難読化やネイティブコード（NDK）への格納はリバースエンジニアリングを困難にはするが根本解決にはならない点に注意する。

サーバ側： 「APIキーが正しいか」のみで正規クライアントと判定する実装をやめ、ユーザ単位の認証・認可（トークンの検証、有効期限チェック、失効の仕組み）を必須化する。加えて、異常なリクエストパターンを検知するレート制限や、非公式クライアントを検知するための追加の仕組み（アプリ整合性検証等）を組み合わせる。

解説・採点基準（計15点）：

採点項目キーワード配点
クライアント側：固定APIキー埋め込みからの脱却、ユーザ単位トークンへの言及「アクセストークン」「ユーザ認証ベース」「有効期限付き」6点
サーバ側：APIキーのみに依存しない認可の実装に言及「ユーザ単位の認可」「トークン検証」「失効の仕組み」6点
難読化等は根本対策ではない旨への言及（加点要素）「難読化だけでは不十分」3点

「難読化を強化する」のみの回答は、リバースエンジニアリングの難易度を上げる緩和策に過ぎず、APIキーが固定シークレットである限りいずれ解析されるリスクが残るため、根本対策としては部分点（最大6点）に留める。

設問2

通信内容の解析を困難にするための技術的対策を1つ挙げ、その効果と運用上の注意点を述べよ。

設問2の解答・解説を見る

正解例： 証明書ピニングを実装する。アプリにサーバの正規証明書（または公開鍵ハッシュ）を組み込み、通信時に照合することで、プロキシツールなどが提示する自己署名証明書やユーザ端末に追加でインストールされた不正なルート証明書を用いた中間者攻撃による通信内容の解析・改ざんを検知・遮断できる。運用上の注意点として、サーバ証明書の更新（有効期限切れによる証明書の入れ替え）に合わせてピン情報も更新する必要があり、更新を怠るとアプリの正規通信自体が失敗してしまう「ピン切れ」のリスクがあるため、証明書更新計画とアプリの更新配布計画をあらかじめ連携させておく必要がある。

解説・採点基準（計15点）：

採点項目キーワード配点
証明書ピニングの実装に言及「証明書ピニング」「公開鍵ハッシュの照合」6点
中間者攻撃・プロキシ解析の防止効果に言及「中間者攻撃の検知・遮断」「プロキシツールでの解析防止」5点
証明書更新に伴う運用上の注意点に言及「ピン切れ」「証明書更新との連携」4点

重要キーワード

用語説明
モバイルアプリセキュリティスマートフォンアプリ特有の脅威（端末が攻撃者管理下にある前提）に対応するセキュリティ設計全般
証明書ピニングアプリにサーバの正規証明書・公開鍵を組み込み、通信時に照合して中間者攻撃を検知・遮断する仕組み
リバースエンジニアリング配布された実行ファイル（APK・IPA等）を逆コンパイル・逆アセンブルして内部ロジックを解析する行為
コード難読化ソースコードや中間コードを解析困難な形に変換し、リバースエンジニアリングの難易度を高める対策。根本対策ではなく緩和策
アクセストークンユーザ認証に基づき発行される、有効期限・スコープを持つ一時的な認証情報。固定APIキーより安全性が高い
ピン切れ証明書ピニング実装後、サーバ証明書の更新にアプリ側のピン情報が追従できず正規通信が失敗する運用上の問題

まとめ

  • 午前I視点： モバイルアプリは端末という攻撃者が制御しうる環境で動作するため、逆コンパイルによる内部ロジック・埋め込み情報の解析リスクを前提とした設計が必要。
  • 午前II視点： 証明書ピニングはサーバ証明書・公開鍵をアプリに組み込み照合することで中間者攻撃を防ぐ仕組みであり、証明書ストアへの登録操作や暗号強度の自動向上とは異なる概念。
  • 午後視点： APIキーの平文埋め込みとキーのみによるサーバ側認可は典型的な脆弱設計。クライアントはユーザ単位のトークン方式へ、サーバは適切な認可検証へ移行するのが根本対策であり、証明書ピニングは通信解析対策として併用する。