Keyless SSLの仕組み

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

学習目的

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

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

関連コンテンツ


さらに詳しく知りたいとお考えですか?

是非、Cloudflareが毎月お届けする「theNET」を購読して、インターネットで最も人気のある洞察をまとめた情報を入手してください!

当社がお客様の個人データをどのように収集し処理するかについては、Cloudflareのプライバシーポリシーをご確認ください。

記事のリンクをコピーする

Keyless SSLとは?

Keyless SSL

Keyless SSLとは、SSL暗号化のためにクラウドベンダーを使用する企業向けのサービスです。通常、企業はクラウドベンダーにプライベートキーを知らせなければなりませんが、Keyless SSLはそれをしなくてもよい方法です。規制上の理由から、多くの企業はプライベートキーを共有できません。Keyless SSLを使用すれば、企業はキー(鍵)の安全を確保しながら、TLSを使用しクラウドを活用することができます。

SSL(正確にはTLS)は、ネットワーク上で通信を認証し暗号化するためのプロトコルです。SSL/TLSを利用するには、いわゆるパブリックキーとプライベートキーを使用する必要があります。企業が自社Webサイトで送受信するトラフィックをこのプロトコルを使って安全にする場合(HTTPSを参照)は、プライベートキーはその企業の手元に残るのが通常です。しかし、企業がクラウドに移行し、ベンダーがTLS暗号化を提供する場合は、ベンダーがプライベートキーを持ちます。

秘密鍵が関与するハンドシェイクをベンダーのサーバーから排除することで、企業が引き続き安全に秘密鍵を保持します。秘密鍵を直接使ってベンダーのサーバーを認証するのではなく、クラウドベンダーが企業のサーバーにデータを転送し、企業のサーバーからデータを受信することで実現しているのです。この通信は、安全な、暗号化されたチャンネルで行われます。したがって、秘密鍵を引き続き使用しますが、社外の人物とは共有しません。

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

Keyless SSLの仕組み

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

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

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

RSA鍵交換のTLSハンドシェイクで、Keyless SSLはどのように動作するのか?

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)

一時的Diffie-Hellman鍵交換を用いたKeyless SSLの仕組みは?

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

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

  1. RSAハンドシェイクの時と同様に、クライアントは、使用するプロトコルバージョン、サポートしている暗号スイートの一覧、およびclient randomを送信します。
  2. サーバーは、選ばれた暗号スイート、サーバーランダム値、SSL証明書で応答します。DHEハンドシェイクとRSAハンドシェイクが異なるのはここからです。サーバーはディフィー・ヘルマン(DH)パラメータも送ります。このパラメータはpremaster secretの計算に使われます。これには認証用のデジタル署名も含まれます。秘密鍵が使われるのはこの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(前方秘匿性)と呼ばれる長所があります。プライベートキーは認証にのみ使用されるため、攻撃者はプライベートキーを使ってセッションキーを見つけることができません。

セッションキーとは?

セッションキーとは、TLSハンドシェイクが完了した後で、TLS経由で安全な通信を行う送信者と受信者が使用する対称キーのことです。いったん送信者と受信者の両方がセッションキーについて同意したら、パブリックキーとプライベートキーを使用する必要はなくなります。TLSは、各セッションに対して異なるセッションキーを生成します。

前方秘匿性(forward secrecy)とは?完全前方秘匿性(perfect forward secrecy)とは?

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

前方秘匿性のプロトコル設定では、秘密鍵は初期のハンドシェイクプロセス時の認証に使用され、それ以外には使用されません。一時的Diffie-Hellmanハンドシェイクは、秘密鍵とは別にセッション鍵を生成するため、前方秘匿性があります。

それに対して、RSAには前方秘匿性がありません。秘密鍵が侵害されると、攻撃者は過去の会話のセッション鍵を判断できてしまいます。これは、プリマスターシークレットを復号化できるのと、クライアントランダムとサーバーランダムが平文だからです。これら3つを組み合わせることで、攻撃者は任意のセッション鍵を生成できます。

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

CloudflareはKeyless SSLを最初にリリースしたクラウドベンダーで、銀行などセキュリティ規制が厳しい企業がクラウドに移行できるようにしました。CloudflareはRSAハンドシェイクとDHハンドシェイクの両方をサポートしていますので、企業は前方秘匿性を組み込み、攻撃者がプライベートキーを盗んでデータの復号化をしないよう保護できます。

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

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