部署零信任會議
使用者在排定會議時選擇會議類型。當從大廳准許參加者進入時以及在會議期間,主持人可以看到每個參加者的身份驗證狀態。還有一個會議代碼,該代碼對會議中的所有目前參加者是通用的,他們可以使用該代碼來驗證其會議未被不需要的第三方中間人 (MITM) 攻擊攔截。
與會議主持人共用以下資訊:
-
使用端對端加密加入 Webex 會議
驗證身分
具有身分驗證的端對端加密為端對端加密會議提供額外的安全性。
當參加者或裝置加入共用的 MLS(訊息層安全性)群組時,他們會向其他群組成員展示其憑證,這些成員隨後會根據簽發憑證的憑證授權單位 (CA) 來驗證憑證。透過確認憑證有效,CA 會驗證參加者的身分,且會議會將參加者/裝置顯示為已驗證。
Webex 應用程式使用者根據 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 裝置要用於其身分識別的網域。您也可以使用 APIxConfiguration 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 系列裝置可以加入 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 來管理您的會議網站,因為 Control Hub 組織具有整個組織的集中式身分識別。
相關資訊
-
Webex 的零信任安全性 (安全性技術文件)
-
JSON Web 加密 (JWE) (IETF 標準草案)
-
Webex Meetings 41.7。
-
雲端註冊的 Webex Room 和 Webex Desk 系列裝置,執行中
10.6.1-RoomOS_August_2021
。 -
對 Control Hub 中的會議網站具有管理存取權。
-
Control Hub 組織中的一個或多個已驗證網域(如果您使用 Webex CA 為已驗證身分簽發裝置憑證)。
-
必須開啟協作會議室,以便人員可以從其視訊系統加入。如需相關資訊,請參閱允許視訊系統加入 Webex 網站上的會議和活動。
如果您不需要外部驗證的身分,則可以跳過此步驟。
為了獲得最高層級的安全性和身分驗證,每個裝置都應該具有由受信任的公共憑證授權單位 (CA) 簽發的唯一憑證。
您需要與 CA 互動以請求、購買和接收數位憑證,並建立關聯的私密金鑰。請求憑證時,請使用以下參數:
-
憑證必須由知名的公用 CA 簽發和簽署。
-
唯一:我們強烈建議為每個裝置使用唯一的憑證。如果您為所有裝置使用一個憑證,則會危害您的安全性。
-
一般名稱 (CN) 和主體替代名稱 (SAN):這些對 Webex 來說並不重要,但應該是人類可以讀取並與裝置關聯的值。CN 將作為裝置的主要已驗證身分顯示給其他會議參加者,如果使用者透過會議 UI 檢查憑證,他們將看到 SAN。您可能想要使用類似的名稱
name.model@example.com
。 -
檔案格式:憑證和金鑰必須位於
.pem
格式。 -
目的:憑證用途必須為 Webex 身分識別。
-
正在產生金鑰:憑證必須基於 ECDSA P-256 金鑰組(使用 P-256 曲線的橢圓曲線數位簽章演算法)。
此需求不會延伸至簽署金鑰。CA 可以使用 RSA 金鑰來簽署憑證。
如果您不想在裝置上使用外部驗證的身分,則可以跳過此步驟。
如果您正在使用新裝置,請先不要向 Webex 註冊它們。為了安全起見,此時請勿將它們連線至網路。
如果您有想要升級以使用外部驗證身分的現有裝置,則必須將裝置重設成出廠預設值。
-
如果您要保留現有組態,請儲存它。
-
在未使用裝置時排定一個時段,或使用分階段的方法。通知使用者他們可以預期的變更。
-
確保對裝置進行實體存取。如果您必須透過網路存取裝置,請注意密碼是以純文字形式傳送,您會危害您的安全性。
完成這些步驟後,允許視訊系統加入 Webex 網站上的會議和活動。
若要確保您的裝置媒體無法被裝置以外的任何人加密,您必須加密裝置上的私密金鑰。我們為裝置設計了 API,以便使用 JSON Web 加密 (JWE) 來管理加密的金鑰和憑證。
為了確保透過我們的雲端進行真正的端對端加密,我們不能參與加密和上傳憑證和金鑰。如果您需要此層級的安全性,您必須:
-
請求您的憑證。
-
產生憑證的金鑰組。
-
為每個裝置建立(並保護)初始密碼,以播種裝置的加密功能。
-
開發和維護您自己的工具,以使用 JWE 標準加密檔案。
以下說明了您需要的過程和(非秘密)參數,以及在您選擇的開發工具中遵循的秘訣。我們還會提供一些測試資料以及我們預期的 JWE Blob,以協助您驗證您的程序。
Cisco 可應要求提供使用 Python3 和 JWCrypto 程式庫的不受支援的參考實作。
-
使用您的工具和裝置的初始密碼串聯並加密憑證和金鑰。
-
將產生的 JWE Blob 上傳至裝置。
-
設定要用於 Webex 身分識別的加密憑證的用途,然後啟動憑證。
-
(建議)為您的工具提供介面(或分發),以使裝置使用者能夠變更初始密碼並保護其媒體不受您的侵害。
我們如何使用 JWE 格式
本節說明我們預期如何建立 JWE 作為裝置的輸入,以便您可以建立自己的工具來從憑證和金鑰建立 Blob。
請參閱JSON Web 加密 (JWE) https://datatracker.ietf.org/doc/html/rfc7516 和JSON Web 簽章 (JWS) https://datatracker.ietf.org/doc/html/rfc7515 。
我們使用精簡序列化 以建立 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 的工具必須遵循相同的程序,以從用戶端密碼衍生相同的加密/解密金鑰。
裝置使用加密 用於金鑰衍生(請參閱https://en.wikipedia.org/wiki/Scrypt),具有以下參數:
-
成本因數 (N) 為 32768
-
BlockSizeFactor (r) 為 8
-
ParallelizationFactor (p) 為 1
-
加鹽是至少 4 個位元組的隨機序列;您必須提供相同的
salt
當指定cisco-kdf
參數。 -
金鑰長度為 16 位元組(如果您選取 AES-GCM 128 演算法)或 32 位元組(如果您選取 AES-GCM 256 演算法)
-
記憶體上限為 64MB
這組參數是 的唯一設定加密 與裝置上的金鑰衍生功能相容。裝置上的此 kdf 稱為"version":"1"
,這是目前由cisco-kdf
參數。
工作範例
您可以遵循以下範例來驗證您的 JWE 加密程序是否與我們在裝置上建立的程序相同。
範例情境是將 PEM Blob 新增至裝置(模仿新增憑證,使用非常短的字串而不是完整的憑證 + 金鑰)。範例中的用戶端密碼為ossifrage
。
-
選擇加密密碼。此範例使用
A128GCM
(在 Galois 計數器模式下具有 128 位元金鑰的 AES)。您的工具可以使用A256GCM
如果您願意。 -
選擇 salt(必須是至少 4 個位元組的隨機序列)。此範例使用(十六進位字元)
E5 E6 53 08 03 F8 33 F6
。Base64url 對序列進行編碼以獲取5eZTCAP4M_Y
(移除 base64 填充)。 -
這是一個範例
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
。 -
選擇 12 位元組的隨機序列以用作初始化向量。此範例使用(十六進位)
34 b3 5d dd 5f 53 7b af 2d 92 95 83
base64url 編碼為NLNd3V9Te68tkpWD
。 -
使用精簡序列化建立 JOSE 標頭(遵循我們在這裡使用的相同參數順序),然後對其進行 base64url 編碼:
{"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}
base64url 編碼的 JOSE 標頭為
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9
這將是 JWE Blob 的第一個元素。
-
JWE Blob 的第二個元素為空,因為我們未提供 JWE 加密金鑰。
-
JWE Blob 的第三個元素是初始化向量
NLNd3V9Te68tkpWD
。 - 使用 JWE 加密工具產生加密的負載和標籤。在此範例中,未加密的負載將是假的 PEM Blob
this is a PEM file
您應該使用的加密參數如下:
有效負載現為
this is a PEM file
加密密碼為 AES 128 GCM
base64url 編碼的 JOSE 標頭作為附加驗證資料 (AAD)
Base64url 對加密的負載進行編碼,這應該會導致
f5lLVuWNfKfmzYCo1YJfODhQ
這是 JWE Blob 中的第四個元素 (JWE Ciphertext)。
-
Base64url 對您在步驟 8 中產生的標籤進行編碼,這應該會導致
PE-wDFWGXFFBeo928cfZ1Q
這是 JWE Blob 中的第五個元素。
-
將 JWE Blob 的五個元素與點 (JOSEheader..IV.Ciphertext.Tag) 串聯以取得:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
-
如果您使用自己的工具衍生出與我們在這裡顯示的相同的 base64url 編碼值,則可以使用它們來保護裝置的 E2E 加密和已驗證身分。
-
此範例實際上不起作用,但原則上,您的下一步是使用您在上面建立的 JWE Blob 作為新增憑證的裝置上 xcommand 的輸入:
xCommand Security Certificates Add
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
所有會議網站都可以使用零信任會議的階段作業類型,無需額外付費。其中一種階段作業類型稱為Pro-End to End Encryption_VOIPonly
。這是公用服務名稱,我們將來可能會變更。有關階段作業類型的目前名稱,請參閱階段作業類型 ID 在參考 部分。
您無需執行任何操作即可為您的網站獲取此功能。您確實需要授予新的階段作業類型(也稱為會議特權)給使用者。您可以透過使用者的設定頁面個別執行此作業,或使用 CSV 匯出/匯入批量執行此作業。
1 |
登入至Control Hub ,然後轉至 。 |
2 |
按一下網站,選擇要變更其設定的 Webex 網站,然後按一下設定。 |
3 |
低於通用設定,選取階段作業類型。 您應該會看到一個或多個端對端加密階段作業類型。請參閱清單階段作業類型 ID 在參考 部分。例如,您可能會看到Pro-End to End Encryption_僅限 VOIP 。
有一個名稱非常相似的較舊階段作業類型:Pro-End to End 加密。此階段作業類型包括對會議的非加密 PSTN 存取。確保您有_僅限 VOIP 版本以確保端對端加密。您可以將滑鼠移至PRO 課程代碼欄中的鏈結;在此範例中,鏈結的目標應該是 我們將來可能會變更這些階段作業類型的公開服務名稱。 |
4 |
如果您還沒有新的階段作業類型,請聯絡您的 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 檔案進行編輯。 每個使用者都有一列, |
7 |
對於您要授予新階段作業類型的每個使用者,新增 的Webex CSV 檔案格式參考 包含有關 CSV 檔案用途和內容的詳細資訊。 |
8 |
在 Control Hub 中開啟會議網站設定面板。 如果您已經在會議網站清單頁面上,您可能需要重新整理它。 |
9 |
在授權和使用者 區段中,按一下批量管理。 |
10 |
按一下匯入 並選取已編輯的 CSV,然後按一下匯入。等待檔案上傳。 |
11 |
匯入完成後,您可以按一下匯入結果 以檢查是否有任何錯誤。 |
12 |
轉至使用者 頁面並開啟其中一個使用者以驗證他們是否具有新的階段作業類型。 |
您可以使用Webex Meetings Pro-End to End Encryption_VOIPonly
階段作業類型,可讓您識別機密會議的未經授權錄製檔的來源用戶端或裝置。
當啟用此功能時,會議音訊包括每個參與的用戶端或裝置的唯一識別碼。您可以將音訊錄製檔上傳至 Control Hub,然後 Control Hub 會分析錄製檔並查找唯一 ID。您可以查看結果以查看哪個來源用戶端或裝置錄製了會議。
- 為了進行分析,錄製檔必須是不大於 500MB 的 AAC、MP3、M4A、WAV、MP4、AVI 或 MOV 檔案。
- 錄製檔必須長於 100 秒。
- 您只能分析組織中的人員主持的會議的錄製檔。
- 浮水印資訊的保留時間與組織的會議資訊相同。
將音訊浮水印新增至 E2EE 會議
- 登入至Control Hub ,然後在管理,選取組織設定。
- 在會議浮水印 區段,開啟新增音訊浮水印。
開啟此功能一段時間後,排定會議的使用者
Webex Meetings Pro-End to End Encryption_VOIPonly
階段作業類型 查看數位浮水印 選項。
上傳並分析帶浮水印的會議
- 在 Control Hub 中,在監控,選取疑難排解。
- 按一下浮水印分析。
- 在清單中搜尋或選取會議,然後按一下分析。
- 在分析音訊浮水印 視窗中,輸入分析的名稱。
- (可選)輸入分析的附註。
- 拖放要分析的音訊檔案,或按一下選擇檔案 以瀏覽至音訊檔案。
- 按一下關閉。
分析完成後,它將顯示在分析浮水印 頁。
- 在清單中選取會議以查看分析結果。按一下
以下載結果。
功能和限制
成功解碼錄製的浮水印所涉及的因素包括錄製裝置與輸出音訊的喇叭之間的距離、該音訊的音量、環境噪音等。我們的浮水印技術具有額外的彈性,可以多次編碼,就像共用媒體時可能發生的那樣。
此功能旨在在廣泛但合理的情況下成功解碼浮水印識別碼。我們的目標是讓位於桌上型電腦上靠近個人端點或筆記型電腦用戶端的錄製裝置(譬如行動電話)應該始終建立能夠成功進行分析的錄製檔。當錄音裝置遠離來源,或被遮住而無法聽到完整的音訊頻譜時,成功分析的機會就會降低。
為了成功分析錄製檔,需要合理擷取會議音訊。如果在主持用戶端的同一台電腦上錄製會議的音訊,則不應套用限制。
如果您的裝置已加入 Control Hub 組織,並且您想要使用 Webex CA 自動產生其識別憑證,則無需將裝置重設成出廠預設值。
此程序會選取裝置用來識別自身的網域,且僅當您的 Control Hub 組織中有多個網域時才需要此程序。如果您有多個網域,我們建議您對將具有「Cisco 驗證」身分的所有裝置執行此操作。如果您未告知 Webex 是哪個網域識別裝置,則會自動選擇一個網域,並且其他會議參加者可能會認為該網域有誤。
開始之前
如果您的裝置尚未上線,請遵循使用 API 或本機 Web 介面向 Cisco Webex 註冊裝置 或Board、Desk 和 Room 系列的雲端上線。您還應該驗證要用於識別裝置的網域管理您的網域。
1 |
登入至Control Hub ,然後在管理,選取裝置。 |
2 |
選取裝置以開啟其組態面板。 |
3 |
選取要用於識別此裝置的網域。 |
4 |
對其他裝置重複此步驟。 |
開始之前
-
取得 CA 簽署的憑證和私密金鑰,位於
.pem
格式,適用於每個裝置。 -
在準備 標籤,閱讀主題了解裝置的外部身分識別程序,
-
根據那裡的資訊準備 JWE 加密工具。
-
確保您具有產生給定長度的隨機位元組序列的工具。
-
確保您具有對位元組或文字進行 base64url 編碼的工具。
-
確保您有
scrypt
實作。 -
確保每個裝置都有一個秘密單字或片語。
1 |
填入裝置的 第一次填入 裝置具有其初始密碼。不要忘記這一點;您無法將其複原,且必須將裝置重設成出廠預設值才能重新啟動。
|
2 |
串聯您的憑證和私密金鑰: |
3 |
建立 JWE Blob 以用作憑證新增指令的輸入: |
4 |
在裝置上開啟 TShell 並執行(多行)新增指令: |
5 |
執行下列作業以驗證是否已新增憑證 複製新憑證的指紋。 |
6 |
為以下目的啟動憑證 裝置具有 CA 簽發的加密、作用中憑證,可用於在端對端加密的 Webex 會議中識別它。
|
7 |
將裝置加入 Control Hub 組織。 |
1 |
排定正確類型的會議( Webex Meetings Pro 端對端 Encryption_僅限 VOIP )。 |
2 |
從 Webex Meetings 用戶端以主持人身分加入會議。 |
3 |
從其身分已由 Webex CA 驗證的裝置加入會議。 |
4 |
作為主持人,請驗證此裝置是否以正確的身分圖示顯示在大廳中。 |
5 |
從其身分已由外部 CA 驗證的裝置加入會議。 |
6 |
作為主持人,請驗證此裝置是否以正確的身分圖示顯示在大廳中。進一步了解身分圖示。 |
7 |
以未驗證的會議參加者身分加入會議。 |
8 |
作為主持人,請驗證此參加者是否以正確的身分圖示出現在大廳中。 |
9 |
作為主持人,允許或拒絕人員/裝置。 |
10 |
在可能的情況下,透過檢查憑證來驗證參加者/裝置身分。 |
11 |
檢查會議中的每個人是否都能看到相同的會議安全代碼。 |
12 |
加入包含新參加者的會議。 |
13 |
檢查每個人是否看到相同的新會議安全代碼。 |
-
您要將端對端加密會議設為預設會議選項,還是僅對部分使用者啟用它,還是允許所有主持人決定?當您決定如何使用此功能時,請為將要使用此功能的使用者做好準備,尤其是關於限制和會議預期內容。
-
您是否需要確保 Cisco 或其他任何人都無法解密您的內容或模仿您的裝置?如果是這樣,您需要來自公用 CA 的憑證。
-
如果您有不同層級的身分驗證,請授權使用者使用憑證支援的身分來驗證彼此。即使在某些情況下,參加者可能顯示為未驗證,並且參加者應該知道如何檢查,但未驗證的人可能不是冒名頂替者。
如果您使用外部 CA 來簽發裝置憑證,則您有責任監控、重新整理和重新套用憑證。
如果您建立了初始密碼,請了解您的使用者可能想要變更其裝置的密碼。您可能需要建立介面/分發工具以使他們能夠執行此操作。
階段作業類型 ID |
公用服務名稱 |
---|---|
638 |
僅限 E2E 加密+VoIP |
652 |
Pro-End to End Encryption_僅限 VOIP |
660 |
Pro 3 自由端對端 Encryption_僅限 VOIP E2E 加密 + 身分識別 |
672 |
Pro 3 Free50-端對端 Encryption_僅限 VOIP |
673 |
教育講師 E2E Encryption_僅限 VOIP |
676 |
Broadworks 標準版加上端對端加密 |
677 |
Broadworks Premium 加上端對端加密 |
681 |
Schoology 免費加上端對端加密 |
這些表格描述了我們為端對端加密會議和已驗證身分新增的 Webex 裝置 API 指令。有關如何使用 API 的更多資訊,請參閱存取 Webex Room 和 Desk 裝置以及 Webex Board 的 API 。
這些 xAPI 指令僅適用於以下任一裝置:
-
已向 Webex 註冊
-
已在內部註冊並透過 Webex Edge for Devices 鏈結至 Webex
API 呼叫 |
說明 |
---|---|
|
當管理員從 Control Hub 設定裝置的偏好網域時,會進行此設定。僅當組織具有多個網域時才需要。 裝置在向 Webex CA 請求憑證時會使用此網域。然後網域會識別裝置。 當裝置具有作用中的外部簽發憑證來識別其自身時,此組態不適用。 |
|
指出裝置是否可以加入端對端加密會議。雲端 API 會呼叫它,以便配對的應用程式知道它是否可以使用裝置加入。 |
|
指示裝置是否使用 |
|
從外部核發憑證的通用名稱讀取的裝置身分。 |
|
從外部簽發的憑證讀取特定資訊。 在顯示的指令中,將
|
|
裝置外部身分識別的狀態(例如 |
|
指出裝置是否具有由 Webex CA 簽發的有效憑證。 |
|
從 Webex 核發憑證的「通用名稱」讀取的裝置身分。 如果組織具有網域,則包含網域名稱。 如果組織沒有網域,則為空。 如果裝置位於具有多個網域的組織中,則此值為 |
|
從 Webex 核發的憑證中讀取特定資訊。 在顯示的指令中,將
|
API 呼叫 |
說明 |
---|---|
| 這三個活動現在包括 |
API 呼叫 |
說明 |
---|---|
或
| 接受 base64url 編碼的純文字值,用於首次在裝置上設定用戶端密碼。 若要在第一次之後更新密碼,您必須提供 JWE Blob,其中包含由舊密碼加密的新密碼。 |
| 新增憑證(帶有私密金鑰)。 我們擴充了此指令以接受包含加密的 PEM 資料的 JWE Blob。 |
| 啟動 WebexIdentity 的特定憑證。為此 |
| 停用 WebexIdentity 的特定憑證。為此 |