Tack för din feedback.

Miljontals användare världen över förlitar sig på Webex för säkert samarbete. Från företagsstyrelserum och regeringssessioner till känsliga läkare-patientkonsultationer, Webex fungerar som en pålitlig plattform för kritisk kommunikation.

I takt med att efterfrågan på distansarbete växer ökar också behovet av robusta, konfidentiella samarbetsverktyg. Webex har åtgärdat detta behov längre än någon annan leverantör. Med ökningen av AI-aktiverad imitering och sofistikerade deepfake-hot är kravet på identitetsverifierat, policydrivet samarbete av största vikt. För våra kunder är säkerhet inte bara en funktion — det är en integrerad del av hela möteslivscykeln, som omfattar schemaläggning, deltagaridentitet och innehållsskydd.

Webex har en lång historia av att stödja stark end-to-end-kryptering (E2EE). Vår Webex Zero Trust Security-modell utvecklar detta arv genom tre primära pelare:

• Upprättande av en grund för standardbaserad, formellt verifierad kryptografi
• Utöka end-to-end-kryptering med end-to-end-verifierad identitet
• Utöka stödet till nuvarande Webex-enheter samt Webex App

Detta tekniska dokument ger bakgrund om end-to-end-säkerhet och beskriver den tekniska grunden för hur WebExZero Trust Security fungerar. För driftsäkerhet för möten, till exempel mötessessionstyper, säkerhetsskillnader mellan schemalagda möten kontra personliga mötesrum, administratörs- och värdkontroller, delning och lagring av mötesinnehåll, och bredare AI- och deepfake-motståndskraft i mötesupplevelsen, se det medföljande tekniska dokumentet för WSMP Meetings Security.

Ett 18-årigt arv av att leverera på E2E-säkerhet

Webex banade väg för E2E-kryptering för möten 2008. Per definition säkerställer E2E-säkerhet att innehållet krypteras från det ögonblick det skickas tills det visas av mottagaren, vilket förhindrar molnleverantören eller någon tredje part från att komma åt eller manipulera data.

Beroende på hur mycket investeringar en videokonferensleverantör gör i E2E-säkerhetsmekanismer, de kan ge olika skyddsnivåer, som visas i figur 1. All E2E-säkerhet är bättre än att bara kryptera i transit och i vila.

Skyddsnivå	Nätverksangripare	Passiva attacker (avlyssning)	Aktiva attacker (imitering)	Exempel
Kryptering i transit och i vila	Javisst	Nej	Nej	Icke-E2EE-appar
E2E-kryptering	Javisst	Javisst	Nej	Äldre E2EE- och konsumentappar
E2E-kryptering och E2E-identitet	Javisst	Javisst	Javisst	Webex Zero Trust-säkerhet

De flesta applikationer som påstår sig tillhandahålla E2E-säkerhet ger endast skydd mot passiva attacker. Endast passiva skydd är fortfarande värdefulla eftersom de gör det så att dåliga aktörer bara kan avlyssna ett möte medan det pågår. Det bästa tillvägagångssättet är dock att skydda mot både passiva och aktiva attacker, där konferensleverantören själv kan låtsas vara en legitim deltagare för att delta i mötet. För detta behövs ett E2E-identitetslager utöver E2E-kryptering.

Med Zero Trust Security ger Webex starkare kryptografi till möten och förstärker end-to-end-kryptering med end-to-end-verifierad identitet för att hålla möten säkra från hela spektrumet av attacker.

Innan du dyker in i tekniska detaljer är det bra att förstå användarupplevelsen. För att skapa ett E2E-krypterat möte väljer värden lämplig mötestyp under schemaläggning i Webex App (Figur 2).

När deltagarna går med ser de en ”sköld med lås” -ikon som indikerar att mötet är E2E-krypterat (Figur 3). Om du trycker på den här ikonen får du information om mötets skydd.

Slutligen anger Webex-applikationen i mötesdeltagarlistan om deltagarens identitet har verifierats på ett E2E-säkert sätt - det vill säga om någon annan än Cisco har godkänt deltagarens identitet (Figur 4).

Deltagarna kan också kontrollera att de alla har samma säkerhetskod för att bekräfta att de alla har samma bild av mötet, och därmed är säkra från imitationsattacker. I distributioner som använder kundtillhandahållna heltäckande identitetscertifikat ger rostertillståndet transparens om identitetssäkring.

Zero Trust Security bygger på kryptografiska protokoll av branschstandard, som Cisco driver tillsammans med andra ledare inom säkerhet och integritet, inklusive Google, Cloudflare, Wickr och Wire. Cisco ledde den första generationen av säker Voice over IP (VoIP) med tekniker som Secure Real-Time Protocol (SRTP), DTLS-SRTP, STIR/SHAKEN och WebRTC, och Cisco gör samma sak med Zero Trust Security (Figur 5).

Skiktet	I dag	Zero Trust-säkerhet
Identitet	SSO (SAML, OpenID)	X.509-certifikat
Nyckelbyte	SDES/DTLS	Meddelandelagersäkerhet (MLS)
Mediekryptering	SRTP	Säkra ramar (sFrame)

Det finns i princip tre lager i systemet, och vid varje lager tar vi den gamla hop-by-hop-tekniken och förstärker den med ett extra lager av skydd från början till slut. De tre skikten inkluderar:

• Identitet—E2E-identitet kräver att klienter har referenser som bevisar deras identitet. Med Zero Trust E2E Identity tillhandahålls klienternas autentiseringsuppgifter av en Webex Independent. Certificate Authority
• Nyckelutbyte — Kunder som deltar i ett E2E-möte måste ställa in nycklar för E2E-kryptering utan att konferensleverantören kan komma åt dessa nycklar. MLS-protokollet (Messaging Layer Security) är en ratificerad standard, RFC 9420, som bygger på teknik som utvecklats i öppen källkodsgemenskap och sätter dem i en rigorös, formellt verifierad miljö.
• Innehållsskydd — Slutligen behöver själva medieinnehållet i mötet ett heltäckande skydd. SFrame (för ”säkra ramar”) är RFC 9605. Det är ett snabbt och enkelt krypteringsramverk för kryptering av realtidsmedia, vilket gör att ett extra lager av kryptering kan läggas till med minimal kostnad.

Låt oss titta på dessa tekniker lite mer detaljerat, från botten upp.

Ett mediekrypteringsschema är ett sätt att ta en nyckel som delas av deltagarna i ett möte och använda den för att skydda det faktiska innehållet som delas i mötet, till exempel ljud, video och skärmdelning. På protokollnivå måste krypteringsschemat skicka extra information med varje enhet krypterad data, viktigast av allt:

1. En rubrik som berättar för mottagaren hur man dekrypterar paketet, och
2. En autentiseringstagg som mottagaren använder för att verifiera att paketet inte har manipulerats.

Till exempel, i SRTP, är krypteringsenheten ett RTP-paket; SRTP förlitar sig på RTP-huvudet för dess installation och lägger till en autentiseringstagg i slutet av paketet.

Eftersom all denna extra information ökar bandbredden som krävs för ett E2E-krypterat möte, tillhandahåller SFrame den minsta mängd inramning som krävs. SFrame-rubriken anger vilken nyckel som ska användas, vilket möjliggör nyckelrotation, och ger ett unikt sekvensnummer som definierar initialiseringsvektorn. Detta följs av innehållet krypterat med E2E-nyckeln och en autentiseringstagg. SFrame-rubriken, innehållet och taggen förpackas sedan i ett SRTP-paket, så att SRTP skyddar mot inspektion eller modifiering av nätverksangripare, och SFrame skyddar mot konferensleverantörens medieelement (se exempel i figur 6).

Detta minimalistiska tillvägagångssätt har andra fördelar. SFrame är oberoende av den underliggande transporten, så den är framåtkompatibel med nya tekniker som RTP över QUIC och RIPT. Det är också möjligt att konfigurera sFrame så att det fungerar på flera paketenheter, till exempel hela ramar, för att ytterligare minska krypteringskostnaderna.

Att ställa in en hemlig nyckel bland en grupp när gruppen bara har tillgång till en opålitlig kanal verkar magiskt. Tekniker för att göra detta utvecklades först på 1980-talet, och idag använder mer än 90 procent av webbsurfningen Transport Layer Security (TLS) för att göra exakt detta. Messaging Layer Security (MLS) utökar den här funktionen till grupper, medan TLS bara fungerar punkt till punkt, så Webex kan använda MLS för att ställa in konferensnycklar även när konferensleverantören inte är betrodd.

MLS tillhandahåller tre kritiska säkerhetsfunktioner:

1. Delad nyckel — Nyckeln är endast känd för autentiserade gruppmedlemmar.
2. Kon sekvens — Säkerställer att alla medlemmar har en konsekvent bild av grupplistan.
3. Rotation — Uppdaterar nycklar automatiskt när en medlem går med eller lämnar.

Den första funktionen ger oss nycklarna vi använder för att kryptera media med SFrame. Tillsammans med den andra funktionen utgör den utgångspunkten för E2E-identitet. Den tredje funktionen säkerställer att de enda personer som kan dekryptera media är de personer som är i mötet just nu - du kan inte dekryptera media från innan du gick med eller efter att du lämnade (eller sparkades ut).

För att åstadkomma allt detta utbyter klienterna i ett möte MLS-meddelanden vid kritiska punkter i mötet för att upprätthålla en MLS-grupp som innehåller exakt deltagarna i mötet när som helst. Webex dirigerar meddelandena mellan klienterna, men MLS skyddar dessa meddelanden så att det är säkert för Webex att hantera dem. Figur 7 visar hur meddelandena flyter.

Skapande: Den första personen som går med i mötet, värd eller inte, skapar MLS-gruppen för mötet och blir ”ledare” för MLS ändamål. Vid varje given tidpunkt utses en enda deltagare i mötet som ledare. I de flesta fall kommer denna deltagare att vara mötesvärd. När sessionen startas försäkrar MLS att varje mötesdeltagare har kryptografisk information för att fungera som ledare; Webex utser helt enkelt en ledare för att undvika förvirring.

Gå med: När en ny deltagare vill gå med i mötet ber de att släppas in genom att skicka ett MLS-nyckelpaketmeddelande till ledaren, som tillhandahåller deras offentliga nyckel och autentiseringsinformation. Ledaren svarar med ett välkomstmeddelande som berättar snickaren om de andra deltagarna i mötet. Ledaren sänder också ett Lägg till meddelande och ett Commite-meddelande till gruppen. Meddelandet Lägg till meddelar den nya kopplaren till de som redan är med i mötet. Meddelandet Commit gör att alla aktuella deltagare hashar den gamla gruppnyckeln för att få en ny nyckel för den nu utökade gruppen. Välkomstmeddelandet ger den här nyckeln till sammanfogaren.

Lämna: När någon lämnar mötet är det ledarens jobb att låsa ut dem. Ledaren gör detta genom att sända MLS Remove and Committ-meddelanden till alla som är kvar i mötet. Meddelandet Ta bort berättar för de återstående deltagarna som lämnade, och Commit krypterar en ny nyckel till alla återstående deltagare men inte till personen som lämnade. De återstående deltagarna hashar den nya nyckeln med den gamla gruppnyckeln för att få en nyckel som personen som lämnade inte har. Om deltagaren som lämnade är ledaren utser Webex en ny ledare och den nya ledaren tar bort den gamla ledaren.

Nyckelrotation kan innebära att det tar några extra sekunder att gå med i ett möte eller ta bort någon, men det ger tydlig säkerhetsgaranti: om någon inte visas i mötesdeltagarlistan har de inte nycklarna för att dekryptera innehållet.

Deltagarlistan i ett E2E-krypterat möte visar identitetsverifieringen för varje användare. Användning av kundutgivna identitetscertifikat ger sann E2E-verifierad identitet i den meningen att Cisco inte kan manipulera med den. I dessa fall visar deltagarlistan domänen som deltagaren tillhör i blå text. I mötet som visas i figur 8 kan du till exempel se att Kevin har en verifierad e-postadress från example.com och Isabella har en verifierad e-postadress från company.com.

Identitetscertifikat utfärdade av en WebexCertificate Authority, till exempel en videoenhetsidentitet, ger ett mer begränsat skydd. Endast en angripare som äventyrar Webex Certificate Authority kan utge sig för att vara en användare. Även om detta är bättre än att inte ha något identitetsskydd alls, är sådana deltagare i mötet inte markerade med blått som Zero Trust end-to-end-identitetsverifierad. De visas med grå text för att indikera Webex-förtroendeidentitetsverifiering.

Som en backstop för dessa procedurer tillhandahåller Webex också en säkerhetskod för mötet. En säkerhetskod är en kort, mänskligt läsbar sträng beräknad som en utgång från MLS-processen. Säkerhetskoden sammanfattar mötesets kryptografiska tillstånd, inklusive gruppens nycklar och de certifikat som presenteras av deltagarna. Denna kod kan användas för att upptäcka en imitationsattack, eftersom en sådan attack skulle resultera i att minst en deltagare har ett annat kryptografiskt tillstånd än alla andra. Men det utesluter bara efterlikning om alla verifierar att de har samma kod. Om någon delmängd av deltagarna verifierar att de har samma kod, vet de att deras identiteter är troget representerade för varandra, men någon som inte bekräftar sin kod kunde ha efterliknats. Figur 9 visar ett exempel på hur säkerhetskoden visas i ett möte.

Denna kod ger ett mycket starkt försvar mot imitationsattacker. Det är en del av MLS-protokollet, så det har haft robust säkerhetsanalys. Eftersom den är tätt bunden till mötets tillstånd ändras säkerhetskoden varje gång någon ansluter sig till mötet. Som ett resultat måste deltagarna i mötet verifiera sina säkerhetskoder varje gång någon ansluter sig. Koden roterar inte när någon lämnar, för att lämna kan inte introducera en imitator.

Webex Zero Trust Security lanserades 2021. År 2026 introducerade Ultra Secure Webex-möten stöd för ytterligare slutpunkter i E2E-krypterade Webex-möten, fullt utrustade Zero Trust E2EE-möten med Video Mesh Node (VMN) och end-to-end-krypterings- och identitetsfunktioner för standardmöten:

• Standardbaserad, formellt verifierad kryptografi
• Zero Trust E2E-kryptering
• Zero Trust E2E verifierad identitet
• Stöd för alla Webex-enheter tillgängliga för försäljning
• Stöd för Webex-appen på dator, mobil och webb
• Stöd för Webex webbapp och Web SDK (planerat för Q1CY27)
• Stöd för Webex Calling telefoner (planerat för Q3CY26)
• Stöd för Video Mesh Node
• Stöd för E2E-kryptering i schemalagda möten och personliga mötesrum

Zero Trust har vissa begränsningar. E2E-krypterade möten stöder inte:

• Funktioner som tillhandahålls av Ciscos molntjänster som kräver åtkomst till klartextmedia, inklusive:
  • Webex molnbaserad inspelning och AI Assistant tjänster. Dessa tjänster kan tillhandahållas med hjälp av hybriddistributioner med Video Mesh Node (VMN).
  • Spara möteschatt, filer, whiteboards och anteckningar.
  • PSTN- eller SIP-interoperabilitet.

Framöver kommer Webex att förbättra E2E-krypterade möten i några få dimensioner, styrda av principerna för att ge molnet minsta behörighet som krävs och ge kunderna kontroll över sina data.

Allestädes närvarande E2E-säkerhet: Allt ska vara E2E-säkert, inte bara utvalda möten. Det första steget för att uppnå denna vision har nåtts med E2E-säkerhet för Webex Web App och molnanslutna Cisco-telefoner. Så småningom bör den öppna, standardbaserade E2E-arkitekturen göra det möjligt för Webex att också ta in SIP-infrastruktur (Session Initiation Protocol).

De innovationer som diskuteras i detta dokument visar en tydlig väg till den långsiktiga visionen om alltid påslagen E2E-kryptering. När användare kan ansluta var som helst och kunder säkert kan välja de funktioner de vill ha i ett möte, kan E2E-kryptering användas för varje Webex-möte - från informella ad hoc-möten med alla funktioner aktiverade, hela vägen upp till låsta möten med hög säkerhet. E2E-kryptering kommer alltid att säkerställa att mötesinnehållet endast är tillgängligt för auktoriserade deltagare, och kunder och användare bestämmer vilken uppsättning deltagare som är rätt för ett visst möte.

AI-aktiverad imitering och deepfake-motståndskraft

Webex hanterar AI-aktiverade hot om personifiering genom ett skiktat tillvägagångssätt som kompletterar Zero Trust end-to-end-krypteringsmodellen. Medan detta dokument fokuserar på de tekniska grunderna för verifierad identitet från början till slut, inklusive kundtillhandahållen certifikatbaserad verifiering och möteskryptografiska integritetskontroller, tillhandahåller Webex också operativa säkerhetskontroller i mötesupplevelsen för att minska risken för obehörig åtkomst och skadliga interaktioner.

För mötessessionstyper, säkerhetsskillnader i schemalagda möten kontra personliga mötesrum, värd- och administratörskontroller i Control Hub och ytterligare identifiering och förebyggande av AI och deepfake i den bredare mötesupplevelsen, se det kompletterande tekniska dokumentet för WSMP Meetings Security.

Webex definierar framtiden för säkra möten genom standardbaserad kryptografi och verifierad identitet. Engagemanget för ett öppet ekosystem säkerställer att kunderna behåller absolut kontroll över sina data, oavsett mötesscenario.