ECDHおよび静的キー暗号化
しばらく経ちましたが、ECC暗号についての私の理解が正しいかどうか、私はまだ理解しようとしています。
基本的に私が理解したことから、純粋に非対称の暗号化は決して使用されません。通常、非対称暗号化は共通の対称鍵を共有するために使用され、それを使用して情報を共有します。これは、純粋な非対称暗号化よりも高速で柔軟性があります。
次の例では、アリスがボブにメッセージを送信することを望んでいて、どちらももう一方の公開鍵をすでに知っているとします。
RSAを使用した手順はおおまかに次のとおりです。
- アリスはランダムなキーを生成します（たとえば、128ビットのキー）
- アリスはボブの公開鍵で鍵を暗号化します
- アリスは暗号化されたキーをボブに送信します
- ボブは自分の秘密鍵で鍵を復号化します
- アリスは、ポイント1で生成されたキーで暗号化されたデータを送信します。ボブはポイント4で復号化されたキーを使用してそれを復号化できます
ただし、ECCに切り替える場合、実際の暗号化手順はありませんが、Diffie-Hellmanプロトコルを介した鍵交換のみが行われます。 ECDHで私が正しく理解した場合、手順は
- アリスは共有秘密を計算します
- アリスは、ポイント1で計算されたキーで暗号化されたデータを送信します
- ボブも共有秘密を計算し、メッセージを復号化します
さて、2番目の方法は、この他の質問を強く思い出させます： 静的キー暗号化はどの程度安全ですか？
ECDHが同じキーを再利用するという事実（RSAのキー交換ではランダムなものを毎回生成する）により、「安全性」が低下しますか？もしそうなら、どの場合に？
- 非常に一般的な脅威を示すために、わざわざ「安全」という言葉を使いました。これが脆弱であるいくつかの脅威モデルがある場合、それを示してください
（この質問を書いているときに）一時キー（ECDHE）を使用するECDHのバリエーションがあることを発見しましたが、これがRSAキー交換に似ているかどうかわかりませんでした。このプロトコルがECCを使用して任意のキーを変更するために使用される場合、それらがどのように機能するかを学ぶいくつかのリソース、またはそれを実装するライブラリを提供してください。
追加情報：これが質問の範囲を絞り込むことができる場合、私はサーバーよりも組み込みシステムに興味があるので、私の参照点は micro-ecc
あなたの理解はおおむね正しいですが、セキュリティ、特に暗号化においては、「広く正しい」はそれをカットしないことがよくあります。
ECIES（楕円曲線統合暗号化スキーム） と呼ばれる、データを暗号化するために楕円曲線暗号を使用する暗号化の標準があります。 （IESは他の鍵合意方法で使用できますが、RSAよりも実用的な利点は楕円曲線のみです。復号化が速く、鍵が小さくなります）。手順は次のとおりです。
- アリスは、選択した楕円曲線上のボブの公開鍵を取得します。
- アリスは、選択したカーブ上にランダムなキーペアを生成します。
- アリスはボブの鍵の共有秘密を計算します。
- アリスは、共有秘密を鍵導出関数（KDF）への入力として渡します。
- Aliceは、KDFの出力を対称認証暗号化のキーとして使用します。
- アリスは、ステップ2で生成された認証済みの暗号文と公開鍵をボブに送信します。
ECDHで生成された共有秘密は一様に擬似ランダムではないため、KDFステップは重要です。攻撃者は、単純な数学的観察によって、それに関する部分的な情報を取得できる可能性があります（たとえば、共有シークレットは1からNまでの数値で、Nは2の累乗ではないため、最上位ビットは0に偏っています）インテリジェントに作成された一連のキーを使用するか、ECDH計算からサイドチャネルを観察することにより、アリスとのキーアグリーメント。鍵に関する部分的な情報により、対称暗号で 関連鍵攻撃 が許可される可能性があります。共有秘密をKDFに渡すと、出力の数学的関係が「スクランブル」されます。
RSAベースのハイブリッド暗号化では、ランダムに生成されるため、同じ対称鍵が2回生成されることはありません。 ECIESでは、ランダムに生成される楕円曲線キーから派生するため、同じ対称キーが2回生成されることはありません。
共有秘密の計算は、まさにECDHの計算です。秘密鍵は使い捨てであるため、「エフェメラル（楕円曲線）Diffie-Hellman」と呼ばれることもあります。エフェメラルと非エフェメラルのDiffie-Hellmanは同じアルゴリズムです。「エフェメラル」とは、キーが1回だけ使用されることを意味します。
暗号化の観点からは、KDFの出力を使用して複数のメッセージを暗号化できます。 （ただし、常に同じアルゴリズムを使用します。2つの異なるアルゴリズム、たとえばAES-GCMとAES-CCMの両方、またはAES-GCMとCamellia-GCMの両方に同じキーを使用することは、セキュリティを低下させる微妙な弱点によるものである可能性があります暗号化されたメッセージを簡単に復元できる壊滅的な弱点に少しずつ。）結局のところ、対称鍵を持っている場合は、どのように取得したかは関係ありません。これを実行するかどうかは運用上の問題です。アリスまたはボブが誤って対称キーをリークするリスクはどのくらいありますか？アリスが対称暗号化ステップで誤ってIVを生成するリスクはどのくらいありますか？これらのリスクが心配されていない場合は、他の共有キーを扱うのと同じように、共有シークレットから生成された対称キーを扱うことができますが、この共有キーの配布の問題はありません。
アリスは、必要に応じて同じ入力で共有秘密の生成を複数回実行できます。彼女は毎回同じ出力を取得するため、攻撃者に追加の情報を提供しません。 AliceがECDHキーを再利用する場合の危険性は、ストレージから、またはサイドチャネルを介して、キーが漏洩するリスクが高まることです。
アリスが同じキーペアを使用して複数のパーティと通信することは安全です 。
すべてが原則として安全だからといって、それが良い考えだとは限りません。キーをそのままにしておくほど、部分的な侵害によってこのキーが明らかになるリスクが高くなります。
ECDHキーを再利用する一般的な理由は、スマートカード、セキュアエレメント、HSMなど、キーで操作を実行するがキー自体は公開しない高セキュリティのハードウェアにECDHキーを配置することです。ただし、これはアリスではなくボブに役立ちます。ボブはアリスが信頼できる方法で何らかの方法で彼の公開鍵をアリスに送信する必要があり、その後、彼は鍵を保持する必要があります。一方、アリスはメッセージの一部として公開鍵を送信するため、ECDH暗号化鍵を再利用しても大きなメリットはありません。
キーを再利用する正当な理由は、メッセージの長さに厳しい制約がある場合です。約65バイト節約できます（256ビット曲線上の非圧縮ポイント表現のサイズ）は便利です。
一方、パフォーマンスは大きな理由ではありません。 ECキーの生成は非常に高速です。適切な長さの均一なビット文字列です（これは、キーの生成に非常にコストがかかるRSAとは異なります）。公開鍵の計算にかかる時間を追加する必要があります。これは、基本的にECDHの計算と同じ計算です。したがって、キーを生成するのではなく、格納されたキーを使用してECIESのような暗号化を設定しても、計算の非対称暗号化部分の時間は2で除算されるだけです。
最後に、ECキーを再利用した場合でも、必要な数の対称キーを導出できることに注意してください。 KDFステップは、パブリックにすることができるオプションの追加入力を取ります。この追加の入力は、asalt、alabel、info stringまたはその他のさまざまな名前。シークレット入力とソルトの両方が同じである場合にのみ、同じKDF出力を取得します。