- Home
- /
- Articolo
Stabilire lo standard per le riunioni riservate e crittografate end-to-end
Milioni di utenti in tutto il mondo si affidano a Webex per una collaborazione sicura. Dalle sale riunioni aziendali e dalle sessioni legislative governative alle consultazioni sensibili tra medico e paziente, Webex funge da piattaforma affidabile per le comunicazioni critiche.
Con l'aumentare della domanda di lavoro a distanza, aumenta anche la necessità di strumenti di collaborazione solidi e riservati. Webex ha soddisfatto questa esigenza più a lungo di qualsiasi altro fornitore. Con l'avvento delle imitazioni basate sull'intelligenza artificiale e delle sofisticate minacce deepfake, il requisito di una collaborazione basata su policy e verificata dall'identità è fondamentale. Per i nostri clienti, la sicurezza non è solo una funzionalità: è un componente integrato dell'intero ciclo di vita delle riunioni, che copre la pianificazione, l'identità dei partecipanti e la protezione dei contenuti.
La base: Webex Zero-Trust Security
Webex ha una lunga storia di supporto della crittografia end-to-end avanzata (E2EE). Il nostro modello Webex Zero Trust Security evolve questo patrimonio attraverso tre pilastri principali:
- Stabilire una base per la crittografia basata su standard e formalmente verificata
- Potenziamento della crittografia end-to-end con identità verificata end-to-end
- Estendere il supporto agli attuali dispositivi Webex e all'app Webex
Questo documento tecnico fornisce informazioni sulla sicurezza end-to-end e illustra le basi tecniche del funzionamento di WebexZero Trust Security. Per la sicurezza operativa delle riunioni, come i tipi di sessioni delle riunioni, le differenze di sicurezza tra le riunioni programmate e le sale riunioni personali, i controlli degli amministratori e degli host, la condivisione e la conservazione dei contenuti delle riunioni e una più ampia resilienza dell'IA e dei deepfake nell'esperienza della riunione, consulta il documento tecnico complementare di WSMP Meetings Security.
Un patrimonio di 18 anni di risultati in materia di sicurezza E2E
Webex è stato il pioniere della crittografia E2E per le riunioni nel 2008. Per definizione, la sicurezza E2E garantisce che il contenuto sia crittografato dal momento in cui viene inviato fino alla visualizzazione da parte del destinatario, impedendo al fornitore di servizi cloud o a terze parti di accedere o manomettere i dati.
A seconda dell'investimento effettuato da un fornitore di videoconferenze nei meccanismi di sicurezza E2E, può fornire diversi livelli di protezione, come mostrato nella Figura 1. Qualsiasi sicurezza E2E è migliore della sola crittografia in transito e a riposo.
| Livello di protezione | Attaccanti di rete | Attacchi passivi (intercettazioni) | Attacchi attivi (imitazione) | Esempi |
|---|---|---|---|---|
| Crittografia in transito e a riposo | Sì | No | No | App non E2EE |
| crittografia E2E | Sì | Sì | No | App E2EE e consumer precedenti |
| Crittografia E2E e identità E2E | Sì | Sì | Sì | Sicurezza Webex Zero Trust |
La maggior parte delle applicazioni che dichiarano di fornire sicurezza E2E forniscono protezione solo dagli attacchi passivi. Le protezioni solo passive sono ancora preziose perché fanno sì che i malintenzionati possano origliare una riunione solo mentre è in corso. L'approccio migliore, tuttavia, è proteggere dagli attacchi passivi e attivi, in cui lo stesso fornitore di servizi di conferenza potrebbe fingere di essere un partecipante legittimo per partecipare alla riunione. Per questo, è necessario un livello di identità E2E oltre alla crittografia E2E.
Con Zero Trust Security, Webex porta una crittografia più potente alle riunioni e aumenta la crittografia end-to-end con identità verificate end-to-end per aiutare a proteggere le riunioni dall'intero spettro di attacchi.
L'esperienza utente end-to-end
Prima di approfondire i dettagli tecnici, è utile comprendere l'esperienza dell'utente. Per creare una riunione crittografata E2E, l'organizzatore seleziona il tipo di riunione appropriato durante la pianificazione nell'app Webex (Figura 2).

Quando i partecipanti si uniscono, vedono un'icona «scudo con lucchetto» che indica che la riunione è crittografata con E2E (Figura 3). Toccando questa icona vengono forniti dettagli sulla protezione della riunione.

Infine, nell'elenco dei partecipanti alla riunione, l'applicazione Webex indica se l'identità del partecipante è stata verificata in modo sicuro E2E, ovvero se qualcuno diverso da Cisco ha garantito l'identità del partecipante (Figura 4).
I partecipanti possono anche verificare di avere tutti lo stesso codice di sicurezza per confermare che hanno tutti la stessa visione della riunione e quindi sono al sicuro dagli attacchi di impersonificazione. Nelle implementazioni che utilizzano certificati di identità end-to-end forniti dal cliente, lo stato dell'elenco fornisce trasparenza sulla garanzia dell'identità.

Crittografia basata su standard
Zero Trust Security si basa su protocolli crittografici standard del settore, che Cisco sta sviluppando insieme ad altri leader in materia di sicurezza e privacy, tra cui Google, Cloudflare, Wickr e Wire. Cisco ha guidato la prima generazione di Voice over IP (VoIP) sicuro con tecnologie come Secure Real-Time Protocol (SRTP), DTLS-SRTP, STIR/SHAKEN e WebRTC, e Cisco sta facendo lo stesso con Zero Trust Security (Figura 5).
| Strato | Oggi | Sicurezza Zero Trust |
|---|---|---|
| Identità | SSO (SAML, OpenID) | Certificato X.509 |
| Scambio di chiavi | SDES/DTLS | Messaging Layer Security (MLS) |
| Crittografia multimediale | SRTP | Cornici sicure (sFrame) |
Il sistema è composto fondamentalmente da tre livelli e in ogni livello stiamo prendendo la vecchia tecnologia hop-by-hop e la stiamo rafforzando con un ulteriore livello di protezione end-to-end. I tre livelli includono:
- Identità: l'identità E2E richiede che i clienti dispongano di credenziali che dimostrino la loro identità. Con Zero Trust E2E Identity, le credenziali dei clienti sono fornite da un Webex Independent. Certificate Authority
- Scambio di chiavi: i clienti che partecipano a una riunione E2E devono impostare le chiavi per la crittografia E2E senza che il fornitore di conferenze sia in grado di accedere a tali chiavi. Il protocollo Messaging Layer Security (MLS) è uno standard ratificato, RFC 9420, che si basa su tecnologie sviluppate nella comunità open source e le colloca in un ambiente rigoroso e formalmente verificato.
- Protezione dei contenuti: infine, il contenuto multimediale effettivo della riunione richiede una protezione end-to-end. sFrame (per «Secure Frames») è RFC 9605. È un framework di crittografia semplice e veloce per la crittografia dei contenuti multimediali in tempo reale, che consente di aggiungere un ulteriore livello di crittografia con un sovraccarico minimo.
Esaminiamo queste tecnologie in modo un po' più dettagliato, partendo dal basso verso l'alto.
Crittografia multimediale leggera
Uno schema di crittografia multimediale è un modo per prendere una chiave condivisa dai partecipanti a una riunione e utilizzarla per proteggere i contenuti effettivi condivisi nella riunione, come audio, video e condivisione dello schermo. A livello di protocollo, lo schema di crittografia deve inviare informazioni aggiuntive con ogni unità di dati crittografati, soprattutto:
- Un'intestazione che indica al destinatario come decrittografare il pacchetto e
- Un tag di autenticazione che il destinatario utilizza per verificare che il pacchetto non sia stato manomesso.
Ad esempio, in SRTP, l'unità di crittografia è un pacchetto RTP; SRTP si basa sull'intestazione RTP per la sua configurazione e aggiunge un tag di autenticazione alla fine del pacchetto.
Poiché tutte queste informazioni aggiuntive aumentano la larghezza di banda richiesta per una riunione crittografata E2E, sFrame fornisce la quantità minima di framing necessaria. L'intestazione sFrame indica quale chiave deve essere utilizzata, consentendo la rotazione della chiave e fornisce un numero di sequenza univoco che definisce il vettore di inizializzazione. Questo è seguito dal contenuto crittografato con la chiave E2E e un tag di autenticazione. L'intestazione, il contenuto e il tag sFrame vengono quindi racchiusi in un pacchetto SRTP, in modo che SRTP protegga dall'ispezione o dalla modifica da parte degli aggressori di rete e sFrame protegga dagli elementi multimediali del fornitore di conferenze (vedere l'esempio nella Figura 6).

Questo approccio minimalista ha altri vantaggi. sFrame è indipendente dal trasporto sottostante, quindi è compatibile con tecnologie emergenti come RTP su QUIC e RIPT. È anche possibile configurare sFrame in modo che funzioni su unità multi-pacchetto, come frame interi, per ridurre ulteriormente il sovraccarico di crittografia.
Scambio di chiavi di gruppo
Impostare una chiave segreta in un gruppo quando il gruppo ha accesso solo a un canale non attendibile sembra magico. Le tecniche per farlo sono state sviluppate per la prima volta negli anni '80 e oggi più del 90 percento della navigazione web utilizza Transport Layer Security (TLS) per fare esattamente questo. Messaging Layer Security (MLS) estende questa funzionalità ai gruppi, mentre TLS funziona solo punto a punto, quindi Webex può utilizzare MLS per impostare le chiavi di conferenza anche quando il fornitore della conferenza non è attendibile.
MLS offre tre funzionalità di sicurezza fondamentali:
- Chiave condivisa: la chiave è nota solo ai membri autenticati del gruppo.
- Coerenza: assicura che tutti i membri abbiano una visione coerente dell'elenco del gruppo.
- Rotazione: aggiorna automaticamente le chiavi quando un membro si unisce o esce.
La prima funzionalità ci fornisce le chiavi che utilizziamo per crittografare i contenuti multimediali con sFrame. Insieme alla seconda funzionalità, fornisce il punto di partenza per l'identità E2E. La terza funzione assicura che le uniche persone in grado di decrittografare i contenuti multimediali siano le persone che sono presenti alla riunione in questo momento: non può decrittografare i contenuti multimediali prima di entrare o dopo la sua partenza (o essere stato espulso).
Per fare tutto ciò, i clienti di una riunione si scambiano messaggi MLS nei punti critici della riunione per mantenere un gruppo MLS che contenga esattamente i partecipanti alla riunione in qualsiasi momento. Webex instrada i messaggi tra i client, ma MLS protegge questi messaggi in modo che sia sicuro per Webex gestirli. La Figura 7 mostra il flusso dei messaggi.

Creazione: La prima persona a partecipare alla riunione, organizzatore o meno, crea il gruppo MLS per la riunione e diventa il «leader» ai fini della MLS. In qualsiasi momento, un singolo partecipante alla riunione viene designato come leader. Nella maggior parte dei casi, questo partecipante sarà l'organizzatore della riunione. Una volta avviata la sessione, MLS assicura che ogni partecipante alla riunione disponga delle informazioni crittografiche per fungere da leader; Webex designa semplicemente un leader per evitare confusione.
Partecipa: Quando un nuovo partecipante desidera partecipare alla riunione, chiede di essere ammesso inviando un messaggio MLS Key Package al leader, che fornisce la chiave pubblica e le informazioni di autenticazione. Il leader risponde con un messaggio di benvenuto che informa il joiner sugli altri partecipanti alla riunione. Il leader trasmette anche un messaggio Aggiungi e un messaggio di conferma al gruppo. Il messaggio Aggiungi annuncia il nuovo partecipante a quelli già presenti alla riunione. Il messaggio Commit fa sì che tutti i partecipanti attuali eseguano l'hashing della vecchia chiave di gruppo per ottenere una nuova chiave per il gruppo ora esteso; il messaggio di benvenuto fornisce questa chiave al joiner.
Congedo: quando qualcuno lascia la riunione, è compito del leader escluderlo. Il leader lo fa trasmettendo messaggi MLS Remove and Commit a tutti i partecipanti alla riunione. Il messaggio Rimuovi indica ai partecipanti rimanenti chi se n'è andato e il Commit crittografa una nuova chiave per tutti i partecipanti rimanenti ma non per la persona che se n'è andata. I partecipanti rimanenti codificano la nuova chiave con la vecchia chiave di gruppo per ottenere una chiave che la persona che se n'è andata non ha. Se il partecipante che se n'è andato è il leader, Webex nomina un nuovo leader e il nuovo leader rimuove il vecchio leader.
Sia le adesioni che le uscite fanno sì che MLS generi una nuova chiave per il gruppo. Ogni volta che ciò accade, i partecipanti alla riunione si aggiornano a questa nuova chiave entro pochi secondi. MLS può anche gestire con garbo più transazioni di aggiunta e rimozione in un unico commit, per evitare una raffica di rotazioni di chiavi non necessarie e costose in situazioni come l'inizio o la fine di una riunione. Dopo ogni rotazione, i partecipanti alla riunione eliminano le loro copie delle vecchie chiavi in modo che, anche se una di esse è compromessa, il vecchio contenuto della riunione è al sicuro. Alla fine della riunione, i partecipanti eliminano le chiavi rimanenti, quindi anche se il contenuto della riunione E2E è stato archiviato da qualche parte, non può più essere decrittografato.
La rotazione delle chiavi può significare che ci vogliono un paio di secondi in più per partecipare a una riunione o rimuovere qualcuno, ma offre una chiara garanzia di sicurezza: se qualcuno non compare nell'elenco dei partecipanti alla riunione, non ha le chiavi per decrittografare il contenuto.
Identità verificata end-to-end
L'elenco dei partecipanti a una riunione crittografata E2E mostra la verifica dell'identità di ciascun utente. L'utilizzo di certificati di identità emessi dal cliente fornisce una vera identità verificata E2E, nel senso che Cisco non può alterarla. In questi casi, l'elenco dei partecipanti mostra il dominio a cui appartiene il partecipante in testo blu. Ad esempio, nella riunione mostrata nella Figura 8, può vedere che Kevin ha un indirizzo email verificato da example.com e Isabella ha un indirizzo email verificato da company.com.
I certificati di identità emessi da un WebexCertificate Authority, come l'identità di un dispositivo video, forniscono una protezione più limitata. Solo un utente malintenzionato che compromette il Webex Certificate Authority può impersonare un utente. Anche se è meglio che non avere alcuna protezione dell'identità, tali partecipanti alla riunione non sono contrassegnati in blu come identità verificata end-to-end Zero Trust. Sono mostrati con testo grigio per indicare la verifica dell'identità di Webex Trust.

Come supporto a queste procedure, Webex fornisce anche un codice di sicurezza per la riunione. Un codice di sicurezza è una stringa breve e leggibile dall'uomo calcolata come output del processo MLS. Il codice di sicurezza riassume lo stato crittografico della riunione, comprese le chiavi del gruppo e i certificati presentati dai partecipanti. Questo codice può essere utilizzato per rilevare un attacco di impersonificazione, perché un attacco del genere comporterebbe che almeno un partecipante abbia uno stato crittografico diverso da tutti gli altri. Ma esclude l'impersonificazione solo se tutti verificano di avere lo stesso codice. Se un sottoinsieme dei partecipanti verifica di avere lo stesso codice, sa che le proprie identità sono rappresentate fedelmente l'uno dall'altro, ma qualcuno che non conferma il proprio codice potrebbe essere stato impersonato. La Figura 9 mostra un esempio di come viene visualizzato il codice di sicurezza in una riunione.

Questo codice fornisce una difesa molto efficace contro gli attacchi di impersonificazione. Fa parte del protocollo MLS, quindi è stato sottoposto a una solida analisi di sicurezza. Poiché è strettamente legato allo stato della riunione, il codice di sicurezza cambia ogni volta che qualcuno partecipa alla riunione. Di conseguenza, i partecipanti alla riunione devono verificare nuovamente i propri codici di sicurezza ogni volta che qualcuno si unisce. Il codice non ruota quando qualcuno se ne va, perché se ne va non può introdurre un imitatore.
Riepilogo
Webex Zero Trust Security è stato lanciato nel 2021. Nel 2026, le riunioni Ultra Secure Webex hanno introdotto il supporto per endpoint aggiuntivi nelle riunioni Webex crittografate E2E, riunioni Zero Trust E2EE complete con Video Mesh Node (VMN) e funzionalità di crittografia e identità end-to-end per le riunioni standard:
- Crittografia basata su standard e formalmente verificata
- Crittografia Zero Trust E2E
- Identità verificata Zero Trust E2E
- Supporto per tutti i dispositivi Webex disponibili per la vendita
- Supporto per l'app Webex su desktop, dispositivi mobili e web
- Supporto per l'app Web Webex e l'SDK Web (previsto per il primo trimestre del 27 gennaio)
- Supporto per Webex Calling telefoni (previsto per il 3° trimestre del 26)
- Supporto per Video Mesh Node
- Supporto per la crittografia E2E nelle riunioni programmate e nelle sale riunioni personali
Zero Trust ha alcune limitazioni. Le riunioni crittografate E2E non supportano:
- Funzionalità fornite dai servizi cloud Cisco che richiedono l'accesso a contenuti multimediali in testo normale, tra cui:
- Registrazione e servizi Webex basati sul cloud. AI Assistant Questi servizi possono essere forniti utilizzando implementazioni ibride con Video Mesh Node (VMN).
- Salvataggio di chat, file, lavagne e annotazioni delle riunioni.
- Interoperabilità PSTN o SIP.
Direzioni future
In futuro, Webex migliorerà le riunioni crittografate E2E in alcune dimensioni, guidate dai principi di concedere al cloud il minimo privilegio necessario e dare ai clienti il controllo sui propri dati.
Sicurezza E2E onnipresente: tutto dovrebbe essere sicuro per l'E2E, non solo riunioni selezionate. Il primo passo verso il raggiungimento di questa visione è stato raggiunto con la sicurezza E2E per Webex Web App e i telefoni Cisco connessi al cloud. Alla fine, l'architettura E2E aperta e basata su standard dovrebbe consentire a Webex di introdurre anche l'infrastruttura SIP (Session Initiation Protocol).
Le innovazioni discusse in questo documento mostrano un chiaro percorso verso la visione a lungo termine della crittografia E2E sempre attiva. Una volta che gli utenti possono connettersi da qualsiasi luogo e i clienti possono attivare in modo sicuro le funzionalità desiderate in una riunione, la crittografia E2E può essere utilizzata per ogni riunione Webex, dalle riunioni informali ad hoc con tutte le funzionalità attivate, fino alle riunioni bloccate e ad alta sicurezza. La crittografia E2E assicurerà sempre che il contenuto della riunione sia disponibile solo per i partecipanti autorizzati e i clienti e gli utenti decideranno quale gruppo di partecipanti è giusto per una determinata riunione.
Impersonificazione basata sull'intelligenza artificiale e resilienza ai deepfake
Webex affronta le minacce di imitazione basate sull'intelligenza artificiale attraverso un approccio a più livelli che integra il modello di crittografia end-to-end Zero Trust. Sebbene questo documento si concentri sui fondamenti tecnici dell'identità verificata end-to-end, tra cui la verifica basata su certificati forniti dal cliente e i controlli di integrità crittografica delle riunioni, Webex fornisce anche controlli di sicurezza operativi nell'esperienza della riunione per ridurre il rischio di accessi non autorizzati e interazioni dannose.
Per i tipi di sessioni di riunione, le riunioni programmate rispetto alle differenze di sicurezza nelle sale riunioni personali, i controlli per host e amministratore in Control Hub e il rilevamento e la prevenzione aggiuntivi dell'IA e dei deepfake nell'esperienza di riunione più ampia, consulta il documento tecnico complementare di WSMP Meetings Security.
Conclusione
Webex sta definendo il futuro delle riunioni sicure attraverso crittografia basata su standard e identità verificate. L'impegno per un ecosistema aperto garantisce che i clienti mantengano il controllo assoluto sui propri dati, indipendentemente dallo scenario della riunione.