ASP.NET Web API を保護するためのソリューションはかなり散らばっているように見えるので、独自の公開/秘密キー暗号化スキームを導入することにしました。私のワークフローを見て、最後に行き詰まった質問に答えるのを手伝ってください. (繰り返しますが、これは .NET 4.0 Web API フレームワークに固有のものです)
- Web MVC 4.0 Web サイトでユーザー登録します。
登録すると、私のウェブサイトは 4 つのことを行います
a) このユーザーの RSAサーバー公開鍵を生成する
b)。このユーザーの RSAサーバー秘密鍵を生成します
c)。このユーザーの RSAクライアント公開鍵を生成します
d)。このユーザーの RSAクライアント秘密鍵を生成します
このユーザー アカウントの 4 つのキーすべてをデータベースに保存し、"APIKey" と呼ばれるサーバーの公開キーと "SecretKey" と呼ばれるクライアントの秘密キーをユーザーに渡します。これは、将来のハンドシェイク用です。ユーザーは、サーバーの秘密鍵もクライアントの公開鍵も知りません。
ユーザーが鍵を持っていることを確認したら、セキュリティ上の目的でデータベースから「クライアントの秘密鍵」を削除します。
ユーザーは、RSA サーバーの公開鍵 (APIKey) を使用して、サーバーの公開鍵 (または APIKey)+":"+ (ユーザー名、パスワード) の暗号化されたメッセージを送信することにより、WebAPI 認証サービスの要求を開始します。
サーバーは APIKey+":"+ 暗号化されたメッセージを受信し、秘密鍵を見つけ、メッセージを復号化し、ユーザー名とパスワードを取得し、メンバーシップ プロバイダーを使用してそれらが正しいことを確認します。
正しくない場合は、拒否された応答を作成します。それ以外の場合は、ユーザーの記録にあるクライアント公開鍵を見つけ、一意の時間依存セッション トークン (5 分で期限切れ) を作成し、それをデータベース + 作成時間に記録し、クライアント公開鍵を使用してトークンを暗号化し、返送します。クライアントに。
クライアントは応答を受信し、その「クライアント秘密鍵」または「秘密鍵」を使用して応答を復号化し、トークンを取得します。
ユーザーは、サーバー公開鍵を使用して以下を暗号化することにより、サービスに対して他の要求を行います。
a) セッション トークン b) タイムスタンプ (リプレイ攻撃が発生しないことを確認できます) c) データ
サーバーにその APIKEy+":"+暗号化されたメッセージを送信します
私が立ち往生しているのは、ステップ9以降です。
手順 9 で公開/秘密鍵を使用して通信する必要がありますか? 私が尋ねている理由は、ブラウザーが SSL を介してサーバーと通信するためです。最後に、ハンドシェイクが発生すると、合意された暗号スイート対称アルゴリズムを使用してメッセージをやり取りします。しかし、そうすると、この時点から病棟は安全になりますか?
その場合、ワークフローのどこで Web API とクライアントの間でこの契約を交換して、同じ対称アルゴリズムを使用して情報を暗号化/復号化することができますか?
ありがとう！！
編集: このワークフローに欠陥がある場合は、お知らせください。大変感謝しています。