暗号スイート

暗号スイートとは、ネットワーク接続のセキュリティを確保するためのアルゴリズムのセットです。スイートでは通常、トランスポート層セキュリティ（TLS）またはその前身であるセキュアソケットレイヤー（SSL）が使用されます。暗号スイートに含まれるアルゴリズムのセットには、通常、鍵交換アルゴリズム、バルク暗号化アルゴリズム、およびメッセージ認証コード（MAC）アルゴリズムが含まれます。[ 1 ]

鍵交換アルゴリズムは、2つのデバイス間で鍵を交換するために使用されます。この鍵は、2つのマシン間で送信されるメッセージの暗号化と復号に使用されます。バルク暗号化アルゴリズムは、送信データの暗号化に使用されます。MACアルゴリズムは、送信データが転送中に変更されていないことを確認するためのデータ整合性チェックを提供します。さらに、暗号スイートには、サーバーまたはクライアントの認証を支援する署名と認証アルゴリズムを含めることができます。

全体として、これらのアルゴリズムの様々な組み合わせを含む数百種類の暗号スイートが存在します。暗号スイートによっては、他の暗号スイートよりも優れたセキュリティを提供するものもあります。しかし、TLS 1.3の採用により、公式にサポートおよび定義されている暗号スイートは5種類のみとなりました。[ 2 ]

暗号スイートの概念の構造と使用法は、TLS標準文書で定義されています。[ 3 ] TLS 1.2は最も普及しているTLSのバージョンです。TLSの最新バージョン（TLS 1.3）では、暗号スイートに対する追加要件が含まれています。定義に特に記載がない限り、TLS 1.2で定義された暗号スイートはTLS 1.3では使用できません。また、その逆も同様です。

名前付き暗号スイートの参照リストはTLS暗号スイートレジストリで提供されている。[ 4 ]

歴史

暗号の使用は、Secure Socket Layer (SSL) 転送プロトコルの作成以来、その一部となっています。SSL は、ほとんどの用途で TLS に引き継がれました。ただし、SSL の最初の草案では、暗号スイートという名前は使用されていませんでした。代わりに、クライアントとサーバーが接続を安全にするために少数の暗号から選択する機能は、Cipher-Choice と呼ばれていました。[ 5 ] [ 6 ]暗号スイートという名前が使用されるようになったのは、SSL v3 (SSL の最終バージョン) になってからです。[ 7 ]それ以降の TLS のすべてのバージョンでは、標準化に暗号スイートを使用しています。暗号スイートの概念と目的は、この用語が最初に造られて以来変わっていません。2 台のマシンが接続を安全にするためにどのアルゴリズムを使用するかを決定するために、マシンがサポートするアルゴリズムを記述する構造として使用されてきましたし、現在も使用されています。変わったのは、暗号スイートでサポートされているアルゴリズムのバージョンです。 TLS の各バージョンでは、より強力なバージョンのアルゴリズムのサポートが追加され、安全でないと特定されたバージョンのアルゴリズムのサポートが削除されました。

TLS 1.3では、マシン間の暗号スイートの調整方法が変更されました。通信する2台のマシンが使用する暗号スイートは、ハンドシェイクプロセスによって決定されます。TLS 1.3では、送信する必要があるメッセージ数を削減するために、ハンドシェイクプロセスに変更が加えられました。これにより、以前のバージョンのTLSと比較して、処理量とパケットトラフィックが削減され、効率が向上します。

命名規則

各暗号スイートには、その識別とアルゴリズムの内容を説明するために使われる一意の名前が付けられています。暗号スイート名の各セグメントは、異なるアルゴリズムまたはプロトコルを表します。暗号スイート名の例：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

この名前の意味は次のとおりです。

TLS
この暗号スイートが対象とするプロトコルを定義します。通常は TLS になります。
ECDHE
使用されている鍵交換アルゴリズムを示します。
RSA
ハンドシェイク中の認証メカニズム。
AES
セッション暗号。
128
暗号のセッション暗号化キーのサイズ(ビット)。
地球全体
暗号化の種類 (暗号ブロックの依存性と追加オプション)。
シャ
(SHA2)ハッシュ関数。ダイジェストが256以上の場合。署名メカニズム。メッセージの認証に使用されるメッセージ認証アルゴリズムを示します。
256
ダイジェスト サイズ (ビット)。

フルハンドシェイク：暗号スイートの調整

暗号スイートを使用するには、クライアントとサーバーがメッセージ交換に使用する特定の暗号スイートについて合意する必要があります。クライアントとサーバーの両方が、合意された暗号スイートをサポートしている必要があります。クライアントとサーバーが暗号スイートについて合意しない場合、接続は確立されません。[ 8 ]この選択プロセスはTLSハンドシェイクプロトコル中に行われます。TLS 1.3には、TLS/SSLの過去および現在のバージョンとは異なるTLSハンドシェイクプロトコルが含まれています。

使用する暗号スイートを調整した後でも、サーバーとクライアントは、現在のハンドシェイクまたは新しいハンドシェイクで ChangeCipherSpecプロトコルを使用して、調整された暗号を変更できます。

サーバーがサポートしているTLS暗号をテストするには、SSL/TLSスキャナーを使用できます。[1]

TLS 1.0–1.2 ハンドシェイク

TLS 1.2 で動作するクライアントとサーバーが、どの暗号スイートを使用するかを調整する方法の視覚的表現

このクライアントは、使用しているTLSのバージョンと、クライアントの優先順位に従った暗号スイートのリストを含むclientHelloメッセージをサーバーに送信することで、プロセスを開始します。サーバーは、選択された暗号スイートとセッションIDを含むserverHelloメッセージをサーバーに送信します。次に、サーバーは自身のIDを確認するためのデジタル証明書をクライアントに送信します。サーバーは必要に応じて、クライアントのデジタル証明書を要求することもあります。

クライアントとサーバーが事前共有キーを使用していない場合、クライアントは暗号化されたメッセージをサーバーに送信し、クライアントとサーバーは交換中に使用される秘密キーを計算できるようになります。

serverHelloメッセージのprefer server cipherビットがtrueに設定されている場合、ネゴシエートされた暗号スイートはserverHelloメッセージの暗号スイートリストで優先されます。それ以外の場合、ネゴシエートされた暗号スイートはclientHelloメッセージの暗号スイートリストで優先されます。[ 9 ]

サーバーの認証を検証し、必要に応じて秘密鍵を交換した後、クライアントはハンドシェイクプロセスが完了したことを示すfinishedメッセージを送信します。サーバーはこのメッセージを受信すると、ハンドシェイクが完了したことを確認するfinishedメッセージを送信します。これで、クライアントとサーバーは相互通信に使用する暗号スイートについて合意したことになります。

TLS 1.3 で動作するクライアントとサーバーが、どの暗号スイートを使用するかを調整する方法の視覚的表現

TLS 1.3 ハンドシェイク

2台のマシンがTLS 1.3で通信する場合、TLS 1.3ハンドシェイクプロトコルを使用して、使用する暗号スイートを調整します。TLS 1.3のハンドシェイクは、以前のバージョンのTLS/SSLで必要だった2回の往復に比べて、1回の往復に短縮されました。

まず、クライアントは、クライアントの好みの順にサポートされている暗号のリストを含むclientHelloメッセージをサーバーに送信し、使用されているキー アルゴリズムを推測して、必要に応じて共有する秘密キーを送信できるようにします。

使用されている鍵アルゴリズムを推測することで、往復の通信を省きます。clientHello を受信した後、サーバーは鍵、証明書、選択された暗号スイート、そして完成したメッセージを含むserverHelloを送信します。

serverHelloメッセージのprefer server cipherビットがtrueに設定されている場合、ネゴシエートされた暗号スイートはserverHelloメッセージの暗号スイートリストで優先されます。それ以外の場合、ネゴシエートされた暗号スイートはclientHelloメッセージの暗号スイートリストで優先されます。[ 10 ]

クライアントがサーバーの完了メッセージを受信した後、どの暗号スイートを使用するかをサーバーと調整します。[ 11 ]

サポートされているアルゴリズム

TLS 1.0～1.2の場合

TLS 1.0～1.2暗号スイートでサポートされているアルゴリズム
鍵交換/合意 認証 ブロック/ストリーム暗号 メッセージ認証
RSARSARC4ハッシュベースのMD5
ディフィー・ヘルマンDSAトリプルDESSHA ハッシュ関数(SHA-1 および SHA-2)
ECDHECDSAAES（128ビットおよび256ビット）
SRPアイデア
PSK [ 12 ]デス
カメリア
チャチャ20

TLS 1.0～1.2でサポートされているアルゴリズムの詳細については、トランスポート層セキュリティ§アプリケーションと採用も参照してください。

TLS 1.3

TLS 1.3では、プロトコルの安全性を高めるため、初期のTLSでサポートされていた多くのレガシーアルゴリズムが削除されました。[ 13 ]さらに、すべての暗号化アルゴリズムと認証アルゴリズムは、認証付き暗号化と関連データ（AEAD）暗号化アルゴリズムに統合されています。また、HMACベースの鍵導出（ HKDF ）ではハッシュアルゴリズムを使用する必要があります。[ 14 ] AEAD以外の暗号はすべて、潜在的な脆弱性のために削除され、暗号は一時的な鍵交換アルゴリズムを使用する必要があります。これにより、交換のたびに新しい鍵ペアが生成されます。[ 15 ]

暗号スイートを使用したDTLS

データグラムトランスポート層セキュリティ（DTLS）はTLSに基づいていますが、TCP接続ではなくUDP接続に特化しています。DTLSはTLSに基づいているため、TLSで定義されている暗号スイートの大部分を使用できます。ただし、TLS暗号スイートをDTLSで使用する場合は、考慮すべき特殊なケースがあります。DTLSはストリーム暗号RC4をサポートしていないため、RC4を使用するTLS暗号はDTLSでは使用できません。[ 16 ]

TLS暗号スイートがDTLSと互換性があるかどうかを判断するために、その名前を見るだけでは役に立ちません。各TLS暗号スイートの名前には、TLS識別子空間が含まれます。例：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。代わりに、すべてのTLSパラメータレジストリには、暗号スイートがDTLSをサポートしているかどうかを示すフラグDTLS-OKが含まれるようになりました。[ 17 ]

脆弱性

暗号スイートの安全性は、それに含まれるアルゴリズムの安全性に左右されます。暗号スイートに含まれる暗号化アルゴリズムまたは認証アルゴリズムのバージョンに既知の脆弱性がある場合、暗号スイートとTLS接続が脆弱になる可能性があります。そのため、TLSと暗号スイートに対する一般的な攻撃は、ダウングレード攻撃と呼ばれています。TLSのダウングレードは、最新のクライアントが古いバージョンのTLSまたはSSLを使用しているレガシーサーバーに接続したときに発生します。

ハンドシェイクを開始する際、最新のクライアントはサポート可能な最高レベルのプロトコルを提供します。接続に失敗した場合、サーバーとのハンドシェイクが成功するまで、TLS 1.0やSSL 3.0などの低レベルのプロトコルで自動的に再試行します。ダウングレードの目的は、新しいバージョンのTLSを古いバージョンと互換性を持たせることです。しかし、攻撃者がこの機能を悪用し、クライアントがセキュリティの脆弱性が知られているアルゴリズムを含む暗号スイートをサポートするTLSまたはSSLのバージョンに自動的にダウングレードするように仕向ける可能性があります。[ 18 ]これはPOODLEなどの攻撃につながっています。

このセキュリティ上の欠陥を回避する方法の一つは、サーバーまたはクライアントがSSL 3.0にダウングレードできないようにすることです。この修正の欠点は、一部のレガシーハードウェアが新しいハードウェアからアクセスできないことです。レガシーハードウェアでSSL 3.0のサポートが必要な場合は、悪意のある意図でダウングレードがトリガーされていないことを確認する、承認済みのTLS_FALLBACK_SCSV暗号スイートがあります。[ 19 ]

制約のあるデバイス向けの暗号スイート

暗号化、鍵交換、認証アルゴリズムは通常、膨大な処理能力とメモリを必要とします。IoT（モノのインターネット）を支えるデバイスなど、処理能力、メモリ、バッテリー寿命が限られているデバイスにセキュリティを提供するために、特別に選択された暗号スイートが存在します。以下にその例を2つ挙げます。

  1. TLS_PSK_WITH_AES_128_CCM_8（事前共有鍵）[ 20 ]
  2. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (生の公開鍵)

これらの暗号スイートはいずれも、処理能力やメモリに制約のあるデバイスで動作するように実装されている。これらはオープンソース プロジェクトTinyDTLSで実装されている。これらの制約のあるデバイスで動作できる理由は、軽量に実装できるためである。事前共有鍵暗号スイートの実装では、わずか 1889 バイトの RAM と 38266 バイトのフラッシュ ROM しか使用しなかった。これは、ほとんどの暗号化およびセキュリティ アルゴリズムと比較して、リソース消費量が非常に少ない。[ 21 ] このメモリ使用量の少なさは、これらの暗号スイートが、安全であることが証明されている効率的なアルゴリズムを使用しているためであるが、より多くのリソースを必要とするアルゴリズムほど安全ではない可能性がある。例: 128 ビット暗号化 vs. 256 ビット暗号化。さらに、これらは事前共有鍵または生の公開鍵を使用するため、従来の公開鍵インフラストラクチャ(PKIX)を使用する場合と比較して、メモリ容量と処理能力が少なくて済む。[ 22 ]

プログラミング参考資料

プログラミングにおいて、暗号スイートは複数形と非複数形の両方で呼ばれます。それぞれ定義が異なります。

暗号スイート cipher_suites
クライアントがサポートする暗号化オプションのリスト。[ 23 ]ハンドシェイクプロセス中にcipher_suitesが通常どのように使用されるかの例：
struct { ProtocolVersion client_version ; Random random ; SessionID session_id ; CipherSuite cipher_suites < 2 .. 2 ^ 16 - 2 >; CompressionMethod compression_methods < 1 .. 2 ^ 8 - 1 >; select ( extensions_present ) { case false : struct {}; case true : Extension extensions < 0 .. 2 ^ 16 - 1 >; }; } ClientHello ;
暗号スイート cipher_suite
サーバーがクライアントのcipher_suitesから選択した暗号スイート。[ 24 ]ハンドシェイクプロセス中にcipher_suiteが通常どのように使用されるかの例：
struct { ProtocolVersion server_version ; Random random ; SessionID session_id ; CipherSuite cipher_suite ; CompressionMethod compression_method ; select ( extensions_present ) { case false : struct {}; case true : Extension extensions < 0 .. 2 ^ 16 - 1 >; }; } ServerHello ;

参照

参考文献

  1. ^ 「TLS/SSL の暗号スイート (Schannel SSP) (Windows)」 . docs.microsoft.com . 2018年7月2日閲覧。
  2. ^ 「TLS v1.3を使用した暗号スイートリストの構成」www.microfocus.com . 2023年11月30日閲覧。
  3. ^ RFC 5246 
  4. ^ TLS暗号スイートレジストリ
  5. ^ 「SSL 0.2プロトコル」www-archive.mozilla.org . 2017年12月7日閲覧。
  6. ^ Elgamal, Taher; Hickman, Kipp EB (1995年4月19日). 「draft-hickman-netscape-ssl-00」 . tools.ietf.org . 2017年12月7日閲覧。
  7. ^ 「SSL 3.0仕様」 www.freesoft.org . 2017年12月7日閲覧。
  8. ^ Villanueva, John Carl. 「暗号スイート入門」 . 2017年10月25日閲覧。
  9. ^ 「Mod_ssl - Apache HTTP サーバー バージョン 2.4」。
  10. ^ Rescorla, Eric (2018年8月). 「トランスポート層セキュリティ（TLS）プロトコル バージョン1.3」 .
  11. ^ Valsorda, Filippo (2016年9月23日). 「TLS 1.3の概要とQ&A」 . Cloudflareブログ. 2020年9月1日閲覧。
  12. ^ TLS 1.2およびDTLS 1.2向けAES-GCMおよびAES-CCM暗号スイートを使用したECDHE_PSK。doi : 10.17487 / RFC8442。RFC 8442。
  13. ^ 「TLS 1.3プロトコルサポート | wolfSSL組み込みSSL/TLSライブラリ」 . wolfSSL . 2017年10月26日閲覧。
  14. ^ E. Rescorla (2016年11月4日). 「トランスポート層セキュリティ（TLS）プロトコル バージョン1.3」 . 2016年11月11日閲覧。
  15. ^ Sullivan, Nick (2018年8月11日). 「RFC 8446 (別名 TLS 1.3) の詳細な考察」 . Cloudflare ブログ. 2020年8月11日閲覧。
  16. ^ N., Modadugu; E., Rescorla (2006年4月). 「データグラムトランスポート層セキュリティ」 . tools.ietf.org . 2017年10月25日閲覧。
  17. ^ Eric, Rescorla; Nagendra, Modadugu (2012年1月). 「データグラムトランスポート層セキュリティ バージョン1.2」 . tools.ietf.org . 2017年10月25日閲覧。
  18. ^ Bodo, Moeller; Adam, Langley (2015年4月). 「プロトコルダウングレード攻撃を防ぐためのTLSフォールバックシグナリング暗号スイート値（SCSV）」 . tools.ietf.org . 2017年10月25日閲覧。
  19. ^ Bodo, Moeller; Adam, Langley (2015年4月). 「プロトコルダウングレード攻撃を防ぐためのTLSフォールバックシグナリング暗号スイート値（SCSV）」 . tools.ietf.org . 2017年10月25日閲覧。
  20. ^ Daniel, Bailey; David, McGrew (2012年7月). 「トランスポート層セキュリティ（TLS）向けAES-CCM暗号スイート」 . tools.ietf.org . 2017年10月26日閲覧。
  21. ^ Perelmen, Vladislav (2012年6月29日). 「IPv6対応ワイヤレスセンサーネットワークにおけるセキュリティ：Contikiオペレーティングシステム向けTLS/DTLSの実装」(PDF) : 38. 2017年8月29日時点のオリジナル(PDF)からアーカイブ。 2017年12月7日閲覧。{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  22. ^ Samuel, Weiler; John, Gilmore; Hannes, Tschofenig; Tero, Kivinen; Paul, Wouters (2014年6月). 「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）における生の公開鍵の使用」 . tools.ietf.org . 2017年12月7日閲覧。
  23. ^ RFC 5246、41ページ 
  24. ^ RFC 5246、42～43ページ、64ページ 
「 https://en.wikipedia.org/w/index.php?title=Cipher_suite&oldid=1335300244」から取得