感謝您的意見回饋。

全球數百萬使用者依賴 Webex 進行安全協作。 從企業董事會會議室和政府立法會議到敏感的醫生與患者諮詢，Webex 是一個可信賴的關鍵通訊平台。

隨著對遠端工作的需求增加，對強大、機密的協作工具的需求也越來越多。 Webex 已滿足此需求的時間比任何其他供應商更長。 隨著 AI 支援的模擬和複雜的 deepfake 威脅的興起，對身份驗證、政策驅動的協作的要求是至關重要的。 對於我們的客戶來說，安全性不僅僅僅是一項功能，它是整個會議生命週期的整合組成部分，包括排程、參與者身份和內容保護。

Webex 在支援強大的端對端加密 (E2EE) 方面擁有悠久的歷史。 我們的 Webex 零信任安全模型通過三個主要支柱來發展這種傳統：

• 建立基於標準的正式驗證的密碼學基礎
• 透過端對端驗證身份增強端對端加密
• 將支援延伸至目前的 Webex 裝置以及 Webex 應用程式

本技術文件提供了端對端安全的背景，並列出了 WebExZero 信任安全如何運作的技術基礎。 有關會議作業安全性，例如會議階段類型、排程會議與個人會議室之間的安全性差異、管理員和主持人控制項、會議內容共享和保留以及會議體驗中的更廣泛 AI 和 deepfake 彈性，請參閱附屬的 WSMP 會議安全技術文件。

提供 E2E 安全性的 18 年歷史

Webex 於 2008 年開創會議的 E2E 加密技術。 根據定義，E2E 安全性可確保內容從發送的那一刻到收件人顯示為止被加密，從而防止雲提供商或任何第三方訪問或偽造數據。

視訊會議供應商對 E2E 安全機制所做的投資而定，它們可以提供不同級別的保護，如圖 1 所示。 任何 E2E 安全性都比僅在傳輸中和靜止時加密更好。

保護等級	網絡攻擊者	被動攻擊（竊聽）	主動攻擊（模仿）	範例
傳輸和靜止時加密	是	否	否	非 E2EE 應用程式
E2E 加密	是	是	否	舊版 E2EE 和消費者應用程式
E2E 加密和 E2E 身份	是	是	是	Webex 零信任安全性

大多數聲稱提供 E2E 安全性的應用程序僅提供防止被動攻擊。 只有被動的保護仍然很有價值，因為它們使壞者只能在會議進行中的時候竊聽。 然而，最好的方法是防止被動和主動攻擊，這些情況下會議提供商本身可能會假裝是合法參與者來參加會議。 為此，除了 E2E 加密之外，還需要 E2E 身分層。

借助零信任安全性，Webex 為會議帶來更強大的密碼學，並使用端對端驗證身份增強端對端加密，以幫助保護會議免受全方位攻擊的侵害。

在深入研究技術細節之前，了解用戶體驗很有幫助。 若要建立 E2E 加密的會議，主持人在 Webex 應用程式中排程期間選取適當的會議類型 (圖 2)。

參與者加入時，他們會看到一個「帶鎖的屏蔽」圖標，指出會議是 E2E 加密的（圖 3）。 點選此圖示可提供有關會議保護的詳細資訊。

最後，在會議參與者清單中，Webex 應用程式會指出參與者的身份是否已經以 E2E-Secure 方式驗證，也就是說，Cisco 以外的人是否已保證參與者的身份（圖 4）。

參與者還可以檢查他們是否擁有相同的安全代碼，以確認他們都有相同的會議視圖，因此受到冒充攻擊的安全性。 在使用客戶提供的端對端身分證書的部署中，名單狀態提供身分保證的透明度。

零信任安全基於業界標準的加密協定，思科正與其他安全和隱私領域的領導者（包括 Google、Cloudflare、Wickr 和 Wire）一起推動。 思科採用安全即時通訊協定 (SRTP)、DTLS-SRTP、STIR/SHAKEN 和 WebRTC 等技術領導第一代安全 IP 語音 (VoIP)，而思科也在零信任安全性方面執行相同的工作（圖 5）。

層	今天	零信任安全
身份	存取權限（SAML，開放 ID）	X.509 憑證
金鑰交換	SDES/DTLS	訊息層安全性 (MLS)
媒體加密	SRTP	安全框架（SFrame）

系統基本上有三個層，在每個層中，我們都採用舊的 hop-by-hop 技術，並通過額外的端到端層保護來加強它。 三個層包括：

• 身份識別 — E2E 身分要求用戶端具有證明其身份的憑證。 使用零信任 E2E 身份，客戶的認證由 Webex 獨立提供。Certificate Authority
• 金鑰交換 — 參與 E2E 會議的用戶端需要設定 E2E 加密金鑰，而會議提供者無法存取這些金鑰。 訊息層安全性 (MLS) 通訊協定是一項已核准的標準 RFC 9420，該標準基於開放原始碼社群開發的技術，並將它們置於嚴格、正式驗證的環境中。
• 內容保護 — 最後，會議的實際媒體內容需要端對端保護。 SFrame（用於「安全框架」）是 RFC 9605。 它是一個快速簡單的加密框架，用於加密即時媒體，允許添加額外的加密層，以最小的負擔。

讓我們從下而上開始更詳細地看看這些技術。

媒體加密方案是一種取得會議中參與者共用的金鑰，並使用它來保護會議中共享的實際內容，例如音訊、視訊和螢幕共用。 在協議層級上，加密方案需要與每個加密數據單位傳送額外的信息，最重要的是：

1. 一個標頭，告訴接收器如何解密封包，以及
2. 接收器用來驗證封包沒有被偽造的驗證標籤。

例如，在 SRTP 中，加密單位是 RTP 封包；SRTP 依賴 RTP 標頭進行設定，並將驗證標籤附加到封包的末尾。

由於所有這些額外的信息都會增加 E2E 加密會議所需的頻寬，因此 sFrame 提供了所需的最少數量的框架。 SFrame 標頭指示應使用哪個鍵，允許按鍵旋轉，並提供定義初始化向量的唯一序號。 接下來是使用 E2E 金鑰加密的內容和身份驗證標籤。 然後將 sFrame 標頭、內容和標籤包裝在 SRTP 封包中，以便 SRTP 防止網路攻擊者檢查或修改，而 SFrame 可防止會議提供者的媒體元素（請參閱圖 6 中的範例）。

這種簡約方法還有其他好處。 SFrame 獨立於基礎傳輸，因此它與 QUIC 和 RIPT 的 RTP 等新興技術相容。 也可以配置 sFrame，使其適用於多封包單元（例如整個框架），以進一步降低加密費用。

當群組只能存取不受信任的頻道時，在群組中設置秘密金鑰似乎很神奇。 做到這一點的技術首次在 1980 年代開發，如今，超過 90% 的網頁瀏覽使用傳輸層安全性 (TLS) 來完成這一點。 訊息層安全性 (MLS) 將此功能擴展到群組，而 TLS 僅可以點對點工作，因此即使會議提供者不受信任，Webex 也可以使用 MLS 來設定會議金鑰。

MLS 提供三項重要的安全性功能：

1. 共用金鑰-只有已驗證的群組成員才知道金鑰。
2. 一致性-確保所有成員對群組名單都有一致的檢視。
3. 旋轉-當成員加入或離開時，自動更新金鑰。

第一個功能為我們提供了用於使用 SFrame 加密媒體的密鑰。 與第二個功能一起，它提供了 E2E 身分的起點。 第三項功能可確保只有可以解密媒體的人才是目前參加會議的人，您無法解密您加入前或離開（或被趕出）之後的媒體。

為了完成所有這一點，會議中的用戶端在會議的關鍵點交換 MLS 訊息，以維護一個 MLS 群組，該群組完全包含在任何時間點會議中的參與者。 Webex 在用戶端之間路由郵件，但 MLS 會保護這些郵件，以便 Webex 可以安全地處理它們。 圖 7 顯示了訊息的流動方式。

建立：第一個加入會議的人，無論是否主持，都會建立會議的 MLS 群組，並成為 MLS 用途的「領導者」。 在任何給定時間點，會議中的單一參與者都被指定為領導者。 在大多數情況下，這位參與者將是會議主持人。 一旦會話開始，MLS 會確保每個會議參與者都擁有可作為領導者的密碼資訊；Webex 只需指定一個領導者，以避免混亂。

加入：當新參與者想加入會議時，他們會透過傳送 MLS 金鑰套件訊息給領導者，該訊息會提供他們的公開金鑰和驗證資訊來要求被允許進入。 領導者會以一則歡迎訊息來回應，該訊息告訴合作員會議中的其他參與者。 領導者還會將新增訊息和提交訊息傳送給群組。 「新增」訊息會向已經在會議中的人通知新連接器。 「提交」訊息會導致所有目前的參與者對舊群組金鑰進行雜湊，以取得現在擴充的群組的新金鑰；歡迎訊息會為連接者提供此金鑰。

離開：當有人離開會議時，領導者的工作是鎖定他們出門。 領導者通過將 MLS 移除和提交訊息傳送給會議中剩餘的所有人來執行此操作。 「移除」訊息會告訴其餘參與者離開的參與者，而「提交」會將新金鑰加密給所有剩餘的參與者，但不會對離開的人員進行加密。 其餘的參與者使用舊的群組密鑰對新密鑰進行哈希，以獲取離開的人沒有的密鑰。 如果離開的參與者是領導者，則 Webex 會指定新的領導者，而新的領導者則會移除舊的領導者。

金鑰旋轉可能意味著加入會議或移除某人需要幾秒鐘的時間，但它可以提供明確的安全保證：如果某人沒有出現在會議的參與者清單中，他們就沒有解密內容的密鑰。

E2E 加密會議中的參與者清單會顯示每個使用者的身分驗證。 使用客戶發行的身分證書可以提供真正的 E2E 驗證身份，這意味著 Cisco 無法偽造它。 在這些情況下，參與者清單以藍色文字顯示參與者所屬的網域。 例如，在 [圖 8] 所示的會議中，您可以看到 Kevin 擁有來自 example.com 的驗證電子郵件地址，而 Isabella 有來自 company.com 的驗證電子郵件地址。

由 Webex 發行的身分證書 (Certificate Authority例如視訊裝置身分) 提供更有限的保護。 只有破壞 Webex 的攻擊者才Certificate Authority能模擬使用者。 儘管這比完全沒有身份保護更好，但會議中的這些參與者並不會以藍色標記為零信任端對端身份驗證。 它們會以灰色文字顯示，以表示 Webex 信任身份驗證。

作為這些程序的後盾，Webex 還為會議提供安全性代碼。 安全程式碼是一個簡短、人類可讀的字串，以 MLS 程序的輸出來計算。 安全性代碼總結會議的加密狀態，包括群組的金鑰和參與者所提供的憑證。 此程式碼可用於偵測模擬攻擊，因為這種攻擊會導致至少一位參與者的加密狀態與其他人不同。 但是，只有在每個人驗證他們具有相同的代碼時，它才能排除模仿。 如果某些參與者的子集驗證他們具有相同的代碼，他們就知道他們的身份是否忠實地彼此表示，但沒有確認其代碼的人可能已被模擬。 圖 9 顯示安全性代碼在會議中如何顯示的範例。

此代碼提供了非常強大的防禦模擬攻擊。 它是 MLS 協議的一部分，因此它已經進行了強大的安全分析。 由於它與會議狀態緊密綁定，因此每次有人加入會議時，安全性代碼都會變更。 因此，每次有人加入會議時，會議的參與者都需要重新驗證其安全代碼。 當有人離開時代碼不會旋轉，因為離開無法引入模擬者。

Webex 零信任安全性於 2021 年推出。 2026 年，超安全 Webex 會議推出了對 E2E 加密 Webex 會議中的其他端點支援、具備視訊網格節點 (VMN) 的完整功能零信任 E2EE 會議，以及標準會議的端對端加密和身分功能：

• 基於標準的，正式驗證的密碼學
• 零信任 E2E 加密
• 零信任 E2E 驗證身份
• 支援所有可供出售的 Webex 裝置
• 支援桌上型電腦、行動裝置和網頁上的 Webex 應用程式
• 支援 Webex 網頁應用程式和網頁開發套件 (預計於第二季度第二季度)
• 支持Webex Calling手機（計劃於第 3CY26 年度）
• 支援視訊網格節點
• 支援預約會議和個人會議室中的 E2E 加密

零信任有一些限制。 E2E 加密會議不支援：

• Cisco 雲端服務所提供的功能需要存取純文字媒體，包括：
  • Webex 雲端記錄和AI Assistant服務。 這些服務可以使用與視訊網格節點 (VMN) 的混合部署來提供。
  • 儲存會議聊天、檔案、白板和註釋。
  • PSTN 或 SIP 互通性。

未來，Webex 將在幾個維度上改進 E2E 加密會議，以授予雲端最少必要的權限並讓客戶控制其數據的原則。

無處不在的 E2E 安全性：一切都應該是 E2E 安全的，而不僅僅僅是特定會議。 實現這個願景的第一步是透過為 Webex 和雲端連線的思科手機提供 E2E 安全Web App性。 最終，開放的基於標準的 E2E 架構應該使 Webex 也能夠引入工作階段啟動通訊協定 (SIP) 基礎架構。

本文中討論的創新顯示了通往永久使用的 E2E 加密長期願景的明確路徑。 一旦用戶可以從任何地方連接並且客戶可以安全地選擇他們在會議中使用他們想要的功能，就可以在每個 Webex 會議中使用 E2E 加密，從啟用所有功能的非正式臨機會議，到鎖定的高安全性會議。 E2E 加密將始終確保會議內容僅供授權的參與者使用，客戶和使用者將決定哪些參與者組合適合給定會議。

採用 AI 模擬和深度假的彈性

Webex 透過與零信任端對端加密模型相符的分層方法來解決啟用 AI 模擬威脅。 雖然本文專注於端對端驗證身分的技術基礎，包括客戶提供的憑證型驗證和會議加密完整性檢查，Webex 還在會議體驗中提供操作安全控制，以降低未經授權存取和有害互動的風險。

有關會議階段類型、排程會議與個人會議室安全性差異、Control Hub 中的主持人和管理員控制，以及更廣泛的會議體驗中的額外 AI 和深入假偵測和防範，請參閱附屬的 WSMP 會議安全技術文件。

Webex 正在通過基於標準的密碼和驗證的身分來定義安全會議的未來。 對開放生態系統的承諾可確保客戶保持對其數據的絕對控制，無論會議情況如何。