7

最近、私はPKIの実際の作業プロセスに関する基本的な理解に出くわしました。私は原則に関する主要な記事を見てきましたが、それでもこのプロセスを理解するのはかなり馬鹿げています。PKIは「私のブログ」用ではないことを理解していますが、簡単にするために、簡単な例「My e-Shop」（たとえば、apacheやphp）と簡単な概念を見ていきましょう。あいまいまたは間違っている可能性のあるステートメントをいくつか書きましたが、それがPKIのプロセスについて知りたいことです。

  1. 会社としての「私のeショップ」は、サードパーティのCAで「認定」される必要があります。つまり、そのCAで1年間のメンバーシップを購入する必要があります。そうすると、システムに「My e-Shop」が登録され、証明書や一意の公開鍵と秘密鍵のペアなどが発行されます。証明書ファイルを入手できますか？

  2. 発行された証明書には私の情報と公開鍵が入力され、Webサーバーのファイルに保存されます。証明書は、「私のeショップ」が泥棒の局ではないことを証明します。

  3. ユーザーが「https」を介して「Mye-shop」にアクセスするたびに、ブラウザは「Mye-shop」の提示された証明書をCAに登録されているものと「サイレント」にチェックします。

    1. ユーザーはどうですか？https経由で「Mye-shop」に入ると、ブラウザはローカルの公開キーと秘密キーを生成しますか？

  4. 一部のユーザーがhttps経由で「Mye-shop」に入ると、次のようになります。「Mye-shop」（Webサーバー）はユーザーの公開鍵（PK1）を取得します。サーバーは「Mye-shop」の証明書をユーザーにサイレントに提示するため、ユーザーは「My e-shop」の公開鍵（PK2）を取得します。サイレントチェックの後、ユーザーのブラウザは提示された証明書を検証し、安全なパイプが確立されます。

  5. ユーザーが安全なパイプを介してリクエストを送信すると、リクエストは「Mye-shop」の公開鍵で暗号化されます。次に、Webサーバーは秘密鍵を使用して要求を復号化します。次に、Webサーバーはユーザーの公開鍵を使用して暗号化された応答を送信します。最後に、ユーザーのブラウザーは自分の秘密鍵を使用して応答を復号化します。

4

3 に答える 3

3

これらの質問を質問ごとに取り上げます。

(1) 企業としての「My e-Shop」は、サードパーティ CA で「認証」される必要があります。つまり、その CA で何らかの 1 年間のメンバーシップを購入する必要があるということです。その後、CA はシステムに「My e-Shop」を登録し、証明書や一意の公開鍵と秘密鍵のペアなどを発行してくれます。証明書ファイルを取得できますか?

はい。また、これは CA によって異なります。一部の CA では、1 年間のメンバーシップと有効なクレジット カードで十分です (たまたま泥棒の集団であっても、取得するのは難しくありません)。一部の CA では、一定量の事務処理が必要です。本人であることを確認するため。CA は、顧客確認プロセスと同じくらい優れているため、一般に、プロセスが面倒であるほど、CA は優れた (そして高価な) ものになります。

お金を払い、書類を作成したら、あなたと CA は少なくとも 2 つのものを生成します。

  • 公開鍵と秘密鍵のペア。多くの場合、これは CA ではなく、あなたによって生成されます。キー ペアの生成方法と保存方法の品質も、別のエンティティが Web サイトをどれだけ信頼できるかを決定する要因となります。一般に、識別証明書 (SSL サーバー証明書など) の場合、顧客 (My e-Shop) にキーを生成してもらうことをお勧めします。
  • 標準形式 (例: PKCS10) で証明書要求を CA に送信します。My e-Shop と公開鍵に関する一連の情報が含まれます。
  • CA会社はあなたの書類をチェックし、あなたがあなたであることを確認します. 次に、CA を使用して証明書にデジタル署名します。その証明書には、提供したばかりの一連の情報、CA プロバイダーが設定した追加情報、公開鍵、および前述のすべてのデータを CA の秘密鍵と暗号的にバインドすることによって生成されたデジタル署名が含まれています。

次の 2 つのいずれかが返されます。

  • 証明書のみ (独自の鍵ペアを生成した場合)
  • 証明書とキー ペア - CA がキー ペアを生成した場合

(2) 発行された証明書には、自分の情報と公開鍵が入力され、Web サーバーのファイルに保存されます。証明書は、「My e-shop」が泥棒の局ではないことを証明します。

はい...ちょっと。Web サーバーには、署名付き証明書とキー ペアの両方が必要です。キー ペアは、エンド ユーザーへの SSL ハンドシェイクの一部として使用されます。この交換は、証明書を手に入れた一部の窃盗団ではなく、キー ペアを所有していることを証明します。これが、鍵ペアを保護する理由です。

(3) ユーザーが「https」を介して「My e-shop」にアクセスするたびに、ブラウザーは、提示された「My e-shop」の証明書と CA に登録されている証明書を「黙って」チェックします。

「サイレント」の定義について。ベースライン ブラウザは、証明書が次のことを確認します。 - 現在有効であること - ブラウザが信頼する CA によって署名されていること (または、アクセスが拒否されるか、迷惑なポップアップが表示されること)

ブラウザのアドオンはさらに進んで、フル パスのチェック (自己署名ルートまで) や証明書の状態のチェックなどを行います。パイプを介して情報が共有されるリスクが高いほど、より多くのチェックが必要になります。

(4) ユーザーが https 経由で「My e-shop」に入ると、次のことが起こります。「My e-shop」(Web サーバー) は、ユーザーの公開鍵 (PK1) を取得します。サーバーは、「My e-shop」の証明書をユーザーにサイレントに提示するため、ユーザーは「My e-shop」の公開鍵 (PK2) を取得します。いくつかのサイレント チェックの後、ユーザーのブラウザは提示された証明書を検証し、安全なパイプが確立されます。

  • ユーザーはどうですか？https 経由で「My e-shop」に入ると、ブラウザはローカルの公開鍵と秘密鍵を生成しますか?

OK - 物事はここで脱線しています。

詳細については、SSL プロトコルを確認してください。ハンドシェイクのセクションで確かな事実がわかります。

ブラウザーと Web サーバーは、セッション暗号化キーを作成するための情報をやり取りします。ブラウザーは、セッションのセットアップに使用されるいくつかの開始材料を生成しますが、それは「ユーザーの公開鍵 (PK1)」ではありません。サーバーがクライアント認証用に構成されていない限り、ユーザーは PKI 資格情報を持っている必要はありません。通常の My e-Shop では、サーバーには PKI クレデンシャルがあり、ブラウザーはその 1 つのセッションだけのためにオンザフライでいくつかのキー マテリアルを生成しています。サーバーは、SSL に関して、ブラウザのユーザーが誰であるかをまったく知りません。すべてのユーザー ID は、アプリケーション レベルのパスワードまたはその他のものから取得されます。

注: これは通常の商取引用です。リスクが高いほど、保護が強化されます。リスクの高いトランザクションでは、クライアント認証が必要になることがよくあります。

(5) ユーザーがセキュアパイプ経由でリクエストを送信すると、リクエストは「My e-shop」の公開鍵で暗号化されます。次に、Web サーバーはその秘密鍵を使用して要求を復号化します。次に、Web サーバーは、ユーザーの公開鍵で暗号化された応答を送信します。最後に、ユーザーのブラウザーは、ユーザーの秘密鍵を使用して応答を復号化します。

そうではありません。これは雑草です。Web アプリケーションの開発者は、これらすべてから比較的抽象化されています。しかし、セッション コンテンツは非対称キーで暗号化されていないため、CPU の負荷が非常に高くなります。サーバーの PKI とオンザフライ ブラウザーで生成されたハンドシェイク データは、セッション暗号化キーの交換に使用されます。これの一部は、クライアントがサーバーの公開鍵で暗号化された秘密鍵を選択して送信することです。サーバーのみが秘密鍵を持っているため、サーバーのみがクライアントから送信されたデータを復号化できます。

この秘密鍵は対称的であり (正確にはどのアルゴリズムもハンドシェイクの一部でもあります)、残りのセッションで使用されます。

于 2011-02-04T19:22:22.333 に答える
1

あなたのステップは、いくつかの異なるレベルで正しくありません。うまくいけば明確な方法で、それらを言い換えさせてください。

  1. サイトには、信頼できるサードパーティCA（Verisignなど）からのSSL証明書が必要です。あなたは彼らからそれを購入する必要があります。公開鍵と秘密鍵のペアを生成し、公開鍵（証明書要求の一部）を提供すると、証明書が生成されます。

  2. 証明書には、サイトのドメイン名、公開鍵、およびその他の追加情報が含まれています。特に、あなたのサイトが「泥棒の局」ではないことを確認するものではありません。通常、それが証明するのは、証明書を要求しているドメイン名を所有していることだけです。それはあなたのサイトが決して信頼できるという意味ではありません。

  3. ユーザーがHTTPS経由でサイトにアクセスすると、サーバーは証明書をクライアントのブラウザーに送信します。クライアントがCAと通信して証明書を検証することはありません。

3.1。通常、エンドユーザー（クライアント、顧客）は独自の証明書や秘密鍵を必要としません。これは相互認証SSLと呼ばれ、証明書を持っている両方の当事者（顧客とサイト）が関与します。これがeコマースサイトで使用されることはめったにありません（あるとしても）。

  1. ユーザーがHTTPS経由でサイトにアクセスすると、サーバーは証明書をクライアントブラウザーに送信します。クライアントはこれを使用してSSLハンドシェイクを実行します。ブラウザとサイト間のこのハンドシェイクは、安全なトンネルを確立するものです。ハンドシェイクプロトコルの詳細は、必要以上に技術的です。

  2. リクエストがSSLトンネルを介してサーバーに送信されると、サーバーは他のリクエストと同じようにリクエストを処理します。唯一の違いは、顧客とサーバー間の通信が暗号化されていることです。Webサーバーは、リクエストからのデータの復号化を処理し、処理のためにWebサーバーに提示する可能性があります。同様に、応答データはSSLトンネルを介して暗号化された形式でクライアントに返されます。

より良い？

于 2011-02-03T20:16:44.493 に答える
0

ポイント3について：

私の知る限り、これは完全に正しいわけではありません。(DNS などのサービスと比較して) 確立されたライブ テスト インフラストラクチャのようなものは実際には存在しないため、Web サーバーは証明書の完全なチェーンをブラウザーに送信します。一方、ブラウザーまたはオペレーティング システムには、一連の信頼されたルート証明書が付属しています (Windows の更新、新しいブラウザーのリリースなど、時々更新する必要があります)。

はい、ブラウザは「信頼されていない」鍵ペアを生成することになっています。通常の状況では、標準ユーザーは自分の証明書を生成しないからです。

ポイント5について：

また、これは完全に真実ではありません。非同期暗号化の計算には多くの時間がかかります。したがって、RSA アルゴリズムは、より高速な同期暗号化標準 (つまり、AES、3TES) のキーを交換するためにのみ使用されます。

于 2011-02-01T17:17:47.650 に答える