web-dev-qa-db-ja.com

認証と鍵交換のための暗号システムの評価

私はコンピュータサイエンスの修士課程で、自分の会社でコンサルタントとしてパートタイムで働いています。

私の最新のプロジェクトは、セキュリティ以外のすべてを処理する私の学位論文に基づいています。アプリケーションは、私を雇った会社よりもはるかに大規模な会社によって監査されます。監査の1つの要件は、すべてのチャネルのセキュリティの二重層です。

もちろん、最初のレイヤーはssl/tlsになります。 2つ目は次のように思いついた。

  • HTTPダイジェストアクセス認証-資格情報交換用
  • DHKE-後でAESキーを転送するために使用される共有シークレットを作成します。
  • RSA-サーバーからの応答にデジタル署名して、中間者がいないことを確認します。

私が最初に考えたのは、RSAを使用してキーを安全に輸送することでした。しかし、代わりにDHKEを使用することで、オーバーヘッドを削減できると思いました。私が間違っている場合は私を訂正してください。

プロトコルは次のように機能します。

Client-> (username + public information for DHKE) -> Server
Server-> (B from DHKE, salt for HTTP digest, AES key encrypted with DHKE secret) -> Client
                 (Whole message signed with server private key)
Client-> AES(Hashed information for HTTP digest) -> Server
Server-> AES(Session token) -> Client

セッションが開始されると、すべてのメッセージがAESキーで暗号化されます。私はおそらくこれを考えすぎて、多くの詳細を見逃しているので、いくつかのアドバイスをいただければ幸いです。

JohanRischよろしくお願いします

authenticationkey-exchangediffie-hellman
1
Risch

あなたはこれを言います：

監査の1つの要件は、すべてのチャネルでの2層のセキュリティです。

そしてそれはそれをすべて言います。監査人は、暗号化やセキュリティが実際にどのように機能するかを理解していません。彼らが医師である場合、彼らはすべての薬の投与量を2倍にするでしょう。彼らが腎臓を移植するとき、彼らは余分な腎臓を引っ掛けようとします。彼らが足を切り落とさなければならないとき、彼らは念のために、他の足も取り除くでしょう。

監査がそのような不合理な後援の下で行われることを考えると、あなたが望むことができる最善のことは、正式には「二重層」の儀式に準拠しているが、それ以外は十分に無害なことをすることです。これは、2つのSSLをカプセル化することを意味します。SSLトンネル内で、別のSSLを実行するだけです（監査人がどれほど嘲笑されているかに気付かないように、異なるアルゴリズムを使用します）。本当にそれらを畏敬の念を抱きたい場合は、内部SSLに別のライブラリを使用してください。 OpenSSL 外側、 GnuTLS 内側。

既存のプロトコルを独自に実装することには危険が伴います。独自のプロトコルをさらに設計する。あなたがそれを避けることができるならば、それをしないでください。既存のプロトコルと既存の実装を再利用すると、多くの時間を節約でき、脆弱性がはるかに少なくなります。

2
Tom Leek