4

プッシュ通知を必要とする iOS アプリケーションの場合、最初にユーザーにプッシュ通知の許可を要求する必要があります。その後、デバイストークンが生成され、これにより、リモートサーバーはこのトークンを介してユーザーと通信できます。

ここで同様の質問を読みましたが、それで十分だとは思いません。下の画像は信頼できる証明書で、このデバイスで発生するすべてのトラフィックを表示できます。

CertMakerと同様にFiddler2を使用すると、HTTPS トラフィックを傍受できます。つまり、クライアントは、送信しているデータと送信先をおそらく知ることができます。

私の質問は、SSL は、クライアントがリモート サーバーに送信する内容を見ることから保護されていないことを知っているため、アプリケーション内で見つかった秘密鍵で単純に暗号化する必要があるかということです。

（これencrypt("device_token","secretkey_a0a0a0a")がObjective-Cであるふりをする）など？

誰かが私のアプリケーション内でそのキーを見つけることができませんでしたか? この質問も読みましたが、秘密鍵を取り戻せそうです。

これに対する私の計画は次のようになります。

  1. iOS アプリケーション内で、 という名前のランダムな文字列を生成しますactivate。
  2. トークンをランダムな文字列と私だけが知っている秘密鍵で暗号化します (ハッシュではありません)。(秘密鍵_a0a0a0)
  3. 暗号化された文字列を、生成されたランダムに生成された文字列 (アクティブ) と共に送信します。
  4. activeサーバー側で、秘密鍵を使用して有効なトークンを復号化できるかどうかを確認します。
  5. トークンが有効であれば、トークンをデータベースに保存します。

これにより、人々がランダムにトークンを入力するのを防ぎます はい、ただし、secretkey_a0a0a0文字列リテラルです。これをアプリケーション バイナリ自体で取得することは非常に可能です。

私の質問は、この秘密鍵をどのように保護するのですか? 答えは、人々が無効なトークンをサーバーに送信するのを防ぐにはどうすればよいかということでもあります。

暗号化という言葉を聞いたことがありますが、それはリソース ファイルだけに当てはまるのでしょうか?

これにどのようにアプローチすればよいですか？

4

4 に答える 4

3

SSL ピニングを行う場合 (AFNetworkingこれが実装されている場合)、サーバーの秘密鍵がなければ、クライアントとサーバー間の https トラフィックを (妥当な時間枠で) スニッフィングすることはできません。

于 2013-07-05T19:16:42.003 に答える
3

中間者がトークンを盗み、アプリケーションのユーザーに偽のプッシュ通知を送信するのではないかと心配している場合は、これが起こらないようにしてください。Apple apn サーバーへのリクエストは pem ファイルで署名する必要があるため、主な関心事は apn トークンではなく、証明書ファイルを保護する方法です。データベースに無効なトークンが書き込まれるのを防ぎたい場合は、CRC または奇数/偶数ビット メカニズムを実装する必要があります。

于 2013-07-04T10:47:44.727 に答える
2

プッシュ通知ガイドのセキュリティ セクション、特に「トークンの生成と分散」というタイトルのセクションを確認することをお勧めします。

デバイス トークンは、Apple の APNS 経由で接続するデバイスによって生成されます。私の推測では (ドキュメントには記載されていません)、特定のアプリ識別子に対して一意であるということです。

APNS はおそらくそれらの識別子を、pem通信に使用する証明書と照合し、プッシュ通知が実際にアプリから発信されていることを検証します。

このシナリオでは、デバイス トークンの暗号化はやり過ぎに思えます。

于 2013-07-04T21:19:35.277 に答える