SafetyNet のハードウェア認証機能は今後も継続します

2020 年 5 月に遡ると、Google はひっそりと Android モッディング コミュニティを驚かせました。 SafetyNet 応答のためのハードウェアによる認証の導入 一部のデバイスでは。 Google のサーバーは、整合性をチェックするための「BASIC」評価レポートの受け入れを完全には停止していないという事実により、 リモート デバイスのソフトウェア環境に比べて、ハードウェアによるキー構成証明の出現は、より重要なもののように思えました。 実験。 しかし、当時、Google は「...」と述べました。デバイスの適格基準の評価と調整...、」は、大規模な展開の可能性を示しています。 そうですね、Google がついにそれをやろうとしているのです。

によると 最近の投稿 「SafetyNet API クライアント」の Google グループでは、SafetyNet Attestation API 応答の「evaluationType」フィールドが正式にサポートされる機能になりました。 開発者にとって、これは、Google Play Services を利用して、デバイスの信頼された実行環境 (TEE) を使用して生成された未変更のキーストア証明書を送信できることを意味します。 デバイスのソフトウェア環境が何らかの方法で改ざんされているかどうかを確認するたびに、SafetyNet サーバーに専用のハードウェア セキュリティ モジュール (HSM) を送信します。 ただし、この機能は、既に「ctsProfileMatch」パラメーターを使用し、最高レベルのデバイス整合性保証を必要とするアプリのみを対象としているため、この機能を過度に使用しないでください。 公式ドキュメントで提案されている.

数週間前、Google Play 開発者サービスがサービスを提供し始めたことに人々が気づいたとき、このことが起こる兆候がありました。 多くの場合、基本的な認証が有効な場合でも、CTS プロファイル検証ではハードウェア認証が優先されます。 選択されました。 まだそうなる可能性があることを念頭に置いてください

悪用する可能性がある ハードウェア構成証明ルーチンの便宜的な性質により、このようなシナリオでは基本構成証明が渡されます。 これは恒久的な修正ではありませんが (これまでに恒久的な修正が証明されたものはありません)、Google が基本的な評価を完全に放棄する決定を下すまで、ユーザーは SafetyNet をバイパスできるようになります。 それにもかかわらず、Google がそもそもこのような措置を講じていることは、愛好家と開発者コミュニティにとって残念なことです。

Google がハードウェアによる認証の強制を継続する場合、パワー ユーザーが認証を行う時代の終わりを意味する可能性があります。 マスキングを使用することで、Google Pay やその他の SafetyNet ベースのアプリを root アクセスと連携して実行できる テクニック。 状況はまだ発展途上であるため、事態は表面的に見えているものよりも複雑である可能性があります。 この件に関して新たな進展があれば、読者に随時お知らせしていきます。

XDAメンバーに感謝します Some_Random_Username ヒントのために！