10. oktober 2026 | 1153 visning(er) | 0 personer mente dette var nyttig
Implementere null-tillitsmøter
list-menuTilbakemelding?
Zero-Trust Security fra Webex gir ende-til-ende-kryptering og sterk identitetsbekreftelse i planlagte og personlige rommøter.

Brukeropplevelse

Brukere velger møtetypen når de planlegger et møte. Når du tar imot deltakere fra lobbyen, så vel som under møtet, kan verten se identitetsbekreftelsesstatusen til hver deltaker. Det er også en møtekode som er felles for alle nåværende deltakere i møtet, som de kan bruke til å bekrefte at møtet deres ikke har blitt avlyttet av et uønsket tredjeparts Meddler In The Middle (MITM) -angrep.

Del følgende informasjon med møtevertene dine:

Identitetsbekreftelse med intern eller ekstern CA

Bekreft identitet

Ende-til-ende-kryptering med identitetsbekreftelse gir ekstra sikkerhet til et ende-til-ende-kryptert møte.

Når deltakere eller enheter blir med i en delt MLS-gruppe (Messaging Layer Security), presenterer de sertifikatene sine for de andre gruppemedlemmene, som deretter validerer sertifikatene mot de utstedende sertifikatmyndighetene (CA). Ved å bekrefte at sertifikatene er gyldige, bekrefter CA identiteten til deltakerne, og møtet viser deltakerne/enhetene som bekreftet.

Webex App-brukere autentiserer seg mot Webex-identitetslageret, som gir dem et tilgangstoken når godkjenningen lykkes. Hvis de trenger et sertifikat for å bekrefte identiteten sin i et ende-til-ende-kryptert møte, utsteder Webex CA dem et sertifikat basert på tilgangstoken. For øyeblikket tilbyr vi ikke en måte for Webex Meetings brukere å få et sertifikat utstedt av en tredjepart/ekstern CA.

Enheter kan autentisere seg selv ved hjelp av et sertifikat utstedt av den interne (Webex) CA, eller et sertifikat utstedt av en ekstern CA:

  • Intern CA — WebEx utsteder et internt sertifikat basert på tilgangstoken til enhetens maskinkonto. Sertifikatet er signert av Webex CA. Enheter har ikke bruker-ID-er på samme måte som brukere har, så Webex bruker (ett av) organisasjonens domener når du skriver enhetssertifikatets identitet (Common Name (CN)).

  • Ekstern CA — be om og kjøp enhetssertifikater direkte fra den valgte utstederen. Du må kryptere, laste opp og autorisere sertifikatene direkte ved hjelp av en hemmelighet som bare er kjent for deg.

    Cisco er ikke involvert, noe som gjør dette til en måte å garantere ekte ende-til-ende-kryptering og verifisert identitet, og forhindre den teoretiske muligheten for at Cisco kan avlytte møtet/dekryptere mediene dine.

Internt utstedt enhetssertifikat

Webex utsteder et sertifikat til enheten når den registrerer seg etter oppstart, og fornyer det når det er nødvendig. For enheter inkluderer sertifikatet konto-ID og et domene.

Hvis organisasjonen ikke har et domene, utsteder Webex CA sertifikatet uten et domene.

Hvis organisasjonen har flere domener, kan du bruke Control Hub til å fortelle Webex hvilket domene enheten skal bruke for identiteten. Du kan også bruke API XConfiguration Conference EndToEndEncryption Identity PreferredDomain: «example.com».

Hvis du har flere domener og ikke angir det foretrukne domenet for enheten, velger Webex ett for deg.

Eksternt utstedt enhetssertifikat

En administrator kan klargjøre en enhet med sitt eget sertifikat som er signert med en av de offentlige CA-ene.

Sertifikatet må være basert på et ECDSA P-256-nøkkelpar, selv om det kan signeres av en RSA-nøkkel.

Verdiene i sertifikatet er etter organisasjonens skjønn. Vanlig navn (CN) og Subject Alternative Name (SAN) vises i Webex-møtebrukergrensesnittet, som beskrevet i Ende-til-ende-kryptering med identitetsbekreftelse for Webex Meetings.

Vi anbefaler at du bruker et eget sertifikat per enhet og å ha en unik CN per enhet. For eksempel «meeting-room-1.example.com» for organisasjonen som eier «example.com» -domenet.

For å beskytte det eksterne sertifikatet mot manipulering, brukes en klient-hemmelig funksjon for å kryptere og signere forskjellige xkommandoer.

Når du bruker klientens hemmelighet, er det mulig å administrere det eksterne Webex-identitetssertifikatet på en sikker måte via xAPI. Dette er for øyeblikket begrenset til elektroniske enheter.

Webex tilbyr for øyeblikket API-kommandoer for å administrere dette.

Funksjoner og begrensninger

Enheter

Skyregistrerte Cisco Board-, Desk- og Room Series-enheter kan delta i E2EE-møter.

Følgende enheter kan ikke delta i E2EE-møter:

  • Tredjeparts SIP-enheter

Programvareklienter

  • Webex-appen for stasjonære og mobile klienter kan delta i E2EE-møter.

  • Webex-nettklienten kan ikke delta i E2EE-møter.

  • Tredjeparts SIP-myke klienter kan ikke delta i E2EE-møter.

Identitet

  • Av design tilbyr vi ikke Control Hub-alternativer for deg å administrere eksternt verifisert enhetsidentitet. For ekte ende-til-ende-kryptering, bør bare du kjenne/få tilgang til hemmelighetene og nøklene. Hvis vi introduserte en skytjeneste for å administrere disse nøklene, er det en sjanse for at de blir avlyttet.

  • For øyeblikket tilbyr vi en «oppskrift» for deg for å designe dine egne verktøy, basert på bransjestandard krypteringsteknikker, for å hjelpe deg med å be om eller kryptere enhetens identitetssertifikater og deres private nøkler. Vi ønsker ikke å ha noen reell eller opplevd tilgang til dine hemmeligheter eller nøkler.

Møter

  • E2EE-møter støtter i dag maksimalt 1000 deltakere.

  • Du kan dele nye tavler i E2EE-møter. Det er noen forskjeller fra tavler i vanlige møter:
    • I E2EE-møter kan ikke brukere få tilgang til tavler som er opprettet utenfor møtet, inkludert private tavler, tavler delt av andre og tavler fra Webex-områder.
    • Tavler opprettet i E2EE-møter er bare tilgjengelige under møtet. De lagres ikke og er ikke tilgjengelige etter at møtet er avsluttet.
    • Hvis noen deler innhold i et E2EE-møte, kan du kommentere det. Hvis du vil ha mer informasjon om merknader, kan du se Webex App | Merk delt innhold med merknader.

Administrasjonsgrensesnitt

Vi anbefaler på det sterkeste at du bruker Control Hub til å administrere møteområdet, ettersom Control Hub-organisasjoner har sentralisert identitet for hele organisasjonen.

Tilleggsressurser
Forutsetninger

  • Webex Meetings41.7.

  • Skyregistrerte Cisco Board-, Desk- og Room Series-enheter, som kjører 10.6.1- RoomOS_August_2021 eller nyere.

  • Administrativ tilgang til møteområdet i Control Hub.

  • Ett eller flere bekreftede domener i Control Hub-organisasjonen (hvis du bruker Webex CA til å utstede enhetssertifikater for bekreftet identitet).

  • Møterom for samarbeid må være slått på slik at folk kan bli med fra videosystemet sitt. Hvis du vil ha mer informasjon, kan du se Tillat videosystemer å delta i møter og arrangementer på Webex-området.

Få enhetssertifikater

Du kan hoppe over dette trinnet hvis du ikke trenger eksternt verifiserte identiteter.

For det høyeste sikkerhetsnivået og for identitetsbekreftelse, bør hver enhet ha et unikt sertifikat utstedt av en klarert offent Certificate Authority lighet (CA).

Du må samhandle med CA for å be om, kjøpe og motta digitale sertifikater og opprette tilknyttede private nøkler. Når du ber om sertifikatet, bruk disse parametrene:

  • Sertifikatet må utstedes og signeres av en kjent offentlig CA.

  • Unik: Vi anbefaler på det sterkeste å bruke et unikt sertifikat for hver enhet. Hvis du bruker ett sertifikat for alle enheter, kompromitterer du sikkerheten din.

  • Vanlig navn (CN) og Subject Alternative Name/s (SAN/s): Disse er ikke viktige for Webex, men bør være verdier som mennesker kan lese og knytte til enheten. CN vises for andre møtedeltakere som den primære bekreftede identiteten til enheten, og hvis brukere inspiserer sertifikatet gjennom møtegrensesnittet, vil de se SAN/s. Det kan være lurt å bruke navn som name.model@example.com.

  • Filformat: Sertifikatene og nøklene må være i .pem-formatet.

  • Formål: Sertifikatformålet må være Webex Identity.

  • Generering av nøkler: Sertifikatene må være basert på ECDSA P-256-nøkkelpar (Elliptical Curve Digital Signature Algorithm som bruker P-256-kurven).

    Dette kravet gjelder ikke signeringsnøkkelen. CA kan bruke en RSA-nøkkel til å signere sertifikatet.

Forbered deg på innebygde enheter

Du kan hoppe over dette trinnet hvis du ikke vil bruke eksternt verifisert identitet med enhetene dine.

Hvis du bruker nye enheter, må du ikke registrere dem på Webex ennå. For å være trygg, ikke koble dem til nettverket på dette tidspunktet.

Hvis du har eksisterende enheter som du vil oppgradere for å bruke eksternt verifisert identitet, må du tilbakestille enhetene til fabrikkinnstillinger.

  • Lagre den eksisterende konfigurasjonen hvis du vil beholde den.

  • Planlegg et vindu når enhetene ikke brukes, eller bruk en trinnvis tilnærming. Gi brukerne beskjed om endringene de kan forvente.

  • Sikre fysisk tilgang til enheter. Hvis du må få tilgang til enheter over nettverket, vær oppmerksom på at hemmeligheter reiser i ren tekst, og at du kompromitterer sikkerheten din.

Når du har fullført disse trinnene, la videosystemer delta i møter og arrangementer på Webex-nettstedet ditt.

Forstå den eksterne identitetsprosessen for enheter

For å sikre at enhetsmediet ikke kan krypteres av andre enn enheten, må du kryptere den private nøkkelen på enheten. Vi designet API-er for enheten for å muliggjøre administrasjon av den krypterte nøkkelen og sertifikatet, ved hjelp av JSON Web Encryption (JWE).

For å sikre ekte ende-til-ende-kryptering gjennom skyen vår, kan vi ikke være involvert i å kryptere og laste opp sertifikatet og nøkkelen. Hvis du trenger dette sikkerhetsnivået, må du:

  1. Be om sertifikatene dine.

  2. Generer nøkkelpar for sertifikatene dine.

  3. Opprett (og beskytt) en innledende hemmelighet for hver enhet, for å sette sammen enhetens krypteringsevne.

  4. Utvikle og vedlikeholde ditt eget verktøy for kryptering av filer ved hjelp av JWE-standarden.

    Prosessen og de (ikke-hemmelige) parametrene du trenger er forklart nedenfor, samt en oppskrift du kan følge i utviklingsverktøyene du velger. Vi gir også noen testdata og de resulterende JWE-blobene slik vi forventer dem, for å hjelpe deg med å bekrefte prosessen din.

    En ikke-støttet referanseimplementering ved bruk av Python3 og JWCrypto-biblioteket er tilgjengelig fra Cisco på forespørsel.

  5. Konkatener og krypter sertifikatet og nøkkelen ved hjelp av verktøyet og enhetens opprinnelige hemmelighet.

  6. Last opp den resulterende JWE-bloben til enheten.

  7. Angi formålet med det krypterte sertifikatet som skal brukes for Webex-identitet, og aktiver sertifikatet.

  8. (Anbefalt) Gi et grensesnitt til (eller distribuere) verktøyet ditt for å gjøre det mulig for enhetsbrukere å endre den opprinnelige hemmeligheten og beskytte mediene sine mot deg.

Hvordan vi bruker JWE-formatet

Denne delen beskriver hvordan vi forventer at JWE skal opprettes som input til enhetene, slik at du kan bygge ditt eget verktøy for å lage blobene fra sertifikatene og nøklene dine.

Se JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 og JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Vi bruker Compact Serialization av et JSON-dokument for å lage JWE-blobs. Parametrene du må ta med når du oppretter JWE-blobs er:

  • JOSE Header (beskyttet). I JSON-objektsignering og krypteringsoverskriften MÅ du inkludere følgende nøkkelverdipar:

    • «alg» :"dir»

      Den direkte algoritmen er den eneste vi støtter for å kryptere nyttelasten, og du må bruke enhetens første klienthemmelighet.

    • «enc» :"A128GCM» eller «enc» :"A256GCM»

      Vi støtter disse to krypteringsalgoritmene.

    • «cisco-action»: «legg til» eller «cisco-handling»: «populere» eller «cisco-handling»: «aktiver» eller «cisco-handling»: «deaktiver»

      Dette er en proprietær nøkkel og fire verdier den kan ta. Vi introduserte denne nøkkelen for å signalisere formålet med de krypterte dataene til målenheten. Verdiene er oppkalt etter xAPI-kommandoene på enheten der du bruker de krypterte dataene.

      Vi kalte det cisco-action for å dempe potensielle sammenstøt med fremtidige JWE-utvidelser.

    • «cisco-kdf»: {«versjon»: «1", «salt»: «base64URLEncodeDrandom4+byte»}

      En annen proprietær nøkkel. Vi bruker verdiene du oppgir som innganger for nøkkelavledning på enheten. Versjonen må være 1 (versjonen av vår nøkkelavledningsfunksjon). Verdien av salt må være en base64 URL-kodet sekvens på minst 4 byte, som du må velge tilfeldig.

  • JWE kryptert nøkkel. Dette feltet er tomt. Enheten henter den fra den opprinnelige ClientSecret.

  • JWE Initialiseringsvektor. Du må oppgi en base64url-kodet initialiseringsvektor for dekryptering av nyttelasten. IV MÅ være en tilfeldig verdi på 12 byte (vi bruker AES-GCM-chifferfamilien, som krever at IV er 12 byte lang).

  • JWE AAD (tilleggsgodkjente data). Du må utelate dette feltet fordi det ikke støttes i Compact Serialization.

  • JWE Ciphertext: Dette er den krypterte nyttelasten du vil holde hemmelig.

    Nyttelasten KAN være tom. For eksempel, for å tilbakestille klientens hemmelighet, må du overskrive den med en tom verdi.

    Det finnes forskjellige typer nyttelast, avhengig av hva du prøver å gjøre på enheten. Ulike xAPI-kommandoer forventer forskjellige nyttelaster, og du må spesifisere formålet med nyttelasten med cisco-action-nøkkelen, som følger:

    • Med «cisco-action» :"populate» er chifferteksten den nye ClientSecret.

    • Med "«cisco-action» :"add» er chifferteksten en PEM-blob som bærer sertifikatet og dets private nøkkel (sammenkoblet).

    • Med "«cisco-action» :"activate» er chifferteksten fingeravtrykket (heksadesimal representasjon av sha-1) til sertifikatet vi aktiverer for verifisering av enhetsidentitet.

    • Med "«cisco-action» :"deaktiver» er chifferteksten fingeravtrykket (heksadesimal representasjon av sha-1) til sertifikatet vi deaktiverer fra å bli brukt til enhetsidentitetsverifisering.

  • JWE-autentiseringskoden: Dette feltet inneholder autentiseringskoden for å fastslå integriteten til hele JWE-kompakt serialiserte blob

Hvordan vi utleder krypteringsnøkkelen fra ClientSecret

Etter den første populasjonen av hemmeligheten godtar eller sender vi ikke ut hemmeligheten som ren tekst. Dette er for å forhindre potensielle ordbokangrep fra noen som kunne få tilgang til enheten.

Enhetsprogramvaren bruker klientens hemmelighet som en inngang til en nøkkelavledningsfunksjon (kdf) og bruker deretter den avledede nøkkelen for dekryptering/kryptering av innhold på enheten.

Hva dette betyr for deg er at verktøyet ditt for å produsere JWE-blobs må følge samme prosedyre for å utlede den samme kryptering/dekrypteringsnøkkelen fra klientens hemmelighet.

Enhetene bruker scrypt for nøkkelavledning (se https://en.wikipedia.org/wiki/Scrypt), med følgende parametere:

  • CostFactor (N) er 32768

  • BlockSizeFactor (r) er 8

  • ParallelizationFactor (p) er 1

  • Salt er en tilfeldig sekvens på minst 4 byte; du må levere det samme saltet når du spesifiserer cisco-kd f-parameteren.

  • Nøkkellengder er enten 16 byte (hvis du velger AES-GCM 128-algoritmen), eller 32 byte (hvis du velger AES-GCM 256-algoritmen)

  • Maks minnehette er 64 MB

Dette settet med parametere er den eneste konfigurasjonen av scrypt som er kompatibel med nøkkelavledningsfunksjonen på enhetene. Denne kdf på enhetene kalles «versjon»: «1", som er den eneste versjonen som for øyeblikket er tatt av cisco-kdf-parameteren.

Fungert eksempel

Her er et eksempel som du kan følge for å bekrefte at JWE-krypteringsprosessen din fungerer på samme måte som prosessen vi opprettet på enhetene.

Eksempelscenariet er å legge til en PEM-blob til enheten (etterligner å legge til et sertifikat, med en veldig kort streng i stedet for en full cert +-nøkkel). Klienthemmeligheten i eksemplet er ossifrage.

  1. Velg en krypteringskryptering. Dette eksemplet bruker A128GCM (AES med 128-biters nøkler i Galois-tellermodus). Verktøyet ditt kan bruke A256GCM hvis du foretrekker det.

  2. Velg et salt (må være en tilfeldig sekvens på minst 4 byte). Dette eksemplet bruker (heksagbyte) E5 E6 53 08 03 F8 33 F 6. Base64URL koder sekvensen for å få 5eztcap4 m_y (fjern base64-polstring).

  3. Her er et eksempel på et scrypt-anrop for å lage innholdskrypteringsnøkkelen (cek):

    cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

    Den avledede nøkkelen skal være 16 byte (hex) som følger: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac som base64url koder til LZ66BDeiaqv4_mqdinj_ra.

  4. Velg en tilfeldig sekvens på 12 byte som skal brukes som en initialiseringsvektor. Dette eksemplet bruker (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 som base64url koder til nLnd3v9TE68tkpwd.

  5. Lag JOSE-overskriften med kompakt serialisering (følg samme rekkefølge av parametere vi bruker her) og deretter koder base64url den:

    {"alg» :"dir», "cisco-action» :"add», "cisco-kdf»: {"salt» :"5eztcap4M_y», "versjon» :"1"}, "enc» :"A128GCM "}

    Den base64url-kodede JOSE-overskriften er EyjhbGcioIJkAxiiLcJjaXnJBY1hy3rpb24ioiJhzgqILcJjaXnjby1rzGyionSiC2fsdCi6ijVlWLrdqVA0tV9ziiWIDmVyc2LvBii6iJEifsWiZw5jiJoiqTeYoEddTSj9

    Dette vil være det første elementet i JWE-bloben.

  6. Det andre elementet i JWE-bloben er tomt, fordi vi ikke leverer en JWE-krypteringsnøkkel.

  7. Det tredje elementet i JWE-bloben er initialiseringsvektoren nLnd3v9TE68tkpwd.

  8. Bruk JWE-krypteringsverktøyet til å produsere en kryptert nyttelast og tag. For dette eksemplet vil den ukrypterte nyttelasten være den falske PEM-bloben, dette er en PEM-fil

    Krypteringsparametrene du bør bruke er:

    • Nyttelast er dette er en PEM-fil

    • Krypteringskryptering er AES 128 GCM

    • Den base64url-kodede JOSE-overskriften som tilleggsautentiserte data (AAD)

    Base64URL koder den krypterte nyttelasten, noe som skal resultere i F5llVUWNfkfmzyco1yjFODHQ

    Dette er det fjerde elementet (JWE Ciphertext) i JWE-bloben.

  9. Base64URL koder taggen du produserte i trinn 8, noe som skal resultere i PE-Wdfwgxffbeo928cfz1q

    Dette er det femte elementet i JWE-bloben.

  10. Sammenkoble de fem elementene i JWE-bloben med prikker (JoseHeader.. iv.CipherText.tag) for å få:

    EYJhbgCIoIJkAXiiLCJaxnjbY1hy3rpb24ioiJhzgQiLcJjaXnJbY1rzGYiOnSiC2fsdCi6ijVLrdQva0tV9ZiiWiDMvYc2LvBiI6iJiIFsWiZw5jiJoiqtEYoeddTSj.. 9nLnd3v9TE68pWlLd.f5JiJoiqtEYoEDDtSj.. 9nLnd3v9TE68pWlLd.f5tKf5jIjOIQtEYoEDDtSj.. VUWNfkfmzyco1yjfodhq.pe-wdfwgxffbeo928cfz1q

  11. Hvis du utledet de samme base64url-kodede verdiene som vi viser her, ved hjelp av dine egne verktøy, er du klar til å bruke dem til å sikre E2E-kryptering og verifisert identitet på enhetene dine.

  12. Dette eksemplet fungerer faktisk ikke, men i prinsippet vil ditt neste trinn være å bruke JWE-bloben du opprettet ovenfor som inngang til xcommand på enheten som legger til sertifikatet:

    XCommand sikkerhetssertifikater Legg til eyJhbgCIoIJkaxiiLcJjaXnjby1hy3rpb24ioiJhzgQiLCJjaXnjby1rzGyionSiC2fsdci6iJvLwLrdQva0tV9ziiWIDmVyC2LvBiI6iJiIFsWiZw5jiJoiqTeyOeDdDtSj.. 9nLnND3v9Tk68TkJ.. pwd. f5llVUwNfkfmzyco1yjfodhq.pe-wdfwg xffbeo928cfz1q

Økttyper for null-tillitsmøter er tilgjengelige for alle møteområder uten ekstra kostnad. En av disse sesjonstypene kalles Pro-End to End Encryption_ VoipOnly. Dette er det offentlige tjenestenavnet, som vi kan endre i fremtiden. Hvis du vil ha gjeldende navn på økttypene, kan du se Øktstype-ID- er i Refer ansedelen i denne artikkelen.

Det er ingenting du trenger å gjøre for å få denne muligheten for nettstedet ditt; du må gi den nye økttypen (også kalt møteprivilegium) til brukere. Du kan gjøre dette individuelt via brukerens konfigurasjonsside, eller i bulk med en CSV-eksport/import.

Bekreft den nye økttypen
1

Logg på Control Hub, og gå til T jenester > Møte.

2

Klikk Nettsteder, velg Webex-området du vil endre innstillingene for, og klikk deretter Inn stillinger.

3

Under Vanlige innstillinger velger du Økttyper.

Du bør se én eller flere ende-til-ende-krypteringsøkttyper. Se listen over øktstype-ID-er i Referanse delen i denne artikkelen. Du kan for eksempel se Pro-End to End Encryption_ VoipOnly.

Det er en eldre sesjonstype med et veldig likt navn: Pro-End to End Encryption. Denne økttypen inkluderer ikke-kryptert PSTN-tilgang til møter. Forsikre deg om at du har _VoipOnly- versjonen for å sikre ende-til-ende-kryptering. Du kan sjekke ved å holde musepekeren over PRO- koblingen i øktkodekolonnen. For dette eksemplet bør målet for koblingen være JavaScript :ShowFeature (652).

Vi kan endre navnene på offentlige tjenester for disse sesjonstypene i fremtiden.

4

Hvis du ikke har den nye økttypen ennå, kontakter du Webex-representanten din.

Hva du skal gjøre videre

Aktiver denne økttype/møteretten for noen eller alle brukerne dine.

Aktiver E2EE-møter for individuelle brukere
1

Logg på Control Hub, og gå til Administrasjon > Brukere.

2

Velg en brukerkonto du vil oppdatere, og velg deretter Møter.

3

Velg møteområdet du vil oppdatere, fra rullegardinlisten Innstillinger gjelder for.

4

Merk av i boksen ved siden av Pro-End to End Encryption_ VoipOnly.

5

Lukk brukerkonfigurasjonspanelet.

6

Gjenta for andre brukere om nødvendig.

Hvis du vil tilordne dette til mange brukere, bruker du det neste alternativet, Aktiver E2EE-møter for flere brukere.

Aktiver E2EE-møter for flere brukere
1

Logg på Control Hub, og gå til T jenester > Møte.

2

Klikk Nettsteder, velg Webex-området du vil endre innstillingene for.

3

Klikk Masse administrasjon i Lisenser og bruker e-seksjonen.

4

Klikk Generer rapport, og vent mens vi forbereder filen.

5

Når filen er klar, klikker du på Eksporter resultater og deretter Last ned. (Du må lukke popup-vinduet manuelt etter at du har klikket Last ned.)

6

Åpne den nedlastede CSV-filen for redigering.

Det er en rad for hver bruker, og MeetingPrivil ege-kolonnen inneholder deres sesjonstype-ID-er som en kommaavgrenset liste.

7

For hver bruker du ønsker å gi den nye økttypen, legger du til 1561 som en ny verdi i den kommaavgrensede listen i MeetingPrivilege-cellen.

Webex CSV File Format Reference inneholder detaljer om formålet med og innholdet i CSV-filen.

8

Åpne konfigurasjonspanelet for møtestedet i Control Hub.

Hvis du allerede var på listesiden for møteområde, må du kanskje oppdatere den.

9

Klikk Masse administrasjon i Lisenser og bruker e-seksjonen.

10

Klikk på Importer og velg den redigerte CSV-en, og klikk deretter på Importer. Vent mens filen lastes opp.

11

Når importen er ferdig, kan du klikke Importer resultater for å se om det oppstod feil.

12

Gå til Bruker e- siden og åpne en av brukerne for å bekrefte at de har den nye økttypen.

Legg til et lydvannmerke for sikkerhet

Du kan legge til et vannmerke i møteopptak med økttypen Webex MeetingsPro-End to End Encryption_VoipOnly, som lar deg identifisere kildeklienten eller enheten til uautoriserte opptak av konfidensielle møter.

Når denne funksjonen er aktivert, inneholder møtelyden en unik identifikator for hver deltakende klient eller enhet. Du kan laste opp lydopptak til Control Hub, som deretter analyserer opptaket og slår opp de unike identifikatorene. Du kan se på resultatene for å se hvilken kildeklient eller enhet som tok opp møtet.

  • For å bli analysert må opptaket være en AAC-, MP3-, M4A-, WAV-, MP4-, AVI- eller MOV-fil som ikke er større enn 500 MB.
  • Opptaket må være lengre enn 100 sekunder.
  • Du kan bare analysere opptak for møter som er vert for personer i organisasjonen.
  • Vannmerkeinformasjon beholdes i samme varighet som organisasjonens møteinformasjon.

Legg til lydmerker i E2EE-møter

  1. Logg på Control Hub, og velg deretter Organisasjonsinnstillinger under Administ rasjon.
  2. I delen Vannmerker for møte, slå på Legg til lydvannmerke.

    Noen ganger etter at dette er slått på, ser brukere som planlegger møter med økttypen Webex Meetings Pro-End to End Encryption_VoipOnly et alternativ for digital vannmerking i delen Sikkerhet.

Last opp og analyser et vannmerket møte

  1. Velg Feilsøking under Over våking i Control Hub.
  2. Klikk Vannmerkeanalyse.
  3. Søk etter eller velg møtet i listen, og klikk deretter Analyser.
  4. Skriv inn et navn for analysen i vinduet Analyser lydvannmerke.
  5. (Valgfritt) Skriv inn et notat for analysen.
  6. Dra og slipp lydfilen som skal analyseres, eller klikk Velg fil for å bla til lydfilen.
  7. Klikk Lukk.

    Når analysen er fullført, vises den i listen over resultater på siden Analyser vannmerke.

  8. Velg møtet i listen for å se resultatene av analysen. Klikk Download button for å laste ned resultatene.

Funksjoner og begrensninger

Faktorer involvert i vellykket dekoding av et innspilt vannmerke inkluderer avstanden mellom opptaksenheten og høyttaleren som sender ut lyden, volumet av den lyden, miljøstøy, etc. Vannmerketeknologien vår har ekstra fleksibilitet til å bli kodet flere ganger, som kan skje når media deles.

Denne funksjonen er utformet for å muliggjøre vellykket dekoding av vannmerkeidentifikatoren under et bredt, men rimelig sett med omstendigheter. Målet vårt er at en opptaksenhet, for eksempel en mobiltelefon, som ligger på et skrivebord i nærheten av et personlig endepunkt eller bærbar klient, alltid skal lage et opptak som resulterer i en vellykket analyse. Når opptaksenheten flyttes bort fra kilden, eller blir skjult for å høre hele lydspekteret, reduseres sjansene for en vellykket analyse.

For å kunne analysere et opptak, er det nødvendig med en rimelig opptak av møtelyden. Hvis lyden fra et møte er spilt inn på den samme datamaskinen som er vert for klienten, bør begrensninger ikke gjelde.

Innebygde enheter (intern CA)

Hvis enhetene dine allerede er koblet til Control Hub-organisasjonen, og du vil bruke Webex CA til automatisk å generere identifiserende sertifikater, trenger du ikke tilbakestille enhetene til fabrikkinnstilling.

Denne prosedyren velger hvilket domene enheten bruker til å identifisere seg selv, og er bare nødvendig hvis du har flere domener i Control Hub-organisasjonen. Hvis du har mer enn ett domene, anbefaler vi at du gjør dette for alle enhetene dine som har «Cisco-verifisert» identitet. Hvis du ikke forteller Webex hvilket domene som identifiserer enheten, velges det automatisk, og det kan se feil ut for andre møtedeltakere.

Før du begynner

Hvis enhetene dine ennå ikke er påbygd, følger du Registrer en enhet for å Cisco Webex bruke API eller lokalt webgrensesnitt eller Cloud onboarding for Board, Desk og Room Series. Du bør også bekrefte domenet/domenene du vil bruke til å identifisere enhetene i Administrer domenene dine.

1

Logg på Control Hub, og velg Enh eter under Administ rasjon.

2

Velg en enhet for å åpne konfigurasjonspanelet.

3

Velg domenet du vil bruke til å identifisere denne enheten.

4

Gjenta for andre enheter.

Innebygde enheter (ekstern CA)

Før du begynner

  • Få et CA-signert sertifikat og en privat nøkkel i .pem- format for hver enhet.

  • Under kategorien Forbered, les emnet For stå ekstern identitetsprosess for enheter,

  • Forbered et JWE-krypteringsverktøy med hensyn til informasjonen der.

  • Forsikre deg om at du har et verktøy for å generere tilfeldige bytesekvenser av gitte lengder.

  • Forsikre deg om at du har et verktøy for å base64url kode byte eller tekst.

  • Forsikre deg om at du har en scrypt-implementering.

  • Forsikre deg om at du har et hemmelig ord eller en setning for hver enhet.

1

Fyll enhetens ClientSecret med en ren teksthemmelighet:

Første gang du fyller Hemmeligh eten, leverer du den i ren tekst. Derfor anbefaler vi å gjøre dette på den fysiske enhetskonsollen.

  1. Base64URL koder den hemmelige setningen for denne enheten.

  2. Åpne TShell på enheten.

  3. Kjør xcommand Security ClientSecret Populate Secret: «MdeYmzq1Njc4owfiY2rlzg»

    Eksempelkommandoen ovenfor fyller hemmeligheten med uttrykket 0 123456789abcdef. Du må velge din egen.

Enheten har sin første hemmelighet. Ikke glem dette; du kan ikke gjenopprette den og må tilbakestille enheten fra fabrikken for å starte på nytt.
2

Sammenkoble sertifikatet og den private nøkkelen:

  1. Bruk et tekstredigeringsprogram til å åpne.pem-filene, lim inn nøkkelbloben i sertifikatbloben og lagre den som en ny .pem-fil.

    Dette er nyttelastteksten du vil kryptere og legge i JWE-bloben din.

3

Opprett en JWE-blob som skal brukes som inngang til sertifikattilleggskommandoen:

  1. Lag en tilfeldig sekvens på minst 4 byte. Dette er saltet ditt.

  2. Utled en innholdskrypteringsnøkkel med scrypt-verktøyet ditt.

    For dette trenger du hemmeligheten, saltet og en nøkkellengde for å matche den valgte krypteringskrypteringen din. Det er noen andre faste verdier å levere (N = 32768, r = 8, p = 1). Enheten bruker samme prosess og verdier for å utlede den samme innholdskrypteringsnøkkelen.

  3. Lag en tilfeldig sekvens på nøyaktig 12 byte. Dette er initialiseringsvektoren din.

  4. Opprett en JOSE-overskrift, angi alg-, enc- og cisco-kdf- nøkler som beskrevet i For stå ekstern identitet sprosess for enheter. Sett «legg til» -handlingen ved å bruke nøkkelen: verdi «cisco-action» :"add» i JOSE-overskriften din (fordi vi legger sertifikatet til enheten).

  5. Base64URL koder JOSE-overskriften.

  6. Bruk JWE-krypteringsverktøyet ditt med den valgte krypteringen og base64url-kodet JOSE-overskriften for å kryptere teksten fra den sammenkoblede pem-filen.

  7. Base64URL koder for initialiseringsvektoren, den krypterte PEM-nyttelasten og godkjenningskoden.

  8. Konstruer JWE-blob som følger (alle verdier er base64url-kodet):

    JoseHeader.. initVector.encryptedPem.AuthTag

4

Åpne TShell på enheten og kjør kommandoen (multiline) add: 

xcommand Security Certificates Services Add IsEncrypted: True
your..JWE.str.ing\n
.\n
5

Bekreft at sertifikatet er lagt til ved å kjøre xcommand Security Certificates Services Show

Kopier fingeravtrykket til det nye sertifikatet.

6

Aktiver sertifikatet for formålet WebExIdentity:

  1. Les fingeravtrykket til sertifikatet, enten fra selve sertifikatet eller fra utdataene fra xcommand Security Certificates Services Show.

  2. Lag en tilfeldig sekvens på minst 4 byte, og base64url koder den sekvensen. Dette er saltet ditt.

  3. Utled en innholdskrypteringsnøkkel med scrypt-verktøyet ditt.

    For dette trenger du hemmeligheten, saltet og en nøkkellengde for å matche den valgte krypteringskrypteringen din. Det er noen andre faste verdier å levere (N = 32768, r = 8, p = 1). Enheten bruker samme prosess og verdier for å utlede den samme innholdskrypteringsnøkkelen.

  4. Lag en tilfeldig sekvens på nøyaktig 12 byte, og base64url koder den sekvensen. Dette er initialiseringsvektoren din.

  5. Opprett en JOSE-overskrift, angi alg-, enc- og cisco-kdf- nøkler som beskrevet i For stå ekstern identitet sprosess for enheter. Angi «aktiver» -handlingen ved å bruke nøkkelen:value «cisco-action» :"activate» i JOSE-overskriften din (fordi vi aktiverer sertifikatet på enheten).

  6. Base64URL koder JOSE-overskriften.

  7. Bruk JWE-krypteringsverktøyet ditt med valgt kryptering og base64url-kodet JOSE-overskriften for å kryptere sertifikatets fingeravtrykk.

    Verktøyet skal sende ut en 16 eller 32 byte sekvens, avhengig av om du valgte 128 eller 256 bit AES-GCM, og en autentiseringskode.

  8. base64URLEnkode det krypterte fingeravtrykket og godkjenningskoden.

  9. Konstruer JWE-blob som følger (alle verdier er base64url-kodet):

    JoseHeader.. initVector.encryptedfingerprint.AuthTag

  10. Åpne TShell på enheten og kjør følgende aktiveringskommando:

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"

Enheten har et kryptert, aktivt, CA-utstedt sertifikat, klar til å brukes til å identifisere det i ende-til-ende-krypterte Webex-møter.
7

Ombord enheten til Control Hub-organisasjonen.

Test ende-til-ende-kryptering med identitetsbekreftelse
1

Planlegg et møte av riktig type (Webex MeetingsPro-End to End Encryption_ VoipOnly).

Se Planlegge et Webex-møte med ende-til-ende-kryptering.

2

Bli med på møtet som vert, fra en Webex Meetings klient.

Se Bli med i et Webex-møte med ende-til-ende-kryptering.

3

Bli med i møtet fra en enhet som har identiteten bekreftet av Webex CA.

4

Som vert, kontroller at denne enheten vises i lobbyen med riktig identitetsikon.

Se Bli med i et Webex-møte med ende-til-ende-kryptering.

5

Bli med i møtet fra en enhet som har identiteten bekreftet av en ekstern CA.

6

Som vert, kontroller at denne enheten vises i lobbyen med riktig identitetsikon. Lær mer om identitetsikoner.

7

Bli med i møtet som en uautorisert møtedeltaker.

8

Som vert, bekreft at denne deltakeren vises i lobbyen med riktig identitetsikon.

9

Som vert, innrømme eller avvis personer/enheter.

10

Valider deltaker/enhetsidentiteter der det er mulig ved å sjekke sertifikatene.

11

Kontroller at alle i møtet ser den samme sikkerhetskoden for møtet.

12

Bli med på møtet med en ny deltaker.

13

Kontroller at alle ser den samme, nye møtesikkerhetskoden.

Angi omfang og forventninger

  • Skal du gjøre ende-til-ende-krypterte møter til standardmøtealternativet, eller aktivere det bare for noen brukere, eller la alle verter bestemme? Når du har bestemt deg for hvordan du skal bruke denne funksjonen, må du forberede brukerne som vil bruke den, spesielt med hensyn til begrensningene og hva du kan forvente i møtet.

  • Trenger du å sikre at verken Cisco eller noen andre kan dekryptere innholdet ditt eller utgi deg for å være enhetene dine? I så fall trenger du sertifikater fra en offentlig CA.

  • Hvis du har forskjellige nivåer av identitetsbekreftelse, kan du gi brukerne mulighet til å bekrefte hverandre med sertifikatstøttet identitet. Selv om det er omstendigheter der deltakerne kan fremstå som Uverifiserte, og deltakerne bør vite hvordan de skal sjekke, kan det hende at ubekreftede personer ikke er bedragere.

Identitetshåndtering

Hvis du bruker en ekstern sertifiseringsinstans til å utstede enhetssertifikatene, er det opp til deg å overvåke, oppdatere og bruke sertifikater på nytt.

Hvis du opprettet den første hemmeligheten, må du forstå at brukerne dine kanskje vil endre enhetens hemmelighet. Du må kanskje opprette et grensesnitt/distribuere et verktøy for å gjøre det mulig for dem å gjøre dette.

ID-er for sesjonstype
Tabell 1. Sesjonstype-ID-er for ende-til-ende-krypterte møter

Sesjonstype-ID

Navn på offentlig tjeneste

638

E2E-kryptering+bare VoIP

652

Pro-End til End-End-End-Encryption_VoipOnly

660

Pro 3 End-til-ende-kryptering_VoipOnly

E2E-kryptering+Identitet

672

Pro 3 Free50-End-til-ende-kryptering_VoipOnly

673

Utdanningsinstruktør E2E Encryption_VoipOnly

676

Broadworks Standard pluss ende-til-ende-kryptering

677

Broadworks Premium pluss ende-til-ende-kryptering

681

Schoology Free pluss ende-til-ende-kryptering

Relaterte XAPI-kommandoer

Disse tabellene beskriver API-kommandoer for Webex-enheter vi la til for ende-til-ende-krypterte møter og bekreftet identitet. Hvis du vil ha mer informasjon om hvordan du bruker API-en, kan du se Få tilgang til API for enheter i Board, Desk og Room Series.

Disse xAPI-kommandoene er bare tilgjengelige på enheter som enten er:

  • Registrert til Webex

  • Registrert lokalt og koblet til Webex med Webex Edge for enheter

Tabell 2. API-er på systemnivå for ende-til-ende-krypterte møter og verifisert identitet

API-anrop

Beskrivelse

XConfiguration Conference EndToEndEncryption Identity PreferredDomain: «example.com»

Denne konfigurasjonen gjøres når administratoren angir enhetens foretrukne domene fra Control Hub. Bare nødvendig hvis organisasjonen har mer enn ett domene.

Enheten bruker dette domenet når den ber om et sertifikat fra Webex CA. Domenet identifiserer deretter enheten.

Denne konfigurasjonen gjelder ikke når enheten har et aktivt, eksternt utstedt sertifikat for å identifisere seg selv.

XStatus Conference EndToEndEndeCryption-tilgjengelighet

Angir om enheten kan delta i et ende-til-ende-kryptert møte. Cloud API kaller det slik at en sammenkoblet app vet om den kan bruke enheten til å bli med.

XStatus Conference EndToEndeCryption ExternalIdentity Verification

Angir om enheten bruker ekstern verifisering (har et eksternt utstedt sertifikat).

XStatus Conference EndToEndEncryption ExternalIdentity Identity

Enhetens identitet som lest fra det eksternt utstedte sertifikatets fellesnavn.

XStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # spesifikinfo

Leser spesifikk informasjon fra et eksternt utstedt sertifikat.

I kommandoen som vises, erst att # med nummeret på sertifikatet. Erst att spesifikinfo med en av:

  • Fingeravtrykk

  • NotAfter Sluttdato for gyldighet

  • NotBefore startdato for gyldighet

  • Primærnavn

  • Offentlig nøkkelalgoritme

  • Serienummer

  • SignaturAlgoritme

  • Em ne # Navn En liste over emnene for sertifikatet (f.eks. e-postadresse eller domenenavn)

  • Gyldighet Angir gyl dighetsstatusen til dette sertifikatet (f.eks. gyldig eller utløpt)

XStatus Conference EndToEndeCryption ExternalIdentity Status

Statusen til enhetens eksterne identitet (f.eks. gyldig eller feil).

XStatus Conference EndToEndeCryption InternalIdentity Verification

Angir om enheten har et gyldig sertifikat utstedt av Webex CA.

XStatus Conference EndToEndEncryption InternalIdentity Identity

Identiteten til enheten som lest fra det Webex-utstedte sertifikatets vanlige navn.

Inneholder et domenenavn hvis organisasjonen har et domene.

Er tom hvis organisasjonen ikke har et domene.

Hvis enheten er i en organisasjon som har flere domener, er dette verdien fra PreferredDomain.

XStatus Conference EndToEndToEndEncryption InternalIdentity CertificateChain Certificate # spesifikinfo

Leser spesifikk informasjon fra det Webex-utstedte sertifikatet.

I kommandoen som vises, erst att # med nummeret på sertifikatet. Erst att spesifikinfo med en av:

  • Fingeravtrykk

  • NotAfter Sluttdato for gyldighet

  • NotBefore startdato for gyldighet

  • Primærnavn

  • Offentlig nøkkelalgoritme

  • Serienummer

  • SignaturAlgoritme

  • Em ne # Navn En liste over emnene for sertifikatet (f.eks. e-postadresse eller domenenavn)

  • Gyldighet Angir gyl dighetsstatusen til dette sertifikatet (f.eks. gyldig eller utløpt)

Tabell 3. Anrops-API-er for ende-til-ende-krypterte møter og verifisert identitet

API-anrop

Beskrivelse

XEvent KonferansedeltakerListe deltakerLagt til

XEvent KonferansedeltakerListe deltakerOppdatert

XEvent KonferansedeltakerListe deltakerSlettet

Disse tre hendelsene inkluderer nå EndToEndenCryptionStatus, EndToEndenCryptionIdentity og EndToEn denCryption CertInfo for den berørte deltakeren.

Tabell 4. ClientSecret-relaterte API-er for ende-til-ende-krypterte møter og verifisert identitet

API-anrop

Beskrivelse

XCommand Security ClientSecret Fyll ut hemmelighet: «base64url-kodet»

eller

XCommand Security ClientSecret Fyll ut hemmelighet: JWeBlob

Godtar en base64url-kodet ren tekstverdi for å sette klienthemmeligheten på enheten for første gang.

For å oppdatere hemmeligheten etter den første gangen, må du levere en JWE-blob som inneholder den nye hemmeligheten kryptert av den gamle hemmeligheten.

XCommand Security Certificates Services Legg til JWEblob

Legger til et sertifikat (med privat nøkkel).

Vi utvidet denne kommandoen til å godta en JWE-blob som inneholder de krypterte PEM-dataene.

XCommand Security Certificates Services Aktiver formål:WebExIdentity FingerPrint: JWEblob

Aktiverer et bestemt sertifikat for WebExIdentity. For dette formålet krever kommandoen at det identifiserende fingeravtrykket krypteres og serialiseres i en JWE-blob.

XCommand Security Certificates Services Deaktiver Formål: WebExIdentity FingerPrint: JWEblob

Deaktiverer et bestemt sertifikat for WebExIdentity. For dette formålet krever kommandoen at det identifiserende fingeravtrykket krypteres og serialiseres i en JWE-blob.

Var denne artikkelen nyttig?
Var denne artikkelen nyttig?
PriserWebex-appMøterCallingMeldingerSkjermdeling
Webex SuiteCallingMøterMeldingerSlidoNettseminarEventsKontaktsenterCPaaSSikkerhetControl Hub
HodesettKameraerSkrivebord-serienRomserieTavleserieTelefonserieTilbehør
UtdanningHelsetjenesterRegjeringFinansSport og underholdningFrontlineIdeelle organisasjonerOppstartsbedrifterHybridarbeid
NedlastingerBli med på et testmøteNettbaserte timerIntegreringerTilgjengelighetInkluderingDirektesendte og nedlastbare webinarerWebex-fellesskapetWebex-utviklereNyheter og innovasjoner
CiscoKontakt supportKontakt salgWebex BlogWebex-tankelederskapWebex-varebutikkKarrierer
  • X
  • LinkedIn
  • Facebook
  • Youtube
  • Instagram
Vilkår og betingelserPersonvernerklæringInformasjonskapslerVaremerker
©2026 Cisco og/eller tilknyttede selskaper. Med enerett.
Vilkår og betingelserPersonvernerklæringInformasjonskapslerVaremerker