【SC試験用語解説】モバイルアプリセキュリティ — OWASP MASVSと証明書ピニング・耐タンパー対策 | 情報処理安全確保支援士問題集

概要

モバイルアプリは端末というユーザの手元（＝攻撃者が物理的にアクセスしうる環境）で動作するため、サーバサイドとは異なるセキュリティ設計が必要です。**OWASP MASVS（Mobile Application Security Verification Standard）**はモバイルアプリのセキュリティ要件を体系化した業界標準であり、**MASTG（Mobile Application Security Testing Guide）**はその検証手順を示すガイドです。SC試験では証明書ピニング・ローカルデータ保護・リバースエンジニアリング対策など、モバイル特有の脅威モデルへの対応が問われます。

仕組みと動作原理

OWASP MASVSの構成

MASVSはモバイルアプリのセキュリティ要件を複数のカテゴリ（MASVS-STORAGE、MASVS-CRYPTO、MASVS-AUTH、MASVS-NETWORK、MASVS-CODE、MASVS-RESILIENCEなど）に分類して定義しています。Webアプリ向けのOWASP Top 10とは異なり、端末というユーザの物理的管理下にある実行環境を前提にしている点が特徴です。

カテゴリ	主な要件領域
STORAGE	端末内データの保存・暗号化
CRYPTO	暗号鍵の管理・暗号アルゴリズムの適切な利用
AUTH	認証・セッション管理・生体認証の安全な利用
NETWORK	通信の暗号化・証明書検証
CODE	コード品質・サードパーティライブラリの管理
RESILIENCE	リバースエンジニアリング・改ざんへの耐性

OWASP MASVSの主要カテゴリ

ローカルストレージの暗号化

モバイル端末は紛失・盗難のリスクが高く、端末内に保存されたデータは攻撃者に物理的にアクセスされる前提で保護する必要があります。

保存先	リスク	対策
平文の設定ファイル・SQLite DB	ルート化／脱獄端末や端末盗難で読み取られる	OSが提供する暗号化ストレージAPIを使用（Android Keystore、iOS Keychain）
SharedPreferences／UserDefaults	平文保存されがちでバックアップにも含まれる	機密情報は保存しない、または暗号化してから保存
キャッシュ・ログファイル	デバッグ用途で機密情報が残存しやすい	機密データをログ・キャッシュに含めない設計

トークンや個人情報などの機密データは、OSのセキュアストレージ機構（Android Keystore・iOS Keychain）に鍵を保管し、その鍵でデータを暗号化する構成が基本です。アプリ独自にハードコードした鍵で暗号化しても、APKやIPAを解析すれば鍵自体が抽出されてしまうため意味がありません。

証明書ピニング（Certificate Pinning）

通常のTLS通信は、端末にインストールされた信頼済みルート証明書のいずれかで検証されたサーバ証明書を信頼します。しかし、企業のプロキシやマルウェアによって端末に不正なルート証明書がインストールされていると、中間者攻撃（MitM）によって通信を盗聴・改ざんされるリスクがあります。

証明書ピニングは、アプリ側にあらかじめ「正規サーバの証明書（またはその公開鍵のハッシュ）」を埋め込んでおき、TLSハンドシェイクで受け取った証明書がそれと一致するかを追加で検証する仕組みです。

通常のTLS検証：
  端末の信頼済みCAストアにあるいずれかのCAで検証できればOK
  → 不正なルート証明書が端末に入っていると迂回される

証明書ピニングを追加した場合：
  端末のCAストアでの検証に加えて、
  アプリに埋め込んだ「正規サーバの証明書/公開鍵ハッシュ」と一致するかを検証
  → 不正なルート証明書があっても、ピン留めされた鍵と一致しなければ通信を拒否

証明書ピニングによる検証の流れ

ピニングの弱点は、サーバ証明書を更新した際にピン情報も更新しないと正規の通信まで遮断してしまうことです。そのため公開鍵ハッシュをピン留めし、中間CA単位でピン留めするなど運用性とのバランスを取る設計が使われます。

リバースエンジニアリング対策（RESILIENCE）

モバイルアプリのバイナリはユーザの端末上で配布されるため、逆コンパイル・逆アセンブルによる解析が容易です。攻撃者はアプリを解析してAPIキーの抽出・ロジックの改ざん・不正コピーなどを行います。

対策	内容
難読化（Obfuscation）	クラス名・メソッド名を意味のない文字列に変換し、逆コンパイル結果の可読性を下げる
改ざん検知（Tamper Detection）	アプリの署名・チェックサムを実行時に検証し、改ざんされたバージョンでの動作を拒否
ルート化／脱獄検知	root化・jailbreak済み端末を検知し、機能制限や警告を行う
デバッガ検知（Anti-Debugging）	実行時にデバッガのアタッチを検知して解析を妨害
コード分割（重要ロジックのサーバ移譲）	決済判定など重要なロジックはクライアントに置かず、サーバ側で処理する

難読化・改ざん検知はあくまで解析コストを引き上げる緩和策であり、完全な防止ではない点がSC試験でも問われるポイントです。

モバイル特有の認証：生体認証APIの安全な利用

生体認証（指紋・顔認証）自体をアプリが直接扱うことはなく、OSが提供するセキュアな認証APIを介して利用します。

実装パターン	安全性	説明
生体情報そのものをアプリが取得・保存	危険（非推奨）	OSは通常この方式を許可しない。仮に実装できても情報漏洩時の被害が甚大
OS APIで認証結果（成功/失敗）のみ受け取る	不十分	端末が改造されていると結果を偽装される余地がある
OS APIで鍵の使用をロック	推奨	生体認証成功時のみセキュアエンクレーブ内の鍵にアクセス可能にする（Android BiometricPrompt + Keystore、iOS Face ID + Secure Enclave）

生体認証の実装パターン比較

「認証に成功したらtrueを返す」という設計は、改造されたアプリや端末では容易にバイパスされます。生体認証の成功と、実際に機密データ・鍵へのアクセスが技術的に紐づいていることが安全な実装の条件です。

SC試験での頻出ポイント

証明書ピニングの目的：端末に不正なルート証明書が入っていても中間者攻撃を防ぐための追加検証
証明書ピニングの運用リスク：サーバ証明書更新時にピン情報を更新し忘れると正規通信まで遮断される
ローカルストレージ暗号化の鍵管理：アプリ独自のハードコード鍵ではなくOSのセキュアストレージ（Keystore/Keychain）を利用する
難読化・改ざん検知は「防止」ではなく「緩和」：解析・改ざんのコストを上げる対策であり、完全に不可能にはできない
生体認証の安全な設計：認証結果のフラグだけでなく、鍵へのアクセス自体を生体認証にひも付ける

よくある誤問・ひっかけパターン

誤り① 「証明書ピニングを実装すればTLS通信は完全に安全になる」→ 誤。ピニングは中間者攻撃への耐性を高めますが、証明書更新時の運用ミスで正規通信が止まるリスクや、端末自体が侵害されている場合の限界があります。TLS自体の設定不備は別途対処が必要です。

誤り② 「難読化すればリバースエンジニアリングは不可能になる」→ 誤。難読化は解析を困難にする緩和策であり、時間と労力をかければ解析は可能です。重要なロジックはサーバ側に置くなど多層的な対策が必要です。

誤り③ 「生体認証はOSが『認証成功』と返せばアプリ側の実装は何でもよい」→ 誤。認証結果のフラグのみに依存する実装は改造アプリでバイパスされる恐れがあります。鍵の使用自体を生体認証に紐づける設計が推奨されます。

重要キーワード

用語	説明
OWASP MASVS	モバイルアプリのセキュリティ要件を体系化した検証標準
MASTG	MASVSの各要件を検証する手順を示すテストガイド
証明書ピニング	アプリに正規サーバの証明書/公開鍵を埋め込み中間者攻撃を防ぐ手法
難読化（Obfuscation）	逆コンパイル結果の可読性を下げてリバースエンジニアリングを困難にする対策
セキュアエンクレーブ／Keystore	鍵を端末内の隔離領域で保護し外部に取り出せなくする仕組み
改ざん検知（Tamper Detection）	アプリの署名やチェックサムを実行時検証し不正な改変を検出する仕組み