オンデバイスモデル暗号化が API 認可を代替できない理由

モバイル AI アプリケーションを 7 つのアセットクラスに分解する

モバイル AI セキュリティは往々にして「モデルが暗号化されているか」だけに単純化されがちですが、実際にはモデルファイル、推論ランタイム、入力前処理、出力後処理、プロンプトまたは業務ルール、リモート API 認証情報、ユーザーデータ、ログなど、少なくともこれらが攻撃対象領域に含まれます。各アセットクラスは漏洩時の影響、更新メカニズム、所有権の責務が異なります。

モデル重みのコピーは知的財産の窃取や業務能力の喪失につながり、プロンプトテンプレートや後処理ロジックの改ざんは業務挙動の変更を招きます。長寿命 API キーの漏洩は直接的な金銭的損失、不正なデータアクセス、リソース乱用を引き起こす可能性があり、入出力ログにはユーザープライバシーデータが含まれる場合があります。モデルファイルのみを保護しても、これらの残存リスクをカバーできません。

資産台帳には、保管場所、生成元、伝送経路、ランタイムでの使用パターン、更新およびロールバックの仕組み、最小権限の原則、ログの対象範囲、保持期間を記載する必要があります。ライフサイクルが定義されていない資産は、暗号化スイッチを有効にしただけで保護されたと見なしてはなりません。

モデルファイルはランタイム中に利用可能な状態になる必要がある

Core ML、LiteRT、その他のオンデバイスランタイムのいずれを使用する場合でも、モデルは読み込まれ、解析され、計算に供される必要があります。ファイルレベルの暗号化は、インストールパッケージやアプリディレクトリからの直接コピーの手間を増やすだけであり、実行中のアプリケーションがモデル素材にアクセスすることを防げません。攻撃者がプロセスを制御するか、ランタイムを観察できる場合、リスクモデルは静的ファイルから、読み込み、メモリ、関数呼び出し、および出力へと移行します。

これはモデル暗号化に価値がないことを意味するものではありません。安易なコピーのコストを引き上げ、直接的な置換を防ぎ、パッケージ保護、完全性チェック、ランタイム環境検出、バージョン紐付けと併せて多層防御戦略の一環を構成します。重要なのは、抽出が不可能だと主張するのではなく、攻撃者のコストを増大させ、露出面（blast radius）を縮小するという観点でメリットを提示することです。

モデルの更新は互換性の課題も引き起こします。モデルバージョンは、前処理ロジック、特徴量の形状、ランタイムバージョン、ハードウェア機能、後処理ルールと紐付ける必要があります。更新失敗時には、旧モデルと新ロジックがランダムに組み合わされる事態を防ぐため、安全なロールバックが必須です。

長寿命かつ高権限の API キーをクライアントシークレットとして扱ってはならない

Android のセキュリティ文書では、ソースコードに埋め込まれた API キーはアプリコンパイル後の逆コンパイルにより発見され得ると明記されています。難読化やアプリケーションハードニングにより特定のコストを引き上げることはできますが、クライアントがこれらの認証情報を保持・使用しなければならない事実を変えることはできません。汎用的なクライアント内でキーが長寿命かつ高権限であり続ける限り、漏洩時の影響（blast radius）を制限することは困難です。

Android Keystore は特定の鍵素材のエクスポートを防げますが、公式ドキュメントではアプリケーションプロセスが侵害された場合、攻撃者がアプリの鍵を使用して操作を実行できる可能性があることが明記されています。これはデバイスに紐付けられた秘密鍵やローカル暗号化の保護に適していますが、リモートサービス向けの任意の長寿命共有シークレットに対する安全な保管庫であると誤解してはなりません。

より堅牢なアーキテクチャでは、クライアントがユーザー ID とデバイスコンテキストに基づき自社のサービスから短寿命で制限付きかつ失効可能なトークンを要求するか、サーバーサイドプロキシが高リスクなモデル呼び出しを処理する必要があります。サーバーはアカウント認可、クォータ、レート制限、モデルスコープ、データスコープ、および異常行動の監視を強制しなければなりません。

• 開発、テスト、本番環境ごとに認証情報を分離する
• トークンが持つモデルおよびデータの権限を最小限に抑える
• サーバーサイドでの失効機能を有効化し、クォータとレート制限を強制する
• クライアントが長寿命の高権限共有鍵を保存することを防止する

request = verify_user_session(input.session)
app = verify_app_evidence(input.attestation)
policy = load_policy(user=request.user, app=app.identity)

if policy.version_state == UNKNOWN:
    return CHALLENGE_OR_LIMIT
if policy.account_scope.allows(input.model_scope) == false:
    return DENY
if policy.risk_score >= HIGH:
    return STEP_UP_VERIFICATION

return issue_short_lived_token(
    scope=input.model_scope,
    quota=policy.quota,
    expires_in=policy.short_window
)

完全性シグナルはサーバーサイドの判定にのみ活用すべきである

Play Integrity は Android バックエンドに対し、アプリ識別、デバイス完全性、アカウントライセンス、および部分的な環境リスクに関するシグナルを提供します。Apple App Attest は、デバイス鍵の生成、ワンタイムチャレンジの発行、サーバー上でのアテステーション検証、および後続のアサーション処理を通じて、リクエストが有効なアプリインスタンスから発信されたかをサーバーが判断するのに役立ちます。共通点は、証拠の最終検証がサーバーによって行われることです。

これらの仕組みには明確な境界があります。Play 関連のシグナルは配布ソース、デバイス状態、サービス条件の影響を受けます。また Apple のドキュメントでは、App Attest がすべてのデバイスタイプでサポートされているわけではなく、単一のポリシーですべての不正を排除できるわけではないと記載されています。サーバーは「成功」「失敗」「利用不可」「一時的エラー」「未設定」の状態を区別しなければなりません。「利用不可」を直接攻撃とみなしたり、クライアント側で最終判断を下したりしてはなりません。

完全性シグナルとモデル暗号化は異なる課題に対処します。前者はアプリケーションインスタンスとランタイム環境の検証を支援し、後者は静的モデルの露出を低減します。真の認可には、アカウントコンテキスト、ビジネスリソースチェック、バージョン検証、リクエスト内容分析、クォータ強制、および行動コンテキストが依然として必要です。

モバイル AI アプリケーションの検証には、静的、ランタイム、およびサーバー側の視点が必要

静的チェックは、インストールパッケージ内にどのモデル、設定、文字列、認証情報、およびデバッグリソースが存在するかを回答します。ランタイムチェックは、モデルがどのようにロードされるか、失敗がどのように処理されるか、ログがデータを漏洩していないか、アップデートがロールバック可能かを回答します。サーバー側チェックは、アカウント、バージョン、完全性、クォータ、およびデータ権限が実際に強制されているかを回答します。これら 3 つのエビデンスタイプのいずれかが欠けると、結論が部分的な視点に偏ります。

テストでは、固有のリリース候補と明示的なモデルバージョンを使用し、対象システム、デバイス機能、ランタイムバックエンド、モデルソース、および更新状態を文書化する必要があります。オンデバイス推論のパフォーマンス、メモリ使用量、および互換性は、モデル構造、量子化、ハードウェア、およびランタイムに依存するため、他のモデルやデバイスからの数値を引用することはできません。

例外パスは重要です。モデルファイルの欠落または破損、更新の中断、非対応ランタイム、サーバートークンの有効期限切れ、完全性シグナルの利用不可、ログアップロードの失敗、およびユーザー権限の取り消しが該当します。システムは安全に縮退し、ユーザーと運用チームの双方に対して回復可能な状態を提供する必要があります。

設計結論とスコープの制限事項

モデル暗号化は有効だが、モデルライフサイクルにおける一つの制御点に過ぎない。商用 AI アプリでは、前後処理ロジックの保護、長寿命な高権限鍵のクライアント流入防止、サーバーによる最終認可の実施、プラットフォーム完全性シグナルに対するフォールトトレランスの実装、およびユーザーデータとログのガバナンスも必要である。

実際のリリース候補、モデルバージョン、対象デバイス、およびサーバー側インターフェースがない現状では、アーキテクチャと未検証項目のレビューのみが可能である。モデルの抽出耐性、インターフェースの悪用耐性、ランタイムインジェクションのブロック、またはパフォーマンス目標の達成を主張することはできない。これらの結論には、現時点でのエビデンスパッケージが必要である。

本ページの Yudun によるアクションエントリーポイントは、アプリケーションハードニングと互換性評価の申請用であり、特定のモデルフレームワークや AI 専用機能の検証を表すものではない。プロジェクトスコープは、技術スタック、モデル配信方法、および重要なビジネスパスを提出した後、別途確定する必要がある。

• モデル、ランタイム、認証情報、およびデータ用に個別の登録簿を維持すること
• 高リスクな関数呼び出しの最終認可をサーバーに行わせること
• プラットフォームシグナル利用不可時の代替経路と機能低下モードを用意すること
• モデル更新において、検証、アトミックスイッチング、およびロールバックをサポートすること
• すべての結論を特定のリリース候補とモデルバージョンに紐付けること