Implemente reuniões sem confiança
A segurança de confiança zero do Webex fornece criptografia de ponta a ponta e forte verificação de identidade em suas reuniões agendadas e em salas pessoais.
Os usuários escolhem o tipo de reunião quando agendam 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 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 terceiro indesejado Meddler No Meio (MITM) ataque.
Compartilhe as seguintes informações com os seus hosts de reunião:
-
Agendar uma Webex Meetings com criptografia de ponta a ponta
-
Entrar em Webex Meetings 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 se juntam a um grupo MLS compartilhado (Messaging Layer Security), eles apresentam seus certificados para os outros membros do grupo, que então validam os certificados em relação às autoridades de certificação emissoras (CA). Ao confirmar que os certificados são válidos, a autoridade de certificação verifica a identidade dos participantes e a reunião mostra os participantes/dispositivos conforme verificado.
Os usuários do aplicativo Webex se autenticam em relação ao armazenamento de identidade Webex, o que emite um token de acesso quando a autenticação é bem-sucedida. Se ele precisar 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 para que os usuários do Webex Meetings obtenham um certificado emitido por uma CA 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 da máquina do dispositivo. O certificado é assinado pela CA Webex. Os dispositivos não têm IDs de usuário da mesma maneira que os usuários têm, portanto, o Webex usa (um dos) domínios da sua organização ao escrever a identidade do certificado do dispositivo (Nome comum (CN)).
-
CA externo — solicite e compre certificados de dispositivo diretamente do emissor escolhido. Você deve criptografar, carregar diretamente e autorizar os certificados usando um segredo conhecido apenas para você.
A Cisco não está envolvida, o que torna essa a maneira de garantir verdadeira criptografia de ponta a ponta e 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 ao dispositivo quando ele se registra 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 emite o certificado sem um domínio.
Se sua organização tiver vários domínios, você pode usar o Control Hub para dizer ao Webex qual domínio o dispositivo usar para sua identidade. Você também pode usar o 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, então o Webex escolhe um para você.
Certificado de dispositivo emitido externamente
Um administrador pode provisionr um dispositivo com seu próprio certificado que foi assinado com um dos CAs públicos.
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 estão de acordo com a discrição 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 o uso de um certificado separado por dispositivo e ter um CN exclusivo por dispositivo. Por exemplo, "meeting-room-1.example.com" da organização que possui o domínio "example.com".
Para proteger totalmente o certificado externo contra violações, um recurso segredo do cliente é usado 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 da xAPI. Isso está atualmente limitado a dispositivos on-line.
Atualmente, o Webex fornece comandos de API para gerenciar isso.
Dispositivos
Os seguintes dispositivos da série Webex Room registrados na nuvem e da série Webex Desk podem entrar em reuniões E2EE:
-
Webex Board
-
Webex Desk Pro
-
Mesa Webex
-
Webex Room Kit
-
Webex Room Kit Mini
Os seguintes dispositivos não podem entrar em reuniões E2EE:
-
Webex Série C
-
Séries Webex DX
-
Webex EX Series
-
Webex MX Series
-
Dispositivos SIP de terceiros
Clientes de software
-
O aplicativo Webex para desktop e clientes móveis pode participar de reuniões E2EE.
-
O cliente da web Webex não pode entrar em reuniões E2EE.
-
Clientes de software SIP de terceiros não podem entrar em reuniões E2EE.
Identidade
-
Por design, não fornecemos opções do Control Hub para que você gerencie a identidade do dispositivo verificada externamente. Para a verdadeira criptografia de ponta a ponta, somente você deve conhecer/acessar os segredos e as chaves. Se introduzimos um serviço em nuvem para gerenciar essas chaves, há uma chance de elas serem interceptadas.
-
Atualmente, fornecemos uma "receita" para que você projete suas próprias ferramentas, com base em técnicas de criptografia padrão da indústria, para ajudar a solicitar ou criptografar os certificados de identidade do seu dispositivo e suas chaves privadas. Nós não queremos ter acesso real ou percebido às suas chaves ou segredos.
Reuniões
-
Atualmente, as reuniões E2EE suportam um máximo de 1000 participantes.
- Você pode compartilhar novos quadros de comunicações nas reuniões E2EE. Existem algumas diferenças em relação aos quadros de comunicações em reuniões regulares:
- Nas reuniões E2EE, os usuários não podem acessar quadros de comunicações criados fora da reunião, incluindo quadros de comunicações privados, quadros de comunicações compartilhados por outras pessoas e quadros de comunicações de espaços Webex.
- Os quadros de comunicações criados nas reuniões E2EE estão disponíveis apenas durante a reunião. Eles não são salvos e não são acessíveis após o término da reunião.
- Se alguém compartilhar conteúdo em uma reunião E2EE, você poderá anotá-lo. Para obter mais informações sobre anotações, 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 (papel técnico de segurança)
-
Criptografia da Web JSON (JWE) (Rascunho padrão IETF)
-
Webex Meetings 41.7.
-
Dispositivos das séries Webex Room e Webex Desk registrados na nuvem, executando
10.6.1-RoomOS _ A ugust_ 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 o Webex CA para emitir certificados de dispositivos para identidade verificada).
-
As salas de reuniões de colaboração devem ser 21 para que as pessoas possam entrar por meio do sistema de vídeo. Para obter mais informações, consulte Permitir que os sistemas de vídeo entrem em reuniões e eventos no site Webex .
Você pode pular 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 CA (autoridade de certificação) 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.
-
Único: Recomendamos o uso de um certificado exclusivo para cada dispositivo. Se você usar um certificado para todos os dispositivos, você está comprometendo a sua segurança.
-
Nome comum (CN) e Nome alternativo do assunto (SAN/s): Estes não são importantes para o Webex, mas devem ser valores que os humanos podem ler e associar ao dispositivo. O CN será mostrar a outros participantes da reunião como a identidade verificada principal do dispositivo, e se os usuários inspecionam o certificado através da IU da reunião, eles verão a SAN/s. Você pode querer usar nomes como
name.model@example.com. -
Formato do arquivo: Os certificados e as chaves devem estar no
formato.pem. -
Propósito: A finalidade do certificado deve ser Identidade Webex.
-
Gerando chaves: Os certificados devem ser baseados em pares de chaves ECDSA P-256 (Algoritmo de assinatura digital de curvas elípticas usando a curvas P-256).
Esse requisito não se estende até a 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 registre-os no Webex. Para estar seguro, não conecte-os à rede neste momento.
Se você tiver dispositivos existentes que deseja atualizar para usar a identidade verificada externamente, deverá redefinir as configurações de fábrica dos dispositivos.
-
Salve a configuração existente se desejar mantê-la.
-
Agende uma janela quando os dispositivos não estão sendo usados ou use uma abordagem faseada. Notifique os usuários sobre as alterações que podem esperar.
-
Garanta acesso físico aos dispositivos. Se você precisa acessar dispositivos pela rede, esteja ciente de que segredos estão viajando em texto simples e você está comprometendo a sua segurança.
Depois de concluir essas etapas, permita que os sistemas de vídeo entrem em reuniões e eventos no site Webex .
Para garantir que a mídia do seu dispositivo não possa ser criptografada por ninguém, exceto pelo 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 através 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, deverá:
-
Solicite seus certificados.
-
Gere os pares de chaves dos seus certificados.
-
Crie (e proteja) um segredo inicial para cada dispositivo, para criar a capacidade de criptografia do dispositivo.
-
Desenvolva e mantenha sua própria ferramenta para criptografia de 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. Nós também fornecemos alguns dados de teste e os blocos JWE resultantes conforme esperamos, para ajudá-lo a verificar seu processo.
Uma implementação de referência não compatível usando Android 3 e a biblioteca JWCrypto está disponível a partir da Cisco, após solicitação.
-
Concatene e criptografe o certificado e a chave usando sua ferramenta e o segredo inicial do dispositivo.
-
Carregue o blob JWE resultante para o dispositivo.
-
De definir a finalidade do certificado criptografado a ser usado para a identidade Webex e ativar o certificado.
-
(Recomendado) Forneça uma interface para (ou distribua) sua ferramenta para permitir que os usuários de dispositivos alterem o segredo inicial e protejam sua mídia de 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 blocos a partir dos 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 JWE são:
-
JOSE Header (protegido). No header de Criptografia e Assinatura de Objeto JSON, você DEVE incluir os seguintes pares de valores de chaves:
-
"alg":"dir"O algoritmo direto é o único que suportamos para criptografar a carga útil, e você deve usar o segredo inicial do cliente do dispositivo.
-
"enc":"A128GCM"ou"enc":"A256GCM"Suportamos estes dois algoritmos de criptografia.
-
"cisco-action": "adicionar"ou"cisco-action": "preencher"ou"cisco-action": "ativar"ou"cisco-action": "desativar"Essa é uma chave proprietária e quatro valores que podem ser considerados. 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 onde você está usando os dados criptografados.
Nós o nomeamos
cisco-actionpara mitigar potenciais confrontos com futuras extensões JWE. -
"cisco-kdf": { "versão": "1", "sal": "base64URLEncodedRandom4+Bytes" }Outra chave proprietária. Usamos os valores que você fornecer como entradas para a derivação de chave no dispositivo. A
versãodeve ser1(a versão de nossa função de derivação de chave). O valor desaltdeve ser uma sequência codificada URL base64 de pelo menos 4 bytes, que você must escolher aleatoriamente.
-
-
Chave criptografada JWE . Este campo está vazio. O dispositivo deriva-o da inicial
ClientSecret. -
Vetor de inicialização JWE . Você deve fornecer um vetor de inicialização codificado base64url para descriptografar a carga. O IV DEVE ser um valor aleatório de 12 bytes (estamos usando a família de codificação AES-GCM, que requer que o IV seja de 12 bytes de comprimento).
-
JWE AAD (dados autenticados adicionais). Você deve omitir este campo porque ele não é suportado na serialização compacta.
-
JWE Ciphertext : 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 com um valor vazio.
Existem diferentes tipos de carga útil, dependendo do que você está tentando fazer no dispositivo. Os diferentes comandos xAPI esperam diferentes cargas e você deve especificar a finalidade da carga com a tecla
cisco-actionda seguinte forma:-
Com
"cisco-action":"populate"the ciphertext is the newClientSecret. -
Com "
"cisco-action":"add"the ciphertext is a PEM blob carrying the certificate and its private key (concatenated). -
Com "
"cisco-action":"ativar"o ciphertext é a impressão digital (representação hexadecimal do sha-1) do certificado que estamos ativando para a verificação de identificação do dispositivo. -
Com "
"cisco-action":"desativar"o texto ciférico é a impressão digital (representação hexadecimal do sha-1) do certificado que estamos desativando de ser usado para verificação da identidade do dispositivo.
-
-
Tag de autenticação JWE: Este campo contém a tag de autenticação para autenticar a integridade de toda a conta de serialização compacta JWE
Como derivamos a chave de criptografia do ClientSecret
Após a primeira população do segredo, não aceitamos ou saídamos o segredo como texto simples. Isso é para evitar potenciais ataques de dicionário por alguém que poderia 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 derivado 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 produzir a mesma chave de criptografia/descriptografia do segredo do cliente.
Os dispositivos usam scrypt para derivação de chave (consulte https://en.wikipedia.org/wiki/Scrypt), com os seguintes parâmetros:
-
CustoFactor (N) é 32768
-
BlockSizeFactor (r) é 8
-
ParalelizaçãoFactor (p) é 1
-
O sal é uma sequência aleatória de pelo menos 4 bytes; você deve fornecer este mesmo
saltao especificar o parâmetrocisco-kdf. -
O comprimento da chave é de 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 64 MB
Este conjunto de parâmetros é a única configuração de scrypt que é compatível com a função de derivação de chave nos dispositivos. Esse kdf nos dispositivos é chamado "versão":"1", que é a única versão atualmente tomada pelo parâmetro cisco-kdf .
Exemplo trabalhado
Aqui está um exemplo que você pode seguir para verificar se o processo de criptografia JWE funciona do mesmo jeito que o processo criado nos dispositivos.
O cenário de exemplo é adicionar um blob PEM ao dispositivo (simular a adição de um certificado, com uma sequência muito curta em vez de um certificado completo + chave). O segredo do cliente no exemplo é ossifrage .
-
Escolha uma codificação de criptografia. Este exemplo usa
A128GCM(AES com teclas de 128 bits no Modo 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 hex)
E5 E6 53 08 03 F8 33 F6. Base64url codifica a sequência para obter5eZTCAP4M _ Y(remova o preenchimento base64). -
Aqui está uma chamada de exemplo
scryptpara 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 derivado deve ter 16 bytes (hex) como a seguir:
95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff acque base64url codifica paralZ bdEiAQV4 _mqd I nj_r A. -
Escolha uma sequência aleatória de 12 bytes para usar como um vetor de inicialização. Este exemplo usa (hex)
34 b3 5d dd 5f 53 7b af 2d 92 95 83qual base64url codifica paraNLNd3V9Te68tkpWD. -
Crie o header JOSE com serialização compacta (siga a mesma ordem de parâmetros que usamos aqui) e depois codificar base64url:
{"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M _ Y","version":"1"},"enc":"A128GCM"}O cabeçalho JOSE codificado pela base64url é
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9Este será o primeiro elemento do bloco JWE.
-
O segundo elemento do blob JWE está vazio, pois não estamos fornecendo um sistema JWE chave de criptografia.
-
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 não criptografada será o blob PEM falso
este é um arquivo PEMOs parâmetros de criptografia que você deve usar são:
Payload é
este é um arquivo PEMA codificação de criptografia é AES 128 GCM
O header JOSE codificado em base64url como Dados Autenticados Adicionais (AAD)
Base64url codifica a carga criptografada, o que deve resultar em
f5lLVuWNfKfmzYCo1YJfODhQEste é o quarto elemento (JWE Ciphertext) no bloco JWE.
-
Base64url codifica a tag que você produziu na etapa 8, o que deve resultar em
PE-wDFWGXFFBeo928cfZ1QEste é o quinto elemento no bloco JWE.
-
Concatenar os cinco elementos do blob JWE com pontos (JOSEheader.. IV.Ciphertext.Tag) para obter:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q -
Se você derivadou os mesmos valores codificados de base64url como nós mostramos aqui, usando suas próprias ferramentas, você está pronto para usá-las para proteger a criptografia E2E e a identidade verificada de seus dispositivos.
-
Este exemplo não funcionará, mas, na verdade, sua próxima etapa seria usar o blob JWE que você criou acima como a entrada no xcommand no dispositivo que adiciona o certificado:
xCommand Certificados de segurança AdicionareyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..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 Pro-End to End E ncryption_ VOIPonly . Este é o Nome do Serviço Público , que podemos mudar no futuro. Para os nomes atuais dos tipos de sessão, consulte as IDs do tipo de sessão na seção 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ão. |
| 4 |
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.
Existe um nome mais tipo de sessão com um nome muito semelhante: Criptografia de ponta a ponta . Essa tipo de sessão inclui acesso não criptografado PSTN a reuniões. Certifique-se de ter a versão _ VOIPonly para garantir a criptografia de ponta a ponta. Você pode verificar passando o mouse sobre o link PRO na coluna de 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. |
| 5 |
Se você ainda não tiver a nova tipo de sessão, entre em contato com o representante Webex. |
O que fazer em seguida
Habilita esta tipo de sessão reunião/privilégios de reunião para alguns ou todos os seus usuários.
| 1 |
Inicie sessão no Control Hub e vá para . |
| 2 |
Selecione uma conta de usuário para atualizar e selecione Meetings . |
| 3 |
No menu suspenso Configurações se aplicam a , selecione o site da reunião para atualizar. |
| 4 |
Marque a caixa ao lado de Pro-End to End E ncryption_ VOIPonly . |
| 5 |
Feche o painel de configuração do 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 baixe . (Você tem que fechar manualmente essa janela pop-up depois de clicar em Download .) |
| 6 |
Abra o arquivo CSV baixado para edição. Há uma linha para cada usuário e a coluna |
| 7 |
Para cada usuário que você deseja conceder o novo tipo de sessão, adicione A Referência do formato de arquivo CSV Webex contém detalhes sobre a finalidade e o conteúdo do arquivo CSV. |
| 8 |
Abra o painel de configuração do site Meeting no Control Hub. Se você já estiver na página de lista de sites da reunião, talvez seja preciso atualize-a. |
| 9 |
Na seção de Licenças e usuários, clique em Gerenciamento em massa. |
| 10 |
Clique em Importar e selecione o CSV editado e, em seguida, clique em Importar. Aguarde enquanto o arquivo é carregado. |
| 11 |
Quando a importação estiver concluída, você poderá clicar em Importar resultados para revisar se houve algum erro. |
| 12 |
Vá para a página Usuários e abra um dos usuários para verificar se eles têm a nova tipo de sessão. |
Você pode adicionar uma marca d'água às gravações de reuniões com o tipo de sessão Webex Meetings Pro-End to End E ncryption_ VOIPonly , 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 analisado, a gravação deve ser um arquivo AAC, MP3, M4A, WAV, MP4, AVI ou MOV não maior que 500 MB.
- A gravação deve ter mais de 100 segundos.
- Você só pode analisar as gravações de reuniões organizadas por pessoas na 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 Management , 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 de ativado, os usuários que agendam reuniões com o tipo de sessão
Webex Meetings Pro-End to End E ncryption_ VOIPonlyverão uma opção Digital Watermarking na seção Segurança.
Carregar e analisar uma reunião com marca d'água
- No Control Hub, em Monitoring , selecione Troubleshooting .
- Clique em Análise de 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 para 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 estiver 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 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 à organização do Control Hub e você quiser usar a CA do Webex para gerar automaticamente os certificados de identificação, 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 você faça isso em todos os dispositivos que terão a identidade "Cisco verificada". Se você não informar ao Webex qual domínio identifica o dispositivo, um é escolhido automaticamente e pode parecer errado para outros participantes da reunião.
Antes de começar
Se seus dispositivos ainda não estiverem integrados, siga Registrar um dispositivo no Cisco Webex usando API ou interface da Web local ou integração na nuvem para Board, Desk e Room Series . Você também deve verificar o domínio/s que deseja usar para identificar os dispositivos em Gerenciar seus domínios .
| 1 |
Inicie sessão no Control Hub e, em Management , selecione Devices . |
| 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 começar
-
Obtenha um certificado assinado pela CA e uma chave privada, no formato
.pem , 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 lá.
Certifique-se de ter uma ferramenta para gerar sequências aleatórias de bytes de determinados comprimentos.
Certifique-se de que você tenha uma ferramenta para basear64url codificar bytes ou texto.
Certifique-se de ter uma implementação
scrypt.Certifique-se de ter uma palavra ou frase secreta para cada dispositivo.
1
Preencha o ClientSecret do dispositivo com um segredo de texto simples:
A primeira vez que você preencher o Secret , você fornecê-lo em texto simples. É por isso que recomendamos fazer isso no console do dispositivo físico.
O dispositivo tem seu segredo inicial. Não se esqueça disso; você não pode recuperá-lo e deve redefinir a fábrica do dispositivo para iniciar novamente.
2
Concatenar seu certificado e chave privada:
3
Crie um blob JWE para usar como entrada para o comando adicionar certificado:
4
Abra o TShell no dispositivo e execute o comando adicionar (multiline) :
xcommand Security Certificates Services Adicionar IsEncrypted: Verdadeiro seu...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
Ative o certificado para a finalidade WebexIdentity :
O dispositivo tem um certificado criptografado, ativo e emitido pela CA, pronto para ser usado para identificá-lo em reuniões Webex criptografadas de ponta a ponta.
7
A integração do dispositivo à organização do Control Hub.
1
Agende uma reunião do tipo correto(Webex Meetings Pro-End para Terminar Encryption_VOIPonly).
2
Entre na reunião como o anfitrião, de um Webex Meetings diferente.
3
Entre na reunião a partir de um dispositivo que tenha sua identidade verificada pela CA Webex.
4
Como o host, verifique se este dispositivo aparece no lobby com o ícone de identidade correto.
5
Entre na reunião de um dispositivo que tenha sua identidade verificada por uma CA externa.
6
Como o host, 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 da reunião.
8
Como o anfitrião, verifique se esse participante aparece no lobby com o ícone de identidade correto.
9
Como o anfitrião, admitir ou rejeitar 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 reuniões criptografadas de ponta a opção de reunião padrão, ou habilita-la apenas para alguns usuários ou permitir que todos os hosts decidam? Quando você decidiu como vai usar esse recurso, prepare os usuários que usarão o recurso, especialmente com relação às limitações e o que esperar da reunião.
-
Você precisa garantir que a Cisco nem qualquer outra pessoa possa descriptografar seu conteúdo ou representar seus dispositivos? Se for o caso, você precisa de certificados de uma CA pública.
-
Se você tiver níveis variados de verificação de identidade, permita que os usuários verifiquem uns aos outros com a identidade apoiada pelo certificado. Mesmo que haja circunstâncias em que os participantes podem aparecer como não verificados, e os participantes devem saber como verificar, pessoas não verificadas podem não ser melhores.
Se você estiver usando uma CA externa para emitir os certificados do seu dispositivo, o onus fica em você para monitorar, atualizar e reaplicar certificados.
Se você criou o segredo inicial, entenda que seus usuários podem querer alterar o segredo de seu dispositivo. Você pode precisar criar uma interface/distribuir uma ferramenta para que elas possam fazer isso.
Tabela 1. IDs do tipo de sessão para reuniões criptografadas de ponta a ponta
ID do tipo de sessão
Nome do Serviço Público
638
Criptografia E2E+VoIP apenas
652
EVOIPonly pro-endncryption_
660
Pro 3 Free-End to End EVOIPonlyncryption_
Criptografia E2E + Identidade
672
Pro 3 Free50- De ponta a ponta e EVOIPonlyncryption_
673
Instrutor de educação E2E EVOIPonlyncryption_
676
Broadworks Standard mais criptografia de ponta a ponta
677
Broadworks Premium além de criptografia de ponta a ponta
681
Schoology Free além de criptografia de ponta a ponta
Estas tabelas descrevem os comandos da 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 o API para dispositivos de Webex Room e de mesa e Webex Boards.
Esses comandos xAPI estão disponíveis apenas em dispositivos que estão:
-
Registrado no Webex
-
Registrado no local e vinculado ao Webex com o Webex Edge para dispositivos
Tabela 2. APIs de nível do 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 preferido do dispositivo a partir do Control Hub. Necessário apenas se a organização tiver mais de um domínio.
O dispositivo usa este domínio quando ele solicita um certificado da CA Webex. O domínio então identifica o dispositivo.
Essa configuração não é aplicável quando o dispositivo possui um certificado ativo emitido externamente para se identificar.
Disponibilidade do xStatus Conference EndToEndEncryption
Indica se o dispositivo pode entrar em uma reunião criptografada de ponta a ponta. A API em nuvem liga para que um aplicativo emparelhado saiba se pode usar o dispositivo para entrar.
Verificação de identidade externa do xStatus Conference EndToEndEncryption
Indica se o dispositivo usa verificação externa (tem um certificado emitido externamente).
Identidade de identidade externa do xStatus Conference EndToEndEncryption
A identidade do dispositivo como lida 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 # pelo número do certificado. Substitua Specificinfo por um dos seguintes:
-
Impressão digital
-
NotAfter Data de término da validade
-
NotBefore Data de início da validade
-
Nome do Primary
-
Algoritmo PublicKeyAlgorithm
-
SerialNumber
-
Algoritmo de assinatura
-
Assunto # Nome Uma lista dos assuntos do certificado (por exemplo, endereço de e-mail ou nome de domínio)
-
Validade Fornece o status de validade deste certificado (por exemplo. valid ou expired )
Status da conferência xStatus da criptografia de extensão do xStatus de identidade externa
O status da identidade externa do dispositivo (por exemplo, valid ou error ).
Verificação do xStatus Conference EndToEndEncryption InternalIdentity
Indica se o dispositivo tem um certificado válido emitido pela CA Webex.
xStatus Conference EndToEndEncryption Identidade interna
A identidade do dispositivo como lida do Nome comum do certificado emitido pelo Webex.
Contém um nome de domínio se a organização tiver um domínio.
Fica vazio se a organização não tiver um domínio.
Se o dispositivo estiver em uma organização com vários domínios, esse será o valor de PreferredDomain .
xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # Specificinfo
Lê informações específicas do certificado emitido pelo Webex.
No comando mostrado, substitua # pelo número do certificado. Substitua Specificinfo por um dos seguintes:
-
Impressão digital
-
NotAfter Data de término da validade
-
NotBefore Data de início da validade
-
Nome do Primary
-
Algoritmo PublicKeyAlgorithm
-
SerialNumber
-
Algoritmo de assinatura
-
Assunto # Nome Uma lista dos assuntos do certificado (por exemplo, endereço de e-mail ou nome de domínio)
-
Validade Fornece o status de validade deste certificado (por exemplo. valid ou expired )
Tabela 3. APIs de chamada para reuniões criptografadas de ponta a ponta e identidade verificada
Chamada API
Descrição
xEvent Conference ParticipantList ParticipantAdicionado
xEvent Conference ParticipantList ParticipantAtualizado
xEvent Conference ParticipantList ParticipantDeleted
Esses três eventos agora incluem EndToEndEncryptionStatus , EndToEndEncryptionIdentity , e EndToEndEndEncryptionCertInfo para o participante afetado.
Tabela 4. ClientSecret relacionada a APIs para reuniões criptografadas de ponta a ponta e identidade verificada
Chamada API
Descrição
xCommand Security ClientSecret Preencher segredo: "base64url-codificado"
ou
Segurança xCommand ClientSecret Preencher segredo: JWEblob
Aceita um valor de texto sem codificação base64url para codificar o segredo do cliente no dispositivo pela primeira vez.
Para atualizar o segredo depois dessa primeira vez, você deve fornecer um blob JWE contendo o novo segredo criptografado pelo antigo segredo.
xCommand Security Certificats Services Adicionar JWEblob
Adiciona um certificado (com chave privada).
Prorrogamos este comando para aceitar um blob JWE contendo os dados PEM criptografados.
Os serviços de certificados de segurança xCommand ativam o propósito: impressão digital da identidade WebexIdentity: JWEblob
Ativa um certificado específico para WebexIdentity. Para este Propósito , o comando requer que a impressão digital de identificação seja criptografada e serializada em um blob JWE.
Os serviços de certificados de segurança xCommand desativam o propósito: impressão digital da identidade WebexIdentity: JWEblob
Desativa um certificado específico para a Identidade Webex. Para este Propósito , o comando requer que a impressão digital de identificação seja criptografada e serializada em um blob JWE.
