Magisk の開発者は、Google がデバイスのブートローダーのロックが解除されているかどうかを判断するためにハードウェア チェックを使用し始めた可能性があることを発見しました。
XDA 認定開発者 トップジョンウの「Magisk」プロジェクトは、Android コミュニティでは基本的に「root」と同義になっています。 これが非常に人気がある主な理由の 1 つは、ユーザーがデバイスを変更したという事実を隠すことができるためです。 ただし、Google はブートローダーのロック解除ステータスをアプリケーションから隠す Magisk の機能を厳しく取り締まっている可能性があります。
携帯電話をルート化するには、通常、ブートローダーのロックを解除する必要があります。これにより、変更されたブート イメージをフラッシュできるようになります。 これは、Magisk がブート イメージを変更してブートローダー ステータスや検証済みブート ステータス チェックを偽装するために必要です。 Google Play Services の一部である Google の SafetyNet Attestation API は、アプリが改ざんされたデバイス上で実行されているかどうかをアプリに通知するために使用されます。 SafetyNet API がブートローダーのロックが解除されたことを検出すると、「基本整合性」チェックの失敗ステータスを返します。 このチェックに失敗したデバイスは、SafetyNet API を使用してデバイスの整合性を判断するアプリからロックアウトされる場合があります。 このようなアプリには通常、銀行アプリ、支払いアプリ (Google Pay など)、および多くのオンライン ゲーム (Pokémon Go など) が含まれます。 ただし、SafetyNet API はこれまでのところ、デバイスが改ざんされているかどうかを判断するためにソフトウェア チェックのみを使用しているため、Magisk は単にデバイスを偽装することができます。 ブートローダーや検証済みブートのステータスは、Google Play サービスや他のユーザースペースよりも低いレベルで高い権限でインストールされるため、 アプリケーション。 topjohnwu が説明しているように、MagiskHide は「検出プロセスのために隔離された『安全な環境』を[作成]し、Google の API を介して 合法的な SafetyNet の結果は、デバイスの実際のステータスを反映していません。」
しかし最近、ブートローダーのロックが解除されたデバイスが、Magisk を使用してブート イメージにパッチを適用したにもかかわらず、SafetyNet の基本整合性チェックに失敗していることにユーザーが気づきました。 topjohnwu 氏によると、これは、Google がブート イメージが改ざんされていないことを確認するためにハードウェア レベルのキー構成証明を実装した可能性があるためであるとのことです。 具体的には、これは、Google Play Services が「未変更のキーストア証明書を SafetyNet サーバーに [送信] し、その正当性を検証し、 証明書拡張データを使用して、デバイスでブートが有効になっていることが確認されたかどうか (ブートローダーのステータス) を確認します。」 これは、デバイスが有効ではなくなっている可能性があることを意味します。 ブートローダーのロックが解除されているという事実を隠すことが可能であり、その結果、Google Pay や Pokémon Go などのアプリケーションが動作しなくなる可能性があります。 通常は。
topjohnwu が指摘したように、SafetyNet がブートローダーのロック解除ステータスをチェックする方法のこの変更は、Google Play Services に含まれる SafetyNet API のサーバー側の更新を通じて行われます。 ただし、すべてのユーザーがこれらの更新された SafetyNet チェックに合格していないわけではないため、新しいハードウェア レベルのキー構成証明はまだ広く施行されていない可能性があります。
私たちは、topjohnwu が技術的なハードルを何度も乗り越えるのを見てきました。 Google は、SafetyNet で新しいチェックを頻繁に展開し、topjohnwu が Magisk で検出してバイパスします。 Android の新しいバージョンごとにパーティション構造またはブート イメージに変更が加えられるため、topjohnwu はその変更を調査し、新しいパッチ適用方法を実装する必要があります。 しかし、今回はtopjohnwuですら迂回路を見つけるのに苦労するかもしれない。
それは、今回の回避策には、秘密キーを取得するためにデバイスの信頼できる実行環境 (TEE) ファームウェアをハッキングすることが含まれるためです。 ただし、非常に安全になるように設計されたファームウェアの脆弱性を見つける必要があるため、これを行うのは非常に困難です。 実際、そのような脆弱性が見つかった場合、多くの企業は数十万ドルの支払いを提案しています。 たとえば、Google は、Pixel の信頼できる実行環境におけるリモート コード実行の脆弱性に対して 25 万ドルを支払い、 最大1,000,000ドル の脆弱性については、 タイタンM セキュリティチップ。 たとえ何らかの理由で秘密鍵が漏洩したとしても、それがあまり役に立たない可能性は低いです。 Google はリモートでキーを取り消すことができる したがって、デバイスの整合性を検証するために使用することはできません。
SafetyNet に対してハードウェア レベルのキー構成証明が広く適用されると、Android 8.0 Oreo 以降を実行するロック解除されたブートローダーを搭載したほとんどのデバイスは、SafetyNet の基本整合性チェックに合格できなくなります。 これは、Android 8.0 Oreo 以降で起動されたすべてのデバイスには、TEE にハードウェア キーストアが実装されている必要があるためです。 最近の特定のデバイスには専用のハードウェア セキュリティ モジュール (HSM) が搭載されており、TEE をメイン プロセッサから遠ざけることで悪用がさらに困難になります。 Pixel 4のTitan Mと サムスンの新しいセキュリティチップ Galaxy S20 がその例です。
トップジョンウ も説明します 他の潜在的な回避策は不可能であるか、非常に困難であるということです。 Xused Framework を使用して Google Play Services の SafetyNet Attestation API を変更することは、機能しない可能性があります。「適切な SafetyNet チェックは、[the] 上ではなく、リモート サーバー上で結果を検証するからです」 コード インジェクション フレームワークによって操作できるデバイスです。」さらに、Google Play Services は高度に難読化されているため、このような Xused モジュールの作成は最初は非常に困難です。 場所。 SafetyNet の応答は「Google サーバーから送信され、Google の秘密鍵で署名されている」ため、SafetyNet テスト結果のなりすましも不可能です。
Google は数年前から、ハードウェアによるキー構成証明を使用して SafetyNet チェックを強化する機能を備えています。 3年間そうしなかったという事実により、ユーザーはバンキングアプリの使用能力を犠牲にすることなくrootおよびMagiskモジュールを楽しむことができました。 ただし、ブートローダーのロック解除ステータスを効果的に隠す Magisk の機能は間もなく終了するようです。 これは私たちが何年も予期していた変更ですが、ついに施行されるのを見て残念に思っています。 Google が SafetyNet Attestation API を更新して、ステータス チェックにハードウェア ベースが使用されたかどうかを返すことを期待します。 これにより、アプリ開発者は、ロックを解除したすべてのユーザーをブロックするかどうかを決定できるようになります。 ブートローダー。
Daniel Micay (@) に感謝します。ダニエルミケイ）この件に関する彼の意見に感謝します！