Brukeropplevelse

Brukere velger møtetypen når de planlegger et møte. Ved tilgang til deltakere fra lobbyen, samt under møtet, kan verten se status for identitetsbekreftelse for hver deltaker. Det finnes 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 ikke har blitt fanget opp av en uønsket tredjeparts Meddler In The Middle (MITM)-angrep.

Del følgende informasjon med møtevertene dine:

Identitetsbekreftelse med intern eller ekstern sertifiseringsinstans

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 til de andre gruppemedlemmene, som deretter validerer sertifikatene mot utstedende sertifiseringsinstanser (CA). Ved å bekrefte at sertifikatene er gyldige bekrefter sertifiseringsinstansen identiteten til deltakerne, og møtet viser deltakerne/enhetene som bekreftet.

Brukere av Webex-appen autentiserer seg mot Webex-identitetslageret, noe som gir dem et tilgangstoken når autentiseringen er vellykket. 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 hjelp 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 (et av) organisasjonens domener når du skriver enhetssertifikatets identitet (vanlig navn (CN)).

  • Ekstern sertifiseringsinstans – Be om og kjøp av enhetssertifikater direkte fra den valgte utstederen. Du må kryptere, laste opp direkte og godkjenne 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 tyde på 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 det er nødvendig. For enheter inkluderer sertifikatet konto-ID og et domene.

Hvis organisasjonen din 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 med en RSA-nøkkel.

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

Vi anbefaler at du bruker et separat sertifikat per enhet og har et unikt 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 klienthemmelighet til å kryptere og signere forskjellige xcommands.

Når du bruker klienthemmeligheten, er det mulig å administrere det eksterne Webex-identitetssertifikatet sikkert via xAPI. Dette er for tiden 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 E2EE-møter:

  • Webex-tavle

  • Webex Desk Pro

  • Webex Desk

  • Webex romsett

  • Mini Webex rom-sett

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

  • Webex C-serien

  • Webex DX-serien

  • Webex EX-serien

  • Webex MX-serien

  • Tredjeparts SIP-enheter

Programvareklienter

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

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

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

Identitet

  • Etter design gir vi ikke Control Hub-alternativer for å administrere eksternt bekreftet enhetsidentitet. For ekte ende-til-ende-kryptering, er det bare du som skal kjenne til / 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 fanget opp.

  • For øyeblikket tilbyr vi en «oppskrift» slik at du kan utforme 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 ekte eller oppfattet tilgang til dine hemmeligheter eller nøkler.

Møter

  • E2EE-møter støtter for øyeblikket 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 får ikke brukere tilgang til tavler som er opprettet utenfor møtet, inkludert private tavler, tavler som deles 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-appen | Markere delt innhold med merknader.

Administrasjonsgrensesnitt

Vi anbefaler på det sterkeste at du bruker Control Hub til å administrere Meetings-nettstedet ditt, da Control Hub-organisasjoner har sentralisert identitet for hele organisasjonen.

Ytterligere ressurser
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øtestedet i Control Hub.

  • Ett eller flere bekreftede domener i Control Hub-organisasjonen din (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 Tillate at videosystemer blir med i møter og hendelser 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 bør hver enhet ha et unikt sertifikat utstedt av en klarert offentlig sertifiseringsinstans (CA).

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

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

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

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

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

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

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

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

Klargjør innføring av enheter

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

Hvis du bruker nye enheter, må du ikke registrere dem i Webex ennå. For å være trygge må du 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 fabrikkinnstillinger.

  • Lagre den eksisterende konfigurasjonen hvis du vil beholde den.

  • Planlegg et vindu når enhetene ikke er i bruk, eller bruk en fasedelt tilnærming. Varsle brukerne 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 reiser i ren tekst og at du kompromitterer sikkerheten din.

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

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 kryptering og opplasting av sertifikatet og nøkkelen. Hvis du trenger dette sikkerhetsnivået, må du:

  1. Be om sertifikatene dine.

  2. Generer sertifikatenes nøkkelpar.

  3. Opprett (og beskytt) en første hemmelighet for hver enhet for å sege enhetens krypteringsfunksjonalitet.

  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, forklares nedenfor, i tillegg til en oppskrift du kan følge i dine valgte utviklingsverktøy. Vi tilbyr også noen testdata og de resulterende JWE-blobene som vi forventer dem, for å hjelpe deg med å bekrefte prosessen din.

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

  5. Sett sammen og krypter sertifikatet og nøkkelen ved hjelp 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-identiteten, og aktiver sertifikatet.

  8. (Anbefalt) Gi et grensesnitt til (eller distribuer) verktøyet ditt slik at enhetsbrukere kan endre den første hemmeligheten og beskytte mediene 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 å opprette 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 til å lage JWE-blober. Parameterne du må inkludere når du oppretter JWE-blobene, er:

  • JOSE Header (beskyttet). I JSON-objektsignerings- og krypteringshodet 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":"A114GCM" eller "enc":"A114GCM"

      Vi støtter disse to krypteringsalgoritmene.

    • "cisco-action": "legg til" eller "cisco-action": "fylle ut" eller "cisco-action": "aktiver" eller "cisco-action": "deaktiver"

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

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

    • «cisco-kdf»: { «versjon»: «1», «salt»: «base64URLEncodedRandom4+Bytes» }

      En annen proprietær nøkkel. Vi bruker verdiene du oppgir som inndata 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 første ClientSecret.

  • JWE-initialiseringsvektor. 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-chifferfamilien, som krever at IV er 12 byte lang).

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

  • JWE chifferkodetekst: Dette er den krypterte nyttelasten du ønsker å 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. Ulike 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" er chifferteksten den nye ClientSecret.

    • Med ""cisco-action":"add" er krypteringsteksten en PEM-blob som bærer sertifikatet og dets private nøkkel (sammenslått).

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

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

  • 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 populasjonen av hemmeligheten, aksepterer eller utgir vi ikke hemmeligheten som ren tekst. Dette er for å forhindre potensielle ordbogsangrep av noen som kan få tilgang til enheten.

Enhetsprogramvaren bruker klienthemmeligheten som inndata til en nøkkelavledningsfunksjon (kdf) og bruker deretter den avledede nøkkelen til 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 til 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 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)

  • Maks minnegrense 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 brukes 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 til enheten (etterligner å legge til et sertifikat, med en veldig kort streng i stedet for en full sertifikat + nøkkel). Klienthemmeligheten i eksemplet er ossifrage.

  1. Velg en krypteringschiffer. Dette eksemplet bruker A114GCM (AES med 128-biters nøkler i Galois Counter Mode). Verktøyet ditt kan bruke A114GCM 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 på scrypt -anrop for å opprette innholdskrypteringsnøkkelen (cek):

    cek=scrypt(password="ossifrage", salt=4-byte-sekvens, N=32768, r=8, p=1, keylengde=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 initialiseringsvektor. Dette eksemplet bruker (hex) 34 b3 5d dd 5f 53 7b av 2d 92 95 83 som base64url koder til NLNd3V9Te68tkpWD.

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

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

    Base64url-kodet JOSE-toppteksten er eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Dette blir 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. 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

    • Krypteringschifferen er AES 128 GCM

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

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

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

  9. Base64url-kode koden du produserte i trinn 8, 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 for å sikre E2E-kryptering og verifisert identitet til enhetene dine.

  12. Dette eksemplet vil faktisk ikke fungere, 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-sikkerhetssertifikater Legg til eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Økttyper for Zero Trust-møter er tilgjengelige for alle møteområder uten ekstra kostnad. En av disse økttypene kalles Pro-End to End Encryption_VOIPonly. Dette er navnet på offentlig tjeneste, som vi kan endre i fremtiden. For gjeldende navn på økttypene, se Økttype-ID-er i Referanse -delen i denne artikkelen.

Du trenger ikke å gjøre noe for å få denne funksjonen for nettstedet ditt. Du må gi den nye økttypen (også kalt Møterettighet) 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 Tjenester > Møte.

2

Klikk på Nettsteder, velg Webex-nettstedet du vil endre innstillingene for, og klikk deretter på Innstillinger.

3

Under Fellesinnstillinger velger du Økttyper.

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

Det finnes en eldre økttype med et svært likt navn: Pro-ende-til-ende-kryptering. Denne økttypen inkluderer ikke-kryptert PSTN-tilgang til møter. Sørg for at du har _VOIPonly -versjonen for å sikre ende-til-ende-kryptering. Du kan sjekke dette ved å holde pekeren over PRO -koblingen i øktkodekolonnen. For dette eksemplet bør koblingens mål være javascript:ShowFeature(652).

Vi kan endre navn på offentlig tjeneste for disse økttypene i fremtiden.

5

Hvis du ikke har den nye økttypen ennå, kan du kontakte din Webex-representant.

Hva du skal gjøre nå

Aktiver denne økttypen / møterettigheten til noen av 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 som skal oppdateres, og velg deretter Møter.

3

Fra rullegardinmenyen Innstillinger gjelder for velger du møtenettstedet som skal oppdateres.

4

Merk av i boksen ved siden av Pro-End to End Encryption_VOIPonly.

5

Lukk brukerkonfigurasjonspanelet.

6

Gjenta dette for andre brukere om nødvendig.

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

Aktiver E2EE-møter for flere brukere
1

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

2

Klikk på Nettsteder, velg Webex-nettstedet du vil endre innstillingene for.

3

I delen Lisenser og brukere klikker du på Masseadministrasjon.

4

Klikk på Generer rapport, 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 klikker på Last ned.)

6

Åpne den nedlastede CSV-filen for redigering.

Det er en rad for hver bruker, og MeetingPrivilege -kolonnen inneholder økttype-ID-ene deres 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.

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

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, og 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 sikkerhet

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

Når denne funksjonen er aktivert, inkluderer møtelyden en unik identifikator for hver deltakende klient eller enhet. Du kan laste opp lydopptak til Control Hub, som deretter analyserer opptaket og ser 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 arrangeres av personer i organisasjonen din.
  • Vannmerkeinformasjon beholdes i samme varighet som organisasjonens møteinformasjon.

Legg til lydvannmerker i E2EE-møter

  1. Logg på Control Hub, og velg deretter Organisasjonsinnstillinger under Administrasjon.
  2. I delen Møtevannmerker slår du på Legg til lydvannmerke.

    Noen tid 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 Sikkerhet-delen.

Last opp og analyser et vannmerket møte

  1. I Control Hub velger du Feilsøking under Overvåking.
  2. Klikk på Vannmerkeanalyse.
  3. Søk etter eller velg møtet i listen, og klikk deretter på Analyser.
  4. Skriv inn et navn for analysen i vinduet Analyser lydvannmerke .
  5. (Valgfritt) Skriv inn en merknad for analysen.
  6. Dra og slipp lydfilen som skal analyseres, eller klikk på Velg fil for å bla til lydfilen.
  7. Klikk på 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 Last ned-knapp for å laste ned resultatene.

Funksjoner og begrensninger

Faktorer som er involvert i vellykket dekoding av et innspilt vannmerke, inkluderer avstanden mellom opptaksenheten og høyttaleren som utgir lyden, volumet på den lyden, omgivelsesstøy osv. Vår vannmerketeknologi har ekstra motstandsdyktighet mot å bli kodet flere ganger, som det kan skje når mediene deles.

Denne funksjonen er utformet for å muliggjøre vellykket dekoding av vannmerkeidentifikatoren i et bredt, men rimelig sett av omstendigheter. Målet vårt er at en opptaksenhet, for eksempel en mobiltelefon, som ligger på et bord i nærheten av et personlig endepunkt eller en bærbar datamaskin, alltid skal opprette et opptak som fører til en vellykket analyse. Når opptaksenheten flyttes bort fra kilden, eller er skjult fra å høre hele lydspektret, reduseres sjansene for en vellykket analyse.

For å kunne analysere et opptak, er det nødvendig med et rimelig opptak av møtelyden. Hvis lyden i et møte blir tatt opp på samme datamaskin som er vert for klienten, bør det ikke gjelde begrensninger.

Innebygde enheter (intern sertifiseringsinstans)

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

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

Før du begynner

Hvis enhetene ennå ikke er innfaset, følger du Registrer en enhet til Cisco Webex ved hjelp av API eller lokalt webgrensesnitt eller Skyinnfasing for Board-, Desk- og Room-serien. Du bør også bekrefte domenet/domenene du vil bruke til å identifisere enhetene i Administrer domenene dine.

1

Logg på Control Hub, og velg Enheter under Administrasjon.

2

Velg en enhet for å åpne konfigurasjonspanelet.

3

Velg domenet du vil bruke til å identifisere denne enheten.

4

Gjenta dette for andre enheter.

Innfasing av enheter (ekstern sertifiseringsinstans)

Før du begynner

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

  • Les emnet Forstå ekstern identitetsprosess for enheter under fanen Forbered.

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

  • Sørg for at du har et verktøy for å generere tilfeldige byte-sekvenser av gitte lengder.

  • Sørg for at du har et verktøy for å base64url-kode byte eller tekst.

  • Sørg for at du har en scrypt implementering.

  • Sørg for at du har 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 Hemmeligheten, skriver du den inn i ren tekst. Derfor anbefaler vi at du gjør dette på den fysiske enhetskonsollen.

  1. Base64url-kode den hemmelige frasen for denne enheten.

  2. Åpne TShell på enheten.

  3. Kjør xcommand Security ClientSecret Fyll ut hemmelighet: "MDEyMzQ1Njc4OWFiY2RlZg"

    Eksempelkommandoen ovenfor fyller ut Hemmeligheten med uttrykket 0123456789abcdef. Du må velge din egen.

Enheten har sin første hemmelighet. Ikke glem dette. Du kan ikke gjenopprette det og 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økkelen blob sertifikatblob og lagre den som en ny .pem-fil.

    Dette er nyttelastteksten du krypterer og legger inn i din JWE-blob.

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 keylengde for å matche den valgte krypteringschifferen. Det er noen andre faste verdier å levere (N=32768, r=8, p=1). Enheten bruker den samme prosessen og verdiene til å utlede den samme innholdskrypteringsnøkkelen.

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

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

  5. Base64url-kode JOSE-hodet.

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

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

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Åpne TShell på enheten og kjør kommandoen for å legge til (flerlinje): 

xcommand sikkerhetssertifikattjenester Add IsEncrypted: Sann din..JWE.str.ing\n .\n
5

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

Kopier det nye sertifikatets fingeravtrykk.

6

Aktiver 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 keylengde for å matche den valgte krypteringschifferen. Det er noen andre faste verdier å levere (N=32768, r=8, p=1). Enheten bruker den samme prosessen og verdiene til å utlede den samme innholdskrypteringsnøkkelen.

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

  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 hjelp av nøkkelen:value "cisco-action":"aktiver" 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 skal vise en sekvens på 16 eller 32 byte, avhengig av om du valgte 128 eller 256 bit AES-GCM, og en godkjenningskode.

  8. Base64urlenkode det krypterte fingeravtrykket og godkjenningskoden.

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

    JOSEHeader..InitVector.EncryptedFingeravtrykk.AuthTag

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

     xcommand sikkerhetssertifikattjenester aktivere formål: WebexIdentity-fingeravtrykk: "Ditt..JWE.encrypted.fingeravtrykk"

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

Innfør enheten i Control Hub-organisasjonen din.

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 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 på 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 i et Webex-møte med ende-til-ende-kryptering.

5

Bli med på 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. Finn ut mer om identitetsikoner.

7

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

8

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

9

Som vert, gi tilgang til eller avvis personer/enheter.

10

Valider deltaker-/enhetsidentiteter der det er mulig ved å kontrollere 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

Sjekk 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 la alle verter bestemme? Når du har bestemt deg for hvordan du skal bruke denne funksjonen, må du forberede brukerne som skal bruke den, spesielt med hensyn til begrensningene og hva de kan forvente i møtet.

  • Må du sørge for at verken Cisco eller noen andre kan dekryptere innholdet ditt eller etterligne enhetene dine? I så fall trenger du sertifikater fra en offentlig sertifiseringsinstans.

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

Identitetsadministrasjon

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 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.

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

Økttype-ID

Navn på offentlig tjeneste

638

Kun E2E-kryptering+VoIP

652

Pro-End to End Encryption_VOIPonly

660

Pro 3 Free-End to End Encryption_VOIPonly

E2E-kryptering + identitet

672

Pro 3 Free50-End til End Encryption_VOIPonly

673

ncryption_Utdanningsinstruktør E2E EVOIPonly

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 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, kan du se Få tilgang til API for Webex Room- og Desk-enheter og Webex Boards.

Disse xAPI-kommandoene er bare tilgjengelige på enheter som enten 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 bekreftet 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. 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 EndToEndEncryption Tilgjengelighet

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

xStatus Conference EndToEndEncryption ExternalIdentity-verifisering

Angir om enheten bruker Ekstern bekreftelse (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 # spesifikk informasjon

Leser spesifikk informasjon fra et eksternt utstedt sertifikat.

I kommandoen som vises, erstatt # med sertifikatnummeret. Erstatt spesifikasjonsinformasjon med ett av:

  • Fingeravtrykk

  • NotAfter Validity-sluttdato

  • IkkeFør gyldighetsstartdato

  • Primærnavn

  • PublicKeyAlgoritme

  • Serienummer

  • Signaturalgoritme

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

  • Gyldighet Gir gyldighetsstatusen til dette sertifikatet (f.eks. gyldig eller utløpt)

xStatus Conference EndToEndEncryption ExternalIdentity Status

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

xStatus Conference EndToEndEncryption InternalIdentity-verifisering

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 # spesifikk informasjon

Leser spesifikk informasjon fra det Webex-utstedte sertifikatet.

I kommandoen som vises, erstatt # med sertifikatnummeret. Erstatt spesifikasjonsinformasjon med ett av:

  • Fingeravtrykk

  • NotAfter Validity-sluttdato

  • IkkeFør gyldighetsstartdato

  • Primærnavn

  • PublicKeyAlgoritme

  • Serienummer

  • Signaturalgoritme

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

  • Gyldighet Gir gyldighetsstatusen til dette sertifikatet (f.eks. gyldig eller utløpt)

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

API-kall

Beskrivelse

xEvent konferansedeltakerListe deltakerLagt til

xEvent Conference DeltakerListe DeltakerOppdatert

xEvent-konferansedeltakerListe deltakerSlettet

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 verifisert identitet

API-kall

Beskrivelse

xCommand Security ClientSecret Fyll ut hemmelighet: "base64url-kodet"

eller

xCommand Security ClientSecret Fyll ut hemmelighet: 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 oppgi en JWE-blob som inneholder den nye hemmeligheten kryptert av den gamle hemmeligheten.

xCommand sikkerhetssertifikattjenester 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 spesifikt sertifikat for WebexIdentity. For dette formålet krever kommandoen at identifikasjonsfingeravtrykket krypteres og serialiseres i en JWE-blob.

xCommand Security Certificates Services deaktiver Formål:WebexIdentity FingerPrint: JWEblob

Deaktiverer et spesifikt sertifikat for WebexIdentity. For dette formålet krever kommandoen at identifikasjonsfingeravtrykket krypteres og serialiseres i en JWE-blob.