Grazie per il feedback.
Feedback?
Gli utenti scelgono il tipo di riunione quando programmano una riunione. Quando ammette i partecipanti dalla lobby, così come durante la riunione, l'organizzatore può vedere lo stato di verifica dell'identità di ciascun partecipante. Esiste anche un codice della riunione comune a tutti gli attuali partecipanti alla riunione, che possono utilizzare per verificare che la riunione non sia stata intercettata da un attacco indesiderato di terze parti Meddler In The Middle (MITM).
Condivida le seguenti informazioni con i conduttori della sua riunione:
-
Partecipa a una riunione Webex con crittografia end-to-end
Verificare l'identità
La crittografia end-to-end con verifica dell'identità fornisce una sicurezza aggiuntiva a una riunione crittografata end-to-end.
Quando i partecipanti o i dispositivi entrano a far parte di un gruppo MLS (Messaging Layer Security) condiviso, presentano i loro certificati agli altri membri del gruppo, che poi convalidano i certificati rispetto alle autorità di certificazione (CA) emittenti. Confermando che i certificati sono validi, la CA verifica l'identità dei partecipanti e la riunione mostra i partecipanti/dispositivi come verificati.
Gli utenti dell'app Webex si autenticano tramite l'archivio di identità Webex, che rilascia loro un token di accesso quando l'autenticazione ha esito positivo. Se hanno bisogno di un certificato per verificare la propria identità in una riunione crittografata end-to-end, la Webex CA rilascia loro un certificato basato sul loro token di accesso. Al momento, non forniamo Webex Meetings agli utenti un modo per ottenere un certificato emesso da una CA terza/esterna.
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 basato sul token di accesso dell'account macchina del dispositivo. Il certificato è firmato dalla Webex CA. I dispositivi non hanno ID utente nello stesso modo degli utenti, quindi Webex utilizza (uno dei) domini della sua organizzazione per scrivere l'identità del certificato del dispositivo (Common Name (CN)).
-
CA esterna: richieda e acquisti i certificati del dispositivo direttamente dall'emittente prescelto. Deve crittografare, caricare direttamente e autorizzare i certificati utilizzando un segreto noto solo a Lei.
Cisco non è coinvolta, il che rende questo il modo per garantire una vera crittografia end-to-end e un'identità verificata e prevenire la possibilità teorica che Cisco possa intercettare la sua riunione/decrittografare i suoi contenuti multimediali.
Certificato del dispositivo rilasciato internamente
Webex emette un certificato al dispositivo quando si registra dopo l'avvio e lo rinnova quando necessario. Per i dispositivi, il certificato include l'ID dell'account e un dominio.
Se la sua organizzazione non ha un dominio, la Webex CA emette il certificato senza dominio.
Se la sua organizzazione ha più domini, può utilizzare Control Hub per indicare a Webex quale dominio il dispositivo deve utilizzare per la sua identità. Può anche utilizzare l'API XConfiguration Conference EndToEncryption Identity PreferredDomain: «example.com».
Se ha più domini e non imposta il dominio preferito per il dispositivo, Webex ne sceglie uno per Lei.
Certificato del dispositivo rilasciato esternamente
Un amministratore può fornire a un dispositivo 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 con una chiave RSA.
I valori nel certificato sono a discrezione dell'organizzazione. Il nome comune (CN) e il nome alternativo del soggetto (SAN) verranno visualizzati nell'interfaccia utente della riunione Webex, come descritto in Crittografia end-to-end con verifica dell'identità per. Webex Meetings
Si consiglia di utilizzare un certificato separato per dispositivo e di avere 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 dalle manomissioni, viene utilizzata una funzionalità segreta del client per crittografare e firmare vari comandi.
Quando si utilizza il segreto del cliente, è possibile gestire in modo sicuro il certificato di identità Webex esterno tramite xAPI. Attualmente è limitato ai dispositivi online.
Webex attualmente fornisce comandi API per gestirlo.
Dispositivi
I dispositivi Cisco Board, Desk e Room registrati nel cloud possono partecipare alle riunioni E2EE.
I seguenti dispositivi non possono partecipare alle riunioni E2EE:
-
Dispositivi SIP di terze parti
Client software
-
L'app Webex per client desktop e mobili può partecipare alle riunioni E2EE.
-
Il client web Webex non può partecipare alle riunioni E2EE.
-
I soft client SIP di terze parti non possono partecipare alle riunioni E2EE.
Identità
-
In base alla progettazione, non forniamo opzioni di Control Hub per gestire l'identità del dispositivo verificata esternamente. Per una vera crittografia end-to-end, solo Lei dovrebbe conoscere/accedere ai segreti e alle chiavi. Se introduciamo un servizio cloud per gestire quelle chiavi, c'è la possibilità che vengano intercettate.
-
Attualmente forniamo una «ricetta» per progettare i suoi strumenti, basati su tecniche di crittografia standard del settore, per aiutarla a richiedere o crittografare i certificati di identità del suo dispositivo e le relative chiavi private. Non vogliamo avere alcun accesso reale o percepito ai suoi segreti o alle sue chiavi.
Riunioni
-
Le riunioni E2EE attualmente supportano un massimo di 1000 partecipanti.
- Può condividere nuove lavagne nelle riunioni E2EE. Ci sono alcune differenze rispetto alle lavagne nelle riunioni regolari:
- Nelle riunioni E2EE, gli utenti non possono accedere alle lavagne create all'esterno della riunione, comprese le lavagne private, le lavagne condivise da altri e le lavagne degli spazi Webex.
- Le lavagne create nelle riunioni E2EE sono disponibili solo durante la riunione. Non vengono salvati e non sono accessibili dopo la fine della riunione.
- Se qualcuno condivide contenuti in una riunione E2EE, può annotarli. Per ulteriori informazioni sulle annotazioni, vedere App Webex | Contrassegnare i contenuti condivisi con annotazioni.
Interfaccia di gestione
Le consigliamo vivamente di utilizzare Control Hub per gestire il suo sito Meetings, poiché le organizzazioni di Control Hub hanno un'identità centralizzata per l'intera organizzazione.
Informazioni correlate
-
Zero-Trust Security per Webex (documento tecnico sulla sicurezza)
-
JSON Web Encryption (JWE) (bozza di standard IETF)
-
Webex Meetings41,7.
-
Dispositivi Cisco delle serie Board, Desk e Room registrati nel cloud, con sistema
10.6.1-RoomOS_August_2021o successivo. -
Accesso amministrativo al sito della riunione in Control Hub.
-
Uno o più domini verificati nella sua organizzazione Control Hub (se utilizza Webex CA per emettere certificati di dispositivo per l'identità verificata).
-
Le sale riunioni di collaborazione devono essere attivate in modo che le persone possano partecipare dal proprio sistema video. Per ulteriori informazioni, vedere Consentire ai sistemi video di partecipare a riunioni ed eventi sul suo sito Webex.
Può saltare questo passaggio se non Le servono identità verificate esternamente.
Per il massimo livello di sicurezza e per la verifica dell'identità, ogni dispositivo deve avere un certificato univoco rilasciato da un pubblico affidabile Certificate Authority (CA).
Deve interagire con la CA per richiedere, acquistare e ricevere i certificati digitali e creare le chiavi private associate. Quando richiede il certificato, utilizzi questi parametri:
-
Il certificato deve essere emesso e firmato da una nota CA pubblica.
-
Unico: Consigliamo vivamente di utilizzare un certificato univoco per ogni dispositivo. Se utilizza un certificato per tutti i dispositivi, sta compromettendo la sua sicurezza.
-
Nome comune (CN) e nome/i alternativi del soggetto (SAN/i): non sono importanti per Webex, ma dovrebbero essere valori che gli esseri umani possano leggere e associare al dispositivo. Il CN mostrerà agli altri partecipanti alla riunione l'identità principale verificata del dispositivo e, se gli utenti controllano il certificato tramite l'interfaccia utente della riunione, vedranno il/i SAN. Potrebbe voler usare nomi come
name.model@example.com. -
Formato file: i certificati e le chiavi devono essere in formato
.pem. -
Scopo: lo scopo del certificato deve essere Webex Identity.
-
Generazione di chiavi: i certificati devono essere basati su coppie di chiavi ECDSA P-256 (Elliptical Curve Digital Signature Algorithm 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.
Può saltare questo passaggio se non desidera utilizzare un'identità verificata esternamente con i suoi dispositivi.
Se sta utilizzando nuovi dispositivi, non li registri ancora su Webex. Per sicurezza, non li connetta alla rete a questo punto.
Se dispone di dispositivi esistenti che desidera aggiornare per utilizzare un'identità verificata esternamente, deve ripristinare le impostazioni di fabbrica dei dispositivi.
-
Salvi la configurazione esistente se desidera mantenerla.
-
Pianifica una finestra in cui i dispositivi non vengono utilizzati o usi un approccio graduale. Informare gli utenti delle modifiche che possono aspettarsi.
-
Garantire l'accesso fisico ai dispositivi. Se deve accedere ai dispositivi tramite la rete, sappia che i segreti viaggiano in testo normale e sta compromettendo la sua sicurezza.
Dopo aver completato questi passaggi, consenti ai sistemi video di partecipare a riunioni ed eventi sul suo sito Webex.
Per garantire che i contenuti multimediali del suo dispositivo non possano essere crittografati da nessuno tranne che dal dispositivo, deve crittografare la chiave privata sul dispositivo. Abbiamo progettato le API per il dispositivo per consentire la gestione della chiave e del certificato crittografati, utilizzando JSON Web Encryption (JWE).
Per garantire una vera crittografia end-to-end attraverso il nostro cloud, non possiamo essere coinvolti nella crittografia e nel caricamento del certificato e della chiave. Se ha bisogno di questo livello di sicurezza, deve:
-
Richieda i suoi certificati.
-
Genera le coppie di chiavi dei suoi certificati.
-
Crea (e protegga) un segreto iniziale per ogni dispositivo, per impostare la capacità di crittografia del dispositivo.
-
Sviluppi e gestisca il suo strumento per crittografare i file utilizzando lo standard JWE.
Il processo e i parametri (non segreti) di cui avrà bisogno sono spiegati di seguito, oltre a una ricetta da seguire nei suoi strumenti di sviluppo preferiti. Forniamo anche alcuni dati di test e i blob JWE risultanti come previsto, per aiutarla a verificare il suo processo.
Un'implementazione di riferimento non supportata che utilizza Python3 e la libreria JWCrypto è disponibile presso Cisco su richiesta.
-
Concatenare e crittografare il certificato e la chiave utilizzando il suo strumento e il segreto iniziale del dispositivo.
-
Carichi il blob JWE risultante sul dispositivo.
-
Impostare lo scopo del certificato crittografato da utilizzare per l'identità Webex e attivare il certificato.
-
(Consigliato) Fornisca un'interfaccia (o distribuisca) il suo strumento per consentire agli utenti del dispositivo di modificare il segreto iniziale e proteggere i propri contenuti multimediali da Lei.
Come utilizziamo il formato JWE
Questa sezione descrive come ci aspettiamo che il JWE venga creato come input per i dispositivi, in modo che Lei possa creare il suo strumento per creare i blob dai suoi certificati e dalle sue chiavi.
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 blob JWE. I parametri che deve includere per creare i blob JWE sono:
-
JOSE Header (protetto). Nell'intestazione JSON Object Signing and Encryption, DEVE includere le seguenti coppie chiave-valore:
-
«alg» :"dir»L'algoritmo diretto è l'unico che supportiamo per crittografare il payload e Lei deve utilizzare il segreto client iniziale del dispositivo.
-
«enc» :"A128GCM» o «enc» :"A256GCM»Supportiamo questi due algoritmi di crittografia.
-
«cisco-action»: «aggiungi» o «cisco-action»: «popola» o «cisco-action»: «attiva»o «cisco-action»: «disattiva»Questa è una chiave proprietaria e può assumere quattro valori. Abbiamo introdotto questa chiave per segnalare lo scopo dei dati crittografati al dispositivo di destinazione. I valori prendono il nome dai comandi xAPI sul dispositivo su cui sta utilizzando i dati crittografati.
L'abbiamo chiamato
cisco-actionper mitigare i potenziali scontri con le future estensioni JWE. -
«cisco-kdf»: {«versione»: «1", «salt»: «base64URLEncodedrandom4+byte»}Un'altra chiave proprietaria. Utilizziamo i valori forniti come input per la derivazione delle chiavi sul dispositivo. La
versionedeve essere1(la versione della nostra funzione di derivazione chiave). Il valore disaltdeve essere una sequenza con codifica URL base64 di almeno 4 byte, che deve scegliere a caso.
-
-
Chiave crittografata JWE. Questo campo è vuoto. Il dispositivo lo deriva dal
ClientSecretiniziale. -
Vettore di inizializzazione JWE. Deve fornire un vettore di inizializzazione codificato base64url per decrittografare il payload. L'IV DEVE essere un valore casuale di 12 byte (stiamo usando la famiglia di cifrari AES-GCM, che richiede che l'IV sia lungo 12 byte).
-
JWE AAD (dati autenticati aggiuntivi). Deve omettere questo campo perché non è supportato nella serializzazione compatta.
-
JWE Ciphertext: Questo è il payload crittografato che desidera mantenere segreto.
Il carico utile PUÒ essere vuoto. Ad esempio, per reimpostare il segreto del cliente, deve sovrascriverlo con un valore vuoto.
Esistono diversi tipi di payload, a seconda di cosa sta cercando di fare sul dispositivo. Comandi xAPI diversi prevedono payload diversi e Lei deve specificare lo scopo del payload con la chiave
cisco-action, come segue:-
Con«cisco-action» :"popola» il testo cifrato è il nuovo ClientSecret. -
Con "
«cisco-action» :"add»il testo cifrato è un blob PEM contenente il certificato e la sua chiave privata (concatenata). -
Con "
«cisco-action» :"activate»il testo cifrato è 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 cifrato è l'impronta digitale (rappresentazione esadecimale di sha-1) del certificato che stiamo disattivando l'uso per la verifica dell'identità del dispositivo.
-
-
Tag di autenticazione JWE: Questo campo contiene il tag di autenticazione per accertare l'integrità dell'intero blob serializzato JWE in modo compatto
Come ricaviamo la chiave di crittografia da ClientSecret
Dopo la prima compilazione del segreto, non accettiamo né pubblichiamo il segreto come testo normale. Questo per prevenire 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) e quindi utilizza la chiave derivata per la decrittografia/crittografia dei contenuti sul dispositivo.
Ciò significa per Lei che il suo strumento per produrre blob JWE deve seguire la stessa procedura per derivare la stessa chiave di crittografia/decrittografia dal segreto del cliente.
I dispositivi utilizzano scrypt per la derivazione delle chiavi (vedi https://en.wikipedia.org/wiki/Scrypt), con i seguenti parametri:
-
Il fattore di costo (N) è 32768
-
BlockSizeFactor (r) è 8
-
Il fattore di parallelizzazione (p) è 1
-
Salt è una sequenza casuale di almeno 4 byte; deve fornire lo stesso
saltquando specifica il parametrocisco-kdf. -
Le lunghezze delle chiavi sono 16 byte (se seleziona l'algoritmo AES-GCM 128) o 32 byte (se seleziona l'algoritmo AES-GCM 256)
-
Il limite massimo di memoria è 64 MB
Questo set di parametri è l'unica configurazione di scrypt compatibile con la funzione di derivazione delle chiavi sui dispositivi. Questo kdf sui dispositivi si chiama «version» :"1", che è l'unica versione attualmente utilizzata dal parametro cisco-kdf.
Esempio funzionante
Ecco un esempio che può seguire per verificare che il suo processo di crittografia JWE funzioni come il processo che abbiamo creato sui dispositivi.
Lo scenario di esempio è l'aggiunta di un blob PEM al dispositivo (simula l'aggiunta di un certificato, con una stringa molto breve anziché un certificato completo + chiave). Il segreto del cliente nell'esempio è l'ossifrage.
-
Scelga un codice di crittografia. Questo esempio utilizza
A128GCM(AES con chiavi a 128 bit in modalità contatore Galois). Il suo strumento potrebbe utilizzareA256GCM se preferisce. -
Scelga 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 per ottenere5EZTCap4M_Y(rimuova il padding di base64). -
Ecco un esempio di chiamata
Scryptper creare la chiave di crittografia dei contenuti (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) come segue:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff acche base64url codifica in LZ66BDEIAQV4_MQDINJ_RA. -
Scelga 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 83che base64url codifica in NLND3v9te68tkpwd. -
Crei l'intestazione JOSE con serializzazione compatta (segua lo stesso ordine di parametri che usiamo qui) e poi base64url la codifica:
{"alg» :"dir», "cisco-action» :"add», "cisco-kdf»: {"salt» :"5EZTCAP4M_Y», "version» :"1"}, "enc» :"A128GCM "}L'intestazione JOSE codificata in base64 url è EYJHBGCIOIJKAXIILCJJJAXNJBY1HY3RPB24IOIJHZGQILCJJAXNJBY1RZGYionSiC2FSDCi6IJVLWLRDQVA0TV9ZiIWidmvyC2LvBii6IjeiSwizw5JijoiVyC2LvbII6IjeiSwizw5JijoiVyC2LvBii6iJeifSwizw5JiJoiVa0TV9ZiIWidmvyC2LVBii6iJeifSwizw5JIjoiQteyoEDDTSJ9Questo sarà il primo elemento del blog JWE.
-
Il secondo elemento del blob JWE è vuoto, perché non stiamo fornendo una chiave di crittografia JWE.
-
Il terzo elemento del blob JWE è il vettore di inizializzazione Nlnd3v9te68Tkpwd. - Usi il suo strumento di crittografia JWE per produrre un payload e un tag crittografati. Per questo esempio, il payload non crittografato sarà il falso blob PEM,
questoè un file PEMI parametri di crittografia che deve usare sono:
Payload
è un file PEMIl codice di crittografia è AES 128 GCM
L'intestazione JOSE codificata in base64url come Additional Authenticated Data (AAD)
Base64url codifica il payload crittografato, che dovrebbe risultare in F5LLVuWNFKFMzyCo1YJfoDHQQuesto è il quarto elemento (testo cifrato JWE) nel blob JWE.
-
Base64url codifica il tag che ha prodotto nel passaggio 8, che dovrebbe risultare in PE-WDFWGXFFBEO928CFZ1QQuesto è il quinto elemento del blog JWE.
-
Concatenate i cinque elementi del blob JWE con punti (joseHeader.. iv.ciphertext.tag) per ottenere:
EYJHBGCIOIJKAXIILCJJAXNJBY1HY3RPB24IOIJHZGQILCJJJAXNJBY1RZGYiOnSiC2FSDCi6IJVLWLRDQVA0TV9ZiIWidmVyC2LvBii6IjeIfSwizw5JiJoiQTEYoEddtsj.. 9nLnDtSj. 3V9te68tkpwd.F5LLVuWNFKFMzyCo1YJfoDHQ.pe-wdfWGxFFBeo928CFZ1Q -
Se ha derivato gli stessi valori codificati in base64url che mostriamo qui, utilizzando i suoi strumenti, è pronto a usarli per proteggere la crittografia E2E e l'identità verificata dei suoi dispositivi.
-
Questo esempio in realtà non funzionerà, ma in linea di principio il suo prossimo passo sarebbe usare il blob JWE da Lei creato sopra come input per il comando sul dispositivo che aggiunge il certificato:
Certificati di sicurezza XCommand AggiungereeyjhbgcioIJkaxiILCJJAXNJBY1HY3RPB24IOIJHZGQILCJJAXNJBY1RZGYiOnSiC2FSDCi6IJVLWLRDQVA0TV9ZiiWidmvyC2LVBII6ijeIfSwizw5JIJoiQTEYoEdtsj.. 9NLND3V9TE68TKPWD.f5LLVuWNFKFMzyCo1YJFODHQ.pe-WDFWGXFFBeo928CFZ1Q
I tipi di sessione per le riunioni zero-trust sono disponibili per tutte le sedi delle riunioni senza costi aggiuntivi. Uno di questi tipi di sessione si chiama Pro-End to End Encryption_VoIPOnly. Questo è il nome del servizio pubblico, che potremmo cambiare in futuro. Per i nomi correnti dei tipi di sessione, vedere gli ID dei tipi di sessione nella sezione Riferimenti di questo articolo.
Non deve fare nulla per ottenere questa funzionalità per il suo sito; deve concedere il nuovo tipo di sessione (chiamato anche Meeting Privilege) agli utenti. Può farlo individualmente tramite la pagina di configurazione dell'utente o in blocco con un'esportazione/importazione CSV.
| 1 |
Acceda a Control Hub e vada su . |
| 2 |
Fare clic su Siti, scegliere il sito Webex per il quale modificare le impostazioni, quindi fare clic su Impostazioni. |
| 3 |
In Impostazioni comuni, seleziona Tipi di sessione. Dovrebbe vedere uno o più tipi di sessioni di crittografia end-to-end. Si riferisca all'elenco degli ID dei tipi di sessione nella sezione Riferimenti di questo articolo. Ad esempio, potrebbe vedere Pro-End to End Encryption_VoIPOnly.
Esiste un tipo di sessione precedente con un nome molto simile: Pro-End to End Encryption. Questo tipo di sessione include l'accesso PSTN non crittografato alle riunioni. Si assicuri di avere la versione _VoIPOnly per garantire la crittografia end-to-end. Può controllare passando il mouse sul link PRO nella colonna del codice di sessione; per questo esempio, la destinazione del link dovrebbe essere Potremmo cambiare i nomi dei servizi pubblici per questi tipi di sessioni in futuro. |
| 4 |
Se non ha ancora il nuovo tipo di sessione, contatti il suo rappresentante Webex. |
Cosa fare dopo
Abilita questo tipo di sessione/privilegio di riunione ad alcuni o tutti i suoi utenti.
| 1 |
Acceda a Control Hub e vada su . |
| 2 |
Seleziona un account utente da aggiornare, quindi seleziona Riunioni. |
| 3 |
Dall'elenco a discesa Impostazioni applica a, seleziona il sito della riunione da aggiornare. |
| 4 |
Spunta la casella accanto a Pro-End to End Encryption_VoIPOnly. |
| 5 |
Chiuda il pannello di configurazione utente. |
| 6 |
Ripetere l'operazione per altri utenti, se necessario. Per assegnarlo a molti utenti, usi l'opzione successiva, Abilita le riunioni E2EE per più utenti. |
| 1 |
Acceda a Control Hub e vada su . |
| 2 |
Fai clic su Siti, scelga il sito Webex per il quale desidera modificare le impostazioni. |
| 3 |
Nella sezione Licenze e utenti, faccia clic su Gestione in blocco. |
| 4 |
Faccia clic su Genera rapporto e attenda mentre prepariamo il file. |
| 5 |
Quando il file è pronto, faccia clic su Esporta risultati e poi su Scarica. (Deve chiudere manualmente la finestra pop-up dopo aver fatto clic su Download.) |
| 6 |
Aprire il file CSV scaricato per modificarlo. C'è una riga per ogni utente e la colonna |
| 7 |
Il riferimento al formato di file CSV Webex contiene dettagli sullo scopo e sul contenuto del file CSV. |
| 8 |
Aprire il pannello di configurazione del sito della riunione in Control Hub. Se era già nella pagina dell'elenco dei siti della riunione, potrebbe doverla aggiornare. |
| 9 |
Nella sezione Licenze e utenti, faccia clic su Gestione in blocco. |
| 10 |
Faccia clic su Importa e selezioni il file CSV modificato, quindi faccia clic su Importa. Attendi che il file venga caricato. |
| 11 |
Al termine dell'importazione, può fare clic su Importa risultati per verificare se ci sono stati errori. |
| 12 |
Vai alla pagina Utenti e apra uno degli utenti per verificare che abbia il nuovo tipo di sessione. |
Può aggiungere una filigrana alle registrazioni delle riunioni con il tipo di sessione Webex MeetingsPro-End to End Encryption_VoIPOnly, che Le 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 identificatore univoco per ogni cliente o dispositivo partecipante. Può caricare le registrazioni audio su Control Hub, che poi analizza la registrazione e cerca gli identificatori univoci. Può guardare i risultati per vedere quale cliente o dispositivo di origine 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 durare più di 100 secondi.
- Può analizzare solo le registrazioni delle riunioni ospitate da persone della sua organizzazione.
- Le informazioni sulla filigrana vengono conservate per la stessa durata delle informazioni sulle riunioni dell'organizzazione.
Aggiungere filigrane audio alle riunioni E2EE
- Accedi a Control Hub, quindi in Gestione, seleziona Impostazioni dell'organizzazione.
- Nella sezione Filigrane della riunione, attivi Aggiungi filigrana audio.
Qualche tempo dopo l'attivazione, gli utenti che programmano riunioni con il tipo di sessione
Webex MeetingsPro-End to End Encryption_VoIPOnlyvedono l'opzione Digital Watermarking nella sezione Sicurezza.
Carica e analizza una riunione con filigrana
- In Control Hub, in Monitoraggio, seleziona Risoluzione dei problemi.
- Fai clic su Analisi della filigrana.
- Cerca o seleziona la riunione nell'elenco, quindi faccia clic su Analizza.
- Nella finestra Analizza filigrana audio, inserisca un nome per la sua analisi.
- (Facoltativo) Inserisca una nota per la sua analisi.
- Trascina e rilascia il file audio da analizzare o fai clic su Scegli file per cercare il file audio.
- Faccia clic su Chiudi.
Una volta completata, l'analisi verrà visualizzata nell'elenco dei risultati nella pagina Analizza filigrana.
- Seleziona la riunione nell'elenco per vedere i risultati dell'analisi. Fare clic
per scaricare i risultati.
Caratteristiche e limitazioni
I fattori coinvolti nella corretta decodifica di una filigrana registrata includono la distanza tra il dispositivo di registrazione e l'altoparlante che emette l'audio, il volume di quell'audio, il rumore ambientale, ecc. La nostra tecnologia di filigrana ha una maggiore resilienza alla codifica più volte, come potrebbe accadere quando i contenuti multimediali vengono condivisi.
Questa funzione è progettata per consentire la corretta decodifica dell'identificatore della filigrana in una serie ampia 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 a un client portatile, crei sempre una registrazione che porti a un'analisi di successo. Man mano che il dispositivo di registrazione viene allontanato dalla sorgente o viene oscurato dall'ascolto dell'intero spettro audio, le possibilità di un'analisi riuscita diminuiscono.
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 cliente, le limitazioni non dovrebbero applicarsi.
Se i suoi dispositivi sono già integrati nella sua organizzazione Control Hub e desidera utilizzare Webex CA per generare automaticamente i loro certificati di identificazione, non è necessario ripristinare le impostazioni di fabbrica dei dispositivi.
Questa procedura seleziona il dominio utilizzato dal dispositivo per identificarsi ed è necessaria solo se ha più domini nella sua organizzazione Control Hub. Se ha più di un dominio, Le consigliamo di farlo per tutti i suoi dispositivi che avranno un'identità «verificata da Cisco». Se non dice a Webex quale dominio identifica il dispositivo, ne viene scelto automaticamente uno e potrebbe apparire sbagliato agli altri partecipanti alla riunione.
Prima che Lei cominci
Se i suoi dispositivi non sono ancora integrati, segua Register a Device to Cisco Webex Using API or Local Web Interface o Cloud Onboarding for Board, Desk e Room Series. Deve inoltre verificare il/i dominio/i che desidera utilizzare per identificare i dispositivi in Gestisci i suoi domini.
| 1 |
Accedi a Control Hub e, in Gestione, seleziona Dispositivi. |
| 2 |
Seleziona un dispositivo per aprirne il pannello di configurazione. |
| 3 |
Selezioni il dominio che desidera utilizzare per identificare questo dispositivo. |
| 4 |
Ripetere l'operazione per altri dispositivi. |
Prima che Lei cominci
-
Ottenga un certificato e una chiave privata firmati dall'autorità di certificazione, in formato
.pem, per ogni dispositivo. -
Nella scheda Prepare, legga l'argomento Comprendere il processo di identità esterna per i dispositivi,
-
Prepari uno strumento di crittografia JWE per quanto riguarda le informazioni ivi contenute.
-
Si assicuri di avere uno strumento per generare sequenze di byte casuali di determinate lunghezze.
-
Si assicuri di avere uno strumento per codificare byte o testo in base64url.
-
Si assicuri di avere un'implementazione di
Scrypt. -
Si assicuri di avere una parola o una frase segreta per ogni dispositivo.
| 1 |
Compila il La prima volta che compila il Il dispositivo ha il suo segreto iniziale. Non lo dimentichi; non può recuperarlo e deve ripristinare le impostazioni di fabbrica del dispositivo per ricominciare da capo.
|
| 2 |
Concatenare il certificato e la chiave privata: |
| 3 |
Crei un blob JWE da utilizzare come input per il comando certificate add: |
| 4 |
Aprire TShell sul dispositivo ed eseguire il comando add (multilinea): |
| 5 |
Verificare che il certificato sia stato aggiunto eseguendo il Copia l'impronta digitale del nuovo certificato. |
| 6 |
Attiva il certificato per lo scopo Il dispositivo ha un certificato crittografato, attivo, emesso dalla CA, pronto per essere utilizzato per identificarlo nelle riunioni Webex crittografate end-to-end.
|
| 7 |
Effettua l'integrazione del dispositivo nella sua organizzazione Control Hub. |
| 1 |
Pianifica una riunione del tipo corretto (Webex MeetingsPro-End to End Encryption_VoIPOnly). |
| 2 |
Partecipa alla riunione come organizzatore, da un Webex Meetings cliente. |
| 3 |
Partecipa alla riunione da un dispositivo la cui identità è stata verificata dalla Webex CA. |
| 4 |
In qualità di host, verifichi che questo dispositivo appaia nella lobby con l'icona di identità corretta. |
| 5 |
Partecipa alla riunione da un dispositivo la cui identità è stata verificata da una CA esterna. |
| 6 |
In qualità di host, verifichi che questo dispositivo appaia nella lobby con l'icona di identità corretta. Saperne di più sulle icone di identità. |
| 7 |
Partecipa alla riunione come partecipante non autenticato alla riunione. |
| 8 |
In qualità di organizzatore, verifichi che questo partecipante appaia nella lobby con l'icona di identità corretta. |
| 9 |
Come host, ammette o rifiuta persone/dispositivi. |
| 10 |
Convalida l'identità del partecipante/dispositivo, ove possibile, controllando i certificati. |
| 11 |
Verifichi che tutti i partecipanti alla riunione vedano lo stesso codice di sicurezza della riunione. |
| 12 |
Partecipa alla riunione con un nuovo partecipante. |
| 13 |
Verifichi che tutti vedano lo stesso nuovo codice di sicurezza per le riunioni. |
-
Ha intenzione di rendere le riunioni crittografate end-to-end l'opzione di riunione predefinita, o la abiliterà solo per alcuni utenti o consentirà a tutti gli organizzatori di decidere? Quando avrà deciso come utilizzare questa funzione, prepari gli utenti a utilizzarla, soprattutto per quanto riguarda le limitazioni e cosa aspettarsi dalla riunione.
-
Deve assicurarsi che né Cisco né nessun altro possano decrittografare i suoi contenuti o impersonare i suoi dispositivi? In tal caso, Le servono i certificati di una CA pubblica.
-
Se dispone di diversi livelli di verifica dell'identità, autorizzi gli utenti a verificarsi reciprocamente con un'identità sostenuta da un certificato. Anche se ci sono circostanze in cui i partecipanti possono apparire come Non verificati e i partecipanti devono sapere come controllare, le persone non verificate potrebbero non essere impostori.
Se sta utilizzando una CA esterna per emettere i certificati del suo dispositivo, spetta a Lei monitorare, aggiornare e riapplicare i certificati.
Se Lei ha creato il segreto iniziale, capisca che i suoi utenti potrebbero voler cambiare il segreto del loro dispositivo. Potrebbe essere necessario creare un'interfaccia/distribuire uno strumento per consentire loro di farlo.
|
ID del tipo di sessione |
Nome del servizio pubblico |
|---|---|
|
638 |
Crittografia E2E+solo VoIP |
|
652 |
Crittografia Pro-End-to-End_VoIPOnly |
|
660 |
Crittografia Pro 3 Free-to-End_VoIPOnly Crittografia E2E + identità |
|
672 |
Pro 3 Free50-Crittografia end-to-end_VoIPOnly |
|
673 |
Istruttore di formazione E2E Encryption_VoIPOnly |
|
676 |
Broadworks Standard più crittografia end-to-end |
|
677 |
Broadworks Premium plus crittografia end-to-end |
|
681 |
Schoology Free più crittografia end-to-end |
Queste tabelle descrivono i comandi API dei dispositivi Webex che abbiamo aggiunto per riunioni crittografate end-to-end e identità verificata. Per ulteriori informazioni su come utilizzare l'API, vedere Accedere all'API per i dispositivi delle serie Board, Desk e Room.
Questi comandi xAPI sono disponibili solo su dispositivi che sono:
-
Registrato a Webex
-
Registrato in sede e collegato a Webex con per dispositivi Webex Edge
|
chiamata API |
Descrizione |
|---|---|
|
|
Questa configurazione viene effettuata quando l'amministratore imposta il dominio preferito del dispositivo da Control Hub. Necessario solo se l'organizzazione ha più di un dominio. Il dispositivo utilizza questo dominio quando richiede un certificato dalla CA Webex. Il dominio identifica quindi il dispositivo. Questa configurazione non è applicabile quando il dispositivo ha un certificato attivo emesso esternamente per identificarsi. |
|
|
Indica se il dispositivo può partecipare a una riunione crittografata end-to-end. L'API cloud lo chiama in modo che un'app associata sappia se può utilizzare il dispositivo per accedere. |
|
|
Indica se il dispositivo utilizza la verifica |
|
|
L'identità del dispositivo letta dal nome comune del certificato rilasciato esternamente. |
|
|
Legge informazioni specifiche da un certificato rilasciato esternamente. Nel comando mostrato, sostituisca
|
|
|
Lo stato dell'identità esterna del dispositivo (ad esempio |
|
|
Indica se il dispositivo dispone di un certificato valido emesso dalla Webex CA. |
|
|
L'identità del dispositivo letta dal nome comune del certificato emesso da Webex. Contiene un nome di dominio se l'organizzazione ha un dominio. È vuoto se l'organizzazione non ha 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 mostrato, sostituisca
|
|
chiamata API |
Descrizione |
|---|---|
|
|
|
chiamata API |
Descrizione |
|---|---|
o
| Accetta un valore di testo normale codificato in base64url per inviare il segreto del client sul dispositivo per la prima volta. Per aggiornare il segreto dopo quella prima volta, deve fornire un blob JWE contenente il nuovo segreto crittografato dal vecchio segreto. |
| Aggiunge un certificato (con chiave privata). Abbiamo esteso questo comando per accettare un blob JWE contenente i dati PEM crittografati. |
| Attiva un certificato specifico per WebexIdentity. |
| Disattiva un certificato specifico per WebexIdentity. |
