Os usuários escolhem o Tipo de reunião ao agendar uma reunião. Ao admitir participantes do lobby, bem como durante a reunião, o organizador pode ver o status de verificação de identidade de cada participante. Há também um código de reunião comum a todos os participantes atuais da reunião, que eles podem usar para verificar uns aos outros.
Compartilhe as seguintes informações com os organizadores da reunião:
Entrar em uma reunião Webex com criptografia de ponta a ponta
Verificar identidade
A criptografia de ponta a ponta com verificação de identidade fornece segurança adicional para uma reunião criptografada de ponta a ponta.
Quando participantes ou dispositivos entram em um grupo MLS (Messaging Layer Security) compartilhado, eles apresentam seus certificados para os outros membros do grupo, que então validam os certificados contra as Autoridades de Certificação (CA) emissoras. Ao confirmar que os certificados são válidos, a CA verifica a identidade dos participantes e a reunião mostra os participantes/dispositivos como verificados.
Os usuários do aplicativo Webex se autenticam no armazenamento de identidade Webex , que emite um token de acesso quando a autenticação é bem-sucedida. Se eles precisarem de um certificado para verificar sua identidade em uma reunião criptografada de ponta a ponta, a CA Webex emitirá um certificado com base no token de acesso. No momento, não fornecemos uma maneira para que os usuários do Webex Meetings obtenham um certificado emitido por uma CA de terceiros/externa.
Os dispositivos podem se autenticar usando um certificado emitido pela CA interna (Webex) ou um certificado emitido por uma CA externa:
CA interna — O Webex emite um certificado interno com base no token de acesso da conta de máquina do dispositivo. O certificado é assinado pela CA Webex . Os dispositivos não têm IDs de usuário da mesma forma que os usuários, portanto, o Webex usa (um dos) domínios da sua organização ao gravar a identidade do certificado do dispositivo (Nome Comum (CN)).
CA externa — Solicite e adquira certificados de dispositivo diretamente do emissor escolhido. Você deve criptografar, carregar diretamente e autorizar os certificados usando um segredo conhecido apenas por você.
A Cisco não está envolvida, o que faz desta uma maneira de garantir a verdadeira criptografia de ponta a ponta e a identidade verificada, além de impedir a possibilidade teórica de que a Cisco possa espionar sua reunião/descriptografar sua mídia.
Certificado de dispositivo emitido internamente
O Webex emite um certificado para o dispositivo quando ele é registrado após a inicialização e o renova quando necessário. Para dispositivos, o certificado inclui a ID da conta e um domínio.
Se sua organização não tiver um domínio, a CA Webex emitirá o certificado sem domínio.
Se sua organização tiver vários domínios, você poderá usar o Control Hub para informar ao Webex qual domínio o dispositivo usar para sua identidade. Você também pode usar a API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".
Se você tiver vários domínios e não definir o domínio preferencial para o dispositivo, o Webex escolherá um para você.
Certificado de dispositivo emitido externamente
Um administrador pode provisionar um dispositivo com seu próprio certificado que foi assinado com uma das CAs públicas.
O certificado deve ser baseado em um par de chaves ECDSA P-256, embora possa ser assinado por uma chave RSA.
Os valores no certificado ficam a critério da organização. O nome comum (CN) e o Nome alternativo do assunto (SAN) serão exibidos na interface do usuário da reunião do Webex , conforme descrito em Criptografia de ponta a ponta com verificação de identidade para Webex Meetings .
Recomendamos o uso de um certificado separado por dispositivo e um CN exclusivo por dispositivo. Por exemplo, "meeting-room-1.example.com" para a organização que possui o domínio "example.com".
Para proteger totalmente o certificado externo contra adulteração, um recurso de segredo do cliente é usado para criptografar e assinar vários xcommands.
Ao usar o segredo do cliente, é possível gerenciar com segurança o certificado de identidade Webex externo através do xAPI. No momento, isso está limitado a dispositivos on-line.
Atualmente, o Webex fornece comandos de API para gerenciar isso.
Dispositivos
Os seguintes dispositivos da série Webex Room e Webex Desk registrados na nuvem podem entrar em reuniões criptografadas de ponta a ponta:
Webex Board
Webex Desk Pro
Mesa Webex
Webex Room Kit
Webex Room Kit Mini
Os seguintes dispositivos não podem entrar em reuniões criptografadas de ponta a ponta:
Webex série C
Série Webex DX
Webex série EX
Webex MX Series
Dispositivos SIP de terceiros
Clientes de software
A partir da versão 41.6, o cliente de desktop Webex Meetings pode entrar em reuniões criptografadas de ponta a ponta.
Se sua organização permitir que o Aplicativo Webex entre em reuniões iniciando o aplicativo de desktop Meetings, você poderá usar essa opção para entrar em reuniões criptografadas de ponta a ponta.
O cliente da web Webex não pode entrar em reuniões criptografadas de ponta a ponta.
Os soft clients SIP de terceiros não podem entrar em reuniões criptografadas de ponta a ponta.
Identidade
Por padrão, não fornecemos opções do Control Hub para que você gerencie a identidade do dispositivo verificada externamente. Para uma verdadeira criptografia de ponta a ponta, somente você deve saber/acessar os segredos e as chaves. Se introduzirmos um serviço em nuvem para gerenciar essas chaves, há uma chance de elas serem interceptadas.
Atualmente, fornecemos uma "receita" para que você possa projetar suas próprias ferramentas, com base em técnicas de criptografia padrão do setor, para ajudar com a solicitação ou criptografia dos certificados de identidade do dispositivo e das chaves privadas. Não queremos ter nenhum acesso real ou percebido aos seus segredos ou chaves.
Reuniões
Atualmente, as reuniões criptografadas de ponta a ponta suportam um máximo de 200 participantes.
Desses 200 participantes, no máximo 25 dispositivos verificados externamente podem entrar, e eles devem ser os primeiros participantes a entrar na reunião .
Quando um número maior de dispositivos entra em uma reunião, nossos serviços de mídia backend tentam transcodificar os fluxos de mídia. Se não conseguirmos decodificar, transcodificar e criptografar novamente a mídia (porque não temos e não devemos ter as chaves de criptografia dos dispositivos), a transcodificação falhará.
Para mitigar essa limitação, recomendamos reuniões menores para dispositivos ou escalonar os convites entre dispositivos e clientes do Meetings.
Interface de gerenciamento
É altamente recomendável que você use o Control Hub para gerenciar o site da reunião, pois as organizações do Control Hub têm a identidade centralizada para toda a organização, enquanto na Administração do site, a identidade é controlada site a site.
Os usuários gerenciados na Administração do site não podem ter a opção de identidade verificada pela Cisco. Esses usuários recebem um certificado anônimo para entrar em uma reunião criptografada de ponta a ponta e podem ser excluídos de reuniões em que o organizador deseja garantir a verificação de identidade.
Informações relacionadas
Segurança Zero-Trust para Webex (documento técnico de segurança): https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html
Apresentação do Cisco Live 2021 (é necessário o registro do Cisco Live): https://www.ciscolive.com/2021/learn/session-catalog.html?tab.digitalbundle=Anytime21&search.sessiontype=BRK&search.learningmap=1614364767910003wzD6#/session/16106298425360015zrh
Criptografia da Web JSON (JWE) (Rascunho do padrão IETF): https://datatracker.ietf.org/doc/html/rfc7516
Documentação voltada para o usuário: https://help.webex.com/5h5d8ab
Webex Meetings 41.7.
Dispositivos Webex Room e Webex Desk Series registrados na nuvem, em execução
10.6.1-RoomOS_August_2021.Acesso administrativo ao local da reunião no Control Hub, para habilitar o novo Tipo de sessão para os usuários.
Um ou mais domínios verificados na sua organização do Control Hub (se você estiver usando a CA Webex para emitir certificados de dispositivo para identidade verificada).
As Salas de Reunião de Colaboração devem ser ativadas para que as pessoas possam entrar a partir de seus sistemas de vídeo. Para obter mais informações, consulte Permitir que os sistemas de vídeo entrem em reuniões e eventos no seu site do Webex .
Você pode ignorar esta etapa se não precisar de identidades verificadas externamente.
Para o mais alto nível de segurança e para verificação de identidade, cada dispositivo deve ter um certificado exclusivo emitido por uma Autoridade de certificação (CA) pública confiável.
Você precisa interagir com a CA para solicitar, comprar e receber os certificados digitais e criar as chaves privadas associadas. Ao solicitar o certificado, use estes parâmetros:
O certificado deve ser emitido e assinado por uma CA pública bem conhecida.
Exclusivo: É altamente recomendável usar um certificado exclusivo para cada dispositivo. Se você usar um certificado para todos os dispositivos, estará comprometendo sua segurança.
Nome comum (CN) e nome(s) alternativo(s) do assunto (SAN/s): Não são importantes para o Webex, mas devem ser valores que os humanos possam ler e associar ao dispositivo. O CN será exibido para outros participantes da reunião como a identidade verificada principal do dispositivo e, se os usuários inspecionarem o certificado através da IU da reunião, verão as SAN(s). Você pode querer usar nomes como
name.model@example.com.Formato do arquivo: Os certificados e as chaves devem estar no
.pemformato.Objetivo: A finalidade do certificado deve ser o Webex Identity.
Gerando chaves: Os certificados devem ser baseados em pares de chaves ECDSA P-256 (Algoritmo de Assinatura Digital de Curva Elíptica usando a curva P-256).
Esse requisito não se estende à chave de assinatura. A CA pode usar uma chave RSA para assinar o certificado.
Você pode ignorar esta etapa se não quiser usar a identidade verificada externamente com seus dispositivos.
Se você estiver usando novos dispositivos, não os registre no Webex ainda. Para sua segurança, não os conecte à rede neste momento.
Se você tiver dispositivos existentes que você deseja atualizar para usar a identidade verificada externamente, você deverá redefinir os dispositivos de fábrica.
Salve a configuração existente se você quiser mantê-la.
Agende uma janela quando os dispositivos não estiverem sendo usados ou use uma abordagem em fases. Notifique os usuários sobre as alterações que eles podem esperar.
Garanta o acesso físico aos dispositivos. Se você precisar acessar os dispositivos através da rede, esteja ciente de que os segredos estão viajando em texto sem formatação e você está comprometendo sua segurança.
Depois de concluir essas etapas, permitir que os sistemas de vídeo entrem em reuniões e eventos no seu site do Webex .
Para garantir que a mídia do seu dispositivo não possa ser criptografada por ninguém exceto o dispositivo, você deve criptografar a chave privada no dispositivo. Projetamos APIs para o dispositivo para permitir o gerenciamento da chave e do certificado criptografados, usando a Criptografia da Web JSON (JWE).
Para garantir uma verdadeira criptografia de ponta a ponta por meio de nossa nuvem, não podemos nos envolver na criptografia e no carregamento do certificado e da chave. Se você precisar desse nível de segurança, você deve:
Solicite seus certificados.
Gere os pares de chaves dos seus certificados.
Crie (e proteja) um segredo inicial para cada dispositivo, para semear a capacidade de criptografia do dispositivo.
Desenvolva e mantenha sua própria ferramenta para criptografar arquivos usando o padrão JWE.
O processo e os parâmetros (não secretos) de que você precisará estão explicados abaixo, bem como uma receita a ser seguida nas ferramentas de desenvolvimento de sua escolha. Também fornecemos alguns dados de teste e os blobs JWE resultantes, conforme os esperamos, para ajudá-lo a verificar seu processo.
Uma implementação de referência não suportada usando Python3 e a biblioteca JWCrypto está disponível na Cisco mediante solicitação.
Concatene e criptografe o certificado e a chave usando sua ferramenta e o segredo inicial do dispositivo.
Carregue o blob JWE resultante no dispositivo.
Defina a finalidade do certificado criptografado a ser usado para a identidade Webex e ative o certificado.
(Recomendado) Fornecer uma interface para (ou distribuir) sua ferramenta para permitir que os usuários do dispositivo alterem o segredo inicial e protejam suas mídias contra você.
Como usamos o formato JWE
Esta seção descreve como esperamos que o JWE seja criado como entrada para os dispositivos, para que você possa criar sua própria ferramenta para criar os blobs a partir de seus certificados e chaves.
Consulte Criptografia da Web JSON (JWE)https://datatracker.ietf.org/doc/html/rfc7516e Assinatura da Web JSON (JWS)https://datatracker.ietf.org/doc/html/rfc7515.
Usamos o Serialização compacta de um documento JSON para criar blobs JWE. Os parâmetros que você precisa incluir ao criar os blobs JWE são:
Cabeçalho JOSE (protegido). No cabeçalho de Assinatura e criptografia de objetos JSON, você DEVE incluir os seguintes pares de chave-valor:
"alg":"dir"O algoritmo direto é o único com suporte para criptografar a carga, e você deve usar o segredo do cliente inicial do dispositivo.
"enc":"A128GCM"ou"enc":"A256GCM"Oferecemos suporte a esses dois algoritmos de criptografia.
"cisco-action": "add"ou"cisco-action": "populate"ou"cisco-action": "activate"ou"cisco-action": "deactivate"Esta é uma chave proprietária e quatro valores que podem levar. Introduzimos essa chave para sinalizar a finalidade dos dados criptografados para o dispositivo de destino. Os valores são nomeados após os comandos xAPI no dispositivo em que você está usando os dados criptografados.
Nós o nomeamos
cisco-actionpara mitigar possíveis confrontos com futuras extensões do JWE."cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }Outra chave proprietária. Usamos os valores que você forneceu como entradas para a derivação de chaves no dispositivo. O
versiondeve ser1(a versão da nossa função de derivação de chaves). O valor desaltdeve ser uma sequência codificada por URL base64 de pelo menos 4 bytes, que você deve escolher aleatoriamente.
Chave criptografada JWE . Este campo está vazio. O dispositivo o deriva do ponto inicial
ClientSecret.Vetor de inicialização JWE . Você deve fornecer um vetor de inicialização codificado em base64url para descriptografar a carga. O IV DEVE seja um valor aleatório de 12 bytes (estamos usando a família de cifras AES-GCM, que requer que o IV tenha 12 bytes).
JWE AAD (dados autenticados adicionais). Você deve omitir este campo porque ele não é compatível com a serialização compacta.
Texto cifrado JWE : Esta é a carga criptografada que você deseja manter em segredo.
A carga PODE estar vazia. Por exemplo, para redefinir o segredo do cliente, você precisa substituí-lo por um valor vazio.
Existem diferentes tipos de cargas, dependendo do que você está tentando fazer no dispositivo. Diferentes comandos xAPI esperam cargas diferentes, e você deve especificar a finalidade da carga com a
cisco-actionchave, da seguinte forma:Com
"cisco-action":"populate"o texto cifrado é o novoClientSecret.Com "
"cisco-action":"add"o texto cifrado é um blob PEM que transporta o certificado e sua chave privada (concatenado).Com "
"cisco-action":"activate"o texto cifrado é a impressão digital (representação hexadecimal de sha-1) do certificado que estamos ativando para verificação de identidade do dispositivo.Com "
"cisco-action":"deactivate"o texto cifrado é a impressão digital (representação hexadecimal de sha-1) do certificado que estamos desativando de ser usado para verificação de identidade do dispositivo.
Tag de autenticação JWE: Este campo contém a tag de autenticação para verificar a integridade de todo o blob JWE serializado de forma compacta
Como derivamos a chave de criptografia do ClientSecret
Após o primeiro preenchimento do segredo, não aceitamos ou geramos o segredo como texto sem formatação. Isso é para impedir possíveis ataques de dicionário por alguém que possa acessar o dispositivo.
O software do dispositivo usa o segredo do cliente como uma entrada para uma função de derivação de chave (kdf) e, em seguida, usa a chave derivada para descriptografia/criptografia de conteúdo no dispositivo.
O que isso significa para você é que sua ferramenta para produzir blobs JWE deve seguir o mesmo procedimento para derivar a mesma chave de criptografia/descriptografia do segredo do cliente.
Os dispositivos usam criptografia para derivação de chaves (consultehttps://en.wikipedia.org/wiki/Scrypt ), com os seguintes parâmetros:
Fator de custo (N) é 32768
BlockSizeFactor (r) é 8
Fator de paralelização (p) é 1
Salt é uma sequência aleatória de pelo menos 4 bytes; você deve fornecer este mesmo
saltao especificar ocisco-kdf.Os comprimentos das chaves são 16 bytes (se você selecionar o algoritmo AES-GCM 128) ou 32 bytes (se você selecionar o algoritmo AES-GCM 256)
O limite máximo de memória é 64MB
Este conjunto de parâmetros é a única configuração do criptografia compatível com a função de derivação de teclas nos dispositivos. Este kdf nos dispositivos é chamado "version":"1", que é a única versão atualmente usada pelo cisco-kdf.
Exemplo resolvido
Aqui está um exemplo que você pode seguir para verificar se o processo de criptografia JWE funciona da mesma forma que o processo que criamos nos dispositivos.
O cenário de exemplo é adicionar um blob PEM ao dispositivo (imita a adição de um certificado, com uma cadeia muito curta em vez de um certificado + chave completo). O segredo do cliente no exemplo é ossifrage.
Escolha uma cifra de criptografia. Este exemplo usa
A128GCM(AES com chaves de 128 bits no modo de contador Galois). Sua ferramenta pode usarA256GCMse você preferir.Escolha um salt (deve ser uma sequência aleatória de pelo menos 4 bytes). Este exemplo usa (bytes hexadecimais)
E5 E6 53 08 03 F8 33 F6. Base64url codifica a sequência para obter5eZTCAP4M_Y(remova o preenchimento base64).Aqui está um exemplo
scryptchamada para criar a chave de criptografia de conteúdo (cek):cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)A chave derivada deve ter 16 bytes (hex) da seguinte forma:
95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff acque base64url codifica paralZ66bdEiAQV4_mqdInj_rA.Escolha uma sequência aleatória de 12 bytes para usar como vetor de inicialização. Este exemplo usa (hex)
34 b3 5d dd 5f 53 7b af 2d 92 95 83que base64url codifica paraNLNd3V9Te68tkpWD.Crie o cabeçalho JOSE com serialização compacta (siga a mesma ordem de parâmetros que usamos aqui) e, em seguida, codifique-o em base64url:
{"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}O cabeçalho JOSE codificado com base64url é
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9Este será o primeiro elemento do blob JWE.
O segundo elemento do blob JWE está vazio, porque não estamos fornecendo uma chave de chave de criptografia JWE .
O terceiro elemento do blob JWE é o vetor de inicialização
NLNd3V9Te68tkpWD.- Use sua ferramenta de criptografia JWE para produzir uma carga e tag criptografadas. Para este exemplo, a carga não criptografada será o blob PEM falso
this is a PEM fileOs parâmetros de criptografia que você deve usar são:
A carga é
this is a PEM fileA criptografia de criptografia é AES 128 GCM
O cabeçalho JOSE codificado com base64url como dados autenticados adicionais (AAD)
Base64url codifica a carga criptografada, que deve resultar em
f5lLVuWNfKfmzYCo1YJfODhQEste é o quarto elemento (texto cifrado JWE) no blob JWE.
Base64url codifique a tag que você produziu na etapa 8, o que deve resultar em
PE-wDFWGXFFBeo928cfZ1QEste é o quinto elemento no blob JWE.
Concatene os cinco elementos do blob JWE com pontos (JOSEheader..IV.Ciphertext.Tag) para obter:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1QSe você derivou os mesmos valores codificados em base64url que mostramos aqui, usando suas próprias ferramentas, você está pronto para usá-los para garantir a criptografia E2E e a identidade verificada dos seus dispositivos.
Este exemplo não funcionará, mas, em princípio, sua próxima etapa seria usar o blob JWE que você criou acima como a entrada para o comando x no dispositivo que adiciona o certificado:
xCommand Security Certificates AddeyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
Os tipos de sessão para reuniões de confiança zero estão disponíveis para todos os sites de reuniões sem custo adicional. Um desses tipos de sessão é chamado de Pro-End to End Encryption_VOIPonly. Este é o Nome do Serviço Público , que podemos mudar no futuro. Para os nomes atuais dos tipos de sessão, consulte IDs de tipo de sessão no Referência deste artigo.
Não há nada que você precise fazer para obter esse recurso para o seu site; você precisa conceder o novo tipo de sessão (também chamado Privilégio de Reunião ) aos usuários. Você pode fazer isso individualmente através da página de configuração do usuário ou em massa com uma exportação/importação CSV.
| 1 | Inicie sessão no Control Hub e vá até . | ||
| 2 | Clique em Sites, escolha o site Webex cujas configurações você deseja alterar e clique em Configurações. | ||
| 3 | Em Configurações comuns , selecione Tipos de sessões . | ||
| 4 | Você deve ver um ou mais tipos de sessão de criptografia de ponta a ponta. Consulte a lista de IDs de tipo de sessão no Referência deste artigo. Por exemplo, você pode ver E de ponta a pontancryption_ Somente VOIP .
| ||
| 5 | Se você ainda não tiver o novo Tipo de sessão , entre em contato com seu representante Webex . |
O que fazer em seguida
Habilite este Tipo de sessão /privilégio de reunião para alguns ou todos os seus usuários.
| 1 | Iniciar sessão em Hub de controle , e vá para . |
| 2 | Selecione uma conta de usuário a ser atualizada e selecione Reuniões . |
| 3 | No menu suspenso Configurações se aplicam a , selecione o site da reunião para atualizar. |
| 4 | Marque a caixa ao lado de E de ponta a pontancryption_ Somente VOIP . |
| 5 | Feche o painel de configuração de usuário . |
| 6 | Repita para outros usuários, se necessário. Para atribuir isso a muitos usuários, use a próxima opção, Habilitar reuniões E2EE para vários usuários . |
| 1 | Inicie sessão no Control Hub e vá até . | ||
| 2 | Clique em Sites , escolha o site Webex para o qual deseja alterar as configurações. | ||
| 3 | Na seção de Licenças e usuários, clique em Gerenciamento em massa. | ||
| 4 | Clique Gerar relatório , e aguarde enquanto preparamos o arquivo. | ||
| 5 | Quando o arquivo estiver pronto, clique em Exportar resultados e depois Baixar . (Você tem que fechar manualmente a janela pop-up depois de clicar Baixar .) | ||
| 6 | Abra o arquivo CSV baixado para edição. Há uma fila para cada usuário, e a | ||
| 7 | Para cada usuário que você deseja conceder o novo Tipo de sessão, adicione O Referência de formato de arquivo CSV do Webex contém detalhes sobre a finalidade e o conteúdo do arquivo CSV. | ||
| 8 | Abra o painel de configuração do site de reunião no Control Hub.
| ||
| 9 | Na seção de Licenças e usuários, clique em Gerenciamento em massa. | ||
| 10 | Clique Importar e selecione o CSV editado, depois clique Importar . Aguarde enquanto o arquivo é carregado. | ||
| 11 | Quando a importação for concluída, você poderá clicar Importar resultados para verificar se houve algum erro. | ||
| 12 | Ir para Usuários página e abra um dos usuários para verificar se ele tem o novo Tipo de sessão. |
Você pode adicionar uma marca d'água às gravações de reuniões com o Webex Meetings Pro-End to End Encryption_VOIPonly tipo de sessão, que permite identificar o cliente de origem ou o dispositivo de gravações não autorizadas de reuniões confidenciais.
Quando esse recurso está ativado, o áudio da reunião inclui um identificador exclusivo para cada cliente ou dispositivo participante. Você pode carregar gravações de áudio no Control Hub, que analisa a gravação e procura os identificadores exclusivos. Você pode ver os resultados para ver qual cliente de origem ou dispositivo gravou a reunião.
- Para ser analisada, a gravação deve ser um arquivo AAC, MP3, M4A, WAV, MP4, AVI ou MOV, com tamanho não superior a 500MB.
- A gravação deve ter mais de 100 segundos.
- Você só pode analisar gravações de reuniões organizadas por pessoas em sua organização.
- As informações da marca d'água são mantidas pela mesma duração que as informações da reunião da organização.
Adicionar marcas d'água de áudio às reuniões E2EE
- Inicie sessão no Control Hub, em seguida, em Gerenciamento, selecione Configurações da organização.
- No Marcas d'água da reunião seção, ativar Adicionar marca d'água de áudio .
Algum tempo depois de ativado, os usuários agendam reuniões com o
Webex Meetings Pro-End to End Encryption_VOIPonlytipo de sessão ver uma Digital Watermarking opção na seção Segurança.
Carregar e analisar uma reunião com marca d'água
- No Control Hub, em Monitoramento , selecione Solução de problemas .
- Clique Análise de marca d'água .
- Procure ou selecione a reunião na lista e clique em Analisar .
- No Analisar marca d'água de áudio janela, insira um nome para sua análise.
- (Opcional) Insira uma nota para sua análise.
- Arraste e solte o arquivo de áudio a ser analisado ou clique Escolher arquivo para navegar até o arquivo de áudio.
- Clique em Fechar.
Quando a análise for concluída, ela será mostrada na lista de resultados na Analisar marca d'água página.
- Selecione a reunião na lista para ver os resultados da análise. Clique
para baixar os resultados.
Recursos e limitações
Os fatores envolvidos na decodificação bem-sucedida de uma marca d'água gravada incluem a distância entre o dispositivo de gravação e o alto-falante que emite o áudio, o volume desse áudio, o ruído ambiental, etc. Nossa tecnologia de marca d'água tem resiliência adicional para ser codificado várias vezes, como pode acontecer quando a mídia é compartilhada.
Esse recurso foi projetado para permitir a decodificação bem-sucedida do identificador da marca d'água em um conjunto amplo, mas razoável de circunstâncias. Nosso objetivo é que um dispositivo de gravação, como um telefone celular, que esteja em uma mesa próxima a um terminal pessoal ou cliente de laptop, sempre crie uma gravação que resulte em uma análise bem-sucedida. Como o dispositivo de gravação é movido para longe da fonte ou fica obscuro ao ouvir todo o espectro de áudio, as chances de uma análise bem-sucedida são reduzidas.
Para analisar com êxito uma gravação, é necessária uma captura razoável do áudio da reunião. Se o áudio de uma reunião for gravado no mesmo computador que está hospedando o cliente, as limitações não deverão ser aplicadas.
Se seus dispositivos já estiverem integrados à sua organização do Control Hub e você quiser usar a CA Webex para gerar automaticamente seus certificados de identificação, você não precisará redefinição das configurações de fábrica .
Este procedimento seleciona qual domínio o dispositivo usa para se identificar e é necessário apenas se você tiver vários domínios na organização do Control Hub. Se você tiver mais de um domínio, recomendamos que você faça isso para todos os seus dispositivos que terão a identidade "verificada pela Cisco". Se você não informar ao Webex qual domínio identifica o dispositivo, um será escolhido automaticamente e poderá parecer errado para outros participantes da reunião.
Antes de você começar
Se seus dispositivos ainda não estiverem integrados, siga Registrar um dispositivo no Cisco Webex usando a API ou a interface da Web local ou Integração em nuvem para as séries Board, Desk e Room . Você também deve verificar o(s) domínio(s) que deseja usar para identificar os dispositivos em Gerenciar seus domínios .
| 1 | Iniciar sessão no Control Hub , e sob Gerenciamento , selecione Dispositivos . |
| 2 | Selecione um dispositivo para abrir seu painel de configuração. |
| 3 | Selecione o domínio que você deseja usar para identificar este dispositivo. |
| 4 | Repita para outros dispositivos. |
Antes de você começar
Você precisa de:
Para obter um certificado assinado pela CA e uma chave privada, em
.pemformato, para cada dispositivo.Para ler o tópico Noções básicas sobre o processo de identidade externa para dispositivos , no Preparar parte deste artigo.
Para preparar uma ferramenta de criptografia JWE com relação às informações nela contidas.
Uma ferramenta para gerar sequências de bytes aleatórias de determinados comprimentos.
Uma ferramenta para codificar bytes ou texto do URL base64.
Um
scryptimplementação.Uma palavra ou frase secreta para cada dispositivo.
| 1 | Preencher a página do dispositivo A primeira vez que você preencher a O dispositivo tem seu segredo inicial. Não se esqueça disso; você não pode recuperá-lo e deve redefinir o dispositivo para iniciar novamente.
|
| 2 | Concatene seu certificado e a chave privada: |
| 3 | Crie um blob JWE a ser usado como entrada para o comando de adição de certificado: |
| 4 | Abra o TShell no dispositivo e execute o comando add (multilinha): |
| 5 | Verifique se o certificado foi adicionado executando Copie a impressão digital do novo certificado. |
| 6 | Ativar o certificado para a finalidade O dispositivo possui um certificado criptografado e ativo emitido pela CA, pronto para ser usado para identificá-lo em reuniões Webex criptografadas de ponta a ponta.
|
| 7 | Integre o dispositivo à sua organização do Control Hub. |
| 1 | Agendar uma reunião do tipo correto ( Webex Meetings profissional de ponta a ponta Encryption_ Somente VOIP ). |
| 2 | Entre na reunião como o organizador, de um cliente Webex Meetings . |
| 3 | Entre na reunião de um dispositivo que tem sua identidade verificada pela CA Webex . |
| 4 | Como o organizador, verifique se este dispositivo aparece no lobby com o ícone de identidade correto. |
| 5 | Entre na reunião de um dispositivo que tem sua identidade verificada por uma CA externa. |
| 6 | Como o organizador, verifique se este dispositivo aparece no lobby com o ícone de identidade correto. Saiba mais sobre ícones de identidade . |
| 7 | Entre na reunião como um participante não autenticado. |
| 8 | Como o organizador, verifique se este participante aparece no lobby com o ícone de identidade correto. |
| 9 | Como o organizador, admita ou rejeite pessoas/dispositivos. |
| 10 | Valide as identidades dos participantes/dispositivos sempre que possível verificando os certificados. |
| 11 | Verifique se todos na reunião veem o mesmo código de segurança. |
| 12 | Entrar na reunião com um novo participante. |
| 13 | Verifique se todos veem o mesmo código de segurança da nova reunião. |
Você vai tornar as reuniões criptografadas de ponta a ponta a opção de reunião padrão ou ativá-las apenas para alguns usuários ou permitir que todos os organizadores decidam? Quando você tiver decidido como vai usar esse recurso, prepare os usuários que o usarão, especialmente com relação às limitações e ao que esperar na reunião.
Você precisa garantir que nem a Cisco nem qualquer outra pessoa possa descriptografar seu conteúdo ou se passar por seus dispositivos? Em caso afirmativo, você precisa de certificados de uma CA pública. Você pode ter apenas até 25 dispositivos em uma reunião segura. Se você precisar desse nível de segurança, você não deve permitir que os clientes da reunião entrem.
Para usuários que estão entrando com dispositivos seguros, deixe que os dispositivos entrem primeiro e defina as expectativas do usuário de que eles podem não ser capazes de entrar se entrarem tarde.
Se você tiver níveis variados de verificação de identidade, fortaleça os usuários para verificar uns aos outros com a identidade baseada em certificado e o código de segurança da reunião. Mesmo que haja circunstâncias em que os participantes possam aparecer como Não verificados e os participantes devam saber como verificar, pessoas não verificadas podem não ser impostoras.
Se você estiver usando uma CA externa para emitir certificados de dispositivo, o ônus será seu para monitorar, atualizar e reaplicar certificados.
Se você criou o segredo inicial, entenda que seus usuários podem querer alterar o segredo do dispositivo. Você pode precisar criar uma interface/distribuir uma ferramenta para permitir que eles façam isso.
ID do tipo de sessão | Nome de serviço público |
|---|---|
638 | Criptografia E2E+VoIP somente |
652 | E de ponta a pontancryption_ Somente VOIP |
660 | Pro 3 gratuito de ponta a ponta Encryption_ Somente VOIP Criptografia E2E + Identidade |
672 | Pro 3 Free50-End to End Encryption_ Somente VOIP |
673 | Instrutor educacional E2E Encryption_ Somente VOIP |
676 | Criptografia de ponta a ponta Broadworks Standard plus |
677 | Criptografia de ponta a ponta Broadworks Premium plus |
681 | Schoology Free e criptografia de ponta a ponta |
Estas tabelas descrevem os comandos da API dos dispositivos Webex que adicionamos para reuniões criptografadas de ponta a ponta e identidade verificada. Para obter mais informações sobre como usar a API, consulte Acessar a API para Webex Room, Desk Devices e Webex Boards .
Estes comandos xAPI estão disponíveis apenas em dispositivos que são:
Registrado no Webex
Registrado no local e vinculado ao Webex com o Webex Edge para dispositivos
Chamada API | Descrição |
|---|---|
| Essa configuração é feita quando o administrador define o domínio preferencial do dispositivo no Control Hub. Necessário apenas se a organização tiver mais de um domínio. O dispositivo usa esse domínio quando solicita um certificado da CA Webex . O domínio, em seguida, identifica o dispositivo. Essa configuração não é aplicável quando o dispositivo possui um certificado ativo emitido externamente para se identificar. |
| Indica se o dispositivo pode entrar em uma reunião criptografada de ponta a ponta. A API em nuvem o chama para que um aplicativo emparelhado saiba se pode usar o dispositivo para entrar. |
| Indica se o dispositivo usa |
| A identidade do dispositivo como lida a partir do nome comum do certificado emitido externamente. |
| Lê informações específicas de um certificado emitido externamente. No comando mostrado, substitua
|
| O status da identidade externa do dispositivo (por exemplo, |
| Indica se o dispositivo possui um certificado válido emitido pela CA Webex . |
| A identidade do dispositivo como lida a partir do nome comum do certificado emitido pelo Webex. Contém um nome de domínio se a organização tiver um domínio. Estará vazio se a organização não tiver um domínio. Se o dispositivo estiver em uma organização que tenha vários domínios, esse será o valor da |
| Lê informações específicas do certificado emitido pelo Webex. No comando mostrado, substitua
|
Chamada API | Descrição |
|---|---|
| Estes três eventos agora incluem |
Chamada API | Descrição |
|---|---|
ou
| Aceita um valor de texto sem formatação codificado em base64url para semear o segredo do cliente no dispositivo pela primeira vez. Para atualizar o segredo após a primeira vez, você deve fornecer um blob JWE que contém o novo segredo criptografado pelo segredo antigo. |
| Adiciona um certificado (com chave privada). Estendemos este comando para aceitar um blob JWE que contém os dados PEM criptografados. |
| Ativa um certificado específico para o WebexIdentity. Para isso |
| Desativa um certificado específico para WebexIdentity. Para isso |
