モバイルアプリ内のデータを暗号化してWebサービスに送信する
AndroidおよびiO向けのモバイルアプリケーションを開発しています。Webサービスに送信されるモバイルアプリケーション内でのデータ暗号化に関して、ベストプラクティスは何ですか？
基本的に、GPSや時間などのいくつかのパラメータで構成される文字列を生成します。この文字列は暗号化してからWebサービスに渡す必要があります。
私は非対称暗号化でそれを行うことを検討しました。文字列を公開キー（ハードコードする必要がありますか）で暗号化し、秘密キーで復号化します。すべてのアプリケーションをリバースエンジニアリングできるため、これはまったく安全ではありません。ハードコードされた公開鍵と文字列生成関数を見つけたら、何でも好きなように偽造するのは簡単です。
どんな入力でも大歓迎です。
編集：私の質問のより明確なアプローチ：私のアプリケーションの関数は文字列を生成し、別の関数はこの文字列を暗号化してサーバーに送信します。アプリケーションをリバースエンジニアリングした後、自分で作成した文字列が暗号化関数に渡されないようにするにはどうすればよいですか？つまり、モバイルアプリケーションからサーバーに送信されたデータが他人によって作成されていないことを暗号化技術で確認できますか？
できません。これは、汎用コンピューティングの基本原理です。
あなたはシャノンの格言にぶつかっています：
敵はシステムを知っています。敵はすぐにそれらに完全に慣れるだろうという仮定の下で、設計システムをすべきです。
私のポイントを完全に明確にするために：あなたは誰かに車を与えて、特定の1つの場所にのみ運転するように彼らに要求しています。彼らが他の場所に行くことを決定するのを妨げるものは何もありません-あなたは彼らがあなたの要求を守ることに頼っています。
セキュリティメカニズムが、誰かが実行可能ファイルを見て、暗号化方法や埋め込みキーを発見しないという希望にかかっている場合、それはセキュリティメカニズムではありません。それはあいまいなメカニズムです。
私が知ることができることから、あなたはユーザーがGPS座標を介して指定されたエリア内にいることを強制しようとしており、ユーザーがそれらの座標を偽装しないことを確実にしたいと考えています。これは行うことはできませんスマートフォンなどの汎用コンピューティングプラットフォームでは。テクノロジースタックを見てみましょう。
- あなたのウェブアプリはどこかの「クラウド」に座っています。あなたはこれを完全に制御します。
- あなたのアプリは電話に座っています。必要に応じて、これを最小限に制御できます。可能な攻撃ベクトルには、リバースエンジニアリング、アプリの変更、直接のwebappリクエスト、メモリ編集などが含まれます。
- スマートフォンのOS（例AndroidまたはiOS）がデバイス上で実行されます。これを制御することはできません。これは、GPSデバイスとの通信および使用可能な座標へのデータの変換を担当します。可能な攻撃ベクトルには、 ：テストパネル経由の偽のGPS座標（ほとんどの電話にこの機能があります）、変更されたGPSドライバー、フックされたGPS APIなど.
- GPSモジュールはデバイス内にあります。これを制御することはできません。 GPSモジュールは、GPS衛星と通信し、標準バスを介してCPUにデータを中継します。可能な攻撃ベクトルには、バスの中間者、交換用の偽のGPSモジュール、ソフトウェア無線機からの偽のGPS衛星信号などが含まれます。
したがって、あなたはできませんアプリレベル、OSレベル、ハードウェアレベル、さらにはGPS信号レベルで改ざんされている可能性があるため、ウェブアプリに受信したGPS座標が正しいことを強制します。または、それをすべて排除すると、誰かが電話を完全にスキップして、偽のデータを含むWebアプリケーションに手動でリクエストを送信する可能性があります。
解決策は、リスクを受け入れるか、セキュリティモデルを変更することです。
常にSSLを使用する必要があります。
SSLには公開鍵が組み込まれており、「認証」を提供します。つまり、通信しているサーバーが、実際に必要なWebサービスであり、詐称者ではないことを保証します。
特に明記していないか、その他の必要がある場合は、SSLを使用すると、サーバーへのデータの送信と転送中のデータの保護に関するすべての懸念を解決できると思います。
更新
コメントの更新された要件に基づいて、Webサービスに送信されるGPSデータのスプーフィングを防止したいと考えています。
デバイスを管理できない場合（管理またはその他）、@ Polynomialの発言は正しいです。クローズドシステムを作成している場合、組み込みシステムを使用している場合、または企業内にいる場合は、さらに多くのオプションがある可能性があります。
アプリケーションを実行するすべての電話を完全に制御できるとします。つまり、電話をロックダウンして、管理者パスワードの排他的な制御を維持し、それをエンドユーザーに決して与えないことです。
次に、各デバイスに一意のキーを割り当てて、Webサービスに送信されるデータを暗号化できます。
特定の電話が侵害された場合、使用されたキーに基づいて、その電話がどのデバイスであったかを判別できます。
ベストプラクティスは、正確な使用方法によって異なります。
私があなたの質問から収集したのは、「足跡」アプリケーションのように、GPSデータと時間を送信するアプリがあるということです。誤ったデータが供給されていないことを確認する必要があるため、データが偽のデータではなく、実際のクライアントから送信されていることを確認する必要があります。
残念ながら、他の回答が述べているように、それは不可能です。アプリのAPKファイルが与えられれば、誰かがそれをJavaソースコードにデコンパイルできる可能性があります。独自のソースほどエレガントではないかもしれませんが、確実に機能します。コードを使用して、自分のアプリは、あなたが期待したとおりにあなたのアプリと通信し、それを使って偽のデータをフィードします。
したがって、データ転送に使用するスキームは、クライアントを信頼する決してべきではありません。代わりにuserを信頼する必要があります。
このソリューションを検討してください。アプリサーバーが信頼された公開鍵証明書で署名されている（この状況では、アプリケーションがexactを知っているという唯一の理由で信頼されている可能性があります）証明書を与える必要があります。これは「証明書のピン留め」と呼ばれ、グローバルCAによって署名された証明書を取得したかどうかに関係なく機能します。要求に応じて、この証明書を要求する人に提示します。それは公開情報であり、インターネット上のすべてのハッカーフォーラムでこれを塗りつぶすことができ、それは同じくらい安全です。クライアントはこの証明書を使用して、安全な通信トンネルをネゴシエートします。これはかなり標準的なものです。
これで、機密性が得られました。 authenticity;が必要です。相手が誰なのかわからない場合、他の誰もあなたとふたりの会話を聞くことができないことは問題ではありません。したがって、チャネルが開いたら、次に予想されるのは、ユーザー資格情報を含む認証要求です。セッションが認証されていない場合は、GPSデータの送信要求を拒否する必要があります。ユーザーがそのようなリクエストで提供する資格情報は、ユーザー名とパスワード、電話のIMEIまたはMACアドレス、暗号鍵フォブからの10桁のコードなど、適切であることを確認するために必要なものonly特定のユーザーがこれらの資格情報を提供できる可能性があります。
これらの資格情報を取得し、それらが期待どおりであることを確認したら、それを行いたい場合は、「認証トークン」を送り返します。これは、他の開いているセッションで使用される乱数とは異なる乱数と同じくらい簡単です。 V4 GUIDもかなり良い選択です。この識別子は、このセッション中にこのチャネルでデータを送受信するためのリクエストの一部として必要です。この特定のチャネルではonlyのみが受け入れられます。 onlyこの一意のセッションが開いている限り。
これがすべてセットアップされると、そのセッションの安全なチャネルを介して行われた、正しい認証トークンを含むサービス呼び出しは、一般に信頼できるようになります。おそらくもう1つ含める必要があります。これは、リプレイ攻撃に対する防御策です。攻撃者は、既に発言されていることを繰り返すだけで、あなたを混乱させるために何が何を送受信されているかを正確に知る必要はありません。そのため、システムが一意のメッセージを送信する回数に関係なく1回だけ処理するようにするには、各メッセージにnonce、一意のメッセージを含める必要があります。一度使用された値。リクエスト構造の一部を形成し、セキュアチャネルによって暗号化された単純なシーケンスカウンター値で十分です。次に、シーケンス番号がクライアントから受信する予定の次のメッセージではないメッセージを無視するだけです（これに固有のフォールトトレランスが存在する可能性がありますが、never同じクライアントからの同じタイプのサービス要求を、同じシーケンス番号で2回受け入れます。