Androidアプリケーションの整合性をサーバー側から確認しています
私はAndroidアプリケーション（モバイルバンキング）を使用していて、サーバーに接続してオンライントランザクション（インターネット/ USSD/SMSを介して）を行っています。これらのクライアントが改ざんされておらず、オリジナルであることを確認したい私が配布したもの。
すべての顧客がGoogle Play経由でアプリケーションをダウンロードするわけではなく、サードパーティのマーケットを使用したり、他の場所からAPKをダウンロードしたりすることに注意してください。
サーバー側でアプリケーションの整合性を（チェックサムまたは署名を使用して）検証して、改ざんされていないことを確認できる方法はありますか？ （例えば、トロイの木馬はアプリケーションに埋め込まれず、再配布されません）
提案された解決策について：
- 3つすべての通信チャネル（SMS/USSD /インターネット）に実装できますか、それとも1つまたは一部のチャネル専用のソリューションですか？
（私はこのページで参照されている手法を正確に探しています： https://samsclass.info/Android/chase.htm ）：
Chaseのサーバーは、サーバーに接続するときにAndroidアプリの整合性をチェックしません。そのため、アプリを簡単に変更し、悪意のあることを行うトロイの木馬コードを追加することができます。トロイの木馬型アプリを使用するように人々はそれらを悪用することができます。
この脆弱性は、Google Playストアの正規のアプリを使用しているユーザーには影響しません。 Webサイトや電子メールなどから変更されたアプリをインストールするようにだまされている人々にのみ害を及ぼします。
Android SafetyNet を使用します。これがAndroid Payが自身を検証する方法です。
基本的な流れは次のとおりです。
- サーバーはnonceを生成し、それをクライアントアプリに送信します。
- アプリはGoogle Play開発者サービスを介してnonceで確認リクエストを送信します。
- SafetyNetは、ローカルデバイスが変更されていないことを確認し、 [〜＃〜] cts [〜＃〜] を渡します。
- Googleが署名した応答（「証明」）がアプリに返され、合格/不合格の結果とアプリのAPKに関する情報（ハッシュと署名証明書）が返されます。
- アプリは、構成証明をサーバーに送信します。
- サーバーはnonceとAPKの署名を検証し、検証のために証明書をGoogleサーバーに送信します。 Googleは構成証明の署名をチェックし、それが本物であるかどうかを通知します。
これが成功すれば、ユーザーが変更されていないシステムでアプリの正規バージョンを実行していることをかなり確信できます。アプリは起動時に証明書を取得し、トランザクションリクエストごとにサーバーに送信する必要があります。
ただし、これは次のことを意味します。
- 携帯電話をルート化したユーザーはこれらのチェックに合格しません
- カスタムまたはサードパーティのROM /ファームウェア/ OS（Cyanogenなど）をインストールしたユーザーは、これらのチェックに合格しません
- Google Play Servicesにアクセスできないユーザー（Amazonデバイス、中国の人々など）はこれらのチェックに合格しません
...したがって、アプリを使用できなくなります。あなたの会社は、これらの制限（および付随する動揺するユーザー）が許容できるかどうかに関してビジネス上の決定を行う必要があります。
最後に、これは完全に気密なソリューションではないことを理解してください。ルートアクセスとおそらくXposedを使用すると、SafetyNetライブラリを変更してGoogleのサーバーに嘘をつき、「正しい」答えを伝えて、Googleが署名した検証パス結果を取得することができます。実際には、SafetyNetはゴールポストを移動するだけで、悪意のある攻撃者を困難にします。これらのチェックは最終的に制御できないデバイスで実行する必要があるため、完全に安全なシステムを設計することは実際には不可能です。
サーバーがデバイスについて確実に判断できる唯一のことは、サーバーに対する動作（受信したデータ、およびどの時間パターンで）かです。攻撃者が動作に影響を与えるすべての要素の知識と制御を持っていると仮定すると、攻撃者は悪意のあるクローンを作成でき、サーバーはそれを知ることはありません。
したがって、技術的にはこれは不可能です。デバイスハードウェアのサポートを採用しない限り、整数APKファイルは悪意のあるクローンを作成するのに十分です（逆コンパイルは簡単で、プロガードは経験豊富なリバースエンジニアに対してはあまり役に立ちません）。
@ CodesInChaos および @ OrenMilman によるコメントで述べたように、
攻撃者が把握するのが非常に難しい要素をその動作に含めることができます。 TPM/TEEとリモート認証を実装します。 TPMに脆弱性がないと仮定すると（これはありそうもないことですが、仮定するだけです）、これは実際にソリューションになります。また、脅威モデルがなければ、セキュリティは無意味です。したがって、脅威モデルがフルタイムの献身、多額のお金、そして場合によってはゼロデイへのアクセスを持つ攻撃者を除外する場合、そのようなメカニズムは安全であると考えることができます。
どのAndroid=デバイスにTPMがあり、そのような手段をサポートしているかはわかりません。その調査を残して、この回答を他の誰かに修正します。
私はパーティーに少し遅れて到着しましたが、私はいくつかの有用な洞察を加えることができると思います。
サーバー側でアプリケーションの整合性を（チェックサムまたは署名を使用して）検証して、改ざんされていないことを確認できる方法はありますか？ （例えば、トロイの木馬はアプリケーションに埋め込まれず、再配布されません）
アプリとAPIサーバーの間の最終的なセキュリティのために、SafetyNetソリューションであるOAUTH2サービスと一緒にモバイルアプリの整合性証明サービスを使用する必要があります。また、モバイルAPIテクニックに関する記事の このシリーズ で説明されているように、証明書ピン留めを使用してAPIサーバーとモバイルアプリ間の通信チャネルを保護することも重要です。
モバイルアプリの整合性検証サービスの役割は、アプリに統合されたSDKとクラウドで実行されているサービスを使用して、アプリが改ざんされていないこと、またはルート化されたデバイスで実行されていないことを実行時に保証することです。
アプリの整合性の認証に成功すると、JWTトークンが発行され、アプリのAPIサーバーとクラウド内のモバイルアプリの整合性認証サービスのみが認識している秘密で署名されます。
App Integrity Attestationでエラーが発生した場合、JWTはAPIサーバーが知らない秘密で署名されます。
これで、アプリはリクエストのヘッダーにあるすべてのAPI呼び出しでJWTトークンを送信する必要があります。これにより、APIサーバーは、JWTトークンの署名を検証できる場合にのみリクエストを処理し、検証に失敗した場合にリクエストを拒否できます。
モバイルアプリの整合性認証サービスで使用されるシークレットがアプリで認識されない場合、アプリが改ざんされている、ルート化されたデバイスで実行されている、または接続されている接続を介して通信している場合でも、実行時にそれをリバースエンジニアリングすることはできません中間者攻撃のターゲット。これは、SafetyNetソリューションとの関連でこのタイプのサービスが優れている点です。
Approovには、Androidを含むいくつかのプラットフォーム用のSDKを備えたこのようなサービスがあります。統合では、不正な使用から保護するために、JWTトークンを検証するためのAPIサーバーコードの小さなチェックも必要になります。
私の顧客のすべてがGoogle Play経由でアプリケーションをダウンロードするわけではなく、サードパーティのマーケットを使用したり、他の場所からAPKをダウンロードしたりすることに注意してください。
Approov のようなMobile API Integrity Attestationサービスを使用すると、アプリがどこからインストールされたかは問題になりません。
私はAndroidアプリケーション（モバイルバンキング）を使用していて、サーバーに接続してオンライントランザクション（インターネット/ USSD/SMSを介して）を行っています。これらのクライアントが改ざんされておらず、オリジナルであることを確認したい私が配布したもの。
そして
推奨される解決策：
3つすべての通信チャネル（SMS/USSD /インターネット）に実装できますか、それとも1つまたは一部のチャネル専用のソリューションですか？
したがって、アプリがサードパートサービスと直接対話することを想定して、その責任をAPIサーバーに委任することをお勧めします。これにより、モバイルからの本物のリクエストのみを処理するようになれば、サードパーティサービスの不正使用を防ぐことができます。整合性の課題に合格したアプリです。
SafetyNet Attestation APIは、アプリが実行されるAndroid環境のセキュリティと互換性を評価するのに役立ちます。このAPIを使用して、アプリをインストールしたデバイスを分析できます。
OAuth 2.0承認フレームワークにより、サードパーティアプリケーションは、リソース所有者とHTTPサービス間の承認インタラクションを調整することにより、リソース所有者に代わってHTTPサービスへの制限付きアクセスを取得できます。または、サードパーティのアプリケーションが自分自身のためにアクセス権を取得できるようにすることにより、この仕様はOAuth 1.0プロトコルをRFC 5849に記述されているプロトコルに置き換え、廃止します。
固定とは、ホストを、予想されるX509証明書または公開鍵に関連付けるプロセスです。証明書または公開鍵が既知であるか、ホストで確認されると、証明書または公開鍵がホストに関連付けられるか、「固定」されます。複数の証明書または公開鍵が受け入れられる場合、プログラムはピンセットを保持します（Jon LarimerおよびKenny Root Google I/Oトークから取得）。この場合、アドバタイズされたIDは、ピンセット内のいずれかの要素と一致する必要があります。
トークンベースの認証
JSON Web Tokenは、2つの当事者間で安全にクレームを表すためのオープンな業界標準RFC 7519メソッドです。
免責事項：私はApproovで働いています。
この問題は、収入の理由でモバイルゲームが対処しなければならない問題であり、私が言うことができることから、彼らはアプリを絶えず更新することによってこれに対処し、ユーザーがゲームを開始する前に毎回新しいパッチをダウンロードしてインストールする必要があります。通常、これは少量です。これらのパッチはまた、ゲームに新しいコンテンツを追加します。パッチは更新自体も処理するため、アプリが変更された場合、パッチは失敗します。
したがって、理論的には（これがどれほど正確かはわかりません）、基本的にアプリ内でアプリを記述します。内部アプリは、重労働を行うアプリです。外部アプリは、起動するたびに、パッチ/整合性検証ツールをダウンロードします。これにより、まずアプリが改ざんされていないことを確認し（通常はチェックサムによって）、必要に応じて内部アプリにパッチを適用します。ブートストラップに似ています。
Marstatoが述べたように、これはまだ完璧ではありません。たとえば、攻撃者は自分のサーバーにリクエストをリダイレクトし、その方法でカスタマイズされたパッチをインストールできます。これを回避する方法として考えられるのは、各トランザクションの前にこの整合性検証を行うことですが、これはかなり遅くなります。