データとともにJSON文字列を返すURLがあります。さて、このデータを秘密にしておきたいので、私のAndroidアプリケーションだけがそれを表示できます。
私の最初のアイデアは、（サーバー側の）秘密鍵を使用してデータをエンコードし、同じ秘密鍵をアプリケーションに保存して、メッセージをデコードできるようにすることでした。ただし、攻撃者（ユーザー）は.apkのコンプライアンスを解除し、秘密鍵を取得する可能性があります。
これは通常は実行できません。ユーザーがデータを表示する必要がある場合は、データを復号化できる必要があります。データをディスクなどに保存しないことで多少難しくすることができますが、決心したユーザー/攻撃者はできます。データを表示するには、メモリをダンプしたり、デバッガを使用したりします。最初に保護しようとしている脅威について考えてから、行動方針を決定します。
アプリのみがデータをダウンロードできるようにする場合は、何らかの認証+SSLを使用する必要があります。アプリでキーまたはパスワードをハードコーディングすると、それを抽出するのはかなり簡単なので、それほど購入する必要はありません。ユーザーがアプリを使用するたびにパスワードを入力するようにすると、ユーザーはすぐにイライラし、1つ星の評価をたくさん残します。中間点は、OAuth（または、本当に必要な場合はClientLoginですが、非推奨になっています）などのトークンベースの認証を使用し、ユーザーに既存のアカウントで認証させて、認証しないようにすることです。登録して、さらに別のパスワードを覚えておく必要があります。ほとんどのAndroidデバイスにはすでにGoogleアカウントが設定されているため、これを使用できますが、これには追加の権限とユーザーの同意（確認ダイアログ）が必要です。
一部の難読化ツールは他の難読化ツールよりもはるかに優れていますが、データが表示されるのではなく、コードがリバースエンジニアリングされるのを防ぎ、やる気のないハッカーからユーザーを保護しますが、それ以外のことはほとんどありません。
コードを正常に逆コンパイル/再コンパイルした人からデータを保護しようとしている場合、ユーザーがデバイスに保存されておらず、暗号化/復号化に使用されるパスワードでデータを承認しない限り、データが明確になることはありません。その場でデータ。
私が考える最も簡単な方法は、データ送信にパスワードで保護されたHTTPSセッションを使用し、同じNEVER TO BE STOREDパスワードを使用してオンザフライで暗号化/復号化するか、同じNEVER TOBESTOREDパスワードを使用してSQLで暗号化して保存することです。
これは、実際に何をしようとしているのか、実際にどれだけ安全である必要があるのか、サーバー側でどの程度制御できるのかなどによって、かなり洗練されたものになる可能性があります。例えば
カスタムに移行したい場合、Androidは安全な鍵交換プロトコル、秘密/公開鍵のサポート、および多くの一般的な暗号化のサポートを備えているため、すべて実行可能ですが、あなたがきれいでない限り、自分で試してみるかどうかはわかりませんすべてのプロトコルとその適切な使用に慣れています。
人々は通常、思っているほど多くのセキュリティを必要としませんが、インフラストラクチャを導入して時間をかけてレビューすることをいとわない場合は、かなり安全になります。