Gracias por sus comentarios.
¿Comentarios?
Los usuarios eligen el tipo de reunión cuando programan una reunión. Al admitir participantes desde el lobby, así como durante la reunión, el anfitrión 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 a todos los participantes actuales en la reunión, que pueden usar para verificar que su reunión no ha sido interceptada por un ataque no deseado de terceros Meddler In The Middle (MITM).
Comparta la siguiente información con los anfitriones de su reunión:
-
Programe una reunión de Webex con cifrado de extremo a extremo
-
Únase a una reunión de Webex con cifrado de extremo a extremo
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 MLS (Messaging Layer Security) compartido, presentan sus certificados a los otros miembros del grupo, quienes luego validan los certificados frente a las Autoridades de Certificación (CA) emisores. 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 Webex App se autentican en el almacén de identidades de Webex, que les emite un token de acceso cuando la autenticación se realiza correctamente. 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 proporcionamos una manera para que Webex Meetings los usuarios obtengan un certificado emitido por una CA de tercera/externa.
Los dispositivos pueden autenticarse mediante un certificado emitido por la CA interna (Webex) o un certificado emitido por una CA externa:
-
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 Webex CA. 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 de dispositivo (Nombre común (CN)).
-
CA externo: solicite y compre certificados de dispositivo directamente de su emisor elegido. Debe encriptar, subir directamente y autorizar los certificados usando un secreto que solo conoce usted.
Cisco no está involucrado, lo que hace que esta sea la manera de garantizar un cifrado verdadero de extremo a extremo y la identidad verificada, y evitar la posibilidad teórica de que Cisco pueda escabullir su reunión o descifrar sus medios.
Certificado de dispositivo emitido internamente
Webex emite un certificado al dispositivo cuando se registra después del inicio y lo renueva cuando es necesario. Para dispositivos, el certificado incluye el ID de 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 usar Control Hub para decirle a Webex qué dominio utilizará el dispositivo para su identidad. También podría usar la API XConfiguration Conference endToEndEncryption Identity PreferredDomain: “example.com”.
Si tiene varios dominios y no establece el dominio preferido para el dispositivo, entonces Webex elige uno para usted.
Certificado de dispositivo emitido externamente
Un administrador puede aprovisionar un dispositivo con su propio certificado firmado con una de las CA públicas.
El certificado debe basarse en un par de claves ECDSA P-256, aunque puede estar firmado 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 separado por dispositivo y tener un CN único por dispositivo. Por ejemplo, “sala de reunión-1.example.com” para la organización propietaria del dominio “example.com”.
Con el fin de proteger completamente el certificado externo de la manipulación, se utiliza una función de secreto del cliente para cifrar y firmar varios comandos.
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 está limitado a dispositivos en línea.
Webex actualmente proporciona comandos de API para administrar esto.
Dispositivos
Los dispositivos Cisco Board, Desk y Room Series registrados en la nube pueden unirse a las reuniones de E2EE.
Los siguientes dispositivos no pueden unirse a las reuniones de E2EE:
-
Dispositivos SIP de terceros
Clientes de software
-
La aplicación Webex para equipos de escritorio y clientes móviles puede unirse a las reuniones de E2EE.
-
El cliente web de Webex no puede unirse a las reuniones de E2EE.
-
Los clientes de terceros SIP soft no pueden unirse a las reuniones de E2EE.
Identidad
-
Por diseño, no proporcionamos opciones de Control Hub para que pueda administrar la identidad del dispositivo verificada externamente. Para un verdadero cifrado de extremo a extremo, solo usted debe conocer/acceder a los secretos y claves. Si introdujimos un servicio en la nube para administrar esas claves, existe la posibilidad de que sean interceptadas.
-
Actualmente le proporcionamos una “receta” para que diseñe sus propias herramientas, basadas en técnicas de cifrado estándar de la industria, para ayudarle a solicitar o cifrar los certificados de identidad de su dispositivo y sus claves privadas. No queremos tener ningún acceso real o percibido a sus secretos o claves.
Reuniones
-
Las reuniones E2EE actualmente admiten un máximo de 1000 participantes.
- Puede compartir nuevas pizarras blancas en las reuniones de E2EE. Hay algunas diferencias con las pizarras blancas en las reuniones regulares:
- En las reuniones E2EE, los usuarios no pueden acceder a pizarras creadas fuera de la reunión, incluidas las pizarras privadas, las pizarras compartidas por otros y las pizarras blancas de los espacios Webex.
- Las pizarras creadas en reuniones E2EE solo están disponibles durante la reunión. No se guardan y no son accesibles después de que la reunión ha terminado.
- Si alguien comparte contenido en una reunión de E2EE, puede anotarlo. Para obtener más información sobre anotaciones, consulte Webex App | Marcar contenido compartido con anotaciones.
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 una identidad centralizada para toda la organización.
Información relacionada
-
Seguridad de confianza cero para Webex (documento técnico de seguridad)
-
Cifrado web JSON (JWE) (Borrador del estándar IETF)
-
Webex Meetings41.7.
-
Dispositivos Cisco Board, Desktop y Room Series registrados en la nube, que ejecutan
10.6.1ROOMOS_August_2021 o posterior. -
Acceso administrativo al sitio de reunión en Control Hub.
-
Uno o más dominios verificados en su organización de Control Hub (si utiliza la CA de Webex para emitir certificados de dispositivo para la identidad verificada).
-
Las salas de reuniones de colaboración deben estar activadas para que las personas puedan unirse desde su sistema de video. Para obtener más información, consulte Permitir que los sistemas de video se unan a reuniones y eventos en su sitio de Webex.
Puede omitir este paso si no necesita identidades verificadas externamente.
Para obtener el más alto nivel de seguridad y para la verificación de identidad, cada dispositivo debe tener un certificado único emitido por un público de confianza Certificate Authority (CA).
Necesita interactuar con la CA para solicitar, comprar y recibir los certificados digitales y crear las claves privadas asociadas. Cuando solicite el certificado, utilice estos parámetros:
-
El certificado debe ser emitido y firmado por una CA pública conocida.
-
Único: Le recomendamos encarecidamente que utilice un certificado único para cada dispositivo. Si utiliza un certificado para todos los dispositivos, está comprometiendo su seguridad.
-
Nombre común (CN) y Nombre alternativo del asunto (SAN/S): Estos no son importantes para Webex, pero deben ser valores que los humanos puedan leer y asociar con el dispositivo. El CN se mostrará a otros participantes de la reunión como la identidad verificada principal del dispositivo, y si los usuarios inspeccionan el certificado a través de la interfaz de usuario de la reunión, verán los SAN/s. Es posible que desee usar nombres como
name.model@example.com. -
Formato de archivo: Los certificados y claves deben estar en el
formato.pem. -
Propósito: El propósito del certificado debe ser Webex Identity.
-
Generación de claves: Los certificados deben basarse en pares de claves ECDSA P-256 (Algoritmo de firma digital de curva elíptica 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 quiere usar una identidad verificada externamente con sus dispositivos.
Si está utilizando nuevos dispositivos, no los registre en Webex todavía. Para estar seguro, no los conecte a la red en este momento.
Si tiene dispositivos existentes que desea actualizar para usar una identidad verificada externamente, debe restablecer los dispositivos de fábrica.
-
Guarde la configuración existente si quiere conservarla.
-
Programe una ventana cuando los dispositivos no se estén utilizando, o utilice un enfoque por fases. Notifique a los usuarios de los cambios que pueden esperar.
-
Asegure el acceso físico a los dispositivos. Si tiene que acceder a los dispositivos a través de la red, tenga en cuenta que los secretos viajan en texto plano y está comprometiendo su seguridad.
Una vez que haya completado estos pasos, permita que los sistemas de video se unan a reuniones y eventos en su sitio de Webex.
Para asegurarse de que los medios de su dispositivo no puedan ser cifrados por nadie, excepto el dispositivo, debe cifrar la clave privada en el dispositivo. Diseñamos API para el dispositivo para 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 participar en el cifrado y la carga del certificado y la clave. Si necesita este nivel de seguridad, debe:
-
Solicite sus certificados.
-
Genere los pares de claves de sus certificados.
-
Cree (y proteja) un secreto inicial para cada dispositivo, para aumentar la capacidad de cifrado del dispositivo.
-
Desarrolle y mantenga su propia herramienta para cifrar archivos utilizando 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 elección. También proporcionamos algunos datos de pruebas y las manchas JWE resultantes como las esperamos, para ayudarle a verificar su proceso.
Una implementación de referencia no compatible con Python3 y la biblioteca JWCrypto está disponible en Cisco a pedido.
-
Concatene y encripte el certificado y la clave usando su herramienta y el secreto inicial del dispositivo.
-
Cargue la blob JWE resultante en el dispositivo.
-
Establezca el propósito del certificado cifrado que se utilizará para la identidad de Webex y active el certificado.
-
(Recomendado) Proporcione una interfaz (o distribuya) su herramienta para permitir que los usuarios del dispositivo cambien el secreto inicial y protejan sus medios de usted.
Cómo usamos el formato JWE
Esta sección describe cómo esperamos que el JWE se cree como entrada a los dispositivos, para que pueda crear su propia herramienta para crear los blobs a partir de sus certificados y claves.
Consulte JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 y JSON Web Signature (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 necesita incluir al crear los blobs de JWE son:
-
Cabecera JOSE (protegido). En el encabezado Firma y cifrado de objetos JSON, DEBE incluir los siguientes pares de clave y valor:
-
“alg” :"dir”El algoritmo directo es el único que admitimos para cifrar la carga útil, y debe usar el secreto inicial del cliente del dispositivo.
-
“enc” :"A128GCM” o “enc” :"A256GCM”Apoyamos estos dos algoritmos de cifrado.
-
“cisco-action”: “agregar” o “cisco-action”: “poblar” o “cisco-action”: “activar”o “cisco-action”: “desactivar”Esta es una clave patentada y cuatro valores que puede tomar. Introdujimos esta clave para indicar el propósito de los datos cifrados al dispositivo de destino. Los valores llevan el nombre de los comandos xAPI del dispositivo en el que está utilizando los datos cifrados.
Lo denominamos
cisco-actionpara mitigar posibles enfrentamientos con futuras extensiones de JWE. -
“cisco-kdf”: {“version”: “1", “salt”: “base64URLEncodeDrandom4+bytes”}Otra clave patentada. Usamos los valores que proporciona como entradas para la derivación de claves en el dispositivo. La
versióndebe ser1(la versión de nuestra función de derivación clave). El valor de lasaldebe ser una secuencia codificada en 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
ClientSecretinicial. -
Vector de inicialización JWE. Debe proporcionar un vector de inicialización codificado base64url para descifrar la carga útil. El IV DEBE ser un valor aleatorio de 12 bytes (estamos usando la familia de cifrado AES-GCM, que requiere que IV tenga una longitud de 12 bytes).
-
JWE AAD (datos autenticados adicionales). Debe omitir este campo porque no es compatible con la serialización compacta.
-
JWE Ciphertext: Esta es la carga útil cifrada que quiere 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 útiles, dependiendo de lo que esté tratando de hacer en el dispositivo. Los diferentes comandos XAPI esperan cargas útiles diferentes, y debe especificar el propósito de la carga útil con la clave
cisco-action, de la siguiente manera:-
Con“cisco-action” :"rellenar”el texto cifrado es el nuevo ClientSecret. -
Con "
“cisco-action” :"add”el texto cifrado es un blob PEM que contiene 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 la identidad del dispositivo. -
Con "
“cisco-action” :"deactivate”, 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 determinar la integridad de todo el blob serializado de forma compacta de JWE
Cómo derivamos la clave de cifrado del ClientSecret
Después de la primera población del secreto, no aceptamos ni mostramos el secreto como texto sin formato. Esto es para evitar posibles ataques de diccionario por parte de alguien que pueda 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, a continuación, utiliza la clave derivada para el descifración/cifrado de contenido en el dispositivo.
Lo que esto significa para usted es que su herramienta para producir blobs 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:
-
El factor de costo (N) es 32768
-
BlockSizeFactor (r) es 8
-
El factor de paralelización (p) es 1
-
La sal es una secuencia aleatoria de al menos 4 bytes; debe proporcionar esta misma
salal especificar el parámetrocisco-kdf. -
Las longitudes de clave son 16 bytes (si selecciona el algoritmo AES-GCM 128) o 32 bytes (si selecciona el algoritmo AES-GCM 256)
-
El límite máximo de memoria es de 64 MB
Este conjunto de parámetros es la única configuración de scrypt que es compatible con la función de derivación clave en los dispositivos. Este kdf en los dispositivos se llama “version” :"1", que es la única versión actualmente tomada por el parámetro cisco-kdf.
Ejemplo resuelto
Aquí hay un ejemplo que puede seguir para verificar que su proceso de cifrado JWE funciona igual que el proceso que creamos en los dispositivos.
El escenario de ejemplo es agregar un blob PEM al dispositivo (imita agregar un certificado, con una cadena muy corta en lugar de una clave cert + completa). El secreto del cliente en el ejemplo es el ossifrage.
-
Elija un cifrado de cifrado. En este ejemplo se utiliza
A128GCM(AES con claves de 128 bits en el modo contador Galois). Su herramienta podría usarA256GCMsi lo prefiere. -
Elija una sal (debe ser una secuencia aleatoria de al menos 4 bytes). Este ejemplo utiliza (bytes hexademales)
E5 E6 53 08 03 F8 33 F6. Base64URL codifique la secuencia para obtener5EZTCAP4M_Y(elimine el relleno base64). -
Aquí hay una llamada
scryptde ejemplo para crear la clave de cifrado de contenido (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 en Lz66bDEIAQV4_mqdinj_ra. -
Elija una secuencia aleatoria de 12 bytes para usar como vector de inicialización.
Este ejemplo utiliza (hex)34 b3 5d dd 5f 53 7b af 2d 92 95 83que base64url codifica para nlnd3v9te68tkpwd. -
Cree el encabezado JOSE con serialización compacta (siga el mismo orden de parámetros que usamos aquí) y luego base64url codifique:
{"alg” :"dir”, "cisco-action” :"add”, "cisco-kdf”: {"salt” :"5EZTCAP4M_Y”, "version” :"1"}, "enc” :"A128GCM "}El encabezado JOSE codificado en base64url es eyJHBGcioIJkaXiILcjjaXnjby1hy3rPB24ioijHzgqILcjjaXnjby1RzGyionSiC2FSDCI6IJvVLwlrdqva0tv9ziiWidmVyc2LVbii6ijeifswizw5jijoiqteyoeddtsJ9Este será el primer elemento de la blob de JWE.
-
El segundo elemento del blob de JWE está vacío, porque no estamos suministrando una clave de cifrado JWE.
-
El tercer elemento del blob de JWE es el vector de inicialización nlND3v9TE68tkpwd. - Utilice su herramienta de cifrado JWE para producir una carga útil y una etiqueta cifradas. Para este ejemplo, la carga útil no cifrada va a ser el blob PEM falso,
estees un archivo PEMLos parámetros de cifrado que debe utilizar son:
Carga útil:
este es un archivo PEMEl cifrado de cifrado es AES 128 GCM
El encabezado JOSE codificado base64url como Datos Autenticados Adicionales (AAD)
Base64URL codifica la carga útil cifrada, lo que debería dar como resultado F5llvUWNFKFMZyCO1YJFODHQEste es el cuarto elemento (JWE Ciphertext) en el bloque de JWE.
-
Base64URL codificará la etiqueta que produjo en el paso 8, lo que debería dar como resultado PE-WDFWGXFFBEO928CFZ1QEste es el quinto elemento en el bloque de JWE.
-
Concatene los cinco elementos del bloque de JWE con puntos (JoseHeader.. IV.CipherText.tag) para obtener:
eyJHBGCIoIJKAxiILcJJaxNJBY1HY3RPB24ioIJHzGqILCJJaxNJby1RzGyionSiC2FSDCi6IJvVLWLRDQVA0tv9ZiiWidMVYC2LVbii6IJeifswizW5jijoiqteYoEDDTSJ.. 9nLnd3v9te68tkpwd.C2LvBii6IJeifswizW5jiJoIqteYoEDDTSJ.. 9nLnd3v9te68tkpWd.CJ 5llVUWNFKFMZyCO1YJFODHQ.PE-WDFWGXFFBEO928CFZ1Q -
Si derivó los mismos valores codificados base64url que mostramos aquí, usando sus propias herramientas, está listo para usarlas para asegurar el cifrado E2E y la identidad verificada de sus dispositivos.
-
Este ejemplo no funcionará, pero en principio su siguiente paso sería usar el blob JWE que creó anteriormente como entrada al comando xen el dispositivo que agrega el certificado:
Certificados de seguridad xCommand AgregarEYJHBGCIoIJKAxiILcJJaxNJBY1HY3rPB24IoijHzGqILcJJaxNJby1RzGyionSiC2fSDCI6IJvLwlrdQva0tv9ZiiWidmVYC2LVBII6IJeifswizW5jiJoIqteYoEDDTSJ.. 9nLnd3VteRtEr 68TKPWD.f5LLvuWNFKFMZyCO1YJFODHQ.PE-WDFWGXFFBEO928CFZ1Q
Los tipos de sesiones 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-End to End End Encryption_VoipOnly. Este es el nombre del servicio público, que podemos cambiar en el futuro. Para obtener los nombres actuales de los tipos de sesión, consulte ID de tipo de sesión en la sección Referencia de este artículo.
No hay nada que necesite hacer para obtener esta capacidad para su sitio; necesita 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 de forma masiva con una exportación/importación CSV.
| 1 |
Inicie sesión en Control Hub y vaya a . |
| 2 |
Haga clic en Sitios, elija el sitio de Webex para el que desea cambiar la configuración y, a continuación, haga clic en Configuración. |
| 3 |
En Configuración común, seleccione Tipos de sesión. Debería ver uno o más tipos de sesión de cifrado de extremo a extremo. Consulte la lista de ID de tipo de sesión en la sección Referencia de este artículo. Por ejemplo, puede ver Pro-End to End Encryption_VoipOnly.
Hay un tipo de sesión más antiguo con un nombre muy similar: Pro-End to End End End End Encryption. Este tipo de sesión incluye acceso PSTN no cifrado a las reuniones. Asegúrese de tener la versión _VoIPOnly para garantizar el cifrado de extremo a extremo. Puede comprobarlo colocando el cursor sobre el enlace PRO en la columna de código de sesión; para este ejemplo, el destino del enlace debe ser Podemos cambiar los nombres de servicio público para estos tipos de sesiones en el futuro. |
| 4 |
Si aún no tiene el nuevo tipo de sesión, comuníquese con su representante de Webex. |
Qué hacer a continuación
Habilite este tipo de sesión/privilegio de reunión para algunos o todos sus usuarios.
| 1 |
Inicie sesión en Control Hub y vaya a . |
| 2 |
Seleccione una cuenta de usuario para actualizar y, a continuación, seleccione Reuniones. |
| 3 |
En la lista desplegable Configuración se aplica a, seleccione el sitio de reunión que desea actualizar. |
| 4 |
Marque la casilla junto a Pro-End to End Encryption_VoipOnly. |
| 5 |
Cierre el panel de configuración del usuario. |
| 6 |
Repita 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 vaya a . |
| 2 |
Haga clic en Sitios, elija el sitio de Webex para el que desea cambiar la configuración. |
| 3 |
En la sección Licencias y usuarios, haga clic en Administración 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 luego en Descargar. (Tiene que 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 |
| 7 |
La Referencia del formato de archivo CSV de Webex contiene detalles sobre el propósito y el contenido del archivo CSV. |
| 8 |
Abra el panel de configuración del sitio de reunión en Control Hub. Si ya estaba en la página de lista del sitio de la reunión, es posible que necesite actualizarla. |
| 9 |
En la sección Licencias y usuarios, haga clic en Administración 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 finalice la importación, 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 tienen el nuevo tipo de sesión. |
Puede agregar una marca de agua a las grabaciones de reuniones con el tipo de sesión Webex MeetingsPro-End to End End Encryption_VoipOnly, que le permite identificar el cliente o dispositivo de origen de grabaciones no autorizadas de reuniones confidenciales.
Cuando esta función está habilitada, el audio de la reunión incluye un identificador único para cada cliente o dispositivo participante. Puede subir grabaciones de audio a Control Hub, que luego analiza la grabación y busca los identificadores únicos. Puede ver los resultados para ver qué cliente o dispositivo de origen grabó la reunión.
- Para ser analizada, la grabación debe ser un archivo AAC, MP3, M4A, WAV, MP4, AVI o MOV de no más de 500 MB.
- La grabación debe durar más de 100 segundos.
- Solo puede analizar grabaciones de 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
- Inicie sesión en Control Hub y, a continuación, en Administración, seleccione Configuración de la organización.
- En la sección Marcas de agua de la reunión, seleccione Agregar marca de agua de audio.
Algún tiempo después de que se active esto, los usuarios que programen reuniones con el tipo de sesión
Webex MeetingsPro-End to End Encryption_VoIPOnly, vean una opción de Marca de agua digital en la sección Seguridad.
Cargue y analice una reunión con marca de agua
- En Control Hub, en Monitoreo, seleccione Solución de problemas.
- Haga clic en Análisis de marca de agua.
- Busque o seleccione la reunión en la lista y, a continuación, haga clic en Analizar.
- En la ventana Analizar marca de agua de audio, escriba un nombre para su análisis.
- (Opcional) Escriba una nota para su análisis.
- Arrastre y suelte el archivo de audio que se va a analizar, o haga clic en Elegir archivo para buscar el archivo de audio.
- Haga clic en Cerrar.
Cuando se complete el análisis, se mostrará en la lista de resultados en la página Analizar marca de agua.
- Seleccione la reunión en la lista para ver los resultados del análisis. Haga clic
para descargar los resultados.
Características y Limitaciones
Los factores involucrados en la decodificación exitosa de una marca de agua grabada incluyen la distancia entre el dispositivo de grabación y el altavoz que produce el audio, el volumen de ese audio, el ruido ambiental, etc. Nuestra tecnología de marcas de agua tiene capacidad de recuperación adicional para ser codificada varias veces, como podría suceder cuando se comparten los medios.
Esta función está diseñada para permitir una decodificación exitosa del identificador de 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é acostado en un escritorio cerca de un terminal personal o un cliente de computadora portátil, siempre debe crear una grabación que resulte en un análisis exitoso. A medida que el dispositivo de grabación se aleja de la fuente o se ve oscurecido al escuchar todo el espectro de audio, las posibilidades de un análisis exitoso disminuyen.
Para analizar con éxito 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 hospeda al cliente, no deberían aplicarse limitaciones.
Si sus dispositivos ya están integrados en su organización de Control Hub y desea utilizar la CA de Webex para generar automáticamente sus certificados de identificación, no necesita restablecer los dispositivos de fábrica.
Este procedimiento selecciona qué dominio utiliza el dispositivo para identificarse, y solo es necesario si tiene varios dominios en su organización de Control Hub. Si tiene más de un dominio, le recomendamos que haga esto para todos sus dispositivos que tengan una identidad “verificada por Cisco”. Si no le dice a Webex qué dominio identifica el dispositivo, se elige uno automáticamente y puede parecer incorrecto para otros participantes de la reunión.
Antes de comenzar
Si sus dispositivos aún no están integrados, siga Registrar un dispositivo para Cisco Webex usar API o interfaz web local o integración en la nube para las series Board, Desktop y Room. También debe verificar los dominios que desea usar 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 CA y una clave privada, en
formato.pem, para cada dispositivo. -
En la pestaña Preparar, lea el tema Descripción del proceso de identidad externa para dispositivos,
-
Prepare una herramienta de cifrado JWE con respecto a la información allí.
-
Asegúrese de tener una herramienta para generar secuencias de bytes aleatorias de longitudes dadas.
-
Asegúrese de tener una herramienta para codificar bytes o texto en base64url.
-
Asegúrese de que tiene una implementación de
Scrypt. -
Asegúrese de tener una palabra o frase secreta para cada dispositivo.
| 1 |
Complete el La primera vez que llene el El dispositivo tiene su secreto inicial. No olvide esto; no puede recuperarlo y debe restablecer de fábrica el dispositivo para volver a arrancar.
|
| 2 |
Concatene su certificado y su clave privada: |
| 3 |
Cree un blob JWE para usarlo como entrada al comando certificate add: |
| 4 |
Abra la TShell en el dispositivo y ejecute el comando de adición (multilínea): |
| 5 |
Verifique que el certificado se haya agregado ejecutando Copie la huella digital del nuevo certificado. |
| 6 |
Active el certificado para el propósito El dispositivo tiene un certificado cifrado, activo y emitido por la CA, listo para ser utilizado para identificarlo en reuniones Webex cifradas de extremo a extremo.
|
| 7 |
Intere el dispositivo a su organización de Control Hub. |
| 1 |
Programe una reunión del tipo correcto (Webex MeetingsEnd to End Encryption_VoipOnly). |
| 2 |
Únase a la reunión como anfitrión, de un Webex Meetings cliente. |
| 3 |
Únase a la reunión desde un dispositivo que tiene su identidad verificada por Webex CA. |
| 4 |
Como anfitrión, verifique que este dispositivo aparezca en el vestíbulo con el icono de identidad correcto. |
| 5 |
Únase a la reunión desde un dispositivo que tenga su identidad verificada por una CA externa. |
| 6 |
Como anfitrión, verifique que este dispositivo aparezca en el vestíbulo con el icono de identidad correcto. Obtenga más información sobre los iconos de identidad. |
| 7 |
Únase a la reunión como participante de reuniones no autenticado. |
| 8 |
Como anfitrión, verifique que este participante aparezca en el vestíbulo con el icono de identidad correcto. |
| 9 |
Como anfitrión, admita o rechace personas/dispositivos. |
| 10 |
Valide las identidades de los participantes/dispositivos siempre que sea posible comprobando los certificados. |
| 11 |
Verifique que todos en la reunión vean el mismo código de seguridad de la reunión. |
| 12 |
Únase a la reunión con un nuevo participante. |
| 13 |
Verifique que todos vean el mismo código de seguridad para reuniones nuevo. |
-
¿Va a hacer que las reuniones cifradas de extremo a extremo sean la opción de reunión predeterminada, o habilitarla solo para algunos usuarios o permitir que todos los anfitriones decidan? Cuando haya decidido cómo va a utilizar esta función, prepare a los usuarios que la usarán, especialmente con respecto a las limitaciones y qué esperar en la reunión.
-
¿Necesita asegurarse de que ni Cisco ni nadie más pueda descifrar su contenido o hacerse pasar por sus dispositivos? Si es así, necesita certificados de una CA pública.
-
Si tiene diferentes niveles de verificación de identidad, permita que los usuarios se verifiquen entre sí con identidad respaldada por certificado. A pesar de que hay circunstancias en las que los participantes pueden aparecer como no verificados y los participantes deben saber cómo verificar, las personas no verificadas pueden no ser impostoras.
Si está utilizando una CA externa para emitir los certificados de su dispositivo, le corresponde a usted supervisar, actualizar y volver a aplicar los certificados.
Si creó el secreto inicial, comprenda que sus usuarios pueden querer cambiar el secreto de su dispositivo. Es posible que necesite crear una interfaje/distribuir una herramienta para permitirles hacer esto.
|
ID de tipo de sesión |
Nombre del servicio público |
|---|---|
|
638 |
Cifrado E2E+VoIP solamente |
|
652 |
Cifrado pro-extremo a extremo _VoIP Only |
|
660 |
Cifrado de extremo a extremo de Pro 3 - VoIP Only Cifrado E2E + Identidad |
|
672 |
Pro 3 Free50 Cifrado de extremo a extremo (solo VoIP) |
|
673 |
Instructor de educación E2E Encryption_VoIP Only |
|
676 |
Broadworks Standard más cifrado de extremo a extremo |
|
677 |
Broadworks Premium más cifrado de extremo a extremo |
|
681 |
Schoology Free más cifrado de extremo a extremo |
Estas tablas describen los comandos API de dispositivos Webex que agregamos para reuniones cifradas de extremo a extremo e identidad verificada. Para obtener más información sobre cómo usar la API, consulte Acceder a la API para dispositivos de las series Board, Desk y Room.
Estos comandos XAPI solo están disponibles en dispositivos que son:
-
Registrado en Webex
-
Registrado en las instalaciones y vinculado a Webex con Webex Edge para dispositivos
|
Llamada a la API |
Descripción |
|---|---|
|
|
Esta configuración se realiza cuando el administrador establece 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 Webex CA. A continuación, el dominio identifica el dispositivo. Esta configuración no es aplicable cuando el dispositivo tiene un certificado activo emitido externamente para identificarse. |
|
|
Indica si el dispositivo puede unirse a una reunión cifrada de extremo a extremo. La API de la nube lo llama para que una aplicación emparejada sepa si puede usar el dispositivo para unirse. |
|
|
Indica si el dispositivo utiliza verificación |
|
|
La identidad del dispositivo tal como se lee en el nombre común del certificado emitido externamente. |
|
|
Lee información específica de un certificado expedido externamente. En el comando que se muestra, reemplace
|
|
|
El estado de la identidad externa del dispositivo (por ejemplo, |
|
|
Indica si el dispositivo tiene un certificado válido emitido por Webex CA. |
|
|
La identidad del dispositivo tal 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 |
|
|
Lee información específica del certificado emitido por Webex. En el comando que se muestra, reemplace
|
|
Llamada a la API |
Descripción |
|---|---|
|
|
|
Llamada a la API |
Descripción |
|---|---|
o
| Acepta un valor de texto plano codificado en base64url para generar el secreto del cliente en el dispositivo por primera vez. Para actualizar el secreto después de esa primera vez, debe proporcionar un blob JWE que contenga el nuevo secreto cifrado por el antiguo secreto. |
| Agrega un certificado (con clave privada). Ampliamos este comando para aceptar un blob JWE que contiene los datos PEM cifrados. |
| Activa un certificado específico para WebExIdentity. Para este |
| Desactiva un certificado específico para WebExIdentity. Para este |
