使用者在排定會議時選擇新的會議類型。 當准許參與者從大廳進入以及在會議期間時,主持人可以看到每個參與者的身分驗證狀態。 會議中的所有目前參與者都可以使用會議代碼來相互驗證。

與會議主持人共用以下資訊:

正在驗證身分

端對端身分驗證可為端對端加密會議提供額外的安全性。

當參與者或裝置加入共用的 MLS (Messaging Layer Security) 群組時,他們會向其他群組成員展示其憑證,然後針對核發的憑證授權單位 (CA) 驗證憑證。 CA 會確認憑證是否有效,以驗證參與者的身分,且會議將參與者/裝置顯示為已驗證。

Webex Meetings 應用程式的使用者會向 Webex 身分識別儲存庫驗證自己的身分,該儲存庫成功後會向使用者核發存取權杖。 如果他們需要憑證來驗證其在端對端加密會議中的身分,Webex CA 會根據存取權杖來向他們核發憑證。 我們尚未提供方法供 Webex Meetings 使用者取得協力廠商/外部 CA 核發的憑證。

裝置可以使用內部 (Webex) CA 核發的憑證或外部 CA 核發的憑證進行自我驗證:

  • 對於內部 CA 案例,Webex 會根據裝置的機器帳戶存取權杖來核發內部憑證。 憑證是由 Webex CA 簽署。 裝置的使用者 ID 與使用者的使用者 ID 不同,因此 Webex 在寫入裝置憑證的身分識別(一般名稱 (CN))時,會使用(其中一個)貴組織的網域。

  • 對於外部 CA 案例,您可以直接向您選擇的核發者請求及購買裝置憑證。 您必須使用只有您知道的密碼來加密、直接上傳及授權憑證。

    Cisco 不參與,這樣可確保實現真正的端對端加密和經過驗證的身分識別,並防止 Cisco 可能竊聽您的會議/解密您的媒體。

內部核發的裝置憑證

Webex 會在裝置啟動後,於註冊時向裝置核發憑證,並在必要時更新憑證。 對於裝置,憑證包括帳戶 ID 和網域。

如果貴組織沒有網域,則 Webex CA 會核發不含網域的憑證。

如果貴組織具有多個網域,您可以使用 Control Hub 告知 Webex 裝置用於其身分識別的網域。 您也可以使用 API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

如果您具有多個網域,且未設定裝置偏好的網域,則 Webex 會選擇一個網域供您使用。

外部核發的裝置憑證

管理員可以使用已向其中一個公用 CA 簽署的憑證來供應裝置。

憑證必須以 ECDSA P-256 金鑰組為基礎,但其可由 RSA 金鑰簽署。

憑證中的值由組織自行決定。 通用名稱 (CN) 和主體別名 (SAN) 將顯示在 Webex 會議使用者介面中,如 Webex Meetings 的身分驗證端對端加密中所述。

建議每個裝置使用個別的憑證,每個裝置具有唯一的 CN。 例如,針對擁有 「example.com」 網域的組織,此雲端為 「meeting-room-1.example.com」。

為了完全防止外部憑證遭到竄改,會使用用戶端密碼功能來加密和簽署各種 xcommand。

使用用戶端密碼時,可以透過 xAPI 安全地管理外部 Webex 身分憑證。 目前僅限線上裝置使用。

目前,Webex 提供用於管理此作業的 API 指令。

裝置

雲端註冊的 Webex Room 系列和 Webex Desk 系列裝置可以加入端對端加密會議,包括:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

下列裝置無法加入端對端加密會議:

  • Webex C 系列

  • Webex DX 系列

  • Webex EX 系列

  • Webex MX 系列

  • 協力廠商 SIP 裝置

軟體用戶端

  • 從 41.6 開始,Webex Meetings 桌面用戶端可以加入端對端加密會議。

  • 如果貴組織允許 Webex 應用程式透過啟動 Meetings 桌面應用程式來加入會議,則您可以使用該選項來加入端對端加密會議。

  • Webex 網路用戶端無法加入端對端加密會議。

  • 第三方 SIP 軟用戶端無法加入端對端加密會議。

身分

  • 我們未為您提供任何 Control Hub 選項來管理外部驗證的裝置身分。 此決定是取決於設計,因為對於真正的端對端加密,只有您應該瞭解/存取密碼和金鑰。 如果引進了雲端服務來管理這些金鑰,則系統可能會攔截這些金鑰。

  • 我們目前未提供任何工具來協助您請求或加密您的裝置身分憑證及其私密金鑰。 目前,我們向您提供了一個秘訣,用於根據產業標準的加密技術設計您自己的工具,以協助您完成這些程序。 我們不想對您的密碼或金鑰進行任何實際或感知的存取。

會議

  • 端對端加密的會議目前最多支援 200 個參與者。

  • 在 200 個參與者中,最多 25 個外部驗證的裝置可以加入,且他們必須是第一個加入會議的參與者

    當更多裝置加入會議時,我們的後端媒體服務會嘗試轉碼媒體串流。 如果我們無法解密、轉碼和重新加密媒體(因為我們沒有且不應該具有這些裝置加密金鑰),則轉碼失敗。

    為了減輕此限制,我們建議對裝置進行較小的會議,或者將裝置與 Meetings 用戶端之間的邀請交錯排列。

管理介面

強烈建議您使用 Control Hub 來管理您的會議網站。

這個的主要原因是 Control Hub 與網站管理管理身分識別方式的差異。 Control Hub 組織具有整個組織的集中式身分,而網站管理則根據網站對身分進行控制。

這表示您無法擁有針對從網站管理進行管理的使用者的 Cisco 驗證的驗證身分選項。 這些使用者會獲得匿名憑證以加入端對端加密會議,並且可能會從主持人想要確保身分的會議中排除這些使用者。

相關資訊

衍生範例 JWE Blob

根據給定參數正確加密的 JWE 範例(附錄)

  • Webex Meetings 41.7。

  • 雲端註冊 Webex Room 和 Webex Desk 系列裝置,執行中 10.6.1-RoomOS_August_2021

  • 在 Control Hub 中對會議網站的管理存取,以針對使用者啟用新的階段作業類型。

  • Control Hub 組織中一個或多個已驗證的網域(如果您使用 Webex CA 來為驗證身分核發裝置憑證)。

  • 必須開啟「共同合作會議室」,以讓人員可以從其視訊系統加入。 如需相關資訊,請參閱允許從視訊系統加入您的 Webex 網站上的 Webex 會議和活動

如果不需要外部驗證身分,您可以略過此步驟。

針對最高層級的安全性及身分驗證,每個裝置都應該具有由受信任公開憑證授權單位機構核發的唯一憑證。

您需要與 CA 互動,以請求、購買和接收數位憑證,以及建立關聯的私密金鑰。 當請求憑證時,這些參數是所使用的參數:

  • 憑證必須由知名的公開 CA 核發及簽署。

  • 獨特: 強烈建議針對每個裝置使用唯一憑證。 如果您將一個憑證用於所有裝置,則您將影響您的安全性。

  • 一般名稱 (CN) 與主體替代名稱 (SAN/s): 這些對於 Webex 而言很重要,但應該是人類可以讀取及關聯至裝置的值。 CN 將顯示給其他會議參與者作為裝置的主要已驗證身分,並且如果使用者透過會議 UI 檢查憑證,則他們將看到 SAN。 您可能想要使用的名稱類似 name.model@example.com 但這是您的選擇。

  • 檔案格式: 憑證和金鑰必須為 .pem 格式。

  • 目的: 憑證用途必須是 Webex 身分。

  • 正在產生金鑰: 憑證必須基於 ECDSA P-256 金鑰組(使用 P-256 曲線的橢圓形數位簽章演算法)。

    此要求不會延伸至簽署金鑰。 CA 可以使用 RSA 金鑰來簽署憑證。

如果您不想將外部驗證身分與裝置一起使用,則可以略過此步驟。

如果您在使用新裝置,請勿將其註冊至 Webex。 最安全的方式是甚至不將其連線到網路。

如果您已有要升級以使用外部驗證身分的裝置,您需要將裝置重設至出廠設定。

  • 若要保留現有設定,請加以儲存。

  • 當裝置不使用時排定時段,或使用分階段的方法。 通知使用者他們可以預期變更。

  • 確保對裝置進行實體存取。 如果您必須透過網路存取裝置,請注意密碼是以純文字方式傳輸,且您將會影響您的安全性。

完成這些步驟後,請允許從視訊系統加入您的 Webex 網站上的 Webex 會議和活動

若要確保您的裝置媒體無法被裝置以外的任何人員加密,您必須將裝置上的私密金鑰加密。 我們已為裝置設計 API,以使用 JSON 網路加密 (JWE) 來啟用加密金鑰和憑證的管理。

為了確保透過我們的雲端進行真正的端對端加密,我們無法涉及加密及上傳憑證和金鑰。 如果您需要此安全性層級,則為您已開啟 onus:

  • 請求您的憑證。

  • 產生憑證的金鑰組。

  • 為每個裝置建立(及保護)初始密碼,以植入裝置的加密功能。

  • 開發並維護您自己的工具,以使用 JWE 標準加密檔案。

    我們在下方說明您需要的程序和(非密碼)參數,以及在您所選擇開發工具中需遵循的秘訣。 我們還提供一些測試資料及如我們預期的結果 JWE Blob,來協助您驗證程序。

    Cisco 可應要求使用 Python3 和 JWCrypto 程式庫提供不支援的參考實作。

  • 使用工具及裝置的初始密碼串聯並加密憑證和金鑰。

  • 將結果 JWE Blob 上傳至裝置。

  • 設定要用於 Webex 身分識別加密憑證的目的,然後啟動憑證。

  • (建議)提供介面至(或分發)您的工具,讓裝置使用者變更初始密碼(保護您提供給他們的媒體!)。

如何使用 JWE 格式

本節說明我們預期如何將 JWE 建立為裝置輸入,以便您可以建立您自己的工具,以從憑證和金鑰建立 Blob。

您需要參閱 JSON 網路加密 (JWE)https://datatracker.ietf.org/doc/html/rfc7516JSON 網路簽章 (JWS)https://datatracker.ietf.org/doc/html/rfc7515

我們選擇使用 JSON 文件的精簡序列化來建立 JWE Blob。 建立 JWE Blob 時需要納入的參數包括:

  • JOSE 標頭(受保護)。 在 JSON 物件簽署和加密標頭中,您必須包含下列金鑰值組:

    • "alg":"dir"

      直接演算法是我們支援用於加密裝載的唯一演算法,且您必須使用裝置的初始用戶端密碼。

    • "enc":"A128GCM""enc":"A256GCM"

      我們支援這兩種加密演算法。

    • "cisco-action": "add""cisco-action": "populate""cisco-action": "activate""cisco-action": "deactivate"

      這是專屬金鑰,且可以使用四個值。 我們引進了此金鑰來向目標裝置發出加密資料用途的訊號。 這些值是以使用加密資料裝置上的 xAPI 指令命名。

      我們將其命名 cisco-action 以因未來的 JWE 擴充功能來減少潛在的災害。

    • "cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }

      另一個專屬金鑰。 我們使用您提供的值當做裝置上金鑰衍生的輸入。 該 version 必須為 1 (我們金鑰衍生功能的版本)。 值 salt 必須至少為 4 個位元組的 base64 URL 編碼序列,您 必須隨機選擇。

  • JWE 加密金鑰。 此欄位為空。 裝置衍生自初始 ClientSecret

  • JWE 初始化向量。 您必須提供 base64url 編碼的初始化向量以解密裝載。 IV 必須是隨機的 12 位元組值(我們使用的是 AES-GCM 加密系列,要求 IV 長度為 12 位元組)。

  • JWE AAD(其他已驗證的資料)。 您必須省略此欄位,因為其在精簡序列化中不受支援。

  • JWE 加密文字: 這是您想要保密的加密裝載。

    裝載可能為空(例如,若要重設用戶端密碼,您需要用空值加以覆寫)。

    存在不同類型的裝載,取決於您嘗試在裝置上執行什麼操作。 不同的 xAPI 指令預期不同的裝載,且您必須指定裝載的目的並使用 cisco-action 金鑰,如下所示:

    • 包含 "cisco-action":"populate" 加密文字是新的 ClientSecret

    • 包含「 "cisco-action":"add" 加密文字是 PEM Blob,可承載憑證及其私密金鑰(串聯)

    • 包含「 "cisco-action":"activate" 加密文字是我們正在啟動的裝置身分驗證的指紋憑證(sha-1 的十六進位表示法)

    • 包含「 "cisco-action":"deactivate" 加密文字是我們正在停用用於裝置身分驗證的指紋憑證(sha-1 的十六進位表示法)

  • JWE 驗證標籤: 此欄位包含驗證標籤,用於驗證 JWE 壓縮序列化 Blob 的完整性

我們如何將加密金鑰衍生自 ClientSecret

在填入第一個密碼之後,我們不接受或輸出純文字密碼。 這是為了防止可能會由可存取裝置的人員進行字典攻擊。

裝置軟體會使用用戶端密碼作為金鑰衍生功能 (kdf) 的輸入,然後使用衍生的金鑰在裝置上解密/加密。

這對您而言表示您產生 JWE Blob 的工具必須遵循相同的程序,從用戶端密碼衍生相同的加密/解密金鑰。

裝置會使用 scrypt 來金鑰衍生(請參閱 https://en.wikipedia.org/wiki/Scrypt),並包含以下參數:

  • CostFactor (N) 為 32768

  • BlockSizeFactor (r) 為 8

  • ParallelizationFactor (p) 為 1

  • Salt 是至少 4 位元組的隨機序列;您必須提供相同的內容 salt 當指定 cisco-kdf 參數。

  • 金鑰長度為 16 位元組(如果您選取 AES-GCM 128 演算法)或 32 位元組(如果您選取 AES-GCM 256 演算法)

  • 最大記憶體容量為 64MB

這組參數是裝置上唯一與金鑰衍生功能相容的 scrypt 設定。 裝置上的此 kdf 稱為 "version":"1" ,這是目前所採用的唯一版本 cisco-kdf 參數。

運作範例

您可以遵循以下範例來驗證您的 JWE 加密程序是否與我們在裝置上建立的程序相同。

範例情境是將 PEM Blob 新增至裝置(模仿使用極短字串而非完整的憑證 + 金鑰來新增憑證)。 範例中的用戶端密碼為 ossifrage

  1. 選擇加密密碼。 本範例使用 A128GCM (在 Galois 計數器模式中具有 128 位元金鑰的 AES)。 您的工具可以使用 A256GCM 若您需要。

  2. 選擇一個 salt(必須是至少 4 位元組的隨機序列)。 此範例使用(十六進位位元組) E5 E6 53 08 03 F8 33 F6 。 Base64url 將序列進行編碼以取得 5eZTCAP4M_Y (移除 base64 填補)。

  3. 以下是範例 scrypt 撥打以建立內容加密金鑰 (cek):

    cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

    衍生的金鑰應該為 16 位元組(十六進位),如下所示: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac base64url 編碼為 lZ66bdEiAQV4_mqdInj_rA

  4. 選擇隨機序列的 12 位元組,以用作初始化向量。 本範例使用(十六進位) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 base64url 編碼為 NLNd3V9Te68tkpWD

  5. 使用壓縮序列化建立 JOSE 標頭(遵循這裡所使用參數的相同順序),然後 base64url 將其進行編碼:

    {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

    base64url 編碼的 JOSE 標頭為 eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    這將成為 JWE Blob 的第一個元素。

  6. JWE Blob 的第二個元素為空,因為我們未提供 JWE 加密金鑰。

  7. JWE Blob 的第三個元素是初始化向量 NLNd3V9Te68tkpWD

  8. 使用 JWE 加密工具產生加密裝載和標籤。 在此範例中,未加密裝載將是假的 PEM Blob this is a PEM file

    您應該使用的加密參數為:

    • 有效負載為 this is a PEM file

    • 加密密碼為 AES 128 GCM

    • base64url 編碼的 JOSE 標頭為其他已驗證資料 (AAD)

    Base64url 對加密裝載進行編碼,應會導致 f5lLVuWNfKfmzYCo1YJfODhQ

    這是 JWE Blob 中的第四個元素(JWE 加密文字)。

  9. Base64url 會對您在步驟 8 中產生的標籤進行編碼,應該會導致 PE-wDFWGXFFBeo928cfZ1Q

    這是 JWE Blob 中的第五個元素。

  10. 使用點串聯 JWE Blob 的五個元素 (JOSEheader..IV.Ciphertext.Tag) 以取得:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. 如果您衍生了與這裡所顯示相同的 base64url 編碼值,則您可以使用您自己的工具來保護您裝置的 E2E 加密和經過驗證的身分。

  12. 此範例實際上不起作用,但原則上,您的下一步是使用您上面所建立的 JWE Blob 新增憑證的裝置上 xcommand 的輸入:

    xCommand Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

為零信任會議提供新的階段作業類型,這些階段作業類型將適用於所有會議網站,無需額外付費。 其中一個新的階段作業類型稱為 Pro-End to End Encryption_VOIPonly 。 這是我們將來可能會變更的 公用服務名稱。 有關目前階段作業類型的名稱,請參閱階段作業類型 ID(在此文章的參考部分中)。

您不需要執行任何操作來取得您網站的新功能,但是您需要將新的階段作業類型(也稱為會議特權)授予使用者。 您可以透過使用者的設定頁面個別執行此作業,或利用 CSV 匯出/匯入功能大量執行此作業。

1

登入 Control Hub 並開啟會議頁面。

2

按一下您的網站名稱以開啟網站的設定面板。

3

按一下設定網站

4

一般設定區域中,按一下階段作業類型

在該頁面上,您應該會看到一個或多個端對端加密階段作業類型。 請參閱階段作業類型 ID(在此文章的參考部分中)。 例如,您可能會看到 Pro-End to End Encryption_VOIPonly

 

存在名稱非常類似的較舊階段作業類型: Pro-End to End Encryption。 此階段作業類型包括會議的非加密 PSTN 存取。 確保您擁有 _VOIPonly 版本以確保進行端對端加密。 您可以將滑鼠移至階段作業代碼欄中的 PRO 連結上進行檢查;針對此範例,連結的目標應為 javascript:ShowFeature(652)

我們將來可能會為這些階段作業類型變更公用服務名稱,例如,我們計劃將 Pro-End to End Encryption_VOIPonly 變更為 E2E Encryption + Identity

5

如果您還沒有新的階段作業類型,請聯絡您的 Webex 代表。

後續動作

向部分或所有使用者啟用此階段作業類型/會議特權。

1

按一下使用者並選取使用者以開啟使用者的設定面板。

2

服務區域中,按一下 Cisco Webex Meetings

3

選取網站(如果使用者位於多個網站中)並按一下主持人

4

勾選標有 Pro-End to End Encryption_VOIPonly 的 Webex Meetings 項目旁的方塊。

5

關閉使用者設定面板。

6

如有必要,對其他使用者重複此步驟。

如果您想要將此指派給多個使用者,請使用 CSV 批量選項。

1

https://admin.webex.com 登入 Control Hub 並開啟會議頁面。

2

按一下您的網站名稱以開啟網站設定面板。

3

授權和使用者區段,按一下批量管理

4

按一下匯出,然後等待我們準備檔案。

5

檔案就緒後,依序按一下匯出結果下載。 (您必須在按一下下載後手動關閉該快顯視窗。)

6

開啟下載的 CSV 檔案進行編輯。

每個使用者都有一列,並且有 MeetingPrivilege 以逗號分隔的清單形式包含其階段作業類型 ID 的欄。

7

對於要授予新階段作業類型的每個使用者,請新增 1561 作為逗號分隔清單中的新值,位於 MeetingPrivilege 儲存格。

Cisco Webex CSV 檔案格式參考檔案包含 CSV 檔案用途和內容的相關詳細資料。

8

在 Control Hub 中開啟會議網站設定面板。


 

如果您已經在會議網站清單頁面上,可能需要將其重新整理。

9

授權和使用者區段,按一下批量管理

10

按一下匯入並選取已編輯的 CSV,然後按一下匯入。 檔案上傳時請稍候。

11

當完成輸入時,您可以按一下匯入結果來檢查是否有任何錯誤。

12

前往使用者頁面並開啟其中一個使用者,以驗證他們具有新的階段作業類型。

如果您的裝置已上線至 Control Hub 組織,且您想要使用 Webex CA 來自動產生其識別憑證,則不需要將裝置重設出廠設定。

此程序會選取裝置用於自行識別的網域,且僅在您 Control Hub 組織中具有多個網域時才需要。 如果您具有多個網域,建議您針對具有「Cisco 驗證」身分的所有裝置執行此操作。 如果您未告知 Webex 哪個網域會識別裝置,我們將選擇其中一個裝置,但其他會議參與者可能會看到錯誤。

在開始之前

如果您的裝置尚未上線,您可以遵循使用 API 或本地 Web 介面向 Cisco Webex 註冊裝置雲端上線裝置。 您還應該驗證您要用來在管理您的裝置中識別裝置的網域。

1

登入 Control Hub (https://admin.webex.com) 並開啟裝置頁面。

2

選取裝置以開啟其設定面板。

3

選取要用於識別此裝置的網域。

4

對於其他裝置重複上述步驟。

在開始之前

您需要:

  • 若要取得每個裝置的 CA 簽署憑證和私密金鑰(.pem 格式)。

  • 若要閱讀瞭解裝置的外部身分識別程序的主題,請參閱本文的準備部分。

  • 準備關於其資訊的 JWE 加密工具。

  • 用於產生給定長度隨機位元組序列的工具。

  • 用於 base64url 編碼位元組或文字的工具。

  • 一個 scrypt 實作。

  • 每個裝置的密碼文字或片語。

1

填入裝置的 ClientSecret 使用純文字密碼:

第一次填入 Secret ,以純文字提供。 這就是我們建議您在實體裝置主控台上執行此操作的原因。

  1. Base64url 會編碼此裝置的密碼片語。

  2. 開啟裝置上的 TShell。

  3. 執行 xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    上面的範例指令會填入 Secret 使用片語 0123456789abcdef 。 您需要選擇您自己的密碼。

裝置具有其初始密碼。 請勿忘記這一點,您無法將其復原,且必須恢復裝置出廠設定才能再次啟動。
2

串聯您的憑證和私密金鑰:

  1. 使用文字編輯器、開啟 .pem 檔案、貼上金鑰 Blob、憑證 Blob,然後將其儲存為新的 .pem 檔案。

    (這是您將加密並放入 JWE Blob 中的裝載文字)

3

建立 JWE Blob 以用作憑證新增指令的輸入:

  1. 建立至少 4 位元的隨機序列。 這是您的 salt。

  2. 使用 scrypt 工具衍生內容加密金鑰。

    為此,您需要密碼、salt 和金鑰長度,以與您選擇的加密 cipher 相符。 需要提供一些其他固定的值(N=32768、r=8、p=1)。 裝置會使用相同的程序和值來衍生相同的內容加密金鑰。

  3. 建立整整 12 位元的隨機序列。 這是您的初始化向量。

  4. 建立 JOSE 標頭,設定 algenccisco-kdf 金鑰,如 瞭解裝置的外部身分識別程序中所述。 使用 key:value 設定「新增」動作 "cisco-action":"add" 在 JOSE 標頭中(因為我們將憑證新增至裝置)。

  5. Base64url 對 JOSE 標頭進行編碼。

  6. 使用包含所選加密的 JWE 加密工具及 base64url 編碼的 JOSE 標頭,從串聯的 pem 檔案加密文字。

  7. Base64url 會編碼初始化向量、加密的 PEM 裝載及驗證標籤。

  8. 以如下方式建構 JWE Blob(所有值都經過 base64url 編碼):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

在裝置上開啟 TShell,然後執行(多行)新增指令:

xcommand Security Certificates Services Add IsEncrypted: True
your..JWE.str.ing\n
.\n
5

驗證是否透過以下操作新增憑證: xcommand Security Certificates Services Show

複製新憑證的指紋。

6

為以下目的啟動憑證: WebexIdentity

  1. 從憑證本身或輸出讀取憑證的指紋 xcommand Security Certificates Services Show

  2. 建立至少 4 位元的隨機序列,然後對該序列進行 base64url 編碼。 這是您的 salt。

  3. 使用 scrypt 工具衍生內容加密金鑰。

    為此,您需要密碼、salt 和金鑰長度,以與您選擇的加密 cipher 相符。 需要提供一些其他固定的值(N=32768、r=8、p=1)。 裝置會使用相同的程序和值來衍生相同的內容加密金鑰。

  4. 建立整整 12 位元的隨機序列,然後對該序列進行 base64url 編碼。 這是您的初始化向量。

  5. 建立 JOSE 標頭,設定 algenccisco-kdf 金鑰,如 瞭解裝置的外部身分識別程序中所述。 使用 key:value 設定「啟動」動作 "cisco-action":"activate" 在 JOSE 標頭中(因為我們將啟動裝置上的憑證)。

  6. Base64url 對 JOSE 標頭進行編碼。

  7. 使用包含所選加密的 JWE 加密工具及 base64url 編碼的 JOSE 標頭,以加密憑證指紋。

    該工具應該輸出 16 或 32 位元組序列,取決於您選擇 128 或 256 位元 AES-GCM 及驗證標籤。

  8. Base64urlencode 加密的指紋和驗證標籤。

  9. 以如下方式建構 JWE Blob(所有值都經過 base64url 編碼):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. 在裝置上開啟 TShell,然後執行下列啟動指令:

    xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
裝置具有加密的、使用中、CA 核發的憑證,可供在端對端加密的 Webex 會議中識別。
7

將裝置上線至 Control Hub 組織。

1

排定正確類型 (Webex Meetings Pro-End to End Encryption_VOIPonly) 的會議。

2

從 Webex Meetings 用戶端以主持人身分加入會議。

3

從已由 Webex CA 驗證其身分的裝置加入會議。

4

請以主持人身分驗證此裝置是否出現在大廳中,並標有正確的身分圖示。

5

從已由外部 CA 驗證其身分的裝置加入會議。

6

請以主持人身分驗證此裝置是否出現在大廳中,並標有正確的身分圖示。 進一步瞭解身分識別圖示

7

以未驗證的會議參與者身分加入會議。

8

請以主持人身分驗證此參與者是否出現在大廳中,並標有正確的身分圖示。

9

請以主持人身分准許或拒絕人員/裝置。

10

檢查憑證,以盡可能驗證參與者/裝置身分。

11

檢查會議中的每個人員是否都看到相同的會議安全代碼。

12

加入有新參與者的會議。

13

檢查每個人員是否看到相同的新會議安全代碼。

要將端對端加密的會議指定為預設會議選項,還是僅對部分使用者啟用它,或是允許所有主持人決定? 當您決定要如何使用此功能時,請將要使用此功能的使用者準備就緒,尤其是關於限制和會議預期內容。

您需要確保 Cisco 及任何其他任何人員都無法解密您的內容或模仿您的裝置嗎? 如果是,您需要來自公用 CA 的憑證。 在安全會議內,您最多只能擁有 25 個裝置。 如果您需要此層級的安全性,則應該不允許會議用戶端加入。

對於使用安全裝置加入的使用者,請讓裝置先加入,並設定使用者在加入較晚時可能無法加入的預期。

如果您有不同層級的身分驗證,可讓使用者以憑證支援的身分和會議安全代碼相互驗證。 即使在某些情況下參與者可能顯示為未驗證,而參與者應該瞭解如何檢查,但未經驗證的人員可能不是頂替者。

若是使用外部 CA 來核發裝置憑證,則您可利用 onus 來監視、重新整理及重新申請憑證。

如果您建立了初始密碼,請瞭解您的使用者可能想要變更其裝置密碼。 您可能需要建立介面/分發工具,以允許他們執行此操作。

即將推出。

表 1. 端對端加密會議的階段作業類型 ID

階段作業類型 ID

公用服務名稱

638

僅 E2E 加密+VoIP 加密

652

Pro-End to End Encryption_VOIPonly

660

Pro 3 Free-End to End Encryption_VOIPonly

E2E 加密 + 身分

672

Pro 3 Free50-End to End Encryption_VOIPonly

673

Education Instructor E2E Encryption_VOIPonly

676

Broadworks Standard 加端對端加密

677

Broadworks Premium 加端對端加密

681

Schoology Free 加端對端加密

這些表格描述了我們針對端對端加密會議和已驗證身分新增的 Webex 裝置 API 指令。 如需進一步瞭解如何使用 API,請參閱存取 Webex Room 裝置、Webex Desk 裝置和 Webex Board 的 API

表 2. 用於端對端加密會議和已驗證身分的系統層級 API

API 呼叫

說明

xConfiguration Conference EndToEndEncryption Mode: On

變成端對端加密模式 OnOff

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

當管理員從 Control Hub 設定裝置偏好的網域時,會進行此設定。 只有在組織具有多個網域時才為必需。

當裝置從 Webex CA 請求憑證時,會使用此網域。 網域隨後會識別裝置。

當裝置具有主動的、外部核發憑證進行自行識別時,此設定不適用。

xStatus Conference EndToEndEncryption Availability

指出裝置是否可加入端對端加密會議。 雲端 API 會呼叫它,以便配對的應用程式得知是否可以使用裝置來加入。

xStatus Conference EndToEndEncryption ExternalIdentity Valid

指出裝置是否具有有效的外部核發憑證。

xStatus Conference EndToEndEncryption ExternalIdentity Identity

從外部核發憑證的一般名稱讀取的裝置身分。

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

從外部核發的憑證讀取憑證資訊,並將其做為 JSON Blob 輸出。

xStatus Conference EndToEndEncryption InternalIdentity Valid

指出裝置是否具有由 Webex CA 核發的有效憑證。

xStatus Conference EndToEndEncryption InternalIdentity Identity

從 Webex 核發憑證的一般名稱讀取的裝置身分。

包含網域名稱(如果組織具有網域)。

如果組織沒有網域,則為空白。

如果裝置在具有多個網域的組織中,則此值來自 PreferredDomain

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

從 Webex 核發的憑證讀取憑證資訊,並將其做為 JSON Blob 輸出。

表 3. 用於端對端加密會議和已驗證身分的通話中 API

API 呼叫

說明

xStatus Call # ServerEncryption Type

讀取 HTTPS 與 Webex 連線中使用的加密密碼。 此資訊會向使用者顯示。

xStatus Conference Call # EndToEndEncryption Status

讀取通話端對端加密狀態。 以呈現(或隱藏)掛鎖圖示向使用者顯示。

xStatus Conference Call # EndToEndEncryption SecurityCode

讀取會議的安全代碼。 這會向使用者顯示,且在參與者加入時變更。

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

讀取媒體連線中使用的加密密碼。 此資訊會向使用者顯示。

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

讀取用於傳訊層安全性 (MLS) 的加密密碼。

xStatus Conference Call # EndToEndEncryption Roster Participant

列出在此會議中為 MLS 群組狀態做貢獻的參與者。 清單是由 MLS 而非 Webex 找到。

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

指定參與者的 WDM URL。

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

指定參與者的驗證狀態。

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

指定參與者的主要身分,通常是網域(裝置)或電子郵件地址(使用者)。

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

指定參與者的顯示名稱。 由參與者/裝置簽署。

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

指定參與者憑證中的憑證資訊為 JSON Blob。

xCommand Conference ParticipantList Search

我們延伸了此指令,以包含參與者的端對端加密資訊。

xCommand Conference ParticipantList Search

參與者清單搜尋現在包括 EndToEndEncryptionStatus ,參與者的身分驗證狀態。 此值會顯示在 UI 中。

xCommand Conference ParticipantList Search

參與者清單搜尋現在包括 EndToEndEncryptionIdentity ,參與者的主要身分。 這通常是網域或電子郵件地址。 此值會顯示在 UI 中。

xCommand Conference ParticipantList Search

參與者清單搜尋現在包括 EndToEndEncryptionCertInfo ,包含參與者憑證的 JSON Blob。 此值會顯示在 UI 中。

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

這三個活動現在包括 EndToEndEncryptionStatusEndToEndEncryptionIdentityEndToEndEncryptionCertInfo 為受影響的參與者。

表 4. 用於端對端加密會議和已驗證身分的 ClientSecret 相關 API

API 呼叫

說明

xCommand Security ClientSecret Populate Secret: "base64url-encoded"xCommand Security ClientSecret Populate Secret: JWEblob

接受 base64url 編碼的純文字值,用於第一次在裝置上植入用戶端密碼。

若要在第一次之後更新密碼,您必須提供包含由舊密碼加密的新密碼的 JWE Blob。

xCommand Security Certificates Services Add JWEblob

新增憑證(使用私密金鑰)。

我們延伸了此指令,以接受包含加密 PEM 資料的 JWE Blob。

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

啟動 WebexIdentity 的特定憑證。 對於此 Purpose ,該指令要求在 JWE Blob 中對識別指紋加密並序列化。

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

停用 WebexIdentity 的特定憑證。 對於此 Purpose ,該指令要求在 JWE Blob 中對識別指紋加密並序列化。