Definition of End-to-end Encryption
voluntas
DeepL 翻訳
最新はこちら
voluntas抄録
エンドツーエンド暗号化（E2EE）は、エンドポイント間の通信システムにおける暗号化技術の応用です。 E2EEシステムは、ユーザーに機密性、完全性、および真正性の機能を提供するという点でユニークです。 E2EEの改良は、ユーザビリティと可用性のバランスをとりながら、システムのセキュリティを最大化することを目指しています。 E2EE通信のユーザーは、安全な実装を提供する信頼できるプロバイダーが、ユーザーのささやきの権利を尊重し、保護することを期待しています。
voluntas1. 序章
この文書では、さまざまな文脈で適用可能な E2EE の完全な定義を構成する 3 つの異なる次元を用いて、エンドツーエンド暗号化（E2EE）を定義する。
最初の定義は、エンドポイントと暗号化の基本的な理解に基づいた形式的な定義である。 第二に、E2EE システムを設計の観点から見た場合の基本的な特徴と、それらの特徴を改善するための方向性について考察します。 最後に、E2EEシステムのユーザーが期待することを考察します。
これらの次元を全体として見ると、メッセージングからビデオ会議まで、アプリケーションを問わず、またエンドポイントの数を問わず、エンドツーエンドの暗号化とは何かについて、IETFでのコンセンサスは一般的に理解しやすいものとなっています。
voluntas2. エンド・ツー・エンド暗号化の正式な定義
エンド・ツー・エンドの暗号化通信システムは、その内容や採用されている特定の方法に関わらず、2つの重要かつ厳密な技術的概念に依存しています。エンド・ツー・エンドの原則は、インターネット・プロトコルにとって重要であることからIETFで定義されています。また、暗号化は、暗号技術の応用であり、インターネット・プロトコルを保護するためにIETFが採用している主要な手段です。
2.1. エンドポイント
直感的には、「エンド」はメッセージを送信するか受信するか、通常はその両方を行います。
しかし、エンドポイントの存在は、本質的に通信システムの少なくとも1つの他のエンティティに依存しているため、単独でエンドポイントの定義を確立することは容易ではありません。 このため、次のサブセクションでは、ニュアンスの異なるエンド・ツー・エンドの原則の説明に直接入ります。
しかし、技術者にとってのニュアンスはともかく、通信システム自体がユーザーに始まり、ユーザーに終わることは広く受け入れられています[RFC8890]。 私たちは、サブシステムの設計において、（アプリケーションのユーザー・インターフェイス、またはユーザー・エージェントを介して）人々をコンポーネントとして想像します。 E2EEシステムでの重要な例外は、公開鍵基盤の使用かもしれません。ここでは、大規模なシステムの信頼モデルを強化するために、認証段階で第三者が使用されることがよくあります。
ユーザーエージェントとユーザーを同一視することはできませんが、両者を完全に分離することもできません。 ユーザーエージェントのコンピューティングがより複雑になり、しばしばよりプロプライエタリになると、ユーザーエージェントはユーザーの利益を最大限に擁護する「代弁者」ではなくなります。 これが、後のセクションで、e2ee システムがユーザの期待に応えることができるかどうかに焦点を当てる理由です。
2.2. エンド・ツー・エンドの原則
エンド・ツー・エンド原則[RFC3724]を検討する上で重要な問題である「何がエンドを構成するのか」に、まず答える必要がありました。 しかし、エンドポイントの概念は、エンド・ツー・エンド通信の原則の中でより完全に定義されています。
1984年、分散型コンピュータシステムのモジュール間で機能を配置する際の指針となる設計原理として、「end-to-end argument」が紹介されました[saltzer]。 これは、システムの低レベルに配置された機能は、その低レベルで機能を提供するためのコストと比較すると、冗長であったり、価値が低かったりすることを示唆している。 これは、システムのどの部分がどのような決定を行うべきかという問題を回避するために使用され、そのため、実際の「話し手」や「終わり」のアイデンティティは、見た目よりも明らかではないかもしれません。 Saltzer氏が説明する通信は、同じ物理的なマシン上にあるかどうかに関わらず、通信するプロセス間で行われ、様々な方法で実装されます。 例えば、BGP スピーカーは、ルーティング情報ベース（RIB）を管理するプロセスとして実装されることが多く、TCP を実装したオペレーティング・システム・サービスを使用して他の BGP スピーカーと通信します。 RIBマネージャは、ピアにアドバタイズすべきプレフィックスをRIBで検索し、それぞれのプレフィックスに対してTCPへの「書き込み」を行うことがあります。 この場合のTCPは、RFC868に記載されているアルゴリズム（「Nagleアルゴリズム」）の変形を実装していることが多く、通信相手との間で飛行中のデータがなくなるまでバッファに書き込みを蓄積し、その後送信するというものですが、これはRIBマネージャが1回検索する間に数回発生する可能性があります。 その意味では、RIBマネージャーは、何を通信すべきかを決定するので、「端」と考えられるかもしれませんし、TCPは、実際にTCPセグメントを送信し、エラーが発生すればそれを検出し、必要であれば再送信し、最終的にセグメントが正常に転送されたことを決定するので、「端」と考えられるかもしれません。
もう1つの重要な問題は、「エンド・ツー・エンドの原則を正確に要約した文は何か」ということだ。 サルツァーはこれに2つの方法で答えている。1つ目は、トランザクションを実装するサービスは、メッセージを送信したアプリケーションの意図を実装する場合に最も正しいというもので、それは関連するIPヘッダーの宛先アドレスに向かってメッセージを移動させることである。 しかし、Salzerの方がより徹底しているのは、実装時に出てくるエンドケースを扱っていることだ。"アブストラクトによれば、「この論文で議論されている例」は、「ビットエラーの回復、暗号化によるセキュリティ、重複メッセージの抑制、システムクラッシュからの回復、配信確認など」です。 また、最適化のためにエンド・ツー・エンドの議論を無視する根拠が存在することもあるとしています。 以下に説明するように、エンド・ツー・エンドの議論とのバランスをとる必要のある、他のユーザーの期待や設計上の特徴があるかもしれません。
2.3. 暗号化
draft-dkg-hrpc-glossary-00 によると、暗号化はエンド・ツー・エンドの原則の基本です。 "エンド・ツー・エンド : プロトコルやシステムの特性を、システム内で可能な限り拡張するという原則。 例えば、エンド・ツー・エンドでインスタントメッセージを暗号化すると、あるユーザーのインスタントメッセージングアプリケーションから、中間デバイスやサーバーを経由して、受信者のインスタントメッセージングアプリケーションに至るまで、通信内容を隠すことができます。 もしメッセージがサービスプロバイダなどの中間地点で復号された場合、エンド・ツー・エンドの暗号化の特性は存在しません」[dkg] これは通信の内容についてのみ述べており、そこから生成されたメタデータについては触れていないことに注意してください。
真のエンド・ツー・エンドの通信システムを実現するには、エンドポイント（送信者と受信者）の間で交換されるデータのコンテンツを暗号化する必要があります。 エンド・ツー・エンドの暗号化技術としては、ダブルラチェットアルゴリズムと認証された暗号化スキームを使用するのが一般的で、IETF Messaging Layer Securityワーキンググループで検討されているものなど、最新のメッセンジャーアプリケーションの多くに採用されています。 openpgp]どちらのプロトコルも非対称・対称暗号を使用しており、エンドポイント間で公開鍵を交換する必要があります。
RFCシリーズには、暗号化方式を基本的かつ技術的に定義した数多くの文書があります。 この種の既存の文書をすべて調査して、それらの共通の特徴を定義することは、興味深い作業となるでしょう。 重要なのは、IETFはインターネットの暗号化通信の仕様を定義する上で、明確な権限と実証された専門性を持っているということです。
voluntas3. エンドツーエンドの暗号化システムの設計
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/リンクプレビューなどのセキュリティへの配慮と相反することがあります。
どのようなソフトウェアアプリケーションでも、メンテナンスや更新が特に時代遅れの暗号ライブラリのために悲惨な状態になる可能性がある場合には、導入が困難であることは有名です。
voluntas4. エンドユーザの期待
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 システムのユーザーは、機密会話へのフロントドア、バックドア、サイドドアの入り口を期待しておらず、プロバイダが技術的にも法的にも、これらの手段による妥協に積極的に抵抗することを期待していると思われます。
voluntas5. 結論
メッセージングからビデオ会議まで、安全で使いやすいE2EEシステムには多くの競合機能があります。 最もよく設計されたシステムであっても、すべてのユーザーの期待に応えることはできませんし、あらゆる面から理想的なシステムが存在するわけでもありません。 E2EEは、本書で定義されている理想を実現するために、常に改良を重ねている技術です。
E2EE システムの特徴や機能は、プライバシー保護のための通信に対するエンドユーザの期待に応えるために開発され、改善されるべきである。
voluntas6. 謝辞
Fred Baker、Stephen Farrell、Richard Barnes、Olaf Kolkman の全員が、この文書の初期の戦略的思考と、それが IETF コミュニティにとって有用かどうかに貢献してくれた。
Riseup と LEAP Encryption Access Project の人々は、エンドユーザの囁く権利に役立つエンドツーエンドの暗号化システムの最も難しい部分を見事に明快に表現してくれた。
Internet Society の Ryan Polk 氏は、Global Encryption Coalition の技術顧問のために、このような有意義な貢献を組織することに関しては、エネルギーに余裕があります。
voluntas7. セキュリティに関する考察
本草案は、情報文書に関するものであるため、セキュリティ上の配慮はない。