web-dev-qa-db-ja.com

RSAまたはECDHE for x.509証明書-それぞれは何をしますか?

私はx.509証明書に比較的慣れていませんが、最近、画面の上部にあるhttps接続の南京錠を見ています。特定のWebサイトでは、パッドをクリックすると、サイトが鍵交換ECDHEを介して安全に接続され、これらの鍵がRSAで署名されていることが通知されます。しかし、サイトの完全な証明書を開くと、公開鍵はRSA 2048ビットです。公開鍵はRSA鍵ではなく、ECC 256ビットである必要があると思っていたので、鍵の交換はECCであり、RSAではないので、これは私を混乱させました。

私はおそらく本当に明白なものを見逃しているだけですが、どんな助けでもいただければ幸いです。

2
Sam Gregg

公開鍵/秘密鍵は(かなり)静的であり、通常は2048ビットまたは4096ビットです。これらはTLSネゴシエーションの初期に使用され、サイトのID(およびクライアントの場合はクライアントのID)を確認し、ネゴシエートします非対称暗号化を使用して、a)クライアントとサーバー間で共有される新しいキー、b)この接続に固有の、c)対称の新しいキー。これは実際に交換されるキーであり、短く、実際の輸送に使用されます。

非対称暗号化は(比較的)低速です。そのため、セッションは実際には対称暗号化で暗号化されます。

2
crovers

鍵交換スキームは、次の2つのアルゴリズムで構成されています。

  • ランダムにキーペアを選択するキー生成アルゴリズム。
  • 秘密鍵とリモートパーティの公開鍵を入力として受け取り、共有秘密を出力する鍵交換アルゴリズム。

署名スキームは、3つのアルゴリズムです。

  • キーペアをランダムに選択するキー生成アルゴリズム。
  • メッセージと秘密鍵を受け取り、署名を出力する署名アルゴリズム。
  • メッセージ、署名、公開鍵を受け取り、組み合わせが有効かどうかを示すブール値を出力する検証アルゴリズム。

認証された一時鍵交換を実行するには、当事者は、鍵交換スキームと署名スキームについて合意し、お互いの認証済み署名公開鍵を持っている必要があります。次に:

  1. 両当事者は、独自の一時的な鍵交換鍵ペアを生成します。
  2. 両当事者は、短命の鍵交換公開鍵に署名します。
  3. 両当事者は、その鍵の署名とともに、短命の鍵交換公開鍵を相手に送信します。
  4. どちらの当事者も、相手の短命な鍵交換公開鍵の署名をチェックし、無効な場合は中止します。
  5. 現在、両方の当事者は、それらの短命鍵交換秘密鍵と他方の短命鍵交換公開鍵を使用して、共有秘密を計算しています。

これは、一方の当事者だけが短命の鍵交換公開鍵に署名することでも実行できます。たとえば、通常はHTTPSを使用します。その場合、相手方は、相手方が本人であると主張しているという保証はありません。

これには、署名とDiffie-Hellmanアルゴリズムの任意の組み合わせを選択できます。署名方式がRSAであり、鍵交換方式がECDHであるかどうかは関係ありません。その場合、ステップ#1はECDH鍵生成アルゴリズムを使用してECDHE鍵ペアを生成し、次にステップ#2はRSA署名アルゴリズムを使用してそのECDHE公開鍵に署名します。署名アルゴリズムは、署名するメッセージがECDHE公開鍵であることを気にしません。これは、一方の当事者が署名し、もう一方の当事者が検証するための単なるデータです。


もう1つ注意すべき点は、質問のタイトルが何かについて混乱していることを示していることです。

RSAまたはECDHE for x.509証明書-それぞれは何をしますか?

ECDHEは証明書に関与していません。証明書には公開署名キー、その所有者を説明するメタデータ、および受信者がメタデータが正確であることを認証するのに役立つ署名が含まれています。証明書で使用される最も一般的な署名アルゴリズムはRSAです。 ECDSAは別の代替手段です。 ECDHは署名アルゴリズムではないため、関連しません。

証明書を使用する場合、上記のスケッチアルゴリズムは、最初に2つのステップを追加することによって変更されます。

  1. 両方の当事者が証明書を相互に送信します。
  2. どちらの当事者もPKIを使用して相手の証明書を検証し、それが無効な場合は中止します。

次に、証明書に含まれているキーを使用して、キー交換の署名と検証を続行します。

2
Luis Casillas

関連する質問:


短い答え:TLSセッションには、次の4つの主要なステップがあります。

  1. クライアントとサーバーは暗号スイートに同意し、ブラウザーと_security.stackexchange.com_はTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1)に同意しているので、例としてそれを使用してみましょう。
  2. クライアントは、クライアントから提供されたデータの公開鍵署名を行うことにより、サーバーにそれが誰であるかを証明するように強制します。この例では、RSAを使用します。
  3. クライアントとサーバーは、セッションキーを確立するためにキー交換を実行します。この例では、曲線_secp256r1_とともにECDHEを使用します。サーバーは、中間者攻撃を防ぐために、ECDHEメッセージにRSAキーを使用して署名します。
  4. セッションキーが確立され、両側(および他の誰も)がそのコピーを持たない場合、セッションの残りの部分(この例では_AES-128-GCM_)で、対称暗号を使用してこのセッションキーを使用します。
1
Mike Ounsworth