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

Del følgende informasjon med møtevertene:

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

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

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

  • For den interne sertifiseringsinstanssaken utsteder Webex et internt sertifikat basert på tilgangstokenet for enhetens maskinkonto. Sertifikatet er signert av Webex CA. Enheter har ikke bruker-IDer på samme måte som brukere, så Webex bruker (ett av) organisasjonens domene(r) når de skriver enhetssertifikatets identitet (Fellesnavn (CN)).

  • For det eksterne CA-tilfellet 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 det er nødvendig. For enheter inkluderer sertifikatet konto-IDen og et domene.

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

Hvis organisasjonen har flere domener, kan du bruke Kontrollhub til å fortelle Webex hvilket domene enheten skal bruke for identiteten. Du kan også bruke API-et xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

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

Eksternt utstedt enhetssertifikat

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

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

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

Det anbefales å bruke et separat sertifikat per enhet og ha et unikt tilkoblet nettverk per 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 online enheter.

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

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

  • Webex romsett

  • Webex Rom 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.7 kan Webex Meetings-skrivebordsklienten bli med på ende-til-ende-krypterte møter.

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

    Hvis organisasjonen gjør det mulig for Webex-appen å bli med i møter ved å starte skrivebordsprogrammet Møter, kan du bruke dette alternativet til å bli med i ende-til-ende-krypterte møter.

  • Webex-webklienten 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 for å administrere eksternt bekreftet enhetsidentitet. Denne beslutningen er standard, fordi for ekte ende-til-ende-kryptering, bør du bare vite / 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.

  • Vi tilbyr for øyeblikket ingen verktøy som hjelper deg med å be om eller kryptere enhetsidentitetssertifikatene og deres private nøkler. For tiden tilbyr vi en "oppskrift" for deg å designe dine egne verktøy, basert på bransjestandard krypteringsteknikker, for å hjelpe deg med disse prosessene. Vi ønsker ikke å ha noen reell eller oppfattet tilgang til dine hemmeligheter eller nøkler.

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 å kode mediestrømmene. Hvis vi ikke kan dekryptere, omkode 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 forskyver invitasjonene mellom enheter og møteklienter.

Administrasjonsgrensesnitt

Vi anbefaler på det sterkeste at du bruker Kontrollhub til å administrere møteområdet.

Hovedårsaken til dette er forskjellen mellom måten Control Hub og Site Administration administrerer identitet på. Control Hub-organisasjoner har sentralisert identitet for hele organisasjonen, mens identiteten i Områdeadministrasjon kontrolleres på områdebasis.

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

Relatert informasjon

Avlede eksempel på JWE-blober

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

  • Webex møter 41.7.

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

  • Administrativ tilgang til møteområdet i Kontrollhub 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).

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

For høyeste sikkerhetsnivå 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 privatnøklene. Når du ber om sertifikatet, er dette parameterne som skal brukes:

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

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

  • Vanlig navn (CN) og alternativt navn/s for emne (SAN/s): 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/s. Du vil kanskje bruke navn som name.model@example.com men det er ditt valg.

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

  • Hensikt: 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 omfatter ikke signeringsnøkkelen. Sertifiseringsinstansen kan bruke en RSA-nøkkel til å signere sertifikatet.

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 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 reiser i ren tekst, og at du går på kompromiss med sikkerheten din.

Hvis du vil sikre at enhetsmediet ikke kan krypteres av andre enn enheten, må du kryptere privatnø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, er onus på deg for å:

  • Be om sertifikatene dine.

  • Generer sertifikatenes nøkkelpar.

  • Opprett (og beskytt) en innledende hemmelighet for hver enhet, for å frø enhetens krypteringsfunksjonalitet.

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

    Nedenfor forklarer vi prosessen og de (ikke-hemmelige) parametrene du trenger, og en oppskrift å 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.

  • Kjede sammen og krypter sertifikatet og nøkkelen ved hjelp 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 for å (eller distribuere) verktøyet slik at enhetsbrukere kan endre den første hemmeligheten (for å beskytte mediene mot deg!).

Hvordan vi bruker 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å referere 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 Compact Serialization av et JSON-dokument for å lage JWE-blober. Parameterne du må inkludere når du oppretter JWE-blobene, er:

  • JOSE-hode (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":"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 det kan ta. Vi introduserte denne nøkkelen for å signalisere formålet med de krypterte dataene til målenheten. Verdiene er oppkalt etter xAPI-kommandoene på enheten der du bruker de krypterte dataene.

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

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

      En annen proprietær nøkkel. Vi bruker verdiene du oppgir som innganger for nøkkelavledning på enheten. Den version 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 velge tilfeldig.

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

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

  • 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. Ulike xAPI-kommandoer forventer forskjellige nyttelaster, og du må angi formålet med nyttelasten med cisco-action-tasten, 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 (sammenkoblet)

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

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

  • JWE-godkjenningskode: Dette feltet inneholder godkjenningstaggen for å fastslå integriteten til hele JWE-kompakt serialiserte BLOB-filen

Hvordan vi henter krypteringsnøkkelen fra ClientSecret

Etter den første befolkningen i hemmeligheten godtar eller sender vi ikke hemmeligheten som ren tekst. Dette er 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 samme salt når du angir cisco-kdf parameter.

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

  • Maksimal minnehette er 64 MB

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

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 en fullstendig sertifikat + nøkkel). Klienthemmeligheten i eksemplet er ossifrage.

  1. Velg en krypteringschiffer. I dette eksemplet brukes A128GCM(AES med 128-biters taster i Galois Counter Mode). Verktøyet kan bruke A256GCM hvis du foretrekker det.

  2. Velg et salt (må være en tilfeldig sekvens på minst 4 byte). Dette eksemplet bruker (heksale byte) E5 E6 53 08 03 F8 33 F6. Base64url koder sekvensen for å få 5eZTCAP4M_Y(fjern base64-polstringen).

  3. Her er et eksempel scrypt kall til å 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 hvilken 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 hvilken base64url koder til NLNd3V9Te68tkpWD.

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

    {"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 tagg. 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-hode som ekstra godkjente data (AAD)

    Base64url koder den krypterte nyttelasten, noe som skal resultere i f5lLVuWNfKfmzYCo1YJfODhQ

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

  9. Base64url koder 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 har 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 nullklareringsmøter som vi ruller ut til alle møtesider uten ekstra kostnad. En av de nye økttypene kalles Pro-End to End Encryption_VOIPonly. Dette er navnet på den offentlige tjenesten som vi kan endre i fremtiden. Hvis du vil se gjeldende navn på økttypene, kan du se Økttype-IDer under Referanse i denne artikkelen.

Det er ingenting du trenger å gjøre for å få den nye funksjonen for området, men du må gi den nye økttypen (også kalt Møterettighet) til brukere. Du kan gjøre dette individuelt gjennom brukerens konfigurasjonsside, eller i bulk med en CSV-eksport / importtur.

1

Logg på Kontrollhub, og åpne Møte-siden.

2

Klikk områdenavnet for å åpne konfigurasjonspanelet for området.

3

Klikk Konfigurer område.

4

Klikk Økttyper under Vanligeinnstillinger.

På den siden skal du se én eller flere ende-til-ende-krypteringsøkttyper. Se listen over økttype-IDer under Referanse i denne artikkelen. Det kan for eksempel hende at Pro-End to End Encryption_VOIPonly.

 

Det finnes en eldre økttype med et svært likt navn: Pro-End til slutt-kryptering. Denne økttypen inkluderer ikke-kryptert PSTN-tilgang til møter. Kontroller at du har den _VOIPonly versjonen for å sikre ende-til-ende-kryptering. Du kan sjekke ved å holde markøren over PRO-koblingen i øktkodekolonnen. 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.

Hva du skal gjøre videre

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

1

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

2

Klikk Cisco Webex Meetings i Tjenester-området.

3

Velg området (hvis brukeren er i mer enn én) og klikk Vert.

4

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

1

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

2

Klikk områdenavnet for å åpne områdekonfigurasjonspanelet.

3

Klikk Masseoppdeling under Lisenser og brukere.

4

Klikk Eksporter , og vent mens vi klargjørfilen.

5

Når filen er klar, klikker du Eksporter resultater og deretter 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 inneholder økttype-IDene 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 celle.

CSV-filformatreferansen https://help.webex.com/en-us/5vox83 har noen detaljer om formålet med og innholdet i CSV-filen.

8

Åpne konfigurasjonspanelet for møteområdet i Kontrollpanel.

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

9

Klikk Masseutdeling under Lisenser og brukere.

10

Klikk Importer og velg den redigerte CSV-filen, og klikk deretter Importer. Vent mens vi laster opp filen.

11

Når importen er fullført, kan du klikke 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.

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 bare nødvendig hvis du har flere domener i Control Hub-organisasjonen. Hvis du har mer enn ett domene, anbefaler vi at du gjør dette for alle enhetene dine som har identiteten "Cisco-verifisert". Hvis du ikke forteller Webex hvilket domene som identifiserer enheten, velger vi et, og det kan se galt ut for andre møtedeltakere.

Før du begynner

Hvis enhetene dine ennå ikke er ombord, kan du følge https://help.webex.com/n25jyr8 eller https://help.webex.com/nutc0dy. Du bør også kontrollere domenet/domenene du vil bruke til å identifisere enhetene (https://help.webex.com/cd6d84).

1

Logg på Kontrollhub (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.

Før du begynner

Du trenger:

  • Hvis du vil ha et ca-signert sertifikat og privatnøkkel, i PEM-format, for hver enhet.

  • Hvis du vil lese emnet Forstå ekstern identitetsprosess for enheter, i delen Klargjøre en del av denne artikkelen.

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

  • Et verktøy for å generere tilfeldige bytesekvenser med gitte lengder.

  • Et verktøy for å basere64url 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 koder 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 uttrykket 0123456789abcdef. Du må velge din egen.

Enheten har sin opprinnelige hemmelighet. Ikke glem dette, du kan ikke gjenopprette det og må tilbakestille enheten til fabrikk for å starte på nytt.
2

Kjede sammen sertifikatet og privatnøkkelen:

  1. Bruk et tekstredigeringsprogram til å åpne PEM-filene, lime inn nøkkel-BLOB-filen for sertifikatbloben 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 finnes noen andre faste verdier å angi (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. Opprette et JOSE-hode, angi alg, enc og cisco-kdf som beskrevet i Forstå ekstern identitetsprosess for enheter. Angi legg til-handlingen ved hjelp av nøkkelen:verdi "cisco-action":"add" i JOSE-overskriften (fordi vi legger til sertifikatet på enheten).

  5. Base64url koder JOSE-hodet.

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

  7. Base64url koder initialiseringsvektoren, den krypterte PEM-nyttelasten og godkjenningstaggen.

  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 kommandoen (flerlinjet) legg til:

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

Kontroller 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 finnes noen andre faste verdier å angi (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 koder sekvensen. Dette er initialiseringsvektoren din.

  5. Opprette et JOSE-hode, angi alg, enc og cisco-kdf som beskrevet i Forstå ekstern identitetsprosess for enheter. Angi aktiveringshandlingen ved hjelp av nøkkelen:verdi "cisco-action":"activate" i JOSE-overskriften (fordi vi aktiverer sertifikatet på enheten).

  6. Base64url koder JOSE-hodet.

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

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

  8. Base64urlencode det krypterte fingeravtrykket og godkjenningstaggen.

  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

Start enheten ombord i Control Hub-organisasjonen.

1

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

2

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

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.

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.

7

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

8

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

9

Som vert, innrøm 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 i møtet med en ny deltaker.

13

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

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 seg? 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 du kan forvente i møtet.

Trenger 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. Du kan bare 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 bli med først for brukere som blir med på sikre enheter, og angi brukerforventninger 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.

Hvis du bruker en ekstern sertifiseringsinstans til å utstede enhetssertifikater, er onusen på deg 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 å gjøre dem i stand til å gjøre dette.

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

Type-ID for økt

Navn på offentlig tjeneste

638

Bare E2E-kryptering+VoIP

652

Pro-End til ende-Encryption_VOIPonly

660

Pro 3 gratis ende-til-ende-Encryption_VOIPonly

E2E-kryptering + identitet

672

Pro 3 Free50-Ende-til-ende-Encryption_VOIPonly

673

Utdanningsinstruktør E2E Encryption_VOIPonly

676

Broadworks Standard pluss ende-til-ende-kryptering

677

Broadworks Premium pluss ende-til-ende-kryptering

681

Schoology Free pluss ende-til-ende-kryptering

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 lese mer om hvordan du bruker APIen, kan du se https://help.webex.com/nzwo1ok.

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

API-kall

Beskrivelse

xConfiguration Conference EndToEndEncryption Mode: On

Gjør slutt på krypteringsmodus On eller Off.

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Denne konfigurasjonen gjøres når administratoren angir enhetens foretrukne domene fra Kontrollhub. 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 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 Valid

Angir om enheten har et gyldig eksternt utstedt sertifikat.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Identiteten til enheten som lest fra det eksternt utstedte sertifikatets fellesnavn.

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Leser sertifikatinformasjonen fra det eksternt utstedte sertifikatet og sender det som en JSON-blob.

xStatus Conference EndToEndEncryption InternalIdentity Valid

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

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 CertInfo

Leser sertifikatinformasjonen fra det Webex-utstedte sertifikatet og sender det som en JSON-blob.

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

API-kall

Beskrivelse

xStatus Call # ServerEncryption Type

Leser krypteringschifferen som brukes i HTTPS-tilkoblingen til Webex. Dette vises for brukeren.

xStatus Conference Call # EndToEndEncryption Status

Leser ende-til-ende-krypteringsstatusen for kall. Vises for brukeren som tilstedeværelsen (eller fraværet) av hengelåsikonet.

xStatus Conference Call # EndToEndEncryption SecurityCode

Leser sikkerhetskoden for møtet. Dette vises for brukeren, og det endres når deltakerne blir med.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Leser krypteringschifferen som brukes i medietilkoblingen. Dette vises for brukeren.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Leser krypteringschifferen som brukes for Messaging Layer Security (MLS).

xStatus Conference Call # EndToEndEncryption Roster Participant

Viser deltakerne som bidrar til MLS-gruppestatusen i dette møtet. Listen oppdages av MLS, ikke Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

WDM-URL-adressen til en angitt deltaker.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

Verifiseringsstatusen til den angitte deltakeren.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

Den primære identiteten til den angitte deltakeren, vanligvis et domene (en enhet) eller en e-postadresse (bruker).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

Visningsnavnet til den angitte deltakeren. Signert av deltakeren/enheten.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

Sertifikatinformasjonen fra den angitte deltakerens sertifikat som en JSON-blob.

xCommand Conference ParticipantList Search

Vi utvidet denne kommandoen til å inkludere ende-til-ende-krypteringsinformasjon for deltakere.

xCommand Conference ParticipantList Search

Deltakerlistesøket inkluderer nå EndToEndEncryptionStatus, deltakerens status for identitetsbekreftelse. Denne verdien vises i brukergrensesnittet.

xCommand Conference ParticipantList Search

Deltakerlistesøket inkluderer nå EndToEndEncryptionIdentity, deltakerens primære identitet. Dette er vanligvis et domene eller en e-postadresse. Denne verdien vises i brukergrensesnittet.

xCommand Conference ParticipantList Search

Deltakerlistesøket inkluderer nå EndToEndEncryptionCertInfo, JSON-bloben som inneholder deltakerens sertifikat. Denne verdien vises i brukergrensesnittet.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

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

Tabell 4. ClientSecret-relaterte APIer 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 såing 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.