Keyless SSLの仕組み | Forward Secrecy

Keyless SSLにより、秘密鍵を共有できない企業はSSL/TLS暗号化を維持しながらクラウドに移行できます。SSL

Share facebook icon linkedin icon twitter icon email icon

Keyless SSL

学習目的

この記事を読み終えると、以下のことができます。

  • TLSハンドシェイクの手順およびセッション鍵と秘密鍵の違いについて説明する
  • Keyless SSLが秘密鍵を使用してTLSハンドシェイクの一部を残りのハンドシェイクから切り離す方法を理解する
  • ディフィー・ヘルマンハンドシェイクとRSAハンドシェイクの違いを理解する
  • forward secrecyとは何かを理解する

Keyless SSLとは?

Keyless SSL

Keyless SSLとは、SSL暗号化のためにクラウドベンダーを使用する企業向けのサービスです。通常、これはクラウドベンダーが企業の秘密鍵を知る必要があることを意味しますが、Keyless SSLではそれを回避することができます。規制上の理由から、多くの企業は各自の秘密鍵を共有できません。Keyless SSLを使用することで、企業はクラウドを利用して鍵の安全性を確保しながら引き続きTLSを使用することができます。

SSL/TLSは、ネットワーク上の通信の認証および暗号化を安全に行うためのプロトコルです。SSL/TLSは、公開鍵と秘密鍵と呼ばれるものを使用する必要があります。企業が自社のWebサイトとユーザー間のトラフィックを保護するためにプロトコルを使用する場合(HTTPSを参照)、通常、秘密鍵はその企業が所有します。ところが、企業がクラウドに移行してベンダーがTLS暗号化を提供する場合、ベンダーが秘密鍵を所有することになります。

秘密鍵が関与するハンドシェイクをベンダーのサーバーから排除することで、企業が引き続き安全に秘密鍵を保持します。セッション鍵(共通鍵)を生成するために秘密鍵を直接使用する代わりに、暗号化を維持するためにクラウドベンダーが安全なチャネルを介して企業からセッション鍵を取得して使用します。したがって、秘密鍵を引き続き使用しますが、社外の人物とは共有しません。

たとえば、Acme Co.がSSLを実装しているとします。Acme Co.は、自社が所有して管理するサーバー上で秘密鍵を安全に保管します。Acme Co.がクラウドに移行して、Webホスティングにクラウドサービスプロバイダーを使用する場合、ベンダーが秘密鍵を所有することになります。しかし、代わりにKeyless SSLを実装するベンダーを使用してAcme Co.がクラウドに移行した場合、クラウド環境でないSSLの実装と同様に、秘密鍵はAcme Co.が所有して管理するサーバー上に残ります。

Keyless SSLの仕組み

Keyless SSLは、TLS通信セッションの最初に行われるTLSハンドシェイク時に秘密鍵が使用されるのは1回であるという事実に基づいています。Keyless SSLは、TLSハンドシェイクの手順を分割することで機能します。Keyless SSLを提供するクラウドベンダーは、プロセスの秘密鍵の部分を別のサーバー(通常は顧客の敷地内にあるサーバー)に移動します。

データを復号化または暗号化するのにハンドシェイク時に秘密鍵が必要になったら、ベンダーのサーバーは、必要なデータを顧客の秘密鍵サーバーに転送します。秘密鍵は、顧客のサーバー上のデータを暗号化または復号化し、ベンダーのサーバーにデータを返信して、通常どおりにハンドシェイクを続行します。

Keyless SSLは、クラウドベンダーの観点から見た場合に「キーレス」となります。顧客の秘密鍵を決して見ることはありません。顧客が秘密鍵を引き続き所有して使用します。一方で、公開鍵は引き続き通常どおりにクライアント側で使用されます。

セッションキーとは?

セッション鍵とは、TLSハンドシェイクが完了した後で、TLS経由で安全な通信を行う送信者と受信者によって使用される対称鍵のことです。いったん送信者と受信者の両方がセッション鍵について同意したら、公開鍵と秘密鍵を使用する必要はなくなります。TLSは、各セッションに対して異なるセッション鍵を生成します。

セッション鍵を生成する手順

この手順は、TLSハンドシェイク時にどの種類の鍵交換アルゴリズムを使用するかによって異なります。代表的な2つの種類は、RSA鍵交換アルゴリズムと一時的ディフィー・ヘルマン鍵交換アルゴリズムです。

RSA鍵交換

RSAハンドシェイクでの、セッション鍵を生成するためのTLSハンドシェイク時の手順は以下のとおりです:

  1. クライアントが、使用するプロトコルバージョンの平文の「hello」メッセージ、サポートしている暗号スイートの一覧、および「client random」と呼ばれるランダムなデータの短い文字列をサーバーに送信します。
  2. サーバーが、SSL証明書、希望する暗号スイート、「server random」と呼ばれるランダムなデータの別の短い文字列で(平文で)応答します。
  3. クライアントが、「premaster secret」と呼ばれる別のランダムなデータセットを作成します。サーバーのSSL証明書から公開鍵を取得し、クライアントはpremaster secretを暗号化して、サーバーに送信します。秘密鍵を持つ人物のみがpremaster secretを復号化できます。
  4. サーバーが、premaster secretを復号化します。秘密鍵が使用されるのは、このときだけです。
  5. これで、クライアントとサーバーの両方がclient random、server random、およびpremaster secretを持っています。互いに独立して、これら3つのインプットを使用してセッション鍵を生成します。双方が同じ結果を導出し、それらの新しい鍵を使用してセッション中のすべての後続の通信を暗号化します。
SSL Handshake (RSA) Without Keyless SSL

Keyless SSLは、手順4で関係してきます。Keyless SSLを使用することで、premaster secret自体を復号化せずに、クラウドベンダーは、それを暗号化した形で顧客がホストする、または管理するサーバーに安全なチャネルを介して送信します。顧客の秘密鍵がpremaster secretを復号化し、復号化されたpremaster secretをクラウドベンダーに返信します。クラウドベンダーのサーバーは、これを使用してセッション鍵を生成して、正常どおりにTLS通信を続行します。

Cloudflare Keyless SSL Handshake (RSA)

一時的ディフィー・ヘルマン鍵交換

一時的ディフィー・ヘルマン鍵交換(DHE)ハンドシェイク(「一時的」というのは、同じ鍵が決して2回使用されないため)は、安全でないチャネルを介して鍵を交換する方法である、ディフィー・ヘルマン鍵交換アルゴリズムを使用してセッション鍵を生成します。このようなTLSハンドシェイクでは、秘密鍵の認証はセッション鍵の生成とは別のプロセスとなります。

DHEハンドシェイクとRSAハンドシェイクの主な違いは、使用するアルゴリズムが異なることに加えて、 premaster secretを生成する方法です。RSAハンドシェイクでは、premaster secretはクライアントが生成したランダムなデータで構成されます。DHEハンドシェイクでは、クライアントとサーバーが、同じpremaster secretを別々に計算するために同意したパラメーターを使用します。

  1. RSAハンドシェイクのとき同様に、クライアントは、使用するプロトコルバージョン、サポートしている暗号スイートの一覧、およびclient randomを送信します。
  2. サーバーが、選択した暗号スイート、server random、およびSSL証明書で応答します。ここから、DHEハンドシェイクとRSAハンドシェイクの違いが現れ始めます。サーバーは、premaster secretを計算するのに使用されるディフィー・ヘルマン(DH)パラメーターも送信します。また、サーバーの秘密鍵を使用して、client random、server random、およびDHパラメーターも暗号化します。秘密鍵が使用されて、サーバーが認証されるのはこのときだけです。
  3. クライアントが、公開鍵でサーバーのメッセージを復号化してSSL証明書を認証します。続いてクライアントが、DHパラメーターで応答します。
  4. クライアントのDHパラメーターとサーバーのDHパラメーターを使用して、双方が別々にpremaster secretを計算します。
  5. 次に、このpremaster secretをclient randomやserver randomと組み合わせて、セッション鍵を取得します。
SSL Handshake (Diffie-Hellman) Without Keyless SSL

秘密鍵は手順2でのみ使用されます。ここでKeyless SSLが関係してきます。この時点では、SSL/TLSベンダーは、client random、server random、およびサーバーのDHパラメーターを、秘密鍵を持つ顧客の管理下にあるサーバーに送信します。この情報は、秘密鍵を使用して暗号化され、暗号化された形でクラウドベンダーに返信されます。それをクラウドベンダーが、クライアントに引き渡します。クライアントは、このデータを公開鍵を使用して復号化し、ハンドシェイクを続行します。このようにして、クラウドベンダーは秘密鍵を扱う必要がありません。

Cloudflare Keyless SSL (Diffie Hellman)

一時的ディフィー・ヘルマンハンドシェイクは、RSAハンドシェイクよりも若干長い時間を要しますが、forward secrecy(前方秘匿性)と呼ばれる長所があります。秘密鍵は認証にのみ使用されるため、攻撃者は任意のセッション鍵を見つけるのに秘密鍵を使用できません。

forward secrecyとは?perfect forward secrecyとは?

forward secrecyは、秘密鍵が暴露されたとしても、暗号化されたデータが暗号化されたままになるようにします。これを「perfect forward secrecy」とも呼びます。各通信セッションに一意のセッション鍵が使用され、セッション鍵が秘密鍵とは別々に生成された場合にforward secrecyが可能です。1つのセッション鍵が侵害された場合、攻撃者はそのセッションのみを復号化することができ、ほかのすべてのセッションは暗号化されたままになります。

forward secrecyのプロトコル設定では、秘密鍵は初期のハンドシェイクプロセス時の認証に使用され、暗号化には使用されません。一時的ディフィー・ヘルマンハンドシェイクは、秘密鍵とは別にセッション鍵を生成するため、forward secrecyがあります。

それに対して、RSAにはforward secrecyがありません。秘密鍵が侵害されると、攻撃者は過去の会話のセッション鍵を復号化できてしまいます。これは、premaster secretを復号化できるのと、client randomsとserver randomsは平文だからです。これら3つを組み合わせることで、攻撃者は任意のセッション鍵を生成できます。

CloudflareはどのようにKeyless SSLを実装するのか?

Cloudflareは、Keyless SSLをリリースした最初のクラウドベンダーでした。それにより、銀行などの厳格なセキュリティを求められていた企業はクラウド化を図ることができるようになりました。Cloudflareは、RSAハンドシェイクとディフィー・ヘルマンハンドシェイクの両方をサポートしているので、企業はディフィー・ヘルマンを介してforward secrecyを組み込み、秘密鍵を手に入れた攻撃者がデータを復号化するのを防止することができます。

Cloudflareサーバーと秘密鍵サーバーの間のすべての通信は、暗号化された安全なチャネルを介して行われます。また、Cloudflareは、Keyless SSLは、秘密鍵サーバーとの余分なやりとりがあるにもかかわらず、パフォーマンスにほとんど影響を与えないことを確認しました。

Keyless SSLの仕組みの詳細については、このブログ投稿をご覧ください。CloudflareのKeyless SSLの詳細については、Keyless SSLサービスの詳細をご覧ください。