38

iPhone アプリから Web サービスにアクセスする必要があるとします。この Web サービスでは、アプリが共有シークレットを「知っている」ことを証明するために、クライアントが HTTP 要求にデジタル署名する必要があります。クライアントキー。リクエストの署名は HTTP ヘッダーに格納され、リクエストは単純に (HTTPS ではなく) HTTP 経由で送信されます。

このキーは常に秘密にしておく必要がありますが、iPhone アプリで使用する必要があります。

では、クライアント側に機密情報を保存しないように常に言われている場合、このキーを安全に保存するにはどうすればよいでしょうか?

平均的なユーザー (ユーザーの 99%) は、喜んでアプリケーションを使用します。なりすましによってサービスまたはクライアント キーの所有者に危害を加えるために、その秘密のクライアント キーを欲しがる誰か (敵?) がいるでしょう。そのような人は、自分の電話をジェイルブレイクし、バイナリにアクセスし、「文字列」または 16 進エディタを実行して、あちこち歩き回る可能性があります。したがって、キーをソース コードに格納するだけでは、ひどい考えになります。

もう 1 つのアイデアは、文字列リテラルではなく、バイト リテラルから作成された NSMutableArray にキーをコードに格納することです。

キーチェーンを使用することはできますが、iPhone アプリはキーチェーンに物を保存するためにパスワードを提供する必要がないため、アプリのサンドボックスにアクセスできる誰かが、その中のアイテムを簡単に見たり、簡単にデコードしたりできるようになるのではないかと心配しています。

編集 - だから私はキーチェーンについてこれを読みました:どのアプリケーションからもアクセスできないようにデバイス上で保護されています。」

したがって、おそらくこれがキーを保存するのに最適な場所です....もしそうなら、アプリのキーチェーンに事前に入力されたキーをどのように出荷すればよいですか? それは可能ですか？そうでなければ、キーがソース コードに含まれていない状態で、最初の起動時にキーを追加するにはどうすればよいでしょうか? うーん..

編集 - http://bugreport.apple.comでバグ レポート # 6584858 を提出

ありがとう。

4

10 に答える 10

9

究極の目標は、Web サービスへのアクセスを許可されたユーザーに制限することですよね? Web サービスを制御する場合は非常に簡単です (制御しない場合は、制御する Web サービスにラップします)。

1) 公開鍵と秘密鍵のペアを作成します。秘密鍵は、ダンジョンに置かれ、ドラゴンによって守られている Web サービス サーバーに置かれます。公開鍵は電話に出ます。誰かが公開鍵を読み取ることができれば、これは問題ではありません。

2) アプリケーションの各コピーに一意の識別子を生成させます。これをどのように行うかはあなた次第です。たとえば、ダウンロード時に実行可能ファイルに組み込むことができますか (これは iPhone アプリで可能ですか)? 電話の GUID を計算する方法があると仮定すると、電話の GUID を使用できます。本当に必要な場合は、セッションごとにこれをやり直すこともできます。

3) 公開鍵を使用して、「私の一意の識別子は $FOO で、このメッセージを承認しました」を暗号化します。Web サービスへのすべての要求でそれを送信します。

4) Web サービスは各要求を復号化し、有効な識別子を含まない要求をバウンスします。ここでは、好きなだけ作業を行うことができます: ホワイトリスト/ブラックリストを保持し、識別子ごとに使用状況を監視し、疑わしい動作を調査するなど.

5) 一意の識別子がネットワーク経由で送信されることはないため、電話に物理的にアクセスする以外に方法はありません。 彼らが電話機に物理的にアクセスできる場合、電話機のどこにあるデータも制御できなくなります。いつも。しょうがない。そのため、1 台の電話が侵害されても複数のアカウントが侵害されないようにシステムを構築しました。

6) ビジネス プロセスを構築して、a) アクセス権を悪用しているユーザーからアクセス権を削除し、b) 電話が物理的に侵害されたユーザーのアクセス権を復元します (これは、ユーザーが特定の権限を持っていない限り、非常にまれです)。敵）。

于 2009-02-13T03:25:28.243 に答える
7

簡単な答えは、今日の状況では、iPhone に秘密を保持することは不可能だということです。ジェイルブレイクされた iPhone は、手に収まる汎用コンピューターです。アクセスできる信頼できるプラットフォーム ハードウェアはありません。ユーザーは、特定のデバイスを一意に識別するために使用できるものなら何でもなりすましできます。ユーザーはプロセスにコードを挿入して、キーチェーンの検査などを行うことができます。(MobileSubstrate を検索して、私の言いたいことを確認してください。) 申し訳ありませんが、あなたはめちゃくちゃです。

この状況における一筋の光は、アプリの購入レシートにあります。アプリ内購入を使用してアプリ内でアイテムを販売すると、暗号署名されたレシートを受け取り、Apple でオンデマンドで確認できます。領収書を秘密にしておくことはできませんが、(あなたではなく Apple によって) 特定の購入にたどることができるため、海賊版がそれらを共有するのを思いとどまらせる可能性があります。また、レシートごとにサーバーへのアクセスを制限して、サーバー リソースが海賊によって流出するのを防ぐこともできます。

于 2009-11-05T20:13:55.963 に答える
4

UAObfuscatedStringは、問題の解決策になる可能性があります。ドキュメントから：

文字列定数を含むコードを記述すると、この文字列はクリア テキストでバイナリに保存されます。ハッカーはエクスプロイトを発見したり、文字列を変更してアプリの動作に影響を与えたりする可能性があります。UAObfuscatedString はバイナリに単一の文字のみを格納し、実行時にそれらを結合して文字列を生成します。これらの単一文字は、コンパイルされたコードのランダムな場所に挿入されるため、バイナリで検出される可能性はほとんどありません。したがって、文字列を抽出しようとする人にとっては、ランダム化されたコードのように見えます。

于 2014-08-14T03:52:10.403 に答える
2

もしあなたが iPhone OS 3.0 のみであることに耐えられるなら、プッシュ通知を見てみたくなるかもしれません。詳細には立ち入らないが、通知自体と一緒にペイロードを Apple のサーバーに配信することができる。ユーザーがアラートを受け入れると (またはアプリが実行されている場合)、コードの一部が呼び出され、キーチェーン アイテムが保存されます。現時点では、iPhone にシークレットを安全に保存する唯一の方法だと思います。

于 2009-06-17T00:25:57.703 に答える
2

私は同じ質問をして、答えを探し回るのに多くの時間を費やしました. 問題はニワトリが先か卵が先かという問題です。アプリに必要なデータをキーチェーンに事前設定する方法です。

いずれにせよ、ジェイルブレイカーが情報を明らかにすることを少なくとも難しくするテクニックを見つけました - 彼らは少なくともあなたのコードを逆アセンブルして、情報をマスクするためにあなたが何をしたかを見つけなければなりません:

文字列の難読化(リンクが壊れている場合は、「文字列の難読化 / 暗号化 (NSString)」を検索してください)

基本的に、文字列はアプリに配置される前に難読化され、コードを使用して難読化を解除します。

何もしないよりはましです。

デビッド

編集：私は実際にこれをアプリで使用しました。基本コーディング文字列を info.plist に入れ、コードでいくつかの操作 (rot13、バイトの回転/反転など) を実行しました。最終的に処理された文字列は、難読化された文字列をデコードするために使用されました。現在、3 通の機関は確実にこれを破る可能性がありますが、バイナリのデコードに何時間もかかるという莫大なコストがかかります。

これは私が遭遇した最高のテクニックだと言うつもりでしたが、UAObfuscatedStringに関する Kiran の投稿(別の回答) を読んだところです。これは難読化の方法がまったく異なります。アプリのどこにも文字列が保存されないという利点があります。各文字はメソッド呼び出しに変換されます。セレクターは文字列として表示されるため、ハッカーはクラスがその手法を使用したことをすぐに知ることができます。

于 2011-10-13T14:33:21.343 に答える
0

この同様の質問と私の答えは、あなたのケースにも関係があると思います. 簡単に言うと、トラステッド プラットフォーム モジュールが iPhone に搭載されているという話がありました。これにより、攻撃者の手に渡ったとしても、サービスが iPhone を信頼できるようになります。ただし、キーチェーンを使用するのが最善の策のようです。

于 2009-02-18T00:08:39.520 に答える
0

最初に秘密をアプリとキーチェーンに送信するために、プッシュ通知の提案を検討/試しましたか? または、これを達成するための他の方法を見つけることになりますか?

于 2009-09-24T07:41:35.560 に答える
0

iPhone アプリで画像を A​​mazon S3 にアップロードします。AWS 資格情報をアプリに入れる代わりに、S3 アップロード リクエストで使用する URI とヘッダーのために、アプリの電話をサーバーに向けます。私のサーバーは、S3 URI、適切な署名などを生成します。その後、AWS が単独で提供するよりも厳密で具体的なセキュリティ モデルをアプリの Web サービスに実装でき、ジェイルブレイクされた iPhone を持っている人に AWS キーを渡す必要はありません。

ただし、アプリに何らかの信頼 (資格情報など) を与える必要があり、その信頼が盗まれる可能性があります。あなたができることは、誰かが iPhone をジェイルブレイクし、アプリ内の資格情報を盗んだ場合の損害を制限することだけです。それらの資格情報が強力であるほど、最悪の事態になります。資格情報の権限を制限する方法には、次のようなものがあります。

  • グローバル資格情報を避けてください。ユーザー/アプリケーションごとに作成する
  • 永続的な資格情報は避けてください。可能であれば一時的にする
  • グローバル権限を避けてください。必要な権限のみを付与します。たとえば、書き込みパーミッションは、挿入、上書き、削除、リソース グループ A または B に対する書き込みなどに分割され、読み取りは名前付きリソースの読み取り、既存のすべてのリソースのリストの読み取り、リソース グループ A または B の読み取りに分割される可能性があります。など
于 2010-05-13T00:21:29.463 に答える
-1

不安定に聞こえます。キーを処理するために、HTTPS とおそらく暗号化パッケージを使用します。

CommonCrypto は iPhone で利用できると思います。

編集：まだ不安定に聞こえます。HTTP ヘッダーで秘密鍵を渡す人がいるのはなぜですか? あなたのネットワーク トラフィックを追跡する人は誰でも (たとえば、ログを記録する Wi-Fi ルーターを介して)、それを見ることができます。

メッセージ トラフィックを暗号化するための十分に確立されたセキュリティ方法があります。

編集 II: ああ、なるほど。キーチェーンを使用します...このような場合を想定していると思います。キーを使用してリクエストを生成していたことを見逃していました。ただし、十分な数の署名を検査して鍵生成スキームを推測するリスクを回避できるため、可能であれば引き続き HTTPS を使用します。

于 2009-02-13T02:09:15.617 に答える
-1

可能であれば、実行時にキーを作成することをお勧めします。このようにして、特定のセッション中にキーが逮捕された場合、セッションが終了すると、キーは無価値になります。彼らが十分に賢ければ、記憶からキーを把握することもできますが、キーは一定期間後に無効になるため、問題にはなりません。

于 2009-02-13T02:12:30.417 に答える