HTTPS の暗号化アルゴリズムに関連する概念

[[176353]]

暗号化はコンピュータサイエンスで広く使用されており、HTTPS は暗号化に基づいた安全な通信プロトコルです。 HTTPS は、1994 年に Netscape によって初めて提案されました。現在では、多くのインターネット メーカーの推進により、HTTPS はあらゆる規模のさまざまな Web サイトで広く使用されています。 HTTPS を完全に理解する前に、プレーンテキスト、暗号文、パスワード、キー、対称暗号化、非対称暗号化、サマリー、デジタル署名、デジタル証明書など、暗号化に関連するいくつかの概念を明確にする必要があります。

暗号

暗号化における暗号は、日常生活で使用するパスワードとは異なります。コンピューター用語の「暗号」は暗号化または復号化に使用されるアルゴリズムであり、日常生活で使用する「パスワード」は認証目的で使用される一連のテキスト文字列であるパスワードです。ここで議論するのは前者の暗号です。

鍵

キーは、暗号アルゴリズムを使用するときに入力されるパラメータです。同じ暗号化アルゴリズムと異なるキーを使用して計算すると、同じ平文から異なる暗号文が生成されます。よく知られている暗号化アルゴリズムの多くは公開されており、鍵は暗号文が安全かどうかを決定する重要なパラメータです。一般的に、鍵が長いほど、解読が難しくなります。たとえば、8 ビットの鍵では最大 256 通りの状況が考えられますが、網羅的方法を使用すると簡単に解読できます。よく知られている DES アルゴリズムは 56 ビットのキーを使用しており、もはや安全な暗号化アルゴリズムではありません。主な理由は、56 ビットのキーが短すぎて、数時間以内に解読されてしまうためです。キーは対称キーと非対称キーに分けられます。

平文/暗号文

平文は暗号化前の元のデータであり、暗号文は暗号化操作後に得られる結果です。

対称鍵

対称鍵アルゴリズムは、共有鍵暗号化とも呼ばれます。暗号化プロセスと復号化プロセスで使用される鍵は同じです。一般的な対称暗号化アルゴリズムには、DES、3DES、AES、RC5、RC6 などがあります。対称キーの利点は計算速度が速いことですが、欠点もあります。通信の両端でキーを共有して、各当事者がキーを認識し、正しく復号化できるようにする必要があります。すべてのクライアントが同じキーを共有する場合、このキーはマスターキーのようなもので、1 つのキーを使用して全員の暗号文を解読できます。各クライアントとサーバーが個別にキーを維持する場合、サーバーは何千ものキーを管理する必要があり、サーバーにとって悪夢をもたらします。以下は、プレーンテキストを ASCII に暗号化する単純な対称暗号化です。

 # 暗号化方式: ASCII + キー値に基づく
def encipher(プレーンテキスト、キー):
    # 暗号化
    暗号文 = []
プレーンテキスト内のcの場合:
        cipher_text.append(str(ord(c) +キー))
戻る  ' ' . join (cipher_text)
 def decipher(cipher_text, key ):
    # 復号化
    プレーンテキスト = []
 cipher_text.split( " " )内のcの場合:
        plain_text.append(chr( int (c)+キー))
戻る  "" .結合(プレーンテキスト)
 __name__ == '__main__'の場合:
    「cipher_text:」を印刷し、暗号化します( 「abcdef」 、0)
    「plain_text:」を印刷し、解読します( 「97 98 99 100 101 102」 、0)

非対称鍵

非対称キー (公開キー暗号化)。公開キー暗号化とも呼ばれます。サーバーはキーのペアを生成します。1 つの秘密キーはサーバー上に保存され、サーバーのみが知ることができます。もう 1 つは公開キーで、誰でも自由に使用できるように公開されます。公開鍵で暗号化されたクライアントのプレーンテキストは、秘密鍵で復号化する必要があります。非対称キーは、暗号化プロセスと復号化プロセスで異なるキーを使用します。暗号化と復号化は非対称であるため、非対称暗号化と呼ばれます。対称鍵暗号化と比較すると、非対称暗号化ではクライアントとサーバー間で鍵を共有する必要がありません。秘密鍵がどのユーザーにも送信されない限り、公開鍵がオンラインで傍受されたとしても、解読することはできません。盗まれた公開鍵だけでは役に立ちません。一般的な非対称暗号化には RSA が含まれます。非対称暗号化と復号化のプロセスは次のとおりです。

1. サーバーは公開鍵と秘密鍵のペアを生成する
2. 秘密鍵はサーバー上に保存され、公開鍵はクライアントに送信されます。
3. クライアントは公開鍵を使用してプレーンテキストを暗号化し、サーバーに送信します。
4. サーバーは秘密鍵を使用して暗号文を復号し、平文を取得します。

デジタル署名

ブラウザとサーバーの間でデータが送信される際、送信の過程でなりすまし犯によって内容がすり替えられる可能性があります。では、データが本物のサーバーから送信され、すり替えられていないことをどのように保証できるでしょうか。同時に、送信されたデータが改ざんされていないことをどのように保証できるでしょうか。この 2 つの問題を解決するには、デジタル署名を使用する必要があります。デジタル署名は日常生活における署名のようなものです。契約書に自分の名前が記名されると、それが自分の署名であることが法的に確認されます。これは自分の筆跡であり、誰も偽造できないため、誰もこれを偽造することはできません。では、コンピューターのデジタル署名はどうでしょうか? デジタル署名は、送信されたコンテンツが実際のサーバーから送信されたデータであるかどうか、および送信されたデータが改ざんされていないかどうかを確認するために使用されます。これら 2 つのことだけを行うのが、非対称暗号化の応用シナリオです。ただし、暗号化には秘密鍵を使用し、復号化には公開鍵を使用します。

ステップ 1: サーバーはメッセージをハッシュした後、ダイジェストを生成します。ダイジェストは秘密鍵で暗号化され、署名が生成されます。サーバーはメッセージとともに署名をクライアントに送信します。

ステップ2: クライアントはデータを受信後、署名を抽出し、公開鍵を使用して復号化します。Digest2が正常に復号化できれば、相手から送信されたものであることが確認できます。

ステップ 3: クライアントはメッセージ テキストを抽出し、同じハッシュ処理を実行して要約情報 Digest1 を取得し、それを以前に復号化した Digest2 と比較します。 2 つが等しい場合、コンテンツは改ざんされていないことを意味し、そうでない場合は、コンテンツが誰かによって変更されたことを意味します。テキストの内容が少しでも変わると、まったく異なる要約が作成されてしまうからです。

デジタル証明書（認証局）

デジタル証明書は CA と略されます。権威ある組織が Web サイトに対して発行する認証証明書です。この証明書はすべての人 (ブラウザ) に認識されます。なぜデジタル証明書が必要なのでしょうか? デジタル署名は十分に安全ではないのでしょうか? ブラウザがすべての実在するサーバーが本当に実在するかどうかを判断できない状況があります。 以下に簡単な例を示します。

メーカーAはあなたの家に錠前を設置し、同時に鍵を渡します。鍵で錠前を開けられる限り、鍵と錠前が一致していると確信できます。誰かが鍵や錠前を変えた場合、ドアを開けることができず、盗まれたことがわかります。しかし、誰かが錠前と鍵を、表面上は似ているが品質がはるかに低い別のセットに交換した場合、鍵と錠前が一致していても、これが本当にメーカーAから提供されたものかどうかはわかりません。このとき、品質検査部門にこの錠前セットが本当にメーカーAからのものであるかどうか確認するよう依頼できます。品質検査部門は権威のある組織であり、その言うことは一般に認められています（笑）。

同様に、誰か (Zhang San) が実際のサーバーからブラウザーに送信された公開鍵を自分の公開鍵に置き換えた場合、Zhang San は自分の秘密鍵を使用して同じ手順を実行し、テキストをハッシュしてデジタル署名します。最終結果に問題はありません。しかし、実際には、ブラウザーが見ているのは実際のサーバーから提供されたものではなく、Zhang San によって内側から外側に (公開鍵から秘密鍵に) 置き換えられたものです。

では、現在使用している公開鍵が実際のサーバーから送信されたものであることを確認するにはどうすればよいでしょうか? この問題を解決するために、デジタル証明書を使用します。デジタル証明書は通常、デジタル証明機関によって発行されます。証明書には、実際のサーバーの公開鍵と Web サイトのその他の情報が含まれています。デジタル証明機関は、独自の秘密鍵で証明書を暗号化し、ブラウザに送信します。ブラウザは、デジタル証明機関の公開鍵を使用して証明書を復号化し、実際のサーバーの公開鍵を取得します。このプロセスは、誰もが認める認証局から取得した公開鍵に基づいているため、安全な方法です。