App AttestとDeviceCheckによる不正行為の抑制

App AttestとDeviceCheckによる不正行為の抑制

Appやコンテンツを保護するために開発されたAppleの強力な不正防止ツールであるApp AttestとDeviceCheckの使用方法を紹介します。App AttestをAppに組み込み、Appやコンテンツの改ざんを防止することで、App Attest展開における秘密を解き明かします。また、DeviceCheckを使用して、Appでプレミアムコンテンツを受け取った顧客と、不正な手段でコンテンツを手に入れた顧客とを確実に区別する方法も紹介します。

リソース
関連ビデオ

WWDC21
- アカウント、プロモーション、およびコンテンツの保護
ダウンロード

ㅤ ♪ ♪ ようこそ「App AttestとDeviceCheckによる不正行為の抑制」に App Storeのトラスト・セキュリティチーム所属のヤン・シェールィです App Attestと Device Checkを使い Appを守る方法をご紹介します Appleはお客様やデベロッパが App Storeを信頼し安心して利用できるよう日々奮闘中でこのセッションではその技術的な側面を扱います反面ビジネス面や概念的な側面を扱っているのは同じくWWDC21の「アカウント、プロモーション、およびコンテンツの保護」です
iOS 11で DeviceCheckを導入しプロモーションに扮した詐欺の防止を図りましたあなたがAppに新機能を追加したとします宣伝すべきですねなので１回限りの無料アイテムを配布しますしかし無料アイテム欲しさに Appのインストールアンインストールを繰り返し悪用する人がいるかもしれませんこのような形で無料アイテムの贈呈を幾度のインストールで悪用されるのは恐らく嫌ですよね
でも DeviceCheckを使えば商品の要求が正当なプロモーションなのか不正が見られるデバイスからなのか判明します
Appleサーバ上に一つのデバイスにつき２ビット分の情報とタイムスタンプが保存できます
このデバイス情報の内容はデベロッパ次第です
情報の更新・照会ができるよう Appleが保管をしています
同一デベロッパの全てのAppに共通なので２ビットで全てのAppで用途が果たせるよう設定の際お気をつけください
Appの再インストールやデバイスの持ち主の変更全設定を初期化した場合もこの情報は残りますプロモーションの方針 App戦略に従ってタイムスタンプを使い情報をリセットするのが賢明かもしれません
もっと詳しく学びたい方は WWCD2017収録の「Privacy and Your Apps」もどうぞ DeviceCheckフレームワークのドキュメントもご覧ください
DeviceCheckのご紹介でした次に DeviceCheck フレームワークの App Attestをご紹介します
サーバにリクエストが送られた際本当に自分のAppからなのか分からない事も
App Attestを使えばリクエストにハードウェア依拠の表明を添付することができますこの表明を使いリクエストが正規のAppleデバイス上の正規のAppからのものなのか確認できます旅行しながらアイテムを集めていくそんなAppを作ったのに改ざんされたAppから外出もせずにアイテムが入手できてしまったり
多人数プレイのカーレースゲームで無制限のパワーアップを使い一挙に一位獲得ができる大多数のユーザーは大迷惑ですね
デベロッパ側からしても土曜日の朝に目覚めて嬉しいことにサーバにリクエストが殺到していたとしますでも調査すると関係ない Appからのものだったとても落胆するでしょう
App Attestを使えば Appの本物と偽物を見分けユーザー体験開発者の収益を守ることが可能です
App Attestは３つの主な機能であなたとAppのユーザーを保護します
App Attestは以下の３つの条件を満たすリクエストのみ容認するようサーバに伝えますがその条件とは Appleデバイスから発信されていること本物のAppが稼働していることペイロードに改変が加えられていないこと
App Attestがこの三条件をどう確認するのでしょうか？ App Attestの基軸は一対のキーのペアとこのキーのペアが正銘なAppleデバイスからだと Appleが認証した構成証明この二つになっていて秘密鍵は保管し App Attest APIの Secure Enclaveにてのみアクセス可能です
Appはこの鍵を使いリクエストを送付サーバはその署名を確かめ本物のAppleデバイスが出自だと確認します
Appleデバイス上でこれを実行する場合必ず署名が必要です無許可改変のAppで実行する際は自身のユーザー情報を使いますが Appの身元もそれに伴い変わります
Appleは構成証明の中に身元情報のハッシュを含蓄
証明に記された身元と本物のAppの身元とを比べることによりリクエストが改変Appかどうか分かるようにしました
リクエストが本物のデバイス本物のAppから出ていることは確認できましたでもペイロードはどうでしょう
Appがペイロードを送る前に App Attestは証明済みの鍵を使いペイロードの要約に署名をすることができますこうすればペイロードの表明が完成
ペイロードを表明とともにサーバに送りますペイロードを鑑み表明を検証することにより通信中にペイロードの改変がなかったと安心できます
以上三機能でしたではプライバシー面はどうでしょう
Appleではプライバシーを重要視しており Appエコシステムの管理にあたり不可欠であるそう考えています App Attestはプライバシーを念頭に置いており
証明措置は正真のデバイスが身元だと証明しつつデータの追跡を防止するため全て匿名になっておりハードウェアも識別できません
App Attestの鍵はインストールの度に取り替え再インストールをする度に消失しますバックアップもなされておらずデバイス間の同期も行えません Appに採用する場合ご注意ください
App Attestの機能は学んでいただけたでしょう次はAppへの導入に関し詳しく説明します App Attestの導入には三つの手順があります鍵の作成鍵の証明・検証表明の作成・検証ですまずはApp Attestの鍵の作成についてコールは全て isSupportedのプロパティでガードする必要があります Secure Enclaveを搭載のデバイスは App AttestをサポートしますしかしApp Extentionなど isSupportedが偽と返る場合もありますこういった場合雑な対応は避けてください
直ちにアクセスを拒否するのでなくリスク信号の一環として捉えましょうとりあえず発信人を「信頼できない」とみなしリスク査定の手順に従い大事な機能を使用可とするかユーザーごとに決めます
もう一つの徴候はあなたのサーバにコールするデバイスで App Attestのサポートをしないものが急増することです App Attestをサポートする発信人の比率が激減した場合改変Appを使ったデバイスかもしれません App Attestの鍵が作成できたら鍵の証明をする必要があります中間者攻撃や反射攻撃を防ぐためには一度限りでチャレンジ認証を行う必要がありますではサーバから Appに促しを送ります
証明をユーザーID その他の情報とリンクする場合 clientDataHashを作成する促しにより双方をハッシュします clientDataHashと keyIdを用意すれば attestKey APIも準備OKです
秘密鍵を使い attestKeyはハードウェア証明のリクエストを作成し認証をするため Appleに送付します認証が済めば Apple側から Appに匿名の証明オブジェクトを送りますカスタムペイロードとともに証明を送付しサーバに認証のため送り返します証明をサーバに送ることができたら最後は認証をしましょう
証明はWeb認証方法を使っており三つの要素で構成されています Appleに署名された証明書の一覧認証データ構造リスクメトリックの受信です
認証に必要な三要素確認していきます
証明書欄はリーフに加え中間証明書で構成されています App Attestのルート証明書は Apple Private PKI レポジトリにあり証明書チェーンを全て認証するとデバイスが Appleのものだと証明されます
attestKeyをコールする際 clientDataHashなどからノンスという一度限りのハッシュが作られそれがリーフ証明書に含まれていますが
改ざんを防止するにはサーバ上でノンスを再構築しマッチングを行います
認証データブロックには App身元のハッシュなど複数のプロパティがありこれを使い本物のAppからのものだと確認できます
鍵証明にはレシートも含まれておりリスクメトリックの要求や保存が可能です後ほどもっと詳細に説明いたしましょう
全ての条件が満たされたら Attest鍵は本物ユーザー情報とリンクされた鍵は以後のリクエスト認証のため保管を
まとめると偽返答は全てが不正ではない isSupportへの偽返答ランプアップ中の詰まり一般的なネットワーク不全等問題には的確に反応しリスクシグナルとして全体的なリスク査定の一環としましょう
この認証方式の導入については添付資料に詳しくあります attest-Key APIをコールすると Appから App Attest宛てにネットワークコールを作成します Appのインスタンス一回に限らますがインストールベースが大きい場合は App Attestに多数のリクエストを送信する事もあります資源を節約しレートリミットされないようこの機能はインストールベースに対しゆっくり浸透させましょう例えばアクティブユーザーが一日百万なら一二日で済ませましょうなんと百億人いるとなったら一か月以上かかります
認証鍵を導入したら次の課題は generateAssertionの APIを使う App サーバ間の大切な通信の保護です
Appleサーバが関与しないため表明の手順は認証手順より単純になります
鍵を使った表明はすべてデバイス上で作成サーバ上で認証となります
まずはサーバに一意の促しを要求次にペイロードの要約を作り generateAssertionのコールダイジェストを使ってノンスを作成し App Attest鍵で署名します
これでAppはペイロードそれに表明をサーバに送信最後にサーバがペイロードを認証
表明ペイロードはハイレベル構成となっています署名と認証データの説明に移ります
署名を認証するには逆の手順に沿いサーバ上でノンスを再構築し公開鍵で署名を認証します
署名が正規の場合ペイロードは無変更だと断定できます
認証データのセクションには身元情報のハッシュがあり
このハッシュを認証すれば表明が正規のAppだと分かります
認証データには無期増加のカウンターも含まれていますが反射攻撃を阻止するにはサーバにカウンタ値を記録リクエストがある度に数値が増加したか確認します
鍵があるのでこのプロセスは何度でも繰り返せますなお表明により Appleサーバを呼び出す事はありませんが暗号を使った演算なので待ち時間は生じます App Attest導入の際この待機時間を算入してください
表明は重要性が高く頻度の低いコールに向いているため呼び出しの際待機時間・演算能力の点で優れています
即時頻繁なネットワーク指示の場合は表明が適していないかもしれません
よく頑張りました！ App Attestの導入はひとまず完了ですもうこれでサーバリクエストを査定し正規のものか改変か判断できこの不正探知能力を利益につなげるこのようなことが可能ですしかしこれで油断はいけません同一のデバイスでいくつもの鍵を作り App Attestを騙した攻撃者が改変Appをそのデバイスを介してサーバに繋げることが考えられます当社はこの種の不正行為を探知するため App Attestリスクメトリックサービスを提供しておりあるデバイスが作成した鍵の数を Appごとに把握することができます attestKeyは表明に加えリスクメトリックのレシートを返しますがこのレシートをサーバに送り新レシートを還元することができます新レシートにはリスクメトリックが示され
定期的に最新のレシートを回収することでデバイス App対の関係を確かめられます
これはレシート構造のハイレベルビューで PKCS7コンテナとなります詳細については「不正リスクの査定」を DeviceCheckの資料よりご覧ください
App Clipは iOSの将来有望な新機能です iOS 15ではそのApp Clipに App Attestをつなげ App ClipからフルAppへの引継ぎをお手伝いします App ClipとフルAppは App Attest上では同一の身元を持つとみなされているのでサーバ側から Appの身元を認証する際ご注意ください
App Clipが削除されたり期限を満了した場合は本Appと同様鍵も無効化されます
App Clipについては以上です App Attest成功のポイントを是非覚えておいてくださいデバイスでなくサーバ側から認証する Appを改変し認証コード無効化を計る攻撃など
反射攻撃を阻止するために一度限りサーバへのチャレンジを導入する
isSupportへの偽返答ランプアップ中のつまり一般的なネットワーク不全このような問題をしっかり予知するまた不意の発展はリスクシグナルとする
App Attestと DeviceCheckは総合不正対策のため必要な情報を伝達しますが DeviceCheckはプロモーションの不正防止
App Attestは App改変の即時探知をお手伝いしあなたのAppやユーザーの満足をお守りしますご静聴ありがとうございます App Attestや Device Checkを活用したAppに出逢えるのが楽しみです “ピース“を！

let appAttestService = DCAppAttestService.shared

if appAttestService.isSupported {
    appAttestService.generateKey { keyId, error in
        guard error == nil else { /* Handle the error. */ }
        // Cache keyId for subsequent operations.
    }
} else {
   // Handle fallback as untrusted device
}

9:34 - Generate key attestation

appAttestService.attestKey(keyId, clientDataHash: clientDataHash) { attestationObject, error in
    guard error == nil else { /* Handle error. */ }

    // Send the attestation object to your server for verification.
}

13:14 - Generate assertion

appAttestService.generateAssertion(keyId, clientDataHash: clientDataHash) { assertionObject, error in
    guard error == nil else { /* Handle error. */ }
    
    // Send assertion object with your data to your server for verification
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC21