前方秘匿性

暗号化において、前方秘匿性( FS ) は完全前方秘匿性( PFS )とも呼ばれ、セッション キー交換で使用される長期秘密が侵害された場合でもセッション キーが侵害されないことを保証し、被害を制限する特定のキー合意プロトコルの機能です。 HTTPSの場合、長期秘密は通常、サーバーの秘密キーです。前方秘匿性は、キーやパスワードの将来の侵害から過去のセッションを保護します。ユーザーが開始するセッションごとに一意のセッション キーを生成することにより、1 つのセッション キーが侵害されても、その特定のキーで保護されている特定のセッションで交換されるデータ以外のデータには影響しません。これだけでは前方秘匿性には不十分で、長期秘密の侵害が過去のセッション キーのセキュリティに影響を与えないことも必要です。

前方秘匿性は、 OpenSSL ^[1]などの一般的なトランスポート層セキュリティプロトコルを使用するネットワークのトランスポート層で、Heartbleedセキュリティバグのように長期秘密鍵が侵害されたときにデータを保護します。前方秘匿性を使用すると、長期秘密鍵やパスワードが将来侵害された場合でも、過去に記録された暗号化された通信やセッションを取得して復号化することはできません。これは、中間者 (MITM) 攻撃などの攻撃者が積極的に干渉した場合でも同じです。

前方秘匿性の価値は、過去の通信を保護することです。これにより、攻撃者がキーを侵害する動機が減ります。たとえば、攻撃者が長期キーを知ったとしても、侵害が検出され、長期キーが取り消されて更新された場合、前方秘匿性が確保されたシステムでは、比較的わずかな情報しか漏洩しません。

前方秘匿性の価値は、想定される攻撃者の能力によって異なります。前方秘匿性は、攻撃者がデバイスから秘密鍵を取得できる（読み取りアクセス）と想定されるが、デバイスでセッション鍵が生成される方法が検出されるか変更できない場合（完全な侵害）に価値があります。場合によっては、デバイスから長期鍵を読み取ることができる攻撃者は、バックドア付きのDual Elliptic Curve Deterministic Random Bit Generatorのように、セッション鍵ジェネレーターの機能を変更することもできます。攻撃者が乱数ジェネレーターを予測可能にできる場合、過去のトラフィックは保護されますが、将来のトラフィックはすべて侵害されます。

前方秘匿性の価値は、攻撃者がサーバーを攻撃する際に鍵を盗むだけで、サーバーが使用する乱数生成器を変更しないという仮定だけでなく、攻撃者が通信リンク上のトラフィックを受動的に収集するだけで、中間者攻撃を使用してアクティブにはならないという仮定によっても制限されます。前方秘匿性は通常、過去のトラフィックの読み取りを防ぐために一時的なDiffie-Hellman 鍵交換を使用します。一時的な Diffie-Hellman 鍵交換は、静的署名鍵を使用してサーバーによって署名されることがよくあります。攻撃者がこの静的 (長期) 署名鍵を盗む (または裁判所命令によって取得する) ことができれば、攻撃者はクライアントに対してサーバーになりすまし、サーバーに対してクライアントになりすまして、典型的な中間者攻撃を実行できます。^[2]

「完全前方秘匿性」という用語は、1990年にCGギュンターによって造られ^[3]、 1992年にホイットフィールド・ディフィー、ポール・ファン・オールショット、マイケル・ジェームズ・ウィーナーによってさらに議論され^[4]、ステーション間プロトコルの特性を説明するために使用されました^{[5] 。}

前方秘匿性は、長期秘密が（共有）パスワードであるパスワード認証鍵共有プロトコルの類似した特性を説明するためにも使用されている。^[6]

2000年にIEEEは初めてIEEE 1363を批准しました。これは、さまざまな標準鍵共有方式の関連する一者間および二者間の前方秘匿性特性を確立するものです。^[7]

セッション開始のキー合意フェーズ中に発生するデータ交換のプレーンテキスト (復号化) 検査によって、セッションの残りの部分を暗号化するために使用されたキーが明らかにならない場合、暗号化システムは前方秘匿性の特性を持ちます。

以下は、前方秘匿性を採用した単純なインスタント メッセージング プロトコルの仮想的な例です。

1. アリスとボブはそれぞれ、長期にわたる非対称の公開鍵と秘密鍵のペアを生成し、公開鍵の指紋を対面またはすでに認証されたチャネルを介して検証します。検証により、公開鍵の所有者として主張されている人が実際の所有者であることが確実に証明されます。
2. アリスとボブは、 Diffie-Hellmanなどの鍵交換アルゴリズムを使用して、一時的な セッション鍵に安全に合意します。このプロセス中、両者はステップ 1 の鍵を互いの認証にのみ使用します。
3. アリスは、ステップ 2 でネゴシエートされたセッション キーを使用して対称暗号で暗号化したメッセージをボブに送信します。
4. ボブはステップ 2 でネゴシエートされたキーを使用してアリスのメッセージを復号化します。
5. このプロセスは、新しいメッセージが送信されるたびに、ステップ 2 から始まり (必要に応じて、送信者/受信者としての Alice と Bob の役割が切り替わります)、繰り返されます。ステップ 1 は繰り返されません。

前方秘匿性 (各メッセージに新しいセッション キーを生成することで実現) により、ステップ 2 の反復で生成されたキーの 1 つが侵害されても、過去の通信を解読できなくなります。これは、そのようなキーは 1 つのメッセージの暗号化にのみ使用されるためです。前方秘匿性により、ステップ 1 の長期秘密キーが侵害されても、過去の通信を解読できなくなります。ただし、これが発生すると、アリスまたはボブになりすますことが可能になり、将来のすべてのメッセージが侵害される可能性があります。

前方秘匿性は、長期秘密鍵の漏洩が過去の会話の機密性に影響するのを防ぐように設計されています。しかし、前方秘匿性では、使用されている基礎暗号の解読が成功することを防ぐことはできません。なぜなら、暗号解読は鍵なしで暗号化されたメッセージを復号化する方法を見つけることであり、前方秘匿性は鍵のみを保護し、暗号自体は保護しないからです。^{[8]忍耐強い攻撃者は、}公開鍵暗号の使用によって機密性が保護されている会話をキャプチャし、基礎暗号が破られるまで待つことができます（たとえば、離散対数問題を迅速に計算できる大規模な量子コンピューターを作成できます）。これにより、前方秘匿性を採用しているシステムでも、古い平文を復元できるようになります。

非対話型の前方セキュア鍵交換プロトコルは、対話型プロトコルには関係のない追加の脅威に直面します。メッセージ抑制攻撃では、ネットワークを制御する攻撃者がメッセージを保存し、メッセージが意図した受信者に届かないようにすることができます。メッセージが受信されないため、対応する秘密鍵が破壊またはパンクチャされない可能性があり、秘密鍵が侵害されると復号化に成功する可能性があります。スケジュールに従って秘密鍵を積極的に破棄すると、この攻撃を軽減できますが、完全に排除することはできません。悪意のある鍵枯渇攻撃では、攻撃者は受信者に多くのメッセージを送信し、秘密鍵の素材を使い果たし、プロトコルに、クローズドに失敗（サービス拒否攻撃を可能にする）するか、オープンに失敗（ある程度の前方秘匿性を放棄する）するかの選択を強います。^[9]

ほとんどの鍵交換プロトコルは対話型であり、当事者間の双方向通信を必要とする。送信者が受信者からの応答を事前に受信する必要なくデータを送信できるプロトコルは、非対話型、非同期、またはゼロラウンドトリップ（0-RTT）と呼ばれることがある。^{[10] [11]}

双方向性は、一部のアプリケーションでは厄介な問題です。たとえば、安全なメッセージング システムでは、送信者と受信者が同時にオンラインである必要はなく、ストア アンド フォワード実装が望ましい場合があります。双方向性の要件を緩めると、接続の確立時や再開時など、厳格な要件ではない場合でもパフォーマンスが向上する可能性があります。これらのユース ケースは、非対話型鍵交換への関心を刺激し、鍵交換プロトコルでは前方セキュリティが望ましい特性であるため、非対話型前方秘匿性への関心を刺激しました。 ^{[12] [13]}この組み合わせは、少なくとも 1996 年以来望ましいと認識されています。 ^[14]ただし、前方秘匿性と非対話性を組み合わせることは困難であることが判明しています。^[15]リプレイ攻撃に対する保護を備えた前方秘匿性は非対話型では不可能であると疑われていましたが、3 つの要件すべてを達成できることが示されました。^[11]

一般的に、非対話型前方秘匿性に対する2つのアプローチ、事前計算された鍵とパンクチャブル暗号化が研究されてきた。^[13]

事前計算された鍵では、多数の鍵ペアが作成され、公開鍵が共有され、対応する公開鍵を使用してメッセージが受信された後に秘密鍵が破棄されます。このアプローチは、Signalプロトコルの一部として導入されています。^[16]

パンクチャラブル暗号化では、受信者はメッセージを受信した後、新しい秘密鍵ではメッセージを読み取ることができないが公開鍵は変更されないような方法で秘密鍵を変更します。Ross J. Anderson は1997 年に、前方秘匿鍵交換のためのパンクチャラブル暗号化方式を非公式に説明しました^[17]。また Green & Miers (2015) はそのようなシステムを正式に説明しました^[18]。これは Canetti、Halevi & Katz (2003) の関連方式に基づいており、スケジュールに従って秘密鍵を変更して、前の期間に送信されたメッセージを後の期間の秘密鍵で読み取ることができないようにするものです。^[15] Green & Miers (2015) は階層型アイデンティティ ベース暗号化と属性ベース暗号化を利用していますが、Günther ら (2017) は任意の階層型アイデンティティ ベース方式に基づくことができる異なる構造を使用しています。^[19（2020）は、QUICを改変して0-RTTフォワードセキュアかつリプレイ耐性のある鍵交換を実装したパンクチャブル暗号化を使用すると、リソース使用量が大幅に増加するが、実用上不可能になるほどで​​はないことを実験的に発見した。^[20]

弱い完全前方秘匿性 (Wpfs) は、エージェントの長期キーが侵害された場合、以前に確立されたセッションキーの機密性が保証されるという弱い特性ですが、敵対者が積極的に干渉しなかったセッションに限ります。この新しい概念と、これと前方秘匿性の区別は、2005 年に Hugo Krawczyk によって導入されました。^{[21] [22]この弱い定義は、完全な (完全な) 前方秘匿性が、敵対者が積極的に干渉し}たセッションや中間者として行動しよ うとしたセッションでも、以前に確立されたセッションキーの機密性を維持することを暗黙的に要求しています。

前方秘匿性は、 SSHやIPsec (RFC 2412)のオプション機能など、いくつかの主要なプロトコル実装に存在します。多くのインスタント メッセージング クライアント用の暗号化プロトコルおよびライブラリであるOff-the-Record Messagingや、そのようなクライアントでマルチユーザー機能などの追加機能を提供するOMEMOは、どちらも前方秘匿性と否認可能な暗号化を提供します。

トランスポート層セキュリティ（TLS）では、 Diffie-Hellman鍵交換（DHE- RSA、DHE- DSA）と楕円曲線Diffie-Hellman鍵交換（ECDHE- RSA、ECDHE- ECDSA ）に基づく暗号スイートが利用可能です。理論的には、TLSはSSLv3以降適切な暗号を選択できましたが、日常の実践では多くの実装が前方秘匿性を提供することを拒否するか、非常に低い暗号化レベルのみを提供していました。^[23] TLS 1.3では、一時的なDiffie-Hellman（有限体と楕円曲線の変種）を唯一の鍵交換メカニズムとして残すことで前方秘匿性を確保しています。^[24]

OpenSSLはバージョン1.0以降、楕円曲線Diffie-Hellmanを使用した前方秘匿性をサポートしていますが、 ^[25]初期ハンドシェイクの計算オーバーヘッドは約15%です。^[26]

シグナルプロトコルは、前方秘匿性を提供するためにダブルラチェットアルゴリズムを使用します。^[27]

一方、現在使用されている一般的なプロトコルの中で、WPA PersonalはWPA3以前は前方秘匿性をサポートしていませんでした。^[28]

前方秘匿性は、いくつかの大手インターネット情報プロバイダーによって重要なセキュリティ機能とみなされています。2011年後半から、GoogleはGmailサービス、Google Docsサービス、暗号化検索サービスのユーザーにTLSによる前方秘匿性をデフォルトで提供してきました。^[25] 2013年11月以来、TwitterはユーザーにTLSによる前方秘匿性を提供してきました。^[29] ウィキメディア財団がホストするウィキはすべて、2014年7月からユーザーに前方秘匿性を提供しており^[30]、2018年8月からは前方秘匿性の使用を義務付けています。

Facebookは、電子メールの暗号化に関する調査の一環として、2014年5月の時点で、STARTTLSをサポートするホストの74％が前方秘匿性も提供していると報告しました。 ^[31] 2018年8月に公開されたTLS 1.3では、前方秘匿性のない暗号のサポートが廃止されました。2019年2月現在^[update]、調査対象のウェブサーバーの96.6％が何らかの形の前方秘匿性をサポートしており、52.1％がほとんどのブラウザで前方秘匿性を使用します。^[32]

2016年のWWDCで、AppleはすべてのiOSアプリがHTTPS通信の使用を強制する機能であるApp Transport Security（ATS）を使用する必要があると発表しました。具体的には、ATSでは前方秘匿性を提供する暗号化暗号の使用が求められます。^[33] ATSは2017年1月1日からアプリに必須となりました。^[34]

Signalメッセージングアプリケーションはプロトコルに前方秘匿性を採用しており、PGPに基づくメッセージングプロトコルとは大きく異なります。[ 35 ^]

2024年5月現在、最新のブラウザでは92.6%のウェブサイトで前方秘匿性がサポートされていますが、0.3%のウェブサイトでは前方秘匿性がまったくサポートされていません。^[36]

• 匿名性を前進させる
• ディフィー・ヘルマン鍵交換
• 楕円曲線ディフィー・ヘルマン
• 今収集して後で解読する

• アンダーソン、ロス(2002)。「公開鍵暗号に関する 2 つのコメント」(PDF)。
• Canetti, Ran ; Halevi, Shai ; Katz, Jonathan (2003)。「前方セキュアな公開鍵暗号化方式」。暗号学の進歩 — EUROCRYPT 2003。コンピュータサイエンスの講義ノート。第 2656 巻。pp. 255–271。doi : 10.1007 /3-540-39200-9_16。ISBN 978-3-540-14039-9。
• Green , Matthew D. ; Miers, Ian (2015)。「パンクチャブル暗号化からの安全な非同期メッセージングの転送」。2015 IEEE セキュリティとプライバシーシンポジウム。pp. 305–320。doi :10.1109/ SP.2015.26。ISBN 978-1-4673-6949-7. S2CID  9171925。
• Günther, Felix; Hale, Britta; Jager, Tibor; Lauer, Sebastian (2017)。「完全な前方秘匿性を備えた 0-RTT キー交換」(PDF)。
• Back, Adam (1996 年 9 月 6 日)。「非対話型前方秘匿性」。Cypherpunks (メーリング リスト)。
• Boyd, Colin; Gellert, Kai (2020年8月24日). 「A Modern View on Forward Security」. The Computer Journal . 64 (4) (2021年4月発行): 639–652. doi :10.1093/comjnl/bxaa104. hdl : 11250/2730309 . 2021年6月7日時点のオリジナルよりアーカイブ。 2021年6月8日閲覧。
• ダルマイヤー、フィン。ドリース、ジャン・P.ゲラート、カイ。ハンドリック、トビアス。イェーガー、ティボール。クラウク、ジョナス。ナハティガル、サイモン。レンゼルマン、ティモ。ウルフ、ルディ（2020）。 「Forward-Secure 0-RTT の稼働: QUIC での実装とパフォーマンス分析」(PDF)。

• RFC 2412 IETF、H. Orman。OAKLEY 鍵決定プロトコル
• Perfect Forward Secrecy は NSA を安全な Web ページからブロックできるが、誰も使用していない Computerworld 2013 年 6 月 21 日
• SSL: 今日傍受され、明日には解読される Netcraft 2013 年 6 月 25 日
• フォワードシークレシーの導入 SSL Labs 2013 年 6 月 25 日
• SSL Labs による Web ブラウザのテスト
• SSL Labs による Web サーバーのテスト