Du kan se detaljer om møter eller samtaler per deltaker, og se detaljert informasjon om lyd-, video- og delingskvaliteten. Dataene oppdateres hvert minutt for Webex Meetings og Call on Webex, slik at du kan diagnostisere problemer etter hvert som de oppstår. Data for Webex Calling oppdateres på slutten av hver samtale.

Brukeropplevelse

Brukere velger møtetypen når de planlegger et møte. Når du slipper deltakere fra lobbyen, så vel som under møtet, kan verten se identitetsbekreftelsesstatusen til hver deltaker. Det finnes også en møtekode som er felles for alle gjeldende deltakere i møtet, som de kan bruke til å bekrefte hverandre.

Del følgende informasjon med møtevertene:

Identitetsverifisering med intern eller ekstern sertifiseringsinstans

Bekreft identiteten

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 sertifiseringsinstansene (CA). Ved å bekrefte at sertifikatene er gyldige, bekrefter CA identiteten til deltakerne, og møtet viser deltakerne/enhetene som bekreftet.

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

Enheter kan godkjenne seg selv ved bruk av et sertifikat utstedt av den interne sertifiseringsinstansen (Webex), eller et sertifikat utstedt av en ekstern sertifiseringsinstans:

  • Intern sertifiseringsinstans – Webex utsteder et internt sertifikat basert på tilgangstokenet til enhetens maskinkonto. Sertifikatet er signert av Webex CA. Enheter har ikke bruker-ID-er på samme måte som brukere, 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 direkte og autorisere sertifikatene 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 bekreftet identitet, og forhindre den teoretiske muligheten for at Cisco kan avlytte møtet ditt/dekryptere mediene dine.

Internt utstedt enhetssertifikat

Webex utsteder et sertifikat til enheten når den registrerer seg etter oppstart, og fornyer det når dette er nødvendig. For enheter inkluderer sertifikatet konto-ID-en 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 et for deg.

Eksternt utstedt enhetssertifikat

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

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. Common Name (CN) og Subject Alternative Name (SAN) vises i brukergrensesnitt for Webex-møte , 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 domenet «example.com».

For å beskytte det eksterne sertifikatet fullstendig mot manipulering, brukes en klienthemmelig funksjon til å kryptere og signere forskjellige xcommands.

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

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

Funksjoner og begrensninger

Enheter

Følgende skyregistrerte enheter i Webex Room-serien og Webex Desk-serien kan bli med i ende-til-ende-krypterte møter:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

Følgende enheter kan ikke bli med i ende-til-ende-krypterte møter:

  • Webex C-serien

  • Webex DX-serien

  • Webex EX-serien

  • Webex MX-serien

  • Tredjeparts SIP-enheter

Programvareklienter

  • Fra og med versjon 41.6 kan Webex Meetings -skrivebordsklienten bli med i ende-til-ende-krypterte møter.

  • Hvis organisasjonen din aktiverer Webex-app for å bli med i møter ved å starte skrivebordsprogrammet Meetings, kan du bruke dette alternativet til å bli med i ende-til-ende-krypterte møter.

  • Webex-nettklienten kan ikke bli med i ende-til-ende-krypterte møter.

  • Myke klienter fra tredjeparts SIP kan ikke delta i ende-til-ende-krypterte møter.

Identitet

  • Vi tilbyr ikke Control Hub-alternativer for å administrere eksternt bekreftet enhetsidentitet. For ekte ende-til-ende-kryptering er det bare du som skal ha tilgang til hemmelighetene og nøklene. Dersom vi introduserte en skytjeneste for å administrere disse nøklene, hadde det vært en risiko for at de ble fanget opp.

  • For øyeblikket tilbyr vi en «oppskrift» der du kan utforme dine egne verktøy, basert på krypteringsteknikker som er standard i bransjen, for å hjelpe deg med å be om eller kryptere enhetsidentitetssertifikatene og de private nøklene til dem. Vi ønsker ikke å ha noen reell eller oppfattet tilgang til hemmelighetene eller nøklene dine.

Møter

  • Ende-til-ende-krypterte møter støtter for øyeblikket maksimalt 200 deltakere.

  • Av disse 200 deltakerne kan maksimalt 25 eksternt bekreftede enheter bli med, og de må være de første deltakerne som blir med på møtet .

    Når et større antall enheter blir med i et møte, prøver backend-medietjenestene våre å omkode mediestrømmene. Hvis vi ikke kan dekryptere, transkode og kryptere mediet på nytt (fordi vi ikke har og ikke skal ha enhetenes krypteringsnøkler), mislykkes transkodingen.

    For å redusere denne begrensningen anbefaler vi mindre møter for enheter, eller forskyving av invitasjonene mellom enheter og Meetings-klienter.

Administrasjonsgrensesnitt

Vi anbefaler på det sterkeste at du bruker Control Hub til å administrere møtenettstedet ditt, siden Control Hub-organisasjoner har sentralisert identitet for hele organisasjonen, mens i nettstedsadministrasjon kontrolleres identiteten fra sted til sted.

Brukere som administreres fra nettstedsadministrasjon, kan ikke ha alternativet Cisco-verifisert identitet. Disse brukerne får utstedt et anonymt sertifikat for å bli med i et ende-til-ende-kryptert møte, og de kan bli ekskludert fra møter der verten ønsker å sikre identitetsbekreftelse.

Ytterligere ressurser

Relatert informasjon

Forutsetninger

  • Webex Meetings 41.7.

  • Skyregistrerte enheter i Webex Room og Webex Desk-serien, som kjører 10.6.1-RoomOS_August_2021.

  • Administrativ tilgang til møtenettstedet i Control Hub for å aktivere den nye økttypen for brukere.

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

  • Møterom for samarbeid (CMR) må være aktivert slik at personer kan bli med fra videosystemet. Hvis du vil ha mer informasjon, se Tillate at videosystemer blir med i møter og arrangementer på Webex-nettstedet.

Hent enhetssertifikater

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

For det høyeste sikkerhetsnivået og for identitetsbekreftelse må hver enhet ha et unikt sertifikat utstedt av en klarert offentlig sertifiseringsinstans (CA).

Du må samhandle med sertifiseringsinstansen for å be om, kjøpe og motta de digitale sertifikatene og opprette de tilknyttede private nøklene. Når du ber om sertifikatet, bruker du disse parametrene:

  • Sertifikatet må utstedes og signeres av en velkjent offentlig sertifiseringsinstans.

  • Unikt: Vi anbefaler på det sterkeste å bruke et unikt sertifikat for hver enhet. Hvis du bruker ett sertifikat for alle enhetene dine, går det ut over sikkerheten.

  • Vanlig navn (CN) og alternativt navn for emne (SAN): Disse er ikke viktige for Webex, men bør være verdier som mennesker kan lese og knytte til enheten. Det tilkoblede nettverket vises for andre møtedeltakere som den primære bekreftede identiteten til enheten, og hvis brukere inspiserer sertifikatet via møtegrensesnittet, vil de se SAN. Du bør kanskje bruke navn som name.model@example.com.

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

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

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

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

Forbered deg på å integrere enheter

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

Hvis du bruker nye enheter, kan du ikke registrere dem på Webex ennå. For sikkerhets skyld ikke koble dem til nettverket på dette tidspunktet.

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

  • Lagre den eksisterende konfigurasjonen hvis du vil beholde den.

  • Planlegg et vindu når enhetene ikke er i bruk, eller bruk en faset tilnærming. Varsle brukere om endringene de kan forvente.

  • Sikre fysisk tilgang til enheter. Hvis du må få tilgang til enheter over nettverket, må du være oppmerksom på at hemmeligheter overføres som ren tekst, og at du går på kompromiss med sikkerheten din.

Når du har fullført disse trinnene, la videosystemer bli med i møter og hendelser på Webex-nettsted ditt .

Forstå den eksterne identitetsprosessen for enheter

Hvis du vil sikre at enhetsmediet ikke kan krypteres av andre enn enheten, må du kryptere privatnøkkelen på enheten. Vi utviklet 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 kryptering og opplasting av sertifikatet og nøkkelen. Hvis du trenger dette sikkerhetsnivået, må du:

  1. Be om sertifikatene dine.

  2. Generere sertifikatenes nøkkelpar.

  3. Opprette (og beskytte) en første hemmelighet for hver enhet, for å seede enhetens krypteringsfunksjonalitet.

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

    Prosessen og de (ikke-hemmelige) parametrene du trenger, er forklart nedenfor, i tillegg til en oppskrift du bør følge i dine valgte utviklingsverktøy. Vi tilbyr også noen testdata og de resulterende JWE-blobene slik vi forventer dem, for å hjelpe deg med å bekrefte prosessen din.

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

  5. Sett sammen og krypter sertifikatet og nøkkelen ved bruk av verktøyet og enhetens første 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. (Anbefales) Opprett et grensesnitt for (eller distribuer) verktøyet ditt slik at enhetsbrukere kan endre den første hemmeligheten og beskytte mediene sine mot deg.

Slik bruker vi JWE-formatet

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

Se JSON-nettkryptering (JWE)https://datatracker.ietf.org/doc/html/rfc7516og JSON-nettsignatur (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Vi bruker Kompakt serialisering av et JSON-dokument for å opprette JWE-blobber. Parametrene du må inkludere når du oppretter JWE-blobbene, er:

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

    • "alg":"dir"

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

    • "enc":"A128GCM" eller "enc":"A256GCM"

      Vi støtter disse to krypteringsalgoritmene.

    • "cisco-action": "add" eller "cisco-action": "populate" eller "cisco-action": "activate" eller "cisco-action": "deactivate"

      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 ga den navnet cisco-action for å redusere potensielle konflikter med fremtidige JWE-utvidelser.

    • "cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }

      En annen proprietær nøkkel. Vi bruker verdiene du oppgir som inndata for nøkkelavledning på enheten. Den version må være 1(versjonen av funksjonen vår for nøkkelavledning). 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 første ClientSecret.

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

  • JWE AAD (flere godkjente data). Du må utelate dette feltet fordi det ikke støttes i kompakt serialisering.

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

    Nyttelasten KAN være tom. Hvis du for eksempel vil tilbakestille klienthemmeligheten, må du overskrive den med en tom verdi.

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

    • Med "cisco-action":"populate" chifferkodeteksten er den nye ClientSecret.

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

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

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

  • JWE-godkjenningskode: Dette feltet inneholder godkjenningskoden for å fastslå integriteten til hele JWE-kompakt serialisert blob

Hvordan vi henter krypteringsnøkkelen fra ClientSecret

Etter den første utfyllingen av hemmeligheten, vil vi hverken godta eller sende hemmeligheten som ren tekst. Dette for å forhindre potensielle ordbokangrep fra noen som kan få tilgang til enheten.

Enhetsprogramvaren bruker klienthemmeligheten som inndata til en nøkkelavledningsfunksjon (kdf), og bruker deretter den avledede nøkkelen for innholdsdekryptering/kryptering på enheten.

Hva dette betyr for deg er at verktøyet ditt, for å produsere JWE-blober, må følge samme prosedyre for å utlede den samme krypterings-/dekrypteringsnøkkelen fra klienthemmeligheten.

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å angi det samme salt når du angir cisco-kdf parameteren.

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

  • Maksimalt minne 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 "version":"1", som er den eneste versjonen som for øyeblikket tas av cisco-kdf parameteren.

Eksempel på arbeid

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

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

  1. Velg en krypteringschiffer. I dette eksemplet brukes 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 (hex-byte) E5 E6 53 08 03 F8 33 F6. Base64url-kode sekvensen for å få 5eZTCAP4M_Y(fjern base64-paddingen).

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

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

    Den avledede nøkkelen må 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 initialiseringsvektor. Dette eksemplet bruker (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 som base64url koder til NLNd3V9Te68tkpWD.

  5. Opprett JOSE-hodet med kompakt serialisering (følg samme rekkefølge av parameterne vi bruker her), og kode det deretter med base64url:

    {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

    Det base64url-kodede JOSE-hodet 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 kode. I dette eksemplet vil den ukrypterte nyttelasten være den falske PEM-bloben this is a PEM file

    Krypteringsparameterne du bør bruke, er:

    • Nyttelast er this is a PEM file

    • Krypteringschiffer er AES 128 GCM

    • Base64url-kodet JOSE-hodet som ekstra godkjente data (AAD)

    Base64url-kode den krypterte nyttelasten, noe som skal resultere i f5lLVuWNfKfmzYCo1YJfODhQ

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

  9. Base64url-kode koden du produserte i trinn 8, noe som skal resultere i PE-wDFWGXFFBeo928cfZ1Q

    Dette er det femte elementet i JWE-bloben.

  10. Sett sammen de fem elementene i JWE-bloben med prikker (JOSEheader..IV.Ciphertext.Tag) for å få:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Hvis du avledet 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-krypteringen og den bekreftede identiteten til enhetene dine.

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

    xCommand Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Det finnes nye økttyper for Zero-Trust-møter, som vil være tilgjengelige for alle møteområder uten ekstra kostnad. Én av de nye økttypene kalles Pro-End to End Encryption_VOIPonly. Dette er navnet på den offentlige tjenesten som vi kan endre i fremtiden. Gjeldende navn på økttypene finner du under Økttype-ID-er under Referanse i denne artikkelen.

Du trenger du ikke å gjøre noe for å få den nye funksjonen for nettstedet, men du må gi den nye økttypen (også kalt Møterettighet) til brukere. Du kan gjøre dette enkeltvis via brukerens konfigurasjonsside, eller i gruppe med en CSV-eksport/-import.

Bekreft den nye økttypen

1

Logg på Control Hub og åpne Meetings-siden.

2

Klikk på nettstednavnet for å åpne konfigurasjonspanelet for nettstedet.

3

Klikk på Konfigurer nettstedet.

4

Gå til området Vanlige innstillinger og klikk på Økttyper.

Du skal se én eller flere ende-til-ende-krypteringsøkttyper. Se listen over Økttype-ID-er i Referanse-delen av denne artikkelen. Det kan for eksempel hende at du bare ser Pro-End to End Encryption_VOIPonly.

 

Det finnes en eldre økttype med et svært likt navn: Pro-End to End Encryption. Denne økttypen inkluderer ikke-kryptert PSTN-tilgang til møter. Kontroller at du har_ Kun VOIP versjon for å sikre ende-til-ende-kryptering. Du kan kontrollere dette ved å holde pekeren over PRO-koblingen i øktkodekolonnen. For dette eksempelet skal koblingens mål være javascript:ShowFeature(652).

Vi kan endre offentlige tjenestenavn for disse økttypene i fremtiden.

5

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

Hva nå?

Aktivere denne økttypen/møterettigheten for noen av eller alle brukerne dine.

Aktiver E2EE-møter for enkeltbrukere

1

Under Ledelse , klikk Brukere .

2

Velg en bruker, og velg deretter Møter .

3

Velg nettstedet (hvis brukeren er på mer enn ett) og klikk på Vert.

4

Merk av i boksen ved siden av Pro-ende til ende Encryption_ Kun VOIP .

5

Lukk brukerkonfigurasjonspanelet.

6

Gjenta dette 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 , deretter under Tjenester , velger du Møte .

2

Velg nettstedet ditt.

3

I delen Lisenser og brukere klikker du på Masseadministrasjon.

4

Klikk på Eksporter og vent mens vi klargjør filen.

5

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

6

Åpne den nedlastede CSV-filen for redigering.

Det finnes en rad for hver bruker, og MeetingPrivilege kolonnen inneholder økttype-ID-ene som en kommadelt liste.

7

For hver bruker du vil gi den nye økttypen, legger du til 1561 som en ny verdi i den kommadelte listen i MeetingPrivilege cellen.

Den Webex CSV-filformatreferanse inneholder detaljer om formålet med og innholdet i CSV-fil.

8

Åpne konfigurasjonspanelet for møtenettstedet i Control Hub.


 

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

9

I delen Lisenser og brukere klikker du på Masseadministrasjon.

10

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

11

Når importen er fullført, kan du klikke på Importer resultater for å se om det oppstod feil.

12

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

Legg til et lydvannmerke for sikkerhets skyld

Du kan legge til et vannmerke i møteopptak med Webex Meetings Pro-Ende til Ende Encryption_ Kun VOIP økttype, som lar deg identifisere hvem som delte opptaket eksternt.

Når denne funksjonen er aktivert, inneholder møtelyden en unik identifikator for hver deltaker. Du kan laste opp lydopptak til Control Hub, som deretter analyserer opptaket og slår opp unike identifikatorer. Du kan se på resultatene for å se hvilken deltaker som delte møteinnholdet eksternt.

  • 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å vare lenger enn 90 sekunder.
  • Du kan bare analysere opptak for møter som er vert av personer i organisasjonen.
  • Analyserte opptak slettes så snart analysen er fullført.
Legg til lydvannmerker i E2EE-møter
  1. Logg på Control Hub , deretter under Ledelse , velger du Organisasjonsinnstillinger .
  2. I Vannmerker for møte seksjon, slå på Legg til lydvannmerke .
Last opp og analyser et vannmerket møte
  1. I Control Hub, under Overvåking , velger du Feilsøking .
  2. Klikk på Vannmerkeanalyse .
  3. Søk etter eller velg møtet i listen, og klikk deretter på Analyser fil .
  4. I Analyser lydvannmerke vindu, skriver du inn et navn på analysen.
  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 på Lukk.

    Når analysen er fullført, vises den i resultatlisten på Analyser vannmerke side.

  8. Velg møtet i listen for å se resultatene av analysen. Klikk påLast ned-knappen for å laste ned resultatene.

Integrerte enheter (intern sertifiseringsinstans)

Hvis enhetene allerede er integrert i Control Hub-organisasjonen, og du vil bruke Webex CA til å automatisk generere identifikasjonssertifikatene sine, trenger du ikke å tilbakestilling til fabrikkinnstillinger .

Denne fremgangsmåten velger hvilket domene enheten bruker til å identifisere seg selv, og er kun nødvendig dersom 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 identiteten «Cisco-verifisert». Hvis du ikke forteller Webex hvilket domene som identifiserer enheten, velges ett automatisk, og det kan se feil ut for andre møtedeltakere.

Før du starter

Hvis enhetene dine ikke er innebygd ennå, følg med Registrere en enhet til Cisco Webex ved hjelp av API eller lokalt webgrensesnitt eller Skyonboarding for tavle-, skrivebords- og romserier . Du bør også bekrefte domenet/-ene du vil bruke til å identifisere enhetene i Administrer domenene dine .

1

Logg på Control Hub , og under Ledelse , velger du Enheter .

2

Velg en enhet for å åpne konfigurasjonspanelet.

3

Velg domenet du vil bruke til å identifisere denne enheten.

4

Gjenta dette for andre enheter.

Integrerte enheter (ekstern CA)

Før du starter

Du må:

  • Hvis du vil hente et CA-signert sertifikat og en privat nøkkel, går du inn .pem format for hver enhet.

  • lese emnet Forstå ekstern identitetsprosess for enheter, i delen Forberede av denne artikkelen.

  • For å forberede et JWE-krypteringsverktøy med hensyn til informasjonen der.

  • Et verktøy for å generere tilfeldige byte-sekvenser med gitte lengder.

  • Et verktøy for å base64url-kode byte eller tekst.

  • En scrypt implementering.

  • Et hemmelig ord eller uttrykk for hver enhet.

1

Fyll ut enhetens ClientSecret med en hemmelighet i ren tekst:

Første gang du fyller ut Secret, angir du den i ren tekst. Derfor anbefaler vi at du gjør dette på den fysiske enhetskonsollen.

  1. Base64url-kode det hemmelige uttrykket for denne enheten.

  2. Åpne TShell på enheten.

  3. Kjør xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    Eksempelkommandoen ovenfor fyller ut Secret med frasen 0123456789abcdef. Du må velge din egen.

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

Sett sammen sertifikatet og privatnøkkelen:

  1. Bruk et tekstredigeringsprogram til å åpne PEM-filene, lime inn nøkkel-BLOB-filen for sertifikat-bloben og lagre den som en ny PEM-fil.

    (Dette er nyttelastteksten du krypterer og legger i JWE-bloben)

3

Opprett en JWE-blob som skal brukes som inndata i kommandoen for sertifikattillegging:

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

  2. Utlede en innholdskrypteringsnøkkel med krypteringsverktøyet.

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

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

  4. Opprett et JOSE-hode, angi alg, enc og cisco-kdf nøkler som beskrevet i Forstå ekstern identitetsprosess for enheter. Angi «legg til»-handlingen ved bruk av key:value "cisco-action":"add" i JOSE-hodet (fordi vi legger til sertifikatet på enheten).

  5. Base64url-kode JOSE-hodet.

  6. Bruk JWE-krypteringsverktøyet med den valgte chifferkoden og det sammenslåtte JOSE-hodet for base64url til å kryptere teksten fra den sammenslåtte PEM-filen.

  7. Base64url-kode initialiseringsvektoren, den krypterte PEM-nyttelasten og godkjenningskoden.

  8. Konstruer JWE-bloben på følgende måte (alle verdier er base64url-kodet):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Åpne TShell på enheten, og kjør legg til-kommandoen (flerlinjet):

xcommand Security Certificates Services Add IsEncrypted: Trueyour..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

Aktivere sertifikatet for formålet WebexIdentity:

  1. Les sertifikatets fingeravtrykk, enten fra selve sertifikatet eller fra utdataene fra xcommand Security Certificates Services Show.

  2. Opprett en tilfeldig sekvens på minst 4 byte, og base64url-kode den sekvensen. Dette er saltet ditt.

  3. Utlede en innholdskrypteringsnøkkel med krypteringsverktøyet.

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

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

  5. Opprett et JOSE-hode, angi alg, enc og cisco-kdf nøkler som beskrevet i Forstå ekstern identitetsprosess for enheter. Angi «aktiver»-handlingen ved bruk av key:value "cisco-action":"activate" i JOSE-hodet (fordi vi aktiverer sertifikatet på enheten).

  6. Base64url-kode JOSE-hodet.

  7. Bruk JWE-krypteringsverktøyet med den valgte chifferkoden og det base64url-kodede JOSE-hodet til å kryptere sertifikatets fingeravtrykk.

    Verktøyet sender en sekvens på 16 eller 32 byte, avhengig av om du valgte 128 eller 256-biters AES-GCM og en godkjenningskode.

  8. Base64url-kode det krypterte fingeravtrykket og godkjenningskoden.

  9. Konstruer JWE-bloben på følgende måte (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, som er klart til bruk for å identifisere det i ende-til-ende-krypterte Webex-møter.
7

Innfase enheten i Control Hub-organisasjonen.

Test ende-til-ende-kryptering med identitetsbekreftelse

1

Planlegg et møte av riktig type (Webex Meetings Pro-End to End Encryption_VOIPonly).

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

2

Bli med i møtet som vert, fra en Webex Meetings-klient.

Se Bli med 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 må du bekrefte at denne enheten vises i lobbyen med riktig identitetsikon.

Se Bli med 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 sertifiseringsinstans.

6

Som vert må du bekrefte at denne enheten vises i lobbyen med riktig identitetsikon. Lær mer om identitetsikoner.

7

Bli med på møtet som en ikke-autentisert møtedeltaker.

8

Som vert må du kontrollere at denne deltakeren vises i lobbyen med riktig identitetsikon.

9

Som vert tar du inn eller avviser personer/enheter.

10

Valider deltaker-/enhetsidentitetene der det er mulig ved å kontrollere sertifikatene.

11

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

12

Bli med i møtet med en ny deltaker.

13

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

Angi omfang og forventninger

Skal du gjøre ende-til-ende-krypterte møter til standard møtealternativ, eller aktivere det bare for noen brukere – eller kanskje la alle vertene bestemme selv? Når du har bestemt deg for hvordan du skal bruke denne funksjonen, klargjør du brukerne som skal bruke den, spesielt med hensyn til begrensningene og hva de kan forvente i møtet.

Trenger du å sørge for at verken Cisco eller andre kan dekryptere innholdet ditt eller etterligne enhetene dine? I så fall trenger du sertifikater fra en offentlig sertifiseringsinstans. Du kan kun ha opptil 25 enheter i et sikkert møte. Hvis du trenger dette sikkerhetsnivået, bør du ikke la møteklienter bli med.

La enheter for brukere som blir med på sikre enheter, bli med først, og gi brukerne forventninger om at de kanskje ikke kan bli med hvis de blir med sent.

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

Identitetsadministrering

Hvis du bruker en ekstern sertifiseringsinstans til å utstede enhetssertifikater, er det din plikt å overvåke, oppdatere og bruke sertifikater på nytt.

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

Økttype-ID-er

Tabell 1. Økttype-ID-er for ende-til-ende-krypterte møter

Økttype-ID

Navn på offentlig tjeneste

638

E2E Encryption+VoIP only

652

Pro-End to End Encryption_VOIPonly

660

Pro 3 Free-End to End Encryption_VOIPonly

E2E Encryption + Identity

672

Pro 3 Free50-End to End Encryption_VOIPonly

673

Utdanningsinstruktør E2E Encryption_VOIPonly

676

Broadworks Standard plus end to end encryption

677

Broadworks Premium plus end to end encryption

681

Schoology Free plus end to end encryption

Relaterte xAPI-kommandoer

Disse tabellene beskriver API-kommandoer for Webex-enheter som vi har lagt til for ende-til-ende-krypterte møter og bekreftet identitet. Hvis du vil ha mer informasjon om hvordan du bruker API-en, se Få tilgang til API-en for Webex Room og Desk-enheter samt Webex Boards.

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

  • Registrert på 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-kall

Beskrivelse

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Denne konfigurasjonen gjøres når administratoren angir enhetens foretrukne domene fra Control Hub. Kun nødvendig dersom 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 EndToEndEncryption Availability

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

xStatus Conference EndToEndEncryption ExternalIdentity Verification

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

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

Leser spesifikk informasjon fra et eksternt utstedt sertifikat.

Erstatt i kommandoen som vises # med nummeret på sertifikatet. Erstatt specificinfo med ett av:

  • Fingerprint

  • NotAfter sluttdato for gyldighet

  • NotBefore startdato for gyldighet

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name En liste over emner for sertifikatet (f.eks. e-postadresse eller domenenavn)

  • Validity Gir gyldighetsstatusen for dette sertifikatet (f.eks valid eller expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

Statusen for enhetens eksterne identitet (f.eks valid eller error).

xStatus Conference EndToEndEncryption 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 EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Leser bestemt informasjon fra det Webex-utstedte sertifikatet.

Erstatt i kommandoen som vises # med nummeret på sertifikatet. Erstatt specificinfo med ett av:

  • Fingerprint

  • NotAfter sluttdato for gyldighet

  • NotBefore startdato for gyldighet

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name En liste over emner for sertifikatet (f.eks. e-postadresse eller domenenavn)

  • Validity Gir gyldighetsstatusen for dette sertifikatet (f.eks valid eller expired)

Tabell 3. I samtale-API-er for ende-til-ende-krypterte møter og bekreftet identitet

API-kall

Beskrivelse

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Disse tre hendelsene inkluderer nå EndToEndEncryptionStatus, EndToEndEncryptionIdentity og EndToEndEncryptionCertInfo for den berørte deltakeren.

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

API-kall

Beskrivelse

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

eller

xCommand Security ClientSecret Populate Secret: JWEblob

Godtar en base64url-kodet ren tekst-verdi for seeding av klienthemmeligheten på enheten for første gang.

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

xCommand Security Certificates Services Add JWEblob

Legger til et sertifikat (med privatnøkkel).

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

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Aktiverer et bestemt sertifikat for WebexIdentity. For dette Purpose, krever kommandoen at identifikasjonsfingeravtrykket krypteres og serialiseres i en JWE-blob.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Deaktiverer et bestemt sertifikat for WebexIdentity. For dette Purpose, krever kommandoen at identifikasjonsfingeravtrykket krypteres og serialiseres i en JWE-blob.