n エンドツーエンド暗号化 n エンドツーエンド暗号化における安全性要件 n エンドツーエンド暗号化に対する攻撃者モデル 2. Zoomのエンドツーエンド暗号化に対する安全性評価 n エンドツーエンド暗号化導⼊の背景 n プロトコル n 脆弱性,攻撃,攻撃の実⾏可能性,対策⼿法 3. エンドツーエンド暗号化SFrameに対する安全性評価 n SFrame導⼊の背景 n プロトコル n 脆弱性,攻撃,攻撃の実⾏可能性,対策⼿法
Zoom u Google Duo u Google Meet u Cisco Webex u Microsoft Teams u Skype u Jitsi Meet u Whereby u BlueJeans u GoToMeeting u ・・・など ビデオ会議システム 3 はじめに 教育,ビジネス,医療,・・・ 機密・プライバシー情報の保護
5 多くのメッセージアプリケーションやビデオ会議システムで採⽤ n Signal Protocol を採⽤ u WhatsApp, Facebook Messenger, Signal n Secure Frame (SFrame) を採⽤予定 u Google Duo, Cisco Webex, Jitsi Meet n 独⾃のプロトコルを採⽤ u iMessage (Apple), LINE, Zoom はじめに エンドツーエンド暗号化(E2EE) ビデオ会議システムの要件:リアルタイム性 n 課題:安全性要件とパフォーマンスを同時に満たすことが現状では困難
6 多くのメッセージアプリケーションやビデオ会議システムで採⽤ n Signal Protocol を採⽤ u WhatsApp, Facebook Messenger, Signal n Secure Frame (SFrame) を採⽤予定 u Google Duo, Cisco Webex, Jitsi Meet n 独⾃のプロトコルを採⽤ u iMessage (Apple), LINE, Zoom はじめに エンドツーエンド暗号化(E2EE) ビデオ会議システムの要件:リアルタイム性 n 課題:安全性要件とパフォーマンスを同時に満たすことが現状では困難
第2章:エンドツーエンド暗号化の⼀般的な定義 u 第3章:エンドツーエンド暗号化に求められる安全性要件 u 第4章:エンドユーザが期待するエンドツーエンド暗号化の機能 *https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition-02 (July 2021).
of recent interest in our encryption practices, we want to start by apologizing for the confusion we have caused by incorrectly suggesting that Zoom meetings were capable of using end-to-end encryption. […] 2020年4⽉1⽇:ZoomにE2EE機能が無いことを報告
published a draft cryptographic design for an end-to-end-encrypted video communications offering. […] In our commitment to remaining transparent and open as we build this end-to-end encryption offering, we have published our cryptographic design for peer review on Github. 2020年5⽉22⽇:E2EEのホワイトペーパー(バージョン1)公開
excited to announce that starting next week, Zoom’s end-to-end encryption (E2EE) offering will be available as a technical preview, which means we’re proactively soliciting feedback from users for the first 30 days.
n 1⽇当たりのアクティブユーザ数:約3億⼈以上(2020年4⽉現在) n E2EE導⼊計画の発表(2020年5⽉) u ホワイトペーパー*として仕様を公開 https://github.com/zoom/zoom-e2e-whitepaper u 4つのフェーズのうちフェーズ1を展開,1ヶ⽉の技術プレビュー(2020年10⽉) *2021年11⽉現在,最新版はVersion 3.2であるが,本講演では論⽂執筆時点で最新版のVersion 2.3.1を対象 Zoomのエンドツーエンド暗号化に対する安全性評価
結託者** 被害者** 1 なりすまし 能動的 L/P - L/P 2 なりすまし 受動的 I - L/P/O 3 なりすまし 能動的 I L/P L/P/O 4 なりすまし 能動的 O I , L L/P/O 5 なりすまし 能動的 O L L/P/O 6 なりすまし 能動的 O I O 7 改ざん 受動的 I - L/P 8 サービス拒否 受動的 I - P *能動的攻撃:ミーティングへの参加だけでなく,データの正常な送受信が可能 *受動的攻撃:攻撃を実⾏するも,データの正常な送受信は不可 **I(インサイダー):Zoomのサーバ・インフラ管理者 ** O(アウトサイダー):ミーティングへのアクセス権を有しないZoomユーザ ** P(参加者):ミーティングへのアクセス権を有するZoomユーザ ** L(リーダー):共有鍵の⽣成・配布,参加者の承認・排除の権限を有する参加者 具体的な攻撃⼿順,現実世界での実現可能性,攻撃に対する効果的な対策を提案 ü 6個の脆弱性 ü 8種類の攻撃 Zoomのエンドツーエンド暗号化に対する安全性評価
結託者** 被害者** 1 なりすまし 能動的 L/P - L/P 2 なりすまし 受動的 I - L/P/O 3 なりすまし 能動的 I L/P L/P/O 4 なりすまし 能動的 O I , L L/P/O 5 なりすまし 能動的 O L L/P/O 6 なりすまし 能動的 O I O 7 改ざん 受動的 I - L/P 8 サービス拒否 受動的 I - P *能動的攻撃:ミーティングへの参加だけでなく,データの正常な送受信が可能 *受動的攻撃:攻撃を実⾏するも,データの正常な送受信は不可 **I(インサイダー):Zoomのサーバ・インフラ管理者 ** O(アウトサイダー):ミーティングへのアクセス権を有しないZoomユーザ ** P(参加者):ミーティングへのアクセス権を有するZoomユーザ ** L(リーダー):共有鍵の⽣成・配布,参加者の承認・排除の権限を有する参加者 具体的な攻撃⼿順,現実世界での実現可能性,攻撃に対する効果的な対策を提案 設計者らの想定 n 参加者がインサイダーと結託することで別の参加者へのなりすまし可能 u インサイダーとの結託による攻撃は仕様上の制約事項と主張 設計者らの想定よりも強⼒な攻撃が可能 n インサイダーが結託なしで任意のユーザへなりすまし可能 u データの正常な送受信は不可(受動的攻撃) n インサイダーが参加者と結託することで任意のユーザへなりすまし可能 u データの正常な送受信も可能(能動的攻撃) Zoomのエンドツーエンド暗号化に対する安全性評価
n 2020年12⽉:ホワイトペーパーのバージョン更新(2.3.1 → 3) u 攻撃2−6について仕様上の制約事項であることを明記(フェーズ2で強化) u フェーズ2のメジャーアップデート,謝辞の追加 *https://hackerone.com/zoom?type=team Zoomのエンドツーエンド暗号化に対する安全性評価
結託者** 被害者** 1 なりすまし 能動的 L/P - L/P 2 なりすまし 受動的 I - L/P/O 3 なりすまし 能動的 I L/P L/P/O 4 なりすまし 能動的 O I , L L/P/O 5 なりすまし 能動的 O L L/P/O 6 なりすまし 能動的 O I O 7 改ざん 受動的 I - L/P 8 サービス拒否 受動的 I - P *能動的攻撃:ミーティングへの参加だけでなく,データの正常な送受信が可能 *受動的攻撃:攻撃を実⾏するも,データの正常な送受信は不可 **I(インサイダー):Zoomのサーバ・インフラ管理者 ** O(アウトサイダー):ミーティングへのアクセス権を有しないZoomユーザ ** P(参加者):ミーティングへのアクセス権を有するZoomユーザ ** L(リーダー):共有鍵の⽣成・配布,参加者の承認・排除の権限を有する参加者 具体的な攻撃⼿順,現実世界での実現可能性,攻撃に対する効果的な対策を提案 Zoomのエンドツーエンド暗号化に対する安全性評価 ü 6個の脆弱性 ü 8種類の攻撃
被害者:任意の参加者(リーダーも含む) n 攻撃⼿順: 1. 攻撃者がプロトコルに従って共有鍵 MK を⼊⼿ 2. コンテンツを暗号化し,被害者のメタ情報(送信者IDなど)を付加して送信 脆弱性1(エンティティ認証⽋如) ミーティングコンテンツに対するエンティティ認証の⽋如 Ø 共有鍵 MK による AES-GCM での暗号化:機密性,完全性はOK,真正性はNG 参加者 被害者 掲⽰板 MK MK リーダー MK ① ② ② ① ① Zoomのエンドツーエンド暗号化に対する安全性評価
被害者:任意の参加者(リーダーも含む) n 攻撃⼿順: 1. 攻撃者がプロトコルに従って共有鍵 MK を⼊⼿ 2. コンテンツを暗号化し,被害者のメタ情報(送信者IDなど)を付加して送信 脆弱性1(エンティティ認証⽋如) ミーティングコンテンツに対するエンティティ認証の⽋如 Ø 共有鍵 MK による AES-GCM での暗号化:機密性,完全性はOK,真正性はNG 参加者 被害者 掲⽰板 MK MK リーダー MK ① ② ② ① ① Zoomのエンドツーエンド暗号化に対する安全性評価
被害者:任意の参加者(リーダーも含む) n 攻撃⼿順: 1. 攻撃者がプロトコルに従って共有鍵 MK を⼊⼿ 2. コンテンツを暗号化し,被害者のメタ情報(送信者IDなど)を付加して送信 脆弱性1(エンティティ認証⽋如) ミーティングコンテンツに対するエンティティ認証の⽋如 Ø 共有鍵 MK による AES-GCM での暗号化:機密性,完全性はOK,真正性はNG 参加者 被害者 掲⽰板 MK MK リーダー MK ① ② ② ① ① Zoomのエンドツーエンド暗号化に対する安全性評価
被害者:任意の参加者(リーダーも含む) n 攻撃⼿順: 1. 攻撃者がプロトコルに従って共有鍵 MK を⼊⼿ 2. コンテンツを暗号化し,被害者のメタ情報(送信者IDなど)を付加して送信 脆弱性1(エンティティ認証⽋如) ミーティングコンテンツに対するエンティティ認証の⽋如 Ø 共有鍵 MK による AES-GCM での暗号化:機密性,完全性はOK,真正性はNG 参加者 被害者 掲⽰板 MK MK リーダー MK ① ② ② ① ① Zoomのエンドツーエンド暗号化に対する安全性評価
ユーザAがリーダーとなってZoomミーティングを主催 2. 攻撃⼿順に従い,Aがインサイダー⼜はアウトサイダーに対し,相⼿⽅のユー ザBにとって影響⼒のある⼈物Cになりすますよう指⽰ 3. Cがコンテンツを何も発信しなければ,BはCから無⾔の圧⼒をかけられている と感じ,Bにとって交渉が思い通りに進まない可能性が⼤ インサイダー リーダーA 参加者B ② ① ③ Zoomのエンドツーエンド暗号化に対する安全性評価 C
ユーザAがリーダーとなってZoomミーティングを主催 2. 攻撃⼿順に従い,Aがインサイダー⼜はアウトサイダーに対し,相⼿⽅のユー ザBにとって影響⼒のある⼈物Cになりすますよう指⽰ 3. Cがコンテンツを何も発信しなければ,BはCから無⾔の圧⼒をかけられている と感じ,Bにとって交渉が思い通りに進まない可能性が⼤ インサイダー リーダーA 参加者B ② ① ③ Zoomのエンドツーエンド暗号化に対する安全性評価 C
ユーザAがリーダーとなってZoomミーティングを主催 2. 攻撃⼿順に従い,Aがインサイダー⼜はアウトサイダーに対し,相⼿⽅のユー ザBにとって影響⼒のある⼈物Cになりすますよう指⽰ 3. Cがコンテンツを何も発信しなければ,BはCから無⾔の圧⼒をかけられている と感じ,Bにとって交渉が思い通りに進まない可能性が⼤ インサイダー リーダーA 参加者B ② ① ③ Zoomのエンドツーエンド暗号化に対する安全性評価 C
ユーザAがリーダーとなってZoomミーティングを主催 2. 攻撃⼿順に従い,Aがインサイダー⼜はアウトサイダーに対し,相⼿⽅のユー ザBにとって影響⼒のある⼈物Cになりすますよう指⽰ 3. Cがコンテンツを何も発信しなければ,BはCから無⾔の圧⼒をかけられている と感じ,Bにとって交渉が思い通りに進まない可能性が⼤ インサイダー リーダーA 参加者B ② ① ③ Zoomのエンドツーエンド暗号化に対する安全性評価 C
攻撃5の実現可能性:meetingUUIDの衝突 u 1⽇当たりアクティブユーザ数:約3億⼈以上(2020年4⽉現在) u 1セッション当たりのミーティング参加者:最⼤1000⼈ l 1年間で約226〜236セッション → 261回の試⾏(攻撃5)は現実的に困難 Zoomのエンドツーエンド暗号化に対する安全性評価 インサイダー リーダーA 参加者B ② ① ③ C
脆弱性2を悪⽤した(受動的)サービス拒否 n 攻撃者:インサイダー n 結託者:なし n 被害者:参加者D n 攻撃⼿順: 1. 被害者Dが SigD と pkD を掲⽰板に投稿 2. インサイダーが pkD を差し替え 3. リーダーによる署名の検証 → 検証に失敗 考察 n 実現可能性:参加者から依頼を受けてインサイダーが容易に実⾏可能 n 対策:掲⽰板の管理を第三者機関に委託,⼜は掲⽰板の内容を暗号化 インサイダー 掲⽰板 被害者D リーダー ① ② ③ Zoomのエンドツーエンド暗号化に対する安全性評価
脆弱性2を悪⽤した(受動的)サービス拒否 n 攻撃者:インサイダー n 結託者:なし n 被害者:参加者D n 攻撃⼿順: 1. 被害者Dが SigD と pkD を掲⽰板に投稿 2. インサイダーが pkD を差し替え 3. リーダーによる署名の検証 → 検証に失敗 考察 n 実現可能性:参加者から依頼を受けてインサイダーが容易に実⾏可能 n 対策:掲⽰板の管理を第三者機関に委託,⼜は掲⽰板の内容を暗号化 インサイダー 掲⽰板 被害者D リーダー ① ② ③ Zoomのエンドツーエンド暗号化に対する安全性評価
脆弱性2を悪⽤した(受動的)サービス拒否 n 攻撃者:インサイダー n 結託者:なし n 被害者:参加者D n 攻撃⼿順: 1. 被害者Dが SigD と pkD を掲⽰板に投稿 2. インサイダーが pkD を差し替え 3. リーダーによる署名の検証 → 検証に失敗 考察 n 実現可能性:参加者から依頼を受けてインサイダーが容易に実⾏可能 n 対策:掲⽰板の管理を第三者機関に委託,⼜は掲⽰板の内容を暗号化 インサイダー 掲⽰板 被害者D リーダー ① ② ③ Zoomのエンドツーエンド暗号化に対する安全性評価
脆弱性2を悪⽤した(受動的)サービス拒否 n 攻撃者:インサイダー n 結託者:なし n 被害者:参加者D n 攻撃⼿順: 1. 被害者Dが SigD と pkD を掲⽰板に投稿 2. インサイダーが pkD を差し替え 3. リーダーによる署名の検証 → 検証に失敗 考察 n 実現可能性:参加者から依頼を受けてインサイダーが容易に実⾏可能 n 対策:掲⽰板の管理を第三者機関に委託,⼜は掲⽰板の内容を暗号化 インサイダー 掲⽰板 被害者D リーダー ① ② ③ Zoomのエンドツーエンド暗号化に対する安全性評価
脆弱性2を悪⽤した(受動的)サービス拒否 n 攻撃者:インサイダー n 結託者:なし n 被害者:参加者D n 攻撃⼿順: 1. 被害者Dが SigD と pkD を掲⽰板に投稿 2. インサイダーが pkD を差し替え 3. リーダーによる署名の検証 → 検証に失敗 考察 n 実現可能性:参加者から依頼を受けてインサイダーが容易に実⾏可能 n 対策:掲⽰板の管理を第三者機関に委託,⼜は掲⽰板の内容を暗号化 インサイダー 掲⽰板 被害者D リーダー ① ② ③ Zoomのエンドツーエンド暗号化に対する安全性評価
脆弱性2を悪⽤した(受動的)サービス拒否 n 攻撃者:インサイダー n 結託者:なし n 被害者:参加者D n 攻撃⼿順: 1. 被害者Dが SigD と pkD を掲⽰板に投稿 2. インサイダーが pkD を差し替え 3. リーダーによる署名の検証 → 検証に失敗 考察 n 実現可能性:参加者から依頼を受けてインサイダーが容易に実⾏可能 n 対策:掲⽰板の管理を第三者機関に委託,⼜は掲⽰板の内容を暗号化 インサイダー 掲⽰板 被害者D リーダー ① ② ③ Zoomのエンドツーエンド暗号化に対する安全性評価
結託者** 被害者** 1 なりすまし 能動的 L/P - L/P 2 なりすまし 受動的 I - L/P/O 3 なりすまし 能動的 I L/P L/P/O 4 なりすまし 能動的 O I , L L/P/O 5 なりすまし 能動的 O L L/P/O 6 なりすまし 能動的 O I O 7 改ざん 受動的 I - L/P 8 サービス拒否 受動的 I - P *能動的攻撃:ミーティングへの参加だけでなく,データの正常な送受信が可能 *受動的攻撃:攻撃を実⾏するも,データの正常な送受信は不可 **I(インサイダー):Zoomのサーバ・インフラ管理者 ** O(アウトサイダー):ミーティングへのアクセス権を有しないZoomユーザ ** P(参加者):ミーティングへのアクセス権を有するZoomユーザ ** L(リーダー):共有鍵の⽣成・配布,参加者の承認・排除の権限を有する参加者 具体的な攻撃⼿順,現実世界での実現可能性,攻撃に対する効果的な対策を提案 ü 6個の脆弱性 ü 8種類の攻撃 Zoomのエンドツーエンド暗号化に対する安全性評価
n ブラウザ上においてサーバを介さない P2P (Pear to Pear) のリアルタイム通 信(⾳声,映像,チャット,データ,など)を実現するシステム n DTLS-SRTP*1,2を採⽤:Hop-by-Hop Encryption ※クライアント・サーバ間の暗号化通信 *1DTLS (Datagram Transport Layer Security): UDP上でセキュリティを実現するためのプロトコル *2RTP (Real-time Transport Protocol): インターネットでリアルタイムデータを転送するためにUDP上で動作するプロ トコル,DTLSと組み合わせることでSRTP (Secure RTP) となる. https://webrtcbydralex.com/index.php/2020/03/30/secure-frames-sframes-end-to-end-media-encryption-with-webrtc-now-in-chrome/ Encoded Media Alice Encoded Media Bob Encoded Media Hop-by-Hop Encryption Layer DTLS-SRTP Hop-by-Hop Encryption
n ブラウザ上においてサーバを介さない P2P (Pear to Pear) のリアルタイム通 信(⾳声,映像,チャット,データ,など)を実現するシステム n DTLS-SRTPを採⽤:Hop-by-Hop Encryption ※クライアント・サーバ間の暗号化通信 n メディアサーバ(SFU*1サーバ)を導⼊可 ※参加者増加に対応 *1SFU (Selective Forwarding Unit): サーバを経由して⾳声,映像の視聴者増加に伴う端末への負荷を軽減するもの https://webrtcbydralex.com/index.php/2020/03/30/secure-frames-sframes-end-to-end-media-encryption-with-webrtc-now-in-chrome/ DTLS-SRTP Hop-by-Hop Encryption Encoded Media Alice Encoded Media Bob Encoded Media Hop-by-Hop Encryption Layer Media Server Unencrypted Storage ! Inside Media Server No Encryption Layer
n ブラウザ上においてサーバを介さない P2P (Pear to Pear) のリアルタイム通 信(⾳声,映像,チャット,データ,など)を実現するシステム n DTLS-SRTPを採⽤:Hop-by-Hop Encryption ※クライアント・サーバ間の暗号化通信 n メディアサーバ(SFU*1サーバ)を導⼊可 ※参加者増加に対応 *1SFU (Selective Forwarding Unit): サーバを経由して⾳声,映像の視聴者増加に伴う端末への負荷を軽減するもの https://webrtcbydralex.com/index.php/2020/03/30/secure-frames-sframes-end-to-end-media-encryption-with-webrtc-now-in-chrome/ DTLS-SRTP Hop-by-Hop Encryption Encoded Media Alice Encoded Media Bob Encoded Media Hop-by-Hop Encryption Layer Media Server Unencrypted Storage ! Inside Media Server No Encryption Layer 問題点: DTLS-SRTPではメディアサーバにてコンテンツが復号される Ø 中間サーバが信頼できない場合,中間サーバがコンテンツにアクセスで きないような新しいスキームを準備する必要がある
WebRTC: Hop-by-Hop Encryption ※クライアント・サーバ間の暗号化通信 n SFrame: End-to-End (Media) Encryption https://webrtcbydralex.com/index.php/2020/03/30/secure-frames-sframes-end-to-end-media-encryption-with-webrtc-now-in-chrome/ DTLS-SRTP Hop-by-Hop Encryption Encoded Media Alice Encoded Media Bob Encoded Media Hop-by-Hop Encryption Layer Media Server Unencrypted Storage ? Inside Media Server E2EE Layer End-to-End Encryption User provided key
WebRTC: Hop-by-Hop Encryption ※クライアント・サーバ間の暗号化通信 n SFrame: End-to-End (Media) Encryption https://webrtcbydralex.com/index.php/2020/03/30/secure-frames-sframes-end-to-end-media-encryption-with-webrtc-now-in-chrome/ DTLS-SRTP Hop-by-Hop Encryption Encoded Media Alice Encoded Media Bob Encoded Media Hop-by-Hop Encryption Layer Media Server Unencrypted Storage ? Inside Media Server E2EE Layer End-to-End Encryption User provided key メディアサーバはサーバ機能を維持するために必要なメタデータのみアクセス可 Ø エンドユーザはサーバを信頼できない場合でも安全にコンテンツを送受信可
al. Secure Frame (SFrame). https://tools.ietf.org/html/draft-omara-sframe-03 (October 2021). リアルタイム通信⽤のE2EE技術 n 設計者:GoogleとCoSMo softwareのグループ n 仕様書:インターネットドラフト [OUGM21] u 暗号プロトコル:認証暗号,ハッシュ関数,署名アルゴリズム u 鍵交換プロトコル:Signal,Olm,MLSなどを利⽤ n 標準化動向 u 2020-05-19: draft-omara-sframe00 u 2020-11-16: draft-omara-sframe01 u 2021-03-29: draft-omara-sframe02 u 2021-09-17: draft-omara-sframe03 今ここ エンドツーエンド暗号化SFrameに対する安全性評価
n 仕様書:インターネットドラフト [OUGM21] u 暗号プロトコル:認証暗号,ハッシュ関数,署名アルゴリズム u 鍵交換プロトコル:Signal,Olm,MLSなどを利⽤ n 標準化動向 u 2020-05-19: draft-omara-sframe00 u 2020-11-16: draft-omara-sframe01 u 2021-03-29: draft-omara-sframe02 u 2021-09-17: draft-omara-sframe03 今ここ エンドツーエンド暗号化SFrameに対する安全性評価 評価対象はここ
タグ⻑ 1 AES_CM_128_HMAC_SHA256_8 16バイト 12バイト 8バイト 2 AES_CM_128_HMAC_SHA256_4 16バイト 12バイト 4バイト 3 AES_GCM_128_SHA256 16バイト 12バイト N/A 4 AES_GCM_256_SHA512 32バイト 12バイト N/A *CM: カウンタモード n 認証暗号 u AES-GCM,AES-CM-HMAC (AES-CTRとHMACの⼀般的構成) n ハッシュ関数 u SHA256,SHA512 n 署名アルゴリズム u EdDSA over Ed25519,ECDSA over P-521 u タグ(のリスト)に対して署名を計算 暗号スイート エンドツーエンド暗号化SFrameに対する安全性評価
Fast message franking: From invisible salamanders to encryptment. In CRYPTO 2018 短いタグを出⼒するAES-CM-HMACへの偽造攻撃 n 短いタグ⻑,特に4バイトのタグを出⼒するAES-CM-HMACを使⽤しない 任意⻑のタグを出⼒するAES-GCMへの偽造攻撃 n タグ(のリスト)だけでなくフレーム全体に対して署名を計算 短いタグを出⼒するAES-GCMへの認証鍵回復攻撃 n 短いタグを出⼒するAES-GCMを使⽤しない n NISTが⽰す制約事項を仕様に明記 その他 n HFC [DGRW18] のような安全なEncryptment⽅式を採⽤ エンドツーエンド暗号化SFrameに対する安全性評価