Gli utenti scelgono il tipo di riunione quando la pianifica una riunione. Quando si ammettono partecipanti dall'area di ingresso virtuale, nonché durante la riunione, l'organizzatore può visualizzare lo stato di verifica dell'identità di ciascun partecipante. Esiste anche un codice riunione comune a tutti i partecipanti correnti nella riunione, che possono utilizzare per verificarsi reciprocamente.

Condividere le seguenti informazioni con gli organizzatori della riunione:

Verificare l'identità

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

Quando i partecipanti o i dispositivi accedono a un gruppo condiviso MLS (messaggistica Layer Security), presentano i relativi certificati agli altri membri del gruppo, che quindi convalidano i certificati contro le autorità di certificazione (CA) di emissione. 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 dell'app Webex si autenticano contro l'archivio identità Webex , che rilascia loro un token di accesso quando l'autenticazione ha esito positivo. Se devono disporre di un certificato per verificare la propria identità in una riunione con crittografia end-to-end, l'Autorità di certificazione Webex rilascia loro un certificato in base al token di accesso. Al momento, non forniamo agli utenti Webex Meetings un modo per ottenere un certificato emesso da una CA di terze parti/esterna.

I dispositivi possono autenticarsi utilizzando un certificato emesso dall'Autorità di certificazione interna (Webex) o un certificato emesso da un'Autorità di certificazione esterna:

  • CA interna: Webex emette un certificato interno in base al token di accesso dell'account macchina del dispositivo. Il certificato è firmato dall'Autorità di certificazione Webex . I dispositivi non dispongono di ID utente allo stesso modo degli utenti, pertanto Webex utilizza (uno dei) domini della propria organizzazione quando scrive l'identità del certificato del dispositivo (nome comune (CN)).

  • CA esterna: richiedere e acquistare i certificati dei dispositivi direttamente dall'autorità emittente scelta. Devi crittografare, caricare direttamente e autorizzare i certificati utilizzando un segreto noto solo a te.

    Cisco non è coinvolta, il che consente di garantire la crittografia end-to-end e l'identità verificata, ed evitare la possibilità teorica che Cisco possa intercettare la riunione o decrittografare i file multimediali.

Certificato dispositivo emesso internamente

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

Se l'organizzazione non dispone di un dominio, l'Autorità di certificazione Webex emette il certificato senza un dominio.

Se l'organizzazione dispone di più domini, è possibile utilizzare Control Hub per indicare a Webex quale dominio il dispositivo utilizza per la propria identità. È inoltre 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 ne sceglie uno.

Certificato dispositivo emesso esternamente

Un amministratore può eseguire il provisioning di un dispositivo con il proprio certificato firmato con una delle CA pubbliche.

Il certificato deve essere basato su una coppia di chiavi ECDSA P-256, sebbene possa essere firmato con 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 interfaccia utente della riunione Webex , come descritto in Crittografia end-to-end con verifica dell'identità per Webex Meetings .

Ti consigliamo 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 che possiede il dominio "example.com".

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

Quando si utilizza il segreto client, è possibile gestire in modo sicuro il certificato di identità Webex esterno tramite la xAPI. Attualmente, questa funzionalità è limitata ai dispositivi online.

Webex attualmente fornisce comandi API per questa gestione.

Dispositivi

I dispositivi della serie Webex Room e Webex Desk registrati su cloud seguenti possono partecipare a riunioni con crittografia end-to-end:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

I dispositivi seguenti non possono partecipare a riunioni con crittografia end-to-end:

  • Webex serie C

  • Serie Webex DX

  • Webex serie EX

  • Serie Webex MX

  • Dispositivi SIP di terze parti

Client software
  • A partire dalla versione 41.6, il client desktop Webex Meetings può partecipare a riunioni con crittografia end-to-end.

  • Se l'organizzazione consente Webex App di accedere alle riunioni avviando l'applicazione desktop Meetings, è possibile utilizzare questa opzione per partecipare alle riunioni con crittografia end-to-end.

  • Il client Web 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à
  • In base alla progettazione, non forniamo opzioni di Control Hub per la gestione dell'identità dei dispositivi verificati esternamente. Per una vera crittografia end-to-end, solo tu devi conoscere/accedere ai segreti e alle chiavi. Se viene introdotto un servizio cloud per gestire tali chiavi, è possibile che vengano intercettate.

  • Attualmente, forniamo una "ricetta" per la progettazione di strumenti personalizzati, in base a tecniche di crittografia standard del settore, per richiedere o crittografare i certificati di identità del dispositivo e le relative chiavi private. Non vogliamo avere alcun accesso reale o percepito ai tuoi segreti o chiavi.

Riunioni
  • Attualmente, le riunioni con crittografia end-to-end supportano un massimo di 200 partecipanti.

  • Di questi 200 partecipanti, possono accedere un massimo di 25 dispositivi verificati esternamente e loro devono essere i primi partecipanti a partecipare alla riunione .

    Quando un numero maggiore di dispositivi accede a una riunione, i nostri servizi multimediali back-end tentano di transcodificare i flussi multimediali. Se non è possibile decrittografare, transcodificare e crittografare nuovamente il supporto (perché non abbiamo e non dovremmo disporre delle chiavi di crittografia dei dispositivi), la transcodifica non viene completata.

    Per ridurre questo limite, si consiglia di organizzare riunioni di dimensioni ridotte per i dispositivi o scaglionare gli inviti tra dispositivi e client Meetings.

Interfaccia di gestione

È consigliabile utilizzare Control Hub per gestire il sito per riunioni, poiché le organizzazioni di Control Hub dispongono di identità centralizzata per l'intera organizzazione, mentre in Amministrazione sito, l'identità è controllata sito per sito.

Gli utenti gestiti da Amministrazione sito non possono disporre dell'opzione di identità verificata Cisco. A tali utenti viene rilasciato un certificato anonimo per partecipare a una riunione con crittografia end-to-end e possono essere esclusi dalle riunioni in cui l'organizzatore desidera garantire la verifica dell'identità.

Informazioni correlate
  • Webex Meetings 41.7.

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

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

  • Uno o più domini verificati nell'organizzazione Control Hub (se si utilizza l'Autorità di certificazione Webex per emettere certificati di dispositivo per l'identità verificata).

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

È possibile saltare questo passaggio se non sono necessarie identità verificate 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 autorità di certificazione (CA) pubblica attendibile.

È necessario interagire con l'Autorità di certificazione 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 sta compromettendo la sicurezza.

  • Nome comune (CN) e Nome/i soggetto/i alternativo/i (SAN/s): Questi non sono importanti per Webex, ma devono essere valori che le persone possono leggere e associare al dispositivo. Il CN verrà visualizzato agli altri partecipanti alla riunione come identità verificata principale del dispositivo e, se gli utenti controllano il certificato attraverso l'interfaccia utente della riunione, visualizzeranno le SAN. Puoi utilizzare nomi come name.model@example.com.

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

  • Scopo: Lo scopo del certificato deve essere Webex Identity.

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

    Questo requisito non si estende alla chiave di firma. L'Autorità di certificazione può utilizzare una chiave RSA per firmare il certificato.

È possibile saltare questo passaggio se non si desidera utilizzare l'identità verificata esternamente con i dispositivi.

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

Se si dispone di dispositivi esistenti che si desidera aggiornare per utilizzare l'identità verificata esternamente, è necessario 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 graduale. Notificare agli utenti le modifiche previste.

  • Garantire l'accesso fisico ai dispositivi. Se devi accedere ai dispositivi attraverso la rete, tieni presente che i segreti viaggiano in testo normale e tu stai compromettendo la tua sicurezza.

Una volta completati questi passaggi, consentire ai sistemi video di accedere a riunioni ed eventi sul sito Webex .

Per garantire che i file multimediali del dispositivo non possano essere crittografati da alcuno tranne 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 tramite JSON Web Encryption (JWE).

Per garantire una crittografia end-to-end effettiva attraverso il nostro cloud, non possiamo essere coinvolti nella crittografia e nel caricamento del certificato e della chiave. Se occorre questo livello di sicurezza, è necessario:

  1. Richiedi i certificati.

  2. Generare le coppie di chiavi dei certificati.

  3. Crea (e proteggi) un segreto iniziale per ciascun dispositivo, per eseguire il seeding della funzionalità di crittografia del dispositivo.

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

    Di seguito vengono spiegati il processo e i parametri (non segreti) necessari, nonché una ricetta da seguire negli strumenti di sviluppo preferiti. Forniamo anche alcuni dati di test e i BLOB JWE risultanti come previsto, per aiutarti a verificare il processo.

    Un'implementazione di riferimento non supportata che utilizza Python3 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 BLOB 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) lo strumento per consentire agli utenti del dispositivo di modificare il segreto iniziale e proteggere i propri file multimediali.

Come viene utilizzato il formato JWE

Questa sezione descrive come ci si aspetta che il JWE venga creato come input per i dispositivi, in modo che sia possibile creare il proprio strumento per creare i BLOB dai certificati e dalle chiavi.

Fare riferimento a Crittografia Web JSON (JWE)https://datatracker.ietf.org/doc/html/rfc7516e Firma Web JSON (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Usiamo il Serializzazione compatta di un documento JSON per creare BLOB JWE. I parametri che è necessario includere durante la creazione dei BLOB JWE sono:

  • Intestazione JOSE (protetto). Nell'intestazione Crittografia e firma oggetto JSON, è NECESSARIO includere le seguenti coppie chiave-valore:

    • "alg":"dir"

      L'algoritmo diretto è l'unico supportato per la crittografia del payload ed è necessario utilizzare il segreto 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"

      Questa è una chiave proprietaria e può contenere quattro valori. Questa chiave è stata introdotta per segnalare lo scopo dei dati crittografati al dispositivo di destinazione. I valori prendono il nome dai comandi xAPI sul dispositivo in cui si stanno utilizzando i dati crittografati.

      Gli abbiamo dato un nome cisco-action per ridurre potenziali conflitti con futuri interni JWE.

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

      Un'altra chiave proprietaria. I valori specificati verranno utilizzati come input per la derivazione della chiave sul dispositivo. Il version deve essere 1(la versione della funzione di derivazione chiave). Il valore di salt deve essere una sequenza codificata URL base64 di almeno 4 byte, che l'utente deve scegliere in modo casuale.

  • Chiave crittografata JWE . Questo campo è vuoto. Il dispositivo la deriva dall'iniziale ClientSecret.

  • Vettore di inizializzazione JWE . È necessario fornire un vettore di inizializzazione codificato base64url per decrittografare il payload. Il IV DEVE essere un valore casuale di 12 byte (si sta utilizzando la famiglia di crittografia AES-GCM, che richiede che l'IV sia lungo 12 byte).

  • JWE AAD (ulteriori dati autenticati). È necessario omettere questo campo poiché non è supportato nella serializzazione compatta.

  • Testo cifrato JWE : Questo è il payload crittografato che si desidera mantenere segreto.

    Il carico utile può essere vuoto. Ad esempio, per reimpostare il segreto del client, è necessario sovrascriverlo con un valore vuoto.

    Esistono diversi tipi di payload, a seconda di quello che si sta tentando di fare sul dispositivo. Comandi xAPI diversi prevedono payload diversi; pertanto, è necessario specificare lo scopo del payload con il comando cisco-action chiave, come segue:

    • Con "cisco-action":"populate" il testo crittografato è il nuovo ClientSecret.

    • Con " "cisco-action":"add" il testo crittografato è un BLOB PEM contenente il certificato e la relativa chiave privata (concatenata).

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

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

  • Tag di autenticazione JWE: Questo campo contiene il tag di autenticazione per verificare l'integrità dell'intero BLOB serializzato in modo compatto JWE

Come si ricava la chiave di crittografia da ClientSecret

Dopo il primo popolamento del segreto, non viene accettato o restituito il segreto come testo normale. Questo per evitare potenziali attacchi al dizionario da parte di qualcuno che potrebbe accedere al dispositivo.

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

Ciò significa che lo strumento per la produzione di BLOB JWE deve seguire la stessa procedura per derivare la stessa chiave di crittografia/decrittografia dal segreto client.

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

  • FattoreCosto (N) è 32768

  • BlockSizeFactor (r) è 8

  • Fattore di parallelizzazione (p) è 1

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

  • Le lunghezze dei tasti sono 16 byte (se si seleziona l'algoritmo AES-GCM 128) o 32 byte (se si seleziona l'algoritmo AES-GCM 256)

  • Il limite di memoria massimo è 64 MB

Questo set di parametri è l'unica configurazione di scrypt che sia compatibile con la funzione di derivazione chiave sui dispositivi. Questo kdf sui dispositivi viene chiamato "version":"1", che è l'unica versione attualmente utilizzata dal cisco-kdf.

Esempio funzionante

Questo è 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 prevede l'aggiunta di un BLOB PEM al dispositivo (imita l'aggiunta di un certificato, con una stringa molto breve anziché una chiave cert+ completa). Il segreto del client nell'esempio è ossifrage.

  1. Scegliere un codice di crittografia. Questo esempio utilizza A128GCM(AES con tasti a 128 bit in modalità contatore Galois). Lo strumento potrebbe utilizzare A256GCM se si preferisce.

  2. Scegliere un salt (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 da ottenere 5eZTCAP4M_Y(rimuovere il rivestimento Base64).

  3. Questo è un esempio scrypt chiamata 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 (esadecimale), eseguendo queste operazioni: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac che codifica base64url lZ66bdEiAQV4_mqdInj_rA.

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

  5. Creare l'intestazione JOSE con serializzazione compatta (seguendo lo stesso ordine di parametri utilizzati qui) e quindi codificarla 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 BLOB JWE.

  6. Il secondo elemento del BLOB JWE è vuoto poiché non viene fornita 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 payload e un tag crittografati. Per questo esempio, il payload non crittografato sarà il BLOB PEM falso this is a PEM file

    I parametri di crittografia da utilizzare sono:

    • Il carico utile è this is a PEM file

    • La crittografia è AES 128 GCM

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

    Base64url codifica il payload crittografato, che dovrebbe avere come risultato f5lLVuWNfKfmzYCo1YJfODhQ

    Questo è il quarto elemento (JWE Ciphertext) nel BLOB JWE.

  9. Base64url codifica il tag prodotto nel passaggio 8, che dovrebbe avere come risultato PE-wDFWGXFFBeo928cfZ1Q

    Questo è il quinto elemento nel BLOB JWE.

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Se hai derivato gli stessi valori codificati base64url indicati di seguito, utilizzando strumenti personali, sei pronto a utilizzarli per proteggere la crittografia E2E e l'identità verificata dei dispositivi.

  12. Questo esempio in realtà non funziona, ma in linea di principio il passo successivo sarebbe utilizzare il blob JWE creato in precedenza come input per il comando x sul dispositivo che aggiunge il certificato:

    xCommand Security Certificates Add 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 è chiamato 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 nel Riferimento sezione 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. Puoi eseguire questa operazione singolarmente nella pagina di configurazione dell'utente o in blocco con un'importazione/esportazione CSV .

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

Sotto Impostazioni comuni , selezionare Tipi di sessione .

4
Dovrebbero essere visualizzati uno o più tipi di sessione di crittografia end-to-end. Fare riferimento all'elenco di ID tipo di sessione nel Riferimento sezione di questo articolo. Ad esempio, potrebbe essere visualizzato Pro-End to End Encryption_ Solo VoIP .

 

Esiste un tipo di sessione precedente con un nome molto simile: Crittografia end-to-end . Questo tipo di sessione include l' accesso PSTN non crittografato alle riunioni. Accertarsi di disporre del_ Solo VoIP per garantire la crittografia end-to-end. È possibile controllare passando il mouse su PRO collegamento nella colonna del codice sessione; per questo esempio, la destinazione del collegamento deve essere javascript:ShowFeature(652).

In futuro, potremmo modificare i nomi del servizio pubblico per questi tipi di sessione.

5

Se non si dispone ancora del nuovo tipo di sessione , contattare il rappresentante Webex .

Operazioni successive

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

1

Accedere a Control Hub , e andare 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_ Solo VoIP .

5

Chiudere il pannello configurazione utente .

6

Ripetere per altri utenti, se necessario.

Per assegnare questa opzione a molti utenti, utilizzare l'opzione successiva, Abilita le 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 Risultati esportazione e poi Scarica . (È necessario chiudere manualmente la finestra popup dopo aver fatto clic su Scarica .)

6

Aprire il file file CSV scaricato per la modifica.

È presente una riga per ciascun utente e il file MeetingPrivilege contiene gli ID tipo di sessione come elenco delimitato da virgole.

7

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

Il Riferimento al formato file CSV Webex contiene dettagli sullo scopo e sul contenuto del file CSV.

8

Aprire il pannello Configurazione sito di riunione in Control Hub.


 

Se ci si trova già nella pagina Elenco siti per riunioni, potrebbe essere necessario aggiornarla.

9

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

10

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

11

Al termine dell'importazione, fare clic Importazione risultati per controllare se sono presenti errori.

12

Andare a Utenti e aprire uno degli utenti per verificare che disponga del nuovo tipo di sessione.

È possibile aggiungere una filigrana alle registrazioni delle riunioni con il Webex Meetings Pro-End to End Encryption_VOIPonly tipo di sessione, che consente di identificare il client o il dispositivo di origine delle registrazioni non autorizzate di 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 poter 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.
  • È possibile analizzare solo le registrazioni delle riunioni organizzate da persone della propria organizzazione.
  • Le informazioni filigrane vengono conservate per la stessa durata delle informazioni della riunione dell'organizzazione.
Aggiungere filigrane audio alle riunioni E2EE
  1. Accedi a Control Hub, quindi sotto Gestione, seleziona Impostazioni organizzazione.
  2. Nel Filigrane riunione sezione, attivare Aggiungere la filigrana audio .

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

Caricare e analizzare una riunione con filigrana
  1. In Control Hub, sotto Monitoraggio , selezionare Risoluzione dei problemi .
  2. Fare clic su Analisi filigrana .
  3. Cercare o selezionare la riunione nell'elenco, quindi fare clic su Analizza.
  4. Nel Analizza la filigrana audio , immettere un nome per l'analisi.
  5. (Opzionale) Inserire una nota per l'analisi.
  6. Trascinare e rilasciare il file audio da analizzare o fare clic Scegli file per individuare il file audio.
  7. Fare clic su Chiudere.

    Al termine dell'analisi, verrà visualizzata nell'elenco dei risultati nella pagina Analizza filigrana pagina.

  8. Selezionare la riunione nell'elenco per visualizzare i risultati dell'analisi. Fare clic suPulsante 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 di tale audio, il rumore ambientale, ecc. La nostra tecnologia di marcatura raggiungibile offre una resilienza aggiuntiva per essere codificata più volte, come potrebbe accadere quando il contenuto multimediale viene condiviso.

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.

Se i dispositivi sono già presenti nell'organizzazione Control Hub e si desidera utilizzare il CA Webex per generare automaticamente i relativi certificati di identificazione, non è necessario ripristino impostazioni di fabbrica .

Questa procedura consente di selezionare il dominio utilizzato dal dispositivo per identificarsi ed è obbligatoria solo se si dispone di più domini nell'organizzazione di Control Hub. Se si dispone di più domini, è consigliabile eseguire questa operazione per tutti i dispositivi con identità "Cisco-verified". Se non si indica a Webex quale dominio identifica il dispositivo, ne viene scelto automaticamente uno e potrebbe sembrare sbagliato agli altri partecipanti alla riunione.

Operazioni preliminari

Se i dispositivi non sono ancora presenti, seguire Registrazione di un dispositivo su Cisco Webex mediante l' API o l'interfaccia Web locale o Introduzione al cloud per le serie Board, Desk e Room . Verificare anche il/i dominio/i che si desidera utilizzare per identificare i dispositivi in Gestisci i tuoi domini .

1

Accedere a Control Hub , e sotto Gestione , selezionare 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 altri dispositivi.

Operazioni preliminari

È necessario:

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

  • Per leggere l'argomento Informazioni su Processo di identità esterna per dispositivi , nel Preparati parte di questo articolo.

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

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

  • Uno strumento per la codifica base64url di byte o testo.

  • An scrypt implementazione.

  • Una parola o una frase segreta per ciascun dispositivo.

1

Popola i dispositivi ClientSecret con un segreto in testo normale:

La prima volta che si compila il file Secret, viene fornita in testo normale. Per questo motivo si consiglia di eseguire questa operazione sulla console del dispositivo fisico.

  1. Base64url codifica la frase segreta per questo dispositivo.

  2. Aprire TShell sul dispositivo.

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

    Il comando di esempio precedente inserisce i valori nel file Secret con la frase 0123456789abcdef. Devi scegliere la tua.

Il dispositivo ha il suo segreto iniziale. Non dimenticarlo; non è possibile ripristinarlo ed è necessario reimpostare il dispositivo per riavviarlo.
2

Concatenare il certificato e la chiave privata:

  1. Utilizzando un editor di testo, aprire i file .pem, incollare il blob chiave, il BLOB del certificato, e salvarlo come nuovo file .pem.

    (Questo è il testo del payload che verrà crittografato e inserito nel BLOB JWE)

3

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

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

  2. Ricavare una chiave di crittografia del contenuto con lo strumento scrypt.

    A tale scopo sono necessari il segreto, il salt e una lunghezza della chiave corrispondente alla crittografia di crittografia scelta. Esistono altri valori fissi da fornire (N=32768, r=8, p=1). Il dispositivo utilizza lo stesso processo e gli stessi valori per derivare la stessa chiave di crittografia del contenuto.

  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 tasti come descritto in Informazioni su Processo di identità esterna per 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 payload PEM crittografato e il tag di autenticazione.

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

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

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 l'impronta digitale 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 tuo sale.

  3. Ricavare una chiave di crittografia del contenuto con lo strumento scrypt.

    A tale scopo sono necessari il segreto, il salt e una lunghezza della chiave corrispondente alla crittografia di crittografia scelta. Esistono altri valori fissi da fornire (N=32768, r=8, p=1). Il dispositivo utilizza lo stesso processo e gli stessi valori per derivare la stessa chiave di crittografia del contenuto.

  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 tasti come descritto in Informazioni su Processo di identità esterna per dispositivi . Impostare l'azione "attiva" 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 l'impronta digitale del certificato.

    Lo strumento deve restituire una sequenza di 16 o 32 byte, a seconda che sia stato scelto 128 o 256 bit AES-GCM, e un tag di autenticazione.

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

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

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

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

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

Eseguire l'onboarding del dispositivo all'organizzazione di Control Hub.

1

Pianificare una riunione del tipo corretto ( Webex Meetings Pro-End to End Encryption_ Solo VoIP ).

2

Accedere alla riunione come organizzatore da un client Webex Meetings .

3

Accedere alla riunione da un dispositivo la cui identità è verificata dall'Autorità di Webex .

4

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

5

Accedere alla riunione da un dispositivo la cui identità è verificata da un'Autorità di certificazione esterna.

6

In qualità di organizzatore, verificare che questo dispositivo venga visualizzato nell'area di ingresso virtuale con l'icona dell'identità corretta. Ulteriori informazioni sulle icone di identità .

7

Accedere alla riunione come partecipante non autenticato.

8

In qualità di organizzatore, verificare che questo partecipante venga visualizzato nell'area di ingresso virtuale con l'icona dell'identità corretta.

9

In qualità di organizzatore, ammette o rifiuta persone/dispositivi.

10

Convalida delle identità dei partecipanti/dispositivo, se possibile, controllando i certificati.

11

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

12

Accedere alla riunione con un nuovo partecipante.

13

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

Rendere le riunioni con crittografia end-to-end l'opzione di riunione predefinita, abilitarla solo per alcuni utenti o consentire a tutti gli organizzatori di decidere? Una volta deciso come utilizzare questa funzione, preparare gli utenti che la utilizzeranno, in particolare rispetto alle limitazioni e a cosa aspettarsi nella riunione.

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

Per gli utenti che accedono con dispositivi sicuri, consentire ai dispositivi di accedere per primi e impostare l'aspettativa per l'utente che potrebbe non essere in grado di accedere se accede in ritardo.

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

Se si utilizza una CA esterna per emettere i certificati del dispositivo, spetta a voi monitorare, aggiornare e riapplicare i certificati.

Se hai creato il segreto iniziale, tieni presente che gli utenti potrebbero voler modificare il segreto del proprio dispositivo. Potrebbe essere necessario creare un'interfaccia/distribuire uno strumento per consentire agli utenti di eseguire questa operazione.

Tabella 1. ID tipo di sessione per riunioni con crittografia end-to-end

ID tipo di sessione

Nome servizio pubblico

638

Solo crittografia E2E+ VoIP

652

Pro-End to End Encryption_ Solo VoIP

660

Pro 3 free-end to end Encryption_ Solo VoIP

Crittografia E2E + identità

672

Pro 3 Free50-End to End Encryption_ Solo VoIP

673

Istruttore di formazione E2E Encryption_ Solo VoIP

676

BroadWorks Standard più crittografia end-to-end

677

BroadWorks Premium più crittografia end-to-end

681

Scuola gratuita più crittografia end-to-end

Queste tabelle descrivono i comandi API dei dispositivi Webex aggiunti per le riunioni con crittografia end-to-end e l'identità verificata. Per ulteriori informazioni su come utilizzare l' API, vedere Accedere API per i dispositivi Webex Room e Desk e le Webex Board .

Questi comandi xAPI sono disponibili solo su dispositivi che sono:

  • Iscritto a Webex

  • Registrato in sede 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ù di un dominio.

Il dispositivo utilizza questo dominio quando richiede un certificato dall'Autorità di certificazione Webex . Il dominio identifica quindi il dispositivo.

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

xStatus Conference EndToEndEncryption Availability

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

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Indica se il dispositivo utilizza External verifica (con un certificato emesso esternamente).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

L'identità del dispositivo letto dal nome comune del certificato emesso esternamente.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

Legge informazioni specifiche da un certificato emesso esternamente.

Nel comando visualizzato, sostituire # con il numero del certificato. Replace specificinfo con uno di:

  • Fingerprint

  • NotAfter Data di data di fine validità

  • NotBefore Data di data di inizio validità

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Un elenco degli oggetti del certificato (es. indirizzo e-mail o nome dominio)

  • Validity Fornisce lo stato di validità di questo certificato (es valid o expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

Lo stato dell'identità esterna del dispositivo (es valid o error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

Indica se il dispositivo dispone di un certificato valido emesso dall'Autorità di certificazione Webex .

xStatus Conference EndToEndEncryption InternalIdentity Identity

L'identità del dispositivo letto dal nome comune del certificato emesso da Webex.

Contiene un nome 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.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Legge informazioni specifiche dal certificato emesso da Webex.

Nel comando visualizzato, sostituire # con il numero del certificato. Replace specificinfo con uno di:

  • Fingerprint

  • NotAfter Data di data di fine validità

  • NotBefore Data di data di inizio validità

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Un elenco degli oggetti del certificato (es. indirizzo e-mail o nome dominio)

  • Validity Fornisce lo stato di validità di questo certificato (es valid o expired)

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

chiamata API

Descrizione

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

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 Populate Secret: "base64url-encoded"

o

xCommand Security ClientSecret Populate Secret: JWEblob

Accetta un valore di testo normale codificato base64url per il seeding del segreto client sul dispositivo per la prima volta.

Per aggiornare il segreto dopo tale prima volta, è necessario fornire un BLOB JWE contenente il nuovo segreto crittografato dal segreto precedente.

xCommand Security Certificates Services Add JWEblob

Aggiunge un certificato (con chiave privata).

Questo comando è stato esteso per accettare un BLOB 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 serializzazione dell'impronta digitale identificativa in un BLOB 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 serializzazione dell'impronta digitale identificativa in un BLOB JWE.