Android改ざん検知の「泥沼」：SafetyNet/Play Integrity APIを過信してはいけない理由
エンジニアの諸君、今日もフロントエンドのAPI叩いて終わり、なんて楽観的な開発をしていないだろうか。
特にAndroidアプリのバックエンドを担当していると、「Play Integrity API（旧SafetyNet）を通しているからデバイスは安全だ」という甘い幻想を抱きがちだ。だが断言しよう。そのAPIのレスポンスをそのまま信じているサーバーサイドの設計こそが、攻撃者にとって最も「おいしい」穴だ。
今日は、暗号理論の基礎から、なぜ改ざん検知が突破されるのか、そして実務でどう防ぐべきかを、現場の血の滲むような教訓を交えて解説する。
—
1. なぜ「改ざん検知」は突破されるのか：PoCのリアル
まず、Play Integrity APIの仕組みを理解せよ。これは公開鍵暗号（ECC）を基盤にしている。アプリがGoogleのサーバーから署名付きの判定結果（JWS: JSON Web Signature）を受け取り、それをバックエンドに転送する。
攻撃者の常套手段はこうだ。
1. フック（Hooking）: Frida や Magisk を使い、アプリ内の「判定結果を返す関数」を書き換える。
2. リプレイ攻撃: 正常なデバイスで取得した「判定OK」の署名をキャプチャし、改造アプリから送信する。
3. エミュレーター化: デバイスのハードウェア情報を偽装し、Googleのチェックを欺く。
ここで重要なのは、「APIの結果をアプリ側で判定してはいけない」ということだ。アプリ内のロジックは、攻撃者がメモリを書き換えればどうとでもなる。必ずサーバーサイドで、Googleが署名したJWSを検証しなければならない。
—
2. サーバーサイド検証の鉄則：実装サンプル
Googleから送られてきたJWSには、デバイスの整合性情報が含まれている。これを検証するためのPython実装例を記す。これが「安全の最低ライン」だ。
import jwt
from google.auth.transport import requests
from google.oauth2 import id_token
# 注意: 本来はGoogleの公開鍵エンドポイントから定期的に鍵を取得すること
# ここでは検証ロジックの骨子を示す
def verify_integrity_token(jws_token, expected_package_name):
try:
# Googleの公開鍵を用いて署名を検証し、ペイロードをデコード
# Play Integrity APIのトークンはJWT形式であるため、標準的なライブラリで解析可能
decoded = jwt.decode(jws_token, options={"verify_signature": False}) # 実際は公開鍵で検証必須
# 最も重要なチェック項目
# 1. パッケージ名が一致しているか
# 2. deviceIntegrity が MEETS_DEVICE_INTEGRITY であるか
# 3. appIntegrity が PLAY_RECOGNIZED であるか
if decoded['appIntegrity']['appRecognitionVerdict'] != 'PLAY_RECOGNIZED':
raise Exception("不正なアプリバイナリが検知されました")
if decoded['deviceIntegrity']['deviceIntegrity'] != 'MEETS_DEVICE_INTEGRITY':
raise Exception("デバイスが改ざんされている可能性があります")
return True
except Exception as e:
# ログには詳細を出すが、クライアントには「認証エラー」のみを返すこと
print(f"Integrity check failed: {e}")
return False—
3. Webアプリエンジニアが陥る「盲点」
APIを叩く際、多くのエンジニアが POST リクエストのヘッダーにトークンを載せるだけで満足する。だが、以下の設定が抜けていれば、ネットワークレベルで攻撃を許す。
Nginx/WAFでの防御設定
通信経路の暗号化（TLS）は前提だが、さらに Content-Security-Policy や Request Header の制限を厳格にかけろ。
# Nginx設定例: 不正なパケットやリプレイ攻撃の兆候を遮断
server {
# TLS 1.3以上を強制し、古い暗号スイートを無効化
ssl_protocols TLSv1.3;
# 頻繁なAPI叩きを制限（ブルートフォース/リプレイ対策）
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;
location /api/v1/integrity-check {
limit_req zone=api_limit burst=10 nodelay;
# 許可されたアプリからのリクエストか検証するカスタムヘッダー
if ($http_x_app_signature = "") {
return 403;
}
}
}—
4. 現場のシニアとしてのアドバイス：完全防御は不可能
厳しいことを言うようだが、「100%改ざんを検知できる魔法のコード」は存在しない。 Play Integrity APIをどれだけ厳格に実装しても、高度な攻撃者はゼロデイの脆弱性やOSレベルの特権を利用してくる。
だからこそ、設計思想を「防御」から「検知と追跡」にシフトさせるんだ。
1. スコアリング: Integrity APIの結果だけでなく、アクセスのIPアドレス、デバイスIDの変更頻度、リクエストのパターンをスコアリングし、異常値を叩き出したら即座にアカウントを一時凍結する。
2. ログの永続化: どのバージョンのアプリが、どのOS環境から「偽装」を試みたか、メタデータをすべてデータベースに残せ。これがあれば、後のインシデントハンドリングで攻撃者の傾向を突き止めることができる。
3. キーの保護: サーバーサイドの検証ロジックで使う秘密鍵やAPIキーは、絶対に環境変数にハードコーディングせず、AWS KMS や HashiCorp Vault で保護しろ。
セキュリティとは、「完璧な鍵」を作ることではなく、「何かが起きたときに即座に反応できるシステム」を構築することだ。君たちのコードが、次なる被害を防ぐ砦になることを期待している。
実装で詰まったら、またいつでも相談に来い。コードの海で溺れる前に、立ち止まってアーキテクチャを見直す勇気を持つことだ。それが、一流のエンジニアへの近道だ。
コメント