App Attestによるアプリの保護

こんにちは、Manthanです Trust and Safety チームの エンジニアです App Attest がアプリと ユーザーを守る方法を説明します 皆さんはアプリを構築し Apple プラットフォームの 安全な環境に配布しました 不正行為者は常に アプリを悪用する方法を探しています 意図した機能の範囲を超えた 形で利用しようとしています これには、改ざんされたアプリのコピーが サーバーに正当なリクエストを送り 機密データにアクセスする攻撃シナリオが含まれます 例えば、試験監視アプリを 構築したとします 学生がクイズを受けて 回答を送信するアプリです 不正行為者がアプリをリバースエンジニアリングして 偽のクイズ回答をサーバーに送信する 改ざんコピーを作成する可能性があります App Attest を使えば、サーバーが このようなリクエストを拒否できます 改ざんされたクライアントからの または、出荷していないコンテンツを 含めるようにアプリを改ざんすることもあります ソースコードの改ざんされたコピーを 直接変更して 関連するリソースバンドルを変更し アプリを再署名し 改ざんされたコピーを デバイスで実行します 例えば、ドラゴンスレイヤーゲームが あるとします 不正行為者がゲームの能力を高める チートメニューを注入したとします これにより、不正なスコアを サーバーに送信できるようになり 改ざんされたゲームアプリのコピーで リーダーボードの上位に入ることができます App Attest はこのような 脅威シナリオに対処するために設計されています まず、App Attest が 何を保護するかから始めます 次に、統合手順と ベストプラクティスを説明します よくある落とし穴を指摘し 最後に不正指標について説明します 不審なアテステーションアクティビティを 検出するための強力なツールです App Attest がアプリを 保護する方法から始めます App Attest は、アプリが 正規の Apple ハードウェアで動作していることを確認できます これはアテステーションを発行することで行われ 暗号的な証明を提供します ユーザーのデバイスで動作している アプリの有効性についての証明です これはサーバーで検証でき アプリが安全な Apple デバイスで 動作していることを確認できます 次に、App Attest はアプリへの 改ざんを検知するのに役立ちます ユーザーのデバイス上での改ざんです App Attest は、リライングパーティに 関する情報を提示します 起動カテゴリ、バンドルバージョンなど アプリに関連する情報です これらはすべて、アプリが 改ざんされているかどうかの判断に役立ちます アプリはリライングパーティ識別子によって 一意に識別されます これは Team Identifier と Apple デベロッパの Provisioning Profile の Bundle Identifier を連結したものです 不正行為者がアプリを改ざんして Team Identifier に一致しない Provisioning Profile で再署名したとします App Attest はユーザーのデバイス上で アプリのアイデンティティを提示し 不正な改ざんを発見できるようにします iOS 27 の新機能として ユーザーのデバイス上でアプリの 起動検証カテゴリを強調表示します App Store を通じて アプリを配布していても App Attest が TestFlight の 起動検証カテゴリを示す場合があります また、出荷したアプリバージョンの バンドルバージョンも識別します 不正行為者が更新されたバンドルバージョンで アプリを再署名した場合 把握していない再署名が行われても App Attest を通じて明らかになります 最後に、App Attest を使って アプリからサーバーへのペイロードを保護できます App Attest はアサーションを生成できます 以前に発行されたアテステーションの 暗号プロパティを使用して サーバーはアプリからのペイロードの アサーションを検証でき ペイロードが転送中に 改ざんされていないことを確認できます 以上を踏まえて App Attest の仕組みと 導入方法を説明します App Attest の各コア部分を 説明していきます まず、App Attest が 利用可能な場所を確認します App Attest はすべての Apple プラットフォームでサポートされており 以前はサポートされていなかった macOS 27 以降も含まれます App Attest はすべての主要な Apple OS で利用可能ですが これらのプラットフォーム上のすべての アプリタイプで使用できるわけではありません App Attest の使用は isSupported API で 制御してください App Attest フレームワークの 例えば、App Attest は Action および SSO アプリ拡張で利用できますが 他の種類のアプリ拡張では使用できません isSupported のレスポンスを 不正シグナルとして使用することもできます リスク評価に組み込んで サポートされたプラットフォームに アプリを配布していて 特定のユーザーから未サポートの レスポンスが急増した場合 改ざんの可能性があります App Attest がサポートされていない場合に ユーザーがアプリの機能を 使用できるかどうかを決める必要があります 次に、App Attest ワークフローの 最初のステップに移ります Key ID の生成です アプリは App Attest を呼び出して Key ID を生成することから始めます App Attest はアプリの代わりに Secure Enclave に紐付けられたキーペアを作成します 秘密鍵は Secure Enclave に格納されます App Attest は公開鍵のハッシュを アプリに返します アプリは Key ID を Keychain に保存します App Attest のキーを扱う際には いくつかのベストプラクティスがあります アカウントベースのアプリには 1ユーザーにつき1つのキーを生成してください またはユーザーのデバイスで アプリ全体に1つのキーを使用します ユーザー間でキーを 共有しないでください アプリが生成した Key ID の保存には Keychain を使用してください Key ID はアプリがインストールされている 間有効です アプリのアップデートでも維持されますが ユーザーがアプリを再インストールするか デバイスを復元すると iCloud バックアップからの復元も含め キーは無効になります キーはデバイスごとに管理され ユーザーのデバイス間では同期されません 以上が App Attest のキー生成です これらはアテステーションと アサーションの基礎を形成します アプリが Key ID を生成したので App Attest にキーの アテステーションを要求できます アプリは Keychain から Key ID を取得します アプリはサーバーに Key ID のアテステーションを要求します サーバーはアプリに チャレンジを返します アテステーションに含めるためのチャレンジです アプリはアテステーション API を呼び出し App Attest フレームワークの API に Key ID とサーバーチャレンジを渡します App Attest は Key ID の キーペアを取得します デバイスのアテステーションデータと共に このアテステーションデータは Secure Enclave から得られます ブート時のデバイスのハードウェア プロパティのスナップショットを含んでいます 変更することはできません Apple サービスへの サーバーリクエストを開始します デバイスデータを検証し アテステーションを返します App Attest はアテステーション オブジェクトをアプリに返します アプリはアテステーションを サーバーに送信します サーバーはアテステーションを 検証する必要があります 次にその手順を説明しますが 保存してアプリのユーザーと 関連付ける必要があります アテステーションを収集・処理する際には いくつかのベストプラクティスがあります サーバーがアテステーションの開始を 制御することが重要です これにより、アプリが安全な 秒間リクエスト数の上限内に 収まるようにできます アテステーションの失敗が発生した場合 アプリはしばらく後に再試行してください グローバルなレート制限に達しないよう 指数バックオフを実装してください 再試行ロジックを アプリにハードコードしないでください Apple アテステーションサーバーへの 制御できない急増を最小限に抑えるためです アプリはユーザーフローの外で アテステーションを収集してください アテステーション操作は バックグラウンドタスクで実行してください 最後に、アテステーションは アプリではなくサーバーで検証してください アプリが侵害された場合 アテステーションの検証には信頼できません 次にアテステーション自体について説明します App Attest のアテステーション API から 返されるオブジェクトです アテステーション構造には 3つのセクションがあります フォーマット、アテステーションステートメント およびオーセンティケーターデータです フォーマットは、Apple の 匿名アテステーションを識別する固定文字列です 次に、アテステーションステートメントは 暗号化された証明書チェーンと レシートを埋め込んでいます 証明書チェーンは アテストされたキーが正規の Apple ハードウェアで生成されたことを証明します デベロッパドキュメントに従って 証明書チェーンを検証してください nonce と Key ID が含まれており リライングパーティ識別子が リーフ証明書に埋め込まれています macOS 27 以降では キーアクセス制御プロパティ、 ACL Blob OID と呼ばれるものが リーフ証明書にも含まれます これは App Attest キーに関連する セキュリティ条件を表します Secure Enclave によって適用された条件で デバイスでアテステーションが 収集された時点のものです キーアクセス制御プロパティは すべてのプラットフォームで利用できますが macOS では特に重要です macOS では、App Attest が 生成された各キーを設定します フルセキュリティモードと System Integrity Protection を要求するポリシーで フルセキュリティモードは 最高レベルのセキュリティを確保し ユーザーのデバイス上のオペレーティング システムの整合性を検証します System Integrity Protection は 不正なコードの実行を防止し システムパスを保護します これらは両方とも Mac デバイスでデフォルトで有効です キーアクセス制御プロパティを 検証することで ユーザーのデバイスに適用された セキュリティ条件を確認できます アテステーションステートメントには レシートも含まれています これは App Store レシートに 似たフォーマットで 解析にはデベロッパドキュメントを 参照してください リライングパーティ ID、アテストされたキー およびサーバーチャレンジを検証してください これらはレシートに含まれています サーバーは不正指標との連携のために このレシートを保存してください 最後に、オーセンティケーターデータは アプリとアテステーションに関する 情報を識別します デベロッパドキュメントに従って オーセンティケーターデータを展開し 内容を検証してください iOS 27 以降では オーセンティケーターデータの末尾に extensions と呼ばれる新しい構造が追加されます これは Web 認証標準に従って フォーマットされています オーセンティケーターモデルのためのものです extensions について サーバーがオーセンティケーターデータの このセクションを処理する方法を説明します Extensions はアプリに関する 追加のセキュリティプロパティを説明します アテステーションプロセス中に デバイスで収集されます 2つの extension 識別子が追加されました 起動検証カテゴリと バンドルバージョンです 起動検証カテゴリは アプリが予期しない環境で 実行されているかどうかを把握するのに役立ちます バンドルバージョンは 配布したアプリバージョンが ユーザーのデバイスで 実行されていることを確認するのに役立ちます これらのプロパティを監視し 予期しない値がないか確認してください ユーザーの総合的なリスク評価に 組み込んでください 以上がアテステーションです 改ざんの兆候を検出するのに 特に役立ちます 例えば、App Attest と統合された macOS アプリがあるとします 不正行為者が System Integrity Protection を 無効にするシナリオを考えてみましょう その後、アプリを改ざんして 別の Provisioning Profile で再署名し システムパスの App Attest フレームワークを改ざんします サーバーで受信したアテステーションは 無効化された System Integrity Protection の状態を キーアクセス制御プロパティで示します 変更された Team Identifier も 含まれる場合があります 起動検証カテゴリや バンドルバージョンも同様です サーバーは改ざんされたアプリのコピーとの 通信を拒否でき これをユーザーの リスク評価に組み込めます サーバーがアテステーションを検証して 公開鍵を保存したので アプリはそのアテストされたキーを使って アサーションによる継続的な 通信を保護できます アプリはサーバーとの データ通信の準備をします サーバーはアプリのペイロードに 含めるチャレンジを返します アプリは Key ID を取得し App Attest フレームワークの アサーション API を呼び出します Key ID と サーバーチャレンジを渡します App Attest はエンコードされた アサーションオブジェクトをアプリに返します アプリはアサーションオブジェクトを ペイロードに埋め込み ペイロードをサーバーに送信します サーバーはアサーションを検証し ペイロードの内容を承認または拒否します アプリがアサーションを生成する際は いくつかの重要な考慮事項があります 必要に応じてオンデマンドで生成してください アサーションはデバイス上で ローカルに生成されます Apple サーバーへのラウンドトリップは不要です アプリのライフサイクルで 必要なタイミングで生成できます サーバーペイロードに埋め込むためです アサーションには CPU への影響があります アサーションの生成には 暗号操作が伴います アサーションを急速に生成することや アプリのライフサイクルで 過剰に生成することに注意してください サーバーはアサーションに埋め込まれた カウンタープロパティを検証し 厳密に増加していることを確認してください サーバーはユーザーに関連する アサーションのカウンターを追跡してください これにより、リプレイ攻撃への 保護が提供されます アプリがアサーションを埋め込むたびに アサーションオブジェクトの カウンター値が増加するはずです カウンター値が変化しないか 減少している場合 アプリの改ざんされたコピーの 可能性があります サーバーに記録されたカウンター値を 把握していないコピーです 次に、アサーションオブジェクトの 展開について簡単に説明します アサーションは2つのセクションを 含む構造体です シグネチャと オーセンティケーターデータです デベロッパドキュメントに従って オーセンティケーターデータを使って シグネチャを検証してください アテステーションオブジェクトの サーバーチャレンジと公開鍵も使います アテステーションと同様に アサーションオブジェクトの オーセンティケーターデータは アサーション時点の アプリに関する情報を識別します iOS 27 以降では オーセンティケーターデータの末尾に 新しい構造が追加されます extensions と呼ばれる構造です これはアテステーション オブジェクトの オーセンティケーターデータの extensions と 同じように処理してください 以上がアサーションです App Attest のコア部分の説明を終わります アサーションはサーバーへのリクエストが 正規のアプリのコピーからであることを 確認するのに特に役立ちます 次に、注意すべき よくある落とし穴を紹介します サーバーはアプリからの 不審なアクティビティシナリオを 慎重に処理する必要があります 既存ユーザーに対する新しい アテステーションの処理を考えてみましょう アプリの再インストールなど 正当なシナリオがあるため またはデバイスの復元による キーローテーションが発生することがあります これはつまり ユーザーの以前のアテステーションのキーを すぐに無効化しないことを意味します 不正指標と組み合わせることで サーバーのアテステーションマップを ユーザーの不正または不正使用の シグナルとして使用できます サーバーがアテステーションまたは アサーションを拒否した場合 アプリはこれを適切に処理してください ユーザーの App Attest に関連する 機能を制限してください 強化された監視のもとで ユーザーに制限付きアクセスを許可してください 包括的なリスク評価なしに ユーザーを直接ブロックすることは避けてください ユーザーへのリスク評価について 少し詳しく説明します これはビジネスや配布するアプリの 種類によって異なります またアプリにおける 潜在的な不正の影響によっても異なります App Attest に基づいてユーザーの 不正活動が疑われる場合は ユーザーの無効化または停止に関する ビジネスのガイドラインに従ってください 適切な評価なしにユーザーをブロックすると 信頼を損なう可能性があります 正規ユーザーに影響を与える 可能性もあります 常に明確に定義された リスク評価プロセスに従ってください App Attest のコアフローについて 幅広い理解と最適な対処方法を 習得できました 最後にカバーする App Attest の 機能は不正指標です 不審なアテステーションアクティビティを 検出するためのツールです 侵害されたデバイスは依然として アテステーションを通過してブローカーとして機能し 他のデバイスで動作する 改ざんされた アプリインスタンスに代わって 有効なアテステーションを生成することがあります これらの改ざんされたアプリは サーバーに不正なリクエストを送信できます 不正指標は アプリに関連付けられた 特定のデバイスの過去30日間における 一意のアテストされたキーの概算数を提供します これをユーザーの リスク評価プロファイルの一部として使用できます ユーザーが侵害された可能性のある デバイスからのアテステーションに 関連しているかどうかを判断します 不正指標はサーバーと App Attest データサーバー間で アクセスします サーバーはユーザーに関連する アテステーションからレシートを取得します 次に App Attest データサーバーに POST リクエストを送信します 取得したレシートを使って データサーバーはサーバーに レシートを返します 不正指標を含むレシートで 次回のレシート取得に使用してください レシートは App Store レシートに 似た構造をしています 3つのセクションがあります シグネチャ、証明書チェーン およびレシートペイロードです シグネチャはレシートペイロードに 署名します 証明書チェーンは Apple の認証機関をルートとします レシートペイロードには情報が含まれています 指標に関連するアテストされたキーと 不正指標自体の情報です デベロッパドキュメントに従って このレシートペイロードの各部分を 検証してください リスク指標フィールドは 不正指標カウントを定義します レシートは更新する必要もあります not before フィールドは レシートを更新できる最早時点を示します expiration time フィールドは レシートの有効期限を表します 有効期限を過ぎると 更新できなくなります 不正指標を使用する際は 以下の点を考慮してください App Attest のキーローテーションを伴う ユーザーの操作はすべて 不正指標に影響します 例えば、アプリの再インストールや デバイスの復元により アプリ内でキー生成と 再アテステーションが発生することがあります これらは不正指標に影響する可能性があります 不正指標を使ってユーザーを 直接ブロックすることは避けてください 不正指標は 不正活動調査の シグナルとして扱ってください その値を監視し ベースラインを分析してください 急増を不審なアクティビティの 指標として識別してください App Attest でアプリのワークフローを 保護するために必要なものが揃いました ユーザーを安全に保ち アプリを守りましょう さらに学習を続けるには まず最新の SDK で アプリを再ビルドしてください App Attest API の 最新機能を利用できるようにするためです アプリの中でアテステーションの セキュリティが役立つ領域を 特定してください 認証フロー、またはプレミアム コンテンツの機密ペイロードなど アサーションで強化できるものです サーバーを設定して アテステーションを検証し レシートを保存し アサーションカウンターを追跡してください 不正指標をリスク評価パイプラインに 組み込んでください App Attest はアプリの整合性を検証する ツールを提供します アプリとサーバー間の通信を保護し 不正の兆候を検出できます これらはすべてApple ハードウェアの セキュリティに支えられています これらの保護をユーザーのために 活用してください ご視聴ありがとうございました