Tak for din feedback.

Millioner af brugere globalt er afhængige af Webex for sikkert samarbejde. Fra virksomhedsbestyrelseslokaler og regeringssessioner til følsomme læge-patientkonsultationer fungerer Webex som en betroet platform til kritisk kommunikation.

Efterhånden som efterspørgslen efter fjernarbejde vokser, vokser behovet for robuste, fortrolige samarbejdsværktøjer også. Webex har løst dette behov længere end nogen anden leverandør. Med fremkomsten af AI-aktiveret efterligning og sofistikerede deepfake-trusler er kravet om identitetsverificeret, politikdrevet samarbejde altafgørende. For vores kunder er sikkerhed ikke blot en funktion — det er en integreret komponent i hele mødets livscyklus, der dækker planlægning, deltageridentitet og indholdsbeskyttelse.

Webex har en lang historie med at understøtte stærk ende-til-ende-kryptering (E2EE). Vores Webex Zero Trust Security-model udvikler denne arv gennem tre primære søjler:

• Etablering af et fundament for standardbaseret, formelt verificeret kryptografi
• Udvidelse af end-to-end-kryptering med ende-til-ende-verificeret identitet
• Udvidelse af support til aktuelle Webex-enheder samt Webex App

Dette tekniske papir giver baggrund om end-to-end-sikkerhed og beskriver det tekniske grundlag for, hvordan WebExZero Trust Security fungerer. For mødeoperationel sikkerhed, f.eks. mødesessionstyper, sikkerhedsforskelle mellem planlagte møder versus personlige mødelokaler, administrator- og værtskontrol, deling og opbevaring af mødeindhold og bredere AI og deepfake-modstandsdygtighed i mødeoplevelsen, se det ledsagende tekniske dokument om WSMP-mødesikkerhed.

18 års erfaring med levering af E2E-sikkerhed

Webex var banebrydende for E2E-kryptering til møder i 2008. Per definition sikrer E2E-sikkerhed, at indhold krypteres fra det øjeblik, det sendes, indtil det vises af modtageren, hvilket forhindrer cloud-udbyderen eller enhver tredjepart i at få adgang til eller manipulere med dataene.

Afhængigt af hvor meget investering en videokonferenceudbyder foretager i E2E-sikkerhedsmekanismer, kan de give forskellige beskyttelsesniveauer, som vist i figur 1. Enhver E2E-sikkerhed er bedre end kun kryptering under transit og i hvile.

Beskyttelsesniveau	Netværksangribere	Passive angreb (aflytning)	Aktive angreb (efterligning)	Eksempler
Kryptering under transit og i hvile	Ja	Nej	Nej	Ikke-E2EE-apps
E2E-kryptering	Ja	Ja	Nej	Ældre E2EE- og forbrugerapps
E2E-kryptering og E2E-identitet	Ja	Ja	Ja	Webex Zero Trust-sikkerhed

De fleste applikationer, der hævder at give E2E-sikkerhed, giver kun beskyttelse mod passive angreb. Kun passiv beskyttelse er stadig værdifuld, fordi de gør det sådan, at dårlige skuespillere kun kan aflytte et møde, mens det pågår. Den bedste tilgang er dog at beskytte mod både passive og aktive angreb, hvor konferenceudbyderen selv kan foregive at være en legitim deltager til at deltage i mødet. Til dette er der brug for et E2E-identitetslag ud over E2E-kryptering.

Med Zero Trust Security bringer Webex stærkere kryptografi til møder og udvider end-to-end-kryptering med ende-til-ende-verificeret identitet for at hjælpe med at holde møder sikre mod hele spektret af angreb.

Før du dykker ned i tekniske detaljer, er det nyttigt at forstå brugeroplevelsen. For at oprette et E2E-krypteret møde vælger værten den relevante mødetype under planlægningen i Webex App (figur 2).

Når deltagerne deltager, ser de et „skjold med lås“ -ikon, der angiver, at mødet er E2E-krypteret (figur 3). Hvis du trykker på dette ikon, får du oplysninger om mødets beskyttelse.

Endelig angiver Webex-applikationen på mødedeltagerlisten, om deltagerens identitet er blevet verificeret på en E2E-sikker måde - det vil sige, om en anden end Cisco har garanteret deltagerens identitet (figur 4).

Deltagerne kan også kontrollere, at de alle har den samme sikkerhedskode for at bekræfte, at de alle har den samme visning af mødet, og dermed er sikre mod efterligningsangreb. I implementeringer, der bruger kundeleverede ende-til-ende-identitetscertifikater, giver listetilstanden gennemsigtighed om identitetssikring.

Zero Trust Security er bygget på branchestandard kryptografiske protokoller, som Cisco driver sammen med andre ledere inden for sikkerhed og privatliv, herunder Google, Cloudflare, Wickr og Wire. Cisco førte den første generation af sikker Voice over IP (VoIP) med teknologier som Secure Real-Time Protocol (SRTP), DTLS-SRTP, STIR/SHAKEN og WebRTC, og Cisco gør det samme med Zero Trust Security (figur 5).

Lag	I dag	Nul tillidssikkerhed
Identitet	SSO (SAML, OpenID)	X.509-certifikat
Nøgleudveksling	SDES/DTLS	Beskedlagssikkerhed (MLS)
Mediekryptering	SRTP	Sikre rammer (sFrame)

Der er dybest set tre lag i systemet, og ved hvert lag tager vi den gamle hop-by-hop teknologi og styrker den med et ekstra lag beskyttelse fra ende til ende. De tre lag omfatter:

• Identitet—E2E-identitet kræver, at klienter har legitimationsoplysninger, der beviser deres identitet. Med Zero Trust E2E Identity leveres klienternes legitimationsoplysninger af en Webex Independent. Certificate Authority
• Nøgleudveksling — Kunder, der deltager i et E2E-møde, skal konfigurere nøgler til E2E-kryptering, uden at konferenceudbyderen har adgang til disse nøgler. MLS-protokollen (Messaging Layer Security) er en ratificeret standard, RFC 9420, der bygger på teknologier udviklet i open source-samfundet og sætter dem i en streng, formelt verificeret indstilling.
• Indholdsbeskyttelse — Endelig har det faktiske medieindhold på mødet brug for ende-til-ende-beskyttelse. SFrame (for „Secure Frames“) er RFC 9605. Det er en hurtig og enkel krypteringsramme til kryptering af realtidsmedier, som gør det muligt at tilføje et ekstra lag kryptering med minimal overhead.

Lad os se på disse teknologier lidt mere detaljeret, startende fra bunden op.

Et mediekrypteringsskema er en måde at tage en nøgle, der deles af deltagerne i et møde, og bruge den til at beskytte det faktiske indhold, der deles i mødet, f.eks. lyd, video og skærmdeling. På protokolniveau skal krypteringsordningen sende ekstra information med hver enhed af krypterede data, vigtigst af alt:

1. En header, der fortæller modtageren, hvordan man dekrypterer pakken, og
2. Et godkendelsesmærke, som modtageren bruger til at kontrollere, at pakken ikke er blevet manipuleret med.

For eksempel er krypteringsenheden i SRTP en RTP-pakke; SRTP er afhængig af RTP-overskriften til dens opsætning og tilføjer et godkendelsestag til slutningen af pakken.

Da al denne ekstra information øger den båndbredde, der kræves til et E2E-krypteret møde, giver SFrame den minimale mængde indramning, der er nødvendig. SFrame-overskriften angiver, hvilken nøgle der skal bruges, hvilket giver mulighed for nøglerotation, og giver et unikt sekvensnummer, der definerer initialiseringsvektoren. Dette efterfølges af indholdet krypteret med E2E-nøglen og et godkendelsesmærke. SFrame-overskriften, indholdet og tagget pakkes derefter ind i en SRTP-pakke, så SRTP beskytter mod inspektion eller ændring af netværksangribere, og SFrame beskytter mod konferenceudbyderens medieelementer (se eksempel i figur 6).

Denne minimalistiske tilgang har andre fordele. SFrame er uafhængig af den underliggende transport, så den er fremadkompatibel med nye teknologier som RTP over QUIC og RIPT. Det er også muligt at konfigurere SFrame, så det fungerer på multi-pakkeenheder, såsom hele rammer, for yderligere at reducere krypteringsomkostningerne.

Oprettelse af en hemmelig nøgle blandt en gruppe, når gruppen kun har adgang til en ikke-betroet kanal, virker magisk. Teknikker til at gøre dette blev først udviklet i 1980'erne, og i dag bruger mere end 90 procent af webbrowsing Transport Layer Security (TLS) til at gøre netop dette. Messaging Layer Security (MLS) udvider denne funktionalitet til grupper, mens TLS kun fungerer punkt til punkt, så Webex kan bruge MLS til at konfigurere konferencenøgler, selv når konferenceudbyderen ikke har tillid til.

MLS indeholder tre kritiske sikkerhedsfunktioner:

1. Delt nø gle — Nøglen er kun kendt af godkendte gruppemedlemmer.
2. Konsist ens — Sikrer, at alle medlemmer har et ensartet overblik over gruppeplanen.
3. Rotation — Opdaterer automatisk nøgler, når et medlem slutter sig til eller forlader.

Den første funktion giver os de nøgler, vi bruger til at kryptere medier med SFrame. Sammen med den anden funktion giver det udgangspunktet for E2E-identitet. Den tredje funktion sikrer, at de eneste personer, der kan dekryptere medierne, er de personer, der er i mødet lige nu - du kan ikke dekryptere medier fra før du tilmeldte dig, eller efter du forlod (eller blev smidt ud).

For at opnå alt dette udveksler klienterne i et møde MLS-meddelelser på kritiske punkter i mødet for at opretholde en MLS-gruppe, der indeholder nøjagtigt deltagerne i mødet til enhver tid. Webex dirigerer meddelelserne mellem klienterne, men MLS beskytter disse meddelelser, så det er sikkert for Webex at håndtere dem. Figur 7 viser, hvordan meddelelserne flyder.

Opre ttelse: Den første person, der deltager i mødet, vært eller ej, opretter MLS-gruppen til mødet og bliver „leder“ med henblik på MLS. På et givet tidspunkt udpeges en enkelt deltager i mødet som leder. I de fleste tilfælde vil denne deltager være mødevært. Når sessionen er startet, forsikrer MLS, at hver mødedeltager har de kryptografiske oplysninger til at fungere som leder; Webex udpeger simpelthen en leder for at undgå forvirring.

Del@@ tag: Når en ny deltager ønsker at deltage i mødet, beder de om at blive sluppet ind ved at sende en MLS Key Package-meddelelse til lederen, som giver deres offentlige nøgle og godkendelsesoplysninger. Lederen svarer med en velkomstbesked, der fortæller snedkeren om de andre deltagere i mødet. Lederen sender også en Tilføj besked og en Commit-meddelelse til gruppen. Meddelelsen Tilføj annoncerer den nye samarbejder til dem, der allerede er i mødet. Meddelelsen Commit får alle aktuelle deltagere til at hash den gamle gruppenøgle for at få en ny nøgle til den nu udvidede gruppe; velkomstmeddelelsen giver denne nøgle til sammenføjeren.

Forlad: Når nogen forlader mødet, er det lederens opgave at låse dem ude. Lederen gør dette ved at sende MLS Remove and Commit-meddelelser til alle, der er tilbage i mødet. Meddelelsen Fjern fortæller de resterende deltagere, der forlod, og Commit krypterer en ny nøgle til alle resterende deltagere, men ikke til den person, der forlod. De resterende deltagere hasher den nye nøgle med den gamle gruppenøgle for at få en nøgle, som den person, der forlod, ikke har. Hvis den deltager, der forlod, er lederen, udpeger Webex en ny leder, og den nye leder fjerner den gamle leder.

Nøglerotation kan betyde, at det tager et par ekstra sekunder at deltage i et møde eller fjerne nogen, men det giver en klar sikkerhedsgaranti: Hvis nogen ikke vises på mødets deltagerliste, har de ikke nøglerne til at dekryptere indholdet.

Deltagerlisten i et E2E-krypteret møde viser identitetsbekræftelsen af hver bruger. Brug af kundeudstedte identitetscertifikater giver ægte E2E-verificeret identitet i den forstand, at Cisco ikke kan manipulere med den. I disse tilfælde viser deltagerlisten det domæne, som deltageren tilhører, i blå tekst. I mødet vist i figur 8 kan du f.eks. se, at Kevin har en bekræftet e-mail-adresse fra example.com, og Isabella har en bekræftet e-mail-adresse fra company.com.

Identitetscertifikater udstedt af en WebexCertificate Authority, såsom en videoenhedsidentitet, giver mere begrænset beskyttelse. Kun en angriber, der kompromitterer Webex, Certificate Authority kan efterligne en bruger. Selvom dette er bedre end at have nogen identitetsbeskyttelse overhovedet, er sådanne deltagere i mødet ikke markeret med blåt som Zero Trust end-to-end-identitetsverificeret. De vises med grå tekst for at angive Webex-tillidsidentitetsbekræftelse.

Som en backstop til disse procedurer giver Webex også en sikkerhedskode til mødet. En sikkerhedskode er en kort, menneskelæsbar streng beregnet som et output fra MLS-processen. Sikkerhedskoden opsummerer mødets kryptografiske tilstand, herunder gruppens nøgler og certifikaterne præsenteret af deltagerne. Denne kode kan bruges til at registrere et efterligningsangreb, fordi et sådant angreb ville resultere i, at mindst en deltager har en anden kryptografisk tilstand end alle andre. Men det udelukker kun efterligning, hvis alle verificerer, at de har den samme kode. Hvis en undergruppe af deltagerne bekræfter, at de har den samme kode, ved de, at deres identiteter er trofast repræsenteret over for hinanden, men en person, der ikke bekræfter deres kode, kunne have været efterlignet. Figur 9 viser et eksempel på, hvordan sikkerhedskoden vises i et møde.

Denne kode giver et meget stærkt forsvar mod efterligningsangreb. Det er en del af MLS-protokollen, så den har haft robust sikkerhedsanalyse. Da den er tæt knyttet til mødets tilstand, ændres sikkerhedskoden, hver gang nogen deltager i mødet. Som følge heraf skal deltagerne i mødet bekræfte deres sikkerhedskoder igen, hver gang nogen deltager. Koden roterer ikke, når nogen forlader, fordi afgang ikke kan introducere en efterligner.

Webex Zero Trust Security blev lanceret i 2021. I 2026 introducerede Ultra Secure Webex-møder understøttelse af yderligere slutpunkter i E2E-krypterede Webex-møder, fuldt udstyrede Zero Trust E2EE-møder med Video Mesh Node (VMN) og end-to-end-krypterings- og identitetsfunktioner til standardmøder:

• Standardbaseret, formelt verificeret kryptografi
• Zero Trust E2E-kryptering
• Zero Trust E2E verificeret identitet
• Support til alle Webex-enheder, der er tilgængelige til salg
• Understøttelse af Webex App på computer, mobil og web
• Understøttelse af Webex Web app og Web SDK (planlagt til Q1CY27)
• Støtte til Webex Calling telefoner (planlagt til Q3CY26)
• Understøttelse af Video Mesh Node
• Understøttelse af E2E-kryptering i planlagte møder og personlige mødelokaler

Zero Trust har nogle begrænsninger. E2E-krypterede møder understøtter ikke:

• Funktioner leveret af Ciscos cloud-tjenester, der kræver adgang til almindelige tekstmedier, herunder:
  • Webex skybaseret optagelse og AI Assistant tjenester. Disse tjenester kan leveres ved hjælp af hybrid-implementeringer med Video Mesh Node (VMN).
  • Gemmer mødechat, filer, whiteboards og annotationer.
  • PSTN- eller SIP-interoperabilitet.

Fremadrettet vil Webex forbedre E2E-krypterede møder i nogle få dimensioner, styret af principperne om at give skyen det mindst nødvendige privilegium og give kunderne kontrol over deres data.

Allestedsnærværende E2E-sikkerhed: Alt skal være E2E-sikkert, ikke kun udvalgte møder. Det første skridt til at nå denne vision er nået med E2E-sikkerhed til Webex Web App og cloud-forbundne Cisco-telefoner. Til sidst skal den åbne, standardbaserede E2E-arkitektur gøre det muligt for Webex også at indføre SIP-infrastruktur (Session Initiation Protocol).

De innovationer, der diskuteres i dette papir, viser en klar vej til den langsigtede vision om altid tændt E2E-kryptering. Når brugerne kan oprette forbindelse hvor som helst, og kunderne sikkert kan tilmelde sig de funktioner, de ønsker i et møde, kan E2E-kryptering bruges til hvert Webex-møde - fra uformelle ad hoc-møder med alle funktioner slået til, helt op til låste møder med høj sikkerhed. E2E-kryptering vil altid sikre, at mødets indhold kun er tilgængeligt for autoriserede deltagere, og kunder og brugere beslutter, hvilket sæt deltagere der er det rigtige for et givet møde.

AI-aktiveret efterligning og deepfake-modstandsdygtighed

Webex adresserer AI-aktiverede efterligningstrusler gennem en lagdelt tilgang, der supplerer Zero Trust ende-til-ende-krypteringsmodellen. Mens dette papir fokuserer på det tekniske grundlag for ende-til-ende-verificeret identitet, herunder kundeleveret certifikatbaseret verifikation og møde af kryptografisk integritetskontrol, leverer Webex også operationelle sikkerhedskontroller i mødeoplevelsen for at reducere risikoen for uautoriseret adgang og skadelige interaktioner.

For mødesessionstyper, sikkerhedsforskelle i planlagte møder versus personlige mødelokaler, værts- og administratorkontroller i Control Hub og yderligere AI- og deepfake-registrering og forebyggelse i den bredere mødeoplevelse, se det ledsagende tekniske dokument om WSMP Meetings Security.

Webex definerer fremtiden for sikre møder gennem standardbaseret kryptografi og verificeret identitet. Forpligtelsen til et åbent økosystem sikrer, at kunderne bevarer absolut kontrol over deres data, uanset mødescenariet.