Keyless SSLの仕組み | Forward Secrecy

Keyless SSLにより、プライベートキーを共有できない企業はSSL/TLS暗号化を維持しながらクラウドに移行できます。

学習目的

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

  • 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を提供するクラウドベンダーは、プロセスのうちプライベートキーの部分を別のサーバー(通常は顧客所有のオンプレミスサーバー)に移動します。

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

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を復号化します。プライベートキーが使われるのはこの1回きりであることに注目してください!
  5. これで、クライアントとサーバーの両方がclient random、server random、およびpremaster secretを持っています。互いに独立して、これら3つのインプットを使用してセッションキーを生成します。双方で同じ結果が導き出されるはずで、それらの新しいキーを使用してセッション中のすべての後続通信を暗号化します。
Keyless SSLを使用しない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. サーバーは、選ばれた暗号スイート、サーバーランダム値、SSL証明書で応答します。DHEハンドシェイクとRSAハンドシェイクが異なるのはここからです。サーバーはディフィー・ヘルマン(DH)パラメータも送ります。このパラメータはpremaster secretの計算に使われます。クライアントランダム値、サーバーランダム値、DHパラメータも、サーバーのプライベートキーで暗号化します。プライベートキーが使われるのはこの1回きりで、サーバーが自称するサーバーであることを認証します。
  3. クライアントが、パブリックキーでサーバーのメッセージを復号化してSSL証明書を認証します。続いてクライアントが、DHパラメーターで応答します。
  4. クライアントのDHパラメーターとサーバーのDHパラメーターを使用して、双方が別々にpremaster secretを計算します。
  5. 次に、このpremaster secretをclient randomやserver randomと組み合わせて、セッションキーを取得します。
Keyless SSLを使わない場合のSSLハンドシェイク(DH)

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

Cloudflare Keyless SSL (DH)

一時的ディフィー・ヘルマンハンドシェイクは、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ハンドシェイクとDHハンドシェイクの両方をサポートしていますので、企業はDHを通じて前方秘匿性を組み込み、攻撃者がプライベートキーを盗んでデータの復号化をしないよう保護できます。

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

Keyless SSLの仕組みの技術的詳細については、こちらのブログ記事をご参照ください。Cloudflareが提供するKeyless SSLサービスの詳細をご確認ください。