Você pode detalhar reuniões ou chamadas por participante e ver informação detalhada sobre a qualidade de áudio, vídeo e compartilhamento. Os dados são atualizados a cada minuto para Webex Meetings e Chamada no Webex, para que você possa diagnosticar problemas à medida que surgirem. Os dados do Webex Calling são atualizados no final de cada chamada.

Experiência do usuário

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:

Verificação de identidade com CA interna ou externa

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.

Recursos e limitações

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.

Recursos adicionais

Informações relacionadas

Pré-requisitos

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

Obter certificados de dispositivo

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

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

Prepare-se para dispositivos integrados

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 .

Entender o processo de identidade externa para dispositivos

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:

  1. Solicite seus certificados.

  2. Gere os pares de chaves dos seus certificados.

  3. Crie (e proteja) um segredo inicial para cada dispositivo, para semear a capacidade de criptografia do dispositivo.

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

  5. Concatene e criptografe o certificado e a chave usando sua ferramenta e o segredo inicial do dispositivo.

  6. Carregue o blob JWE resultante no dispositivo.

  7. Defina a finalidade do certificado criptografado a ser usado para a identidade Webex e ative o certificado.

  8. (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-action para 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 comando version deve ser 1(a versão da nossa função de derivação de chaves). O valor de salt deve 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-action chave, da seguinte forma:

    • Com "cisco-action":"populate" o texto cifrado é o novo ClientSecret.

    • 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 salt ao especificar o cisco-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.

  1. Escolha uma cifra de criptografia. Este exemplo usa A128GCM(AES com chaves de 128 bits no modo de contador Galois). Sua ferramenta pode usar A256GCM se você preferir.

  2. 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 obter 5eZTCAP4M_Y(remova o preenchimento base64).

  3. Aqui está um exemplo scrypt chamada 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 ac que base64url codifica para lZ66bdEiAQV4_mqdInj_rA.

  4. 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 83 que base64url codifica para NLNd3V9Te68tkpWD.

  5. 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 é eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Este será o primeiro elemento do blob JWE.

  6. O segundo elemento do blob JWE está vazio, porque não estamos fornecendo uma chave de chave de criptografia JWE .

  7. O terceiro elemento do blob JWE é o vetor de inicialização NLNd3V9Te68tkpWD.

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

    Os parâmetros de criptografia que você deve usar são:

    • A carga é this is a PEM file

    • A 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 f5lLVuWNfKfmzYCo1YJfODhQ

    Este é o quarto elemento (texto cifrado JWE) no blob JWE.

  9. Base64url codifique a tag que você produziu na etapa 8, o que deve resultar em PE-wDFWGXFFBeo928cfZ1Q

    Este é o quinto elemento no blob JWE.

  10. Concatene os cinco elementos do blob JWE com pontos (JOSEheader..IV.Ciphertext.Tag) para obter:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

  12. 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 Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Existem novos tipos de sessão para reuniões de confiança zero, que estarão disponíveis para todos os sites de reunião sem custo adicional. Um dos novos tipos de sessão é chamado Pro-End to End Encryption_VOIPonly. Este é o Nome de serviço público que podemos alterar 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 o novo recurso para seu site, mas será necessário conceder o novo Tipo de sessão (também chamado de 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.

Verificar o novo Tipo de sessão

1

Iniciar sessão no Control Hub e abra a Reunião página.

2

Clique no nome do site para abrir o painel de configuração do site.

3

Clique em Configurar site.

4

No Configurações comuns área, clique em Tipos de sessão .

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 .

 

Existe um Tipo de sessão mais antigo com um nome muito semelhante: Criptografia profissional de ponta a ponta . Esse Tipo de sessão inclui acesso PSTN não criptografado às reuniões. Certifique-se de ter a_ Somente VOIP para garantir a criptografia de ponta a ponta. Você pode verificar passando o mouse sobre PRO link na coluna de código da sessão; neste exemplo, o destino do link deve ser javascript:ShowFeature(652).

Podemos alterar os Nomes de serviço público para esses tipos de sessão no futuro.

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.

Habilitar reuniões E2EE para usuários individuais

1

Em Gerenciamento , clique em Usuários .

2

Selecione um usuário e selecione Reuniões .

3

Selecione o site (se o usuário estiver em mais de um) e clique em Organizador .

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 .

Habilitar reuniões E2EE para vários usuários

1

Iniciar sessão no Control Hub , depois sob Serviços , selecione Reunião .

2

Selecione seu site.

3

Na seção de Licenças e usuários, clique em Gerenciamento em massa.

4

Clique Exportar 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 MeetingPrivilege A coluna contém suas IDs de Tipo de sessão como uma lista delimitada por vírgulas.

7

Para cada usuário que você deseja conceder o novo Tipo de sessão, adicione 1561 como um novo valor na lista delimitada por vírgulas na MeetingPrivilege célula.

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.


 

Se você já estava na página de lista do site da reunião, talvez seja necessário atualizá-la.

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.

Adicionar uma marca d'água de áudio para segurança

Você pode adicionar uma marca d'água às gravações de reunião com o Webex Meetings profissional de ponta a ponta Encryption_ Somente VOIPO Tipo de sessão, que permite identificar quem compartilhou a gravação externamente.

Quando esse recurso está ativado, o áudio da reunião inclui um identificador exclusivo para cada participante. Você pode carregar gravações de áudio no Control Hub, que então analisa a gravação e procura identificadores exclusivos. Você pode analisar os resultados para ver qual participante compartilhou o conteúdo da reunião externamente.

  • 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 90 segundos.
  • Você só pode analisar gravações de reuniões organizadas por pessoas em sua organização.
  • As gravações analisadas são excluídas assim que a análise é concluída.
Adicionar marcas d'água de áudio às reuniões E2EE
  1. Iniciar sessão no Control Hub , depois sob Gerenciamento , selecione Configurações da organização .
  2. No Marcas d'água da reunião seção, ativar Adicionar marca d'água de áudio .
Carregar e analisar uma reunião com marca d'água
  1. No Control Hub, em Monitoramento , selecione Solução de problemas .
  2. Clique Análise de marca d'água .
  3. Pesquise ou selecione a reunião na lista e clique em Analisar arquivo .
  4. No Analisar marca d'água de áudio janela, insira um nome para sua análise.
  5. (Opcional) Insira uma nota para sua análise.
  6. Arraste e solte o arquivo de áudio a ser analisado ou clique Escolher arquivo para navegar até o arquivo de áudio.
  7. Clique em Fechar.

    Quando a análise for concluída, ela será mostrada na lista de resultados na Analisar marca d'água página.

  8. Selecione a reunião na lista para ver os resultados da análise. CliqueBotão de download para baixar os resultados.

Dispositivos integrados (CA interna)

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.

Dispositivos integrados (CA externa)

Antes de você começar

Você precisa de:

  • Para obter um certificado assinado pela CA e uma chave privada, em .pem formato, 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 scrypt implementação.

  • Uma palavra ou frase secreta para cada dispositivo.

1

Preencher a página do dispositivo ClientSecret com um segredo de texto sem formatação:

A primeira vez que você preencher a Secret, você o fornece em texto sem formatação. É por isso que recomendamos que você faça isso no console do dispositivo físico.

  1. Base64url codifica a frase secreta para este dispositivo.

  2. Abra o TShell no dispositivo.

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

    O comando de exemplo acima preenche o Secret com a frase 0123456789abcdef. Você precisa escolher o seu.

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:

  1. Usando um editor de texto, abra os arquivos .pem, cole o blob de chaves no blob de certificados e salve-o como um novo arquivo .pem.

    (Este é o texto da carga que você criptografará e colocará no blob JWE)

3

Crie um blob JWE a ser usado como entrada para o comando de adição de certificado:

  1. Crie uma sequência aleatória de pelo menos 4 bytes. Este é o seu sal.

  2. Derive uma chave de criptografia de conteúdo com sua ferramenta de scrypt.

    Para isso, você precisa do segredo, do salt e de um comprimento de chave correspondente à cifra de criptografia escolhida. Existem alguns outros valores fixos a serem fornecidos (N=32768, r=8, p=1). O dispositivo usa o mesmo processo e valores para derivar a mesma chave de criptografia de conteúdo .

  3. Crie uma sequência aleatória de exatamente 12 bytes. Este é o seu vetor de inicialização.

  4. Criar um cabeçalho JOSE, configuração alg, enc, e cisco-kdf teclas, conforme descrito em Noções básicas sobre o processo de identidade externa para dispositivos . Defina a ação "adicionar" usando a chave:valor "cisco-action":"add" no cabeçalho do JOSE (porque estamos adicionando o certificado ao dispositivo).

  5. Base64url codifica o cabeçalho JOSE.

  6. Use sua ferramenta de criptografia JWE com a cifra escolhida e o cabeçalho JOSE codificado com base64url para criptografar o texto do arquivo pem concatenado.

  7. Base64url codifica o vetor de inicialização, a carga PEM criptografada e a tag de autenticação.

  8. Construa o blob JWE da seguinte forma (todos os valores são codificados em base64url):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Abra o TShell no dispositivo e execute o comando add (multilinha):

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

Verifique se o certificado foi adicionado executando xcommand Security Certificates Services Show

Copie a impressão digital do novo certificado.

6

Ativar o certificado para a finalidade WebexIdentity:

  1. Ler a impressão digital do certificado, seja do próprio certificado ou da saída de xcommand Security Certificates Services Show.

  2. Crie uma sequência aleatória de pelo menos 4 bytes e base64url codifique essa sequência. Este é o seu sal.

  3. Derive uma chave de criptografia de conteúdo com sua ferramenta de scrypt.

    Para isso, você precisa do segredo, do salt e de um comprimento de chave correspondente à cifra de criptografia escolhida. Existem alguns outros valores fixos a serem fornecidos (N=32768, r=8, p=1). O dispositivo usa o mesmo processo e valores para derivar a mesma chave de criptografia de conteúdo .

  4. Crie uma sequência aleatória de exatamente 12 bytes e base64url codifique essa sequência. Este é o seu vetor de inicialização.

  5. Criar um cabeçalho JOSE, configuração alg, enc, e cisco-kdf teclas, conforme descrito em Noções básicas sobre o processo de identidade externa para dispositivos . Defina a ação "ativar" usando a chave:valor "cisco-action":"activate" no cabeçalho JOSE (porque estamos ativando o certificado no dispositivo).

  6. Base64url codifica o cabeçalho JOSE.

  7. Use sua ferramenta de criptografia JWE com a cifra escolhida e o cabeçalho JOSE codificado com base64url para criptografar a impressão digital do certificado.

    A ferramenta deve gerar uma sequência de 16 ou 32 bytes, dependendo se você escolheu AES-GCM de 128 ou 256 bits, e uma tag de autenticação.

  8. Base64urlencode a impressão digital criptografada e a tag de autenticação.

  9. Construa o blob JWE da seguinte forma (todos os valores são codificados em base64url):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Abra o TShell no dispositivo e execute o seguinte comando de ativação:

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
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.

Teste a criptografia de ponta a ponta com verificação de identidade

1

Agendar uma reunião do tipo correto ( Webex Meetings profissional de ponta a ponta Encryption_ Somente VOIP ).

Ver Agendar uma reunião Webex com criptografia de ponta a ponta .

2

Entre na reunião como o organizador, de um cliente Webex Meetings .

Ver Entrar em uma reunião Webex com criptografia de ponta a ponta .

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.

Ver Entrar em uma reunião Webex com criptografia de ponta a ponta .

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.

Definir escopo e expectativas

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.

Gerenciamento de identidades

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.

IDs de tipo de sessão

Tabela 1. IDs de tipo de sessão para reuniões criptografadas de ponta a ponta

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

Comandos xAPI relacionados

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

Tabela 2. APIs de nível de sistema para reuniões criptografadas de ponta a ponta e identidade verificada

Chamada API

Descrição

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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.

xStatus Conference EndToEndEncryption Availability

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.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Indica se o dispositivo usa External verificação (possui um certificado emitido externamente).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

A identidade do dispositivo como lida a partir do nome comum do certificado emitido externamente.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

Lê informações específicas de um certificado emitido externamente.

No comando mostrado, substitua # com o número do certificado. Replace specificinfo com um dos seguintes:

  • Fingerprint

  • NotAfter Data de data de término

  • NotBefore Data de data de início

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Uma lista dos assuntos do certificado (por exemplo, endereço de e-endereço de email ou nome de domínio)

  • Validity Fornece o status de validade deste certificado (por exemplo, valid ou expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

O status da identidade externa do dispositivo (por exemplo, valid ou error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

Indica se o dispositivo possui um certificado válido emitido pela CA Webex .

xStatus Conference EndToEndEncryption InternalIdentity Identity

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

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Lê informações específicas do certificado emitido pelo Webex.

No comando mostrado, substitua # com o número do certificado. Replace specificinfo com um dos seguintes:

  • Fingerprint

  • NotAfter Data de data de término

  • NotBefore Data de data de início

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Uma lista dos assuntos do certificado (por exemplo, endereço de e-endereço de email ou nome de domínio)

  • Validity Fornece o status de validade deste certificado (por exemplo, valid ou expired)

Tabela 3. Em APIs de chamada para reuniões criptografadas de ponta a ponta e identidade verificada

Chamada API

Descrição

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Estes três eventos agora incluem EndToEndEncryptionStatus, EndToEndEncryptionIdentity, e EndToEndEncryptionCertInfo para o participante afetado.

Tabela 4. APIs relacionadas ao ClientSecret para reuniões criptografadas de ponta a ponta e identidade verificada

Chamada API

Descrição

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

ou

xCommand Security ClientSecret Populate Secret: JWEblob

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.

xCommand Security Certificates Services Add JWEblob

Adiciona um certificado (com chave privada).

Estendemos este comando para aceitar um blob JWE que contém os dados PEM criptografados.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Ativa um certificado específico para o WebexIdentity. Para isso Purpose, o comando exigirá que a impressão digital de identificação seja criptografada e serializada em um blob JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Desativa um certificado específico para WebexIdentity. Para isso Purpose, o comando exigirá que a impressão digital de identificação seja criptografada e serializada em um blob JWE.