Open

Definition of End-to-end Encryption

9

抄録

エンドツーエンド暗号化(E2EE)は、エンドポイント間の通信システムにおける暗号化技術の応用です。 E2EEシステムは、ユーザーに機密性、完全性、および真正性の機能を提供するという点でユニークです。 E2EEの改良は、ユーザビリティと可用性のバランスをとりながら、システムのセキュリティを最大化することを目指しています。 E2EE通信のユーザーは、安全な実装を提供する信頼できるプロバイダーが、ユーザーのささやきの権利を尊重し、保護することを期待しています。

1. 序章

この文書では、さまざまな文脈で適用可能な E2EE の完全な定義を構成する 3 つの異なる次元を用いて、エンドツーエンド暗号化(E2EE)を定義する。

最初の定義は、エンドポイントと暗号化の基本的な理解に基づいた形式的な定義である。 第二に、E2EE システムを設計の観点から見た場合の基本的な特徴と、それらの特徴を改善するための方向性について考察します。 最後に、E2EEシステムのユーザーが期待することを考察します。

これらの次元を全体として見ると、メッセージングからビデオ会議まで、アプリケーションを問わず、またエンドポイントの数を問わず、エンドツーエンドの暗号化とは何かについて、IETFでのコンセンサスは一般的に理解しやすいものとなっています。

2. エンドツーエンド暗号化の正式な定義

エンドツーエンドの暗号化通信システムは、その内容や採用されている特定の方法に関わらず、2つの重要かつ厳格な技術的概念に依存しています。インターネットプロトコルの重要性からIETFで定義されているエンドツーエンドの原則と、暗号化とは、暗号技術の応用であり、IETFがインターネットプロトコルの安全性を確保するために採用している主要な手段です。

2.1. エンドツーエンドの原則

エンドツーエンドの原則(End-to-End Principle) [RFC3724]をレビューする際の重要な質問は、「何がエンドを構成するのか」ということである。 直感的には、「エンド」はメッセージを送信するか受信するかのどちらかであり、通常はその両方である。

1984年には、分散型コンピュータシステムのモジュール間で機能を配置する際の指針となる設計原理として、「エンドツーエンド引数」が導入されました[saltzer]。 これは、システムの低レベルに配置された機能は、その低レベルで提供するコストと比較すると、冗長であったり、価値が低いものである可能性があることを示唆しています。 これは、システムのどの部分がどの決定を行うべきかという質問を中心に設計するために使用され、そのような実際の「話し手」や「終わり」の正体は、見かけよりも明らかではないかもしれません。 Saltzer によって記述された通信は、同じ物理マシン上にあってもなくてもよい通信プロセス間のものであり、さまざまな方法で実装されているかもしれません。 例えば、BGPスピーカは、ルーティング情報ベース(RIB)を管理し、TCPを実装したオペレーティングシステムサービスを使用して他のBGPスピーカと通信するプロセスとして実装されることが多い。 RIBマネージャは、ピアにアドバタイズされるべきプレフィックスをRIBから検索し、それぞれのプレフィックスに対してTCPへの「書き込み」を実行していることに気づくかもしれません。 この文脈でのTCPは、RFC868に記載されているアルゴリズム(「Nagleアルゴリズム」)の変形版を実装していることが多く、これは、通信相手間の飛行中のデータがなくなるまでバッファに書き込みを蓄積し、それを送信する。 その意味では、RIB マネージャは何を通信すべきかを決定するので「終わり」と考えられ、TCP は「終わり」と考えることができ、TCP セグメントを実際に送信し、エラーが発生した場合にはそれを検出し、必要に応じて再送信し、最終的にセグメントが正常に転送されたと決定するので、TCP は「終わり」と考えることができます。

しかし、技術者にとっては微妙なニュアンスではあるが、通信システム自体はユーザに始まりユーザに終わるということが広く受け入れられている[RFC8890]。 私たちは、(アプリケーションのユーザーインターフェースを通じて)人をサブシステムの設計のコンポーネントとして想像しています。 E2EE システムでの重要な例外として、公開鍵インフラストラクチャを使用することがあります。

もう 1 つの重要な質問は、「エンド・ツー・エンドの原則を正確に要約しているのはどのような記述か」ということです。 第一は、トランザクションを実装するサービスが、それを送信したアプリケーションの意図を実装していれば最も正しいということで、それはメッセージを関連するIPヘッダの宛先アドレスに向かって移動させるということである。 しかし、Salzerのより徹底した扱いは、実装で出てくるエンドケースを扱っている。"抄録によると、「この論文で議論されている例」には、「ビットエラーの回復、暗号化を使用したセキュリティ、重複メッセージの抑制、システムクラッシュからの回復、および配信確認が含まれています」とあります。 また、最適化を目的としたエンドツーエンドの議論を無視する根拠が時折あることにも言及しています。 以下で説明するように、エンドツーエンド引数とのバランスをとる必要がある他のユーザーの期待や設計機能があるかもしれません。

2.2. 暗号化

draft-dkg-hrpc-glossary-00より、暗号化はEnd-to-Endの原理の基本です。 "End-to-End : プロトコルやシステムの特性をシステム内で可能な限り拡張する原則。 例えば、エンドツーエンドのインスタントメッセージの暗号化は、あるユーザーのインスタントメッセージングアプリケーションから、中間デバイスやサーバーを経由して、受信者のインスタントメッセージングアプリケーションに至るまで、通信内容を隠すことになります。 メッセージがサービスプロバイダなどの中間地点で復号化された場合、エンドツーエンドの暗号化の特性は存在しないでしょう」[dkg] これは通信の内容についてのみ述べており、通信から生成されたメタデータについては述べていないことに注意してください。

真のエンドツーエンド通信システムを実現する方法は、エンドポイント間で交換されるデータの内容を暗号化することである。 暗号化のためのより一般的なエンドツーエンドの技術は、認証された暗号化方式を用いたダブルラチェットアルゴリズムを使用しています。 また、オブジェクトの暗号化、オブジェクトの署名、およびアイデンティティ認証をカバーする仕様を作成するためにIETFでチャーターされています[openpgp]両方のプロトコルは、非対称および対称暗号化の使用に依存し、エンドポイント間で公開鍵を交換する必要があります。

RFCシリーズには、基本的かつ技術的に暗号化方式を定義する文書が多数あります。 この種の既存の文書をすべて調査して、その共通の特徴をまとめて定義することは、おそらく興味深い作業になるだろう。 要するに、IETF は、インターネットの暗号化通信の仕様を定義するための明確なマンデートと専門知識を持っているということです。

3. エンドツーエンドの暗号化システムの設計

E2EEシステムを設計の観点から見る場合、まず最初に考慮すべきことは、E2EEを採用していないシステムとE2EEシステムを区別する基本的な機能のリストです。 次に、E2EEシステムの特徴を改善するための方向性を考えなければなりません。 言い換えれば、E2EEシステムの設計者、開発者、実装者はどのような課題に直面しているのでしょうか。

以下に挙げた特徴と課題は、設計、開発、実装、使用の観点からではなく、全体的な観点から見たものです。

3.1. 特徴

技術の定義は、その技術が何をするのか、あるいは何をしようとしているのかを機能の形で検査することによっても行うことができます。 実装の観点から見たエンドツーエンド暗号化の特徴は、いくつかの重要なカテゴリーに分けて検討することができます。1) E2EE に必要な機能である真正性、機密性、完全性であり、2) 可用性、否認性、前方秘匿性、妥協後のセキュリティは E2EE システムを強化する機能である。

3.1.1. 必要な機能

真正性 受信者がメッセージを送った人が確実であり、送信者がメッセージを受け取った人が確実である場合、システムはメッセージの真正性を提供します。

機密性 システムは、送信者と意図した受信者だけがメッセージの平文を読むことができる場合、メッセージの機密性を提供します。

つまり、受信者は、受信したメッセージが送信者の意図した通りのものであることが保証されます。

3.1.2. オプション/望ましい機能

可用性 システムは、ユーザが望むときにメッセージを入手でき、複数のデバイスからメッセージを入手できる場合、高い可用性を提供します。

否認可能性 否認可能性は、メッセージ受信者を含むトランスクリプトの記録を持つ誰もが、通信の特定の参加者がメッセージを作成したことを暗号化して他人に証明できないことを保証します。 つまり、通信の参加者は、意図された当事者と通信していることを保証されなければなりませんが、この保証は他の当事者には証明できません。

前方秘匿性 前方秘匿性は、たとえ攻撃者がエンドポイントの1つを侵害したとしても、通信チャネル上で以前にキャプチャした暗号化されたデータをすべて復号化することを防ぐセキュリティ特性です。 前方秘匿性は通常、暗号化/復号鍵を更新することで達成され、古い鍵は定期的に削除されます。

危殆化後のセキュリティ 危殆化後のセキュリティは、エンドポイントの危殆化から回復する方法を保証しようとするセキュリティ特性です(結果として、危殆化後に送信された通信は、危殆化前と同じセキュリティ特性で保護されます)。 これは通常、暗号化/復号化鍵の導出にエフェメラル鍵交換を追加することで達成される。

3.2. 課題

先に、インターネットプロトコルの実装で想定される形式的な定義を用いて、エンドツーエンド暗号化を定義しました。 そして、「IETFは、人々のインターネットの設計、使用、管理の方法に影響を与える高品質で関連性の高い技術文書を作成する最先端の場」であることから、IETFにおけるエンドツーエンド暗号化技術の現在の展開は、その開発の最先端を示すものであると確信することができます。

以下に、エンドツーエンド暗号化システムのプロトコル設計者が現在直面している課題を、網羅的に、しかし漠然と要約したリストを示します。 言い換えれば、エンドツーエンド暗号化システムの目標を実現するためには、ユーザと実装者の両方のために(前のセクションを参照)、これらの問題に取り組まなければなりません。 このリストから外れている問題は、1) エンドツーエンド暗号化システムの目的を達成することを無視した、あるいは何もしない不必要な機能要求、あるいは 2) エンドツーエンド暗号化システムの目的に反したものである可能性が高いと考えられます。

公開鍵の検証は、ユーザが管理するのが非常に難しい。 両端の認証は、秘密の会話のために必要とされる。 したがって、公開鍵の検証の問題を解決することは、エンド・ツー・エンドの暗号化システムを設計する上で大きな関心事です。 いくつかのアプリケーションでは、アカウントのアイデンティティと鍵をバインドし、公開鍵の指紋情報に助けられて、ユーザがそれらの間の信頼関係を確立するようにしています。

ユーザーは、デバイス間でアプリケーションの使用をスムーズに切り替えたいと考えていますが、これはユーザーデータのセキュリティを犠牲にしています。 このように、エンドツーエンドの暗号化システムでは、アカウントIDの秘密鍵がエンドユーザの元のデバイスによって生成され保存され、秘密鍵を別のデバイスに移動させると、システムのエンドポイントの1つのセキュリティが危うくなるため、可用性の問題があります。

既存のプロトコルは、メタデータがコンテンツよりもはるかに機密性の高いものであることが多いにもかかわらず、メタデータの分析に対して脆弱です。 メタデータは、ワイヤを横切って移動する平文情報であり、エンドポイントのアカウント ID、タイムスタンプ、メッセージサイズなど、中央サーバが必要とする配信関連の詳細が含まれています。 メタデータを効率的に難読化することは困難です。

ユーザーはグループで通信する必要がありますが、公開鍵暗号に依存するエンドツーエンドの暗号化システムでは、スケールの大きな問題があります。

1つのメッセージだけが漏洩しても、ユーザーのデータ全体は安全であるべきです。 しかし、暗号化された通信では、現在のところ、前方秘匿か非同期通信のどちらかを選択しなければなりません。 これは、電子メールやRCSなどの非同期メッセージングにエンドツーエンドの暗号化を使用するアプリケーション設計に問題があります。

E2EEシステムのユーザーは、プレーンテキストから大容量ファイルまで、任意の媒体で通信できるはずですが、エンドツーエンド暗号化システムで同じリソースを安全に共有できるオープンプロトコルがないため、しばしばリソースの問題が発生します。 クライアントサイド、例えばエンドポイント、URL の展開スキャンのようなアクティビティ。

ユーザビリティへの配慮は、メッセージの読み取り状況、タイピングインジケータ、URL/リンクプレビューなどのセキュリティへの配慮と相反することがあります。

どのようなソフトウェアアプリケーションでも、メンテナンスや更新が特に時代遅れの暗号ライブラリのために悲惨な状態になる可能性がある場合には、導入が困難であることは有名です。

4. エンドユーザの期待

E2EE システムの正式な定義と特性は、通信セキュリティに関連していますが、包括的な脅威モデルからのものではなく、また、ユーザーが E2EE 通信に期待することについても言及していません。 このような状況下では、一部の E2EE 設計やアーキテクチャは、最終的に E2EE システムに対するユーザーの期待に反して動作する可能性があります。 GEC-EU] システム設計の中には、暗号化アルゴリズムの「数学」に直接違反するものはありませんが、E2EE _system_の他の重要な側面を暗示したり、弱めたりすることで、そのような設計をしているものもあります。

4.1. 会話は秘密

E2EEシステムで互いに話をしているユーザーは、彼らが何について話しているのかを知っている唯一の存在であるべきである[RFC7624]。 国際人権法で定義されているように、人々にはプライバシーの権利があり、デジタル通信を使用しているかどうか、あるいはフィールドを歩いているかどうかに関わらず、表現の自由と意見を持つ権利の中に、ささやく権利があると推測されています。

4.2. プロバイダーは信頼できる

信頼性は工学的な観点から厳密に定義することができますが、この文書の目的のために、インターネット・ソサエティのスタッフによる内部ワークショップに触発された「信頼性」の定義を選びました。

信頼できる システムは、ユーザーの期待に一貫して応えられるように、完全に回復力があり、信頼性があり、説明責任があり、安全である場合にのみ、完全に信頼できるものとなります。 信頼できる」の反対語は「信頼できない」です。

この定義は、その肯定的な側面と否定的な側面で完全である:それが何であるか、例えば "信頼に値する "と、それが何ではないか、例えばRFC7258では:"それらの当事者の合意なしで、当事者を通信する当事者の意図を裏切る行動"。 RFC7258]では

したがって、信頼できるエンドツーエンド暗号化通信システムとは、機密性と真正性を提供する機能が信頼できる場合に、第三者が通信内容にアクセスすることなく、機密性と真正性のある方法で相互に通信を行うために、2つ以上の当事者が必要とする機能のセットのことである。

4.3. 第三者によるアクセスが不可能な場合

詳細がどうであれ、第三者がメッセージの内容にアクセスするために使用される方法は、E2EE メッセージングに対するユーザーの期待に反します。 "これらのアクセス方法は、ユーザーのデバイス上でメッセージの内容をスキャンし、「メッセージが受信者に送信される前に、場合によっては送信後に、禁止されているコンテンツのデータベースと一致するかどうかをスキャンします」。 GEC-EU

メソッドが、エンドポイント間の暗号化されたチャネル上で送信されることを意図したプライベートな通信を、チャネルの機密性に正式に干渉することなく、受信者以外の当事者が利用できるようにする場合、そのメソッドは、そのセキュリティ特性の理解された期待に違反します。

4.4. パターン推論は最小化される

トラフィック・フィンガープリントや同型暗号化計算などの解析は、エンドユーザーに安全な通信を提供するという E2EE システムの目標の範囲外と考えるべきです。

このような分析方法は、E2EE システムの設計の外で、あるいは設計の一部として、第三者が機密性を意図した通信から推論を行うことを可能にします。 "サーバやそのプロバイダが直接アクセスすることで、プライベートなユーザデータをスキャンすることを可能にすることで、これらの方法を使用することは、"エンドツーエンドの暗号化通信システムのユーザのプライバシーへの期待を侵害するものとみなされるべきである "としています。GEC-EU

E2EE システムは、パターン推論を許可しないことでユーザーのプライバシーを重視するだけでなく、これらの技術の進歩を先取りした更なるイノベーションにより、メタデータやトレーサビリティ(強化されたメタデータ)の問題解決にも積極的に取り組むべきである。

4.5. E2EE システムが損なわれない

RFC3552では、インターネット脅威モデルについて、ユーザーは通信システム、特にE2EEシステムが危殆化していないことを期待できると仮定しています。 E2EE システムのユーザーは、機密会話へのフロントドア、バックドア、サイドドアの入り口を期待しておらず、プロバイダが技術的にも法的にも、これらの手段による妥協に積極的に抵抗することを期待していると思われます。

5. 結論

メッセージングからビデオ会議まで、安全で使いやすいE2EEシステムには多くの競合機能があります。 最もよく設計されたシステムであっても、すべてのユーザーの期待に応えることはできませんし、あらゆる面から理想的なシステムが存在するわけでもありません。 E2EEは、本書で定義されている理想を実現するために、常に改良を重ねている技術です。

E2EE システムの特徴や機能は、プライバシー保護のための通信に対するエンドユーザの期待に応えるために開発され、改善されるべきである。

6. 謝辞

Fred Baker、Stephen Farrell、Richard Barnes、Olaf Kolkman の全員が、この文書の初期の戦略的思考と、それが IETF コミュニティにとって有用かどうかに貢献してくれた。

Riseup と LEAP Encryption Access Project の人々は、エンドユーザの囁く権利に役立つエンドツーエンドの暗号化システムの最も難しい部分を見事に明快に表現してくれた。

Internet Society の Ryan Polk 氏は、Global Encryption Coalition の技術顧問のために、このような有意義な貢献を組織することに関しては、エネルギーに余裕があります。

7. セキュリティに関する考察

本草案は、情報文書に関するものであるため、セキュリティ上の配慮はない。

作成者以外のコメントは許可されていません