Gli utenti scelgono il nuovo tipo di riunione quando pianificano una riunione. Quando si ammissione dei partecipanti dall'area di ingresso virtuale e durante la riunione, l'organizzatore può visualizzare lo stato di verifica dell'identità di ciascun partecipante. È disponibile anche un codice riunione comune a tutti i partecipanti correnti nella riunione, che possono utilizzare per verificarsi l'uno con l'altro.

Condividere le seguenti informazioni con gli organizzatori delle riunioni:

Verifica dell'identità

end-to-end verifica dell'identità fornisce ulteriore sicurezza a una riunione con crittografia end-to-end.

Quando i partecipanti o i dispositivi a unirsi a un gruppo DI SICUREZZA (MESSAGING Layer Security) condiviso, presentano i propri certificati agli altri membri del gruppo che, quindi, convalidano i certificati in base all'autorità di certificazione/IE (CA) che emette. Confermando che i certificati sono validi, l'Autorità di certificazione verifica l'identità dei partecipanti e la riunione mostra i partecipanti/dispositivi come verificati.

Gli utenti del gruppo app Webex Meetings si autenticano verso l'archivio di identità Webex e, al termine, eseguono un token di accesso. Se necessitano di un certificato per verificarne l'identità in una riunione con crittografia end-to-end, la CA Webex emissione di un certificato in base al token di accesso. Non è ancora disponibile un modo per consentire agli utenti Webex Meetings ottenere un certificato emesso da una CA di terze parti/esterna.

I dispositivi possono autenticarsi utilizzando un certificato emesso dalla CA interna (Webex) o un certificato emesso da una CA esterna:

  • Per il caso ca interno, Webex emissione di un certificato interno basato sul token di accesso dell'account macchina del dispositivo. Il certificato è firmato dalla CA Webex. I dispositivi non dispongono di ID utente come fanno gli utenti, pertanto Webex utilizza (uno dei) domini della propria organizzazione quando scrive l'identità del certificato del dispositivo (CN)).

  • Per il caso CA esterno, richiedere e acquistare i certificati dei dispositivi direttamente dall'autorità di certificazione scelta. È necessario crittografare, caricare direttamente e autorizzare i certificati utilizzando un segreto noto solo all'utente.

    Cisco non è coinvolto, il che fa in modo di garantire la crittografia end-to-end e l'identità verificata, e impedisce che Cisco possa determinare la riunione/ decrittografare il contenuto multimediale.

Certificato dispositivo emesso internamente

Webex elaga un certificato al dispositivo quando viene registrato dopo l'avvio e lo rinnova se necessario. Per i dispositivi, il certificato include l'ID account e un dominio.

Se la propria organizzazione non dispone di un dominio, la CA Webex emissione del certificato senza un dominio.

Se la propria organizzazione dispone di più domini, è possibile utilizzare Control Hub per indicare a Webex il dominio che il dispositivo utilizzare per la relativa identità. È anche possibile utilizzare l'API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Se si dispone di più domini e non si imposta il dominio preferito per il dispositivo, Webex sceglie uno per l'utente.

Certificato dispositivo emesso esternamente

Un amministratore può fornire un dispositivo con il proprio certificato che è stato firmato con una delle CA pubbliche.

Il certificato deve essere basato su una coppia di chiavi ECDSA P-256, sebbene possa essere firmato da una chiave RSA.

I valori nel certificato sono a discrezione dell'organizzazione. Il nome comune (CN) e la san (nome alternativo oggetto) verranno visualizzati nell'interfaccia utente della riunione Webex, come descritto in Crittografia end-to-end con verifica identità per Webex Meetings.

Si consiglia di utilizzare un certificato separato per dispositivo e un CN univoco per dispositivo. Ciò potrebbe, ad esempio, essere "meeting-room-1.example.com", per l'organizzazione che possiede il dominio "example.com".

Per proteggere completamente il certificato esterno dalla manomissione, viene utilizzata una funzione client-secret per crittografare e firmare diversi xcommand.

Quando si utilizza il segreto client, è possibile gestire in modo sicuro il certificato di identità Webex esterno tramite xAPI. Questo limite è attualmente limitato ai dispositivi online.

Attualmente, Webex fornisce i comandi API per gestire questa operazione.

Dispositivi

I dispositivi Webex Room registrati su cloud e i dispositivi serie Webex Desk possono accedere alle riunioni con crittografia end-to-end, incluse:

  • Webex Board

  • Webex Desk Pro

  • Scrivania Webex

  • Webex Room Kit

  • Webex Room Kit Mini

I seguenti dispositivi non possono accedere alle riunioni end-to-end crittografate:

  • Webex serie C

  • Webex serie DX

  • Webex serie EX

  • Webex serie MX

  • Dispositivi SIP di terze parti

Client software

  • Dalla versione 41.7, il client desktop Webex Meetings accedere alle riunioni con crittografia end-to-end.

  • L'app Webex non può accedere a riunioni con crittografia end-to-end.

    Se la propria organizzazione abilita l'app Webex per accedere alle riunioni avviando l'applicazione desktop Meetings, è possibile utilizzare tale opzione per accedere alle riunioni crittografate end-to-end.

  • Il client Web di Webex non può accedere a riunioni con crittografia end-to-end.

  • I soft client SIP di terze parti non possono accedere a riunioni con crittografia end-to-end.

identità

  • Non vengono fornite opzioni Control Hub per la gestione dell'identità dei dispositivi verificata esternamente. Questa decisione è stata scelta per impostazione predefinita poiché per la crittografia end-to-end, solo l'utente deve conoscere e accedere alle chiavi e all'algoritmo. Se è stato introdotto un servizio cloud per gestire tali chiavi, è possibile che vengano intercettate.

  • Attualmente non offriamo strumenti di assistenza nella richiesta o nella crittografia dei certificati di identità dei dispositivi e delle relative chiavi private. Attualmente, fornisci un 'recipe' per progettare i propri strumenti, in base alle tecniche di crittografia standard del settore, per fornire assistenza con questi processi. Non dobbiamo avere accesso reale o percepiva l'accesso alle vostre chiavi o vostre chiavi.

Riunioni

  • end-to-end le riunioni crittografate attualmente supportano un massimo di 200 partecipanti.

  • Di questi 200 partecipanti, un massimo di 25 dispositivi verificati esternamente possono accedere e devono essere i primi partecipanti a unirsi allariunione.

    Quando un numero maggiore di dispositivi si unisce a una riunione, i servizi multimediali backend tentano di transcodificare gli streaming multimediali. Se non è possibile decrittografare, codificare e crittografare nuovamente il contenuto multimediale (perché non sono disponibili e non sono disponibili le chiavi di crittografia dei dispositivi), la transcodifica non riesce.

    Per ridurre questa limitazione, si consigliano riunioni di dimensioni più ridotte per i dispositivi o sconsigliare gli inviti tra i dispositivi e i client Meetings.

Interfaccia di gestione

Si consiglia vivamente di utilizzare Control Hub per gestire il sito della riunione.

Il motivo principale di questa modifica è la differenza tra il modo in cui Control Hub e amministrazione sito l'identità. Le organizzazioni Control Hub hanno centralizzato l'identità per l'intera organizzazione mentre amministrazione sito identità è controllata su base sito per sito.

Ciò significa che non è possibile disporre dell'opzione di identità verificata da Cisco per gli utenti gestiti da amministrazione sito. Tali utenti emesse un certificato anonimo per partecipare a una riunione crittografata end-to-end e potrebbero essere escluse dalle riunioni in cui l'organizzatore desidera garantire l'identità.

Informazioni correlate

Riferimento di esempio JWE

Esempio di JWE crittografato correttamente in base ai parametri specificati (appendice)

  • Webex Meetings 41.7.

  • Dispositivi con Webex Room registrati su cloud e serie Webex Desk, in esecuzione 10.6.1-RoomOS_August_2021.

  • Accesso amministrativo al sito per riunioni in Control Hub, per abilitare il nuovo tipo di sessione per gli utenti.

  • Uno o più domini verificati nella propria organizzazione Control Hub (se si utilizza la CA Webex per emettere certificati di dispositivo per l'identità verificata).

È possibile ignorare questa operazione se non occorre un'identità verificata esternamente.

Per il livello massimo di sicurezza e per la verifica dell'identità, ciascun dispositivo deve disporre di un certificato univoco emesso da un'autorità di certificazione pubblica affidabile.

È necessario interagire con la CA per richiedere, acquistare e ricevere i certificati digitali e creare le chiavi private associate. Quando si richiede il certificato, questi sono i parametri da utilizzare:

  • Il certificato deve essere emesso e firmato da una CA pubblica nota.

  • Unico: Si consiglia vivamente di utilizzare un certificato univoco per ciascun dispositivo. Se si utilizza un certificato per tutti i dispositivi, si compromette la sicurezza.

  • Nome comune (CN) e Nome alternativo oggetto (SAN/s): Questi non sono importanti per Webex, ma devono essere valori che gli umane possono leggere e associare al dispositivo. Il CN visualizza agli altri partecipanti alla riunione come identità verificata principale del dispositivo e se gli utenti controllano il certificato attraverso l'interfaccia utente della riunione, visualizzano le SAN. Si potrebbe voler utilizzare nomi come name.model@example.com ma è una scelta propria.

  • Formato di file: I certificati e le chiavi devono essere in formato .pem.

  • Scopo: Lo scopo del certificato deve essere Identità Webex.

  • Generazione delle chiavi: I certificati devono essere basati su coppie di chiavi ECDSA P-256 (algoritmo di firma digitale a curva ellittica che utilizza la curva P-256).

    Questo requisito non estende la chiave di firma. La CA può utilizzare una chiave RSA per firmare il certificato.

È possibile ignorare questa operazione se non si desidera utilizzare l'identità verificata esternamente con i dispositivi.

Se si stanno utilizzando nuovi dispositivi, non registrarli ancora in Webex. Non è ancora possibile connetterli alla rete.

Se si dispone di dispositivi esistenti che si desidera eseguire l'aggiornamento per utilizzare l'identità verificata esternamente, sarà necessario ripristinare le impostazioni dei dispositivi.

  • Salvare la configurazione esistente se si desidera conservarla.

  • Pianificare una finestra quando i dispositivi non vengono utilizzati o utilizzare un approccio a più fasi. Avvisare gli utenti delle modifiche previste.

  • Assicurarsi dell'accesso fisico ai dispositivi. Se occorre accedere ai dispositivi su rete, tenere presente che se si viaggia in testo normale e si compromette la sicurezza.

Per assicurarsi che il contenuto multimediale del dispositivo non possa essere crittografato da un utente eccetto il dispositivo, è necessario crittografare la chiave privata sul dispositivo. Sono state progettate le API per il dispositivo per consentire la gestione della chiave crittografata e del certificato utilizzando la crittografia Web JSON (JWE).

Per garantire la crittografia end-to-end reale attraverso il nostro cloud, non possiamo essere coinvolti nella crittografia e nel caricamento del certificato e della chiave. Se occorre questo livello di sicurezza, l'accesso è importante per:

  • Richiedere i certificati.

  • Generare le coppie di chiavi dei certificati.

  • Creare (e proteggere) un segreto iniziale per ciascun dispositivo per impostare la funzionalità di crittografia del dispositivo.

  • Sviluppare e mantenere il proprio strumento per la crittografia dei file utilizzando lo standard JWE.

    Di seguito viene descritto il processo e i parametri (non segrete) necessari e una recipe da seguire negli strumenti di sviluppo disponibili. Vengono forniti anche alcuni dati di test e i risultati JWE risultante come previsto, al modo in cui ci si attende, per aiutare l'utente a verificare il processo.

    Un'implementazione di riferimento non supportata che utilizza Stereo3 e la libreria JWCrypto è disponibile da Cisco su richiesta.

  • Concatenare e crittografare il certificato e la chiave utilizzando lo strumento e il segreto iniziale del dispositivo.

  • Caricare il codice JWE risultante sul dispositivo.

  • Impostare lo scopo del certificato crittografato da utilizzare per l'identità Webex e attivare il certificato.

  • (Consigliato) Fornire un'interfaccia per (o distribuire) lo strumento per consentire agli utenti di dispositivi di modificare il segreto iniziale (per proteggere i relativi supporti).

Modalità d'uso del formato JWE

Questa sezione descrive come si prevede che l'JWE sia creato come input per i dispositivi, in modo che sia possibile creare il proprio strumento per creare le chiavi e certificati.

È necessario fare riferimento a Crittografia Web JSON (JWE)https://datatracker.ietf.org/doc/html/rfc7516 e firma Web JSON (JWS).https://datatracker.ietf.org/doc/html/rfc7515

Si è scelto di utilizzare la stringa compatta di un documento JSON per creare elementi JWE. I parametri che è necessario includere quando si creano le sistemazioni JWE sono:

  • Intestazione JOSE (protetta). Nell'intestazione Firma oggetto JSON e crittografia, È NECESSARIO includere le seguenti coppie di valori chiave:

    • "alg":"dir"

      L'algoritmo diretto è l'unico supportato per la crittografia del carico utile ed è necessario utilizzare il segreto del client iniziale del dispositivo.

    • "enc":"A128GCM" o "enc":"A256GCM"

      Sono supportati questi due algoritmi di crittografia.

    • "cisco-action": "add" o "cisco-action": "populate" o "cisco-action": "activate" o "cisco-action": "deactivate"

      Si tratta di una chiave proprietaria e di quattro valori. È stata introdotta questa chiave per segnalare lo scopo dei dati crittografati al dispositivo di destinazione. I valori sono denominati dopo i comandi xAPI sul dispositivo in cui si utilizzano i dati crittografati.

      L'abbiamo chiamata cisco-action per evitare possibili problemi con future estensioni JWE.

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

      Un'altra chiave proprietaria. I valori forniti come input per la derivazione chiave sul dispositivo vengono utilizzati. L'icona version deve essere 1(versione della funzione di derivazione chiave). Il valore di salt deve essere una sequenza base64 codificata da URL di almeno 4 byte, che è necessario scegliere in ordine casuale.

  • Chiave crittografata JWE. Campo vuoto. Il dispositivo deriva dal dispositivo iniziale ClientSecret.

  • Vettore di inizializzazione JWE. Specificare un vettore di inizializzazione codificato base64url per la decrittografia del carico utile. Il valore IV DEVE essere un valore casuale di 12 byte (stiamo utilizzando la famiglia di crittografia AES-GCM, che richiede un IV di 12 byte).

  • JWE AAD (dati autenticati aggiuntivi). È necessario omettere questo campo poiché non è supportato nel sistema Compact Compact.

  • Testo di crittografiaJWE: Questo è il carico utile crittografato che si desidera mantenere nascosto.

    Il carico utile POTREBBE essere vuoto (ad esempio, per reimpostare il segreto del client, è necessario sovrascriverlo con un valore vuoto).

    Esistono diversi tipi di carico utile, a seconda di ciò che si sta tentando di fare sul dispositivo. Diversi comandi xAPI prevedono diversi carichi di carico utile ed è necessario specificare lo scopo del carico utile con il cisco-action chiave, come segue:

    • Con "cisco-action":"populate" il testo di crittografia è il nuovo ClientSecret

    • Con " "cisco-action":"add" il testo di crittografia è un PEM che porta il certificato e la relativa chiave privata (concatenata)

    • Con " "cisco-action":"activate" il testo di crittografia è l'impronta digitale (rappresentazione esadecimale di sha-1) del certificato che stiamo attivando per la verifica dell'identità dei dispositivi

    • Con " "cisco-action":"deactivate" il testo di crittografia è l'impronta digitale (rappresentazione esadecimale di sha-1) del certificato che viene disattivato dall'uso per la verifica dell'identità del dispositivo

  • Tag autenticazione JWE: Questo campo contiene il tag di autenticazione per verificare l'integrità dell'intera applicazione JWE in modalità compatta

La modalità di derivazione chiave di crittografia dalla ClientSecret

Dopo la prima popolazione del segreto, non accettiamo o non viene restituito il segreto come testo normale. Al scopo di evitare possibili attacchi del dizionario da parte di qualcuno che potrebbe accedere al dispositivo.

Il software del dispositivo utilizza il segreto client come input per una funzione di derivazione chiave (kdf), quindi utilizza la chiave derivata per la decrittografia/crittografia del contenuto sul dispositivo.

Ciò significa per l'utente che il proprio strumento per produrre certificati JWE deve seguire la stessa procedura per specificare la stessa chiave di crittografia/decrittografia dal segreto client.

I dispositivi utilizzano scrypt per la derivazione della chiave (vedere https://en.wikipedia.org/wiki/Scrypt), con i seguenti parametri:

  • CostFactor (N) è 32768

  • BlockSizeFactor (r) ha 8

  • ParallelizationFactor (p) è 1

  • Il sale è una sequenza casuale di almeno 4 byte; è necessario fornire lo stesso salt quando si specifica la cisco-kdf.

  • La lunghezza delle chiavi è di 16 byte (se si seleziona l'algoritmo AES-GCM 128) o 32 byte (se si seleziona l'algoritmo AES-GCM 256)

  • Il limite massimo di memoria è 64 MB

Questa serie di parametri è l'unica configurazione di scrypt compatibile con la funzione di derivazione chiave sui dispositivi. Questa chiave kdf sui dispositivi è denominata "version":"1", che è l'unica versione attualmente in uso da cisco-kdf.

Esempio non elaborato

Di seguito è riportato un esempio che è possibile seguire per verificare che il processo di crittografia JWE funzioni allo stesso modo del processo creato sui dispositivi.

Lo scenario di esempio consiste nell'aggiunta di un peM di accesso al dispositivo (microfoni che aggiungono un certificato, con una stringa molto breve anziché una chiave completa di certificato +). Il segreto del client nell'esempio è ossifrage.

  1. Scegliere una crittografia. In questo esempio viene utilizzato A128GCM(AES con chiavi a 128 bit nella modalità contatore galois). Lo strumento potrebbe utilizzare A256GCM se si preferisce.

  2. Scegliere un sale (deve essere una sequenza casuale di almeno 4 byte). In questo esempio viene utilizzato (byte esadecimali) E5 E6 53 08 03 F8 33 F6. Base64url codifica la sequenza per ottenere 5eZTCAP4M_Y(rimuovere il riempimento base64).

  3. Di seguito è riportato un esempio scrypt chiamata per creare il contenuto chiave di crittografia (cek):

    cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

    La chiave derivata deve essere di 16 byte (hex) nel modo seguente: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac che base64url codifica a lZ66bdEiAQV4_mqdInj_rA.

  4. Scegliere una sequenza casuale di 12 byte da utilizzare come vettore di inizializzazione. In questo esempio viene utilizzato (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 che base64url codifica a NLNd3V9Te68tkpWD.

  5. Creare l'intestazione JOSE con compact json (seguire lo stesso ordine dei parametri utilizzati qui) e codificare base64url:

    {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

    L'intestazione JOSE codificata base64url è eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Questo sarà il primo elemento del sistema JWE.

  6. Il secondo elemento del sistema JWE è vuoto poiché non viene fornito un chiave di crittografia JWE.

  7. Il terzo elemento di JWE è il vettore di inizializzazione NLNd3V9Te68tkpWD.

  8. Utilizzare lo strumento di crittografia JWE per produrre un carico utile e un tag crittografati. Per questo esempio, il carico utile non crittografato sta per essere il falso PEMrca this is a PEM file

    I parametri di crittografia da utilizzare sono:

    • Carico utile this is a PEM file

    • La crittografia della crittografia è AES 128 GCM

    • Intestazione JOSE codificata base64url come dati autenticati aggiuntivi (AAD)

    Base64url codifica il carico utile crittografato, che dovrebbe provocare f5lLVuWNfKfmzYCo1YJfODhQ

    Questo è il quarto elemento (testo di crittografia JWE) nel sistema JWE.

  9. Base64url codificare il tag prodotto al punto 8 per determinare PE-wDFWGXFFBeo928cfZ1Q

    Questo è il quarto elemento nella finestra JWE.

  10. Concatenare i cinque elementi del modello JWE con punti (JOSEheader.. IV.Ciphertext.Tag) per ottenere:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Se sono stati derivati gli stessi valori codificati base64url mostrati qui, utilizzando i propri strumenti, si è pronti a utilizzarli per proteggere la crittografia E2E e l'identità verificata dei dispositivi.

  12. Questo esempio non funziona, ma in generale, il passo successivo consiste nell'utilizzare il comando JWE creato sopra come input al comando xcommand sul dispositivo che aggiunge il certificato:

    xCommand Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Sono disponibili nuovi tipi di sessione per le riunioni con attendibilità zero che verranno ri sul sito di tutte le riunioni senza costi aggiuntivi. Uno dei nuovi tipi di sessione è denominato Pro-End to End Encryption_VOIPonly. Questo è il nome del servizio pubblico che potrebbe cambiare in futuro. Per i nomi correnti dei tipi di sessione, vedere ID tipo di sessione nella sezione Riferimento di questo articolo.

Non è necessario eseguire alcuna operazione per ottenere la nuova funzionalità per il sito, ma occorre concedere il nuovo privilegio a tipo di sessione (denominato anche privilegio riunione). È possibile effettuare questa operazione singolarmente attraverso la pagina di configurazione dell'utente o in massa con un round trip di esportazione/importazione CSV.

1

Accedere a Control Hub e aprire la pagina Riunione.

2

Fare clic sul nome del sito per aprire il pannello di configurazione del sito.

3

Fare clic su Configura sito.

4

Nell'area Impostazioni comuni, fare clic su Tipi disessione.

In tale pagina, dovrebbero essere visualizzati uno o più tipi di sessione di crittografia end-to-end. Fare riferimento all'elenco di ID dei tipi di sessione nella sezione Riferimento di questo articolo. Ad esempio, è possibile visualizzare Pro-End to End Encryption_VOIPonly.

 

Una versione precedente tipo di sessione con un nome molto simile: Crittografia Pro-End to End. Questa tipo di sessione include l'accesso degli utenti non PSTN alle riunioni. Accertarsi di disporre della _VOIPonly corretta per garantire la crittografia end-to-end. È possibile controllare passando il mouse sul collegamento PRO nella colonna del codice di sessione; ad esempio, la destinazione del collegamento deve essere javascript:ShowFeature(652).

È possibile modificare i nomi dei servizi pubblici per questi tipi di sessione in futuro, ad esempio, si prevede di modificare l'opzione Da pro-end a Encryption_VOIPonly in Crittografia E2E + Identità.

5

Se ancora non si dispone delle nuove tipo di sessione, contattare il personale Webex.

Operazione successivi

Abilitare questo privilegio tipo di sessione/riunione per alcuni o tutti gli utenti.

1

Fare clic su Utenti e selezionare un utente per aprire il pannello di configurazione dell'utente.

2

Nell'area Servizi, fare clic su Cisco Webex Meetings .

3

Selezionare il sito (se l'utente si trova in più di uno) e fare clic su Ospita.

4

Selezionare la casella accanto alla voce Webex Meetings gruppo con etichetta Pro-End to End Encryption_VOIPonly.

5

Chiudere il pannello di configurazione dell'utente.

6

Se necessario, ripetere questa operazione per gli altri utenti.

Se si desidera assegnare questa opzione a molti utenti, utilizzare l'opzione di massa CSV.

1

Accedere a Control Hub su https://admin.webex.com e aprire la pagina Riunione.

2

Fare clic sul nome del sito per aprire il pannello di configurazione del sito.

3

Nella sezione Licenze e utenti, fare clic su Gestione di massa.

4

Fare clic su Esporta e attendere la preparazione delfile.

5

Quando il file è pronto, fare clic su Esporta risultati, quindi scaricare . (È necessario chiudere manualmente tale finestra popup dopo aver fatto clic su Scarica.

6

Aprire il file CSV scaricato per la modifica.

Per ciascun utente è presente una riga e il campo MeetingPrivilege la colonna contiene gli tipo di sessione della colonna come elenco delimitato da virgole.

7

Per ciascun utente a cui si desidera concedere il nuovo tipo di sessione, aggiungere 1561 come nuovo valore nell'elenco delimitato da virgola nel campo MeetingPrivilege Cella.

Il riferimento al formato del file CSV su contiene alcuni https://help.webex.com/en-us/5vox83 dettagli sullo scopo e sul contenuto del file CSV.

8

Aprire il pannello Configurazione sito riunione in Control Hub.

Se si era già presenti nella pagina di elenco dei siti per riunioni, potrebbe essere necessario aggiornarlo.

9

Nella sezione Licenze e utenti, fai clic su Gestione di massa.

10

Fare clic su Importa e selezionare il file CSV modificato, quindi fare clic su Importa. Attendere il caricamento del file.

11

Al termine dell'importazione, è possibile fare clic su Importa risultati per esaminare la presenza di errori.

12

Andare alla pagina Utenti e aprire uno degli utenti per verificare se dispongono del nuovo indirizzo tipo di sessione.

Se i dispositivi sono già presenti nell'organizzazione Control Hub e si desidera utilizzare l'autorità di certificazione Webex per generare automaticamente i relativi certificati di identificazione, non è necessario ripristinare le impostazioni delle impostazioni dei dispositivi.

Questa procedura seleziona il dominio utilizzato dal dispositivo per identificarsi ed è richiesta solo se si dispone di più domini nella propria organizzazione Control Hub. Se si dispone di più domini, si consiglia di effettuare questa operazione per tutti i dispositivi con identità "Cisco verificata". Se non si identifica il dominio Webex, ne viene scelto uno e l'errore potrebbe essere errato per gli altri partecipanti alla riunione.

Operazioni preliminari

Se i dispositivi non sono ancora presenti, è possibile seguire https://help.webex.com/n25jyr8 o https://help.webex.com/nutc0dy. È necessario anche verificare il/i dominio/i che si desidera utilizzare per identificare i dispositivi (https://help.webex.com/cd6d84).

1

Accedere a Control Hub (https://admin.webex.com) e aprire la pagina Dispositivi.

2

Selezionare un dispositivo per aprire il relativo pannello di configurazione.

3

Selezionare il dominio che si desidera utilizzare per identificare questo dispositivo.

4

Ripetere per gli altri dispositivi.

Operazioni preliminari

Hai bisogno:

  • Per ottenere un certificato firmato dalla CA e una chiave privata, in formato .pem, per ciascun dispositivo.

  • Per leggere l'argomento Processo di identità esterna per dispositivi, nella parte Preparazione di questo articolo.

  • Per preparare uno strumento di crittografia JWE in relazione alle informazioni in questo punto.

  • Uno strumento per generare sequenze di byte casuali di date di lunghezza.

  • Uno strumento per base64url codifica byte o testo.

  • Un scrypt Implementazione.

  • Una parola o una frase segrete per ciascun dispositivo.

1

Inserire i dati nel campo del dispositivo ClientSecret con un segreto in testo normale:

La prima volta che si compila il campo Secret, l'utente lo fornisce in testo normale. Per questo motivo si consiglia di utilizzare questa opzione nella console del dispositivo fisico.

  1. Base64url codifica la frase segreto per questo dispositivo.

  2. Aprire TShell sul dispositivo.

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

    Il comando di esempio precedente compila il campo Secret con la frase 0123456789abcdef. È necessario scegliere il proprio.

Il dispositivo ha il segreto iniziale. Non dimenticare che non è possibile recuperarlo e occorre ripristinare le impostazioni delle impostazioni di fabbrica per avviare nuovamente il dispositivo.
2

Concatenare il certificato e la chiave privata:

  1. Utilizzando un editor di testi, aprire i file .pem, incollare la chiave e salvare il certificato come un nuovo file .pem.

    (Questo è il testo del carico utile che verrà crittografato e inserito nel sistema JWE)

3

Creare un codice JWE da utilizzare come input per il comando di aggiunta del certificato:

  1. Creare una sequenza casuale di almeno 4 byte. Questo è il sale.

  2. Creare un modello di chiave di crittografia con lo strumento scrypt.

    A tale scopo, occorre il segreto, il sale e una lunghezza chiave corrispondenti alla crittografia scelta. Esistono altri valori fissi da fornire (N=32768, r=8, p=1). Il dispositivo utilizza lo stesso processo e valori per modificare lo stesso contenuto chiave di crittografia.

  3. Creare una sequenza casuale di esattamente 12 byte. Questo è il vettore di inizializzazione.

  4. Crea un'intestazione JOSE, impostazione alg, enc e cisco-kdf come descritto in Processo di identità esterna per i dispositivi. Impostare l'azione di aggiunta utilizzando il valore key:value "cisco-action":"add" nell'intestazione JOSE (poiché si sta aggiungendo il certificato al dispositivo).

  5. Base64url codifica l'intestazione JOSE.

  6. Utilizzare lo strumento di crittografia JWE con la crittografia scelta e l'intestazione JOSE codificata base64url per crittografare il testo dal file pem concatenato.

  7. Base64url codifica il vettore di inizializzazione, il carico utile PEM crittografato e il tag di autenticazione.

  8. Costruire il sistema JWE come segue (tutti i valori sono codificati base64url):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Aprire TShell sul dispositivo ed eseguire il comando di aggiunta (multiline):

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

Verificare che il certificato sia aggiunto eseguendo xcommand Security Certificates Services Show

Copiare le impronte digitali del nuovo certificato.

6

Attivare il certificato allo scopo di WebexIdentity:

  1. Leggere l'impronta del certificato, sia dal certificato stesso che dall'output di xcommand Security Certificates Services Show.

  2. Creare una sequenza casuale di almeno 4 byte e base64url codificare tale sequenza. Questo è il sale.

  3. Creare un modello di chiave di crittografia con lo strumento scrypt.

    A tale scopo, occorre il segreto, il sale e una lunghezza chiave corrispondenti alla crittografia scelta. Esistono altri valori fissi da fornire (N=32768, r=8, p=1). Il dispositivo utilizza lo stesso processo e valori per modificare lo stesso contenuto chiave di crittografia.

  4. Creare una sequenza casuale di esattamente 12 byte e base64url codificare tale sequenza. Questo è il vettore di inizializzazione.

  5. Crea un'intestazione JOSE, impostazione alg, enc e cisco-kdf come descritto in Processo di identità esterna per i dispositivi. Impostare l'azione di attivazione utilizzando il tasto:valore "cisco-action":"activate" nell'intestazione JOSE (perché viene attivato il certificato sul dispositivo).

  6. Base64url codifica l'intestazione JOSE.

  7. Utilizzare lo strumento di crittografia JWE con la crittografia scelta e l'intestazione JOSE codificata base64url per crittografare le impronte digitali del certificato.

    Lo strumento deve eseguire un output in sequenza di 16 o 32 byte, in base all'opzione AES-GCM a 128 o 256 bit e a un tag di autenticazione.

  8. Base64urlencode l'impronta digitale crittografata e il tag di autenticazione.

  9. Costruire il sistema JWE come segue (tutti i valori sono codificati base64url):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Aprire TShell sul dispositivo ed eseguire il seguente comando di attivazione:

    xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
Il dispositivo dispone di un certificato emesso da CA crittografato, attivo e pronto per essere utilizzato per identificarlo nelle riunioni Webex con crittografia end-to-end.
7

Onboard il dispositivo nell'organizzazione Control Hub.

1

Pianificare una riunione del tipo corretto (Webex Meetings Pro-End a fine Encryption_VOIPonly).

2

Accedere alla riunione come organizzatore da un Webex Meetings organizzatore.

3

Accedere alla riunione da un dispositivo di cui è stata verificata l'identità dalla CA Webex.

4

In quanto organizzatore, verificare che questo dispositivo venga visualizzato nell'ingresso virtuale con l'icona di identità corretta.

5

Partecipare alla riunione da un dispositivo di cui è stata verificata l'identità da una CA esterna.

6

In quanto organizzatore, verificare che questo dispositivo venga visualizzato nell'ingresso virtuale con l'icona di identità corretta.

7

Accedere alla riunione come partecipante di riunioni non autenticate.

8

In quanto organizzatore, verificare che il partecipante venga visualizzato nell'ingresso virtuale con l'icona di identità corretta.

9

In quanto organizzatore, ammettere o rifiutare persone/dispositivi.

10

Convalidare l'identità dei partecipanti/dispositivi, ove possibile, controllando i certificati.

11

Verificare che tutti i partecipanti alla riunione vedano lo stesso codice di sicurezza della riunione.

12

Accedere alla riunione con un nuovo partecipante.

13

Verificare che tutti vedano lo stesso codice di sicurezza della riunione nuovo.

Si stanno per impostare le riunioni con crittografia end-to-end come opzione predefinita della riunione o abilitarla solo per alcuni utenti o consentire a tutti gli organizzatori di decidere? Quando si decide come utilizzare questa funzione, preparare gli utenti che la utilizzeranno, specialmente in relazione alle limitazioni e agli aspetti da prevedere nella riunione.

È necessario assicurarsi che né Cisco né altri utenti possano decrittografare il contenuto o rappresentare i propri dispositivi? In tal caso, sono necessari i certificati di una CA pubblica. È possibile avere fino a 25 dispositivi in una riunione protetta. Se occorre questo livello di sicurezza, non consentire ai client di riunioni di partecipare.

Per gli utenti che a partecipare con dispositivi sicuri, consentire ai dispositivi di accedere prima e impostare le aspettative degli utenti che potrebbero non essere in grado di accedere se si uniscono in ritardo.

Se si dispone di diversi livelli di verifica dell'identità, consentire agli utenti di verificarsi l'un l'altro con l'identità supportata da certificato e il codice di sicurezza della riunione. Anche in alcune circostanze in cui i partecipanti possono apparire come Non verificati e i partecipanti devono sapere come controllare, le persone non verificate potrebbero non essere impostori.

Se si utilizza una CA esterna per rilasciare i certificati del dispositivo, è possibile monitorare, aggiornare e riapplicare i certificati.

Se hai creato il segreto iniziale, comprendi che i tuoi utenti potrebbero voler modificare il segreto del loro dispositivo. A tale scopo, è possibile che sia necessario creare un'interfaccia o distribuire uno strumento.

Tabella 1. ID dei tipi di sessione per le riunioni con crittografia end-to-end

ID tipo di sessione

Nome servizio pubblico

638

Solo crittografia E2E+VoIP sistema

652

Pro-End fino a fine Encryption_VOIPonly

660

Termine gratuito Pro 3 Encryption_VOIPonly

Crittografia E2E + Identità

672

Pro 3 free50-end-to-end Encryption_VOIPonly

673

istruttore e2E Encryption_VOIPonly

676

Broadworks Standard più crittografia end-to-end

677

Broadworks Premium più crittografia end-to-end

681

Crittografia gratuita gratuita più crittografia end-to-end

In queste tabelle vengono descritti i comandi API dei dispositivi Webex aggiunti per le riunioni con crittografia end-to-end e l'identità verificata. Per ulteriori informazioni sull'uso dell'API, vedere https://help.webex.com/nzwo1ok.

Tabella 2. API a livello di sistema per riunioni con crittografia end-to-end e identità verificata

chiamata API

Descrizione

xConfiguration Conference EndToEndEncryption Mode: On

Passa alla modalità di crittografia end-to-end On o Off.

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Questa configurazione viene effettuata quando l'amministratore imposta il dominio preferito del dispositivo da Control Hub. Necessario solo se l'organizzazione dispone di più domini.

Il dispositivo utilizza questo dominio quando richiede un certificato dalla CA Webex. Il dominio identifica quindi il dispositivo.

Questa configurazione non è applicabile se il dispositivo dispone di un certificato attivo ed emesso esternamente per identificare se stesso.

xStatus Conference EndToEndEncryption Availability

Indica se il dispositivo può accedere a una riunione crittografata end-to-end. L'API cloud chiama in modo che un'app accoppiata sappia se può utilizzare il dispositivo per accedere.

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Indica se il dispositivo dispone di un certificato emesso esternamente valido.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Identità del dispositivo come letta dal nome comune del certificato rilasciato esternamente.

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Legge le informazioni del certificato dal certificato emesso esternamente e le restituisce come json json.

xStatus Conference EndToEndEncryption InternalIdentity Valid

Indica se il dispositivo dispone di un certificato valido emesso dalla CA Webex.

xStatus Conference EndToEndEncryption InternalIdentity Identity

Identità del dispositivo come letta dal nome comune del certificato emesso da Webex.

Contiene un nome di dominio se l'organizzazione dispone di un dominio.

È vuoto se l'organizzazione non dispone di un dominio.

Se il dispositivo è in un'organizzazione che dispone di più domini, questo è il valore della pagina PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Legge le informazioni del certificato dal certificato emesso da Webex e le restituisce come json json.

Tabella 3. API di chiamata per riunioni con crittografia end-to-end e identità verificata

chiamata API

Descrizione

xStatus Call # ServerEncryption Type

Legge la crittografia utilizzata nella connessione HTTPS a Webex. Visualizzato all'utente.

xStatus Conference Call # EndToEndEncryption Status

Legge lo stato di crittografia end-to-end delle chiamate. Visualizzato all'utente come presenza (o assenza) dell'icona di lucchetto.

xStatus Conference Call # EndToEndEncryption SecurityCode

Legge il codice di sicurezza della riunione. Questa opzione viene visualizzata all'utente e cambia quando i partecipanti a partecipare.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Legge la crittografia di crittografia utilizzata nella connessione multimediale. Visualizzato all'utente.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Legge la crittografia utilizzata per MESSAGING Layer Security (GRUP).

xStatus Conference Call # EndToEndEncryption Roster Participant

Elenca i partecipanti che contribuiscono allo stato del gruppoINI IN questa riunione. L'elenco è rilevato daMPERS, non da Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

URL WDM di un partecipante specificato.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

Lo stato di verifica del partecipante specificato.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

Identità principale del partecipante specificato, solitamente un dominio (dispositivo) o un indirizzo e-mail (utente).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

Il nome di visualizzazione del partecipante specificato. Firma del partecipante/dispositivo.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

Informazioni del certificato dal certificato del partecipante specificato come json json.

xCommand Conference ParticipantList Search

Questo comando è stato esteso per includere informazioni di crittografia end-to-end per i partecipanti.

xCommand Conference ParticipantList Search

La ricerca dell'elenco dei partecipanti ora include EndToEndEncryptionStatus, lo stato di verifica dell'identità del partecipante. Questo valore viene visualizzato nell'interfaccia utente.

xCommand Conference ParticipantList Search

La ricerca dell'elenco dei partecipanti ora include EndToEndEncryptionIdentity, l'identità principale del partecipante. Questo è solitamente un dominio o un indirizzo e-mail. Questo valore viene visualizzato nell'interfaccia utente.

xCommand Conference ParticipantList Search

La ricerca dell'elenco dei partecipanti ora include EndToEndEncryptionCertInfo, il json contenente il certificato del partecipante. Questo valore viene visualizzato nell'interfaccia utente.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

Questi tre eventi ora includono EndToEndEncryptionStatus, EndToEndEncryptionIdentity e EndToEndEncryptionCertInfo per il partecipante interessato.

Tabella 4. API correlate a ClientSecret per riunioni con crittografia end-to-end e identità verificata

chiamata API

Descrizione

xCommand Security ClientSecret Populate Secret: "base64url-encoded" o xCommand Security ClientSecret Populate Secret: JWEblob

Accetta un valore di testo normale codificato base64url per la prima volta che viene restituito il segreto client sul dispositivo.

Per aggiornare il segreto dopo tale prima volta, occorre fornire un agente JWE contenente il nuovo segreto crittografato dal segreto precedente.

xCommand Security Certificates Services Add JWEblob

Aggiunge un certificato (con chiave privata).

È stato esteso questo comando per accettare un sistema JWE contenente dati PEM crittografati.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Attiva un certificato specifico per WebexIdentity. Per questo Purpose, il comando richiede la crittografia e la crittografia dell'impronta digitale in un sistema JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Disattiva un certificato specifico per WebexIdentity. Per questo Purpose, il comando richiede la crittografia e la crittografia dell'impronta digitale in un sistema JWE.