使用者在排定會議時可以選擇會議類型。從大廳以及會議期間准許參加者時,主持人可以看到每個參加者的身分驗證狀態。還有一個會議代碼供會議中的所有目前參加者共用,他們可使用此代碼來驗證其會議是否已被不需要的第三方「中間人」(MITM) 攻擊攔截。

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

驗證身分

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

當參加者或裝置加入共用的 MLS(傳訊層安全性)群組時,他們將其憑證提供給其他群組成員,然後由其他群組成員根據發行的憑證授權單位 (CA) 驗證憑證。透過確認憑證有效,CA 會驗證參加者的身分,並且會議將參加者/裝置顯示為已驗證。

Webex應用程式使用者根據Webex身分儲存區進行自我驗證,該儲存區在驗證成功時向他們發出存取權杖。如果他們需要憑證來在端對端加密會議中驗證其身分, Webex CA 會根據其存取權杖向他們核發憑證。目前,我們不向Webex Meetings使用者提供獲取由第三方/外部 CA 核發的憑證的方法。

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

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

  • 外部 CA — 直接從您選擇的發行商處申請和購買裝置憑證。您必須使用只有您知道的密碼來加密、直接上傳及授權憑證。

    Cisco不參與其中,從而確保真正的端對端加密和已驗證的身分,並防止Cisco可能會竊聽您的會議/解密您的媒體。

內部核發的裝置憑證

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

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

如果貴組織具有多個網域,您可以使用 Control Hub 告知 Webex 裝置用於其身分識別的網域。您還可以使用API x配置會議 EndToEndEncryption 身分偏好網域:「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 系列裝置可以加入 E2EE 會議:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

下列裝置無法加入 E2EE 會議:

  • Webex C 系列

  • Webex DX 系列

  • Webex EX 系列

  • Webex MX 系列

  • 協力廠商 SIP 裝置

軟體用戶端

  • 桌面版和行動版Webex應用程式用戶端可以加入 E2EE 會議。

  • Webex Web 用戶端無法加入 E2EE 會議。

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

身分

  • 根據設計,我們不提供 Control Hub 選項來管理經過外部驗證的裝置身分。對於真正的端對端加密,只有您應該知道/存取密碼和金鑰。如果引進了雲端服務來管理這些金鑰,則系統可能會攔截這些金鑰。

  • 目前,我們提供了一個「配方」,可讓您設計您自己的工具(基於工業標準加密技術),以協助您請求或加密您的裝置身分憑證及其私密金鑰。我們不想對您的密碼或金鑰進行任何實際或感知的存取。

會議

  • E2EE 會議目前最多支援 1000 個參加者。

  • 您可以在 E2EE 會議中共用新的白板。與常規會議中的白板有一些差異:
    • 在 E2EE 會議中,使用者無法存取在會議之外建立的白板,包括私人白板、由其他人共用的白板,以及來自Webex空間的白板。
    • 在 E2EE 會議中建立的白板僅在會議期間可用。會議將不會儲存,且在會議結束後無法存取。
    • 如果有人在 E2EE 會議中共用內容,您可以對其進行註解。有關註解的更多資訊,請參閱Webex應用程式| 使用註解來標記共用內容

管理介面

強烈建議您使用 Control Hub 來管理您的 Meetings 網站,因為 Control Hub 組織具有整個組織的集中式身分識別。

  • Webex Meetings 41.7。

  • 雲端註冊的Webex Room 和Webex Desk 系列裝置,執行中10.6.1-RoomOS_一個ugust_2021 年

  • 對 Control Hub 中的會議位置的管理存取權。

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

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

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

為了獲得最高級別的安全性和身分驗證,每個裝置都應具有由受信任的公開憑證授權單位(CA) 核發的唯一憑證。

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

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

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

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

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

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

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

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

若您不希望將外部驗證身分用於裝置,則可以跳過此步驟。

如果您在使用新裝置,請勿將其註冊至 Webex。為了安全起見,此時請勿將它們連線至網路。

如果現有裝置要升級以使用外部驗證的身分,則必須將裝置恢復原廠設定。

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

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

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

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

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

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

  1. 請求您的憑證。

  2. 產生憑證的金鑰組。

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

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

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

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

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

  6. 將結果 JWE Blob 上傳至裝置。

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

  8. (推薦)提供您的工具的介面(或分發)以使裝置使用者能夠變更初始密碼並保護他們的媒體不受您的侵害。

如何使用 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」:「目錄」

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

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

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

    • "cisco-action": "新增""cisco-action": "填入""cisco-action": "啟用""cisco-action": "停用"

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

      我們將其命名cisco-action 以減輕與未來的 JWE 擴充功能的潛在衝突。

    • "cisco-kdf": { "version": "1", "salt": "base64URLEncodeRandom4+字節" }

      另一個專屬金鑰。我們使用您提供的值當做裝置上金鑰衍生的輸入。的版本 必須是1 (我們的金鑰推導功能的版本)。的值 必須是至少 4 個字節的 base64 URL編碼序列,您可以必須 隨機選擇。

  • JWE 加密金鑰。此欄位為空。該裝置從初始的用戶端機密

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

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

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

    有效荷載可能為空。例如,若要重設用戶端密碼,您需要使用空值來覆寫它。

    存在不同類型的裝載,取決於您嘗試在裝置上執行什麼操作。不同的 xAPI 指令預期不同的有效荷載,您必須使用下列字元指定有效荷載的用途: cisco-action 鍵,如下所示:

    • "cisco-action":"填入" 密文是新的用戶端機密

    • 有了 " "cisco-action":"新增" 密文是帶有憑證及其私密金鑰(串聯)的 PEM Blob。

    • 有了 " "cisco-action":"啟用" 密文是我們為裝置身分驗證而啟動的憑證的指紋(sha-1 的十六進製表示)。

    • 有了 " "cisco-action":"停用" 密文是我們要停用的憑證的指紋(sha-1 的十六進製表示),以免其用於裝置身分驗證。

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

我們如何從用戶端機密

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

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

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

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

  • CostFactor (N) 為 32768

  • BlockSizeFactor (r) 為 8

  • ParallelizationFactor (p) 為 1

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

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

  • 最大記憶體容量為 64MB

這組參數是裝置上唯一與金鑰衍生功能相容的 scrypt 設定。裝置上的這個 kdf 稱為「版本」:「1」 ,這是目前使用的唯一版本思科-kdf 參數。

運作範例

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

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

  1. 選擇加密密碼。此範例使用A128GCM (在伽羅瓦計數器模式中使用 128 位元金鑰的AES )。您的工具可以使用A256GCM 如果您願意。

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

  3. 這是一個範例scrypt 建立內容加密金鑰(cek) 的呼叫:

    cek=scrypt(密碼="ossifage",鹽 = 4 字節序列,N = 32768,r = 8,p = 1,密鑰長度 = 16)

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

  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這是 PEM 檔案

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

    • 有效荷載現為這是 PEM 檔案

    • 加密密碼為 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 安全性憑證新增 eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

所有會議網站都可免費使用零信任會議的階段作業類型。其中一種階段作業類型稱為Pro-End to End Encryption_純 VOIP 。這是公開服務名稱,我們可能在將來變更。有關目前階段作業類型的名稱,請參閱階段作業類型 ID(在此文章的參考部分中)。

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

1

登入 Control Hub,然後轉至服務 > 會議

2

按一下網站,選擇您要變更其設定的 Webex 網站,然後按一下設定

3

通用設定下,選取階段作業類型

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

存在名稱非常類似的較舊階段作業類型:專業的端對端加密。此階段作業類型包括會議的非加密 PSTN 存取。請確保您有_純 VOIP 版本,以確保端對端加密。您可以將滑鼠移至PRO 課程代碼欄中的鏈結;對於此範例,鏈結的目標應該是javascript:顯示功能(652)

我們可能會在將來變更這些課程類型的公開服務名稱。

5

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

後續動作

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

1

登入Control Hub ,並轉至管理 > 使用者

2

選取要更新的使用者帳戶,然後選取會議

3

設定適用於 下拉式功能表中,選取要更新的會議位置。

4

勾選Pro-End to End Encryption_純 VOIP

5

關閉使用者設定面板。

6

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

若要將此指定給許多使用者,請使用下一個選項,為多個使用者啟用 E2EE 會議

1

登入 Control Hub,然後轉至服務 > 會議

2

按一下網站,選擇您要變更設定的Webex 網站。

3

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

4

按一下產生報告,並等候我們準備檔案。

5

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

6

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

每個使用者有一行,而會議特權 欄階段作業類型ID,格式為逗號定界清單。

7

對於您想要授與新的階段作業類型的每個使用者,新增1561 作為新值(在會議特權 單元格。

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

8

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

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

9

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

10

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

11

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

12

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

您可以使用以下方式向會議錄製檔新增水印: Webex Meetings Pro 端對端 Encryption_純 VOIP 階段階段作業類型,可讓您識別機密會議的未經授權的錄製檔的來源用戶端或裝置。

當啟用此功能時,會議音訊將包含每個參與用戶端或裝置的唯一標識符。您可以將音訊錄製檔上傳至 Control Hub,Control Hub 會分析錄製檔並尋找唯一標識符。您可以查看結果以查看哪個來源用戶端或裝置錄製了會議。

  • 為了便於分析,錄製檔必須是不大於 500MB 的 AAC、MP3、M4A、WAV、MP4、AVI 或 MOV 檔案。
  • 錄製檔必須超過 100 秒。
  • 您只能分析由貴組織中的人員主持的會議的錄製檔。
  • 水印資訊的保留時間與組織的會議資訊相同。

向 E2EE 會議新增音訊水印

  1. 登入Control Hub ,然後在管理,選取組織設定
  2. 會議水印 區段,開啟新增音訊水印

    開啟此功能一段時間後,使用者排定與Webex Meetings Pro 端對端 Encryption_純 VOIP 階段作業類型請參閱數位水印 選項中的選項。

上傳和分析加水印的會議

  1. 在 Control Hub 中,下監控,選取疑難排解
  2. 按一下水印分析
  3. 在清單中搜尋或選取會議,然後按一下分析
  4. 分析音訊水印 視窗中,輸入您的分析的名稱。
  5. (可選)為分析輸入附註。
  6. 拖放要分析的音訊檔案,或按一下選擇檔案 以瀏覽至該音訊檔案。
  7. 按一下 關閉.

    當分析完成後,將顯示在分析水印 頁面。

  8. 請選取清單中的會議以查看分析結果。按一下下載按鈕 以下載結果。

功能與限制

成功解碼錄製的水印涉及的因素包括錄製裝置與輸出音訊的喇叭之間的距離、音訊的音量、環境噪音等。我們的水印技術對於被多次編碼具有額外的彈性,因為共用媒體時可能會發生這種情況。

此功能旨在在廣泛但合理的一組環境中成功解碼水印識別碼。我們的目標是讓錄製檔裝置(例如行動電話)在個人端點或膝上型用戶端附近的桌面上,應該一律建立導致成功分析的錄製檔。當錄製裝置遠離來源或被遮擋無法聽到完整的音訊頻譜時,成功分析的機率就會降低。

為了成功分析錄製檔,需要合理擷取會議音訊。如果會議的音訊是在託管用戶端的同一台電腦上錄製,則不適用限制。

如果您的裝置已加入 Control Hub 組織,並且您想要使用Webex CA 自動生成其識別憑證,則不需要將裝置恢復重設成出廠預設值。

此程序會選取裝置用於自行識別的網域,且僅在您 Control Hub 組織中具有多個網域時才需要。如果您具有多個網域,建議您針對具有「Cisco 驗證」身分的所有裝置執行此操作。如果您不告訴Webex哪個網域識別裝置,系統會自動選擇一個網域,並且其他會議參加者可能會將其視為錯誤。

開始之前

如果您的裝置尚未上線,請遵循使用API或本機網路 Interface 將裝置註冊到Cisco WebexBoard、Desk 和 Room 系列的雲端新手上路。您還應該驗證要用於在 中識別裝置的網域管理您的網域

1

登入Control Hub ,並在管理,選取裝置

2

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

3

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

4

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

開始之前

  • 取得 CA 簽署的憑證和私密金鑰, .pem 格式,適用於每個裝置。

  • 根據準備 標籤,閱讀主題了解裝置的外部身分識別程序

  • 根據其中的資訊準備 JWE 加密工具。

  • 確保您具有產生給定長度的隨機位元組序列的工具。

  • 確保您具有 base64url 編碼位元組或文字的工具。

  • 請確保您有scrypt 執行。

  • 確保每個裝置都有密碼。

1

填入裝置的用戶端機密 使用純文字密碼:

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

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

  2. 開啟裝置上的 TShell。

  3. 執行xcommand Security ClientSecret 填入密碼:「MDEyMzQ1Njc4OWFiY2RlZg」

    上述指令範例填寫了秘密 與這句話0123456789abc定義。您需要選擇您自己的密碼。

裝置具有其初始密碼。不要忘記這一點;您無法復原,必須將裝置重設為出廠值才能重新開始。
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 標頭,設定alg enc ,以及思科-kdf 中所述的鍵了解裝置的外部身分識別程序。使用鍵:值設定「新增」動作"cisco-action":"新增" 在 JOSE 標頭中(因為我們將憑證新增至裝置)。

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

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

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

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

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

xcommand 安全憑證服務新增 IsEncrypted:確定您的...JWE.str.ing\n 。\n
5

執行下列動作以驗證是否已新增憑證xcommand 安全性憑證服務顯示

複製新憑證的指紋。

6

為此目的啟動憑證WebexIdentity

  1. 從憑證本身或從 的輸出中讀取憑證的指紋xcommand 安全性憑證服務顯示

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

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

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

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

  5. 建立 JOSE 標頭,設定alg enc ,以及思科-kdf 中所述的鍵了解裝置的外部身分識別程序。使用鍵:值設定「啟用」動作"cisco-action":"啟用" 在 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 安全性憑證服務啟動 用途:WebexIdentity 指紋:「您的..JWE.crypted.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 的憑證。

  • 如果您具有不同級別的身分驗證,請授權使用者使用憑證支援的身分來相互驗證。即使在某些情況下參與者可能顯示為未驗證,而參與者應該瞭解如何檢查,但未經驗證的人員可能不是頂替者。

若是使用外部 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

這些 xAPI 指令僅適用於以下任一裝置:

  • 已向 Webex 註冊的裝置

  • 已註冊的內部部署裝置,並且已關聯至具有 Webex Edge for Devices 的 Webex

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

API 呼叫

說明

x配置會議 EndToEndEncryption 身分偏好網域:「example.com」

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

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

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

x狀態會議端對端加密可用性

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

x狀態會議端對端加密外部身分驗證

指出裝置是否使用外部 驗證(具有外部簽發的憑證)。

x狀態會議 EndToEndEncryption ExternalIdentity 身分

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

x狀態會議 EndToEndEncryption ExternalIdentity 憑證鏈憑證 #特定資訊

從外部簽發的憑證中讀取特定資訊。

在顯示的指令中,取代# 與憑證號。取代特定資訊 具有以下之一:

  • 指紋

  • 不之後 有效期限結束日期

  • 不在此之前 有效期限開始日期

  • 主要名稱

  • 公開金鑰算法

  • 序號

  • 簽名算法

  • 主旨# 名稱 憑證的主體清單(例如電子郵件地址或網域名稱)

  • 有效性 提供此憑證的有效性狀態(例如有效已過期)

xStatus 會議 EndToEndEncryption ExternalIdentity 狀態

裝置外部身分的狀態(例如有效錯誤)。

x狀態會議端對端加密內部身分驗證

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

x狀態會議端對端加密內部身份識別身分

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

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

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

如果裝置位於具有多個網域的組織中,這是來自偏好的網域

x狀態會議端對端加密內部身份憑證鏈憑證#特定資訊

從 Webex 簽發的憑證中讀取特定資訊。

在顯示的指令中,取代# 與憑證號。取代特定資訊 具有以下之一:

  • 指紋

  • 不之後 有效期限結束日期

  • 不在此之前 有效期限開始日期

  • 主要名稱

  • 公開金鑰算法

  • 序號

  • 簽名算法

  • 主旨# 名稱 憑證的主體清單(例如電子郵件地址或網域名稱)

  • 有效性 提供此憑證的有效性狀態(例如有效已過期)

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

API 呼叫

說明

xEvent 會議參加者清單參加者已新增

xEvent 會議參加者清單參加者已更新

xEvent 會議參加者清單參加者已刪除

這三個活動現在包括端對端加密狀態端對端加密身分,以及端對端加密憑證資訊 受影響的參加者。

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

API 呼叫

說明

xCommand 安全性 ClientSecret 填入密碼:「base64url 編碼」

xCommand 安全性 ClientSecret 填入密碼:JWEBlob

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

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

xCommand 安全性憑證服務 新增JWEBlob

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

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

xCommand 安全性憑證服務啟動用途:WebexIdentity 指紋:JWEBlob

啟動 WebexIdentity 的特定憑證。為此目的,該指令需要在 JWE Blob 中加密和序列化識別指紋。

xCommand 安全性憑證服務停用用途:WebexIdentity 指紋:JWEBlob

停用 WebexIdentity 的特定憑證。為此目的,該指令需要在 JWE Blob 中加密和序列化識別指紋。