Obrigado pelos seus comentários.
Implantar reuniões de confiança zero
Comentários?
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 poderá ver o status de verificação de identidade de cada participante. Há também um código de reunião que é comum a todos os participantes atuais na reunião, que eles podem usar para verificar se a reunião não foi interceptada por um ataque indesejado de terceiros Meddler In The Middle (MITM).
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 os participantes ou dispositivos entram em um grupo MLS (Segurança da camada de mensagens) compartilhado, eles apresentam seus certificados aos outros membros do grupo, que, em seguida, 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 identidades Webex, que emite a eles um token de acesso quando a autenticação for bem-sucedida. Se eles precisarem de um certificado para verificar a identidade em uma reunião criptografada de ponta a ponta, a CA do Webex emitirá um certificado com base no token de acesso. No momento, não fornecemos uma maneira de os usuários do Webex Meetings obterem um certificado emitido por uma autoridade de certificação externa/de terceiros.
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 do Webex. Os dispositivos não têm IDs de usuários da mesma maneira que os usuários, então o Webex usa (um dos) domínios da sua organização ao escrever a identidade do certificado do dispositivo (nome comum (CN)).
-
CA externa — Solicite e adquira certificados de dispositivos 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 torna isso o caminho para garantir a verdadeira criptografia de ponta a ponta e a identidade verificada, e evitar 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 do Webex emitirá o certificado sem um domínio.
Se sua organização tiver vários domínios, você poderá usar o Control Hub para dizer 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 preferido para o dispositivo, o Webex escolherá um para você.
Certificado de dispositivo emitido externamente
Um administrador pode provisionar um dispositivo com o 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 Webex, conforme descrito em Criptografia de ponta a ponta com verificação de identidade do Webex Meetings.
Recomendamos usar um certificado separado por dispositivo e ter um CN exclusivo por dispositivo. Por exemplo, "meeting-room-1.example.com" para a organização que possui o domínio "example.com".
A fim de proteger totalmente o certificado externo contra adulteração, uma funcionalidade secreta de cliente é usada para criptografar e assinar vários xcommands.
Ao usar a senha do cliente, é possível gerenciar com segurança o certificado de identidade Webex externo por meio do xAPI. Atualmente, isso está limitado a dispositivos on-line.
O Webex atualmente 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 E2EE:
-
Webex Board
-
Webex Desk Pro
-
Webex Desk
-
Kit do Webex Room
-
Kit Webex Room Mini
Os seguintes dispositivos não podem entrar em reuniões E2EE:
-
Série Webex C
-
Série Webex DX
-
Série Webex EX
-
Série MX Webex
-
Dispositivos SIP de terceiros
Clientes de software
-
O aplicativo Webex para clientes de desktop e móveis podem entrar em reuniões E2EE.
-
O cliente web Webex não pode entrar em reuniões E2EE.
-
Os soft clients SIP de terceiros não podem entrar em reuniões E2EE.
Identidade
-
Por padrão, não fornecemos opções do Control Hub para que você gerencie a identidade de dispositivos verificados externamente. Para criptografia de ponta a ponta verdadeira, somente você deve conhecer/acessar os segredos e chaves. Se introduzimos um serviço em nuvem para gerenciar essas chaves, há uma chance de que elas sejam interceptadas.
-
Atualmente, fornecemos uma “receita” para você projetar suas próprias ferramentas, com base em técnicas de criptografia padrão do setor, para ajudar na solicitação ou criptografia dos certificados de identidade do dispositivo e suas chaves privadas. Não queremos ter acesso real ou percebido aos seus segredos ou chaves.
Reuniões
-
Atualmente, as reuniões E2EE suportam um máximo de 1000 participantes.
- Você poderá compartilhar novos quadros de comunicação em reuniões E2EE. Existem algumas diferenças em relação aos quadros de comunicações em reuniões regulares:
- Em reuniões E2EE, os usuários não podem acessar quadros de comunicação criados fora da reunião, incluindo quadros de comunicação privados, quadros de comunicação compartilhados por outras pessoas e quadros de comunicação de espaços Webex.
- Os quadros de comunicação criados em reuniões E2EE só estarão disponíveis durante a reunião. Eles não são salvos e não estão acessíveis após o término da reunião.
- Se alguém compartilhar conteúdo em uma reunião E2EE, você pode anotá-lo. Para obter mais informações sobre anotação, consulte Aplicativo Webex | Marcar conteúdo compartilhado com anotações.
Interface de gerenciamento
É altamente recomendável que você use o Control Hub para gerenciar seu site Meetings, pois as organizações do Control Hub têm identidade centralizada para toda a organização.
Informações relacionadas
-
Segurança de confiança zero para Webex (documento técnico de segurança)
-
Criptografia da web JSON (JWE) (Rascunho do padrão IETF)
-
Webex Meetings 41.7.
-
Dispositivos da série Webex Room e Webex Desk registrados na nuvem, executando
10.6.1-RoomOS_August_2021. -
Acesso administrativo ao site da reunião no Control Hub.
-
Um ou mais domínios verificados na organização do Control Hub (se você estiver usando a CA Webex para emitir certificados de dispositivos para identidade verificada).
-
As salas de reuniões de colaboração devem estar ativadas para que as pessoas possam entrar do seu sistema de vídeo. Para obter mais informações, consulte Permitir que sistemas de vídeo entrem em reuniões e eventos no seu site Webex.
Você pode pular esta etapa se não precisar de identidades verificadas externamente.
Para obter 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 pública (CA) 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: Recomendamos fortemente o uso de 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): Esses não são importantes para o Webex, mas devem ser valores que os seres humanos possam ler e associar ao dispositivo. O CN mostrará a outros participantes da reunião como a principal identidade verificada do dispositivo e, se os usuários inspecionarem o certificado por meio da interface do usuário da reunião, eles verão as SAN(s). Você pode querer usar nomes como
name.model@example.com. -
Formato do ficheiro: Os certificados e chaves devem estar no
.pemformato. -
Finalidade: A finalidade do certificado deve ser a Identidade Webex.
-
Chaves de geração: 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).
Este requisito não se estende à chave de assinatura. A CA pode usar uma chave RSA para assinar o certificado.
Você pode pular esta etapa se não quiser usar a identidade verificada externamente com seus dispositivos.
Se você estiver usando novos dispositivos, ainda não os registre no Webex. Para estar seguro, não conecte-os à rede neste ponto.
Se você tiver dispositivos existentes que deseja atualizar para usar identidade verificada externamente, deverá redefinir os dispositivos de fábrica.
-
Salve a configuração existente se desejar mantê-la.
-
Agende uma janela quando os dispositivos não estiverem sendo usados ou use uma abordagem faseada. Notifique os usuários sobre as alterações que eles podem esperar.
-
Garanta o acesso físico aos dispositivos. Se você precisar acessar dispositivos pela rede, esteja ciente de que os segredos estão viajando em texto simples e você está comprometendo sua segurança.
Depois de concluir estas etapas, permita que os sistemas de vídeo entrem em reuniões e eventos no seu site Webex.
Para garantir que a mídia do seu dispositivo não possa ser criptografada por ninguém que não seja o dispositivo, você deve criptografar a chave privada no dispositivo. Nós projetamos APIs para o dispositivo para permitir o gerenciamento da chave e do certificado criptografados, usando JSON Web Encryption (JWE).
Para garantir a verdadeira criptografia de ponta a ponta por meio da nossa nuvem, não podemos estar envolvidos 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 seed da 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) que você precisará são explicados abaixo, bem como uma receita para seguir em suas ferramentas de desenvolvimento de escolha. Também fornecemos alguns dados de teste e os blogues de JWE resultantes como esperamos, para ajudá-lo a verificar seu processo.
Uma implementação de referência não suportada usando o 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 identidade Webex e ative o certificado.
-
(Recomendado) Forneça uma interface para (ou distribua) sua ferramenta para permitir que os usuários do dispositivo alterem o segredo inicial e protejam a mídia 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 de seus certificados e chaves.
Consulte JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 e JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.
Usamos a Serialização compacta de um documento JSON para criar blobs JWE. Os parâmetros que você precisa incluir ao criar os blobs do JWE são:
-
Cabeçalho JOSE (protegido). No cabeçalho Assinatura de objeto e criptografia JSON, você DEVE incluir os seguintes pares chave-valor:
-
"alg":"dir"O algoritmo direto é o único que oferecemos suporte para criptografar a carga útil, e você deve usar a senha inicial do cliente do dispositivo.
-
"enc":"A128GCM"ou"enc":"A256GCM"Nós suportamos 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 pode assumir. Introduzimos essa chave para sinalizar o propósito 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 conflitos com futuras extensões da JWE. -
"cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }Outra chave proprietária. Usamos os valores fornecidos como entradas para derivação de chave no dispositivo. O
versiondeve ser1(a versão de nossa função de derivação principal). 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 da
ClientSecretinicial. -
Vetor de inicialização do JWE. Você deve fornecer um vetor de inicialização codificado por base64url para descriptografar a carga útil. O IV DEVE ser um valor aleatório de 12 bytes (estamos usando a família de cifras AES-GCM, que exige que o IV tenha 12 bytes).
-
JWE AAD (dados adicionais autenticados). Você deve omitir este campo porque ele não é suportado na serialização compacta.
-
Texto de codificação JWE: Esta é a carga criptografada que você deseja manter em segredo.
A carga útil PODE estar vazia. Por exemplo, para redefinir a senha do cliente, você precisa substituí-la com 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 o propósito da carga com a
cisco-actionchave, da seguinte forma:-
Com
"cisco-action":"populate"o texto criptografado é o novoClientSecret. -
Com "
"cisco-action":"add"o texto criptografado é um blob PEM carregando o certificado e sua chave privada (concatenada). -
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 o uso para verificação da identidade do dispositivo.
-
-
Etiqueta de autenticação JWE: Este campo contém a tag de autenticação para verificar a integridade de todo o blob JWE compactamente serializado
Como derivamos a chave de criptografia do ClientSecret
Após a primeira população do segredo, não aceitamos ou produzimos o segredo como texto simples. Isso é para evitar possíveis ataques ao dicionário por alguém que possa acessar o dispositivo.
O software do dispositivo usa a senha do cliente como 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 obter a mesma chave de criptografia/descriptografia do segredo do cliente.
Os dispositivos usam scrypt para derivação de chaves (consulte https://en.wikipedia.org/wiki/Scrypt), com os seguintes parâmetros:
-
O CostFactor (N) é 32768
-
BlockSizeFactor (r) é 8
-
O fator de paralelização (p) é 1
-
O sal é uma sequência aleatória de pelo menos 4 bytes; você deve fornecer isso mesmo
saltao especificar ocisco-kdfparâmetro. -
Os comprimentos de chave 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 é de 64MB
Este conjunto de parâmetros é a única configuração do scrypt compatível com a função de derivação de chave nos dispositivos. Este kdf nos dispositivos é chamado de "version":"1", que é a única versão atualmente usada pelo parâmetro cisco-kdf .
Exemplo trabalhado
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 string muito curta em vez de um certificado completo + chave). A senha do cliente no exemplo é ossifrage.
-
Escolha uma cifra de criptografia. Este exemplo usa
A128GCM(AES com chaves de 128 bits no modo de contador de Galois). Sua ferramenta pode usarA256GCMse preferir. -
Escolha um sal (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 de
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 acpara qual base64url codificalZ66bdEiAQV4_mqdInj_rA. -
Escolha uma sequência aleatória de 12 bytes para usar como um vector de inicialização. Este exemplo usa (hex) para
34 b3 5d dd 5f 53 7b af 2d 92 95 83qual base64url codifica oNLNd3V9Te68tkpWD. -
Crie o cabeçalho JOSE com serialização compacta (siga a mesma ordem de parâmetros que usamos aqui) e, em seguida, codificá-lo base64url:
{"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}O cabeçalho JOSE codificado em 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 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 uma tag criptografadas. Para este exemplo, a carga útil não criptografada será o falso blob PEM
this is a PEM fileOs parâmetros de criptografia que você deve usar são:
A carga útil é
this is a PEM fileA cifra de criptografia é AES 128 GCM
O cabeçalho JOSE codificado na base64url como dados autenticados adicionais (AAD)
A Base64url codifica a carga criptografada, o que deve resultar em
f5lLVuWNfKfmzYCo1YJfODhQEste é o quarto elemento (JWE Ciphertext) no blob JWE.
-
Base64url codifica a tag que você produziu no passo 8, o que deve resultar em
PE-wDFWGXFFBeo928cfZ1QEste é o quinto elemento do blob JWE.
-
Concatene os cinco elementos do blob JWE com pontos (JOSEheader..IV.Ciphertext.Tag) para obter:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q -
Se você tiver derivado os mesmos valores codificados de base64url como mostramos aqui, usando suas próprias ferramentas, você está pronto para usá-los para proteger a criptografia E2E e a identidade verificada de seus dispositivos.
-
Este exemplo não funcionará na verdade, mas, em princípio, sua próxima etapa seria usar o blob JWE que você criou acima como entrada para o xcommand no dispositivo que adiciona o certificado:
xCommand Security Certificates AddeyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
Os tipos de sessão de 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 Pro-End to End Encryption_VOIPonly. Este é o Nome do Serviço Público, que podemos alterar no futuro. Para os nomes atuais dos tipos de sessão, consulte IDs do tipo de sessão na seção Referência deste artigo.
Não há nada que você precisa fazer para obter esse recurso para seu site; você precisa conceder o novo tipo de sessão (também chamado de Privilégio de reunião) aos usuários. Você pode fazer isso individualmente por meio da página de configuração do usuário ou em massa com uma exportação/importação CSV.
| 1 | |
| 2 |
Clique em Sites, escolha o site Webex para o qual você deseja alterar as configurações e clique em Configurações. |
| 3 |
Em Configurações comuns, selecione 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 do tipo de sessão na seção Referência deste artigo. Por exemplo, você pode ver Pro-End to End Encryption_VOIPonly.
Há um tipo de sessão mais antigo com um nome muito semelhante: Criptografia pró-ponta a ponta. Esse tipo de sessão inclui acesso PSTN não criptografado às reuniões. Certifique-se de ter a versão _VOIPonly para garantir a criptografia de ponta a ponta. Você pode verificar ao passar o mouse sobre o link PRO na coluna código da sessão; para este exemplo, o destino do link deve ser Podemos alterar os Nomes de Serviço Público para esses tipos de sessão no futuro. |
| 4 |
Se você ainda não tiver o novo tipo de sessão, entre em contato com o representante Webex. |
O que fazer a seguir
Habilite este tipo de sessão/privilégio de reunião para alguns ou todos os seus usuários.
| 1 | |
| 2 |
Clique em Sites, escolha o site Webex para o qual você deseja alterar as configurações. |
| 3 |
Na seção de Licenças e usuários , clique em Gerenciamento em massa. |
| 4 |
Clique em Gerar relatório e aguarde enquanto preparamos o arquivo. |
| 5 |
Quando o arquivo estiver pronto, clique em Exportar resultados e em Baixar. (Você precisa fechar manualmente essa janela pop-up depois de clicar em Baixar.) |
| 6 |
Abra o arquivo CSV baixado para edição. Há uma linha para cada usuário e a |
| 7 |
Para cada usuário que você deseja conceder o novo tipo de sessão, adicione A Referência do formato de arquivo Webex CSV contém detalhes sobre o objetivo e o conteúdo do arquivo CSV. |
| 8 |
Abra o painel de configuração do site da reunião no Control Hub. Se você já estava na página de lista de sites 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 em Importar , selecione o CSV editado e clique em Importar. Aguarde enquanto o arquivo é carregado. |
| 11 |
Quando a importação terminar, você poderá clicar em Importar resultados para revisar se houve algum erro. |
| 12 |
Vá para a página de Usuários e abra um dos usuários para verificar se eles têm 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 ou o dispositivo de origem das gravações não autorizadas de reuniões confidenciais.
Quando este 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 para o Control Hub, que analisa a gravação e procura os identificadores exclusivos. Você pode olhar os resultados para ver qual cliente ou dispositivo de origem 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 500 MB.
- A gravação deve durar mais de 100 segundos.
- Você só pode analisar gravações de reuniões organizadas por pessoas da 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 e, em seguida, em Gerenciamento, selecione Configurações da organização.
- Na seção Marcas d'água da reunião , ative Adicionar marca d'água de áudio.
Algum tempo depois que isso é ativado, os usuários que agendam reuniões com o tipo de sessão
Webex Meetings Pro-End to End Encryption_VOIPonlyveem uma opção de Marca d'água digital na seção de Segurança.
Carregar e analisar uma reunião marcada com água
- No Control Hub, em Monitoramento, selecione Solução de problemas.
- Clique em Análise da marca d'água.
- Procure ou selecione a reunião na lista e clique em Analisar.
- Na janela Analisar marca d'água de áudio , insira um nome para sua análise.
- (Opcional) Insira uma nota na sua análise.
- Arraste e solte o arquivo de áudio a ser analisado ou clique em 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 página Analisar marca d'água .
- Selecione a reunião na lista para ver os resultados da análise. Clique em
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 ambiente, etc. Nossa tecnologia de marca d'água tem resiliência adicional de ser codificada várias vezes, como pode acontecer quando a mídia é compartilhada.
Esse recurso foi projetado para permitir a descodificação bem-sucedida do identificador de 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 perto de um terminal pessoal ou cliente de laptop, sempre crie uma gravação que resulte em uma análise bem-sucedida. À medida que o dispositivo de gravação é movido para longe da fonte ou fica obscurecido para ouvir todo o espectro de áudio, as chances de uma análise bem-sucedida diminuem.
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 devem se aplicar.
Se seus dispositivos já estiverem integrados à sua organização do Control Hub e você quiser usar a CA Webex para gerar automaticamente os certificados de identificação, você não precisará redefinir as configurações de fábrica dos dispositivos.
Este procedimento seleciona qual domínio o dispositivo usa para se identificar e só é necessário se você tiver vários domínios na organização do Control Hub. Se você tiver mais de um domínio, recomendamos que faça isso para todos os seus dispositivos que terão identidade "verificada pela Cisco". Se você não informar ao Webex qual domínio identifica o dispositivo, um será automaticamente escolhido e pode parecer errado para outros participantes da reunião.
Antes de você começar
Se os 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 na 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 |
Inicie sessão no Control Hub e, em 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
-
Obtenha um certificado assinado pela CA e uma chave privada, no
.pemformato, para cada dispositivo. -
Na guia Preparar , leia o tópico Entendendo o processo de identidade externa para dispositivos,
-
Prepare uma ferramenta de criptografia JWE com relação às informações nele contidas.
-
Certifique-se de ter uma ferramenta para gerar sequências aleatórias de bytes de determinados comprimentos.
-
Certifique-se de que você tem uma ferramenta para base64url codificar bytes ou texto.
-
Certifique-se de ter uma
scryptimplementação. -
Certifique-se de ter uma palavra ou frase secreta para cada dispositivo.
| 1 |
Preencha o do dispositivo Na primeira vez que você preencher o O dispositivo tem seu segredo inicial. Não se esqueça disso; você não pode recuperá-lo e deve redefinir as configurações de fábrica do dispositivo para iniciar novamente.
|
| 2 |
Concatene seu certificado e chave privada: |
| 3 |
Crie um blob JWE para usar como entrada no comando de adição de certificado: |
| 4 |
Abra o TShell no dispositivo e execute o comando de adição (multilinha): |
| 5 |
Verifique se o certificado foi adicionado executando Copie a impressão digital do novo certificado. |
| 6 |
Ative o certificado para o propósito O dispositivo tem um certificado criptografado 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 |
Agende uma reunião do tipo correto (Webex Meetings Pro-End to End Encryption_VOIPonly). |
| 2 |
Entre na reunião como organizador a partir de um cliente Webex Meetings. |
| 3 |
Entre na reunião usando um dispositivo que tenha sua identidade verificada pela CA do Webex. |
| 4 |
Como organizador, verifique se este dispositivo aparece no lobby com o ícone de identidade correto. |
| 5 |
Entre na reunião usando um dispositivo que tenha sua identidade verificada por uma CA externa. |
| 6 |
Como organizador, verifique se este dispositivo aparece no lobby com o ícone de identidade correto. Saiba mais sobre os ícones de identidade. |
| 7 |
Entrar na reunião como um participante de reuniões não autenticado. |
| 8 |
Como organizador, verifique se este participante aparece no lobby com o ícone de identidade correto. |
| 9 |
Como organizador, admita ou rejeite pessoas/dispositivos. |
| 10 |
Valide as identidades de participante/dispositivo sempre que possível, verificando os certificados. |
| 11 |
Verifique se todos na reunião veem o mesmo código de segurança da reunião. |
| 12 |
Entre na reunião com um novo participante. |
| 13 |
Verifique se todos veem o mesmo novo código de segurança da reunião. |
-
Você vai tornar as reuniões criptografadas de ponta a ponta a opção de reunião padrão, habilitá-la apenas para alguns usuários ou permitir que todos os organizadores decidam? Quando você decidir como usará esse recurso, prepare os usuários que o usarão, especialmente no que diz respeito à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 representar seus dispositivos? Se sim, você precisa de certificados de uma CA pública.
-
Se você tiver níveis variáveis de verificação de identidade, permita que os usuários verifiquem uns aos outros com a identidade comprovada por certificado. Mesmo que haja circunstâncias em que os participantes possam aparecer como Não verificados e os participantes devam saber como verificar, as pessoas não verificadas podem não ser impostores.
Se você estiver usando uma CA externa para emitir os certificados do dispositivo, a responsabilidade será sobre você para monitorar, atualizar e reaplicar os certificados.
Se você criou o segredo inicial, entenda que seus usuários podem querer alterar o segredo do dispositivo. Talvez seja necessário criar uma interface/distribuir uma ferramenta para permitir que eles façam isso.
|
ID do tipo de sessão |
Nome do serviço público |
|---|---|
|
638 |
Somente criptografia E2E + VoIP |
|
652 |
Somente Encryption_VOIP profissional de ponta a ponta |
|
660 |
Pro 3 gratuito de ponta a ponta Encryption_VOIPonly Criptografia E2E + Identidade |
|
672 |
Pro 3 gratuito50 de ponta a ponta Encryption_VOIPonly |
|
673 |
Instrutor de educação E2E Encryption_VOIPonly |
|
676 |
Broadworks Standard mais criptografia de ponta a ponta |
|
677 |
Broadworks Premium mais criptografia de ponta a ponta |
|
681 |
Schoology Free plus criptografia de ponta a ponta |
Estas tabelas descrevem os comandos de API de 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 dispositivos Webex Room e Desk e Webex Boards.
Esses 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 for Devices
|
Chamada de API |
Descrição |
|---|---|
|
|
Essa configuração é feita quando o administrador define o domínio preferido do dispositivo no Control Hub. Necessário somente se a organização tiver mais de um domínio. O dispositivo usa esse domínio quando solicita um certificado da CA do Webex. O domínio então identifica o dispositivo. Essa configuração não é aplicável quando o dispositivo tem 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 chama para que um aplicativo emparelhado saiba se pode usar o dispositivo para entrar. |
|
|
Indica se o dispositivo usa |
|
|
A identidade do dispositivo conforme lida 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 tem um certificado válido emitido pela CA Webex. |
|
|
A identidade do dispositivo conforme lida 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 tem vários domínios, esse será o valor do |
|
|
Lê informações específicas do certificado emitido pelo Webex. No comando mostrado, substitua
|
|
Chamada de API |
Descrição |
|---|---|
| Esses três eventos agora incluem |
|
Chamada de API |
Descrição |
|---|---|
ou
| Aceita um valor de texto simples codificado por base64url para semear a senha do cliente no dispositivo pela primeira vez. Para atualizar o segredo após essa primeira vez, você deve fornecer um blob JWE contendo o novo segredo criptografado pelo segredo antigo. |
| Adiciona um certificado (com chave privada). Estendemos este comando para aceitar um blob JWE contendo os dados PEM criptografados. |
| Ativa um certificado específico para o WebexIdentity. Para este |
| Desativa um certificado específico para o WebexIdentity. Para este |
