秘密キー暗号化では、通信するAliceとBobはメッセージの暗号化と復号化に同じキーを使用します。暗号化されたデータをネットワークで送信する前に、AliceとBobはキーを持っていることが必要で、暗号化と復号化に使用する暗号化アルゴリズムに同意している必要があります

秘密キー暗号化で大きな問題の1つが、攻撃者にアクセスされずに一方から他方にキーを渡す方法の問題です。AliceとBobが秘密キー暗号化でデータを保護しても、CharlieがそのキーにアクセスできればAliceとBobの間で傍受した秘密メッセージを理解できます。CharlieはAliceとBobのメッセージを復号化できるだけではなく、Aliceになりすまして暗号化データをBobに送信することもできるのです。Bobには、メッセージがCharlieから届いたものかAliceから届いたものかはわかりません。

秘密キーの配布の問題が解決すれば、秘密キー暗号化はたいへん貴重なツールになります。そのアルゴリズムにより、優れたセキュリティと暗号化データが比較的迅速に提供できるからです。TLSセッションで送信される機密性の高いデータの多くは、秘密キー暗号化で送信されます。

秘密キー暗号化は、データの暗号化と復号化の両方に同じキーを使用するため、対称暗号化とも呼ばれます。よく知られている秘密キー暗号化アルゴリズムには、Advanced Encryption Standard (AES)、Triple Data Encryption Standard (3DES)およびRivest Cipher 4 (RC4)があります。

公開キー暗号化は、公開キーと秘密キーの両方を使用することでキーの配布方法の問題を解決しました。公開キーはネットワークを通じて公開し、送信できますが、秘密キーは通信の1人の当事者にしか公開されません。公開キーと秘密キーは暗号化方式が逆で、一方のキーで暗号化したものをもう一方のキーで復号化します。

Bobが公開キー暗号化を使用して、Aliceに秘密のメッセージを送信するとします。Aliceは公開キーと秘密キーをどちらも持っているので、秘密キーは安全な場所に保管しておき、公開キーをBobに送信します。BobはAliceの公開キーを使ってAliceへの秘密のメッセージを暗号化します。Aliceは秘密キーを使ってメッセージを復号化します。

Aliceが自分の秘密キーを使用してメッセージを暗号化し、その暗号化されたメッセージをBobに送信すれば、Bobが受信するデータはAliceから届いたものだと考えることができます。BobがAliceの公開キーでデータを復号化できれば、そのメッセージはAliceが自分の秘密キーで暗号化したものに間違いなく、Aliceの秘密キーを持っているのはAliceのみです。問題は、Aliceの公開キーが公開されているために、だれもがメッセージを読めてしまうことです。このシナリオは、セキュアなデータ通信を考慮に入れていませんが、デジタル署名の基本を示しています。デジタル署名とは公開キー証明書のコンポーネントの1つで、TLSでクライアントやサーバーを認証するために使用します。公開キー証明書とデジタル署名を参照してください。

公開キー暗号化は、データの暗号化と復号化に別のキーを使用するので、非対称暗号化とも呼ばれます。TLSでよく使われる、よく知られている公開キー暗号化アルゴリズムは、Rivest Shamir Adleman (RSA)アルゴリズムです。このほかにも、秘密キーを交換するために設計されたTLSを使う公開キー暗号化アルゴリズムには、Diffie-Hellman (DH)があります。公開キー暗号化には膨大な計算が必要なため、速度が大幅に遅くなります。そこで、この方式は暗号化データ通信全体に使用するよりもむしろ、秘密キーなど少量のデータを暗号化する場合にだけ使用します。

暗号化されたデータを送信する場合、TLSは通常、暗号化ハッシュ関数を使ってデータの整合性を保証します。ハッシュ関数を使って、AliceがBobに送ったデータをCharlieが改ざんできないようにします。

暗号化ハッシュ関数はチェックサムに似ています。主な違いは、チェックサムがデータの偶発的変化を検出するのに対し、暗号化ハッシュ関数は故意による変更を検出するように設計されています。データが暗号化ハッシュ関数で処理されると、ハッシュと呼ばれる小さなビット文字列が生成されます。メッセージがごくわずかだけ変更された場合も、結果として生成されるハッシュは大きく変更されます。暗号化ハッシュ関数には、暗号化キーが必要ありません。TLSとともによく使用されるハッシュ関数は、Secure Hash Algorithm (SHA)です。SHAは、U.S. National Institute of Standards and Technology (NIST)によって提案されました。

メッセージ認証コード(MAC)は暗号化ハッシュに似ていますが、秘密キーをベースにしている点が異なります。秘密キー情報が暗号化ハッシュ関数で処理したデータに含まれている場合、その結果生成されるハッシュはHMACと呼ばれます。

Aliceは、BobへのメッセージをCharlieが確実に改ざんしないようにする場合、メッセージのHMACを計算して元のメッセージにHMACを追加できます。次に、Bobと共有している秘密キーを使用してメッセージとHMACを暗号化できます。Bobは、メッセージを復号化してHMACを計算すれば、送信中にメッセージが変更されたかどうかを知ることができます。TLSでは、HMACを使ってセキュアなデータを送信します。

メッセージに暗号化ハッシュが作成されると、ハッシュは送信者の秘密キーで暗号化されます。このような暗号化ハッシュをデジタル署名と呼びます。

次の図に、TLSハンドシェーク全体の一連のメッセージを示します。

図8-7 TLS 1.3ハンドシェーク

1. キー交換:

   1. クライアントは、サーバーにClientHelloメッセージを送信します。

   2. サーバーはClientHelloメッセージを処理し、接続に適した暗号化パラメータを決定します。その後、ネゴシエーションされた接続パラメータを示す独自のServerHelloメッセージで応答します。TLS 1.3の場合、ServerHelloメッセージによってキーおよび暗号オプションのみが決定されます。その他のハンドシェーク・パラメータは、後で決定できます。

2. サーバー・パラメータ: サーバーは、次の2つのメッセージを送信してサーバー・パラメータを確立します:

   • EncryptedExtensions: このメッセージには、個々の証明書に固有のものを除いて、暗号化パラメータの決定に必要とされないClientHello拡張への応答が含まれています。

   • CertificateRequest (オプション): 証明書ベースのクライアント認証が必要な場合、サーバーはその証明書に必要なパラメータを含むメッセージを送信します。クライアント認証が不要な場合、このメッセージは省略されます。

3. 認証:

   1. サーバーは次の認証メッセージを送信します:

      • Certificate (オプション): このメッセージには、認証証明書と、証明書チェーン内のサポートするその他の証明書が含まれます。サーバーが証明書で認証されていない場合、このメッセージは省略されます。

        ノート:

        Certificateメッセージには、証明書のかわりに未加工のキーを含めることができます。

      • CertificateVerify (オプション): このメッセージには、Certificateメッセージ内の公開キーに対応する秘密キーを使用したハンドシェーク全体に対する署名が含まれています。サーバーが証明書で認証されていない場合、このメッセージは省略されます。

      • Finished: ハンドシェーク全体のMAC (メッセージ認証コード)。

   2. クライアントは、独自のCertificate、CertificateVerifyおよびFinishedメッセージで応答します。サーバーがCertificateRequestメッセージを送信しなかった場合、Certificateメッセージは省略されます。クライアントが証明書で認証されていない場合、CertificateVerifyメッセージは省略されます。

クライアントとサーバーは、アプリケーション・データを相互に安全に送信できるようになりました。

事前共有キー(PSK)は、使用する前になんらかのセキュアなチャネルを使用している2者間で共有されていた共有シークレットです。あるTLSハンドシェーク中にPSKを確立し、それを使用して別のハンドシェークで新しい接続を確立できます。これはPSKによるセッション再開と呼ばれます。PSKは、初期ハンドシェークから導出された一意のキーに対応します。新しい接続の確立時にサーバーがPSKを受け入れる場合、この接続のセキュリティ・コンテキストは暗号により元の接続に関連付けられ、完全なTLSハンドシェークではなく、最初のハンドシェークから導出されたキーを使用して暗号化状態がブートストラップされます。

次の図は、2つのハンドシェークを示しています。1つ目はPSKを確立し、もう1つはPSKを使用します。

図8-8 PSKを確立するTLS 1.3ハンドシェーク

図8-9 PSKを使用するTLS 1.3ハンドシェーク

1. クライアントは、key_share拡張を含むClientHelloメッセージをサーバーに送信します。この拡張機能は、クライアントがサポートするキー交換暗号化方式を一覧表示します。

2. サーバーは、key_share拡張を含むServerHelloメッセージで応答します。この拡張機能には、キー交換に使用する暗号化方式が含まれています。

3. サーバーはそのサーバー・パラメータをクライアントに送信します。

4. サーバーとクライアントの両方が認証メッセージを交換します。

5. サーバーはNewSessionTicketメッセージをクライアントに送信します。このメッセージにはPSKが含まれており、クライアントはこのPSKをClientHelloメッセージのpre_shared_key拡張に含めることで、将来のハンドシェークに使用できます。

6. クライアントとサーバーは、暗号化されたアプリケーション・データを交換できるようになりました。

7. 将来のハンドシェークでは、クライアントは、key_shareおよびpre_shared_key拡張を含むClientHelloメッセージをサーバーに送信します。pre_shared_key拡張には、NewSessionTicketメッセージで送信されるPSKが含まれています。

8. サーバーは、pre_shared_keyおよびkey_share拡張を含むServerHelloメッセージで応答します。pre_shared_key拡張には、サーバーが使用に同意したPSKが含まれます。

9. サーバーはそのパラメータをクライアントに送信します。

10. サーバーとクライアントは、互いにFinishedメッセージを送信します。この接続のセキュリティ・コンテキストは暗号により元の接続に結び付けられるため、認証フェーズは実行されません。

11. クライアントとサーバーは、暗号化されたアプリケーション・データを交換できるようになりました。

クライアントとサーバーは、ハンドシェーク後に他のメッセージ(新規セッション・チケット・メッセージ、ポストハンドシェーク認証およびキー更新)を送信できます。

この項では、JSSEの機能拡張によって生じる可能性がある互換性の問題やその他の既知の問題について説明します。

TLS 1.2ハンドシェークでは、SSLハンドシェークについて概要を説明しました。これは、暗号化されたメッセージを送信する前にクライアントとサーバーの間で行われる情報の交換です。図8-10に詳細を示します。これは、SSLハンドシェークで交換される一連のメッセージを示しています。特定の状況下でだけ送信されるメッセージには「optional」と記されています。各SSLメッセージについては、後で詳しく説明します。

図8-10 SSL/TLSハンドシェーク

SSLメッセージは、次の順序で送信されます。

1. Client hello: クライアントは、それがサポートする最上位バージョンのSSLと暗号化方式群のリスト(TLS 1.0はSSL 3.1と示される)を含むサーバー情報を送信します。暗号化方式群の情報には、暗号化アルゴリズムとキーのサイズが含まれます。
2. Server hello: サーバーは、クライアントとサーバーの両方がサポートする最上位バージョンのSSLと最適な暗号化方式群を選択し、この情報をクライアントに送信します。
3. (オプション) Certificate: サーバーはクライアントに証明書または証明書チェーンを送信します。証明書チェーンは通常、サーバーの公開キー証明書で始まり、認証局のルート証明書で終わります。このメッセージはオプションで、サーバー認証を求められた場合に使用します。
4. (オプション) Certificate request: サーバーがクライアントを認証する必要がある場合、クライアントに証明書要求を送信します。インターネット・アプリケーションでは、このメッセージが使われることはほとんどありません。
5. (オプション) Server key exchange: Certificateからの公開キー情報がキー交換を行うのに不十分な場合、サーバーはクライアントにサーバー・キー交換メッセージを送信します。たとえば、Diffie-Hellman (DH)に基づく暗号化方式群では、このメッセージにはサーバーのDH公開キーが含まれています。
6. Server hello done: サーバーは、最初のネゴシエーション・メッセージを終了したことをクライアントに伝えます。
7. (オプション) Certificate: サーバーがクライアントに証明書を要求すると、クライアントはサーバーが前に行ったように、その証明書チェーンを送信します。

   ノート:

   クライアントに証明書を要求するのは、ごく一部のインターネット・サーバー・アプリケーションのみです。
8. Client key exchange: クライアントは、対称暗号化で使用するキーを作成するために使用される情報を生成します。RSAでは、クライアントはサーバーの公開キーでこのキー情報を暗号化してサーバーに送信します。DHに基づく暗号化方式群の場合、このメッセージにはクライアントのDH公開キーが含まれています。
9. (オプション) Certificate verify: このメッセージは、上述のとおりクライアントが証明書を提示する場合にクライアントによって送信されます。このメッセージは、サーバーにクライアントの認証処理を完了させるためのものです。このメッセージが使用されると、クライアントは暗号化ハッシュ関数で電子的に署名した情報を送信します。サーバーがクライアントの公開キーでこの情報を復号化すれば、サーバーはクライアントを認証できます。
10. Change cipher spec: クライアントはメッセージを送信し、暗号化モードに変更するようサーバーに伝えます。
11. Finished クライアントはサーバーに、セキュアなデータ通信を開始する準備ができたことを伝えます。
12. Change cipher spec: サーバーはメッセージを送信し、暗号化モードを変更するようクライアントに伝えます。
13. Finished: サーバーはクライアントに、セキュアなデータ通信を開始する準備ができたことを伝えます。SSLハンドシェークが終了します。
14. Encrypted data: クライアントとサーバーは、client helloとserver hello時にネゴシエーションされた対称暗号化アルゴリズムと暗号化ハッシュ関数およびclient key exchange時にクライアントがサーバーに送信した秘密キーを使用して通信します。このときハンドシェークの再ネゴシエーションを行うことができます。ハンドシェークの再実行(再ネゴシエーション)を参照してください。
15. Close Messages: 接続の終わりに、それぞれの側がclose_notifyアラートを送信し、接続が終了したことをピアに伝えます。

SSLセッションで生成したパラメータを保存しておけば、将来のSSLセッションでこれらのパラメータを再利用できます。SSLセッションのパラメータを保存しておけば、暗号化通信をすばやく開始できます。

アプリケーション・データを送信または受信できるようにするには、DTLSプロトコルで、暗号化パラメータを確立するためのハンドシェークが必要です。このハンドシェークでは、SSLEngineオブジェクトによる、クライアントとサーバーとの間の一連のメッセージのやり取りが必要です。