Brukeropplevelse

Brukere velger den nye møtetypen når de planlegger et møte. Når du tar inn deltakere fra lobbyen og i løpet av møtet, kan verten se status for identitetsbekreftelse for 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:

Bekrefte identitet med intern eller ekstern CA

Bekrefte identitet

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

Brukere av Webex Meetings-appen godkjenner seg selv mot Webex-identitetslageret, som gir dem et tilgangstoken når de lykkes. Hvis de trenger et sertifikat for å bekrefte identiteten deres i et ende-til-ende-kryptert møte, utsteder Webex CA et sertifikat til dem basert på tilgangstokenet. Vi gir ennå ikke en måte for å gi Webex Meetings-brukere et sertifikat utstedt av en tredjepart / ekstern CA.

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

  • For den interne sertifiseringsinstans utsteder Webex et internt sertifikat basert på tilgangstokenet for 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 domene(r) når de skriver enhetssertifikatets identitet (Vanlig navn (CN)).

  • I tilfellet med ekstern CA, ber du om og kjøper 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 verifisert identitet, og forhindre den teoretiske muligheten for at Cisco kan tyvlytte 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 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. Vanlig navn (CN) og alternativt navn for emne (SAN) vises i brukergrensesnittet for Webex-møte, som beskrevet i Ende-til-ende-kryptering med identitetsbekreftelse for Webex-møter.

Det anbefales å bruke et separat sertifikat for hver enhet og ha et unikt CN for hver enhet. Dette kan for eksempel være «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 sikkert via xAPI. Dette er for øyeblikket begrenset til nettbaserte enheter.

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

Funksjoner og begrensninger

Enheter

Skyregistrerte enheter i Webex Room-serien og Webex Desk-serien kan bli med på ende-til-ende-krypterte møter, inkludert:

  • Webex Board

  • Webex Desk Pro

  • Webex Desk

  • Webex Room Kit

  • Webex Room Kit Mini

Følgende enheter kan ikke koble til ende-til-ende-krypterte møter:

  • Webex C-serien

  • Webex DX-serien

  • Webex EX-serien

  • Webex MX-serien

  • Tredjeparts SIP-enheter

Programvareklienter

  • Fra 41.6 kan Webex Meetings-skrivebordsklienten bli med på ende-til-ende-krypterte møter.

  • Hvis organisasjonen tillater at Webex-appen blir 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 ingen Control Hub-alternativer for deg så du kan administrere eksternt bekreftet enhetsidentitet. Denne beslutningen er som utformet, fordi det ved ekte ende-til-ende-kryptering, kun bør være du som kjenner til / har 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.

  • Vi tilbyr for øyeblikket ingen verktøy som hjelper deg med å be om eller kryptere enheters identitetssertifikater og deres private nøkler. For tiden tilbyr vi en «oppskrift» så du kan utforme dine egne verktøy, basert på bransjestandardens krypteringsteknikker, for å hjelpe deg med disse prosessene. 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 medietjenestene våre å transkode 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.

Hovedårsaken til dette er forskjellen mellom måten Control Hub og nettstedsadministrasjon administrerer identitet på. Control Hub-organisasjoner har sentralisert identitet for hele organisasjonen, mens identiteten i nettstedsadministrasjon kontrolleres på nettstedbasis.

Dette betyr at du ikke kan ha det Cisco-bekreftede identitetsalternativet for brukere som administreres fra nettstedsadministrasjon. 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 identitet.

Ytterligere ressurser

Relatert informasjon

Avlede eksempler på JWE-blober

Eksempel på korrekt kryptert JWE basert på gitte parametere (tillegg)

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 Webex Meetings og Events på Webex-nettstedet.

Hente enhetssertifikater

Du kan hoppe over dette trinnet hvis du ikke trenger ekstern bekreftet identitet.

For høyeste nivå av sikkerhet og identitetsbekreftelse bør hver enhet ha et unikt sertifikat utstedt av en klarert offentlig sertifiseringsinstans.

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, er dette parameterne som skal brukes:

  • 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 men det velger du selv.

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

Forberede deg på å innlemme 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å. Det er tryggest å ikke engang koble dem til nettverket ennå.

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

  • Lagre eksisterende konfigurasjon 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, tillater du at videosystemer blir med Meetings og Events på Webex-nettstedet.

Forstå ekstern identitetsprosess for enheter

Hvis du vil sikre at enhetsmediet ikke kan krypteres av andre enn enheten, må du kryptere privatnøkkelen på enheten. Vi utformet API-er for enheten for å muliggjøre administrasjon av den krypterte nøkkelen og sertifikatet ved bruk 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, er din plikt å:

  • Be om sertifikatene dine.

  • Generere sertifikatenes nøkkelpar.

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

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

    Nedenfor forklarer vi prosessen og de (ikke-hemmelige) parameterne du trenger, samt en oppskrift du følger 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.

  • Sett sammen og krypter sertifikatet og nøkkelen ved bruk av verktøyet og enhetens første hemmelighet.

  • Last opp den resulterende JWE-bloben til enheten.

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

  • (Anbefales) Gi et grensesnitt til (eller distribuer) verktøyet ditt, slik at enhetsbrukere kan endre den første hemmeligheten (for å 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 å lage blobene fra sertifikatene og nøklene dine.

Du må henvise til JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516 og JSON Web Signature (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Vi valgte å bruke kompakt serialisering av et JSON-dokument for opprette JWE-blober. Parameterne du må inkludere når du oppretter JWE-blobene, 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. ​ 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" chifferkodeteksten er en PEM-blob som inneholder sertifikatet og privatnøkkelen (sammenslått)

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

    • Med " "cisco-action":"deactivate" chifferkodeteksten er fingeravtrykket (heksadesimal representasjon av sha-1) for 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 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 Counter Mode). 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 ny økttype

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.

På den siden skal du 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. Forsikre deg om at du har _VOIPonly-versjonen 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 navn på offentlige tjenester for disse økttypene i fremtiden, for eksempel planlegger vi å endre Pro-End til End Encryption_VOIPonly til E2E Encryption + Identity.
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.

Aktivere E2EE-møter for individuelle brukere

1

Klikk på Brukere, og velg en bruker for å åpne brukerens konfigurasjonspanel.
2

Gå til Tjenester-området og klikk på Cisco Webex Meetings.
3

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

Merk av i boksen ved siden Webex Meetings-oppføringen merket 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 alternativet CSV-gruppe.

Aktivere E2EE-møter for flere brukere

1

Logg på Control Hub på https://admin.webex.com og åpne Møte-siden.
2

Klikk på nettstednavnet for å åpne nettstedkonfigurasjonspanelet.
3

I delen Lisenser og brukere klikker du på Gruppeadministrasjon.
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 på 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.

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

Innfasing av enheter (intern sertifiseringsinstans)

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

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, velger vi et, og det kan se feil ut for andre møtedeltakere.

Før du starter

Hvis enhetene dine ennå ikke er innfaset, kan du følge Registrere en enhet til Cisco Webex ved bruk av API eller lokalt webgrensesnitt eller Skyinnfasing for enheter. Du bør også kontrollere domenet/domenene du vil bruke til å identifisere enhetene i Administrere enhetene dine.

1

Logg på Control Hub (https://admin.webex.com) og åpne Enheter-siden.
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 starter

Du må:

  • skaffe et CA-signert sertifikat og en privatnøkkel, i .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 denne – du kan ikke gjenopprette den og må tilbakestille enheten til fabrikkstandard 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: True
your..JWE.str.ing\n
.\n
5

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

Kopier fingeravtrykket til det nye sertifikatet.
6

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.

Teste E2EE-kryptering og verifisert identitet

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

Vanlige spørsmål om Zero-Trust-møter

Kommer snart.

Ø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 bestemt informasjon fra et eksternt utstedt sertifikat.

I kommandoen som vises, erstatter du # 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 emnene 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.

I kommandoen som vises, erstatter du # 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 emnene 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.