用户在安排会议时选择新的会议类型。 在允许参加者从等候区加入会议时和在会议期间,主持人可以查看每个参加者的身份验证状态。 会议的所有当前参加者都共有一个会议代码,他们可以使用该代码相互验证。

与会议主持人共享以下信息:

正在验证身份

端到端身份验证为端到端加密会议提供了更高的安全性。

当参加者或设备加入共享 MLS(消息传递层安全性)组时,他们向其他组成员出示证书,然后其他组成员根据颁发证书的机构 (CA) 验证证书。 在确认证书有效后,CA 会验证参加者的身份,并且会议将显示参加者/设备为已验证状态。

Webex Meetings 应用程序的用户通过 Webex identity store 进行身份验证,验证成功后 Webex identity store 会向他们颁发访问令牌。 如果他们在端到端加密会议上需要证书来验证其身份,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 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.7 开始,Webex Meetings 桌面客户端可以加入端到端加密会议。

  • Webex 应用程序无法加入端到端加密会议。

    如果您的组织通过启动 Meetings 桌面应用程序将 Webex 应用程序加入会议,则您可以使用该选项加入端到端加密会议。

  • Webex web 客户端无法加入端到端加密会议。

  • 第三方 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 颁发用于验证身份的设备证书)。

如果您不需要已外部验证的身份,可以跳过此步骤。

为达到最高级别的安全性和进行身份验证,每台设备都应具有由受信任的公共证书颁发机构颁发的唯一证书。

您需要与 CA 沟通,以请求、购买和接收数字证书,并创建关联的私钥。 在请求证书时,要使用以下参数:

  • 证书必须由知名的公共 CA 颁发和签名。

  • 唯一性: 我们强烈建议每台设备使用唯一证书。 如果您对所有设备使用同一证书,将影响安全性。

  • 通用名称 (CN) 和主题备用名称 (SAN): 这些对 Webex 并不重要,但应该是人类可以读取并与设备关联的值。 CN 将作为设备主要验证身份的方式向其他会议参加者显示,如果用户通过会议 UI 检查证书,他们将看到 SAN。 您可能希望使用以下名称: name.model@example.com 但由您决定是否使用。

  • 文件格式: 证书和密钥必须采用 .pem 格式。

  • 目的: 证书必须用于 Webex 身份。

  • 生成密钥: 证书必须基于 ECDSA P-256 密钥对(使用 P-256 曲线的椭圆曲线数字签名算法)。

    此要求不会扩展到签名密钥。 CA 可以使用 RSA 密钥签名证书。

如果您不想在设备上使用已外部验证的身份,可以跳过此步骤。

如果您使用的是新设备,请勿将其注册到 Webex。 新设备不联网最安全。

如果您想对现有设备升级以使用外部已验证身份,您需要恢复设备出厂设置。

  • 如果要保留现有配置,请进行保存。

  • 在设备不使用时安排一个窗口,或采用分阶段的方法。 通知用户可预期的变化。

  • 确保对设备进行物理访问。 如果您必须通过网络访问设备,请注意,密码以纯文本方式传输,会影响安全性。

要确保您的设备媒体只能由设备加密而无法被任何人加密,您必须对设备的私钥进行加密。 我们为设备设计了 API,以使用 JSON Web Encryption (JWE) 实现对加密密钥和证书的管理。

为确保通过我们的云实现真正的端到端加密,我们不能参与证书和密钥的加密和上传。 如果您需要此种级别的安全性,则您有责任:

  • 请求您的证书。

  • 生成您证书的密钥对。

  • 为每台设备创建(并保护)初始密码,以植入设备加密能力。

  • 开发和维护您自己的工具,以便使用 JWE 标准加密文件。

    下面我们将说明您需要的流程和(非秘密)参数,以及在您选择的开发工具中应遵循的方法。 我们还提供了一些测试数据和其生成的 JWE blob(与预期一致),帮助验证您的流程。

    使用Python3和JWCrypto库的不受支持的参考实现可根据要求从 Cisco 获得。

  • 使用工具和设备的初始密码对证书和密钥进行连接和加密。

  • 将生成的 JWE blob上传到设备。

  • 将加密证书设置为用于 Webex 身份,并激活证书。

  • (推荐)为您的工具提供一个接口(或分布),使设备用户能够更改初始密码(以保护他们的媒体不受您影响!)。

如何使用 JWE 格式

本节描述了我们期望如何将 JWE 创建为设备的输入,以便您可以构建自己的工具来从证书和密钥创建 blob。

您将需要参考 JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516JSON Web Signature (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 算法)

  • 最大内存上限为 64 MB

此参数组是唯一与设备上密钥派生函数兼容的 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 加密 + 身份

5

如果您还没有新的会话类型,请联系您的 Webex 代表。

下一步

对部分或所有用户启用此会话类型/会议权限。

1

单击用户,并选择一个用户以打开用户的配置面板。

2

服务区域,单击 Cisco Webex Meetings

3

选择站点(如果用户位于多个站点中)并单击主持人

4

选中 Webex Meetings 项旁边标记为 Pro-End to End Encryption_VOIPonly 的复选框。

5

关闭用户配置面板。

6

如有必要,对其他用户重复上述步骤。

如果要将其分配给多个用户,请使用 CSV 批量选项。

1

https://admin.webex.com 处登录到 Control Hub 并打开会议页面。

2

单击站点名称以打开站点配置面板。

3

许可证和用户部分,单击批量管理

4

单击导出,然后等待准备文件。

5

文件就绪后,单击导出结果,然后单击下载。 (单击下载后,必须手动关闭该弹出窗口。)

6

打开下载的 CSV 文件进行编辑。

每个用户都有一行,且 MeetingPrivilege 每列包含用户的会话类型 ID,以逗号分隔的列表形式呈现。

7

对于要授予新会话类型的用户,请添入 1561 逗号分隔的列表一个新值于 MeetingPrivilege 单元格中。

https://help.webex.com/en-us/5vox83 的 CSV 文件格式参考中有一些关于 CSV 文件的目的和内容的详细信息。

8

在 Control Hub 中打开会议站点配置面板。

如果您已经位于会议站点列表页面,可能需要进行刷新。

9

许可证和用户部分,单击批量管理

10

单击导入并选择已编辑的 CSV,然后单击导入。 正在上传文件,请稍候。

11

导入完成后,您可以单击导入结果,查看是否出现错误。

12

转至用户页面,打开其中一个用户,验证其拥有新的会话类型。

如果您的设备已加入 Control Hub 组织,并且您希望使用 Webex CA 自动生成其标识证书,则不需要恢复设备出厂设置。

此程序选择设备用来标识自身的域,且仅在 Control Hub 组织中有多个域时才需要此程序。 如果您拥有多个域,我们建议您对具有“经 Cisco 验证”身份的所有设备进行此操作。 如果您不告诉 Webex 哪个域标识该设备,我们将选择一个域,其他会议参加者可能会认为这是错误的。

准备工作

如果您的设备尚未加入,您可以遵循https://help.webex.com/n25jyr8https://help.webex.com/nutc0dy。 您还应该验证要用于识别设备的域 (https://help.webex.com/cd6d84)。

1

登录到 Control Hub (https://admin.webex.com) 并打开设备页面。

2

选择设备以打开其配置面板。

3

选择要用于标识此设备的域。

4

对其他设备重复上述步骤。

准备工作

您需要:

  • 为每台设备获取 .pem 格式的 CA 签名证书和私钥。

  • 阅读了解设备的外部身份流程主题于本文准备部分中。

  • 准备与信息有关的 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 和密钥长度来匹配您选择的加密密码。 还有一些其他固定值需要提供 (N = 32768,r = 8,p = 1)。 设备使用相同的过程和值来派生相同的内容加密密钥。

  3. 创建 12 个字节的随机序列。 这是您的初始化向量。

  4. 创建 JOSE 标头,设置 alg, enccisco-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 和密钥长度来匹配您选择的加密密码。 还有一些其他固定值需要提供 (N = 32768,r = 8,p = 1)。 设备使用相同的过程和值来派生相同的内容加密密钥。

  4. 创建 12 字节的随机序列,并对该序列进行 base64url 编码。 这是您的初始化向量。

  5. 创建 JOSE 标头,设置 alg, enccisco-kdf 密钥,如 了解设备的外部身份流程中所述。 设置“激活”操作,使用 key:value "cisco-action":"activate" 于 JOSE 标头中(因为我们正在设备上激活证书)。

  6. Base64url 对 JOSE 标头进行编码。

  7. 使用 JWE 加密工具与所选密码和 base64url 编码的 JOSE 标头加密证书指纹。

    该工具应输出 16 或 32 字节的序列(取决于您选择的是 128 位还是 256 位 AES-GCM)以及身份验证标记。

  8. Base64Url 对加密指纹和身份验证标记进行编码。

  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 颁发的设备证书,则您有责任监视、更新和重新应用证书。

如果您创建了初始密码,您需要清楚用户可能希望更改其设备密码。 您可能需要创建界面/分发工具以允许他们进行此操作。

表 1. 用于端到端加密会议的会话类型 ID

会话类型 ID

公共服务名称

638

E2E Encryption+VoIP only

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 的更多内容,请参阅https://help.webex.com/nzwo1ok

表 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)

现在这三项活动包括 EndToEndEncryptionStatus, EndToEndEncryptionIdentityEndToEndEncryptionCertInfo 针对受影响的参加者。

表 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 中对识别指纹进行加密和序列化。