Los usuarios eligen el tipo de reunión cuando planificar una reunión. Al admitir participantes desde el vestíbulo, 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 en la reunión, que pueden utilizar para verificar entre sí.
Comparta la siguiente información con los organizadores de la reunión:
Planifique 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 (seguridad de la capa de Mensajería ) compartido, presentan sus certificados a los otros miembros del grupo, quienes luego validan los certificados con las autoridades de certificación (CA) emisoras. Al confirmar que los certificados son válidos, la CA verifica la identidad de los participantes y la reunión muestra a los participantes / dispositivos como verificados.
Los usuarios de la aplicación Webex 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 un extremo a otro, la CA de Webex les emite un certificado en función de su token de acceso. En este momento, no proporcionamos una forma para que los usuarios de Webex Meetings obtengan un certificado emitido por una CA externa o de terceros.
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 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 usa (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 utilizando un secreto que solo usted conoce.
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 evitar la posibilidad teórica de que Cisco pueda espiar su reunión / descifrar sus medios.
Certificado de dispositivo emitido internamente
Webex emite un certificado para el dispositivo cuando se registra después del inicio y lo renueva cuando es necesario. Para los dispositivos, el certificado incluye el Identificador 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 usar Control Hub para indicarle a Webex qué dominio debe usar el dispositivo para su identidad. También puede utilizar 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 haya 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 del certificado quedan 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 utilizar un certificado separado por dispositivo y tener un CN único por dispositivo. Por ejemplo, "sala de reuniones-1.example.com" para la organización propietaria del dominio "example.com".
Para proteger completamente el certificado externo contra la manipulación, se utiliza una función de secreto de cliente para cifrar y firmar varios comandos x.
Al utilizar el secreto del cliente, es posible administrar de forma segura el certificado de identidad externo de Webex a través de la xAPI. Actualmente, esto está limitado a dispositivos en línea.
Webex actualmente proporciona comandos de API para administrar esto.
Dispositivos
Los siguientes dispositivos de la serie Webex Room y la serie Webex Desk registrados en la nube pueden unirse a reuniones cifradas de un extremo a otro:
Webex Board
Webex Desk Pro
Escritorio de Webex
Webex Room Kit
Webex Room Kit Mini
Los siguientes dispositivos no pueden entrar a reuniones cifradas de un extremo a otro:
Serie C de Webex
Webex DX Series
Serie EX de Webex
Serie MX de Webex
Dispositivos SIP de terceros
Clientes de software
A partir de la versión 41.6, el cliente de escritorio de Webex Meetings puede entrar a reuniones cifradas de un extremo a otro.
Si su organización permite que la Aplicación Webex entre a reuniones iniciando la aplicación de escritorio Meetings, puede usar esa opción para unirse a reuniones cifradas de un extremo a otro.
El cliente web de Webex no puede entrar a reuniones cifradas de un extremo a otro.
Los clientes de software SIP de terceros no pueden entrar a reuniones cifradas de un extremo a otro.
Identidad
Por diseño, no proporcionamos opciones de Control Hub para que usted administre 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, ofrecemos una 'receta' para que diseñe sus propias herramientas, basadas en técnicas de cifrado estándar de la industria, para ayudarlo 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
Actualmente, las reuniones cifradas de un extremo a otro admiten un máximo de 200 participantes.
De esos 200 participantes, un máximo de 25 dispositivos verificados externamente pueden unirse, y deben ser los primeros participantes en unirse a la reunión .
Cuando un mayor número de dispositivos se une a una reunión, nuestros servicios multimedia de back-end intentan transcodificar las transmisiones multimedia. Si no podemos descifrar, transcodificar y volver a cifrar los medios (porque no tenemos ni deberíamos tener las claves de cifrado de los dispositivos), 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, ya que las organizaciones de Control Hub tienen una identidad centralizada para toda la organización, mientras que en la Administración del sitio, la identidad se controla sitio por sitio.
Los usuarios administrados desde la Administración del sitio no pueden tener la opción de identidad verificada por Cisco. A esos usuarios se les emite un certificado anónimo para entrar a una reunión cifrada de un extremo a otro, y pueden ser excluidos de las reuniones en las que el organizador desea garantizar la verificación de identidad.
Información relacionada
Seguridad de confianza cero para Webex (documento técnico de seguridad): https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html
Presentación de Cisco Live 2021 (se requiere registro de Cisco Live): https://www.ciscolive.com/2021/learn/session-catalog.html?tab.digitalbundle=Anytime21&search.sessiontype=BRK&search.learningmap=1614364767910003wzD6#/session/16106298425360015zrh
Cifrado Web JSON (JWE) (Borrador del estándar IETF): https://datatracker.ietf.org/doc/html/rfc7516
Documentación orientada al usuario: https://help.webex.com/5h5d8ab
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 la conferencia en Control Hub, para habilitar el nuevo tipo de sesión para los usuarios.
Uno o más dominios verificados en su organización de Control Hub (si está utilizando 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 entrar desde su sistema de vídeo. Para obtener más información, consulte Permita que los sistemas de vídeo 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 una Certificate Authority (CA) pública de confianza.
Debe 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 reconocida.
Único: Recomendamos encarecidamente utilizar un certificado único para cada dispositivo. Si usa un certificado para todos los dispositivos, está comprometiendo su seguridad.
Nombre común (CN) y nombre alternativo del sujeto (SAN): 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 los demás 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 las SAN. Es posible que desee utilizar nombres como
name.model@example.com.Formato de archivo: Los certificados y las claves deben estar en el
.pemformato.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 firma digital de curva elíptica que utiliza la curva P-256).
Este requisito no se extiende a la clave de firma. La CA puede utilizar una clave RSA para firmar el certificado.
Puede omitir este paso si no desea utilizar una identidad verificada externamente con sus dispositivos.
Si está utilizando dispositivos nuevos, no los registre todavía en Webex . Para estar seguro, 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 de fábrica.
Guarde la configuración existente si desea 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.
Garantizar el acceso físico a los dispositivos. Si debe acceder a dispositivos a través de la red, tenga en cuenta que los secretos viajan en texto sin formato y que está comprometiendo su seguridad.
Una vez que haya completado estos pasos, permitir que los sistemas de vídeo se unan a reuniones y eventos en su Sitio de Webex .
Para asegurarse de que nadie más que el dispositivo pueda cifrar los medios de su dispositivo, debe cifrar la clave privada en el dispositivo. Diseñamos API para el dispositivo para permitir la administración de la clave y el certificado cifrados, 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 generar 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 las herramientas de desarrollo que elija. También proporcionamos algunos datos de prueba y los blobs JWE resultantes como los esperamos, para ayudarlo a verificar su proceso.
Una implementación de referencia no compatible con Python3 y la biblioteca JWCrypto está disponible en Cisco a pedido.
Concatenar y cifrar el certificado y la clave utilizando su herramienta y el secreto inicial del dispositivo.
Cargue el 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 para (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
En esta sección se describe cómo esperamos que se cree el JWE como entrada para los dispositivos, de modo que pueda crear su propia herramienta para crear los blobs a partir de sus certificados y claves.
Consulte Cifrado Web JSON (JWE)https://datatracker.ietf.org/doc/html/rfc7516y Firma Web JSON (JWS)https://datatracker.ietf.org/doc/html/rfc7515.
Usamos el Serialización compacta de un documento JSON para crear blobs JWE. Los parámetros que debe incluir al crear los blobs de JWE son:
JOSE Encabezado (protegido). En el encabezado de cifrado y firma de objetos JSON, DEBE incluir los siguientes pares clave-valor:
"alg":"dir"El algoritmo directo es el único que admitimos para cifrar la carga útil, y debe utilizar el secreto de cliente inicial del dispositivo.
"enc":"A128GCM"o"enc":"A256GCM"Apoyamos estos dos algoritmos de cifrado.
"cisco-action": "add"o"cisco-action": "populate"o"cisco-action": "activate"o"cisco-action": "deactivate"Esta es una clave propietaria y cuatro valores que puede tomar. Introdujimos esta clave para señalar el propósito de los datos cifrados al dispositivo de destino. Los valores reciben el nombre de los comandos xAPI en el dispositivo en el que está utilizando los datos cifrados.
Lo nombramos
cisco-actionpara mitigar posibles conflictos con futuras extensiones de JWE."cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }Otra clave propietaria. Usamos los valores que usted proporciona como entradas para la derivación de claves en el dispositivo. El
versiondebe ser1(la versión de nuestra función de derivación de claves). El valor desaltdebe 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 de la inicial
ClientSecret.Vector de inicialización de JWE . Debe proporcionar un vector de inicialización codificado en 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 el IV tenga 12 bytes de longitud).
JWE AAD (datos autenticados adicionales). Debe omitir este campo porque no es compatible con la serialización compacta.
Texto cifrado JWE : Esta es la carga útil 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 útiles, 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 el
cisco-actionclave, de la siguiente manera:Con
"cisco-action":"populate"el texto cifrado es el nuevoClientSecret.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 la 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 obtenemos 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 luego utiliza la clave derivada para el descifrado / 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 cifrar para la derivación de claves (verhttps://en.wikipedia.org/wiki/Scrypt ), con los siguientes parámetros:
CostFactor (N) es 32768
BlockSizeFactor (r) es 8
ParallelizationFactor (p) es 1
Salt es una secuencia aleatoria de al menos 4 bytes; debes suministrar este mismo
saltal especificar elcisco-kdf/qb.Las longitudes de las claves son 16 bytes (si selecciona el AES-GCM 128) o 32 bytes (si selecciona el AES-GCM 256)
La capacidad máxima de memoria es de 64 MB
Este conjunto de parámetros es la única configuración de cifrar que sea compatible con la función de derivación de claves en los dispositivos. Este kdf en los dispositivos se llama "version":"1", que es la única versión que toma actualmente el cisco-kdf/qb.
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 (simula agregar un certificado, con una cadena muy corta en lugar de un certificado completo + clave). El secreto del cliente en el ejemplo es ossifrage.
Elija un cifrado de cifrado. Este ejemplo utiliza
A128GCM(AES con claves de 128 bits en el modo de contador de Galois). Tu herramienta podría usarA256GCMsi lo prefiere.Elija una sal (debe ser una secuencia aleatoria de al menos 4 bytes). Este ejemplo utiliza (bytes hexadecimales)
E5 E6 53 08 03 F8 33 F6. Base64url codifica la secuencia para obtener5eZTCAP4M_Y(elimine el relleno de base64).Aquí hay una muestra
scryptllamar 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 tener 16 bytes (hexadecimal) de la siguiente manera:
95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff acque codifica base64urllZ66bdEiAQV4_mqdInj_rA.Elija una secuencia aleatoria de 12 bytes para utilizarla como vector de inicialización. Este ejemplo usa (hex)
34 b3 5d dd 5f 53 7b af 2d 92 95 83que codifica base64urlNLNd3V9Te68tkpWD.Cree el encabezado JOSE con serialización compacta (siga el mismo orden de parámetros que usamos aquí) y luego codifíquelo en base64url:
{"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}El encabezado JOSE codificado en base64url es
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9Este será el primer elemento del blob JWE.
El segundo elemento del blob JWE está vacío, porque no estamos proporcionando una clave de clave de cifrado JWE.
El tercer elemento del blob 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 será el blob PEM falso
this is a PEM fileLos parámetros de cifrado que debe utilizar son:
La carga útil es
this is a PEM fileEl cifrado de 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 como resultado
f5lLVuWNfKfmzYCo1YJfODhQEste es el cuarto elemento (texto cifrado JWE) en el blob JWE.
Base64url codifica la etiqueta que produjo en el paso 8, lo que debería dar como resultado
PE-wDFWGXFFBeo928cfZ1QEste es el quinto elemento del blob JWE.
Concatenar los cinco elementos del blob JWE con puntos (JOSEheader..IV.Ciphertext.Tag) para obtener:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1QSi obtuvo los mismos valores codificados en base64url que mostramos aquí, utilizando sus propias herramientas, está listo para usarlos para asegurar el cifrado E2E y la identidad verificada de sus dispositivos.
Este ejemplo en realidad no funcionará, pero en principio su siguiente paso sería utilizar el blob JWE que creó anteriormente como entrada para el xcommand en el dispositivo que agrega el certificado:
xCommand Security Certificates AddeyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..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-End to End Encryption_VOIPonly. Este es el Nombre del servicio público, que podemos cambiar en el futuro. Para conocer los nombres actuales de los tipos de sesión, consulte ID de tipo de sesión en el Referencia sección de este artículo.
No tiene que hacer nada para obtener esta capacidad para su sitio; sí tiene que conceder el nuevo tipo de sesión (también llamado Privilegio de la reunión) a los usuarios. Puede hacerlo de forma individual a través de la página de configuración del usuario o de forma masiva con una exportación / importación de CSV .
| 1 | Inicie sesión en Control Hub y, a continuación, vaya a . | ||
| 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 | Bajo 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 ID de tipo de sesión en el Referencia sección de este artículo. Por ejemplo, puede ver Pro-End to End Encryption_ VOIPonly .
| ||
| 5 | 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 | Iniciar sesión en Centro de control y ve a . |
| 2 | Seleccione una cuenta de usuario para actualizar, luego 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 . |
| 5 | Cierre el panel de configuración de usuario . |
| 6 | Repita para otros usuarios si es necesario. Para asignar esto a muchos usuarios, use la siguiente opción, Habilite las reuniones E2EE para varios usuarios . |
| 1 | Inicie sesión en Control Hub y, a continuación, vaya a . | ||
| 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 luego 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 el | ||
| 7 | Para cada usuario al que desee otorgar el nuevo tipo de sesión, agregue El Referencia de 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 la reunión en Control Hub.
| ||
| 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, luego 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 | Ir a la Usuarios página y abra uno de los usuarios para verificar que tenga el nuevo tipo de sesión. |
Puede agregar una marca de agua a las grabaciones de reuniones con el Webex Meetings Pro-End to End Encryption_VOIPonly tipo de sesión, que le permite identificar el cliente o dispositivo de origen de las grabaciones no autorizadas de 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 que no supere los 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 E2EE
- Inicie sesión en Control Hub, luego, en Administración, seleccione Configuración de la organización.
- En el Reunión de marcas de agua sección, activar Agregar marca de agua de audio .
Un tiempo después de que esto se active, los usuarios planifican reuniones con el
Webex Meetings Pro-End to End Encryption_VOIPonlytipo de sesión, consulte la opción Marcado de agua digital en la sección Seguridad.
Cargar y analizar una reunión con marca de agua
- En Control Hub, debajo 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 haga clic en Analizar.
- En el Analizar marca de agua de audio ventana, introduzca un nombre para su análisis.
- (Opcional) Introduzca una nota para su análisis.
- Arrastre y suelte el archivo de audio que desee analizar, o haga clic en Elegir archivo para buscar el archivo de audio.
- Haga clic en Cerrar.
Cuando el análisis esté completo, se mostrará en la lista de resultados en la Analizar marca de agua página.
- Seleccione la reunión en la lista para ver los resultados del análisis. Haga clic en
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 envía el audio, el volumen de ese audio, el ruido ambiental, etc. Nuestra tecnología de marcado de agua tiene una resiliencia adicional al codificarse 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 configuración 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 tendrán una identidad "verificada por Cisco". Si no le dice a Webex qué dominio identifica el dispositivo, se elige uno automáticamente y puede parecerle incorrecto a otros participantes de la reunión.
Antes de comenzar
Si sus dispositivos aún no están incorporados, siga Registrar un dispositivo en Cisco Webex mediante la API o la interfaz Web local 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 Administra tus dominios .
| 1 | Iniciar sesión en Control Hub y bajo Gestió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
Necesita:
Para obtener un certificado firmado por una CA y una clave privada, en
.pemformato, para cada dispositivo.Para leer el tema Comprensión del proceso de identidad externa para dispositivos , en el Preparar parte de este artículo.
Preparar una herramienta de cifrado JWE con respecto a la información allí.
Una herramienta para generar secuencias de bytes aleatorias de longitudes determinadas.
Una herramienta para codificar bytes o texto en base64url.
Un
scryptimplementación.Una palabra o frase secreta para cada dispositivo.
| 1 | Rellenar el dispositivo La primera vez que rellene el 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 clave privada: |
| 3 | Cree un blob JWE para usarlo como entrada para el comando de adición de certificado: |
| 4 | Abra TShell en el dispositivo y ejecute el comando add (multilínea): |
| 5 | Verifique que el certificado se agregue ejecutando Copie la huella digital del nuevo certificado. |
| 6 | Activar el certificado para el propósito El dispositivo tiene un certificado cifrado, activo y 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 | Programe una reunión del tipo correcto ( Webex Meetings Pro de extremo a extremo Encryption_ VOIPonly ). |
| 2 | Únase a la reunión como organizador, desde un cliente de Webex Meetings . |
| 3 | Únase a la reunión desde un dispositivo cuya identidad haya sido verificada por la CA de Webex . |
| 4 | Como organizador, verifique que este dispositivo aparezca en el vestíbulo con el icono de identidad correcto. |
| 5 | Entre a la reunión desde un dispositivo cuya identidad haya sido verificada por una CA externa. |
| 6 | Como organizador, verifique que este dispositivo aparezca en el vestíbulo con el icono de identidad correcto. Más información sobre los iconos de identidad . |
| 7 | Únase a la reunión como participante no autenticado. |
| 8 | Como organizador, 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 mediante la verificación de los certificados. |
| 11 | Compruebe que todos los participantes de 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 | Compruebe que todos vean el mismo código de seguridad de reunión nuevo. |
¿Va a convertir las reuniones cifradas de extremo a extremo en la opción de reunión predeterminada, o las habilitará solo para algunos usuarios, o permitirá que todos los organizadores decidan? Cuando haya decidido cómo va a utilizar esta función, 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 pueda descifrar su contenido o suplantar sus dispositivos? Si es así, necesita 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 las reuniones entren.
Para los usuarios que se unen con dispositivos seguros, permita que los dispositivos se unan primero y establezca las expectativas de los usuarios de que es posible que no puedan entrar si se unen tarde.
Si tiene distintos niveles de verificación de identidad, permita que los usuarios se verifiquen entre sí con la identidad respaldada por un certificado y el código de seguridad de la reunión. Aunque 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 impostores.
Si está utilizando una CA externa para emitir los certificados de su dispositivo, usted es responsable de supervisar, actualizar y volver a aplicar los certificados.
Si creó el secreto inicial, comprenda que es posible que sus usuarios quieran cambiar el secreto de su dispositivo. Es posible que deba crear una interfaz / distribuir una herramienta para permitirles hacer esto.
Identificador de tipo de sesión | Nombre del servicio público |
|---|---|
638 | Encriptación E2E + VoIP solamente |
652 | Pro-End to End Encryption_ VOIPonly |
660 | Pro 3 de extremo libre a extremo Encryption_ VOIPonly Cifrado E2E + Identidad |
672 | Pro 3 Free50-End to End Encryption_ VOIPonly |
673 | Instructor de educación E2E Encryption_ VOIPonly |
676 | Broadworks Standard más cifrado de extremo a extremo |
677 | Broadworks Premium plus cifrado de extremo a extremo |
681 | Schoology Free plus 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 un extremo a otro y la identidad verificada. Para obtener más información sobre cómo utilizar la API, consulte Acceda a la API de Webex Room y Desk Devices y Webex Boards .
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 for Devices
Llamada a 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 la CA de Webex . Luego, 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 entrar a una reunión cifrada de un extremo a otro. 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 |
| La identidad del dispositivo leída del nombre común del certificado emitido externamente. |
| Lee información específica de un certificado emitido externamente. En el comando que se muestra, reemplace
|
| El estado de la identidad externa del dispositivo (p. Ej. |
| Indica si el dispositivo tiene un certificado válido emitido por la CA de Webex . |
| La identidad del dispositivo como se lee del nombre común del certificado emitido por Webex. Contiene un nombre del 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 la |
| Lee información específica del certificado emitido por Webex. En el comando que se muestra, reemplace
|
Llamada a API | Descripción |
|---|---|
| Estos tres eventos ahora incluyen |
Llamada a API | Descripción |
|---|---|
o
| Acepta un valor de texto sin formato codificado en base64url para sembrar 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. |
| 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. Por esto |
| Desactiva un certificado específico para WebexIdentity. Por esto |
