web-dev-qa-db-ja.com

静的な公開鍵とパラメーターでECDHを使用できますか?

プライバシーに必要なプロトコルがあります。したがって、私はハイブリッド暗号を使用したいと思います。私の知識に基づいて、ECDHは高速で安全です。私のシステムは、信頼されたサーバー、クライアント、サーバーの3つの主要コンポーネントで構成されています

1- The server will generate ECDH parameters and the private key 
and compute the public key.
These parameters and the public key save at the trusted server.
2- When the client joins the network, the trusted server sends the 
parameter and public key to the client. 
3- The client generates his private key, computes public key and then computes 
the secret key by using the public key of the server that was received 
from the trusted server.
4- The client encrypts his message by using the secret key and 
send the encrypted message and his public key to the server.
5- When the server receives the message, the server computes the 
secret key by using the public key of the client and decrypts the 
message by using the secret key.

私の質問は次のとおりです:1-このシナリオは正しいですか? 2-静的な公開鍵とパラメーターでECDHを使用できますか?

2
ayman khallel

シナリオは正しくないようです。攻撃者の中間者のステップ2を停止するにはどうすればよいですか?

クライアントが攻撃者ではなく実際の信頼されたサーバーと通信していることをクライアントが知る方法は、プロトコルには見られません。


また、お客様のソリューションでは、クライアントがネットワークに参加するのをブロックしたり、クライアントを許可する前にクライアントの身元を確認したりする方法がないことにも気づきました(つまり、プライバシーは提供されますが、認証は提供されません)。これを行うには、ネットワークに参加する前に、なんらかの証明書/事前共有キー/認証トークンを使用してクライアントをブートストラップする必要があります。

基本的に、クライアントはsomeoneでセキュリティを通信しますが、誰が誰であるかはまったくわかりません。攻撃者にネットワークへの自由な参加を許可する場合、暗号化のポイントは何ですか?


静的ECDHは存在するので、あなたはcanを使用しますが、個人的には「現実の世界」で使用されたことがありません。CAからのRSA証明書を使用したECDHE + RSAなどです。


ええ、基本的に独自の暗号プロトコルを発明しないでください。しないでください。

暗号化の専門家によって適切に設計されたオープンソース実装を備えた安全なネットワーキングプロトコルはいくつもあります。 Signal/libsignalが思い浮かびますが、他にもたくさんあります。これは解決された問題です。車輪を再発明しないでください。

1
Mike Ounsworth

(あらゆる種類の)静的キーのペアを使用するには、プロトコルが公開キーをtrustに信頼するための何らかの方法が必要です。公開鍵が信頼されると、yesstatic-static Diffie-Hellmanを使用して生成できますセッション固有の秘密。もちろん、静的キーに加えてナンスが必要です。そうでなければ、常に同じ秘密の値を生成します。

すべての種類の秘密鍵合意スキームは、 NIST SP 800-56A Rev. 3:Discrete Logarithm Cryptographyを使用したペアワイズ鍵確立スキームの推奨事項 にあります。静的静的スキームはセクション6.3で指定されており、一時キー(e)と2つの静的キー(s)を使用しないため、C(0e、2s)と呼ばれます。

このような静的で静的なC(0e、2s)スキームはフォワードセキュリティを提供しないことに注意してください。二者間スキームのいずれかの秘密鍵が漏洩した場合、すべてのメッセージが危険にさらされます。 1つの解決策は、静的キーペアに加えて2つの一時キーペアを使用することです。このスキームは、NISTドキュメントではC(2e、2s)スキームと呼ばれます。

ただし、一般的にはc(2e、0s)スキームを使用してセッションシークレットを作成します。次に、使用される(ランダムな)パラメーターに署名を生成することにより、セッションが認証されます。その場合、静的な鍵ペアは、鍵合意自体ではなく、署名の生成(RSA、ECDSA)に使用されます。例を見つけるのは簡単です。TLSで使用されるすべてのDHEおよびECDHEスキームは、この種の鍵合意/認証を実行します。

0
Maarten Bodewes