Loading article…
暗号化において、前方秘匿性( FS )、または完全前方秘匿性( PFS ) は、特定の鍵合意プロトコルの機能であり、セッション鍵交換で使用される長期秘密鍵が漏洩した場合でもセッション鍵が漏洩しないことを保証し、被害を限定します。 [ 1 ] [ 2 ] [ 3 ] TLSの場合、長期秘密鍵は通常、サーバーの秘密鍵です。前方秘匿性は、鍵またはパスワードの将来の漏洩から過去のセッションを保護します。ユーザーが開始するセッションごとに一意のセッション鍵を生成することで、単一のセッション鍵が漏洩しても、その特定の鍵で保護されている特定のセッションで交換されたデータ以外には影響しません。これだけでは前方秘匿性には十分ではなく、長期秘密鍵の漏洩が過去のセッション鍵のセキュリティに影響を与えないことも必要です。
前方秘匿性は、 Heartbleedセキュリティバグのように長期秘密鍵が漏洩した場合に、OpenSSL などの一般的なトランスポート層セキュリティプロトコルを使用するネットワークのトランスポート層上のデータを保護します。[4] 前方秘匿性が使用されている場合、攻撃者が中間者攻撃 (MITM) などによって積極的に妨害したとしても、将来長期秘密鍵やパスワードが漏洩した場合でも、過去に記録された暗号化された通信やセッションを取得して復号化することはできません。
前方秘匿性の利点は、過去の通信を保護できる点にある。これにより、攻撃者が鍵を侵害しようとする動機が軽減される。例えば、攻撃者が長期鍵を入手したとしても、その侵害が検知され、長期鍵が失効・更新されれば、前方秘匿性の高いシステムでは漏洩する情報は比較的少なくなる。
前方秘匿性の価値は、攻撃者の想定される能力に依存します。前方秘匿性は、攻撃者がデバイスから秘密鍵を取得できる（読み取りアクセス）ものの、検出されるか、デバイス内でセッション鍵の生成方法を変更できない（完全な侵害）場合に価値を持ちます。場合によっては、デバイスから長期鍵を読み取ることができる攻撃者が、バックドア付きのデュアル楕円曲線決定論的乱数ビット生成器のように、セッション鍵生成器の動作を変更できることもあります。攻撃者が乱数生成器を予測可能にできる場合、過去のトラフィックは保護されますが、将来のすべてのトラフィックは侵害されます。
前方秘匿性の価値は、攻撃者がサーバーを攻撃する際に鍵を盗むだけで、サーバーが使用する乱数生成器を変更しないという前提だけでなく、攻撃者が通信リンク上のトラフィックをパッシブに収集するだけで、中間者攻撃をアクティブに行わないという前提によっても制限されます。前方秘匿性は通常、過去のトラフィックの読み取りを防ぐために一時的なDiffie–Hellman 鍵交換を使用します。一時的な Diffie–Hellman 鍵交換は、多くの場合、静的署名鍵を使用してサーバーによって署名されます。攻撃者がこの静的 (長期) 署名鍵を盗む (または裁判所命令によって入手する) ことができれば、攻撃者はクライアントに対してサーバーになりすまし、サーバーに対してクライアントになりすまして、古典的な中間者攻撃を実行できます。[ 5 ]
「完全前方秘匿性」という用語は、1990 年に CG Günther によって造語され[ 6 ] 、1992 年にWhitfield Diffie、Paul van Oorschot、Michael James Wienerによってさらに議論され[ 7 ] 、ステーション間プロトコルの特性を説明するために使用されました[ 8 ] 。
前方秘匿性は、長期秘密が（共有）パスワードであるパスワード認証鍵合意プロトコルの類似特性を説明するためにも使用されている。[ 9 ]
2000年にIEEEはIEEE 1363を初めて承認し、さまざまな標準鍵合意スキームの関連する一者間および二者間の前方秘匿性を確立しました。[ 10 ]
暗号化システムは、セッション開始時の鍵合意フェーズで行われるデータ交換を平文（復号化済み）で検査しても、セッションの残りの部分を暗号化するために使用された鍵が明らかにならない場合、前方秘匿性という特性を持つ。
以下は、前方秘匿性を採用したシンプルなインスタントメッセージングプロトコルの架空の例です。
前方秘匿性（メッセージごとに新しいセッションキーを生成することで実現）により、ステップ2の反復処理で生成されたキーのいずれかが漏洩した場合でも、過去の通信は復号化されないことが保証されます。これは、そのようなキーは単一のメッセージの暗号化にのみ使用されるためです。前方秘匿性は、ステップ1の長期秘密鍵が漏洩した場合でも、過去の通信が復号化されないことも保証します。ただし、この場合、アリスまたはボブになりすますことが可能になり、将来のすべてのメッセージが危険にさらされる可能性があります。
前方秘匿性は、長期秘密鍵の漏洩が過去の会話の機密性に影響を与えないように設計されている。しかし、前方秘匿性は、使用されている基盤となる暗号の暗号解読が成功した場合を防ぐことはできない。なぜなら、暗号解読とは鍵なしで暗号化されたメッセージを復号する方法を見つけることであり、前方秘匿性は鍵のみを保護し、暗号自体を保護しないからである。[ 11 ]忍耐強い攻撃者は、公開鍵暗号を使用して機密性が保護されている会話を傍受し、基盤となる暗号が破られるまで待つことができる（たとえば、離散対数問題を高速に計算できる大規模な量子コンピュータが作成される可能性がある）。これは、今すぐ収集し、後で復号する攻撃とも呼ばれる。これにより、前方秘匿性を採用しているシステムでも、古い平文を復元することが可能になる。
非対話型の前方秘匿鍵交換プロトコルは、対話型プロトコルには関係のない追加の脅威に直面します。メッセージ抑制攻撃では、ネットワークを制御する攻撃者が、メッセージが意図した受信者に届かないようにしながら、メッセージを自身で保存する場合があります。メッセージが受信されないため、対応する秘密鍵が破壊または侵害されない可能性があり、秘密鍵が漏洩すると復号化が成功する可能性があります。秘密鍵をスケジュールに従って積極的に廃止することで、この攻撃を軽減できますが、完全に排除することはできません。悪意のある鍵枯渇攻撃では、攻撃者が受信者に多数のメッセージを送信して秘密鍵の素材を枯渇させ、プロトコルにフェイルクローズ（サービス拒否攻撃を可能にする）またはフェイルオープン（前方秘匿性をある程度放棄する）のいずれかを選択させることになります。[ 12 ]
ほとんどの鍵交換プロトコルは対話型であり、当事者間の双方向通信を必要とします。送信者が受信者からの応答を待たずにデータを送信できるプロトコルは、非対話型、非同期型、またはゼロラウンドトリップタイム（0-RTT）と呼ばれることがあります。[ 13 ] [ 14 ]
対話性は一部のアプリケーションにとって負担となる。たとえば、セキュアなメッセージング システムでは、送信者と受信者が同時にオンラインである必要がないため、ストア アンド フォワード実装が望ましい場合がある。双方向性の要件を緩和すると、接続の確立や再開など、厳密な要件ではない場合でもパフォーマンスが向上する可能性がある。これらのユース ケースは、非対話型鍵交換、および鍵交換プロトコルで望ましい特性である前方セキュリティ、非対話型前方秘匿性への関心を刺激した。[ 15 ] [ 16 ]この組み合わせは、少なくとも 1996 年以来望ましいと認識されている。[ 17 ]しかし、前方秘匿性と非対話性を組み合わせることは困難であることがわかっている。[ 18 ]リプレイ攻撃に対する保護を備えた前方秘匿性を非対話型で実現することは不可能であると疑われていたが、3 つの要件すべてを達成できることが示された。[ 14 ]
大まかに言うと、非対話型前方秘匿性には、事前計算された鍵と穿孔可能な暗号化という2つのアプローチが検討されてきた。[ 16 ]
事前に計算された鍵を使用すると、多数の鍵ペアが作成され、公開鍵が共有され、対応する公開鍵を使用してメッセージを受信した後に秘密鍵が破棄されます。このアプローチは、Signalプロトコルの一部として展開されています。[ 19 ]
破裂可能な暗号化では、受信者はメッセージを受信した後、新しい秘密鍵ではメッセージを読み取ることができないが公開鍵は変更されない方法で秘密鍵を変更します。Ross J. Anderson は1997 年に前方安全な鍵交換のための破裂可能な暗号化方式を非公式に説明し[ 20 ]、Green & Miers (2015) はそのようなシステムを正式に説明しました[ 21 ] 。これは、Canetti、Halevi & Katz (2003)の関連方式に基づいており、以前の期間に送信されたメッセージが後の期間の秘密鍵で読み取れないようにスケジュールに従って秘密鍵を変更します。[ 18 ] Green & Miers (2015)は階層的アイデンティティベース暗号化と属性ベース暗号化を利用していますが、Günther et al. (2017)は任意の階層的アイデンティティベース方式に基づくことができる別の構成を使用しています。[ 22 ] Dallmeier et al. (2020)は実験的に、 QUICを修正して、穴あけ可能な暗号化で実装された0-RTT前方安全かつリプレイ耐性のある鍵交換を使用すると、リソース使用量が大幅に増加するが、実用化不可能になるほどではないことを発見した。[ 23 ]
弱い完全前方秘匿性 (Wpfs) は、エージェントの長期鍵が侵害された場合でも、以前に確立されたセッション鍵の秘匿性が保証されるという、より弱い特性です。ただし、これは攻撃者が積極的に干渉しなかったセッションに限られます。この新しい概念と、これと前方秘匿性との区別は、2005 年に Hugo Krawczyk によって導入されました。[ 24 ] [ 25 ]このより弱い定義は、完全前方秘匿性が、攻撃者が積極的に干渉したり、中間者として行動しようとした セッションでも、以前に確立されたセッション鍵の秘匿性を維持することを暗黙のうちに要求しています。
前方秘匿性は、 SSHやIPsec （RFC 2412）など、いくつかのプロトコル実装に備わっていますが、後者ではオプションです。多くのインスタントメッセージングクライアント向けの暗号化プロトコルおよびライブラリであるOff-the-Record Messaging、およびそのようなクライアントでマルチユーザー機能などの追加機能を提供するOMEMOは、いずれも前方秘匿性と否認可能な暗号化を提供します。
トランスポート層セキュリティ(TLS)では、ディフィー・ヘルマン鍵交換 (DHE- RSA、DHE- DSA ) と楕円曲線ディフィー・ヘルマン鍵交換 (ECDHE- RSA、ECDHE- ECDSA )に基づく暗号スイートが利用可能です。理論的には、TLS は SSLv3 以降前方秘匿性を使用できますが、多くの実装では前方秘匿性を提供していないか、低レベルの暗号化で提供しています。[ 26 ] TLS 1.3 では鍵交換の RSA のサポートが削除され、ディフィー・ヘルマン (前方秘匿性付き) が鍵交換の唯一のアルゴリズムとして残されました。[ 27 ]
OpenSSLはバージョン1.0以降、楕円曲線ディフィー・ヘルマンを使用した前方秘匿性をサポートしており、 [ 28 ]最初のハンドシェイクの計算オーバーヘッドは約15%です。[ 29 ]
シグナルプロトコルは、前方秘匿性を提供するためにダブルラチェットアルゴリズムを使用します。[ 30 ]
一方、現在広く使われているプロトコルの中では、WPA PersonalはWPA3以前は前方秘匿性をサポートしていませんでした。[ 31 ]
2011年後半以降、GoogleはGmailサービス、Googleドキュメントサービス、暗号化検索サービスのユーザーにTLSによる前方秘匿性をデフォルトで提供している。 [ 28 ] 2013年11月以降、TwitterはユーザーにTLSによる前方秘匿性を提供している。[ 32 ]ウィキメディア財団がホストするWikiはすべて、2014年7月以降ユーザーに前方秘匿性を提供しており、[ 33 ] 2018年8月以降は前方秘匿性の使用を必須としている。
Facebookは電子メール暗号化に関する調査の一環として、2014年5月時点でSTARTTLSをサポートするホストの74%が前方秘匿性も提供していると報告した。[ 34 ] 2018年8月に公開されたTLS 1.3では、前方秘匿性のない暗号のサポートが廃止された。2019年2月現在 調査対象のウェブサーバーの96.6%が何らかの形のフォワードシークレットをサポートしており、52.1%がほとんどのブラウザでフォワードシークレットを使用する予定です。[ 35 ]
WWDC 2016で、AppleはすべてのiOSアプリがHTTPS送信の使用を強制する機能であるApp Transport Security（ATS）を使用する必要があると発表した。具体的には、ATSは前方秘匿性を提供する暗号化方式の使用を要求する。[ 36 ] ATSは2017年1月1日にアプリに必須となった。[ 37 ]
Signalメッセージングアプリケーションは、プロトコルに前方秘匿性を採用しており、PGPに基づくメッセージングプロトコルとは大きく異なっている。[ 38 ]
2025年6月のある調査では最新のブラウザでアクセスした場合、人気のあるウェブサイトの約95%が前方秘匿性をサポートしており、0.2%は全くサポートしていませんでした。[ 39 ]
{{cite journal}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)