La sicurezza zero-trust di Webex fornisce la crittografia end-to-end e la verifica dell'identità affidabile nelle riunioni pianificate sala riunioni personale attendibili.
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:
Partecipare a una riunione Webex con crittografia end-to-end
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
Sicurezza zero trust per Webex (documento tecnico sulla sicurezza): https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html
Presentazione Cisco Live 2021 (è richiesta la registrazione Cisco Live): https://www.ciscolive.com/2021/learn/session-catalog.html?tab.digitalbundle=Anytime21&search.sessiontype=BRK&search.learningmap=1614364767910003wzD6#/session/16106298425360015zrh
Crittografia Web JSON (JWE) (Bozza standard IETF): https://datatracker.ietf.org/doc/html/rfc7516
Documentazione destinata agli utenti: https://help.webex.com/5h5d8ab
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:
Richiedi i certificati.
Generare le coppie di chiavi dei certificati.
Crea (e proteggi) un segreto iniziale per ciascun dispositivo, per eseguire il seeding della funzionalità di crittografia del dispositivo.
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.
Concatenare e crittografare il certificato e la chiave utilizzando lo strumento e il segreto iniziale del dispositivo.
Caricare il BLOB 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 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 essere1
(la versione della funzione di derivazione chiave). Il valore disalt
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 nuovoClientSecret
.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 ilcisco-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
.
Scegliere un codice di crittografia. Questo esempio utilizza
A128GCM
(AES con tasti a 128 bit in modalità contatore Galois). Lo strumento potrebbe utilizzareA256GCM
se si preferisce.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 ottenere5eZTCAP4M_Y
(rimuovere il rivestimento Base64).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 base64urllZ66bdEiAQV4_mqdInj_rA
.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 base64urlNLNd3V9Te68tkpWD
.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.
Il secondo elemento del BLOB JWE è vuoto poiché non viene fornita chiave di crittografia JWE .
Il terzo elemento del BLOB JWE è il vettore di inizializzazione
NLNd3V9Te68tkpWD
.- 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.
Base64url codifica il tag prodotto nel passaggio 8, che dovrebbe avere come risultato
PE-wDFWGXFFBeo928cfZ1Q
Questo è il quinto elemento nel BLOB JWE.
Concatenare i cinque elementi del BLOB JWE con punti (JOSEheader..IV.Ciphertext.Tag) per ottenere:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
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.
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 . | ||
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 .
| ||
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 . |
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 . | ||
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 | ||
7 | Per ogni utente che si desidera concedere il nuovo tipo di sessione, aggiungere 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.
| ||
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
- Accedi a Control Hub, quindi sotto Gestione, seleziona Impostazioni organizzazione.
- 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
- In Control Hub, sotto Monitoraggio , selezionare Risoluzione dei problemi .
- Fare clic su Analisi filigrana .
- Cercare o selezionare la riunione nell'elenco, quindi fare clic su Analizza.
- Nel Analizza la filigrana audio , immettere un nome per l'analisi.
- (Opzionale) Inserire una nota per l'analisi.
- Trascinare e rilasciare il file audio da analizzare o fare clic Scegli file per individuare il file audio.
- Fare clic su Chiudere.
Al termine dell'analisi, verrà visualizzata nell'elenco dei risultati nella pagina Analizza filigrana pagina.
- Selezionare la riunione nell'elenco per visualizzare i risultati dell'analisi. Fare clicper 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 La prima volta che si compila il file 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: |
3 | Creare un BLOB JWE da utilizzare come input per il comando di aggiunta del certificato: |
4 | Aprire TShell sul dispositivo ed eseguire il comando di aggiunta (multilinea):
|
5 | Verificare che il certificato sia stato aggiunto eseguendo Copiare l'impronta digitale del nuovo certificato. |
6 | Attivare il certificato allo scopo 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.
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
chiamata API | Descrizione |
---|---|
| 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. |
| 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. |
| Indica se il dispositivo utilizza |
| L'identità del dispositivo letto dal nome comune del certificato emesso esternamente. |
| Legge informazioni specifiche da un certificato emesso esternamente. Nel comando visualizzato, sostituire
|
| Lo stato dell'identità esterna del dispositivo (es |
| Indica se il dispositivo dispone di un certificato valido emesso dall'Autorità di certificazione Webex . |
| 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 |
| Legge informazioni specifiche dal certificato emesso da Webex. Nel comando visualizzato, sostituire
|
chiamata API | Descrizione |
---|---|
| Questi tre eventi ora includono |
chiamata API | Descrizione |
---|---|
o
| 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. |
| Aggiunge un certificato (con chiave privata). Questo comando è stato esteso per accettare un BLOB JWE contenente dati PEM crittografati. |
| Attiva un certificato specifico per WebexIdentity. Per questo |
| Disattiva un certificato specifico per WebexIdentity. Per questo |