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 nåværende deltakere i møtet, som de kan bruke til å bekrefte at møtet ikke har blitt fanget opp av et uønsket tredjepartsangrep fra Meddler In The Middle (MITM).

Del følgende informasjon med møtevertene dine:

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 autentisere seg selv ved hjelp av et sertifikat utstedt av den interne (Webex) CA, eller et sertifikat utstedt av en ekstern CA:

  • 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 registreres etter oppstart, og fornyer det ved behov. 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 som identitet. Du kan også bruke API-et xConfiguration Conference EndToEndEncryption Identity PreferredDomain: «example.com» .

Hvis du har flere domener og ikke angir foretrukket domene 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 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 bestemmes av organisasjonen. 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 å fullstendig beskytte det eksterne sertifikatet mot tukling, brukes en klienthemmelig funksjon til å kryptere og signere forskjellige x-kommandoer.

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 E2EE-møter:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex romsett

  • Webex romsett mini

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 skrivebords- og mobilklienter kan bli med i E2EE-møter.

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

  • Tredjeparts myke SIP-klienter kan ikke delta i E2EE-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. 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» der du kan utforme dine egne verktøy, basert på krypteringsteknikker som er standard i industrien, 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

  • 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 har 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 merknad, se Webex-appen| Merk delt innhold med merknader .

Administrasjonsgrensesnitt

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

Ytterligere ressurser
Forutsetninger

  • Webex Meetings 41.7.

  • Skyregistrerte enheter i serien Webex Room og Webex Desk, kjører 10.6.1-RoomOS_ August_ 2021 .

  • Administrativ tilgang til møtested 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 aktivert slik at folk kan bli med fra videosystemet sitt. Hvis du vil ha mer informasjon, se Tillat at videosystemer blir med i møter og hendelser på Webex-nettsted ditt .

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 CA 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å være utstedt og signert av en kjent 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, går det ut over sikkerheten.

  • Felles navn (CN) og alternative navn/navn for emne (SAN/er): 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øte-grensesnittet, vil de se SAN/-ene. Det kan være lurt å bruke navn som navn.modell@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 som bruker P-256-kurven).

    Dette kravet gjelder ikke for signaturnø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, må du ikke registrere dem til 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 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 beveger seg i ren tekst, og du går på bekostning av sikkerheten.

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

For å sikre at enhetsmediet ikke kan krypteres av andre enn enheten, må du kryptere den private nø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. Generer nøkkelparene til sertifikatene dine.

  3. Opprett (og beskytt) en første hemmelighet for hver enhet, for å se enhetens krypteringsfunksjon.

  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, i tillegg til en oppskrift du bør følge i dine valgte utviklingsverktøy. Vi gir også noen testdata og de resulterende JWE-blobbene slik vi forventer dem, for å hjelpe deg med å bekrefte prosessen.

    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 hjelp av verktøyet og enhetens første hemmelighet.

  6. Last opp den resulterende JWE-blobben 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.

Hvordan vi bruker JWE-formatet

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

Se JSON-nettkryptering (JWE) https://datatracker.ietf.org/doc/html/rfc7516 og 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-hode (beskyttet). I JSON Object Signing and Encryption-hodet MÅ du inkludere følgende nøkkelverdipar:

    • "alg": "katalog"

      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": "legg til" eller "cisco-action": "fyll 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 å signalisere formålet med de krypterte dataene til målenheten. Verdiene er oppkalt etter xAPI-kommandoer på enheten der du bruker de krypterte dataene.

      Vi ga den navnet cisco-action for å redusere potensielle sammenstøt med fremtidige JWE-utvidelser.

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

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

  • JWE-kryptert nøkkel . Dette feltet er tomt. Enheten henter det fra initialen ClientSecret .

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

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

  • JWE-kryptering : 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 nyttelast, 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økkel, som følger:

    • Med "cisco-action":"fyll ut" chifferteksten er den nye ClientSecret .

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

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

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

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

Hvordan vi henter krypteringsnøkkel fra ClientSecret

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

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

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

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

  • CostFactor (N) er 32768

  • BlockSizeFactor (r) er 8

  • Parallelliseringsfaktor (p) er 1

  • Salt er en tilfeldig sekvens på minst 4 byte. du må oppgi dette samme salt når du angir cisco-kdf parameter.

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

  • Maksimalt minne er 64 MB

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

Fungert eksempel

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 tillegging av et sertifikat, med en veldig kort streng i stedet for en full cert + nøkkel). Klienthemmeligheten i eksemplet er ossifrage .

  1. Velg et krypteringschiffer. 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 (hexbyte) E5 E6 53 08 03 F8 33 F6 . Base64url kode sekvensen som skal hentes 5eZTCAP4M_ Y (fjern base64-polstringen).

  3. Her er et eksempel krypter anrop for å opprette innholdskrypteringsnøkkelen ( krypteringsnøkkel ):

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

    Den utledede nøkkelen skal være på 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_mqd Inj_r A .

  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 som vi bruker her), og kode det deretter med base64url:

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

    Den base64url-kodede JOSE-hodeteksten er eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZWTEQ5jIjoD

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

  6. Det andre elementet i JWE-blobben 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 kommer den ukrypterte nyttelasten til å være den falske PEM-blobben dette er en PEM-fil

    Krypteringsparametrene du bør bruke er:

    • Nyttelasten er dette er en PEM-fil

    • Krypteringskrypteringen er AES 128 GCM

    • Base64url-kodet JOSE-hodet som ytterligere autentisert 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 taggen du produserte i trinn 8, noe som skal resultere i PE-wDFWGXFFBeo928cfZ1Q

    Dette er det femte elementet i JWE-klatten.

  10. Sett sammen de fem elementene i JWE-blobben 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 bekreftet identiteten til enhetene dine.

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

    xCommand-sikkerhetssertifikater Legg til eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Økttyper for møter med null tillit er tilgjengelige for alle møtenettsteder uten ekstra kostnad. En av disse økttypene kalles Pro-ende til ende Encryption_ Kun VOIP . Dette er Offentlig tjenestenavn , som vi kan endre i fremtiden. For gjeldende navn på økttypene, se Økttype-ID-er i Referanse delen av denne artikkelen.

Det er ingenting du trenger å gjøre 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 samtidig med en CSV-eksport/import.

Bekreft den nye økttypen
1

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

2

Klikk på Nettsteder velger du Webex-nettsted du vil endre innstillingene for, og klikker deretter Innstillinger .

3

Under Fellesinnstillinger , velger du Økttyper .

4
Du skal se én eller flere ende-til-ende-krypteringsøkttyper. Se listen over Økttype-ID-er i Referanse delen av denne artikkelen. Du kan for eksempel se Pro-ende til ende Encryption_ Kun VOIP .

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. Kontroller at du har_ Kun VOIP versjon for å sikre ende-til-ende-kryptering. Du kan sjekke ved å holde pekeren over PRO kobling i øktkodekolonnen; for dette eksemplet skal målet for koblingen 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 din Webex-representant.

Hva du skal gjøre videre

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

Aktiver E2EE-møter for enkeltbrukere
1

Logg på Kontrollhub , og gå til Ledelse > Brukere .

2

Velg en brukerkonto som skal oppdateres, og velg deretter Møter .

3

Fra Innstillingene gjelder for velger du møtested som skal oppdateres.

4

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

5

Lukk panelet for brukerkonfigurasjon .

6

Gjenta om nødvendig for andre brukere.

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å Kontrollhub , og gå til Tjenester > Møte .

2

Klikk på Nettsteder , velger du Webex-nettsted du vil endre innstillingene for.

3

I Lisenser og brukere klikker du på Massebehandling .

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 Last ned . (Du må lukke popup-vinduet manuelt etter at du har klikket Last ned .)

6

Åpne den nedlastede CSV-fil for redigering.

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

7

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

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

8

Åpne konfigurasjonspanelet for møteområde i Control Hub.

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

9

I Lisenser og brukere klikker du på Massebehandling .

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 var noen feil.

12

Gå til Brukere 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 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 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å vare lenger enn 100 sekunder.
  • Du kan bare analysere opptak for møter som er vert av personer i organisasjonen.
  • Vannmerkeinformasjonen beholdes i samme varighet som organisasjonens møteinformasjon.

Legg til lydvannmerker i E2EE-møter

  1. Logg på Kontrollhub , deretter under Ledelse , velger du Organisasjonsinnstillinger .
  2. I Vannmerker for møte seksjon, slå på Legg til lydvannmerke .

    Noe tid etter at dette er slått på, planlegger brukere møter med Webex Meetings Pro-Ende til Ende Encryption_ Kun VOIP økttype, se a Digital vannmerking i delen Sikkerhet.

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

Funksjoner og begrensninger

Faktorer som er involvert i vellykket avkoding av et vannmerke som er tatt opp, inkluderer avstanden mellom opptaksenheten og høyttaleren som sender ut lyden, volumet på den lyden, miljøstøy osv. Vannmerketeknologien vår har ekstra robusthet til å bli kodet flere ganger, noe som kan skje når mediet deles.

Denne funksjonen er utformet for å muliggjøre vellykket dekoding av vannmerke-ID-en under et bredt, men rimelig sett med 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 klient, alltid skal opprette et opptak som resulterer i en vellykket analyse. Når opptaksenheten flyttes bort fra kilden, eller blir skjult fra å høre hele lydspekteret, reduseres sjansene for en vellykket analyse.

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

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 prosedyren velger hvilket domene enheten bruker til å identifisere seg selv, og er bare obligatorisk 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 skal ha «Cisco-verifisert» identitet. 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 begynner

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å Kontrollhub , 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 for andre enheter.

Integrerte enheter (ekstern CA)

Før du begynner

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

  • Under Forbered deg -fanen, les emnet Forstå ekstern identitetsprosess for enheter ,

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

  • Kontroller at du har et verktøy for å generere tilfeldige bytesekvenser med gitte lengder.

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

  • Kontroller at du har en krypter gjennomføring.

  • Kontroller at du har et hemmelig ord eller en setning for hver enhet.

1

Fyll ut enhetens ClientSecret med en ren teksthemmelighet:

Første gang du fyller ut Hemmelighet , leverer du den i ren tekst. Det er derfor vi anbefaler 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 Populate Secret: «MDeyMzQ1Njc4OWFiY2RlZg»

    Eksempelkommandoen ovenfor fyller ut Hemmelighet med uttrykket0123456 789abcdef . 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

Slå sammen sertifikatet og den private nøkkelen:

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

    Dette er nyttelastteksten du skal kryptere og legge i JWE-blobben din.

3

Opprett en JWE-blob som skal brukes som inndata for sertifikatet legge til-kommandoen:

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

  2. Utled en krypteringsnøkkel for innhold med krypteringsnøkkel .

    For dette trenger du hemmeligheten, saltet og en nøkkellengde som samsvarer med ditt valgte krypteringschiffer. Det finnes noen andre faste verdier å oppgi (N=32768, r=8, p=1). Enheten bruker den samme prosessen og verdiene for å utlede den samme krypteringsnøkkel for innhold.

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

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

  5. Base64url kode JOSE-hodet.

  6. Bruk JWE-krypteringsverktøyet med valgt chiffer og den base64url-kodede JOSE-hodet for å kryptere teksten fra den sammenkoblede PEM-filen.

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

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Åpne TShell på enheten og kjør (flere linjer) add-kommandoen: 

xcommand Security Certificates Services Add IsEncrypted: Sann din..JWE.str.ing\n .\n
5

Kontroller at sertifikatet er lagt til ved å kjøre xcommand Sikkerhetssertifikater Vis tjenester

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 til xcommand Sikkerhetssertifikater Vis tjenester .

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

  3. Utled en krypteringsnøkkel for innhold med krypteringsnøkkel .

    For dette trenger du hemmeligheten, saltet og en nøkkellengde som samsvarer med ditt valgte krypteringschiffer. Det finnes noen andre faste verdier å oppgi (N=32768, r=8, p=1). Enheten bruker den samme prosessen og verdiene for å utlede den samme krypteringsnøkkel for innhold.

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

  5. Opprett et JOSE-hode, innstilling alg , enc , og cisco-kdf taster som beskrevet i Forstå ekstern identitetsprosess for enheter . Angi «aktiver»-handlingen ved hjelp av nøkkel:verdi "cisco-action": "aktiver" i JOSE-hodet (fordi vi aktiverer sertifikatet på enheten).

  6. Base64url kode JOSE-hodet.

  7. Bruk JWE-krypteringsverktøyet med valgt chiffer og den base64url-kodede JOSE-hodet for å kryptere sertifikatets fingeravtrykk.

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

  8. Base64urlencode det krypterte fingeravtrykket og autentiseringskoden.

  9. Konstruer JWE-blobben 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-sikkerhetssertifikater-tjenester Aktivering Formål: WebexIdentity-fingeravtrykk: «Ditt..JWE.encrypted.fingeravtrykk»

Enheten har et kryptert, aktivt CA-utstedt sertifikat som er klart til bruk for å identifisere den i ende-til-ende-krypterte Webex-møter.
7

Integrer enheten til Control Hub-organisasjonen din.

Test ende-til-ende-kryptering med identitetsbekreftelse
1

Planlegg et møte av riktig type ( Webex Meetings Pro-Ende til Ende Encryption_ Kun VOIP ).

Se Planlegg 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 på 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 kontrollere at denne enheten vises i lobbyen med riktig identitetsikon.

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

5

Bli med på møtet fra en enhet som har identiteten sin bekreftet av en ekstern sertifiseringsinstans.

6

Som vert må du kontrollere at denne enheten vises i lobbyen med riktig identitetsikon. Finn ut 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 kan du tillate eller avvise 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 på møtet med en ny deltaker.

13

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

Angi omfang og forventninger

  • Kommer du til å gjøre ende-til-ende-krypterte møter til standard møtealternativ, aktivere det bare for noen brukere, eller la alle verter bestemme? Når du har bestemt deg for hvordan du skal bruke denne funksjonen, forbereder du brukerne som skal 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 seg for å være enhetene dine? I så fall trenger du sertifikater fra en offentlig sertifiseringsinstans.

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

Identitetsbehandling

Hvis du bruker en ekstern sertifiseringsinstans til å utstede enhetssertifikatene, har du ansvaret for å 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 å sette dem i stand til å gjøre dette.

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

Økttype-ID

Offentlig tjenestenavn

638

Kun E2E-kryptering+VoIP

652

Pro-ende til ende Encryption_ Kun VOIP

660

Pro 3 Free-End til Ende Encryption_ Kun VOIP

E2E-kryptering + identitet

672

Pro 3 Free50-Ende til Ende Encryption_ Kun VOIP

673

Utdanningsinstruktør E2E Encryption_ Kun VOIP

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-et, kan du se Tilgang til API-en for Webex rom- og skrivebordsenheter og 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 bekreftet identitet

API-kall

Beskrivelse

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: «example.com»

Denne konfigurasjonen foretas når administrator angir enhetens foretrukne domene fra Control Hub. Kun 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 er ikke aktuelt når enheten har et aktivt, eksternt utstedt sertifikat for å identifisere seg selv.

xStatus Conference EndToEndEncryption Tilgjengelighet

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

xStatus-konferansen EndToEndEncryption ExternalIdentity-verifisering

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

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Identiteten til enheten som lest fra det eksternt utstedte sertifikatets Common Name.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # spesifikk informasjon

Leser spesifikk informasjon fra et eksternt utstedt sertifikat.

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

  • Fingeravtrykk

  • IkkeEtter sluttdato for gyldighet

  • IkkeFør startdato for gyldighet

  • PrimaryName

  • PublicKeyAlgorithm

  • Serienummer

  • Signaturalgoritme

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

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

xStatus-konferansen EndToEndEncryption ExternalIdentity Status

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

xStatus-konferansen EndToEndEncryption InternalIdentity-verifisering

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

xStatus-konferanse EndToEndEncryption InternalIdentity Identity

Identiteten til enheten som lest fra det Webex-utstedte sertifikatets Common Name.

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

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # spesifikk informasjon

Leser bestemt informasjon fra det Webex-utstedte sertifikatet.

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

  • Fingeravtrykk

  • IkkeEtter sluttdato for gyldighet

  • IkkeFør startdato for gyldighet

  • PrimaryName

  • PublicKeyAlgorithm

  • Serienummer

  • Signaturalgoritme

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

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

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

API-kall

Beskrivelse

x Deltakerliste for deltakerkonferanse i arrangement lagt til

xEvent Conference DeltakerListe DeltakerUpdated

x Deltakerliste for deltaker i arrangementskonferansen er slettet

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 Fyll ut hemmelig: JWEblob

Godtar en base64url-kodet ren tekstverdi for visning 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-sikkerhetssertifikater Tjenester 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-sikkerhetssertifikater-tjenester Aktivere Formål:WebexIdentity FingerPrint: JWEblob

Aktiverer et bestemt sertifikat for WebexIdentity. For dette Formål , krever kommandoen at det identifiserende fingeravtrykket krypteres og serialiseres i en JWE-blob.

xCommand Security Certificates Services Deaktivere Formål:WebexIdentity Fingerprint: JWEblob

Deaktiverer et bestemt sertifikat for WebexIdentity. For dette Formål , krever kommandoen at det identifiserende fingeravtrykket krypteres og serialiseres i en JWE-blob.