Os usuários escolhem a nova tipo de reunião ao agendar uma reunião. Ao admitir participantes do lobby, e durante a reunião, o anfitrião 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 uns aos outros.

Compartilhe as seguintes informações com os seus hosts de reunião:

Verificando identidade

de ponta a ponta verificação de identidade oferece segurança adicional para uma reunião criptografada de ponta a ponta.

Quando os participantes ou dispositivos se associarem a um grupo MLS compartilhado (Messaging Layer Security), eles apresentarão seus certificados aos outros membros do grupo que então validarem os certificados contra a autoridade de certificação de emissão/ies (CA). Ao confirmar que os certificados são válidos, a CA verifica a identidade dos participantes e a reunião mostra os participantes/dispositivos conforme verificado.

Os usuários das Aplicativo Webex Meetings se autenticam em relação ao armazenamento de identidade Webex, o que os emite um token de acesso quando eles têm sucesso. Se eles precisam de um certificado para verificar sua identidade - em uma reunião criptografada de ponta a ponta - o Webex CA emite um certificado com base no token de acesso. Ainda não fornecemos uma maneira Webex Meetings os usuários recebam 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:

  • Para o caso de 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 possuem IDs de usuário da mesma maneira que os usuários, então o Webex usa (um de) o(s) domínio(s) da sua organização ao escrever a identidade do certificado do dispositivo (Nome comum (CN)).

  • Para o caso de CA externa, você solicita e compra certificados de dispositivo diretamente do seu 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 faz com que seja o modo de garantir a verdadeira criptografia de ponta a ponta e a identidade verificada, e evitar a possibilidade de que a Cisco possa sair da 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 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, 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 nome alternativo do assunto (SAN) serão exibidos na interface de usuário da reunião Webex, conforme descrito em Criptografia de ponta a ponta com Verificação de identidade para Webex Meetings.

Recomenda-se usar um certificado separado por dispositivo e ter um CN único por dispositivo. Isso pode, por exemplo, ser "meeting-room-1.example.com", para a 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 o segredo do cliente, é possível gerenciar de forma segura o certificado de identidade Webex externo através do xAPI. No momento, isso está limitado a dispositivos on-line.

Atualmente, o Webex fornece comandos de API para gerenciar isso.

Dispositivos

Os dispositivos Webex Room Cloud-registered Webex Room Desk e as séries Webex Desk podem entrar em reuniões criptografadas de ponta a ponta, incluindo:

  • Webex Board

  • Webex Desk Pro

  • Mesa Webex

  • Webex Room Kit

  • Webex Room Kit Mini

Os seguintes dispositivos não podem entrar de ponta a ponta de reuniões criptografadas:

  • Webex Série C

  • Séries Webex DX

  • Webex EX Series

  • Webex MX Series

  • Dispositivos SIP de terceiros

Clientes de software

  • A partir da 41.7, o Webex Meetings de desktop remoto pode entrar em reuniões criptografadas de ponta a ponta.

  • O aplicativo Webex não pode entrar em reuniões criptografadas de ponta a ponta.

    Se sua organização permite 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 web Webex não pode entrar em reuniões criptografadas de ponta a ponta.

  • Os clientes soft SIP de terceiros não podem entrar em reuniões criptografadas de ponta a ponta.

Identidade

  • Não fornecemos quaisquer opções do Control Hub para que você gerencie a identidade do dispositivo verificada externamente. Essa decisão é por design, porque, para a verdadeira criptografia de ponta a ponta, apenas você deve saber/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, não fornecemos nenhuma ferramenta para ajudá-lo com a solicitação ou criptografia dos certificados de identidade do seu dispositivo e suas chaves privadas. No momento, fornecemos uma "receita" para você projetar suas próprias ferramentas, com base em técnicas de criptografia padrão da indústria, para ajudar com esses processos. Nós não queremos ter acesso real ou percebido às suas chaves ou segredos.

Reuniões

  • de ponta a ponta criptografadas atualmente suportam um máximo de 200 participantes.

  • Dos 200 participantes, um máximo de 25 dispositivos verificados externamente podem entrar, e eles devem ser os primeiros participantes a entrar nareunião.

    Quando um número maior de dispositivos participa de uma reunião, nossos serviços de mídia backend tentam transcodificar os fluxos de mídia. Se não podemos descriptografar, transcodificar e criptografar a mídia (porque não temos e não devemos ter as chaves de criptografia dos dispositivos), a transcodificação falha.

    Para atenuar essa limitação, recomendamos reuniões menores para dispositivos ou aprovamos os convites entre clientes do Meetings e dispositivos.

Interface de gerenciamento

É altamente recomendável que você use o Control Hub para gerenciar seu site de Reuniões.

O principal motivo para isso é a diferença entre a maneira como o Control Hub e o administração do site a identidade. As organizações do Control Hub têm a identidade centralizada para toda a organização, enquanto no administração do site, a identidade é controlada em um site, de acordo com o site.

Isso significa que você não pode ter a opção de identidade verificada pela Cisco para usuários que são gerenciados de administração do site. Esses usuários recebem um certificado anônimo para entrar em uma reunião criptografada de ponta a ponta, e eles podem ser excluídos de reuniões onde o host deseja garantir a identidade.

Informações relacionadas

Coletando amostras de blocos JWE

Amostra de JWE corretamente criptografado com base em determinados parâmetros (apêndice)

  • Webex Meetings 41.7.

  • Dispositivos das séries Webex Room e Webex Desk registrados em nuvem, em execução 10.6.1-RoomOS_August_2021.

  • Acesso administrativo ao site da reunião no Control Hub para ativar a nova tipo de sessão para os usuários.

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

Você pode pular esta etapa se não precisar de identidade verificada externamente.

Para o nível mais alto 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 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, estes são os parâmetros a usar:

  • 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 mas é sua escolha.

  • 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. Ainda não é possível conectá-los à rede.

Se você tiver dispositivos existentes que deseja atualizar para usar a identidade verificada externamente, será necessário redefinir os dispositivos de fábrica.

  • Salve a configuração existente se você quiser 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 mudanças 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.

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 criptografada e do certificado, usando a Criptografia JSON Web (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, o onus fica com você para:

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

    Abaixo, explicamos o processo e os parâmetros (não-segredo) que você precisará, e uma receita para seguir nas 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 dispositivo alterem o segredo inicial (para proteger 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.

Você precisará consultar o JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516 e JSON Web Signature (JWS).https://datatracker.ietf.org/doc/html/rfc7515

Optamos por usar a Serialização Compacta de um documento JSON para criar blocos de JWE. Os parâmetros que você precisará incluir ao criar os blobs JWE são:

  • Header JOSE (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": "add" ou "cisco-action": "populate" ou "cisco-action": "activate" ou "cisco-action": "deactivate"

      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 nomeá-lo cisco-action para atenuar potenciais conflitos com futuras extensões JWE.

    • "cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }

      Outra chave proprietária. Usamos os valores que você fornecer como entradas para a derivação de chave no dispositivo. O comando version deve ser 1(a versão da nossa função de chave de derivação). O valor de salt deve ser uma sequência codificada por URL de base64 de pelo menos 4 bytes, que você deve escolher aleatoriamente.

  • Chave criptografada JWE. Este campo está vazio. O dispositivo o deriva da inicial ClientSecret.

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

  • Texto cifradoJWE: 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 sobrescrever com um valor vazio).

    Existem diferentes tipos de carga útil, dependendo do que você está tentando fazer no dispositivo. Diferentes comandos xAPI esperam cargas diferentes, e você deve especificar a finalidade da carga útil com o 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 identificação 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 autenticar a integridade de toda a conta de serialização compacta JWE

Como nós 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 salt é uma sequência aleatória de pelo menos 4 bytes; você deve fornecer esta mesma salt ao especificar o cisco-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. Este kdf nos dispositivos é chamado "version":"1", que é a única versão atualmente tomada pelo 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.

  1. Escolha uma codificação de criptografia. Este exemplo usa A128GCM(AES com chaves de 128 bits no modo de contador Galois). Sua ferramenta pode ser usada A256GCM se preferir.

  2. 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. Codificar base64url a sequência para obter 5eZTCAP4M_Y(remova o preenchimento base64).

  3. Aqui está uma amostra scrypt chamar para criar o conteúdo chave de criptografia (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 ac qual codificação base64url para lZ66bdEiAQV4_mqdInj_rA.

  4. 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 83 qual codificação base64url para NLNd3V9Te68tkpWD.

  5. 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 header JOSE codificado em base64url é eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Este será o primeiro elemento do bloco JWE.

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

  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 uma tag criptografadas. Para este exemplo, a carga não criptografada será a conta do PEM falso this is a PEM file

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

    • A carga útil é this is a PEM file

    • A codificação de criptografia é AES 128 GCM

    • O header JOSE codificado em base64url como Dados autenticados adicionais (AAD)

    Codificar base64url da carga útil criptografada, o que deve resultar em f5lLVuWNfKfmzYCo1YJfODhQ

    Este é o quarto elemento (JWE Ciphertext) no bloco JWE.

  9. Codificar base64url a tag que você gerou no passo 8, o que deve resultar em PE-wDFWGXFFBeo928cfZ1Q

    Este é o quinto elemento no bloco JWE.

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

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

Existem novos tipos de sessão para reuniões sem confiança que estamos implantando em todos os sites de reuniões sem custo adicional. Um dos novos tipos de sessão é chamado Pro-End to End Encryption_VOIPonly. Este é o Nome do Serviço Público que podemos mudar no futuro. Para os nomes atuais dos tipos de sessão, consulte as IDs do tipo de sessão na seção Referência deste artigo.

Não há nada que você precisa fazer para obter a nova capacidade para seu site, mas você precisará conceder a nova 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 viagem de ida e volta com CSV.

1

Entre no Control Hub e abra a página de Reunião.

2

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

3

Clique em Configurar site.

4

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

Nessa página 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 a End Encryption_VOIPonly.

 

Existe um nome mais tipo de sessão com um nome muito semelhante: Criptografia Pro-End-to-End. Essa tipo de sessão inclui acesso não criptografado PSTN a reuniões. Certifique-se de que você tenha a _VOIPonly atual para garantir a criptografia de ponta a ponta. Você pode verificar o mouse sobre o link PRO na coluna do código de sessão; para este exemplo, o destino do link deve ser javascript:ShowFeature(652).

Podemos alterar os Nomes do Serviço Público para esses tipos de sessão no futuro, por exemplo, planejamos mudar o pro-end para o Encryption_VOIPonly para Criptografia E2E +Identidade.

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

Clique em Usuários e selecione um usuário para abrir o painel de configuração do usuário.

2

Na área de Serviços, clique em Cisco Webex Meetings.

3

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

4

Marque a caixa próxima à entrada Webex Meetings entrada rotulada Pro-End a End Encryption_VOIPonly.

5

Feche o painel de configuração do usuário.

6

Repita para outros usuários, se necessário.

Se você quiser atribuir isso a muitos usuários, use a opção em massa CSV.

1

Entre no Control Hub em https://admin.webex.com e abra a página de Reunião.

2

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

3

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

4

Clique em Exportar e aguarde enquantopreparamos o arquivo.

5

Quando o arquivo estiver pronto, clique em Exportar resultados e baixe. (Você precisa fechar manualmente essa janela pop-up depois de clicar Baixar.)

6

Abra o arquivo CSV baixado para edição.

Existe uma linha para cada usuário e a MeetingPrivilege coluna contém suas tipo de sessão IDs como uma lista delimitada por vírgulas.

7

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

A referência do formato de arquivo CSV em tem alguns detalhes sobre a finalidade e https://help.webex.com/en-us/5vox83 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 carregamos o arquivo.

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.

Se os dispositivos já estão integrados à organização do Control Hub e você quiser usar o Webex CA para gerar automaticamente os certificados de identificação, não precisará redefinir os dispositivos de fábrica.

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 dizer ao Webex qual domínio identifica o dispositivo, escolheremos um e ele poderá parecer errado para outros participantes da reunião.

Antes de começar

Se seus dispositivos ainda não estão onboarded, você pode seguir https://help.webex.com/n25jyr8 ou https://help.webex.com/nutc0dy. Você também deve verificar o domínio/s que você deseja usar para identificar os dispositivos (https://help.webex.com/cd6d84).

1

Entrar no Control Hub (https://admin.webex.com) e abrir a página de 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 começar

Você precisa:

  • Para obter um certificado assinado pela CA e a chave privada, em formato .pem, para cada dispositivo.

  • Para ler o tópico Compreendendo o processo de identidade externa paradispositivos , na parte Preparar este artigo.

  • Para preparar uma ferramenta de criptografia JWE com relação às informações lá.

  • Uma ferramenta para gerar sequências de byte aleatórios de comprimentos determinados.

  • Uma ferramenta para codificar bytes ou texto de base64url.

  • Um scrypt Implementação.

  • Uma palavra ou frase secreta para cada dispositivo.

1

Preencher o dispositivo ClientSecret com um segredo de texto simples:

A primeira vez que você preencher o Secret, você o fornecerá em texto simples. É por isso que recomendamos que você faça isso no console do dispositivo físico.

  1. Base64url codificar 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 próprio.

O dispositivo tem seu segredo inicial. Não se esqueça disso, você não pode recuperá-lo e deve redefinir de fábrica o dispositivo para iniciar novamente.
2

Concatenar seu certificado e chave privada:

  1. Usando um editor de texto, abra os arquivos .pem, bloquee a tecla blob do certificado e salve-os como um novo arquivo .pem.

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

3

Crie um blob JWE para usar como entrada para o comando adicionar certificado:

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

  2. Produza um conteúdo chave de criptografia sua ferramenta sscriptografada.

    Para isso, você precisa do segredo, do salt e de uma chave para corresponder com sua codificação de criptografia escolhida. Existem alguns outros valores corrigidos para fornecer (N=32768, r=8, p=1). O dispositivo usa o mesmo processo e valores para derivar o mesmo conteúdo chave de criptografia.

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

  4. Criar um header JOSE, definir alg, enc, e cisco-kdf chaves, conforme descrito em Compreendendo o processo de identidade externa para dispositivos. De definir a ação "adicionar" usando a chave:value "cisco-action":"add" no seu título JOSE (porque estamos adicionando o certificado ao dispositivo).

  5. Base64url codificar o header JOSE.

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

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

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Abra o TShell no dispositivo e execute o comando adicionar (multiline) :

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

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

Copie a impressão digital do novo certificado.

6

Ative o certificado para a finalidade WebexIdentity:

  1. Leia a impressão digital do certificado, seja do certificado em si ou da saída do xcommand Security Certificates Services Show.

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

  3. Produza um conteúdo chave de criptografia sua ferramenta sscriptografada.

    Para isso, você precisa do segredo, do salt e de uma chave para corresponder com sua codificação de criptografia escolhida. Existem alguns outros valores corrigidos para fornecer (N=32768, r=8, p=1). O dispositivo usa o mesmo processo e valores para derivar o mesmo conteúdo chave de criptografia.

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

  5. Criar um header JOSE, definir alg, enc, e cisco-kdf chaves, conforme descrito em Compreendendo o processo de identidade externa para dispositivos. De definir a ação "ativar" usando a chave:value "cisco-action":"activate" no título do seu JOSE (porque estamos ativando o certificado no dispositivo).

  6. Base64url codificar o header JOSE.

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

    A ferramenta deve ter uma sequência de 16 ou 32 byte, 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. Construir o blob JWE da seguinte forma (todos os valores são codificados de 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 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 Reuniões Pro-End a Encryption_VOIPonly).

2

Entre na reunião como o anfitrião, a partir 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.

7

Entre na reunião como um participante não autenticado da reunião.

8

Como o anfitrião, verifique se este participante aparece no lobby com o ícone de identidade correto.

9

Como o anfitrião, admitir ou rejeitar pessoas/dispositivos.

10

Valide as identidades dos participantes/dispositivos quando 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 ou qualquer outra pessoa não possa descriptografar seu conteúdo ou representar seus dispositivos? Se for o caso, você precisa de certificados de uma CA pública. Você pode ter até 25 dispositivos em uma reunião segura. Se você precisar desse nível de segurança, não deve permitir que os clientes de reuniões participem.

Para usuários que estão participando com dispositivos seguros, primeiro deixe que os dispositivos participem e de definir as expectativas dos usuários de que eles podem não ser capazes de entrar se eles participarem tarde.

Se você tiver níveis variáveis de verificação de identidade, os usuários podem verificar uns aos outros com a identidade do certificado e o código de segurança da reunião. Embora 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

1 a 1 pro-ponto Encryption_VOIPonly

660

3. De ponta a ponta do Pro 3 a Encryption_VOIPonly

Criptografia E2E + Identidade

672

3 Free50 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 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 ler mais sobre como usar a API, consulte https://help.webex.com/nzwo1ok.

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 Mode: On

Se transforma em modo de criptografia de ponta a ponta On ou Off.

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.

xStatus Conference EndToEndEncryption Availability

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.

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Indica se o dispositivo tem um certificado válido de emissão externa.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

A identidade do dispositivo como lida do Nome comum do certificado emitido externamente.

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Lê as informações do certificado a partir do certificado emitido externamente e os saídas como um bloco de JSON.

xStatus Conference EndToEndEncryption InternalIdentity Valid

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

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 que tenha vários domínios, este é o valor do PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Lê as informações do certificado a partir do certificado emitido pela Webex e os resultados como um bloco de JSON.

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

Chamada API

Descrição

xStatus Call # ServerEncryption Type

Lê a codificação de criptografia usada na conexão HTTPS à Webex. Isso é exibido para o usuário.

xStatus Conference Call # EndToEndEncryption Status

Lê o status de criptografia de chamadas de ponta a ponta. Exibido ao usuário como a presença (ou ausência) do ícone do cadeado.

xStatus Conference Call # EndToEndEncryption SecurityCode

Lê o código de segurança da reunião. Isso é exibido ao usuário e ele muda quando os participantes participam.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Lê a codificação de criptografia usada na conexão de mídia. Isso é exibido para o usuário.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Lê a codificação de criptografia usada pelo Messaging Layer Security (MLS).

xStatus Conference Call # EndToEndEncryption Roster Participant

Lista os participantes que estão contribuintes para o estado do grupo MLS nesta reunião. A lista foi descoberto pelo MLS, não pela Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

A URL WDM de um participante especificado.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

O status de verificação do participante especificado.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

A identidade principal do participante especificado, normalmente um domínio (dispositivo) ou endereço de e-mail (usuário).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

O nome de exibição do participante especificado. Assinado pelo participante/dispositivo.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

As informações do certificado do certificado do participante especificado como um blob JSON.

xCommand Conference ParticipantList Search

Estendemos este comando para incluir informações de criptografia de ponta a ponta para os participantes.

xCommand Conference ParticipantList Search

A pesquisa da lista de participantes agora inclui EndToEndEncryptionStatus, o status de verificação de identidade do participante. Este valor é exibido na IU.

xCommand Conference ParticipantList Search

A pesquisa da lista de participantes agora inclui EndToEndEncryptionIdentity, a identidade principal do participante. Normalmente, este é um domínio ou um endereço de e-mail. Este valor é exibido na IU.

xCommand Conference ParticipantList Search

A pesquisa da lista de participantes agora inclui EndToEndEncryptionCertInfo, o blob JSON que contém o certificado do participante. Este valor é exibido na IU.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

Esses três eventos agora incluem EndToEndEncryptionStatus, EndToEndEncryptionIdentity, e EndToEndEncryptionCertInfo 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 Populate Secret: "base64url-encoded" ou xCommand Security ClientSecret Populate Secret: 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 Certificates Services Add JWEblob

Adiciona um certificado (com chave privada).

Prorrogamos este comando para aceitar um blob JWE contendo os dados PEM criptografados.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Ativa um certificado específico para WebexIdentity. Para isso Purpose, o comando requer 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 a Identidade Webex. Para isso Purpose, o comando requer que a impressão digital de identificação seja criptografada e serializada em um blob JWE.