安全なiPhoneアプリ↔サーバー通信
IOSアプリとそのサーバーコンポーネントの間のプライベート通信を実現するための最良のアプローチは何でしょうか？変更されていない単一の「秘密鍵」をアプリのソースに十分に焼き付けていますか、それともそのような「ハンドシェイク」鍵の世代を何らかの方法で動的に設定する必要がありますか？
サーバー自体は機密データにアクセスできないため、ユーザーがいくつかのプライベートエンドポイントにアクセスしたとしても、どこにも到達することはありませんが、それらを公開しないようにしたいだけです。基本的に、iOSアプリからのリクエストでない限り、特定のルートに到達するすべてのリクエストを無視します。
サーバーコンポーネントは、重要であればRoRで実行されます。
すべての顧客に個別に取り消すことができる秘密鍵を提供しない限り、接続を効果的に拒否することはできません。しかし、これはおそらくやり過ぎです。ほとんどの人が弾丸を発射する気にならなければ、防弾ソリューションは必要ありません。
これはセキュリティの問題なので、脅威モデルと緩和戦略について説明しましょう。
顕著なコスト（処理コストなど）が発生する可能性があるURLヒットがあり、単純なDoS攻撃と模倣アプリの両方からそれを保護したいとします。
SSLを使用して、接続が簡単に分析されないようにします。要求のコストのかかる部分を実行する前に、接続を少し複雑にするために、obviuos以外のポート番号、リダイレクトシーケンス、Cookie交換を使用します。アプリに組み込まれた秘密のコードを使用して、接続を受け入れる必要があることをサーバーに通知します。
これで、パケットスニファを実行したり、コード内のURLのような文字列を調べたりするだけでは、高額なヒットURLを知ることができなくなります。潜在的な攻撃者は、アプリを逆コンパイルする必要があります。
コードを逆コンパイルしたり、デバッガーで実行したりすることはできません。攻撃者は最終的に秘密鍵と接続シーケンスを学習します。
攻撃の形で、または実行するためにサービスにアクセスする必要があるコピーキャットアプリの形で、高価なURLで不正なリクエストを受信し始めていることに気づきました。または、エクスプロイトコードが公開されている可能性があります。ただし、不正なリクエストと正当なリクエストを区別することはできません。
異なる秘密鍵を使用して、アプリに無料のマイナーアップデートを作成します。侵害された高価なURLと同じデータを提供する別の高価なURLにヒットする必要があります。しばらくの間、両方のURLにアクセスできるようにします。
ユーザーベースが更新されたバージョンに切り替わるのを見てください。侵害された高価なURLを抑制し、最終的に404を抑制します。あなたは、セキュリティ侵害を軽減したところです。振り出しに戻って。
免責事項：私はセキュリティの専門家ではありません。
あなたは 古典的な問題 を持っていますが、それは本当に解決することができません。
シンプルなプライバシーを確保するには（つまり、転送中にデータが盗まれたり変更されたりしないようにする）、SSLを介してすべてを実行し、サーバーに適切に-iPhoneが認識するCAが発行した証明書。
ただし、承認については、アプリ以外のユーザーがAPIにアクセスできないことを100％保証する優れたソリューションはありません。あなたの提案された解決策は動作しますが、以下を除きます：
- アプリをダウンロードした人は、必ず秘密鍵を所有している
- 彼らがなんとかしてあなたのアプリをアンパッケージして、それを逆コンパイルするならば、彼らは平文で秘密鍵を持っているでしょう
- 平文で秘密鍵を取得すると、それを使用して自分の悪意のある要求に署名できます。
これを回避する方法はありません。そのアプローチを採用できなかったと言っているのではありませんが、それが絶対確実ではないことを理解してください。 DRMが完全に無効 になるのはまさにこの問題です。
これが TLSおよびSSL の目的です。どちらも、固定の秘密鍵を必要とせずに安全な接続を作成できます。リンクされたページの説明セクションを読んで、その方法を確認してください。
多くの作業を行うことなくTLS/SSLの利点を得る効果的な方法は、クライアントがHTTPSプロトコルを使用してアクセスするWebサービスをサーバーに実装させることです。 HTTPSは安全な接続を介した単なるHTTPであり、iOSのURLロードシステムがそれを実装します。