真ん中に誰もいないとき
サーバーを通過するデータを暗号化することは内容を保護します。真ん中にサーバーを置かないことは、その問題を排除します。これらは同じではありません。
2人の人間、1つの会話
部屋で二人が面と向かって話しているとき、他の誰も何も聞いていないと約束する必要はありません。その場にいなかったから聞こえなかったのです。二人が手から手へ紙切れを渡すとき、間にいる誰かがそれを読んでいないと誓う必要はありません。間には誰もいないからです。
日常生活のほとんどの事柄はこのように機能しています。私たちは、声を伝える空気や、手に持っている紙と秘密保持契約を結ぶことはありません。会話のプライバシーは仲介者の約束の上に成り立っているわけではありません。仲介者が存在しないからです。これはプライバシーを守る上で最も強力な形の1つです。何かや誰かが行儀良く振る舞うからではなく、何かや誰かが存在しないからです。
会話がデジタルチャネルに移行すると、これはデフォルトで変わります。通常のモデルは次の通りです。2人がサーバーに接続し、サーバーがメッセージを受け取り、暗号化するか暗号化して保存し、受信者に届けます。サーバーが真ん中にいます。サーバーは誠実かもしれません。監査されているかもしれません。有利な管轄区域で、厳格なプライバシーポリシーの下で運営されているかもしれません。これらすべてが真実かもしれません。しかし、サーバーは真ん中にいるのです。
暗号化と収集しないことの違い(第2部)
同シリーズの以前の記事で、コンテンツを暗号化することとメタデータを収集しないことは同じではないと主張しました。さらにもう一歩踏み込んで明確にするべきことがあります。サーバーを通過するデータを暗号化することと、サーバーを持たないことも同じではないということです。
最初のモデル、つまり中間にサーバーがありコンテンツが暗号化されるモデルは、サーバーの運営者、保守担当者、システムを侵害する外部の攻撃者からコンテンツを保護します。そしてそれは重要です。しかし、サーバーを排除するわけではありません。サーバーはそこにあり、メタデータを処理し、裁判所の命令、法的介入、政治的圧力、またはセキュリティ侵害にさらされています。結局のところ、依然として誰かに信頼を置く必要があるポイントなのです。
両端の間にサーバーがない2番目のモデルは、暗号化されたコンテンツをより良く保護するわけではありません。暗号化が堅牢であれば、どちらのケースでもコンテンツは保護されます。変わるのは質問そのものです。「サーバーはどうなるのか?」という質問は対象を失います。質問するべきサーバーが存在しないからです。
信頼、不在、そして両者の違い
信頼は正しく置かれるかもしれません。誠実な企業は存在します。厳格な監査人も存在します。ユーザーに有利な法律も存在します。上記すべてを厳格に遵守する真面目なサービスも存在します。それに値する事業者に与えられる信頼は、悪い取り決めではありません。
しかし、どれほど強固であっても、信頼は信頼に過ぎません。それは社会的解決策であり、技術的解決策ではありません。企業は所有者が変わる可能性があり、管轄区域は政府が変わる可能性があり、裁判所の命令が明日届く可能性があり、新しい脆弱性が来月発見される可能性があります。これらのどれも悪意から起こるわけではありません。運営者が存在し、存在するすべてのものは世界の中の不測の事態に服するため起こるのです。
事業者が存在しないことは、同じ不測の事態にさらされません。裁判所命令は、存在しないサーバーにデータを要求することはできません。攻撃者は存在しないサーバーを侵害することはできません。企業のポリシー変更は、企業が一度も持ったことのないデータに影響を与えることはできません。重要なフレーズは単純です。存在しないデータは失われることはありません。
サーバー側の正当な主張について
真ん中にサーバーがあるプロフェッショナルなメッセージングサービスを提供する事業者は、通常、完全に有効な3つの主張を展開します。第1に、受信者がオフラインのときに配信を保証するためにサーバーが必要であること。第2に、コンテンツの暗号化は強力であり、したがって事業者はそれを読むことができないこと。第3に、サービスはヨーロッパの法律に準拠しており、データは法律によって保護されていること。
3つの主張はすべて真実です。どれも事の本質を変えるものではありません。遅延配信のためにサーバーがメッセージを保存できることは事実です。また、遅延配信が数十年にわたって改良され今日運用されている、デバイス間の直接通信プロトコルによって別の方法で解決できることも事実です。真面目なサービスでは、通信中のコンテンツの暗号化が強力であることは事実です。そして、ヨーロッパの法律が他の多くの場所よりもユーザーを保護しているのも事実です。
問題は、真ん中にサーバーがあるサービスが合法かどうか、安全かどうか、コンテンツを保護するかどうかではありません。それらはそうであり得ますし、合法であり、通常は安全です。問題は、真ん中にサーバーを持つことはアーキテクチャ上の選択であり、技術的な制約ではないということです。そして、すべての選択には結果が伴います。真ん中にサーバーがあるアーキテクチャは、信頼しなければならない行為者を必然的に生み出します。真ん中にサーバーがないアーキテクチャでは、そうなりません。
法律が言うこと、アーキテクチャがすること
GDPRは特定のアーキテクチャモデルを要求していません。データ最小化、目的制限、データ保護・バイ・デザインおよびデフォルト、コンプライアンスを証明する能力といった結果を要求しています。真ん中にサーバーがあるサービスは、これらすべての要件を満たすことができます。真ん中にサーバーがないサービスは、宣言によってではなく、その構造そのものによってそれらのいくつかを満たします。絶対的な最小化、つまりメッセージを配信するために厳密に必要なもの以外は何も収集しないことは、何かを収集できるサーバーが存在しない場合には些細なことです。
日常の機密性の高くない用途では、サーバーアーキテクチャは完全に合理的であり、真面目な事業者を信頼することは有効な取り決めです。その他の用途、つまり法規制に基づく職業上の秘密を伴うもの、倫理的責任を伴うもの、特に機密性の高い情報を扱うものについては、信頼の拠点が欠如していることは贅沢ではなく、構造的な利点です。
不要な証人
最初の部屋に戻ることで、考えを定着させることができます。誰も会話を聞いていなかったというのは、証人が行儀よく振る舞ったかどうかに依存するのではなく、証人がいなかったということに依存します。中間に位置するサーバーは、誠実で、監査され、GDPRのすべての条項を遵守していても、やはり証人であることに変わりはありません。職業上の秘密を扱う者にとって、本当に重要な質問は、その証人が信頼に値するかどうかではなく、その部屋にいる必要があったかどうかです。
今日存在するほとんどのプロフェッショナル向けメッセージングサービスにおける答えは、必要なかった — それでもそこにあった、というものです。
この記事で Cuadernos Lacre の初期サイクルは終了します。暗号化、メタデータ、職業上の秘密について話した後、私たちはアーキテクチャの全体像を完成させました。コンテンツを暗号化することと、真ん中にサーバーを持たないことは別のことです。どちらも合法かもしれませんが、信頼の起点を排除するのは後者だけです。
参考文献および関連資料
- Saltzer, J. H.; Reed, D. P.; Clark, D. D. — End-to-end arguments in system design, ACM TOCS, 1984。システムの保証は中間のチャネルではなく、末端で実装されなければならないという原則の基礎的文献。
- 規則 (EU) 2016/679 第25条 — データ保護・バイ・デザインおよびデフォルト。
- 規則 (EU) 2016/679 第5条1項(c) — データ最小化の原則。
- Schneier, B. — Data and Goliath: the hidden battles to collect your data and control your world (2015), W. W. Norton。設計によってデータ収集を最小限に抑えるアーキテクチャに関する章。