Esperienza utente

Gli utenti scelgono il tipo di riunione quando pianificano una riunione. Quando si ammettono i partecipanti dall'area di ingresso virtuale e durante la riunione, l'organizzatore può visualizzare lo stato di verifica dell'identità di ciascun partecipante. Esiste anche un codice riunione comune a tutti gli attuali partecipanti alla riunione, che possono utilizzare per verificare che la riunione non sia stata intercettata da un Meddler In The Middle (MITM) di terze parti indesiderato.

Condividere le seguenti informazioni con gli organizzatori delle riunioni:

Verifica identità con CA interna o esterna

Verifica identità

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

Quando i partecipanti o i dispositivi accedono a un gruppo MLS condiviso (Messaging Layer Security), presentano i certificati agli altri membri del gruppo, che quindi convalidano i certificati in base alle autorità di certificazione (CA) che li rilasciano. Confermando la validità dei certificati, la CA verifica l'identità dei partecipanti e la riunione mostra i partecipanti/dispositivi come verificato.

Gli utenti dell'app Webex eseguono l'autenticazione dall'archivio delle identità Webex, che genera un token di accesso quando l'autenticazione ha esito positivo. Se è necessario un certificato per verificare la propria identità in una riunione con crittografia end-to-end, l'autorità di certificazione Webex genera un certificato in base al token di accesso. Attualmente, gli utenti Webex Meetings non possono ottenere un certificato emesso da un'autorità di certificazione esterna/di terze parti.

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

  • CA interna: Webex emette un certificato interno in base al token di accesso dell'account macchina del dispositivo. Il certificato è firmato dalla CA Webex. I dispositivi non dispongono di ID utente nello stesso modo in cui gli utenti utilizzano Webex (uno dei) domini della tua organizzazione quando scrivi l'identità del certificato dispositivo (nome comune (CN)).

  • CA esterna: richiedere e acquistare i certificati del dispositivo direttamente dall'emittente scelto. È necessario crittografare, caricare direttamente e autorizzare i certificati utilizzando un segreto noto solo all'utente.

    Cisco non è coinvolto, il che rende questo il modo per garantire la vera crittografia end-to-end e l'identità verificata, e prevenire la possibilità teorica che Cisco possa intercettare 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 il nome alternativo oggetto (SAN) verranno visualizzati nell'interfaccia utente della riunione Webex, come descritto nella crittografia end-to-end con verifica dell'identità per Webex Meetings.

Si consiglia di utilizzare un certificato separato per dispositivo e di disporre di un CN univoco per dispositivo. Ad esempio, "meeting-room-1.example.com" per l'organizzazione proprietaria del 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 client secret, è possibile gestire in modo sicuro il certificato di identità Webex esterno tramite xAPI. Questo limite è attualmente limitato ai dispositivi online.

Webex attualmente fornisce i comandi API per la gestione di questa operazione.

Funzioni e limitazioni

Dispositivi

I seguenti dispositivi Webex Room registrati su cloud e serie Webex Desk possono accedere alle riunioni E2EE:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

I seguenti dispositivi non possono accedere alle riunioni E2EE:

  • Webex serie C

  • Webex serie DX

  • Webex serie EX

  • Webex serie MX

  • Dispositivi SIP di terze parti

Client software

  • L'app Webex per client desktop e mobili può accedere alle riunioni E2EE.

  • Il client Web Webex non può accedere alle riunioni E2EE.

  • I client soft SIP di terze parti non possono accedere alle riunioni E2EE.

Identità

  • Per impostazione predefinita, non forniamo opzioni Control Hub per la gestione dell'identità del dispositivo verificata esternamente. Per una vera crittografia end-to-end, solo l'utente deve conoscere/accedere ai segreti e alle chiavi. Se è stato introdotto un servizio cloud per gestire tali chiavi, è possibile che vengano intercettate.

  • Attualmente forniamo una "ricetta" per progettare i propri strumenti, in base a tecniche di crittografia standard del settore, per assistere nella richiesta o crittografia dei certificati di identità del dispositivo e delle relative chiavi private. Non dobbiamo avere accesso reale o percepiva l'accesso alle vostre chiavi o vostre chiavi.

Riunioni

  • Le riunioni E2EE attualmente supportano un massimo di 1000 partecipanti.

  • È possibile condividere nuove lavagne nelle riunioni E2EE. Esistono alcune differenze rispetto alle lavagne nelle riunioni regolari:
    • Nelle riunioni E2EE, gli utenti non possono accedere alle lavagne create al di fuori della riunione, incluse lavagne private, lavagne condivise da altri e lavagne dagli spazi Webex.
    • Le lavagne create nelle riunioni E2EE sono disponibili solo durante la riunione. Non vengono salvati e non sono accessibili al termine della riunione.
    • Se qualcuno condivide contenuto in una riunione E2EE, è possibile annotarlo. Per ulteriori informazioni sulle annotazioni, vedi App Webex | Contrassegna il contenuto condiviso con le annotazioni.

Interfaccia di gestione

Si consiglia vivamente di utilizzare Control Hub per gestire il sito Meetings, poiché le organizzazioni Control Hub hanno un'identità centralizzata per l'intera organizzazione.

Risorse aggiuntive
Prerequisiti

  • Webex Meetings 41.7.

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

  • Accesso amministrativo al sito della riunione in Control Hub.

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

  • Le sale riunioni di collaborazione devono essere attivate in modo che le persone possano accedere dal proprio sistema video. Per ulteriori informazioni, vedere Consenti ai sistemi video di accedere a riunioni ed eventi sul sito Webex.

Ottieni certificati dispositivo

Puoi saltare questa fase se non hai bisogno di identità verificate esternamente.

Per il massimo livello di sicurezza e per la verifica dell'identità, ciascun dispositivo deve disporre di un certificato univoco rilasciato da un'autorità di certificazione pubblica attendibile (CA).

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

  • 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. È possibile utilizzare nomi come name.model@example.com.

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

Preparazione per l'onboarding dei dispositivi

Puoi ignorare questa operazione se non desideri utilizzare l'identità verificata esternamente con i tuoi dispositivi.

Se si stanno utilizzando nuovi dispositivi, non registrarli ancora in Webex. Per essere sicuri, non connetterli alla rete a questo punto.

Se disponi di dispositivi esistenti che desideri aggiornare per utilizzare un'identità verificata esternamente, devi ripristinare le impostazioni di fabbrica 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.

Una volta completate queste operazioni, consentire ai sistemi video di accedere alle riunioni e agli eventi sul sito Webex.

Comprendere il processo di identità esterna per i dispositivi

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. Abbiamo progettato API per il dispositivo per consentire la gestione della chiave crittografata e del certificato, utilizzando JSON Web Encryption (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 hai bisogno di questo livello di sicurezza, devi:

  1. Richiedere i certificati.

  2. Generare le coppie di chiavi dei certificati.

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

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

    Il processo e i parametri (non segreti) di cui avrai bisogno sono spiegati di seguito, così come una ricetta da seguire nei tuoi strumenti di sviluppo di scelta. 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.

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

  6. Caricare il codice JWE risultante sul dispositivo.

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

  8. (Consigliato) Fornire un'interfaccia per (o distribuire) il proprio strumento per consentire agli utenti del dispositivo di modificare il segreto iniziale e proteggere i relativi supporti da voi.

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.

Fare riferimento a JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 e JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Utilizziamo la serializzazione compatta di un documento JSON per creare blobs JWE. I parametri da includere nella creazione dei blobs 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": "A660 GCM" o "enc": "A660 GCM"

      Sono supportati questi due algoritmi di crittografia.

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

      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 denominata cisco-action per attenuare potenziali conflitti con future estensioni JWE.

    • "cisco-kdf": { "versione": "1", "sale": "base64URLEncodedRandom4+Bytes" }

      Un'altra chiave proprietaria. I valori forniti come input per la derivazione chiave sul dispositivo vengono utilizzati. La versione deve essere 1 (la versione della nostra funzione di derivazione chiave). Il valore di sale deve essere una sequenza con codifica URL base64 di almeno 4 byte, che deve scegliere in modo casuale.

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

  • 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 (ulteriori dati autenticati). È necessario omettere questo campo poiché non è supportato nel sistema Compact Compact.

  • Testo crittografico JWE: Questo è il carico utile crittografato che si desidera mantenere nascosto.

    Il payload PUÒ 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 payload diversi e è necessario specificare lo scopo del payload con il tasto azione cisco, come segue:

    • Con "cisco-action":"popolate" il testo della crittografia è il nuovo ClientSecret.

    • Con ""cisco-action":"add" il testo della crittografia è un blob PEM che trasporta il certificato e la sua chiave privata (concatenata).

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

    • Con ""cisco-action":"deactivate" il ciphertext è l'impronta digitale (rappresentazione esadecimale di sha-1) del certificato che stiamo disattivando per essere utilizzati 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

Come otteniamo la chiave di crittografia da 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 sale quando si specifica il parametro 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. Questo kdf sui dispositivi si chiama "versione":"1", che è l'unica versione attualmente utilizzata dal parametro 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 cliente nell'esempio è ossifrage.

  1. Scegliere una crittografia. Questo esempio utilizza A128GCM (AES con chiavi a 128 bit in modalità contatore Galois). Il tuo strumento potrebbe utilizzare A174 GCM se preferisci.

  2. Scegliere un sale (deve essere una sequenza casuale di almeno 4 byte). Questo esempio utilizza (byte esadecimali)E5 E6 53 08 03 F8 33 F6. Base64url codifica la sequenza per ottenere 5eZTCAP4M_Y (rimuovere l'imbottitura base64).

  3. Di seguito è riportata una chiamata di scrypt di esempio per creare la chiave di crittografia del contenuto (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 di base64url codifica a lZ66bdEiAQV4_mqdInj_rA.

  4. Scegliere una sequenza casuale di 12 byte da utilizzare come vettore di inizializzazione. Questo esempio utilizza (esadecimale) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 , dove la base64url codifica 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 in 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 del blob 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 payload non crittografato sarà il blob PEM falso questo è un file PEM

    I parametri di crittografia da utilizzare sono:

    • Payload è un file PEM

    • La crittografia della crittografia è AES 128 GCM

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

    Base64url codifica il payload crittografato, che dovrebbe risultare in f5lLVuWNfKfmzYCo1YJfODhQ

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

  9. Base64url codifica il tag prodotto al punto 8, che dovrebbe risultare in 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:

    xCertificati di sicurezza dei comandi Aggiungi eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

I tipi di sessione per le riunioni zero-trust sono disponibili per tutti i siti di riunioni senza costi aggiuntivi. Uno di questi tipi di sessione si chiama Pro-End to End Encryption_VOIPonly. Questo è il Nome servizio pubblico, che potremmo cambiare in futuro. Per i nomi correnti dei tipi di sessione, vedere ID tipo di sessione nella sezione Riferimento di questo articolo.

Non è necessario fare nulla per ottenere questa funzionalità per il sito; è necessario concedere il nuovo tipo di sessione (denominato anche Privilegio riunione) agli utenti. È possibile effettuare questa operazione singolarmente attraverso la pagina di configurazione dell'utente o in massa con un'esportazione/importazione CSV.

Verificare il nuovo tipo di sessione
1

Accedi a Control Hub e vai a Servizi > Riunione.

2

Fai clic su Siti , scegli il sito Webex per il quale desideri modificare le impostazioni, quindi fai clic su Impostazioni.

3

In Impostazioni comuni, selezionare Tipi di sessione.

4
È necessario visualizzare uno o più tipi di sessione con 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-End. Questa tipo di sessione include l'accesso degli utenti PSTN alle riunioni non crittografato. Accertarsi di disporre della versione _solo VOIP per garantire la crittografia end-to-end. È possibile controllare passando il mouse sul collegamento PRO nella colonna del codice sessione. In questo esempio, il target del collegamento deve essere javascript:ShowFeature(652).

I nomi dei servizi pubblici per questi tipi di sessione potrebbero essere modificati in futuro.

5

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

Operazione successivi

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

Abilita riunioni E2EE per singoli utenti
1

Accedi a Control Hub e vai a Gestione > Utenti.

2

Selezionare un account utente da aggiornare, quindi selezionare Riunioni.

3

Dall'elenco a discesa Impostazioni , selezionare il sito della riunione da aggiornare.

4

Selezionare la casella accanto a Pro-End to End Encryption_VOIPonly.

5

Chiudere il pannello di configurazione dell'utente.

6

Se necessario, ripetere questa operazione per gli altri utenti.

Per assegnare questa opzione a molti utenti, utilizzare l'opzione successiva, Abilita riunioni E2EE per più utenti.

Abilita riunioni E2EE per più utenti
1

Accedi a Control Hub e vai a Servizi > Riunione.

2

Fare clic su Siti, scegliere il sito Webex per il quale si desidera modificare le impostazioni.

3

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

4

Fare clic su Genera report e attendere durante la preparazione del file.

5

Quando il file è pronto, fare clic su Esporta risultati, quindi scaricare . Dopo aver fatto clic su Download chiudere manualmente la finestra popup.

6

Aprire il file CSV scaricato per la modifica.

Per ogni utente è presente una riga e la colonna MeetingPrivilege contiene gli ID del tipo di sessione come elenco delimitato da virgole.

7

Per ciascun utente che si desidera concedere il nuovo tipo di sessione, aggiungere 1561 come nuovo valore nell'elenco delimitato da virgole nella cella MeetingPrivilege .

Il riferimento al formato di file CSV Webex contiene dettagli sull'obiettivo 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.

Aggiungi livello raggiungibile audio per sicurezza

È possibile aggiungere una filigrana alle registrazioni delle riunioni con il tipo di sessione Webex Meetings Pro-End to End Encryption_VOIPonly , che consente di identificare il client o il dispositivo di origine delle registrazioni non autorizzate delle riunioni riservate.

Quando questa funzione è abilitata, l'audio della riunione include un identificativo univoco per ciascun client o dispositivo partecipante. È possibile caricare registrazioni audio in Control Hub, che quindi analizza la registrazione e cerca gli identificatori univoci. È possibile esaminare i risultati per vedere quale client di origine o dispositivo ha registrato la riunione.

  • Per essere analizzata, la registrazione deve essere un file AAC, MP3, M4A, WAV, MP4, AVI o MOV non più grande di 500 MB.
  • La registrazione deve essere più lunga di 100 secondi.
  • Puoi analizzare solo le registrazioni per le riunioni organizzate da persone nella tua organizzazione.
  • Le informazioni filigrane vengono conservate per la stessa durata delle informazioni della riunione dell'organizzazione.

Aggiungi livelli raggiungibili audio alle riunioni E2EE

  1. Accedi a Control Hub, quindi in Gestione, seleziona Impostazioni organizzazione.
  2. Nella sezione Filigrane riunione , attiva Aggiungi filigrana audio.

    Qualche tempo dopo l'attivazione, gli utenti che pianificano riunioni con il tipo di sessione Webex Meetings Pro-End to End Encryption_VOIPonly visualizzano un'opzione Digital Watermarking nella sezione Sicurezza.

Carica e analizza una riunione contrassegnata da acqua

  1. In Control Hub, in Monitoraggio, seleziona Risoluzione dei problemi.
  2. Fare clic su Analisi livello raggiungibile.
  3. Cercare o selezionare la riunione nell'elenco, quindi fare clic su Analizza.
  4. Nella finestra Analizza livello raggiungibile audio , immettere un nome per l'analisi.
  5. (Opzionale) Inserire una nota per l'analisi.
  6. Trascina la selezione del file audio da analizzare o fai clic su Scegli file per passare al file audio.
  7. Fare clic su Chiudere.

    Una volta completata, l'analisi sarà visualizzata nell'elenco dei risultati nella pagina Analizza livello raggiungibile .

  8. Selezionare la riunione nell'elenco per visualizzare i risultati dell'analisi. Fare clic su Pulsante Scarica per scaricare i risultati.

Funzioni e limitazioni

I fattori coinvolti nella decodifica di un livello raggiungibile registrato includono la distanza tra il dispositivo di registrazione e l'altoparlante che distribuisce l'audio, il volume dell'audio, il rumore ambientale, ecc. La nostra tecnologia di filigrana ha una resilienza aggiuntiva ad essere codificato più volte, come potrebbe accadere quando i media vengono condivisi.

Questa funzione è progettata per consentire la decodifica riuscita dell'identificatore del livello raggiungibile in un insieme ampio ma ragionevole di circostanze. Il nostro obiettivo è che un dispositivo di registrazione, come un telefono cellulare, che si trova su una scrivania vicino a un endpoint personale o un client portatile, crei sempre una registrazione che risulti in un'analisi di successo. Poiché il dispositivo di registrazione viene allontanato dalla sorgente o viene oscurato dall'ascolto dell'intero spettro audio, le possibilità di un'analisi di successo sono ridotte.

Per analizzare correttamente una registrazione, è necessaria un'acquisizione ragionevole dell'audio della riunione. Se l'audio di una riunione viene registrato sullo stesso computer che ospita il client, le limitazioni non devono essere applicate.

Dispositivi di bordo (CA interna)

Se i tuoi dispositivi sono già caricati nella tua organizzazione Control Hub e desideri utilizzare la CA Webex per generare automaticamente i certificati di identificazione, non devi ripristinare le impostazioni di fabbrica 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 indica a Webex quale dominio identifica il dispositivo, se ne sceglie automaticamente uno e questo potrebbe apparire errato per gli altri partecipanti alla riunione.

Operazioni preliminari

Se i dispositivi non sono ancora caricati, seguire Registra un dispositivo su Cisco Webex utilizzando l'API o l'interfaccia Web locale o l'onboarding cloud per Board, Desk e serie Room. È inoltre necessario verificare i domini da utilizzare per identificare i dispositivi in Gestisci domini.

1

Accedi a Control Hub e in Gestione seleziona 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.

Dispositivi di bordo (CA esterna)

Operazioni preliminari

  • Ottieni un certificato firmato da CA e una chiave privata, nel formato .pem , per ogni dispositivo.

  • Nella scheda Prepara , leggi l'argomento Comprensione del processo di identità esterna per i dispositivi,

  • Preparare uno strumento di crittografia JWE in relazione alle informazioni in esso contenute.

  • Assicurarsi di avere uno strumento per generare sequenze byte casuali di determinate lunghezze.

  • Accertarsi di disporre di uno strumento per la base di byte o testo di codifica di64url.

  • Assicurati di disporre di un'implementazione scrypt .

  • Assicurati di avere una parola o una frase segreta per ciascun dispositivo.

1

Popolare ClientSecret del dispositivo con un semplice testo segreto:

La prima volta che popolate il Segreto, lo fornite in testo normale. Ecco perché consigliamo di farlo nella console del dispositivo fisico.

  1. Base64url codifica la frase segreto per questo dispositivo.

  2. Aprire TShell sul dispositivo.

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

    Il comando di esempio precedente popola il segreto con la frase 0123456789abcdef. È necessario scegliere il proprio.

Il dispositivo ha il segreto iniziale. Non dimenticare questo; non puoi recuperarlo e devi ripristinare le impostazioni di fabbrica del dispositivo per riavviarlo.
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 payload che crittograferai e inserirai nel tuo blob 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, impostando le chiavi alg, enc e cisco-kdf come descritto in Comprensione del processo di identità esterna per i dispositivi. Impostare l'azione "aggiungi" utilizzando la chiave:valore "cisco-action":"add" nell'intestazione JOSE (perché stiamo 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 stato aggiunto eseguendo xcommand Security Certificates Services Show

Copiare le impronte digitali del nuovo certificato.

6

Attivare il certificato allo scopo WebexIdentity:

  1. Leggere l'impronta digitale del certificato, dal certificato stesso o 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, impostando le chiavi alg, enc e cisco-kdf come descritto in Comprensione del processo di identità esterna per i dispositivi. Impostare l'azione "activate" utilizzando la chiave:valore "cisco-action":"activate" nell'intestazione JOSE (perché stiamo attivando 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: Impronta digitale WebexIdentity: "La tua..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.

Esegui test di crittografia end-to-end con verifica identità
1

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

Vedere Pianificazione di App Webex Meetings con crittografia end-to-end.

2

Accedere alla riunione come organizzatore da un Webex Meetings partecipanti.

Vedere Accesso a App Webex Meetings con crittografia end-to-end.

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.

Vedere Accesso a App Webex Meetings con crittografia end-to-end.

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. Ulteriori informazioni sulle icone delle identità.

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

Se possibile, convalida le identità dei partecipanti/dispositivi 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.

Impostazione dell'ambito e delle aspettative

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

  • Se disponi di diversi livelli di verifica dell'identità, consenti agli utenti di verificarsi a vicenda con l'identità supportata dal certificato. 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.

Gestione identità

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.

ID tipi di sessione
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 utente

652

Pro-End fino alla fine EVOIPonlyncryption_

660

Fine gratuita Pro 3 a fine EVOIPonlyncryption_

Crittografia E2E + Identità

672

Pro 3 gratuito 50-fine EVOIPonlyncryption_

673

Istruttore istruzione E2E EVOIPonlyncryption_

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

Comandi xAPI correlati

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 Accesso all'API per la Webex Room e i dispositivi della scrivania e Webex Boards.

Questi comandi xAPI sono disponibili solo sui dispositivi che sono:

  • Registrato per Webex

  • Registrato in locale e collegato a Webex con Webex Edge per dispositivi

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

chiamata API

Descrizione

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.

Disponibilità crittografia endToEnd conferenza xStatus

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.

Verifica identitàEsternaCrittografia EndToEndConferenza xStatus

Indica se il dispositivo utilizza la verifica esterna (con certificato rilasciato esternamente).

xStatus conferenza EndToEndEncryption ExternalIdentity Identity

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

xStato conferenza EndToEndEncryption ExternalIdentity CertificateChain Certificate # info specifiche

Legge informazioni specifiche da un certificato emesso esternamente.

Nel comando mostrato, sostituire # con il numero del certificato. Sostituire le informazioni specifiche con una delle seguenti opzioni:

  • Impronte digitali

  • Non dopo la data di fine validità

  • Non prima della data di inizio validità

  • NomePrincipale

  • Algoritmo chiavi pubbliche

  • Numero di serie

  • AlgoritmoFirma

  • Oggetto # Nome Un elenco dei soggetti per il certificato (ad esempio indirizzo e-mail o nome del dominio)

  • Validità Fornisce lo stato di validità di questo certificato (ad es. valido o scaduto)

xStatus conferenza EndToEndEncryption ExternalIdentity Status

Lo stato dell'identità esterna del dispositivo (ad esempio, valido o errato).

xStato conferenza EndToEndCrittografia InternalIdentity Verification

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

xStatus Conferenza EndToEndCrittografia 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 si trova in un'organizzazione con più domini, questo è il valore di PreferredDomain.

xStato conferenza EndToEndEncryption InternalIdentity CertificateChain Certificate # info specifiche

Legge informazioni specifiche del certificato emesso da Webex.

Nel comando mostrato, sostituire # con il numero del certificato. Sostituire le informazioni specifiche con una delle seguenti opzioni:

  • Impronte digitali

  • Non dopo la data di fine validità

  • Non prima della data di inizio validità

  • NomePrincipale

  • Algoritmo chiavi pubbliche

  • Numero di serie

  • AlgoritmoFirma

  • Oggetto # Nome Un elenco dei soggetti per il certificato (ad esempio indirizzo e-mail o nome del dominio)

  • Validità Fornisce lo stato di validità di questo certificato (ad es. valido o scaduto)

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

chiamata API

Descrizione

xEvento conferenza partecipanteElenco partecipantiAggiunto

xEvent Conference ParticipantList ParticipantAggiornata

xEvent Conference ParticipantList ParticipantDeleted

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 Popolate Secret: "base64url-codificato"

o

xCommand Security ClientSecret Popolate 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 Aggiungi JWEblob

Aggiunge un certificato (con chiave privata).

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

I servizi dei certificati di sicurezza xCommand attivano lo scopo:WebexIdentity FingerPrint: JWEblob

Attiva un certificato specifico per WebexIdentity. Per questo Scopo, il comando richiede che l'impronta digitale identificativa sia crittografata e serializzata in un blob JWE.

I servizi dei certificati di sicurezza xCommand disattivano lo scopo:WebexIdentity FingerPrint: JWEblob

Disattiva un certificato specifico per WebexIdentity. Per questo Scopo, il comando richiede che l'impronta digitale identificativa sia crittografata e serializzata in un blob JWE.