iOSアプリのシナリオでのキーの保護、それは安全ですか？
私は自分のアプリの1つで使用している2つの秘密を隠そうとしています。
キーチェーンは良い場所だと理解していますが、アプリを送信する前に追加することはできません。
私はこのシナリオについて考えました-
- アプリのCoreDataデータベースにシークレットを事前にシードして、それらを他のエンティティに分散させて、それらを不明瞭にします。 （そのアプリにはすでにシードDBがあります）。
- アプリが初めて起動したら、キーを生成してキーチェーンに移動します。
- CoreDataからレコードを削除します。
それは安全ですか、それともハッカーはこれが起こっているのを見てそれらのキーを取得できますか？
* 3番目の編集**このシナリオを最初から説明していませんでした-アプリには多くのレベルがあり、各レベルにはファイル（オーディオ、ビデオ、画像）が含まれています。ユーザーはレベル（IAP）を購入できます。購入が完了したら、ファイルをデバイスにダウンロードする必要があります。
IOS6の場合、ファイルはApple新しい「ホストコンテンツ」機能で保存されます。iOS5の場合、ファイルはAmazon S3に保存されます。
したがって、このすべてのプロセスで2つのキーがあります。1. Apple IAP。2. S3キー、iOS5ユーザーのS3からファイルを取得するためのIAPキー：
NSString *secretAccessKey = @"xxxxxxxxx";
NSString *accessKey = @"xxxxxxxxx";
これらのキーを保護する必要はありますか？レベルを購入しなくても、S3からファイルを取得できるようになると思います。または、そのハッカーは、すべてのレベルが事前にダウンロードされたハッキングされたバージョンを構築することができます。
あなたの質問を複数のサブ質問/仮定に分解してみましょう：
仮定：
a）キーチェーンは安全な場所です
実際、それほど安全ではありません。アプリケーションがジェイルブレイクされたデバイスにインストールされている場合、ハッカーはキーチェーンからキーを取得できます
質問：
a）アプリ（AppStoreから配信されるバイナリ）にキーを入力して完全に安全にする方法はありますか？
短い答えはノーです。バイナリに何かがあるとすぐに、リバースエンジニアリングすることができます。
b）難読化は役立ちますか？
はい。それはハッカーがそれを理解するための時間を増やします。アプリにあるキーがリバースエンジニアリングに費やす時間よりも「コスト」が低い場合-一般的に言えば、それは問題ありません。
しかし、ほとんどの場合、あいまいさによるセキュリティは悪い習慣です。それはあなたが安全だと感じますが、そうではありません。
したがって、これはセキュリティ対策の1つになる可能性がありますが、他のセキュリティ対策も実施する必要があります。
c）このような場合はどうすればよいですか？*
あなたがやろうとしていることの背景を知らずにあなたに良い解決策を与えることは難しいです。
例として、なぜ誰もが同じAmazon S3にアクセスする必要があるのですか？読み取り専用または書き込みが必要ですか（Kendall Helmstetter Geinが指摘）。
最も安全なシナリオの1つは、次のようなものだと思います。
- アプリケーションはパスコードで保護する必要があります
- アプリケーションに初めてアクセスすると、サーバーに対してユーザーの認証（ユーザー名、パスワードの入力）が要求されます。
- サーバーまたは他の認証プロバイダー（Googleなど）に対して認証します
- サーバーは認証トークンをデバイスに送信します（多くの場合、それはあるタイプのCookieです）。
- アプリケーションのパスコードのハッシュに基づいてこのトークンを暗号化し、この形式でキーチェーンに保存します
- そして今、あなたは2つのことの1つをすることができます：
- 特定のキーをサーバーからクライアントに渡し（各クライアントが独自のキーを持つようにする）、アプリケーションパスコードのハッシュでそれらを暗号化する
- サーバーでS3を使用してすべての操作を処理します（クライアントに送信を要求します）
このようにして、複数の可能な攻撃から保護します。
c）うわぁ....私があなたが書いたばかりのものをすべて実装するつもりはありません。何ヶ月もかかるからです。もっと簡単なことはありますか？
クライアントごとにキーのセットが1つある場合は、便利だと思います。
これでも多すぎる場合は、サーバーから暗号化されたキーをダウンロードし、暗号化された形式でデバイスに保存し、復号化キーをアプリにハードコーディングします。それは最小限の侵襲性であり、少なくともあなたのバイナリにはキーがありません。
追伸ケンドールとロブはどちらも正しい。
アップデート1（新しい情報に基づく）
まず第一に、あなたは アプリ購入プログラミングガイド を見ましたか？.
サーバー製品モデルの下には非常に優れた図があります。このモデルは、新しいレベルを購入しなかった誰かから保護します。アプリケーションに埋め込まれたAmazonキーはなく、サーバー側は購入の受領を受け取るとレベルを引き渡します。
コンテンツを購入した（そしてそれをアプリケーションから引き離すことを決定した）誰かから保護するための完璧なソリューションはありません。何故なら、アプリケーションはコンテンツがデバイスにダウンロードされ、プレーン（暗号化されていない形式）でそれを必要とするからです。 ）ある時点で。
このケースが本当に心配な場合は、すべてのアセットを暗号化し、暗号化キーと一緒にサーバーから暗号化された形式で渡すことをお勧めします。暗号化キーはクライアントごとに生成し、アセットはそれを使用して暗号化する必要があります。
これは高度なハッカーを阻止しませんが、少なくともiExplorerを使用してファイルをコピーするだけの人からは保護されます（暗号化されるため）。
アップデート2
アップデート1についてもう1つ。暗号化されていないファイルを保存し、暗号化キーをどこかに（たとえば、キーチェーンに）保存する必要があります。
ゲームでインターネット接続が必要な場合は、暗号化キーをデバイスに保存しないことをお勧めします。アプリを起動するたびにサーバーから取得できます。
禁止アプリでの書き込みに使用するS3キーを保存します！短期間でトラフィックをスニッフィングする誰かがS3への書き込み呼び出しを確認し、短期間でそのキーを見つけて好きなことを行います。
アプリケーションがS3にコンテンツを任意のセキュリティで書き込むことができる唯一の方法は、ユーザーが制御するサーバーを経由することです。
それが読み取り専用の使用に使用されるキーである場合、つまり、S3をパブリックに読み取ることはできませんが、キーを書き込むことができない読み取り専用アクセスに使用できる場合、アプリケーションに埋め込むことができますが、プルしたい人はそれをプルできますアウト。
プリロードされた機密データを軽く不明瞭にするために、ファイルで暗号化すると、アプリはそれをメモリに読み込んで、キーチェーンに格納する前に復号化できます。繰り返しになりますが、誰かがこれらのキーにアクセスできるようになるため、できればあまり問題になりません。
編集：
新しい情報に基づいて、おそらく秘密をコードに埋め込む方が良いでしょう。因果関係のあるユーザーは、iExplorerのようなツールを使用して、コアデータデータベースやアプリケーションバンドル内の他のものに簡単にアクセスできますが、オブジェクトファイルは多少暗号化されています。ジェイルブレイクしたデバイスがあれば、暗号化されていないバージョンを簡単に入手できますが、意味のある文字列を見つけるのは難しい場合があります。おそらく、それらを2つの部分に格納し、コードに再アセンブルします。
繰り返しになりますが、ハッカーを止めることはできませんが、ほとんどの人を締め出すのに十分です。
ダウンロードできるオーバーライドシークレットがあるかどうかをサーバーに問い合わせるコードを追加することもできます。このようにして、シークレットが漏洩した場合、コピーされたシークレットを使用しているユーザーを遮断しながら、アプリに使用されているシークレットを変更することで、迅速に対応できます。まず、ダウンロードするオーバーライドはありません。新しいキーを使用できるようにするために、アプリケーションの更新を待つ必要はありません。
攻撃者に送信するコードに秘密を隠す良い方法はありません。このタイプのほとんどのものと同様に、キーを漏らさないようにするために無制限の時間を費やすのではなく、キーがリークした場合の問題を軽減する方法にもっと焦点を合わせる必要があります。たとえば、ユーザーごとに異なるキーを生成すると、不正に使用されているキーを無効にすることができます。または、中間サーバーを介して作業することで、プロトコルを制御できます（つまり、サーバーにはキーがあり、それを使用して特定のことだけを実行します）。
少し難読化するのは時間の無駄ではありません。それはいいです。しかし、それに多くの時間を費やさないでください。プログラム内にあり、非常に価値がある場合は、ハッキングされます。それがいつ発生したかを検出する方法と、それが発生したときに回復する方法に焦点を当てます。そして、可能な限り、その種の機密データを自分が管理する他のサーバーに移動します。