5

そのため、私は現在、Djangoで構築されたRESTAPIにリクエストを送信するモバイルアプリに取り組んでいます。

APIを保護するために、秘密鍵と公開鍵のペア認証システムを使用する予定です。

私が考えたワークフローは次のようになります。

  1. ユーザーはFacebookを使用してログインします
  2. ユーザーが署名すると、アプリは秘密鍵を生成します
  3. 秘密鍵はサーバーとアプリの間で共有されるため、サーバーはその秘密鍵を特定のユーザーにマップすることを認識します。
  4. モバイルアプリがリクエストを行うたびに、アプリはリクエストパラメーターと秘密鍵を使用してHMAC/署名を生成します。HMACに加えて、アプリはそれを送信したユーザーのuser_idも送信します（これは公開鍵として機能します）。
  5. サーバーは要求を受信すると、独自のHMACを生成します。user_idを取得し、テーブル内の秘密鍵を検索します。秘密鍵を使用して、要求パラメーターを使用してHMACを再作成し、モバイルアプリが送信したHMACと比較します。サーバーとモバイルに一致するHMACがある場合、サーバーは要求を実行します。

今、私の問題はステップ3にあり、秘密鍵をモバイルアプリとサーバーの間で何らかの方法で共有する必要があります。秘密鍵を安全に送信するにはどうすればよいですか？

4

1 に答える 1

5

まず、アプリのサーバー部分が秘密鍵を知る必要がある理由を尋ねます。ユーザーを認証するだけの場合は、公開鍵とユーザーIDのみが必要であり、ユーザーIDを公開鍵にすることはできません（使用する公開鍵を見つける方法が必要です）。

たとえば、キーを共有するプロセスであるステップ3は、次のようになります。

  1. アプリは公開鍵と秘密鍵のペアを生成します。
  2. アプリは公開鍵をサーバーに送信し、誰がそれを傍受できるかは気にしません。
  3. サーバーはその公開鍵を保存し、ユーザーが指定したIDに関連付けます。

たぶん、Facebookへの統合はこれを不可能にする部分です。Facebookがこのプロセス全体にどのように関与するのかよくわかりません。

キーの転送を少し安全にすることができる1つのことは、複数のチャネルを使用してキーを転送することです。

たとえば、アプリケーションは、REST APIを使用して生成された秘密鍵を送信できますが、対称暗号化スキームを使用して暗号化します。対称暗号化キーは、電子メールなどの他の媒体を介して、またはSMSを介して送信できます。これはモバイルアプリであるため、または登録ユーザーが提供する番号に自動電話をかけることもできます。キーは、実際の対称暗号化キーを生成するランダムパスフレーズにすることができ、ユーザーが入力できるものであることを確認します。次に、アプリのロックを解除するには、ユーザーはこのパスフレーズを画面に入力する必要があり、秘密鍵のロックが解除されます。

繰り返しになりますが、これは転送のセキュリティをわずかな差で改善するだけです。特に、秘密鍵の送信を傍受できれば、パスフレーズを含む電子メールを傍受できる可能性があるという事実を考慮してください。私の意見では、秘密鍵をサーバーに送信しないことは、最適であるだけでなく、必須でもあります。

于 2012-08-06T18:01:54.863 に答える