トランスポート層セキュリティー(TLS)とは

執筆者

Alexandra Jonker

Staff Editor

IBM Think

Tom Krantz

Staff Writer

IBM Think

トランスポート層セキュリティー(TLS)とは

トランスポート層セキュリティー(TLS)は、インターネットなどの保護されていないコンピューター・ネットワーク上での通信を保護するための暗号化プロトコルです。

TLSは、さまざまな 非対称 および 対称 暗号技術によって、エンド・ツー・エンドの認証 、機密性、および データの整合性 を実現します。これらの保護は、Eメール、メッセージング、VoIP(Voice over IP)、仮想プライベート・ネットワーク(VPN)など、幅広いネットワーク通信に適用されます。

TLSは、Web閲覧のための安全な接続を確立する手段として広く認識されています。これは、Webアプリケーションとほとんどの主要なWebブラウザー間での暗号化されたデータ交換を可能にするアプリケーション層プロトコルである、HTTPS(Hypertext Transfer Protocol Secure)の基盤です。

TLS暗号化プロトコルは、TLSハンドシェイク・プロトコルとTLSレコード・プロトコルの2つの層で構成されます。ハンドシェイク・プロトコルは、Webサーバーとクライアント(サーバーに接続するデバイス)を認証します。レコード・プロトコルは、転送するデータを検証して保護します。

これらのレイヤーは、TCP/IP(Transmission Control Protocol/Internet Protocol)モデルなどのトランスポート・プロトコルの上に位置します。TCP/IPモデルとは、コンピューター間の通信標準を指定するプロトコルのスイートであり、「インターネットをつなぐ接着剤」と考えることができます1

The DX Leaders

AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。

ご登録いただきありがとうございます。

ニュースレターは日本語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。

SSLとTLSの比較

TLSプロトコルは、Netscape Communications Corporationによって開発された、Secure Sockets Layer(SSL)プロトコル標準の後継プロトコルです。1996年、Internet Engineering Task Force(IETF)はSSLプロトコルを正式に標準化しました。

1999年1月に、IETFは最新のSSLバージョン(SSL 3.0)の機能改善と脆弱性の対応を実施し、名称をトランスポート層セキュリティー(TLS)に変更しました。これはRFC(Request for Comments)2246で正式に定義されました。今日、「TLS」と「SSL」という用語は、たいてい同じ意味で使用されるか、定型的にTLS/SSLと表記されています。

AI Academy

ハイブリッドクラウドでAI対応を実現

IBMのエキスパートが主催するこのカリキュラムは、ビジネス・リーダーが成長を促進するAI投資に優先順位を付けるために必要な知識を習得できます。

TLSを使用する理由

TLSは、IETFによって「インターネット上で最も重要なセキュリティー・プロトコル」と呼ばれており、オンライン通信を不正アクセスから保護するために不可欠です。最新バージョンのTLS 1.3は、より強力で高速なセキュリティーを実現し、今日の安全なデジタル世界のバックボーンとしての役割を果たしています。

世界人口の約68%がオンラインで繋がっており2、そのうち数十億人が、買い物や銀行業務から医療やPersonal Communicationsまで、あらゆる目的で毎日インターネットを利用しています。これらすべてのユースケースで、機密データの保護が不可欠です。つまり、ハッカー、改ざん、盗聴や、その他のサイバーセキュリティー脅威(データ侵害マルウェア中間者攻撃など)から機密データを保護しなければならないということです。

TLSは特に、Webサイトの標準セキュリティー・プロトコルであるHTTPSの基盤となっています。HTTPSのパッドロック・アイコンは、今ではWebブラウザーでよく知られている主要な機能であり、Webサイトが信頼でき、安全であることをユーザーに伝えます。

アイコンは、Webサイトに有効なTLS証明書(SSL証明書とも呼ばれる)があることも示します。認証局(CA)が発行するこのデジタル認証情報は、WebサイトのIDを検証し、暗号化された接続を可能にします。TLSとHTTPSの使用の規模を示す例として、ある大手TLS証明書プロバイダーは、1時間あたり34万件以上の証明書を発行しています

TLSは、安全なチャネルの次の3つのコア・プロパティーを適用することで、安全なインターネット通信を保証します。

認証

送信者と受信者の身元、およびデータの発信元と宛先を検証します。

機密性(Confidentiality)

意図した受信者のみがデータにアクセスできるようにします。

完全性(Integrity)

変更が検出されないまま、ストレージ内でまたは送信中にデータを変更できないようにします。

TLSの仕組み

トランスポート層セキュリティーは、送信された情報を保護するために暗号化プロセスに依存しているため、効果的です。

暗号(Cryptography)という語は、「隠された」を意味するギリシャ語の「kryptos」に由来します。暗号の主な目的は、暗号化を使用して通信を保護し、読み取り困難にすることです。暗号化とは、複雑なアルゴリズムによって、読み取り可能なメッセージ(平文)を、エンコードされたメッセージ(暗号文)に変換するプロセスのことです。暗号文は、許可された受信者のみが、特定の鍵を使用して読み取り可能な形式に復号化できます。

TLS暗号化などの暗号のコンテキストでは、鍵とは、数字や文字のランダムな文字列のことです。それを暗号アルゴリズムと併用することで、情報が暗号化(ロック)または復号化(ロック解除)されます。ネットワーク経由で転送されるデータを暗号化/復号化するために使用されるアルゴリズムは、通常、秘密鍵暗号と公開鍵暗号の2つのカテゴリーに分類されます。

秘密鍵暗号

対称暗号化または対称鍵暗号とも呼ばれるこのシステムは、機密データを暗号化/復号化するための単一の共有鍵を作成します。対称暗号化はシンプルで効率的ですが、安全な鍵交換と綿密な鍵管理に依存しています。

TLSセッションで送信される機密データのほとんどは、秘密鍵暗号を使用して送信されます。TLSは暗号化ハッシュ関数を使用して、プライバシーとデータの整合性を確保します。ハッシュ関数は、入力データから固定サイズのハッシュ値を生成します。この値は、送信の前後で比較できるデジタル指紋として機能します。ハッシュが変更された場合、それは誰かによってデータが改ざんされたことを意味します。

メッセージ認証コード(MAC)は、暗号化ハッシュに似ていますが、送信者も認証するという点が異なります。これはハッシュ化されたメッセージに秘密鍵を適用します。その結果得られるハッシュは、ハッシュ・メッセージ認証コード(HMAC)と呼ばれます。

公開鍵暗号

公開鍵暗号は、非対称暗号化とも呼ばれ、数学的にリンクされた鍵のペア(公開鍵と秘密鍵)を使用して、データ暗号化/復号化します。これにより、事前に秘密鍵を共有しなくても、ユーザーとシステムが機密情報を交換できます。それは郵便受けになぞらえることができます。誰でもそこに郵便物を入れることはできますが、鍵を開けて取り出すことができるのは所有者だけです。

これらの機能は、公開鍵インフラストラクチャー(PKI)と統合することで、信頼の確立に役立ちます。例えば、公開鍵証明書(デジタル証明書またはSSL/TLS証明書とも呼ばれる)は、認証局を通じて公開鍵を検証済みのIDにバインドします。

これはまた、デジタル署名の基礎も提供します。デジタル署名は、TLSでクライアントまたはWebサーバーを認証するために使用されるデジタル証明書の構成要素です。メッセージの暗号化ハッシュが作成されると、そのハッシュは送信者の秘密鍵で暗号化されます。

この暗号化されたハッシュがデジタル署名です。署名は、公開鍵を使用して誰でも検証でき、送信者の身元とデータの整合性を検証できます。

TLSの2つの層とは

TLSプロトコルには、TLSハンドシェイク・プロトコルとTLSレコード・プロトコルの2つのサブプロトコルがあります。正確な手順は、TLSのバージョンによって異なる場合があります。

TLSハンドシェイク・プロトコル

TLSハンドシェイクは、クライアントとWebサーバー間の安全な接続を確立します。公開鍵暗号化を使用し、サーバーは(場合によってはクライアントも)デジタル証明書を使用して認証されます。次に、クライアントとサーバーは暗号スイート(一連の暗号化アルゴリズム)に同意し、鍵交換を実行して、共有セッション鍵(暗号化とハッシュ用の秘密鍵)を安全に確立します。

セッション鍵が確立されると、安全なセッションがセットアップされたと見なされます。この時点から、公開鍵暗号化は使用されなくなり、その後送信されたすべてのデータは、秘密鍵暗号方式を使用して暗号化および認証されます。

(詳細については、「TLSハンドシェイクの手順」を参照してください。)

TLSレコード・プロトコル

レコード・プロトコルは、TLS接続中に送信されるデータを保護する役割を果たします。そのために、データ保護方法の一種のレシピとして、ハンドシェイク中にネゴシエートされた暗号スイートと鍵を使用します。

暗号スイートは、鍵交換、暗号化、およびメッセージ認証に使用するアルゴリズムを定義します。対称(秘密)鍵は、送信データの暗号化と受信データの復号化に使用されます。この鍵はさらに、データの整合性を検証するメッセージ認証コードの作成にも使用されます。

これらのメカニズムを通じて、レコード・プロトコルは接続の認証、整合性、機密性を保証します。

TLSハンドシェイクの手順

TLSハンドシェイクの正確な手順は、TLSのバージョンによって異なります。所要時間は約200~300ミリ秒で、最短では100ミリ秒で完了します(もちろん正確な時間は、レイテンシー、ラウンドトリップ時間(RTT)、サーバーの性能、その他のネットワークの考慮事項の影響を受けます)。

この図では、最速かつ最新で、より安全性が高いTLS 1.3バージョンを使用しています。

1. ClientHello

クライアントは、ClientHelloメッセージを、サポートされているTLSバージョン(TLS 1.3)、暗号スイート、ランダム・バイト文字列(client_random)、および一時鍵共有を含め、楕円曲線Diffie-Hellman Ephemeral(ECDHE)鍵交換方式を使用して送信します。

2. ServerHelloと鍵交換

サーバーはServerHelloメッセージで応答します。それには選択した暗号スイート、別のランダムなバイト文字列(server_random)、および独自の一時鍵共有が含まれます。このステップでは、鍵交換パラメーターが確立されます。

現在では、双方の当事者がECDHEを使用して共有秘密を計算できるようになりました。この共有秘密は、ハンドシェイク鍵を導き出すために使用されます。

次に、サーバーはデジタル証明書、CertificateVerifyメッセージ(秘密鍵で署名されたもの)、およびFinishedメッセージ(ハンドシェイク鍵で暗号化されたもの)を送信します。

(オプション:サーバーはクライアント認証を要求する場合に、CertificateRequestを送信します。クライアントは、自身の証明書とCertificateVerifyメッセージを返します。)

3. 認証と終了

クライアントは、サーバーの証明書が信頼できる認証局によって発行されていること、有効であり取り消されていないこと、およびドメインが一致していることを検証します。また、証明書からのサーバーの公開鍵を使用してサーバーのCertificateVerifyメッセージを検証し、ハンドシェイク鍵を使用してFinishedメッセージを検証します。

クライアントはハンドシェイク鍵を使用して独自のFinishedメッセージを送信し、ハンドシェイクが完了したことを確認します。

この時点で、双方の当事者が相互に認証し、共有秘密鍵を確立しています。これで対称暗号化を使用してメッセージを交換できるようになりました。

TLSはどのような鍵交換方式を使用していますか?

鍵交換方式は、ユーザーが暗号化鍵を安全に交換するための手法です。TLSを実装するために使用される鍵交換方式はいくつかあり、以下のようなものがあります。

Diffie-Hellman(DH)

Diffie-Hellmanは、最も一般的な鍵交換方式の1つです。これは、お互いの事前知識がない2つの当事者が、安全でないチャネルを経由して安全に通信するための共有秘密鍵を生成できる非対称鍵交換プロトコルです。そのセキュリティーは離散対数の問題を解く難しさに依存しています。この複雑な数学の問題により、共有された秘密を解読することは計算上不可能です。

Diffie-Hellman鍵交換には、次のようないくつかのバリエーションがあります。

  • Diffie-Hellman一時鍵共有(DHE):DHEでは、「一時」とは、セッションごとに一時的または使い捨ての鍵が生成されることを意味します。これは前方秘匿性を提供し、長期鍵の侵害によって過去のセッションが危険にさらされないようにします。DHEはTLS 1.2で一般的に使用されていますが、TLS 1.2はDHとDHEの両方をサポートしています。

  • 楕円曲線Diffie-Hellman(ECDH):ECDHはDHと類似していますが、楕円曲線暗号を使用しています。これにより、より小さな鍵サイズでより高いセキュリティーを実現できます。鍵のサイズが小さいため、ECDHの計算はより高速で、少ないリソースの消費で済みます。ただし非一時暗号スイートは、前方秘匿性がないため、IETFはその使用を推奨していません。

  • 楕円曲線Diffie-Hellman一時鍵共有(ECDHE):ECDHの一時鍵共有バージョンで、セッションごとに一時鍵を生成し、前方秘匿性を提供します。これは、TLS 1.3では必須の鍵交換方式です。

Rivest-Shamir-Adleman(RSA)

RSAは、大きな素数の因数分解という数学的複雑さを利用して鍵ペアを生成する、非対称暗号化アルゴリズムです。暗号化と復号化に公開鍵と秘密鍵のペアを使用するため、安全なデータ送信やデジタル署名に適しています。RSAは、セキュリティー上の理由から、TLS 1.3では鍵交換をサポートしていません(つまり、前方秘匿性を提供しません)。ただし、認証には使用できます。

事前共有鍵(PSK)

PSKは、TLSセッションの前に安全なチャネルを使用して二者間で共有される共有秘密鍵です。ユーザーは、TLSハンドシェイク中にPSKを確立し、それを使用して別のハンドシェイク中に新しい接続を確立できます。これはPSKによるセッション再開と呼ばれます。前方秘匿性を実現するために、PSKをDHEまたはECDHEと併用することをお勧めします。

最新のTLSプロトコルのバージョン

1999年のTLS 1.0の最初のリリース(SSLバージョン3.0へのアップグレード)以降、IETFは3つのTLS後続バージョンをリリースしました。

  • TLS 1.1RFC 4346で規定)、2006年4月:このバージョンではセキュリティーと編集における軽微な改善が実施され、明確化が図られました。

  • TLS 1.2RFC 5246で規定)、2008年8月:このバージョンはTLS 1.1の更新版であり、暗号化アルゴリズムのネゴシエーションの柔軟性が大幅に向上しました。

  • TLS 1.3RFC 8446で規定)、2018年8月:この最新のアップデートでは、ゼロ・ラウンドトリップ時間(0-RTT)によるレイテンシーの削減、ネゴシエーションの簡素化などの変更により、セキュリティー、パフォーマンス、プライバシーが向上しました。

TLS 1.3は下位互換モードで実装できますが、以前のTLSバージョンとは直接の互換性がないことに注意することが重要です。

関連ソリューション
IBM Cloud Infrastructure Center 

IBM Cloud Infrastructure Centerは、IBM zSystemsおよびIBM LinuxONE上のプライベートクラウドのインフラストラクチャーを管理するためのOpenStack互換ソフトウェア・プラットフォームです。

Cloud Infrastructure Centerの詳細はこちら
ITインフラストラクチャー・ソリューション

企業のハイブリッドクラウドとAI戦略のために設計された、サーバー、ストレージ、ソフトウェアを紹介します。

ITインフラストラクチャー・ソリューションはこちら
クラウド・ソリューション

安全性と柔軟性を備えたクラウドで、ビジネスの成長に合わせてリソースを無理なく拡張できます。

クラウド・ソリューション
詳細情報はこちら

IBMのハイブリッドクラウドとAI対応ソリューションで、企業インフラを変革しましょう。ビジネスを保護、拡張、モダナイズするために設計されたサーバー、ストレージ、ソフトウェアを発見したり、専門家のインサイトにアクセスして生成AIストラテジーを強化したりできます。

ITインフラストラクチャー・ソリューションはこちら 電子書籍を読む