厳しくなったSafetyNet Attestationによる端末チェック

DroidKaigi 2021 Day2 18:00~

Transcript

1. 厳しくなった SafetyNet Attestationによる 端末チェック Akihiro Shiota @aki_sh_7
2. Agenda SafetyNet Attestationとは 最近のRoot化事情 厳しくなったチェックと新しいパラメータ ：evaluationType 変更に対する反応 変更されたSafetyNet Attestationの活用 01 02 03 04 05
3. Agenda SafetyNet Attestationとは 最近のRoot化事情 厳しくなったチェックと新しいパラメータ ：evaluationType 変更に対する反応 変更されたSafetyNet Attestationの活用 01 02 03 04 05
4. SafetyNet Attestation “SafetyNet Attestation API は、アプリが動作している Android デバイスをアプ リのデベロッパーが評価するための不正利用防止 API です。この API は、不正利 用検出システムの一部として、サーバーとやり取りしているのが正規の Android デバイスで動作している正規のアプリかどうかを判断するために使用します。” 出典：Android developers, SafetyNet Attestation API, https://developer.android.com/training/safetynet/attestation?hl=ja, 2021/10/7閲覧
5. SafetyNet Attestation “SafetyNet Attestation API は、アプリが動作している Android デバイスをアプ リのデベロッパーが評価するための不正利用防止 API です。この API は、不正利 用検出システムの一部として、サーバーとやり取りしているのが正規の Android デバイスで動作している正規のアプリかどうかを判断するために使用します。” 出典：Android developers, SafetyNet Attestation API, https://developer.android.com/training/safetynet/attestation?hl=ja, 2021/10/7閲覧 このデバイスを評価する機能で、代表的に取り上げられるのがルート化チェック
6. SafetyNet Attestationの仕組み Google Android Device Server 1 2 3 6 7 8 4 5 1. リクエスト開始 2. nonce返却 3. SafetyNet Attestation API呼出 4. 評価結果の署名済み構成証明を リクエスト 5. 署名済み構成証明を端末へ送信 6. 署名済み構成証明のアプリへの返却 7. 署名済み構成証明をサーバへ送信 8. 構成証明の検証結果に応じたレスポ ンス サーバ側で検証するのが大事！ Client App Client Backend Google Play services (Safetynet Attestation API) Attestation API Backend
7. APIのレスポンス中のフィールド フィールド 説明 timestampMs Googleのサーバでレスポンスが生成された時刻。UNIX時間(ミリ秒)。 nonce API呼び出し時にアプリから受け渡されたnonce apkPackageName API呼び出し元アプリのパッケージ名 apkCertificateDigestSha256 API呼び出し元アプリの証明書ハッシュ ctsProfileMatch デバイスの完全性に関する厳密な判定結果。CTSの合格はこっち。 basicIntegrity デバイスの完全性に関する緩やかな判定結果 evaluationType ctsProfileMatchやbasicIntegrityなどの計算に使用される測定のタイプ
8. 代表的な判定結果 デバイスの状態 ctsProfileMatch basicIntegrity CTS に合格した認証済みの正規デバイス true true ブートローダーがロック解除されている認証済みデバイス false true 正規だが認証されていないデバイス false true カスタム ROM を搭載したデバイス false true エミュレータ false false デバイスがない（プロトコルをエミュレートするスクリプトなど） false false システムの完全性が侵害されている兆候（ルート権限取得など） false false その他のアクティブな攻撃の兆候（API フックなど） false false 出典：Android developers, SafetyNet Attestation API, https://developer.android.com/training/safetynet/attestation?hl=ja, 2021/10/7閲覧
9. Agenda SafetyNet Attestationとは 最近のRoot化事情 厳しくなったチェックと新しいパラメータ ：evaluationType 変更に対する反応 変更されたSafetyNet Attestationの活用 01 02 03 04 05
10. 最近のRoot化 ⚫ 主流はMagisk ⚫ bootイメージにパッチを当て、フラ ッシュすれば容易にRoot化可能 (ブートローダーのアンロックは必要) ⚫ Root隠し機能のMagisk Hideで SafetyNet Attestationも通過
11. Agenda SafetyNet Attestationとは 最近のRoot化事情 厳しくなったチェックと新しいパラメータ ：evaluationType 変更に対する反応 変更されたSafetyNet Attestationの活用 01 02 03 04 05
12. 厳しくなったチェック ⚫ ctsProfileMatchとbasicIntegrityの結果判定に、Key Attestationを利用 ⚫ 2020年3月～5月より試験導入、2021年1月より本格展開 2020 2021 コミュニティ等でチェックが通ら なくなった報告が上がる SafetyNet Attestation APIの メーリングリストに仮導入連絡 Mar May Feb Sep 本格導入報告 デバイス名による Key Attestation利用可否の確認導入
13. 厳しくなったチェック ⚫ ctsProfileMatchとbasicIntegrityの結果判定に、Key Attestationを利用 ⚫ Magisk Hideを使っていても、 SafetyNet Attestationを回避することが出来なくなった！ ⚫ Key Attestationの結果の改ざんは困難 ⚫ ハードウェアレベルでのサポート＋証明書失効なし＋ルート証明書がGoogleの場合 ⚫ ブートローダーやブート状態を示す結果を利用していると推測
14. 厳しくなったチェック ⚫ ctsProfileMatchとbasicIntegrityの結果判定に、Key Attestationを利用 ⚫ Key Attestationを使っているかは、レスポンス中のevaluationTypeで確認可能 ⚫ BASIC：従来からの測定データや参照データを利用する方法 ⚫ HARDWARE_BACKED：(ハードウェアレベルの)Key Attestationを利用 ⚫ 2021/9に、判定方法がさらに厳格化 ⚫ Googleが、デバイス名に応じて、 Key Attestationを利用できるのに、利用していないか を確認している？
15. デバイス評価以外への効果 – 接続元アプリのチェック- サーバ側で、接続してきたアプリの正当性の確認を実施可能 ⚫ 従来でも、apkCertificateDigestSha256により、サーバに接続してきたアプ リが正当であるか確認することはできた ⚫ ただし、先に説明したように、従来は端末の正当性検証を回避する方法があり、 その端末からのAPK情報を信頼することは難しかった。 出典：Android developers, SafetyNet Attestation API, https://developer.android.com/training/safetynet/attestation?hl=ja, 2021/10/7閲覧
16. Agenda SafetyNet Attestationとは 最近のRoot化事情 厳しくなったチェックと新しいパラメータ ：evaluationType 変更に対する反応 変更されたSafetyNet Attestationの活用 01 02 03 04 05
17. 2020年：対応のしようがない… ⚫ 初期はユーザによって、 対象となってるかがまちまち ⚫ 認識されたけど、どう回避するのか ⚫ TEEの脆弱性をついて、KeyAttestationの結果を 改ざん？ ⚫ XposedでSafetyNet Attestation APIをHook？ ⚫ SafetNet Attestationの結果を改ざん？
18. 2020年：対応のしようがない… ⚫ 初期はユーザによって、 対象となってるかがまちまち ⚫ 認識されたけど、どう回避するのか ⚫ TEEの脆弱性をついて、KeyAttestationの結果を 改ざん？ ⚫ XposedでSafetyNet Attestation APIをHook？ ⚫ SafetNet Attestationの結果を改ざん？ 無理！
19. Universal SafetyNet Fix ⚫ 2021/1にgithubで公開。おそらく現在最も安定して回避を実現するモジュール。 ⚫ SafetyNet Attestation APIに対して、該当する端末がKey Attestation非対応 であるように見せかける。 ⚫ evaluationTypeはBASICとして判定されるようになる。 ⚫ v1系とv2系では、実装や細部は異なるが、大まかな思想は同じ(v2系はriruを利用) ⚫ 2021/9のデバイス名のチェックにも対応(v2.1)。 デバイス名を変更することで、回避している。
20. Agenda SafetyNet Attestationとは 最近のRoot化事情 厳しくなったチェックと新しいパラメータ ：evaluationType 変更に対する反応 変更されたSafetyNet Attestationの活用 01 02 03 04 05
21. これまでの再整理 ⚫ Key Attestation対応端末では、Root化などの端末状態の検知精度が向上 ⚫ Magisk＋Universal SafetyNet Fixの組み合わせでは、SafetyNet Attestation の回避が成立してしまう。 ⚫ ただし、Key Attestation非対応端末として判定される（evaluationTypeがBASICになる）
22. どのように使っていくか ⚫ 厳しくなった判定結果を享受するのなら、Universal SafetyNet Fixを使っても、 回避できないようにしてやる必要がある。 ⚫ ＝ evaluationTypeにHARDWARE_BACKEDが含まれるものだけ許可 ⚫ アプリ(または機能)の利用可能端末を、Key Attestation対応端末に絞る。
23. 活用時の注意点 ⚫ 対応端末を絞る際に、OSのバージョンで区切ることはできない。 ⚫ Key Attestationが対応必須となったのは、Android 8.0以上。 ⚫ 機能自体は、Android7.0からだが、対応が必須だったわけではない。 ⚫ マニフェストでは、機能制限としての定義はできないので、事前に対応端末を 定義するなら、調査してリスト化することが必要
24. 活用時の注意点 出典：Android developers, SafetyNet Attestation API, https://developer.android.com/training/safetynet/attestation, 2021/10/19閲覧
25. 活用時の注意点 出典：Android developers, SafetyNet Attestation API, https://developer.android.com/training/safetynet/attestation, 2021/10/19閲覧 最高レベルのデバイス完全性の保障が求められるアプリでの利用を想定
26. 懸念点 ⚫ すぐにアプリに導入して大丈夫？ ⚫ Android8.0搭載端末が出てきたのは2018年頃（主にキャリア端末）であるため、 幅広い端末で利用してもらうには、もう少し時間が必要？ ⚫ 今後破られることは？ ⚫ TEEなどが侵害された場合は起こりうるが、失効リストに追加される。
27. 懸念点 ⚫ 後継となるPlay Integrity API（現在EAP中）で、本機能が引き継がれるか。 ⚫ Windows 11等、Google Play Serviceが利用できないものでのAndroidアプリ 実行が増えてきた時にどうするか
28. まとめ ⚫ SafetyNet Attestationは、Key Attestationの結果を用いることで、 より、デバイスの完全性について、精度の高い判定を行うようになった。 ⚫ 一方、Magisk＋Universal SafetyNet Fixにより、Key Attestation対象外の端 末のふりをすることで、精度の高い判定を回避することは可能 ⚫ 精度の高い判定を利用したい場合は、対象端末を絞る必要が生じる。 ⚫ また、接続元アプリが正規であるかの確認も、精度高く行えるようになった。