Los usuarios eligen el tipo de reunión cuando planifican una reunión. Al admitir participantes desde la sala de recepción, así como durante la reunión, el organizador puede ver el estado de verificación de identidad de cada participante. También hay un código de reunión que es común para todos los participantes actuales de la reunión, que pueden utilizar para verificar que su reunión no haya sido interceptada por un ataque Meddler In The Middle (MITM) de terceros no deseados.

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

Verificar identidad

El cifrado de extremo a extremo con 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 de MLS (Messaging Layer Security) compartido, presentan sus certificados a los demás miembros del grupo, que luego los validan con las autoridades de emisión de certificados (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 de la aplicación Webex se autentican con el almacén de identidades de Webex, que les emite un token de acceso cuando la autenticación tiene éxito. Si necesitan un certificado para verificar su identidad en una reunión cifrada de extremo a extremo, la CA de Webex les emite un certificado basado en su token de acceso. En este momento, no ofrecemos una forma para que los usuarios de Webex Meetings 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:

  • CA interna: Webex emite un certificado interno basado en el token de acceso de la cuenta de la 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, por lo que Webex utiliza (uno de) los dominios de su organización al escribir la identidad del certificado del dispositivo (nombre común [CN]).

  • CA externa: solicite y compre certificados de dispositivo directamente del emisor elegido. Debe cifrar, cargar directamente y autorizar los certificados mediante un secreto conocido solo por usted.

    Cisco no participa, lo que hace que esta sea la manera de garantizar el verdadero cifrado de extremo a extremo y la identidad verificada, e impedir la posibilidad teórica de que Cisco pueda espiar su reunión/descifrar sus 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 decirle a Webex qué dominio debe utilizar el dispositivo para su identidad. También puede utilizar la API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "ejemplo.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.

Recomendamos usar un certificado independiente por dispositivo y tener un CN único por dispositivo. Por ejemplo, “meeting-room-1.example.com” para la organización que posee el 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 de forma segura el certificado de identidad externo de Webex a través de xAPI. Actualmente, esto se limita a dispositivos en línea.

Actualmente, Webex proporciona comandos de la API para administrar esto.

Dispositivos

Los siguientes dispositivos de la serie Webex Room y de la serie Webex Desk registrados en la nube pueden entrar a reuniones de E2EE:

  • Webex Board

  • Webex Desk Pro

  • Escritorio de Webex

  • Webex Room Kit

  • Webex Room Kit Mini

Los siguientes dispositivos no pueden entrar a reuniones de E2EE:

  • Serie Webex C

  • Serie Webex DX

  • Serie EX de Webex

  • Serie MX de Webex

  • Dispositivos SIP de otros proveedores

Clientes de software

  • La aplicación de Webex para clientes móviles y de escritorio puede entrar a reuniones de E2EE.

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

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

Identidad

  • Por diseño, no ofrecemos opciones de Control Hub para que usted administre la identidad de dispositivos verificados externamente. Para un verdadero cifrado de extremo a extremo, solo usted debe conocer/acceder a los secretos y claves. Si incorporamos un servicio en la nube para administrar esas claves, existe la posibilidad de que sean interceptadas.

  • Actualmente le ofrecemos una "receta" para que diseñe sus propias herramientas, basadas en técnicas de cifrado estándar del sector, para ayudarle a solicitar o cifrar los certificados de identidad de su dispositivo y sus claves privadas. No queremos tener un acceso real o percibido a sus teclas o la inversión.

Reuniones

  • Actualmente, las reuniones de E2EE admiten un máximo de 1000 participantes.

  • Puede compartir pizarras blancas nuevas en las reuniones de E2EE. Hay algunas diferencias con las pizarras blancas en las reuniones regulares:
    • En las reuniones de E2EE, los usuarios no pueden acceder a las pizarras creadas fuera de la reunión, incluidas las pizarras privadas, las pizarras compartidas por otras personas y las pizarras blancas de los espacios de Webex.
    • Las pizarras blancas creadas en las reuniones de E2EE solo están disponibles durante la reunión. No se guardan y no se puede acceder a ellos una vez finalizada la reunión.
    • Si alguien comparte contenido en una reunión de E2EE, puede realizar anotaciones. Para obtener más información sobre los comentarios, consulte Aplicación de Webex | Marcar contenido compartido con comentarios.

Interfaz de administración

Le recomendamos encarecidamente que utilice Control Hub para administrar su sitio de reuniones, ya que las organizaciones de Control Hub tienen identidad centralizada para toda la organización.

  • Webex Meetings 41.7.

  • Dispositivos de las series Webex Room y Webex Desk registrados en la nube, que ejecutan 10.6.1-RoomOS_August_2021.

  • Acceso administrativo al sitio de la reunión en Control Hub.

  • 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).

  • Las salas de reuniones de colaboración deben estar activadas para que las personas puedan entrar desde su sistema de vídeo. Para obtener más información, consulte Permitir que los sistemas de vídeo entren a reuniones y eventos en su sitio de Webex.

Puede omitir este paso si no necesita identidades verificadas externamente.

Para el nivel más alto de seguridad y para la verificación de identidad, cada dispositivo debe tener un certificado único emitido por una autoridad de certificación (CA) 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, utilice estos parámetros:

  • 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 desee utilizar nombres como name.model@example.com.

  • 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 omitir este paso si no desea utilizar la identidad verificada externamente con sus dispositivos.

Si está utilizando dispositivos nuevos, aún no insc inscripción en Webex. Para estar seguros, no los conecte a la red en este momento.

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

  • Guarde la configuración existente si desea conservarla.

  • Plante 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.

Una vez que haya completado estos pasos, permita que los sistemas de vídeo entren a reuniones y eventos en su sitio de Webex.

Para asegurarse de que cualquier persona no pueda cifrar los medios de su dispositivo, excepto el dispositivo, debe cifrar la clave privada del dispositivo. Diseñamos API para el dispositivo con el fin de permitir la administración de la clave cifrada y el certificado, utilizando JSON Web Encryption (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, debe:

  1. Solicite sus certificados.

  2. Genere sus pares de claves de certificados.

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

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

    El proceso y los parámetros (no secretos) que necesitará se explican a continuación, así como una receta a seguir en sus herramientas de desarrollo de su elección. 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.

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

  6. Cargue el archivo JWE resultante en el dispositivo.

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

  8. (Recomendado) Proporcione una interfaz para (o distribuya) su herramienta para permitir que los usuarios del dispositivo cambien el secreto inicial y protejan sus medios de usted.

Cómo utilizamos el formato JWE

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

Consulte Cifrado web de JSON (JWE) https://datatracker.ietf.org/doc/html/rfc7516 y Firma web de JSON (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Utilizamos la serialización compacta de un documento JSON para crear blobs JWE. Los parámetros que debe incluir al crear los blobs JWE son:

  • 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":"A GCM"

      Se admiten estos dos algoritmos de cifrado.

    • "cisco-action": "agregar" o "cisco-action": "llenar" o "cisco-action": "activar" o "cisco-action": "desactivar"

      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 enfrentamientos con futuras extensiones de JWE.

    • "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. La versión debe ser 1 (la versión de nuestra función de derivación clave). El valor de salt debe ser una secuencia codificada por URL base64 de al menos 4 bytes, que debe elegir al azar.

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

  • Vector de inicialización de 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 cifrado JWE: Esta es la carga cifrada que desea mantener en secreto.

    La carga útil PUEDE estar vacía. Por ejemplo, para restablecer el secreto del cliente, debe sobrescribirlo con un valor vacío.

    Hay diferentes tipos de cargas, según lo que intente hacer en el dispositivo. Los diferentes comandos xAPI esperan diferentes cargas útiles, y debe especificar el propósito de la carga útil con la clave cisco-action , de la siguiente manera:

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

    • Con ""cisco-action":"add" el texto cifrado es un blob 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 identidad del dispositivo.

    • Con ""cisco-action":"desactivar" el texto cifrado es la huella digital (representación hexadecimal de sha-1) del certificado que estamos desactivando para que no se utilice para la verificación de 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 de 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 de diccionario por parte 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 esta misma sal al especificar el parámetro cisco-kdf .

  • 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 en los dispositivos se llama "versión":"1", que es la única versión que utiliza actualmente el parámetro cisco-kdf .

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 de cliente en el ejemplo es ossifrage.

  1. Elija un cifrado de cifrado. En este ejemplo se utiliza A128GCM (AES con claves de 128 bits en el modo contador de Galois). La herramienta podría utilizar UN GCM si lo prefiere.

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

  3. Aquí hay una llamada de ejemplo scrypt para crear la clave de cifrado de contenido (cek):

    cek=scrypt(password="ossifrage", salt=secuencia de 4 bytes, 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 lZ66bdEiAQV4_mqdInj_rA.

  4. Elija una secuencia aleatoria de 12 bytes para usar como vector de inicialización. En este ejemplo se utiliza (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 , que base64url codifica 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 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 del bloque 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 útil no cifrada será el bloque PEM falso este es un archivo PEM

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

    • La carga útil es este es un archivo PEM

    • El cifrado es AES 128 GCM

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

    Base64url codifica la carga útil cifrada, lo que debería dar lugar a f5lLVuWNfKfmzYCo1YJfODhQ

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

  9. Base64url codifica la etiqueta que ha producido en el paso 8, lo que debería dar lugar a 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:

    Certificados de seguridad de xCommand Agregar eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Los tipos de sesión para reuniones de confianza cero están disponibles para todos los sitios de reuniones sin costo adicional. Uno de estos tipos de sesión se llama Pro de extremo a extremo Encryption_VOIP. Este es el Nombre del 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 tiene que hacer nada para obtener esta capacidad para su sitio; sí tiene que otorgar el nuevo tipo de sesión (también llamado Privilegio de la 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.

1

Inicie sesión en Control Hub y, a continuación, vaya a Servicios > Reuniones.

2

Haga clic en Sitios, elija el sitio Webex para el que desee cambiar la configuración y, a continuación, haga clic en Configuraciones.

3

En Configuración común, seleccione Tipos de sesión.

4
Debería ver uno o más tipos de sesión 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, es posible que vea VoI De extremo a extremo en ncryption_formaresponsable.

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

Es posible que cambiemos los nombres de servicio público para estos tipos de sesiones en el futuro.

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

Inicie sesión en Control Hub y vaya a Administración > Usuarios.

2

Seleccione una cuenta de usuario para actualizar y, a continuación, seleccione Reuniones.

3

En la lista desplegable Configuración aplicada a , seleccione el sitio de la reunión que desea actualizar.

4

Marque la casilla junto a Pro-End to End Encryption_VOIPonly (Solo VoIP de extremo a extremo).

5

Cierre el panel de configuración del usuario.

6

Repita estos pasos para otros usuarios si es necesario.

Para asignar esto a muchos usuarios, utilice la siguiente opción, Habilitar reuniones E2EE para varios usuarios.

1

Inicie sesión en Control Hub y, a continuación, vaya a Servicios > Reuniones.

2

Haga clic en Sitios y elija el sitio de Webex para el que desea cambiar la configuración.

3

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

4

Haga clic en Generar informe y espere mientras preparamos 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 en Descargar).

6

Abra el archivo CSV descargado para editarlo.

Hay una fila para cada usuario y la columna MeetingPrivilege contiene sus ID de tipo de sesión como una lista delimitada por comas.

7

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

La Referencia de formato de archivo CSV de Webex contiene 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 se carga 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.

Puede agregar una marca de agua a las grabaciones de reuniones con el tipo de sesión Webex Meetings Pro de extremo a extremo Encryption_VOIPonly , que le permite identificar el cliente o dispositivo de origen de las grabaciones no autorizadas de las reuniones confidenciales.

Cuando esta característica está habilitada, el audio de la reunión incluye un identificador único para cada cliente o dispositivo participante. Puede cargar grabaciones de audio en Control Hub, que luego analiza la grabación y busca los identificadores únicos. Puede ver los resultados para ver qué dispositivo o cliente de origen grabó la reunión.

  • Para ser analizada, la grabación debe ser un archivo AAC, MP3, M4A, WAV, MP4, AVI o MOV no superior a 500 MB.
  • La grabación debe durar más de 100 segundos.
  • Solo puede analizar las grabaciones de las reuniones organizadas por personas de su organización.
  • La información de la marca de agua se conserva durante el mismo tiempo que la información de la reunión de la organización.

Agregar marcas de agua de audio a las reuniones de E2EE

  1. Inicie sesión en Control Hub y, a continuación, en Administración, seleccione Configuración de la organización.
  2. En la sección Marcas de agua de la reunión , active Agregar marca de agua de audio.

    Un tiempo después de que esto se active, los usuarios que planifican reuniones con el tipo de sesión de Solo VoIPncryption_Webex Meetings Pro de extremo a extremo verán una opción de Marcado de agua digital en la sección Seguridad.

Cargar y analizar una reunión con marca de agua

  1. En Control Hub, en Monitoreo, seleccione Solución de problemas.
  2. Haga clic en Análisis de marca de agua.
  3. Busque o seleccione la reunión en la lista y haga clic en Analizar.
  4. En la ventana Analizar marca de agua de audio , introduzca un nombre para el análisis.
  5. (Opcional) Introduzca una nota para su análisis.
  6. Arrastre y suelte el archivo de audio que se va a analizar o haga clic en Elegir archivo para buscar el archivo de audio.
  7. Haga clic en Cerrar.

    Una vez finalizado el análisis, se mostrará en la lista de resultados de la página Analizar marca de agua .

  8. Seleccione la reunión en la lista para ver los resultados del análisis. Haga clic en Botón Descargar para descargar los resultados.

Características y limitaciones

Los factores involucrados en la descodificación exitosa de una marca de agua grabada incluyen la distancia entre el dispositivo de grabación y el altavoz que expulsa el audio, el volumen de ese audio, el ruido ambiental, etc. Nuestra tecnología de marcado de agua tiene una resiliencia adicional al ser codificada varias veces, como puede suceder cuando se comparten los medios.

Esta característica está diseñada para permitir la descodificación exitosa del identificador de la marca de agua en un conjunto amplio pero razonable de circunstancias. Nuestro objetivo es que un dispositivo de grabación, como un teléfono móvil, que esté tumbado en un escritorio cerca de un extremo personal o un cliente portátil, siempre debe crear una grabación que dé como resultado un análisis exitoso. A medida que el dispositivo de grabación se aleja de la fuente o se impide escuchar el espectro de audio completo, disminuyen las posibilidades de un análisis exitoso.

Para analizar correctamente una grabación, se necesita una captura razonable del audio de la reunión. Si el audio de una reunión se graba en la misma computadora que aloja al cliente, no deben aplicarse limitaciones.

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 restablecer los dispositivos a los 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, se elige uno automáticamente y puede parecer incorrecto para los demás participantes de la reunión.

Antes de comenzar

Si sus dispositivos aún no están incorporados, siga Inscribir un dispositivo en Cisco Webex mediante la interfaz web local o la API o Incorporación en la nube para las series Board, Desk y Room. También debe verificar los dominios que desea utilizar para identificar los dispositivos en Administrar sus dominios.

1

Inicie sesión en Control Hub y, en Administración, seleccione 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 para otros dispositivos.

Antes de comenzar

  • Obtenga un certificado firmado por una autoridad de certificación y una clave privada, en formato .pem , para cada dispositivo.

  • En la ficha Preparar , lea el tema Comprensión del proceso de identidad externa para los dispositivos.

  • Prepare una herramienta de cifrado JWE con respecto a la información que contiene.

  • Asegúrese de tener una herramienta para generar secuencias de bytes aleatorios de longitudes dadas.

  • Asegúrese de tener una herramienta para basar bytes o texto de codificación de64url.

  • Asegúrese de tener una implementación de scrypt .

  • Asegúrese de tener una palabra o frase secreta para cada dispositivo.

1

Rellene el ClientSecret del dispositivo con un secreto de texto sin formato:

La primera vez que rellena el Secreto, lo proporciona en texto sin formato. Por eso recomendamos hacerlo 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 Completar secreto: "MDEyMzQ1Njc4OWFiY2RlZg"

    El comando de ejemplo anterior rellena el Secreto 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 de fábrica para que se inicie de nuevo.
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 útil que cifrarás y pondrás en tu blob JWE.

3

Cree un 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 contenido 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. Cree un encabezado JOSE, configure las claves alg, enc y cisco-kdf como se describe en Comprensión del proceso de identidad externa para dispositivos. Configure la acción "agregar" con la clave:value "cisco-action":"add" en el 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 siempre 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 (Servicios de certificados de seguridad): True your..JWE.str.ing\n .\n
5

Verifique que el certificado se agregue ejecutando xcommand Security Certificates Services Show

Copie la huella digital del nuevo certificado.

6

Active el certificado para el propósito WebexIdentity:

  1. Lea la huella digital del certificado, ya sea desde el propio certificado o desde la salida 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 contenido 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. Cree un encabezado JOSE, configure las claves alg, enc y cisco-kdf como se describe en Comprensión del proceso de identidad externa para dispositivos. Configure la acción "activar" con el valor clave "cisco-action":"activar" en el 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 siempre 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:

     Función de activación de los servicios de certificados de seguridad de xcommand: Huella digital de WebexIdentity: "Su..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

Planifite una reunión del tipo correcto ( Webex Meetings VoI De extremo a extremoncryption_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. Obtenga más información sobre los iconos de identidad.

7

Entre 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 comprobando 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, 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.

  • Si tiene distintos niveles de verificación de identidad, permita a los usuarios verificarse entre sí con identidad respaldada por certificados. 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

Responsable de EVOI de extremoncryption_a extremo

660

EVOI de extremo a extremo gratuito dencryption_Pro 3

Cifrado E2E + Identidad

672

EVOI de extremo a extremo de Pro 3 dencryption_extremo a extremo

673

Instructor de educación E2E EVOIncryption_Responsable

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 acerca de cómo utilizar la API, consulte Acceder a la API para dispositivos de Webex Room y de escritorio y Webex Boards.

Estos comandos de xAPI solo están disponibles en dispositivos que:

  • Registrado en Webex

  • Registrado localmente y vinculado a Webex con Webex Edge para dispositivos

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 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.

Disponibilidad de extremo a extremo de cifrado de conferencia xStatus

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.

Verificación de identidad externa de extremo a extremo de cifrado de conferencia xStatus

Indica si el dispositivo utiliza la verificación Externa (tiene un certificado emitido externamente).

xStatus Conferencia EndToEndEncryption ExternalIdentity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # información específica

Lee información específica de un certificado emitido externamente.

En el comando que se muestra, sustituya # por el número del certificado. Reemplace la información específica por una de las siguientes opciones:

  • Huella digital

  • No posterior Fecha de finalización de validez

  • No antes Fecha de inicio de validez

  • Nombre principal

  • Algoritmo de clave pública

  • Número de serie

  • Algoritmo de firma

  • Asunto # Nombre Una lista de los asuntos del certificado (p. ej., dirección de correo electrónico o nombre de dominio)

  • Validez : indica el estado de validez de este certificado (p. ej. válido o caducado)

Estado de identidad externa de extremo a extremo de conferencia xStatus

El estado de la identidad externa del dispositivo (p. ej.: válido o error).

Verificación de identidad interna de extremo a extremo de cifrado de conferencia xStatus

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

Identidad interna de cifrado de extremo a extremo de conferencia xStatus

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 de PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # información específica

Lee información específica del certificado emitido por Webex.

En el comando que se muestra, sustituya # por el número del certificado. Reemplace la información específica por una de las siguientes opciones:

  • Huella digital

  • No posterior Fecha de finalización de validez

  • No antes Fecha de inicio de validez

  • Nombre principal

  • Algoritmo de clave pública

  • Número de serie

  • Algoritmo de firma

  • Asunto # Nombre Una lista de los asuntos del certificado (p. ej., dirección de correo electrónico o nombre de dominio)

  • Validez : indica el estado de validez de este certificado (p. ej. válido o caducado)

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

Llamada a API

Descripción

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Estos tres eventos ahora incluyen EndToEndToEndEncryptionStatus, EndToEndToEndEncryptionIdentity y EndToEndToEndEncryptionCertInfo 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 Completar secreto: JWEblob

Acepta un valor de texto sin formato codificado en base64url para mostrar 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.

Servicios de certificados de seguridad de xCommand Add JWEblob

Agrega un certificado (con clave privada).

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

Los servicios de certificados de seguridad de xCommand activan Purpose:WebexIdentity FingerPrint: JWEblob

Activa un certificado específico para WebexIdentity. Para este Propósito, el comando requiere que la huella digital de identificación esté cifrada y serializada en un blob JWE.

Servicios de certificados de seguridad de xCommand Desactivar Purpose:WebexIdentity FingerPrint: JWEblob

Desactiva un certificado específico para WebexIdentity. Para este Propósito, el comando requiere que la huella digital de identificación esté cifrada y serializada en un blob JWE.