web-dev-qa-db-ja.com

TLSはどのように機能しますか（RSA、Diffie-Hellman、PFS）？

「TLSのしくみ」がここで何度も議論されていることは知っています crypto ですが、私はまだ混乱しており、これまでにわかったことを要約します 1 この巨人のいつかこれが役立つことを期待してテキストの塊。

RSAとDHの2つの一般的なTLS鍵交換方法があります。どちらの場合も、典型的なTLSハンドシェイクは次のようになります。

  1. クライアントはClientHelloメッセージを送信します。このメッセージには、サポートする最大のTLSバージョンと、優先順の暗号スイートのリストが含まれています。さらに、ClientHello.randomと呼ばれるランダムな28バイトの値も転送されます。

  2. サーバーはServerHelloメッセージで応答し、サポート可能な最高の暗号スイートとバージョン、およびServerHello.randomと呼ばれる独自のランダムな28バイト値とデジタル証明書を返します。

  3. クライアントは、信頼できるCAストアに対してサーバーのデジタル証明書を検証します。次に、クライアントはpre_master_secretを作成し、サーバーのデジタル証明書から抽出されたサーバーの公開鍵で暗号化して、サーバーに送り返します。これはClientKeyExchangeとして知られています。

  4. サーバーは、秘密鍵を使用してメッセージを復号化し、マスターシークレットを生成します。

TLS 1.2でmaster_secretが生成される方法は次のとおりです 2 ：

  master_secret = PRF(pre_master_secret, "master secret",
                      ClientHello.random + ServerHello.random)
                      [0..47];

  1. その後、クライアントはChangeCipherSpecレコード（6バイト）もサーバーに送信し、対称暗号化とFinishedメッセージを使用することを示します。

  2. サーバーはChangeCipherSpecおよびFinishedメッセージで応答します。

  3. この時点以降、すべてのトラフィックはTLSを介して通信され、暗号化されます。

質問1：派生の"master secret"は何ですか？言い換えれば、実際の値は何ですか？

質問2：クライアントはどのようにメッセージを暗号化しますか？どのキー/シークレットが使用されていますか？ master_secretの役割がわかりませんか？

質問3：（RFCセクション7.3）では、「ランダムな値」とは何で、彼らの目的は何ですか？

  • プリマスターシークレットからマスターシークレットを生成し、ランダムな値を交換します。

質問4：「セッションキー」という用語をよく読みます。それは何ですか？ master_secretですか？

[〜＃〜] rsa [〜＃〜]

上記の手順3で整合性を制御するためにRSAを使用できることを知っています。つまり、公開鍵と秘密鍵の非対称暗号化を使用して、pre_master_secretがプレーンテキストで読み取れないことを意味します。

[〜＃〜] dh [〜＃〜][〜＃〜] rsa [〜＃を使用する主な弱点〜]はサーバーの秘密鍵を使用するものです。攻撃者はすべてのトラフィックを記録し、サーバーの秘密鍵が危険にさらされた場合にトラフィックを復号化できます。したがって、前方秘密を提供するために 4 、DHを使用できます。

DHは、離散アルゴリズムの原理に基づいて動作します。数学的特性により、両側（クライアントとサーバー）が独自のシークレット（それぞれa、b）を生成し、p、G、g ^ X mod p（xはa）を指定して同じshared secretを導出できるおよびb）パブリックチャネル経由（世界中で読み取り可能） 5 。

質問4：後続のすべてのトラフィックは共有シークレットを使用して暗号化されると思いますよね？

Perfect Forward Secrecy（PFS）

以前に記録されたトラフィックを誰も読み取れないようにするために、PFSが導入されました。基本的に、クライアントとサーバーは、有効期間が長い共有キーを使用する代わりに、有効期間が短いセッションキーを生成し、メモリから破棄します。

質問5：有効期間が短いキーとは何ですか？クライアントとサーバーのX（それぞれaとb）？

PSFおよびRSA

私の理解では、RSAが認証に使用されています（「サーバー」の送信はMiTMではなく「サーバー」から送信されます）。鍵の交換中に生成される整合性チェック用のHMACがあります。

質問6：正しいですか？

他の関連する質問や詳細は省略しているかもしれません。しかし、どんな反応もありがたいです。

tlsdiffie-hellmanperfect-forward-secrecy
3
CppLearner

率直に言って、これがあまり役に立たないと思います。それがそうかもしれない….

準備としてあなたが言うほとんどすべてはバージョン1.2までのTLSのためだけです。プロトコルにかなり大きな変更を加えたTLSバージョン1.3は昨年リリースされ（長い遅延の後）、現在拡散の過程にあります。歴史的な経験に基づくと、TLS <= 1.2は3年程度でかなりなくなると思われます。公平を期すために、オンラインで簡単に見つけられるリソースのほとんどは、特に1.3より前の＃20803のUrsine Epicsなどです。

どちらの場合も、典型的なTLSハンドシェイクは次のようになります。

どちらでもない、あなたが説明するものはカバーしますonly RSA; DHは異なります。詳細は以下をご覧ください。

  1. ...さらに、ClientHello.random ...と呼ばれるランダムな28バイトの値。
  2. ... ServerHelloメッセージ... ServerHello.randomと呼ばれる独自のランダムな28バイトの値とデジタル証明書。

.randomという名前のフィールドは実際には32バイトであり、4バイトのタイムスタンプ（コンピューターのクロックが正確でない場合でも、正確ではない場合はランダムではありません）と28バイトの実際のランダムデータに分割されます。鍵導出などで使用される値は32バイトの値です。

厳密に言えば、サーバー証明書はServerHelloメッセージ内ではなく、別のメッセージ内にあります。ただし、これらの両方のメッセージと、該当する場合はServerKeyExchangeおよび常にServerHelloDoneは、1つのrecordの一部である可能性があり、通常は1つのTCPレベルの送信の一部です。より実質的には、サーバー証明書で1つまたは複数の中間証明書または「チェーン」証明書を検証する必要がある場合、これは現在ほとんどの場合当てはまりますが、それらのチェーン証明書も含める必要があります。 「ブラウザは私のサーバー接続を安全であると見なしますが、$ other_swは$ some_errorを提供します」についていくつかのスタックに多くのQがあり、これは多くの場合、チェーン証明書を正しく構成していないことが原因です。 （Aは多くの場合、関連するサーバーソフトウェアによって異なります。）

  1. クライアントは、信頼できるCAストアに対してサーバーのデジタル証明書を検証します。次に、クライアントはpre_master_secretを作成し、サーバーのデジタル証明書から抽出されたサーバーの公開鍵で暗号化して、サーバーに送り返します。これはClientKeyExchangeとして知られています
  2. サーバーは秘密鍵を使用して[プリマスター]を復号化し、マスターシークレットを生成します

クライアントは、サーバー証明書を（通常は）チェーン経由でクライアントのトラストストアと照合し、サーバー証明書がクライアントが接続するサーバーの名前（またはアドレス）と一致することを確認します。 （HonestBank.comに接続する場合、接続しようとすると、信頼できるCAからWeAreCrooks.comに発行された証明書が取得されますが、その接続で銀行情報を送信する必要はありません。）

サーバーの両方andクライアントは、プリマスターと2つのランダムからmaster_secretを派生させます。

Ifサーバーがクライアント認証を要求し、クライアント証明書または「双方向」または「相互」認証とも呼ばれる場合、クライアントは実際にClientKeyExchangeの前に証明書を送信し、その後にCertVerifyを送信します。これはすべて5246で説明されていますが、ほとんど使用されません。

  1. その後、クライアントはChangeCipherSpecレコード（6バイト）もサーバーに送信し、対称暗号化を使用することを示します...
  2. この時点以降、すべてのトラフィックはTLSを介して通信され、暗号化されます。

CCSの後、すべてのトラフィックが暗号化されますおよび認証済み;どちらも重要です。方法は異なります。古い暗号スイートは、（純粋な）暗号を使用して暗号化し、（個別の）HMACを認証して （（HMAC = Hash-based Message Authentication Code） ;を使用します。 1.2には、正式にAEAD = Authenticated Encryption with Additional Dataと呼ばれる（2008年に）新しい認証済み暗号もありました。これは、暗号化と認証の両方を1つの複合操作で実行します。 セクション6.2.3. を直前のセクションと比較します。

質問1：派生の「マスターシークレット」とは何ですか？言い換えれば、実際の値は何ですか？

これはセッションごとに異なり、2つのエンドポイント（クライアントとサーバー）以外は誰もそれを知っているべきではないため、「秘密」です。 （デバッグ機能によって抽出できる場合もありますが、いくつかのQがあります。）その値は、8.1から投稿した式を使用して計算されます。ブラウザーの「検索」機能が壊れていて、表示の欠陥により目次が表示されない場合、PRFはPseudo（R）andom Functionを省略し、 セクション5 で説明されています。

質問2：クライアントはメッセージをどのように暗号化しますか？どのキー/シークレットが使用されていますか？ master_secretの役割がわかりませんか？

Master_secretはmultiple作業キー、またはより正確には秘密を導出するために使用されます。 セクション6. を参照してください。クライアントは「client_write_key」を使用して暗号化し、サーバーはそれを使用して復号化します。 IVを使用する暗号スイート（1.2では一部のAEADのみ）の場合も、client_write_IVを使用します。非AEADのHMACを使用する暗号スイートの場合、クライアントはclient_write_MACを使用してHMACを生成し、サーバーはそれを使用して確認します。 セッションキーは対称キーだけですか？ またはクロス https://crypto.stackexchange.com/questions/1139/what-is-the-purpose-of-four-different- secrets-shared-by-client-and-server-in-ssl 。

質問3：3（RFCセクション7.3）では、次のように述べられています。これらの「ランダムな値」とは何で、その目的は何ですか。
-プリマスターシークレットからマスターシークレットを生成し、ランダムな値を交換します。

これは、セクション8.1から3に投稿した式とまったく同じです。サーバーに送信されたClientHello.randomとクライアントに送信されたServerHello.randomはランダムな値で交換され、（共有された）premaster_secretと組み合わされて（また共有された）マスターシークレットを生成します。

質問4：「セッションキー」という用語をよく読みます。それは何ですか？それはmaster_secretですか？

これは、master_secret、または派生した作業キー/シークレット（複数）、またはその両方のいずれかです。特に、TLS <= 1.2でのセッション再開（別名：再利用）は、セッションID（ServerHello内）と、マスターシークレットを含む対応するセキュリティパラメーターを保存し、それらを使用することで行われます。後続または同時接続でも。

RSA

上記の手順3で整合性を制御するためにRSAを使用できることを知っています。つまり、公開鍵と秘密鍵の非対称暗号化を使用して、pre_master_secretがプレーンテキストで読み取れないようにします。

「プレーン」なRSA鍵交換はRSA暗号化を使用します。これは、非対称暗号化、つまり公開鍵暗号化の一種であるため、pre_master_secretを読み取ることができません。非対称暗号化または公開鍵暗号化では公開鍵と秘密鍵が使用されますが、通常「公開鍵と秘密鍵」とは言いません。私はあなたが「完全性管理」とはどういう意味か分かりません。 RSA暗号化は、暗号化テキストを操作する敵対者にそれほど抵抗しません。これにより、 ブライヘンバッハによる攻撃 が許可されました 問題が残る 。プレーンRSAハンドシェイクの（唯一の）保護は、（少なくとも1つのエンドポイントが正直で正しい限り）一種のMACとして機能するFinishedメッセージのPRF値です。

DH RSAを使用することの主な弱点は、サーバーの秘密鍵を使用することです。攻撃者はすべてのトラフィックを記録し、サーバーの秘密鍵が危険にさらされた場合にトラフィックを復号化できます。したがって、前方秘密4を提供するために、DHを使用できます。
DHは、離散アルゴリズムの原理に基づいて動作します。数学的特性により、両側（クライアントとサーバー）が独自のシークレット（それぞれa、b）を生成し、p、G、g ^ X mod p（xはそれぞれaとb）を指定して同じ共有シークレットを導出できます。 ）公開チャネルを介して（世界はそれらを読むことができます）5。

それは離散的ですlogarithm。より正確には、Diffie-Hellman ephemeralは、前方秘密を提供します。重要なのは「短命」です。 1.2（およびそれ以前）では静的（非一時的）DHキー交換も定義されていますが、これらは実際には使用されておらず、主に混乱の原因となっています。 （これらは1.3で完全に削除されます。）技術的に2つのバリアントがあります。TLSでDHEと指定された、整数を使用する元のDH-ephmeral。 ECDHEと呼ばれる楕円曲線バージョン。同じ原則が両方に適用されますが、それらを実装する実際のコード（およびデータ）はかなり異なります。

質問4：後続のすべてのトラフィックは共有シークレットを使用して暗号化されると思います。

直接ではありません。 [EC] DHE契約によって生成されたシークレットは、上記と同じ方法でプレマスターシークレットとして使用されます。最初にマスターシークレットに、次に作業キー/シークレットに導出されます。投稿した抜粋の直後に、セクション8.1.1と8.1.2を比較します。

Perfect Forward Secrecy（PFS）
以前にログに記録されたトラフィックを誰も読み取れないようにするために、PFSが導入されました。基本的に、クライアントとサーバーは、有効期間が長い共有キーを使用する代わりに、有効期間が短いセッションキーを生成し、メモリから破棄します。
質問5：有効期間が短いキーは何ですか？クライアントとサーバーのX（それぞれaとb）？

はい。ジェネリックDHはしばしばa/Aおよびb/B（正規には、アリスとボブ）の用語で記述されますが、TLS仕様では異なる表記法を使用することを除きます。 5246の整数DHEの場合、サーバーとクライアントの公開鍵はそれぞれdh_Ysとdh_Ycです。 （修正！）対応する秘密鍵はおそらくXsとXcですが、表示されていません。 4492のECDHEの場合、サーバーの公開鍵の名前はpublicですが、クライアントの公開鍵の名前はecdh_Ycです（ECCでは一般に、ポイントの座標にX、Yを使用し、秘密鍵を呼び出します） （整数）dと公開鍵（ポイント）Q）と秘密鍵は表示されません。

PSFおよびRSA
私の理解は、RSAが認証に使用されていることです（「サーバー」の送信はMiTMではなく「サーバー」から送信されます）。鍵の交換中に生成される整合性チェック用のHMACがあります。
質問6：正しいですか？

（これはPFSです。または単にFSです。）私はあなたが何を言っているのかまったくわかりません。そのため、前に言ったことをほとんど繰り返します。

  • rSA鍵交換の場合、プリマスターは証明書にサーバーの公開鍵を使用してRSAによって暗号化され、ハンドシェイクの唯一の整合性チェックは完了です。これは、HMACとは異なるがPRFを使用します。

  • [EC] DHE keyexchangeの場合、keyexchangeパラメーターはサーバー証明書のサーバーの公開鍵で署名されます。その鍵、つまり署名はRSA（どちらの場合も）、またはDSA（DSSとも呼ばれます）または鍵交換に応じてECDSA）

  • キー交換に関係なく、暗号に応じて、HMACまたはAEADのいずれか（両方ではない）がデータトラフィックの認証に使用されます。

4
dave_thompson_085