私が最初にやりたいことは、あなたの期待の何かを明確にすることです.
あなたにとって重要なデータには 2 つの側面があります。
- 認証- あなたに送信されたデータは、許可された、変更されていないプログラムから送信されたものです
- 整合性- あなたに送信されたデータは、転送中に変更されていません。
整合性の問題は、プログラムでサーバーへの SSL 接続を使用するだけで簡単に解決できます。通常の CA のいずれかによって署名された証明書を使用する必要さえありません。実際、使用しない方がよい場合もあります。アプリの CA を作成し、そのプライベート CA を使用して Web サーバーで実行される証明書に自分で署名することができます。これを行うと、CA の公開鍵をプログラムにハードコーディングし、プライベート CA によって署名された証明書を持つサーバーへの接続のみを許可できます。これを行うと、誰かが MITM SSL プロキシ ( Fiddlerなど) を設定して、送信中にデータを編集するのを防ぐことができます。
認証は、解決するのが少し難しい問題です。偽のクライアントまたは変更された実際のクライアントがサーバーに接続して偽のデータを送信するのを防ぐ必要がありますが、これは簡単に解決できる問題ではありません。攻撃者が任意のコードを実行できるデバイスでソフトウェアが実行されている場合、問題を解決することは不可能です。それが不可能な理由は、ユーザーがデバッガーをアタッチし、コードを段階的に実行してプロセスを複製できるからです。それを「解決」する唯一の方法は、ユーザーが何も実行できないものでプログラムを実行することであり、実行するソフトウェアは最初にサードパーティによって精査される必要があります（ジェイルブレイクされていない電話など）。
ただし、問題を「緩和」することはできます。不可能にする必要はありません。悪意のあるユーザーが、あなたが入れた障害を克服する努力に見合わないほど難しいだけです。
攻撃者をより困難にするためにできること:
- すべてのメッセージは、極力隠した秘密鍵を使用して署名されています。
- コードにコード難読化ツールを使用して、リバース エンジニアリングを困難にします。
- SSL 接続でクライアント証明書を使用し、クライアント証明書を持たない接続をサーバーに拒否させます。
- コードをリバースエンジニアリングしにくくするために、あなたよりも経験豊富なコンサルタントに相談してください。
できることはもっとたくさんありますが、それが私が数分間考えただけで思いついたものです.
要するに、あまり心配しなければ、標準の SSL を使用するだけで、改ざんの 75% を阻止できる可能性があります。さらに心配な場合は、カスタム CA トリックを使用して SSL MITM 攻撃を阻止し、最大で 80% に達する可能性があります。しかし、その 80% を超えようとすると、指数関数的に難しくなり、ある時点で立ち止まって、自分自身に尋ねる必要があります。それだけの価値のある悪いデータを私に送ってくれませんか? それとも、100 人中 20 人が私に悪いデータを送ってくるのと一緒に暮らすことができますか? 10、5、1 はどうですか?」