デジタル証明書、署名、およびSSLのプロセスはどのように機能しますか？

Question

私はsslがどのように機能するかを理解しようとしています。アリスとボブの代わりに、クライアントとサーバーの通信について考えてみましょう。サーバーには、CAから取得したデジタル証明書があります。また、公開鍵と秘密鍵もあります。サーバーがクライアントにメッセージを送信しようとしています。サーバーの公開鍵はすでにクライアントで利用可能です。

Sslハンドシェイクが完了したと仮定します。

サーバーからクライアント：

サーバーはその公開鍵をメッセージに添付します。
（メッセージ+公開キー）でハッシュ関数を実行します。結果はHMACとして知られています。
秘密鍵を使用してHMACを暗号化します。結果はデジタル署名と呼ばれます。
デジタル証明書とともにクライアントに送信します。
クライアントは証明書をチェックし、それが予期されたサーバーからのものであることを見つけます。
サーバーの公開鍵を使用してHMACを復号化します。
（メッセージ+公開キー）でハッシュ関数を実行して、元のメッセージを取得します。

クライアントからサーバー

クライアントは（メッセージ+公開鍵）でハッシュ関数を実行し、同じ公開鍵を使用して暗号化します。
サーバーは秘密鍵を使用して復号化し、結果のデータに対してハッシュ関数を実行してメッセージを取得します。

私の理解が正しいかどうか私に知らせてください。

Tom Leek · Accepted Answer

投稿にいくつかの混乱があります。まず、 [〜＃〜] hmac [〜＃〜] はハッシュ関数ではありません。 HMACについては後で詳しく説明します。

ハッシュ関数

ハッシュ関数は完全に公開されたアルゴリズム（その中にキーはありません）であり、解きほぐすことができないような方法でビットをつぶします。誰でも任意のハッシュ関数を実行できますデータですが、ハッシュ出力からデータを見つけることは、私たちのウィットをはるかに超えているようです。ハッシュ出力のサイズは固定されており、通常は256ビット（SHA-256の場合）または512ビット（SHA-512の場合）です。 160ビットを出力するSHA- *関数は、SHA-160ではなくSHA-1と呼ばれます。これは、暗号化担当者が自分のデバイスに任せることができるのはその期間だけであり、5パイントを超えないことです。

署名アルゴリズム

signatureアルゴリズムは、数学的にリンクされたキーのペアを使用します。privatekeyおよび公開キー（公開キーから秘密キーを再計算することは理論的には実現可能ですが、実際にはビッグリーコンピュータでも実行が難しいため、公開キーを公開して公開します秘密鍵は秘密のままです）。鍵の数学的構造を使用して、署名アルゴリズムは次のことを可能にします。

generate秘密鍵を使用した一部の入力データの署名（署名は、適度にコンパクトな数学的オブジェクトです。たとえば、一般的なRSA署名では数百バイト） ;
verify公開鍵を使用して、一部の入力データに署名します。検証は、署名、入力データ、および公開鍵をパラメーターとして取り、「perfect、man！」のいずれかを返します。または「おい、これらは一致しない」。

安全な署名アルゴリズムの場合、署名値と入力データを生成して、特定の公開鍵による検証アルゴリズムが「良好」と表示するようにすることはおそらく不可能である、unless対応する秘密鍵。この場合、簡単で効率的です。細かい注意書きに注意してください。秘密鍵がないと、データと署名を選択できても、公開鍵で機能する一部のデータand署名値を呼び出すことはできません。あなたの好きなように。

「実行不可能と思われる」とは、世界中のすべてのスマート暗号技術者が数年間それに取り組んだにもかかわらず、5パイントの後でさえ、その方法を見つけられなかったことを意味します。

ほとんどの（実際にはすべての）署名アルゴリズムは、入力データをハッシュ関数で処理することから始まり、次にハッシュ値のみを処理します。これは、署名アルゴリズムがサイズに制限のある特定のセットの数学オブジェクトを必要とするため、ハッシュ関数の出力など、「大きすぎない」値を処理する必要があるためです。ハッシュ関数の性質上、問題はうまく機能します（ハッシュ出力への署名は、ハッシュ入力への署名と同じです）。

鍵交換と非対称暗号化

鍵交換プロトコルは、両方の当事者が数学オブジェクトを互いに投げるプロトコルであり、各オブジェクトは、ある方法で保持するいくつかの秘密の値とリンクされている可能性があります公開鍵と秘密鍵のペアとよく似ています。鍵交換の最後に、両方の当事者が共通の「値」（まだ別の数学的オブジェクト）を計算できます。これにより、回線上で交換されたビットを観察した人の把握を完全に回避できます。鍵交換アルゴリズムの一般的なタイプの1つは、非対称暗号化です。非対称暗号化では、公開鍵と秘密鍵のペアを使用します（署名アルゴリズムと同じ種類である必要はありません）。

公開鍵を使用すると、データの一部をencryptできます。そのデータは通常、サイズに制約があります（たとえば、1024ビットの公開鍵を持つRSAの場合は117バイト以下）。暗号化の結果は、バイトのシーケンスにエンコードできる数学オブジェクトです。
秘密鍵を使用すると、decryptを実行できます。つまり、逆の操作を実行して、初期入力データを復元できます。秘密鍵がなければ、幸運だと思われます。

次に、鍵交換プロトコルが実行されます。一方の当事者がランダムな値（ランダムなバイトのシーケンス）を選択し、それをピアの公開鍵で暗号化して送信します。ピアは自分の秘密鍵を使用して復号化し、共有秘密であるランダムな値を回復します。

署名の歴史的な説明は、「秘密鍵による暗号化、公開鍵による復号」です。Forgetその説明。間違っています。これは、特定のアルゴリズム（RSA）にのみ当てはまる可能性があり、実際には、適切なセキュリティを実際に備えていない粗末化されたバージョンのRSAにのみ当てはまります。したがって、no、デジタル署名は「逆」の非対称暗号化ではありません。

対称暗号化

2人の当事者が秘密の値を共有すると、対称暗号を使用して、機密データを使用してさらにデータを交換できます。両方の当事者が同じ鍵、つまり同じ知識、つまり同じ力を持っているため、対称と呼ばれます。プライベート/パブリックの二分法はもうありません。 2つのプリミティブが使用されます。

対称暗号化：データをマングルし、後でそれをアンマングルする方法。
メッセージ認証コード：「鍵付きチェックサム」：秘密鍵を知っている人だけが一部のデータのMACを計算できます（秘密鍵と公開鍵が同じである署名アルゴリズムのようなものです-- 「公開」キーは公開しない方がいいです！）。

HMACは一種のMACであり、スマートな方法でハッシュ関数上に構築されます。これを行うには多くの非スマートな方法があり、ハッシュ関数が提供するものについて微妙な詳細が原因で失敗します。提供しません。

証明書

certificateは公開鍵のコンテナです。上で説明したツールを使用すると、サーバーが公開鍵を持ち、クライアントがサーバーとの鍵交換に使用する公開鍵を想定することができます。しかし、クライアントは、悪意のある攻撃者であるサーバーを巧みに偽装する悪意のあるユーザーの公開鍵ではなく、正しいサーバーの公開鍵を使用していることをどのように確認しますか？そこで活躍するのが証明書です。証明書はsignedであり、物理的な身元の確認を専門とする人が作成します。Certificate Authorityと呼ばれます。 CAは「実生活」で（たとえば、バー内で）サーバーと出会い、サーバーのアイデンティティを検証し、サーバー自身からサーバーの公開鍵を取得し、ロット全体に署名します（サーバーのアイデンティティおよび公開鍵）。これは、証明書と呼ばれる気の利いたバンドルになります。証明書は、名前と公開鍵が互いに一致するという保証/ CAを表します（うまくいけば、CAは騙されにくいため、保証は信頼できます-できれば、 CAは、5番目のパイントの後にnot証明書に署名します）。

クライアントは、証明書を見ると、CA公開鍵と比較して証明書の署名を検証できるため、サーバーの公開鍵が実際に目的のサーバーに属しているという確信を得ることができます。

しかし、あなたは私に言ったでしょう、私たちは何を得ましたか？それでも、公開鍵、つまりCA公開鍵を知っている必要があります。それをどのように確認しますか？まあ、anotherCAを使用できます。これは問題を回避するだけですが、先験的によって署名されていないuber-CAからの一意のまたは少数の公開鍵を知るという問題に終わる可能性があります他の人は。思慮深く、マイクロソフトはそのような「ルート公開鍵」（「トラストアンカー」とも呼ばれる）約100をInternet Explorer自体の奥深くに埋め込みました。これが信頼の源です（正確には、あなたはレドモンド会社への信頼の根拠を失いました-これで、ビルゲイツが世界で最も裕福な男になった方法を理解しましたか？）。

[〜＃〜] ssl [〜＃〜]

それをすべてまとめて、SSLプロトコルにまとめます。SSLプロトコルは、現在 [〜＃〜] tls [〜＃〜] として知られています（ "SSL"は、Netscapeのプロパティのときのプロトコル名でした）株式会社）。

クライアントはサーバーと通信したいと考えています。クライアントがサポートする暗号化アルゴリズムのリストなど、一連の管理データを含むメッセージ（「ClientHello」）を送信します。

サーバーは、どのアルゴリズムが使用されるかを通知することによって応答します（ "ServerHello"）。次に、サーバーは自分の証明書（「証明書」）を送信します。クライアントがそれらを必要とする場合に備えて、いくつかのCA証明書を送信します（ルート証明書ではなく、中間の下位CA証明書）。

クライアントはサーバー証明書を検証し、サーバーの公開鍵をそこから抽出します。クライアントはランダムな値（ "プレマスターシークレット"）を生成し、サーバーの公開キーで暗号化して、thatをサーバー（ "ClientKeyExchange"）に送信します。

サーバーはメッセージを復号化し、プリマスターを取得し、そこから対称暗号化とMACの秘密鍵を導出します。クライアントは同じ計算を実行します。

クライアントは、暗号化され、派生キーでMAC化された検証メッセージ（「終了」）を送信します。サーバーは、Finishedメッセージが適切であることを確認し、応答として独自の「Finished」メッセージを送信します。その時点で、クライアントとサーバーの両方に必要なすべての対称キーがあり、「ハンドシェイク」が成功したことがわかります。次に、対称暗号化とMACを使用して、アプリケーションデータ（HTTPリクエストなど）が交換されます。

ハンドシェイク以外のプロセスに関与する公開鍵または証明書はありません。対称暗号化（3DES、AES、RC4など）とMAC（通常はSHA-1またはSHA-256を備えたHMAC）のみ。

John · Answer

多くの闘争の後。 SSL、非対称キー暗号化、デジタル証明書（DC）、デジタル署名（DS）の違いを以下で理解しています。

公開鍵証明書とも呼ばれるデジタル証明書とは何ですか？

DCは、デジタル署名を使用して、公開鍵を名前、住所などの識別情報にバインドする電子ドキュメントです。

証明書の内容：公開鍵証明書

最も重要なことは、署名アルゴリズム、発行者、公開鍵です。

非対称鍵暗号化とデジタル署名とは何ですか？

例を挙げて説明します。

どちらのマシンにも、暗号化キーのペア（公開暗号化キーと秘密復号化キー）があります。

Machine-AはMachine-Bの公開鍵と証明書にアクセスできます。
マシンBはマシンAの公開鍵と証明書にアクセスできます。

マシンAからマシンB

マシンAで：

Hash_function（Data）= Hash
Machine-Aの秘密キーを使用した暗号化（ハッシュ）= DS
DSおよびDC = Data + DS + DCにデータを添付
Machine-Bの公開鍵を使用して暗号化（Data + DS + DC）します。
Machine-Bに送信します。

マシンBで：

Machine-Bの秘密鍵を使用して復号化（Data + DS + DC）します。
検証DC=マシンAを認証します。
Machine-Aの公開キーを使用したDecrypt（DS）= Hash＃1
Hash_function（Data）= Hash＃2
if（Hash＃1 == Hash＃2）データと署名は有効です。

マシンBからマシンA

プロセスは、上記の逆です。

SSL/TLSとは何ですか？

TLSプロトコルを使用すると、クライアント/サーバーアプリケーションは、盗聴や改ざんを防止するように設計された方法でネットワークを介して通信できます。ほとんどのクライアント/サーバー通信では、サーバーのみを認証する必要があります。 TLSは非対称鍵暗号化を合理化して、この現象を効果的に利用します。 Secure Sockets Layer

クライアントとサーバーの例。

サーバーには、CAから取得したデジタル証明書があります。また、公開鍵と秘密鍵もあります。

ユーザーがで始まるURLをクリックした

https：//

このセッションには安全な接続が必要です。ブラウザはHTTPSでTCP接続を確立しますTCPポート443。

クライアント>サーバー：SYN
クライアント<サーバー：SYN + ACK
クライアント>サーバー：ACK

新しいTCP接続でのSSLハンドシェイク：
クライアント>サーバー：CLIENT_HELLO

クライアントはCLIENT_HELLOコマンドをサーバーに送信します。
- クライアントがサポートする最高のSSLおよびTLSバージョン。
- クライアントがサポートする暗号。暗号は優先順にリストされています。
- クライアントでサポートされているデータ圧縮方法。
- セッションID。クライアントが新しいSSLセッションを開始している場合、セッションIDは0です。
- 鍵生成プロセスで使用するためにクライアントによって生成されるランダムデータ。
クライアント<サーバー：SERVER_HELLO

サーバーはSERVER_HELLOコマンドをクライアントに送信します。
- SSLセッションに使用されるSSLまたはTLSのバージョン。
- SSLセッションに使用される暗号。
- SSLセッションに使用されるデータ圧縮方法。
- SSLセッションのセッションID。
- 鍵生成プロセスで使用するためにサーバーによって生成されるランダムデータ。
クライアント<サーバー：証明書（公開キー）

サーバーはCERTIFICATEコマンドを送信します。サーバー証明書が含まれます。
クライアント<サーバー：SERVER_DONE

サーバーはSERVER_DONEコマンドを送信します。このコマンドは、サーバーがSSLハンドシェイクのこのフェーズを完了したことを示しています。
クライアント>サーバー：CERTIFICATE_VERIFY

クライアントは、サーバーの証明書を検証したことをサーバーに通知します
クライアント>サーバー：

これまでにハンドシェイクで生成されたすべてのデータを使用して、クライアント（使用されている暗号に応じてサーバーの協力を得て）がセッションのプリマスターシークレットを作成し、サーバーの公開鍵（サーバーの証明書から取得）でそれを暗号化します）、暗号化されたプリマスターシークレットをサーバーに送信します。

サーバーは、その秘密キーを使用してプレマスターシークレットを復号化し、一連の手順を実行してマスターシークレットを生成します。

クライアントは、プレマスターシークレットに対して同じ一連の手順を実行して、同じマスターシークレットを生成します。

注：クライアントを認証する必要がある状況では、クライアントは、このハンドシェイクに固有であり、クライアントとサーバーの両方が認識している別のデータにも署名します。この場合、クライアントは、暗号化されたプレマスターシークレットと共に、署名されたデータとクライアント自身の証明書の両方をサーバーに送信します。
クライアント<>サーバー：

クライアントとサーバーの両方がマスターシークレットを使用してセッションキーを生成します。セッションキーは、SSLセッション中に交換される情報の暗号化と復号化、およびその整合性の検証に使用される対称キーです。

注：これからは、対称鍵暗号化になります。
クライアント>サーバー：

クライアントは、クライアントからの今後のメッセージがセッションキーで暗号化されることを通知するメッセージをサーバーに送信します。
クライアント>サーバー：終了

次に、クライアントは、ハンドシェイクの一部が終了したことを示す別の（暗号化された）メッセージを送信します。
クライアント<サーバー：

サーバーはクライアントにメッセージを送信し、サーバーからの今後のメッセージはセッションキーで暗号化されることを通知します。
クライアント<サーバー：終了

サーバーは、ハンドシェイクの一部が完了したことを示す別の（暗号化された）メッセージを送信します。

これでSSLハンドシェイクが完了し、セッションが開始されます。クライアントとサーバーは、セッションキーを使用して、お互いに送信するデータを暗号化および復号化し、その整合性を検証します。

George · Answer

「内部」の詳細な説明については、次の記事も提案できます。 HTTPS接続の最初の数ミリ秒ジェフ・モーザー著。この記事では、HTTPS通信セッションのパケットキャプチャを使用して、プロトコルの仕組みを説明します。私たちが話していることの実際を見るのは興味深いことであり、多くの「暗い」スポットを一掃します。

Steve Dispensa · Answer

結構です。証明書は、最初のSSLハンドシェイク中またはSSL再ネゴシエーション中にのみ機能します。その後、AES、（3）DES、RC4などの対称暗号が使用されます。公開鍵暗号は一般に対称暗号よりもコストがかかるため、一般に最初に対称鍵について合意するために使用されます。