Los usuarios eligen el nuevo tipo de reunión cuando planifican una reunión. Cuando admite participantes desde la sala de recepción, y durante la reunión, el host puede ver el estado de verificación de identidad de cada participante. También hay un código de reunión común a todos los participantes actuales de la reunión, que pueden usar para verificarse entre sí.

Comparta la siguiente información con los organizadores de la reunión:

Verificando identidad

de extremo a extremo verificación de identidad proporciona seguridad adicional a una reunión cifrada de extremo a extremo.

Cuando los participantes o dispositivos se unen a un grupo deMLS (Seguridad de capa de mensajería) compartido, presentan sus certificados a otros miembros del grupo que luego validan los certificados ante la Autoridad de emisión de certificados/ies (CA). Al confirmar que los certificados son válidos, la CA verifica la identidad de los participantes y la reunión muestra los participantes/dispositivos como verificados.

Los usuarios del aplicación Webex Meetings autentican ante el almacén de identidades de Webex, lo que les emite un token de acceso cuando tienen éxito. Si necesitan un certificado para verificar su identidad (en una reunión cifrada de extremo a extremo), la CA de Webex le emite un certificado sobre la base de su token de acceso. Aún no ofrecemos una forma para que Webex Meetings usuarios obtengan un certificado emitido por una CA externa/externa.

Los dispositivos pueden autenticarse mediante un certificado emitido por la CA interna (Webex) o por un certificado emitido por una CA externa:

  • En el caso de la CA interna, Webex emite un certificado interno basado en el token de acceso de la cuenta de máquina del dispositivo. El certificado está firmado por la CA de Webex. Los dispositivos no tienen ID de usuario de la misma manera que los usuarios, de manera que Webex utiliza (uno de) los dominios de su organización al escribir la identidad del certificado del dispositivo (Nombre común (CN)).

  • En el caso de la CA externa, usted solicita y adquiere certificados de dispositivos directamente del emisor que eligió. Debe cifrar, cargar directamente y autorizar los certificados mediante un secreto conocido solo por usted.

    Cisco no está involucrado, lo que hace que esta sea la manera de garantizar el verdadero cifrado de extremo a extremo y la identidad verificada, y evita la posibilidad verificada de que Cisco pueda abrir la cuenta en su reunión/descifrar los medios.

Certificado de dispositivo emitido internamente

Webex emite un certificado al dispositivo cuando se inscribe después del inicio y lo renueva cuando es necesario. Para los dispositivos, el certificado incluye el ID de la cuenta y un dominio.

Si su organización no tiene un dominio, la CA de Webex emite el certificado sin un dominio.

Si su organización tiene varios dominios, puede utilizar Control Hub para saber a Webex qué dominio debe utilizar el dispositivo para su identidad. También puede usar la API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Si tiene varios dominios y no establece el dominio preferido para el dispositivo, Webex elige uno por usted.

Certificado de dispositivo emitido externamente

Un administrador puede aprovisionar un dispositivo con su propio certificado que se ha firmado con una de las CA públicas.

El certificado debe basarse en un par de claves ECDSA P-256, aunque pueden estar firmados por una clave RSA.

Los valores en el certificado son a discreción de la organización. El Nombre común (CN) y el Nombre alternativo del sujeto (SAN) se mostrarán en la interfaz de usuario de la reunión de Webex, como se describe en Cifrado de extremo a extremo con verificación de identidad para Webex Meetings.

Se recomienda utilizar un certificado por dispositivo y tener un nombre común único por dispositivo. Por ejemplo, podría ser "meeting-room-1.example.com", para la organización que es propietaria del dominio "example.com".

Para proteger por completo el certificado externo de las falsificaciónes, se utiliza una función que permite encriptar e iniciar sesión con varios xcommands.

Cuando se utiliza el secreto del cliente, es posible administrar en forma segura el certificado de identidad externo de Webex a través de la xAPI. Actualmente, esto se limita a dispositivos en línea.

Actualmente, Webex proporciona comandos de API para administrar esto.

Dispositivos

Los dispositivos de Webex Room registrados en la nube y de la serie Webex Desk pueden entrar a reuniones cifradas de extremo a extremo, incluidos:

  • Webex Board

  • Webex Desk Pro

  • Escritorio de Webex

  • Webex Room Kit

  • Webex Room Kit Mini

Los siguientes dispositivos no pueden entrar a reuniones de extremo a extremo cifradas:

  • Serie Webex C

  • Serie Webex DX

  • Serie Ex de Webex

  • Serie Mx de Webex

  • Dispositivos SIP de otros proveedores

Clientes de software

  • A partir de la versión 41.7, el Webex Meetings cliente de escritorio puede entrar en reuniones cifradas de extremo a extremo.

  • La aplicación de Webex no puede entrar a reuniones cifradas de extremo a extremo.

    Si su organización permite que la aplicación de Webex entre a reuniones iniciando la aplicación de escritorio de Meetings, puede utilizar esa opción para entrar a reuniones cifradas de extremo a extremo.

  • El cliente web de Webex no puede entrar a reuniones cifradas de extremo a extremo.

  • Los clientes de software de SIP de terceros no pueden entrar a reuniones cifradas de extremo a extremo.

Identidad

  • No proporcionamos ninguna opción de Control Hub para que administre la identidad del dispositivo verificada externamente. Esta decisión es por diseño, ya que para un verdadero cifrado de extremo a extremo, solo usted debe conocer/acceder a la ventana y claves. Si incorporamos un servicio en la nube para administrar esas claves, existe la posibilidad de que sean interceptadas.

  • Actualmente no ofrecemos ninguna herramienta para ayudarlo a solicitar o cifrar los certificados de identidad de su dispositivo y sus claves privadas. En la actualidad, le ofrecemos una "receta" para que diseñe sus propias herramientas, basadas en técnicas de cifrado estándar de la industria, que lo ayudan con estos procesos. No queremos tener un acceso real o percibido a sus teclas o la inversión.

Reuniones

  • de extremo a extremo reuniones cifradas actualmente admiten un máximo de 200 participantes.

  • De esos 200 participantes, pueden entrar un máximo de 25 dispositivos verificados externamente, y deben ser los primeros participantes en entrar a lareunión.

    Cuando entra a una reunión una mayor cantidad de dispositivos, nuestros servicios multimedia backend intentan transcodificar las transmisiones multimedia. Si no podemos descifrar, transcodificar y volver a cifrar los medios (porque no tenemos las claves de cifrado de los dispositivos y, por lo tanto, la transcodificación falla.

    Para mitigar esta limitación, recomendamos reuniones más pequeñas para dispositivos, o escalonar las invitaciones entre dispositivos y clientes de reuniones.

Interfaz de administración

Recomendamos encarecidamente que utilice Control Hub para administrar su sitio de Reuniones.

El principal motivo de esto es la diferencia entre la manera en que Control Hub y Administración del sitio administran la identidad. Las organizaciones del Control Hub tienen una identidad centralizada para toda la organización, mientras que en Administración del sitio la identidad se controla según el sitio.

Esto significa que no puede tener la opción de identidad verificada por Cisco para los usuarios que se administran desde Administración del sitio. A esos usuarios se les emite un certificado anónimo para entrar a una reunión cifrada de extremo a extremo, y pueden ser excluidos de las reuniones en las que el host desea garantizar la identidad.

Información relacionada

Derivación de nombres de archivo JWE de muestra

Muestra de JWE correctamente cifrada en función de los parámetros dados (apéndice)

  • Webex Meetings 41.7.

  • Dispositivos de la serie Webex Room y Webex Desk registrados en la nube, en ejecución 10.6.1-RoomOS_August_2021.

  • Acceso administrativo al sitio de reuniones en Control Hub, para habilitar las nuevas tipo de sesión para los usuarios.

  • Uno o más dominios verificados en su organización de Control Hub (si está usando la CA de Webex para emitir certificados de dispositivos con identidad verificada).

Puede omitir este paso si no necesita una identidad verificada externamente.

Para el mayor nivel de seguridad y para la verificación de identidades, cada dispositivo debe tener un certificado único emitido por una Autoridad de certificación pública de confianza.

Necesita interactuar con la CA para solicitar, comprar y recibir los certificados digitales y crear las claves privadas asociadas. Al solicitar el certificado, estos son los parámetros para utilizar:

  • El certificado debe ser emitido y firmado por una CA pública conocida.

  • Único: Recomendamos en forma enérgica el uso de un certificado único para cada dispositivo. Si utiliza un certificado para todos los dispositivos, está comprometer su seguridad.

  • Nombre común (CN) y Nombre/s alternativo del sujeto (SAN/s): Estos no son importantes para Webex, pero deben ser valores que los humanos pueden leer y asociar con el dispositivo. El nombre común se mostrará a otros participantes de la reunión como la identidad verificada principal del dispositivo, y si los usuarios inspeccionarán el certificado a través de la interfaz de usuario de la reunión, verán los SAN/s. Es posible que quiera usar nombres como name.model@example.com pero es su elección.

  • Formato de archivo: Los certificados y las claves deben tener formato .pem.

  • Propósito: El propósito del certificado debe ser La identidad de Webex.

  • Generando claves: Los certificados deben basarse en pares de claves ECDSA P-256 (Algoritmo de firmas digitales de curvas elípticas utilizando la curva P-256).

    Este requisito no se extiende a la clave de firma. La CA puede usar una clave RSA para firmar el certificado.

Puede saltear este paso si no desea utilizar identidad verificada externamente con sus dispositivos.

Si está utilizando dispositivos nuevos, aún no insc inscripción en Webex. Es más seguro ni siquiera conectarlos a la red todavía.

Si tiene dispositivos existentes que desea actualizar para utilizar identidad verificada externamente, tendrá que restablecer los dispositivos a los valores de fábrica.

  • Guarde la configuración existente si quiere mantenerla.

  • Planije una ventana cuando los dispositivos no se estén utilizando, o utilice un enfoque en etapas. Notifique a los usuarios sobre los cambios que pueden esperar.

  • Garantice el acceso físico a los dispositivos. Si tiene que acceder a los dispositivos por la red, tenga en cuenta que la experiencia de los grupos se está desplazando en texto sin formato y está comprometer su seguridad.

Para asegurarse de que cualquier persona no pueda cifrar los medios de su dispositivo, excepto el dispositivo, debe cifrar la clave privada del dispositivo. Hemos diseñado las API para el dispositivo a modo de permitir la administración de la clave cifrada y del certificado mediante el cifrado web JSON (JWE).

Para garantizar un verdadero cifrado de extremo a extremo a través de nuestra nube, no podemos involucrarnos en la cifrado y carga del certificado y la clave. Si necesita este nivel de seguridad, el onus está on usted para:

  • Solicite sus certificados.

  • Genere sus pares de claves de certificados.

  • Cree (y proteja) un secreto inicial para cada dispositivo para usar la capacidad de cifrado del dispositivo.

  • Desarrolle y mantenga su propia herramienta para cifrar archivos mediante el estándar JWE.

    A continuación, le explicamos el proceso y los parámetros (sin secretos) que necesitará, y una receta que debe seguir en sus herramientas de desarrollo que prefiera. También ofrecemos algunos datos de prueba y los resultados de la prueba de JWE como esperamos que los ayude a verificar su proceso.

    Una implementación de referencia no compatible que utiliza Python3 y la biblioteca JWCrypto está disponible en Cisco a pedido.

  • Concatenar y cifrar el certificado y la clave mediante su herramienta y el secreto inicial del dispositivo.

  • Cargue el archivo JWE resultante en el dispositivo.

  • Defina el propósito del certificado cifrado que se utilizará para la identidad de Webex y active el certificado.

  • (Recomendado) Proporcione una interfaz para (o distribuir) su herramienta a fin de permitir que los usuarios del dispositivo cambien el secreto inicial (para proteger sus medios de usted).

Cómo utilizamos el formato JWE

Esta sección describe cómo esperamos que se cree la JWE como entrada a los dispositivos, para que pueda crear su propia herramienta para crear los recursos a partir de sus certificados y claves.

Tendrá que referirse a JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516 y JSON Web Signature (JWS).https://datatracker.ietf.org/doc/html/rfc7515

Elegimos utilizar la serrial compacta de un documento JSON para crear recursos reserva de JWE. Los parámetros que necesitará incluir al crear las características de JWE son los siguientes:

  • Encabezado JOSE (protegido). En el encabezado De firma de objetos JSON y cifrado, DEBE incluir los siguientes pares de valor de clave:

    • "alg":"dir"

      El algoritmo directo es el único que admitemos para cifrar la carga, y debe utilizar el secreto inicial del cliente del dispositivo.

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

      Se admiten estos dos algoritmos de cifrado.

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

      Esta es una clave de propiedad y cuatro valores que puede tomar. Hemos introducido esta clave para señalizar el propósito de los datos cifrados en el dispositivo de destino. Los valores se llaman después de los comandos de xAPI en el dispositivo donde está utilizando los datos cifrados.

      Lo llamamos cisco-action para mitigar posibles conflictos con extensiones JWE futuras.

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

      Otra clave de propiedad. Utilizamos los valores que proporciona como entradas para la derivación de claves en el dispositivo. El mensaje version debe ser 1(la versión de nuestra función de derivación de claves). El valor de salt debe ser una secuencia base de 4 bytes codificados en URL, que debe elegir aleatoriamente.

  • Clave cifrada JWE. Este campo está vacío. El dispositivo lo deriva de la ClientSecret.

  • Vector de inicialización JWE. Debe suministrar un vector de inicialización codificado en base64url para descifrar la carga. El IV DEBE ser un valor aleatorio de 12 bytes (estamos utilizando la familia de cifrado AES-GCM, que requiere que el IV tenga 12 bytes de longitud).

  • JWE AAD (datos autenticados adicionales). Debe omitir este campo porque no es compatible con la Ser jsonización compacta.

  • Texto cifradoJWE: Esta es la carga cifrada que desea mantener en secreto.

    La carga puede estar vacía (Por ejemplo, para restablecer el secreto del cliente, usted debe sobrescribirlo con un valor vacío).

    Hay diferentes tipos de cargas, según lo que intente hacer en el dispositivo. Distintos comandos de xAPI esperan diferentes cargas, y debe especificar el propósito de la carga con la cisco-action como se muestra a continuación:

    • Con "cisco-action":"populate" el texto cifrado es el nuevo ClientSecret

    • Con " "cisco-action":"add" el texto cifrado es un PEM pem que lleva el certificado y su clave privada (concatenada)

    • Con " "cisco-action":"activate" el texto cifrado es la huella digital (representación hexadecimal de sha-1) del certificado que estamos activando para la verificación de identificación del dispositivo

    • Con " "cisco-action":"deactivate" el texto cifrado es la huella digital (representación hexadecimal de sha-1) del certificado que estamos desactivando del que se está utilizando para la verificación de la identidad del dispositivo

  • Etiqueta de autenticación JWE: Este campo contiene la etiqueta de autenticación para garantizar la integridad de todo JWE compactamente reorial

Cómo derivamos la clave de cifrado del ClientSecret

Después de la primera población del secreto, no aceptamos ni generamos el secreto como texto sin formato. Esto es para evitar posibles ataques del diccionario de alguien que podría acceder al dispositivo.

El software del dispositivo utiliza el secreto del cliente como entrada a una función de derivación de claves (kdf) y luego utiliza la clave derivada para el descifrado/cifrado de contenido en el dispositivo.

Lo que esto significa para usted que su herramienta para producir JWE debe seguir el mismo procedimiento para derivar la misma clave de cifrado/descifrado del secreto del cliente.

Los dispositivos utilizan scrypt para la derivación de claves (consulte https://en.wikipedia.org/wiki/Scrypt), con los siguientes parámetros:

  • Cost Hr (N) es 32768

  • BlockSizeSize (r) es 8

  • Paraleloización Mi (p) es 1

  • La sal es una secuencia aleatoria de al menos 4 bytes; debe suministrar este mismo salt al especificar la cisco-kdf/qb.

  • La longitud de las claves es de 16 bytes (si selecciona el algoritmo AES-GCM 128) o de 32 bytes (si selecciona el algoritmo AES-GCM 256)

  • La capacidad máxima de memoria es 64 MB

Este conjunto de parámetros es la única configuración de la encriptación que es compatible con la función de derivación de claves en los dispositivos. Este kdf de los dispositivos se llama "version":"1", que es la única versión actualmente de la cisco-kdf/qb.

Ejemplo funcionad

A continuación, se muestra un ejemplo que puede seguir para verificar que su proceso de cifrado JWE funcione de la misma manera que el proceso que creamos en los dispositivos.

La situación de ejemplo es agregar un PEM al dispositivo (imite a agregar un certificado, con una cadena muy corta en lugar de una tecla + certificado completo). El secreto del cliente en el ejemplo es ossifrage.

  1. Elija un cifrado de cifrado. Este ejemplo usa A128GCM(AES con claves de 128 bits en el modo contador de Galois). Su herramienta podría usarse A256GCM si lo prefiere.

  2. Elija una sal (debe ser una secuencia aleatoria de al menos 4 bytes). Este ejemplo usa (bytes hexadecimales) E5 E6 53 08 03 F8 33 F6. Base64url codifica la secuencia para obtener 5eZTCAP4M_Y(elimine el relleno base64).

  3. A continuación, se muestra una muestra scrypt llamar para crear el contenido clave de cifrado (cek):

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

    La clave derivada debe ser de 16 bytes (hexadecimal) de la siguiente manera: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac que base64url codifica a lZ66bdEiAQV4_mqdInj_rA.

  4. Elija una secuencia aleatoria de 12 bytes para usar como vector de inicialización. Este ejemplo usa (hexadecimal) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 que base64url codifica a NLNd3V9Te68tkpWD.

  5. Cree el encabezado JOSE con inicialización compacta (siga el mismo orden de parámetros que utilizamos aquí) y luego codificada con base64url:

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

    El encabezado JOSE codificado en base64url es eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Este será el primer elemento del elemento JWE después.

  6. El segundo elemento de la JWE después está vacío, porque no estamos suministrando un archivo JWE clave de cifrado.

  7. El tercer elemento de la JWE es el vector de inicialización NLNd3V9Te68tkpWD.

  8. Utilice su herramienta de cifrado JWE para generar una carga y una etiqueta cifradas. Para este ejemplo, la carga no cifrada será el pem pem falso this is a PEM file

    Los parámetros de cifrado que debe utilizar son los siguientes:

    • La carga es this is a PEM file

    • El cifrado es AES 128 GCM

    • El encabezado JOSE codificado en base64url como datos autenticados adicionales (AAD)

    Base64url codifica la carga cifrada, que debería generar f5lLVuWNfKfmzYCo1YJfODhQ

    Este es el cuarto elemento (texto de cifrado JWE) en el JWE después.

  9. Base64url codifica la etiqueta que produjo en el paso 8, lo que debería generar PE-wDFWGXFFBeo928cfZ1Q

    Este es el quinto elemento de la lista JWE.

  10. Concatena los cinco elementos de JWE concatenados con puntos (JOSEheader. IV.Ciphertext.Tag) para obtener:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Si deriva los mismos valores codificados en base64url que mostramos aquí, mediante sus propias herramientas, estará en disposición de utilizarlos para asegurar el cifrado E2E e identidad verificada de sus dispositivos.

  12. En realidad, este ejemplo no funcionará, pero, en principio, su próximo paso sería utilizar la JWE que creó anteriormente como entrada al xcommand del dispositivo que agrega el certificado:

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

Hay nuevos tipos de sesión para reuniones sin confianza que estamos implementando en todos los sitios de reuniones sin ningún costo adicional. Uno de los nuevos tipos de sesión se llama Pro-End to End Encryption_VOIPonly. Este es el nombre de servicio público que podemos cambiar en el futuro. Para ver los nombres actuales de los tipos de sesión, consulte LOS IDs del tipo de sesión en la sección Referencia de este artículo.

No hay nada que tenga que hacer para obtener la nueva funcionalidad para su sitio, pero tendrá que otorgar el nuevo tipo de sesión (también llamado Privilegio de reunión) a los usuarios. Puede hacerlo individualmente a través de la página de configuración del usuario, o en forma masiva con una exportación/importación de CSV de ida y vuelta.

1

Inicie sesión en Control Hub y abra la página Reunión.

2

Haga clic en el nombre de su sitio para abrir el panel de configuración del sitio.

3

Haga clic en Configurar sitio.

4

En el área Configuración común, haga clic en Tipos desesión.

En esa página debería ver uno o más tipos de sesiones de cifrado de extremo a extremo. Consulte la lista de LOS IDs del tipo de sesión en la sección Referencia de este artículo. Por ejemplo, puede ver las pantallas De extremo a extremo Encryption_VOIPonly.

 

Hay una versión anterior tipo de sesión con un nombre muy similar: Cifrado de extremo a extremopro . Esta tipo de sesión incluye acceso no cifrado PSTN reuniones. Asegúrese de tener la versión _VOIPonly para garantizar el cifrado de extremo a extremo. Puede comprobar desplazando el mouse sobre el enlace PRO en la columna de código de sesión; para este ejemplo, el destino del enlace debe ser javascript:ShowFeature(652).

Podemos cambiar los nombres de servicio público para estos tipos de sesiones en el futuro; por ejemplo, planeamos cambiar El Pro-End a Fin Encryption_VOIPonly el Cifrado E2E + Identidad.

5

Si aún no tiene la nueva tipo de sesión, comuníquese con su representante de Webex.

Qué hacer a continuación

Habilite este privilegio tipo de sesión reunión/reunión para algunos o todos sus usuarios.

1

Haga clic en Usuarios y seleccione un usuario para abrir el panel de configuración del usuario.

2

En el área Servicios, haga clic en Cisco Webex Meetings.

3

Seleccione el sitio (si el usuario está en más de uno) y haga clic en Organizar.

4

Marque la casilla junto al campo Webex Meetings etiqueta Pro-End to End Encryption_VOIPonly.

5

Cierre el panel de configuración del usuario.

6

Repita estos pasos para otros usuarios si es necesario.

Si quiere asignar esto a muchos usuarios, utilice la opción csv masiva.

1

Inicie sesión en Control Hub en https://admin.webex.com y abra la página Reunión.

2

Haga clic en el nombre de su sitio para abrir el panel de configuración del sitio.

3

En la sección Licencias y usuarios, haga clic en Administrar en cantidad.

4

Haga clic en Exportar y espere mientraspreparamos el archivo.

5

Cuando el archivo esté listo, haga clic en Exportar resultados y, a continuación, en Descargar. (Debe cerrar manualmente esa ventana emergente después de hacer clic Descargar.)

6

Abra el archivo CSV descargado para editarlo.

Hay una fila para cada usuario, y el MeetingPrivilege contiene los identificadores tipo de sesión personas como una lista delimitada por comas.

7

Para cada usuario al que desee otorgar el nuevo tipo de sesión, agregue 1561 como un nuevo valor de la lista delimitada por comas en MeetingPrivilege celda.

La referencia de formato de archivo CSV en https://help.webex.com/en-us/5vox83 tiene algunos detalles sobre el propósito y el contenido del archivo CSV.

8

Abra el panel configuración del sitio de reuniones en Control Hub.

Si ya estaba en la página de lista de sitios de Meeting, es posible que deba actualizarla.

9

En la sección Licencias y usuarios, haga clic en Administrar de forma masiva.

10

Haga clic en Importar y seleccione el CSV editado y, a continuación, haga clic en Importar. Espere mientras cargamos el archivo.

11

Cuando la importación haya finalizado, puede hacer clic en Importar resultados para revisar si hubo algún error.

12

Vaya a la página Usuarios y abra uno de los usuarios para verificar que tengan el nuevo tipo de sesión.

Si sus dispositivos ya están incorporados a su organización de Control Hub, y desea utilizar la CA de Webex para generar automáticamente sus certificados de identificación, no es necesario que restablezca los dispositivos a sus valores de fábrica.

Este procedimiento selecciona qué dominio utiliza el dispositivo para identificarse a sí mismo, y solo es necesario si usted tiene varios dominios en su organización de Control Hub. Si tiene más de un dominio, le recomendamos que lo haga para todos sus dispositivos que tengan identidades "verificadas por Cisco". Si no le dice a Webex qué dominio identifica el dispositivo, elegimos uno y es posible que los otros participantes de la reunión vean incorrectamente.

Antes de comenzar

Si sus dispositivos todavía no están incorporados, puede seguir https://help.webex.com/n25jyr8 o https://help.webex.com/nutc0dy. También debe verificar el dominio/s que desea utilizar para identificar los dispositivos (https://help.webex.com/cd6d84).

1

Inicie sesión en Control Hub (https://admin.webex.com) y abra la página Dispositivos.

2

Seleccione un dispositivo para abrir su panel de configuración.

3

Seleccione el dominio que desea utilizar para identificar este dispositivo.

4

Repita estos pasos para otros dispositivos.

Antes de comenzar

Te hace falta:

  • Para obtener un certificado firmado por una CA y una clave privada, en formato .pem, para cada dispositivo.

  • Para leer el tema Qué es el proceso de identidad externa para losdispositivos , en la parte Preparar de este artículo.

  • Para preparar una herramienta de cifrado JWE con respecto a la información que se encuentra allí.

  • Una herramienta para generar secuencias de bytes aleatorios de determinadas longitudes.

  • Una herramienta para codificar bytes o texto en base64url.

  • Un scrypt Implementación.

  • Una palabra o frase secreta para cada dispositivo.

1

Completar el dispositivo ClientSecret con un secreto de texto sin formato:

La primera vez que complete el Secret, puede suministrarlo en texto sin formato. Es por ello que le recomendamos que lo haga en la consola del dispositivo físico.

  1. Base64url codifica la frase secreta para este dispositivo.

  2. Abra el TShell en el dispositivo.

  3. Ejecutar xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    El comando de ejemplo anterior completa la Secret con la frase 0123456789abcdef. Tiene que elegir el suyo.

El dispositivo tiene su secreto inicial. No olvide esto, no puede recuperarlo y debe restablecer el dispositivo a sus valores de fábrica para volver a iniciarlo.
2

Concatenar su certificado y su clave privada:

  1. Utilice un editor de texto, abra los archivos .pem, pegue la clave después del certificado y guárdelo como un nuevo archivo .pem.

    (Este es el texto de carga que cifrará y colocará en su JWE después)

3

Cree un archivo JWE to use como entrada para el comando para agregar certificado:

  1. Crear una secuencia aleatoria de al menos 4 bytes. Esta es su sal.

  2. Derive un archivo de clave de cifrado con su herramienta de cifrado.

    Para esto necesita el secreto, la sal y una llavero para que coincida con el cifrado que eligió. Hay algunos otros valores fijos para suministrar (N=32768, r=8, p=1). El dispositivo utiliza el mismo proceso y valores para derivar el mismo contenido clave de cifrado.

  3. Cree una secuencia aleatoria de exactamente 12 bytes. Este es su vector de inicialización.

  4. Crear un encabezado JOSE, configuración alg, enc, y cisco-kdf claves como se describe en Qué es el proceso de identidad externa para los dispositivos. Configure la acción "agregar" con la tecla key:value "cisco-action":"add" en su encabezado JOSE (porque estamos agregando el certificado al dispositivo).

  5. Base64url codifica el encabezado JOSE.

  6. Utilice su herramienta de cifrado JWE con el cifrado elegido y el encabezado JOSE codificado en base64url para cifrar el texto del archivo pem concatenado.

  7. Base64url codifica el vector de inicialización, la carga de PEM cifrada y la etiqueta de autenticación.

  8. Construir la JWE como se muestra a continuación (todos los valores están codificados en base64url):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Abra el TShell en el dispositivo y ejecute el comando para agregar (multilínea):

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

Verifique que el certificado se agregó mediante la ejecución xcommand Security Certificates Services Show

Copie la huella digital del nuevo certificado.

6

Active el certificado con el fin WebexIdentity:

  1. Lea la huella digital del certificado, ya sea desde el certificado en sí o desde el resultado de xcommand Security Certificates Services Show.

  2. Cree una secuencia aleatoria de al menos 4 bytes, y base64url codifica esa secuencia. Esta es su sal.

  3. Derive un archivo de clave de cifrado con su herramienta de cifrado.

    Para esto necesita el secreto, la sal y una llavero para que coincida con el cifrado que eligió. Hay algunos otros valores fijos para suministrar (N=32768, r=8, p=1). El dispositivo utiliza el mismo proceso y valores para derivar el mismo contenido clave de cifrado.

  4. Cree una secuencia aleatoria de exactamente 12 bytes, y base64url codifica esa secuencia. Este es su vector de inicialización.

  5. Crear un encabezado JOSE, configuración alg, enc, y cisco-kdf claves como se describe en Qué es el proceso de identidad externa para los dispositivos. Configure la acción "activar" con la tecla key:value "cisco-action":"activate" en su encabezado JOSE (porque estamos activando el certificado en el dispositivo).

  6. Base64url codifica el encabezado JOSE.

  7. Utilice su herramienta de cifrado JWE con el cifrado elegido y el encabezado JOSE codificado en base64url para cifrar la huella digital del certificado.

    La herramienta debe generar una secuencia de 16 o 32 bytes, según si eligió AES-GCM de 128 o 256 bits y una etiqueta de autenticación.

  8. Base64code la huella digital cifrada y la etiqueta de autenticación.

  9. Construir la JWE como se muestra a continuación (todos los valores están codificados en base64url):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Abra el TShell en el dispositivo y ejecute el siguiente comando de activación:

    xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
El dispositivo tiene un certificado cifrado, activo, emitido por una CA, listo para ser utilizado para identificarlo en reuniones de Webex cifradas de extremo a extremo.
7

Incorpore el dispositivo a su organización de Control Hub.

1

Planificar una reunión del tipo correcto ( Webex Meetings De extremo aextremo Encryption_VOIPonly).

2

Entre a la reunión como el anfitrión, desde un Webex Meetings cliente.

3

Entre a la reunión desde un dispositivo que tenga su identidad verificada por la CA de Webex.

4

Como el host, verifique que este dispositivo aparezca en la sala de recepción con el icono de identidad correcto.

5

Entre a la reunión desde un dispositivo que tenga su identidad verificada por una CA externa.

6

Como el host, verifique que este dispositivo aparezca en la sala de recepción con el icono de identidad correcto.

7

Entrar a la reunión como un participante de reuniones no autenticadas.

8

Como el anfitrión, verifique que este participante aparezca en la sala de recepción con el icono de identidad correcto.

9

Como el anfitrión, admita o rechace personas/dispositivos.

10

Valide las identidades de los participantes/dispositivos cuando sea posible, verificando los certificados.

11

Verifique que todas las personas en la reunión vea el mismo código de seguridad de la reunión.

12

Entrar a la reunión con un participante nuevo.

13

Verifique que todos los usuarios puedan ver lo mismo con el nuevo código de seguridad de la reunión.

¿Va a hacer que las reuniones cifradas de extremo a extremo sean la opción de reunión predeterminada, o la habilitará solo para algunos usuarios, o permitir que todos los organizadores decidan? Cuando haya decidido cómo utilizará esta característica, prepare a los usuarios que la utilizarán, especialmente con respecto a las limitaciones y qué esperar en la reunión.

¿Necesita asegurarse de que ni Cisco ni nadie más puedan descifrar su contenido o suplantar sus dispositivos? De ser así, necesitará certificados de una CA pública. Solo puede tener hasta 25 dispositivos en una reunión segura. Si necesita este nivel de seguridad, no debe permitir que los clientes de reuniones entren.

En el caso de los usuarios que se unen con dispositivos seguros, permita que los dispositivos entren primero y establezca expectativas del usuario de que tal vez no puedan entrar si ingresan más tarde.

Si tiene diversos niveles de verificación de identidad, permita que los usuarios se verifiquen entre sí con identidad con respaldo de certificado y el código de seguridad de la reunión. Aunque existen circunstancias en las que los participantes pueden aparecer como No verificados, y los participantes deben saber cómo comprobar, es posible que las personas no verificadas no sean impostores.

Si está utilizando una CA externa para emitir los certificados de su dispositivo, el usuario está usando para monitorear, actualizar y volver a aplicar los certificados.

Si creó el secreto inicial, comprenda que sus usuarios podrían querer cambiar el secreto de su dispositivo. Es posible que deba crear una interfaz/distribuir una herramienta para que pueda hacerlo.

Tabla 1. IDs de tipo de sesión para reuniones cifradas de extremo a extremo

ID del tipo de sesión

Nombre del servicio público

638

Solo cifrado E2E VoIP electrónico

652

Versión de extremo a extremo Encryption_VOIPonly

660

Versión de extremo a extremo de Pro 3 Encryption_VOIPonly

Cifrado E2E + Identidad

672

Versión de extremo a extremo de Pro 3 Encryption_VOIPonly

673

Instructor de educación E2E Encryption_VOIPonly

676

Broadworks Standard más cifrado de extremo a extremo

677

Broadworks Premium más cifrado de extremo a extremo

681

Método gratuito más cifrado de extremo a extremo

Estas tablas describen los comandos de la API de los dispositivos de Webex que agregamos para las reuniones cifradas de extremo a extremo y la identidad verificada. Para obtener más información sobre el uso de la API, consulte https://help.webex.com/nzwo1ok.

Tabla 2. API de nivel del sistema para reuniones cifradas de extremo a extremo e identidad verificada

Llamada a API

Descripción

xConfiguration Conference EndToEndEncryption Mode: On

Turn end to end encryption mode (Finaliza el modo de cifrado de extremo a extremo) On o Off.

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Esta configuración se realiza cuando el administrador define el dominio preferido del dispositivo desde Control Hub. Solo es necesario si la organización tiene más de un dominio.

El dispositivo utiliza este dominio cuando solicita un certificado de la CA de Webex. El dominio identifica el dispositivo.

Esta configuración no se aplica cuando el dispositivo tiene un certificado emitido externamente para identificarse.

xStatus Conference EndToEndEncryption Availability

Indica si el dispositivo puede entrar a una reunión cifrada de extremo a extremo. La API en la nube lo llama para que una aplicación emparejada sepa si puede usar el dispositivo para entrar.

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Indica si el dispositivo tiene un certificado emitido externamente válido.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

La identidad del dispositivo tal como se lee en el Nombre común del certificado emitido externamente.

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Lee la información del certificado del certificado emitido externamente y la genera como un json.

xStatus Conference EndToEndEncryption InternalIdentity Valid

Indica si el dispositivo tiene un certificado válido emitido por la CA de Webex.

xStatus Conference EndToEndEncryption InternalIdentity Identity

La identidad del dispositivo como se lee en el Nombre común del certificado emitido por Webex.

contiene un nombre de dominio si la organización tiene un dominio.

Está vacío si la organización no tiene un dominio.

Si el dispositivo está en una organización que tiene varios dominios, este es el valor del campo PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Lee la información del certificado del certificado emitido por Webex y la genera como json.

Tabla 3. API de llamadas para reuniones cifradas de extremo a extremo e identidad verificada

Llamada a API

Descripción

xStatus Call # ServerEncryption Type

Lee el cifrado de cifrado utilizado en la conexión HTTPS a Webex. Esto se muestra al usuario.

xStatus Conference Call # EndToEndEncryption Status

Lee el estado del cifrado de extremo a extremo de las llamadas. Se muestra al usuario como la presencia (o ausencia) del icono de candado.

xStatus Conference Call # EndToEndEncryption SecurityCode

Lee el código de seguridad de la reunión. Esto se muestra al usuario, y cambia cuando los participantes entren.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Lee el cifrado de cifrado utilizado en la conexión de medios. Esto se muestra al usuario.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Lee el cifrado de cifrado utilizado para la Seguridad de capa de mensajería (ML).

xStatus Conference Call # EndToEndEncryption Roster Participant

Enumera los participantes contribuyentes al estado del grupo MLS en esta reunión. La lista se descubre porMLS, no Por Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

La URL WDM de un participante especificado.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

El estado de verificación del participante especificado.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

La identidad primaria del participante especificado, generalmente un dominio (dispositivo) o una dirección de correo electrónico (usuario).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

El nombre para mostrar del participante especificado. Firmado por el participante/dispositivo.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

La información del certificado del certificado del participante especificado como un archivo JSON.

xCommand Conference ParticipantList Search

Hemos extendido este comando para incluir información de cifrado de extremo a extremo para los participantes.

xCommand Conference ParticipantList Search

La búsqueda de la lista de participantes ahora incluye EndToEndEncryptionStatus, el estado de verificación de identidad del participante. Este valor se muestra en la interfaz de usuario.

xCommand Conference ParticipantList Search

La búsqueda de la lista de participantes ahora incluye EndToEndEncryptionIdentity, la identidad principal del participante. Suele ser un dominio o una dirección de correo electrónico. Este valor se muestra en la interfaz de usuario.

xCommand Conference ParticipantList Search

La búsqueda de la lista de participantes ahora incluye EndToEndEncryptionCertInfo, el JSON que contiene el certificado del participante. Este valor se muestra en la interfaz de usuario.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

Estos tres eventos ahora incluyen EndToEndEncryptionStatus, EndToEndEncryptionIdentity, y EndToEndEncryptionCertInfo para el participante afectado.

Tabla 4. Api relacionadas con ClientSecre para reuniones cifradas de extremo a extremo e identidad verificada

Llamada a API

Descripción

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

Acepta un valor de texto sin formato codificado en base64url para sesar el secreto del cliente en el dispositivo por primera vez.

Para actualizar el secreto después de esa primera vez, debe suministrar un archivo JWE que contenga el nuevo secreto cifrado por el antiguo secreto.

xCommand Security Certificates Services Add JWEblob

Agrega un certificado (con clave privada).

Hemos extendido este comando para aceptar un archivo JWE que contenga los datos PEM cifrados.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Activa un certificado específico para WebexIdentity. Para este Purpose, el comando requiere la identificación de la huella digital para encriptarse y cargarse en un archivo anterior de JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Desactiva un certificado específico para WebexIdentity. Para este Purpose, el comando requiere la identificación de la huella digital para encriptarse y cargarse en un archivo anterior de JWE.