Takk for tilbakemeldingen.

Millioner av brukere globalt stoler på Webex for sikkert samarbeid. Webex fungerer som en pålitelig plattform for kritisk kommunikasjon, fra bedriftsstyrerom og offentlige lovgivningsmøter til sensitive lege-pasientkonsultasjoner.

Ettersom etterspørselen etter fjernarbeid vokser, øker også behovet for robuste, konfidensielle samarbeidsverktøy. Webex har adressert dette behovet lenger enn noen annen leverandør. Med fremveksten av AI-aktivert etterligning og sofistikerte deepfake-trusler, er kravet om identitetsverifisert, policydrevet samarbeid avgjørende. For våre kunder er sikkerhet ikke bare en funksjon — det er en integrert komponent i hele møtets livssyklus, som dekker planlegging, deltakeridentitet og innholdsbeskyttelse.

Webex har en lang historie med å støtte sterk ende-til-ende-kryptering (E2EE). Vår Webex Zero Trust Security-modell utvikler denne arven gjennom tre hovedpilarer:

• Etablere et fundament for standardbasert, formelt verifisert kryptografi
• Forbedrer ende-til-ende-kryptering med ende-til-ende-verifisert identitet
• Utvide støtte til nåværende Webex-enheter så vel som Webex-appen

Denne tekniske artikkelen gir bakgrunn om ende-til-ende-sikkerhet og legger ut det tekniske grunnlaget for hvordan WebExZero Trust Security fungerer. For driftssikkerhet for møter, for eksempel møteøkttyper, sikkerhetsforskjeller mellom planlagte møter kontra personlige møterom, administrator- og vertskontroller, deling og oppbevaring av møteinnhold, og bredere AI og deepfake-motstandskraft i møteopplevelsen, se det medfølgende tekniske dokumentet for WSMP-møtesikkerhet.

18 års erfaring med å levere på E2E-sikkerhet

Webex var banebrytende for E2E-kryptering for møter i 2008. Per definisjon sikrer E2E-sikkerhet at innholdet er kryptert fra det øyeblikket det sendes til det vises av mottakeren, og forhindrer skyleverandøren eller tredjepart i å få tilgang til eller tukle med dataene.

Avhengig av hvor mye investering en videokonferanseleverandør gjør i E2E-sikkerhetsmekanismer, kan de gi varierende beskyttelsesnivåer, som vist i figur 1. Enhver E2E-sikkerhet er bedre enn bare kryptering i transitt og i ro.

Beskyttelsesnivå	Nettverksangripere	Passive angrep (avlytting)	Aktive angrep (etterligning)	Eksempler
Kryptering i transitt og i ro	Ja	Nei	Nei	Ikke-E2EE-apper
E2E-kryptering	Ja	Ja	Nei	Eldre E2EE- og forbrukerapper
E2E-kryptering og E2E-identitet	Ja	Ja	Ja	Webex Zero Trust Sikkerhet

De fleste applikasjoner som hevder å gi E2E-sikkerhet gir bare beskyttelse mot passive angrep. Bare passiv beskyttelse er fortsatt verdifull fordi de gjør det slik at dårlige skuespillere bare kan avlytte et møte mens det pågår. Den beste tilnærmingen, derimot, er å beskytte mot både passive og aktive angrep, der konferanseleverandøren selv kan late som å være en legitim deltaker for å delta i møtet. For dette er det nødvendig med et E2E-identitetslag i tillegg til E2E-kryptering.

Med Zero Trust Security gir Webex sterkere kryptografi til møter og utvider ende-til-ende-kryptering med ende-til-ende-verifisert identitet for å holde møter trygge mot hele spekteret av angrep.

Før du dykker ned i tekniske detaljer, er det nyttig å forstå brukeropplevelsen. For å opprette et E2E-kryptert møte velger verten riktig møtetype under planlegging i Webex-appen (figur 2).

Når deltakerne blir med, ser de et «skjold med lås» -ikon som indikerer at møtet er E2E-kryptert (figur 3). Hvis du trykker på dette ikonet, får du informasjon om møtets beskyttelse.

Til slutt, i møtedeltakerlisten, angir Webex-applikasjonen om deltakerens identitet er bekreftet på en E2E-sikker måte - det vil si om noen andre enn Cisco har gått god for deltakerens identitet (figur 4).

Deltakerne kan også sjekke at de alle har samme sikkerhetskode for å bekrefte at de alle har samme visning av møtet, og dermed er sikre mot etterligningsangrep. I distribusjoner som bruker kundeleverte ende-til-ende-identitetssertifikater, gir listetilstanden åpenhet om identitetssikring.

Zero Trust Security er bygget på bransjestandard kryptografiske protokoller, som Cisco driver sammen med andre ledere innen sikkerhet og personvern, inkludert Google, Cloudflare, Wickr og Wire. Cisco ledet den første generasjonen av sikker Voice over IP (VoIP) med teknologier som Secure Real-Time Protocol (SRTP), DTLS-SRTP, STIR/SHAKEN og WebRTC, og Cisco gjør det samme med Zero Trust Security (figur 5).

Lag	I dag	Null tillitssikkerhet
Identitet	SSO (SAML, OpenID)	X.509-sertifikat
Nøkkelutveksling	SDES/DTLS	Meldingslagssikkerhet (MLS)
Mediekryptering	SRTP	Sikre rammer (sFrame)

Det er i utgangspunktet tre lag i systemet, og på hvert lag tar vi den gamle hop-by-hop-teknologien og styrker den med et ekstra lag fra ende til ende med beskyttelse. De tre lagene inkluderer:

• Identitet—E2E-identitet krever at klienter har legitimasjon som beviser identiteten deres. Med Zero Trust E2E Identity blir klientens legitimasjon gitt av en Webex Independent. Certificate Authority
• Nøkkelutveksling — Klienter som deltar i et E2E-møte må konfigurere nøkler for E2E-kryptering uten at konferanseleverandøren har tilgang til disse nøklene. MLS-protokollen (Messaging Layer Security) er en ratifisert standard, RFC 9420, som bygger på teknologier utviklet i åpen kildekode-fellesskap og setter dem i en streng, formelt verifisert setting.
• Innholdsbeskyttelse — Til slutt, det faktiske medieinnholdet i møtet trenger ende-til-ende-beskyttelse. SFrame (for «Secure Frames») er RFC 9605. Det er et raskt og enkelt krypteringsrammeverk for kryptering av sanntidsmedier, som gjør at et ekstra lag med kryptering kan legges til med minimal overhead.

La oss se på disse teknologiene litt mer detaljert, fra bunnen opp.

En mediekrypteringsordning er en måte å ta en nøkkel som deles av deltakerne i et møte, og bruke den til å beskytte det faktiske innholdet som deles i møtet, for eksempel lyd, video og skjermdeling. På protokollnivå må krypteringsordningen sende ekstra informasjon med hver enhet av krypterte data, viktigst av alt:

1. En overskrift som forteller mottakeren hvordan den skal dekryptere pakken, og
2. En autentiseringsmerke som mottakeren bruker for å bekrefte at pakken ikke har blitt tuklet med.

For eksempel, i SRTP, er krypteringsenheten en RTP-pakke; SRTP er avhengig av RTP-overskriften for oppsettet og legger til en autentiseringskode til slutten av pakken.

Siden all denne ekstra informasjonen øker båndbredden som kreves for et E2E-kryptert møte, gir SFrame den minimale mengden innramming som er nødvendig. SFrame-overskriften indikerer hvilken nøkkel som skal brukes, muliggjør nøkkelrotasjon, og gir et unikt sekvensnummer som definerer initialiseringsvektoren. Dette etterfølges av innholdet kryptert med E2E-nøkkelen og en autentiseringsmerke. SFrame-overskriften, innholdet og taggen blir deretter pakket inn i en SRTP-pakke, slik at SRTP beskytter mot inspeksjon eller modifikasjon av nettverksangripere, og SFrame beskytter mot konferanseleverandørens medieelementer (se eksempel i figur 6).

Denne minimalistiske tilnærmingen har andre fordeler. SFrame er uavhengig av den underliggende transporten, så den er fremoverkompatibel med nye teknologier som RTP over QUIC og RIPT. Det er også mulig å konfigurere SFrame slik at den fungerer på flerpakkeenheter, for eksempel hele rammer, for ytterligere å redusere krypteringsomkostninger.

Å sette opp en hemmelig nøkkel blant en gruppe når gruppen bare har tilgang til en ukjent kanal virker magisk. Teknikker for å gjøre dette ble først utviklet på 1980-tallet, og i dag bruker mer enn 90 prosent av nettlesingen Transport Layer Security (TLS) for å gjøre akkurat dette. Messaging Layer Security (MLS) utvider denne funksjonaliteten til grupper, mens TLS bare fungerer punkt til punkt, slik at Webex kan bruke MLS til å konfigurere konferansenøkler selv når konferanseleverandøren ikke er klarert.

MLS gir tre kritiske sikkerhetsfunksjoner:

1. Delt nø kkel — Nøkkelen er bare kjent for godkjente gruppemedlemmer.
2. Konsist ens — Sikrer at alle medlemmer har et konsistent syn på gruppelisten.
3. Rotasjon — Oppdaterer taster automatisk når et medlem blir med eller forlater.

Den første funksjonen gir oss nøklene vi bruker til å kryptere medier med SFrame. Sammen med den andre funksjonen gir den utgangspunktet for E2E-identitet. Den tredje funksjonen sikrer at de eneste personene som kan dekryptere media er personene som er i møtet akkurat nå — du kan ikke dekryptere medier fra før du ble med eller etter at du dro (eller ble sparket ut).

For å oppnå alt dette utveksler klientene i et møte MLS-meldinger på kritiske punkter i møtet for å opprettholde en MLS-gruppe som inneholder nøyaktig deltakerne i møtet når som helst. Webex ruter meldingene mellom klientene, men MLS beskytter disse meldingene slik at det er trygt for Webex å håndtere dem. Figur 7 viser hvordan meldingene flyter.

Oppre ttelse: Den første personen som blir med i møtet, vert eller ikke, oppretter MLS-gruppen for møtet og blir «leder» for MLS-formål. På et gitt tidspunkt er en enkelt deltaker i møtet utpekt som leder. I de fleste tilfeller vil denne deltakeren være møteverten. Når økten er startet, forsikrer MLS at hver møtedeltaker har kryptografisk informasjon for å fungere som leder; Webex utpeker ganske enkelt en leder for å unngå forvirring.

Bli med: Når en ny deltaker ønsker å bli med i møtet, ber de om å bli sluppet inn ved å sende en MLS Key Package-melding til lederen, som gir deres offentlige nøkkel og godkjenningsinformasjon. Lederen svarer med en velkomstmelding som forteller snekkeren om de andre deltakerne i møtet. Lederen sender også en Legg til-melding og en Committ-melding til gruppen. Meldingen Legg til kunngjør den nye sammenføleren til de som allerede er i møtet. Committ-meldingen får alle nåværende deltakere til å hashe den gamle gruppenøkkelen for å få en ny nøkkel for den nå utvidede gruppen. Velkomstmeldingen gir denne nøkkelen til sammenføyeren.

Av reise: Når noen forlater møtet, er det lederens jobb å låse dem ute. Lederen gjør dette ved å kringkaste MLS Remove and Committ-meldinger til alle som er igjen i møtet. Meldingen Fjern forteller de gjenværende deltakerne som dro, og Commit krypterer en ny nøkkel til alle gjenværende deltakere, men ikke til personen som dro. De resterende deltakerne hasher den nye nøkkelen med den gamle gruppenøkkelen for å få en nøkkel som personen som dro ikke har. Hvis deltakeren som dro er lederen, utpeker Webex en ny leder og den nye lederen fjerner den gamle lederen.

Nøkkelrotasjon kan bety at det tar et par ekstra sekunder å bli med i et møte eller fjerne noen, men det gir tydelig sikkerhetsforsikring: Hvis noen ikke vises i deltakerlisten for møtet, har de ikke nøklene til å dekryptere innholdet.

Deltakerlisten i et E2E-kryptert møte viser identitetsbekreftelsen til hver bruker. Bruk av kundeutstedte identitetssertifikater gir ekte E2E-verifisert identitet i den forstand at Cisco ikke kan tukle med den. I disse tilfellene viser deltakerlisten domenet som deltakeren tilhører i blå tekst. I møtet vist i figur 8 kan du for eksempel se at Kevin har en bekreftet e-postadresse fra example.com, og Isabella har en bekreftet e-postadresse fra company.com.

Identitetssertifikater utstedt av en WebexCertificate Authority, for eksempel en videoenhetsidentitet, gir mer begrenset beskyttelse. Bare en angriper som kompromitterer Webex, Certificate Authority kan utgi seg for å være en bruker. Selv om dette er bedre enn å ikke ha noen identitetsbeskyttelse i det hele tatt, er slike deltakere i møtet ikke merket med blått som Zero Trust ende-til-ende-identitetsverifisert. De vises med grå tekst for å indikere Webex-tillitsidentitetsbekreftelse.

Som en sikkerhetskopi for disse prosedyrene gir Webex også en sikkerhetskode for møtet. En sikkerhetskode er en kort, menneskelesbar streng beregnet som en utgang fra MLS-prosessen. Sikkerhetskoden oppsummerer den kryptografiske tilstanden til møtet, inkludert gruppens nøkler og sertifikatene presentert av deltakerne. Denne koden kan brukes til å oppdage et etterligningsangrep, fordi et slikt angrep vil resultere i at minst en deltaker har en annen kryptografisk tilstand enn alle andre. Men det utelukker bare etterligning hvis alle bekrefter at de har samme kode. Hvis noen delsett av deltakerne bekrefter at de har samme kode, vet de at identiteten deres er trofast representert for hverandre, men noen som ikke bekrefter koden deres, kan ha blitt etterlignet. Figur 9 viser et eksempel på hvordan sikkerhetskoden vises i et møte.

Denne koden gir et veldig sterkt forsvar mot etterligningsangrep. Det er en del av MLS-protokollen, så den har hatt robust sikkerhetsanalyse. Fordi den er tett bundet til møtets tilstand, endres sikkerhetskoden hver gang noen blir med i møtet. Som et resultat, deltakerne i møtet må bekrefte sikkerhetskodene sine på nytt hver gang noen blir med. Koden roterer ikke når noen drar, fordi det å forlate ikke kan introdusere en etterligner.

Webex Zero Trust Security ble lansert i 2021. I 2026 introduserte Ultra Secure Webex-møter støtte for flere endepunkter i E2E-krypterte Webex-møter, fullt utstyrte Zero Trust E2EE-møter med Video Mesh Node (VMN) og ende-til-ende-kryptering og identitetsfunksjoner for standardmøter:

• Standardbasert, formelt verifisert kryptografi
• Zero Trust E2E-kryptering
• Zero Trust E2E verifisert identitet
• Støtte for alle Webex-enheter tilgjengelig for salg
• Støtte for Webex-appen på datamaskin, mobil og web
• Støtte for Webex webapp og Web SDK (planlagt for Q1CY27)
• Støtte for Webex Calling telefoner (planlagt for Q3CY26)
• Støtte for Video Mesh Node
• Støtte for E2E-kryptering i planlagte møter og personlige møterom

Zero Trust har noen begrensninger. E2E-krypterte møter støtter ikke:

• Funksjoner levert av Ciscos skytjenester som krever tilgang til klartekstmedier, inkludert:
  • Webex skybasert opptak og AI Assistant tjenester. Disse tjenestene kan leveres ved hjelp av hybriddistribusjoner med Video Mesh Node (VMN).
  • Lagre møtechat, filer, tavler og merknader.
  • PSTN eller SIP interoperabilitet.

Fremover vil Webex forbedre E2E-krypterte møter i noen få dimensjoner, styrt av prinsippene om å gi skyen minst mulig privilegium og gi kundene kontroll over dataene sine.

Allestedsnærværende E2E-sikkerhet: Alt skal være E2E-sikkert, ikke bare utvalgte møter. Det første trinnet for å oppnå denne visjonen er nådd med E2E-sikkerhet for Webex Web App og skytilkoblede Cisco-telefoner. Til slutt bør den åpne, standardbaserte E2E-arkitekturen gjøre det mulig for Webex å bringe inn SIP-infrastruktur (Session Initiation Protocol) også.

Innovasjonene diskutert i denne artikkelen viser en klar vei til den langsiktige visjonen om alltid på E2E-kryptering. Når brukere kan koble seg fra hvor som helst og kundene sikkert kan velge funksjonene de ønsker i et møte, kan E2E-kryptering brukes for hvert Webex-møte - fra uformelle ad hoc-møter med alle funksjoner slått på, helt opp til låste møter med høy sikkerhet. E2E-kryptering vil alltid sikre at møtets innhold bare er tilgjengelig for autoriserte deltakere, og kunder og brukere vil bestemme hvilket sett med deltakere som er riktig for et gitt møte.

AI-aktivert etterligning og deepfake-resiliens

Webex adresserer AI-aktiverte etterligningstrusler gjennom en lagdelt tilnærming som utfyller Zero Trust ende-til-ende-krypteringsmodellen. Mens denne artikkelen fokuserer på det tekniske grunnlaget for ende-til-ende-verifisert identitet, inkludert kundelevert sertifikatbasert verifisering og møte kryptografiske integritetskontroller, gir Webex også operasjonelle sikkerhetskontroller i møteopplevelsen for å redusere risikoen for uautorisert tilgang og skadelige interaksjoner.

For møteøkttyper, sikkerhetsforskjeller i planlagte møter kontra personlige møterom, verts- og administratorkontroller i Control Hub, og ytterligere oppdagelse og forebygging av AI og deepfake i den bredere møteopplevelsen, se det medfølgende tekniske dokumentet for WSMP Meetings Security.

Webex definerer fremtiden for sikre møter gjennom standardbasert kryptografi og verifisert identitet. Forpliktelsen til et åpent økosystem sikrer at kundene opprettholder absolutt kontroll over dataene sine, uavhengig av møtescenariet.