Brugeroplevelse

Brugere vælger mødetypen, når de planlægger et møde. Når deltagere får adgang fra lobbyen såvel som under mødet, kan værten se status for identitetsbekræftelse for hver deltager. Der er også en mødekode, der er fælles for alle aktuelle mødedeltagere, som de kan bruge til at bekræfte, at deres møde ikke er blevet opsnappet af en uønsket tredjepart Meddler In The Middle (MITM) angreb.

Del følgende oplysninger med dine mødeværter:

Identitetsbekræftelse med internt eller eksternt nøglecenter

Bekræft identitet

Slutpunkt-til-slutpunkt-kryptering med identitetsbekræftelse giver yderligere sikkerhed for et slutpunkt-til-slutpunkt-krypteret møde.

Når deltagere eller enheder deltager i en delt MLS-gruppe (Messaging Layer Security), præsenterer de deres certifikater for de andre gruppemedlemmer, som derefter validerer certifikatmyndighederne (CA). Ved at bekræfte, at certifikaterne er gyldige, bekræfter CA deltagernes identitet, og mødet viser deltagerne/enhederne som bekræftet.

Brugere af Webex-appen godkender sig selv i Webex-identitetslageret, hvilket giver dem et adgangstoken, når godkendelsen lykkes. Hvis de har brug for et certifikat for at bekræfte deres identitet i et slutpunkt-til-slutpunkt-krypteret møde, udsteder Webex-nøglecentret dem et certifikat baseret på deres adgangstoken. På nuværende tidspunkt tilbyder vi ikke en måde, hvorpå Webex Meetings-brugere kan få et certifikat udstedt af en tredjepart/ekstern certifikatmyndighed.

Enheder kan godkende sig selv ved hjælp af et certifikat, der er udstedt af det interne (Webex) CA, eller et certifikat, der er udstedt af en ekstern CA:

  • Internt nøglecenter – Webex udsteder et internt certifikat baseret på adgangstokenet for enhedens maskinkonto. Certifikatet er signeret af Webex-nøglecenteret. Enheder har ikke bruger-id'er på samme måde som brugere, så Webex bruger (et af) din organisations domæner, når enhedens certifikatidentitet skrives (Common Name (CN)).

  • Ekstern CA – anmod om og køb enhedscertifikater direkte fra din valgte udsteder. Du skal kryptere, uploade og godkende certifikaterne direkte ved hjælp af en hemmelighed, som kun du kender.

    Cisco er ikke involveret, hvilket gør dette til en måde at garantere ægte slutpunkt-til-slutpunkt-kryptering og bekræftet identitet og forhindre den teoretiske mulighed for, at Cisco kan lytte efter i dit møde/dekryptere dine medier.

Internt udstedt enhedscertifikat

Webex udsteder et certifikat til enheden, når den registreres efter opstart, og fornyer den, når det er nødvendigt. For enheder omfatter certifikatet konto-id'et og et domæne.

Hvis din organisation ikke har et domæne, udsteder Webex-nøglecentret certifikatet uden et domæne.

Hvis din organisation har flere domæner, kan du bruge Control Hub til at fortælle Webex, hvilket domæne enheden skal bruge til sin identitet. Du kan også bruge API'en xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Hvis du har flere domæner og ikke indstiller det foretrukne domæne for enheden, vælger Webex et for dig.

Eksternt udstedt enhedscertifikat

En administrator kan klargøre en enhed med sit eget certifikat, der er blevet signeret med en af de offentlige nøglecentre.

Certifikatet skal være baseret på et ECDSA P-256-nøglepar, selvom det kan signeres med en RSA-nøgle.

Værdierne i certifikatet er efter organisationens skøn. Det fælles navn (CN) og det alternative emnenavn (SAN) vises i brugergrænsefladen for Webex-møder, som beskrevet i Slutpunkt-til-slutpunkt-kryptering med identitetsbekræftelse til Webex Meetings.

Vi anbefaler, at du bruger et separat certifikat pr. enhed og har et unikt CN pr. enhed. For eksempel "meeting-room-1.example.com" for den organisation, der ejer "example.com"-domænet.

For fuldt ud at beskytte det eksterne certifikat mod manipulation bruges en klienthemmelig funktion til at kryptere og underskrive forskellige xkommandoer.

Når du bruger klienthemmeligheden, er det muligt på sikker vis at administrere det eksterne Webex-identitetscertifikat via xAPI. Dette er i øjeblikket begrænset til onlineenheder.

Webex leverer i øjeblikket API-kommandoer til administration af dette.

Funktioner og begrænsninger

Enheder

Følgende cloud-registrerede enheder i Webex Room-serien og Webex Desk-serien kan deltage i E2EE-møder:

  • Webex Board

  • Webex Desk Pro

  • Webex-skrivebord

  • Webex-rumsæt

  • Webex-rumsæt Mini

Følgende enheder kan ikke deltage i E2EE-møder:

  • Webex C-serien

  • Webex DX-serien

  • Webex EX-serien

  • Webex MX-serien

  • SIP-enheder fra tredjepart

Softwareklienter

  • Webex-appen til desktop og mobilklienter kan deltage i E2EE-møder.

  • Webex-webklienten kan ikke deltage i E2EE-møder.

  • SIP-softwareklienter fra tredjepart kan ikke deltage i E2EE-møder.

Identitet

  • Pr. design giver vi ikke Control Hub-valgmuligheder, så du kan administrere eksternt bekræftet enhedsidentitet. For ægte slutpunkt-til-slutpunkt-kryptering er det kun dig, der kender/har adgang til hemmeligheder og nøgler. Hvis vi introducerede en cloud-tjeneste til at administrere disse nøgler, er der en chance for, at de bliver opfanget.

  • I øjeblikket leverer vi en "opskrift", som du kan bruge til at designe dine egne værktøjer, baseret på branchens standardkrypteringsteknikker, til at hjælpe med at anmode om eller kryptere dine enhedsidentitetscertifikater og deres private nøgler. Vi ønsker ikke at have nogen reel eller opfattet adgang til dine hemmeligheder eller nøgler.

Møder

  • E2EE-møder understøtter i øjeblikket maksimalt 1000 deltagere.

  • Du kan dele nye whiteboards i E2EE-møder. Der er nogle forskelle fra whiteboards i almindelige møder:
    • I E2EE-møder kan brugere ikke få adgang til whiteboards, der er oprettet uden for mødet, herunder private whiteboards, whiteboards delt af andre og whiteboards fra Webex-rum.
    • Whiteboards, der er oprettet i E2EE-møder, er kun tilgængelige under mødet. De gemmes ikke og er ikke tilgængelige, når mødet er afsluttet.
    • Hvis nogen deler indhold i et E2EE-møde, kan du kommentere det. Få yderligere oplysninger om kommentering i Webex-app | Marker delt indhold med kommentarer.

Administrationsgrænseflade

Vi anbefaler på det kraftigste, at du bruger Control Hub til at administrere dit Meetings-websted, da Control Hub-organisationer har centraliseret identitet for hele organisationen.

Yderligere ressourcer
Forudsætninger

  • Webex Meetings 41.7.

  • Cloud-registrerede enheder i Webex Room- og Webex Desk-serien, der kører 10.6.1-RoomOS_August_2021.

  • Administrativ adgang til mødewebstedet i Control Hub.

  • Et eller flere bekræftede domæner i din Control Hub-organisation (hvis du bruger Webex CA til at udstede enhedscertifikater for bekræftet identitet).

  • Mødelokaler til samarbejde skal være aktiveret, så folk kan deltage fra deres videosystem. Få flere oplysninger i Tillad videosystemer at deltage i møder og begivenheder på dit Webex-websted.

Hent enhedscertifikater

Du kan springe dette trin over, hvis du ikke har brug for eksternt bekræftede identiteter.

For at opnå det højeste sikkerhedsniveau og til identitetsbekræftelse skal hver enhed have et unikt certifikat udstedt af et pålideligt offentligt nøglecenter (CA).

Du skal interagere med nøglecentret for at anmode om, købe og modtage de digitale certifikater og oprette de tilknyttede private nøgler. Når du anmoder om certifikatet, skal du bruge disse parametre:

  • Certifikatet skal udstedes og underskrives af et velkendt offentligt CA.

  • Entydigt: Vi anbefaler på det kraftigste, at du bruger et unikt certifikat for hver enhed. Hvis du bruger ét certifikat til alle enheder, kompromitterer du din sikkerhed.

  • Fælles navn (CN) og alternativt/alternative emnenavn(er): Disse er ikke vigtige for Webex, men bør være værdier, som mennesker kan læse og knytte til enheden. CN vises for andre mødedeltagere som enhedens primære bekræftede identitet, og hvis brugere inspicerer certifikatet via mødets brugergrænseflade, vil de se SAN(erne). Du kan bruge navne som name.model@example.com.

  • Filformat: Certifikaterne og nøglerne skal være i formatet .pem .

  • Formål: Certifikatets formål skal være Webex Identity.

  • Genererer nøgler: Certifikaterne skal være baseret på ECDSA P-256-nøglepar (Elliptical Curve Digital Signature Algorithm ved hjælp af P-256-kurven).

    Dette krav gælder ikke for signeringsnøglen. CA kan bruge en RSA-nøgle til at underskrive certifikatet.

Forbered dig til onboarding af enheder

Du kan springe dette trin over, hvis du ikke vil bruge eksternt bekræftet identitet med dine enheder.

Hvis du bruger nye enheder, skal du endnu ikke registrere dem i Webex. For at være sikker skal du ikke forbinde dem til netværket på nuværende tidspunkt.

Hvis du har eksisterende enheder, som du vil opgradere for at bruge eksternt bekræftet identitet, skal du fabriksnulstille enhederne.

  • Gem den eksisterende konfiguration, hvis du vil beholde den.

  • Planlæg et vindue, når enhederne ikke bruges, eller brug en faseinddelt tilgang. Giv brugerne besked om de ændringer, de kan forvente.

  • Sørg for fysisk adgang til enheder. Hvis du skal have adgang til enheder via netværket, skal du være opmærksom på, at hemmeligheder rejser i almindelig tekst, og at du kompromitterer din sikkerhed.

Når du har fuldført disse trin, skal du tillade videosystemer at deltage i møder og begivenheder på dit Webex-websted.

Forstå enheders eksterne identitetsproces

For at sikre, at dine enhedsmedier ikke kan krypteres af andre end enheden, skal du kryptere den private nøgle på enheden. Vi har designet API'er til enheden for at aktivere administration af den krypterede nøgle og certifikat ved hjælp af JSON Web Encryption (JWE).

For at sikre ægte slutpunkt-til-slutpunkt-kryptering via vores cloud kan vi ikke være involveret i kryptering og overførsel af certifikatet og nøglen. Hvis du har brug for dette sikkerhedsniveau, skal du:

  1. Anmod om dine certifikater.

  2. Generer dine certifikaters nøglepar.

  3. Opret (og beskyt) en indledende hemmelighed for hver enhed for at udforme enhedens krypteringsfunktion.

  4. Udvikl og vedligehold dit eget værktøj til kryptering af filer ved hjælp af JWE-standarden.

    Processen og de (ikke-hemmelige) parametre, du skal bruge, forklares nedenfor, samt en opskrift, der skal følges i dine valgte udviklingsværktøjer. Vi leverer også nogle testdata og de resulterende JWE-blobs, som vi forventer dem, for at hjælpe dig med at bekræfte din proces.

    En ikke-understøttet referenceimplementering ved hjælp af Python3 og JWCrypto-biblioteket er tilgængelig fra Cisco efter anmodning.

  5. Sammenkæd og krypter certifikatet og nøglen ved hjælp af dit værktøj og enhedens indledende hemmelighed.

  6. Overfør den resulterende JWE-blob til enheden.

  7. Indstil formålet med det krypterede certifikat, der skal bruges til Webex-identitet, og aktivér certifikatet.

  8. (Anbefales) Angiv en grænseflade til (eller distribuere) dit værktøj, så enhedsbrugere kan ændre den oprindelige hemmelighed og beskytte deres medier mod dig.

Sådan bruger vi JWE-formatet

Dette afsnit beskriver, hvordan vi forventer, at JWE oprettes som input til enhederne, så du kan oprette dit eget værktøj til at oprette blobs fra dine certifikater og nøgler.

Se JSON-webkryptering (JWE) https://datatracker.ietf.org/doc/html/rfc7516 og JSON-websignatur (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Vi bruger Kompakt serialisering af et JSON-dokument til at oprette JWE-blobs. De parametre, du skal medtage, når du opretter JWE-blobs, er:

  • JOSE-overskrift (beskyttet). I JSON-objektsignering og -kryptering-headeren SKAL du inkludere følgende nøgleværdipar:

    • "alg":"dir"

      Den direkte algoritme er den eneste, vi understøtter til kryptering af nyttelasten, og du skal bruge enhedens indledende klienthemmelighed.

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

      Vi understøtter disse to krypteringsalgoritmer.

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

      Dette er en beskyttet nøgle og fire værdier, den kan tage. Vi introducerede denne nøgle for at signalere formålet med de krypterede data til destinationsenheden. Værdierne navngives efter xAPI-kommandoerne på den enhed, hvor du bruger de krypterede data.

      Vi har navngivet det cisco-action for at afbøde potentielle sammenstød med fremtidige JWE-lokalnumre.

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

      En anden beskyttet nøgle. Vi bruger de værdier, du angiver som input til nøgleafledning på enheden. version skal være 1 (versionen af vores vigtigste afledte funktion). Værdien af salt skal være en base64-URL-kodet sekvens på mindst 4 byte, som du skal vælge tilfældigt.

  • JWE-krypteret nøgle. Dette felt er tomt. Enheden udleder den fra den oprindelige ClientSecret.

  • JWE-initialiseringsvektor. Du skal angive en base64url-kodet initialiseringsvektor for at dekryptere nyttelasten. IV SKAL være en tilfældig værdi på 12 byte (vi bruger AES-GCM-krypteringsfamilien, som kræver, at IV'en er 12 byte lang).

  • JWE AAD (yderligere godkendte data). Du skal udelade dette felt, fordi det ikke understøttes i den kompakte serialisering.

  • JWE-krypteringstekst: Dette er den krypterede nyttelast, som du vil holde hemmelig.

    Nyttelasten kan VÆRE tom. Hvis du f.eks. vil nulstille klienthemmeligheden, skal du overskrive den med en tom værdi.

    Der er forskellige typer nyttelast, afhængigt af hvad du forsøger at gøre på enheden. Forskellige xAPI-kommandoer forventer forskellige nyttelast, og du skal angive formålet med nyttelast med cisco-action nøglen som følger:

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

    • Med ""cisco-action":"add" er krypteringsteksten en PEM-blob, der bærer certifikatet og dets private nøgle (sammenkædet).

    • Med ""cisco-action":"activate" er krypteringsteksten fingeraftrykket (hexadecimal gengivelse af sha-1) af certifikatet, som vi aktiverer til bekræftelse af enhedsidentitet.

    • Med ""cisco-action":"deactivate" er krypteringsteksten fingeraftrykket (hexadecimal gengivelse af sha-1) af certifikatet, som vi deaktiverer fra at blive brugt til bekræftelse af enhedsidentitet.

  • JWE-godkendelsesmærke: Dette felt indeholder godkendelsestegnet til at kontrollere integriteten af hele JWE-serialiserede blob kompakt

Hvordan vi udleder krypteringsnøglen fra ClientSecret

Efter den første population af hemmeligheden accepterer eller udgiver vi ikke hemmeligheden som almindelig tekst. Dette er for at forhindre potentielle overgreb i ordbogen fra personer, der har adgang til enheden.

Enhedssoftwaren bruger klienthemmeligheden som et input til en nøgleafledt funktion (kdf) og bruger derefter den afledte nøgle til dekryptering/kryptering af indhold på enheden.

Hvad dette betyder for dig, er, at dit værktøj til at producere JWE-blobs skal følge den samme procedure for at udlede den samme kryptering/dekrypteringsnøgle fra klienthemmeligheden.

Enhederne bruger scrypt til nøgleafledning (se https://en.wikipedia.org/wiki/Scrypt) med følgende parametre:

  • Omkostningsfaktor (N) er 32768

  • BlockSizeFactor (r) er 8

  • Paralleliseringsfaktor (p) er 1

  • Salt er en tilfældig sekvens på mindst 4 byte. Du skal angive den samme salt når du angiver cisco-kdf parameteren.

  • Nøglelængder er enten 16 byte (hvis du vælger AES-GCM 128-algoritmen) eller 32 byte (hvis du vælger AES-GCM 256-algoritmen)

  • Maks. hukommelsesgrænse er 64 MB

Dette sæt parametre er den eneste konfiguration af scrypt , der er kompatibel med funktionen til nøgleafledning på enhederne. Denne kdf på enhederne kaldes "version":"1", som er den eneste version, der i øjeblikket tages af cisco-kdf parameteren.

Eksempel på arbejde

Her er et eksempel, som du kan følge for at bekræfte, at din JWE-krypteringsproces fungerer på samme måde som den proces, vi oprettede på enhederne.

Eksempelscenariet er at tilføje en PEM-blob til enheden (efterligner tilføjelse af et certifikat med en meget kort streng i stedet for en fuld certifikatnøgle + nøgle). Klienthemmeligheden i eksemplet er ossifrage.

  1. Vælg en krypteringskode. Dette eksempel bruger A128GCM (AES med 128-bit taster i Galois-tællertilstanden). Dit værktøj kan bruge, A256GCM hvis du foretrækker det.

  2. Vælg et salt (skal være en tilfældig sekvens på mindst 4 byte). Dette eksempel bruger (hex byte)E5 E6 53 08 03 F8 33 F6. Base64url-adresse koder sekvensen for at få 5eZTCAP4M_Y (fjern base64-padding).

  3. Her er et eksempel scrypt på et opkald til at oprette indholdskrypteringsnøglen (cek):

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

    Den afledte nøgle skal være 16 byte (hex) som følger:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac som base64url koder til lZ66bdEiAQV4_mqdInj_rA.

  4. Vælg en tilfældig sekvens på 12 byte, der skal bruges som en initialiseringsvektor. Dette eksempel bruger (hex), 34 b3 5d dd 5f 53 7b af 2d 92 95 83 som base64url koder til NLNd3V9Te68tkpWD.

  5. Opret JOSE-headeren med kompakt serialisering (følg den samme rækkefølge af parametre, som vi bruger her) og kode den derefter base64url:

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

    Base64url-kodet JOSE-header er eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Det bliver det første element i JWE-blob.

  6. Det andet element i JWE-blob er tomt, fordi vi ikke leverer en JWE-krypteringsnøgle.

  7. Det tredje element i JWE-blob er initialiseringsvektoren NLNd3V9Te68tkpWD.

  8. Brug dit JWE-krypteringsværktøj til at oprette en krypteret nyttelast og tag. I dette eksempel vil den ikke-krypterede nyttelast være den falske PEM-blob this is a PEM file

    De krypteringsparametre, du skal bruge, er:

    • Nyttelast er this is a PEM file

    • Krypteringskoden er AES 128 GCM

    • Base64url-kodet JOSE-header som yderligere godkendte data (AAD)

    Base64url-adresse koder den krypterede nyttelast, som skal resultere i f5lLVuWNfKfmzYCo1YJfODhQ

    Dette er det fjerde element (JWE Ciphertext) i JWE blob.

  9. Base64url koder det tag, du producerede i trin 8, hvilket skulle resultere i PE-wDFWGXFFBeo928cfZ1Q

    Det er det femte element i JWE-blob.

  10. Sammenkæd de fem elementer i JWE blob med prikker (JOSEheader..IV.Ciphertext.Tag) for at få:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Hvis du afledte de samme base64url-kodede værdier, som vi viser her, ved hjælp af dine egne værktøjer, er du klar til at bruge dem til at sikre E2E-krypteringen og den bekræftede identitet af dine enheder.

  12. Dette eksempel vil faktisk ikke fungere, men i princippet er dit næste trin at bruge den JWE-blob, du oprettede ovenfor, som input til xcommand på den enhed, der tilføjer certifikatet:

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

Sessionstyper for zero trust-møder er tilgængelige for alle mødewebsteder uden ekstra omkostninger. En af disse sessionstyper kaldes Pro-End to End Encryption_VOIPonly. Dette er navnet på den offentlige tjeneste, som vi kan ændre i fremtiden. For de aktuelle navne på sessionstyperne, se Sessionstype-id'er i afsnittet Reference i denne artikel.

Der er intet, du skal gøre for at få denne funktion til dit websted. Du skal tildele den nye sessionstype (også kaldet Mødeprivilegium) til brugere. Du kan gøre dette individuelt via brugerens konfigurationsside eller sammen med en CSV-eksport/-import.

Bekræft den nye sessionstype
1

Log ind på Control Hub, og gå til Tjenester > Møde.

2

Klik på Websteder, vælg det Webex-websted, som du vil ændre indstillingerne for, og klik derefter på Indstillinger.

3

Under Almindelige indstillinger skal du vælge Sessionstyper.

Du bør se en eller flere sessionstyper med slutpunkt-til-slutpunkt-kryptering. Se listen over sessionstype-id'er i afsnittet Reference i denne artikel. Du kan f.eks. se Pro-End to End Encryption_VOIPonly.

Der er en ældre sessionstype med et meget lignende navn: Kryptering fra pro-end til slutpunkt. Denne sessionstype inkluderer ikke-krypteret PSTN-adgang til møder. Sørg for, at du har _VOIPonly -versionen for at sikre slutpunkt-til-slutpunkt-kryptering. Du kan kontrollere det ved at holde markøren over linket PRO i sessionskodens kolonne. I dette eksempel skal målet for linket være javascript:ShowFeature(652).

Vi kan ændre public service-navnene for disse sessionstyper i fremtiden.

4

Hvis du endnu ikke har den nye sessionstype, skal du kontakte din Webex-repræsentant.

Hvad der skal ske nu

Aktivér denne sessionstype/mødeprivilegium for nogle eller alle dine brugere.

Aktivér E2EE-møder for individuelle brugere
1

Log ind på Control Hub, og gå til Administration > Brugere.

2

Vælg en brugerkonto, der skal opdateres, og vælg derefter Møder.

3

Fra rullegardinmenuen Indstillingerne gælder for skal du vælge det mødewebsted, der skal opdateres.

4

Markér afkrydsningsfeltet ved siden af Pro-End to End Encryption_VOIPonly.

5

Luk brugerkonfigurationspanelet.

6

Gentag for andre brugere, hvis det er nødvendigt.

For at tildele dette til mange brugere skal du bruge den næste valgmulighed, Aktivér E2EE-møder for flere brugere.

Aktivér E2EE-møder for flere brugere
1

Log ind på Control Hub, og gå til Tjenester > Møde.

2

Klik på Websteder, og vælg det Webex-websted, som du vil ændre indstillingerne for.

3

I afsnittet Licenser og brugere skal du klikke på Masseadministrer.

4

Klik på Generer rapport, og vent, mens vi forbereder filen.

5

Når filen er klar, skal du klikke på Eksporter resultater og derefter på Download. (Du skal lukke pop op-vinduet manuelt, når du har klikket på Download.)

6

Åbn den downloadede CSV-fil til redigering.

Der er en række for hver bruger, og MeetingPrivilege kolonnen indeholder vedkommendes sessionstype-id'er som en kommasepareret liste.

7

For hver bruger, du ønsker at tildele den nye sessionstype, skal du tilføje 1561 som en ny værdi på den kommaseparerede liste i MeetingPrivilege cellen.

Webex CSV-filformatreferencen indeholder oplysninger om CSV-filens formål og indhold.

8

Åbn panelet Konfiguration af mødewebsted i Control Hub.

Hvis du allerede var på listen over mødewebsteder, skal du muligvis opdatere den.

9

I afsnittet Licenser og brugere skal du klikke på Masseadministrer.

10

Klik på Importer , og vælg den redigerede CSV, og klik derefter på Importer. Vent, mens filen uploades.

11

Når importen er færdig, kan du klikke på Importer resultater for at gennemgå, om der var fejl.

12

Gå til siden Brugere , og åbn en af brugerne for at bekræfte, at de har den nye sessionstype.

Tilføj et lydvandmærke for sikkerhed

Du kan føje et vandmærke til mødeoptagelser med Webex Meetings Pro-End to End Encryption_VOIPonly sessionstypen, som giver dig mulighed for at identificere kildeklienten eller -enheden for uautoriserede optagelser af fortrolige møder.

Når denne funktion er aktiveret, inkluderer mødelyden et entydigt id for hver deltagende klient eller enhed. Du kan overføre lydoptagelser til Control Hub, som derefter analyserer optagelsen og finder de entydige id'er op. Du kan se på resultaterne for at se, hvilken kildeklient eller -enhed der har optaget mødet.

  • For at blive analyseret skal optagelsen være en AAC-, MP3-, M4A-, WAV-, MP4-, AVI- eller MOV-fil, der ikke er større end 500 MB.
  • Optagelsen skal være længere end 100 sekunder.
  • Du kan kun analysere optagelser for møder, der hostes af personer i din organisation.
  • Vandmærkeoplysninger bevares i samme varighed som organisationens mødeoplysninger.

Føj lydvandmærker til E2EE-møder

  1. Log ind på Control Hub, og vælg derefter Organisationsindstillinger under Administration.
  2. I afsnittet Mødevandmærker skal du slå Tilføj lydvandmærke til.

    Et stykke tid efter dette er slået til, vil brugere, der planlægger møder med Webex Meetings Pro-End to End Encryption_VOIPonly sessionstypen, se valgmuligheden Digitalt vandmærke i afsnittet Sikkerhed.

Overfør og analysér et vandmærket møde

  1. I Control Hub under Overvågning skal du vælge Fejlfinding.
  2. Klik på Vandmærkeanalyse.
  3. Søg efter eller vælg mødet på listen, og klik på Analysér.
  4. I vinduet Analysér lydvandmærke skal du indtaste et navn til din analyse.
  5. (Valgfri) Indtast en note til din analyse.
  6. Træk og slip lydfilen, der skal analyseres, eller klik på Vælg fil for at gennemse lydfilen.
  7. Klik på Luk.

    Når analysen er færdig, vises den på listen over resultater på siden Analysér vandmærke .

  8. Vælg mødet på listen for at se analyseresultaterne. Klik på Knappen Download for at downloade resultaterne.

Funktioner og begrænsninger

Faktorer, der indgår i en vellykket afkodning af et optaget vandmærke, omfatter afstanden mellem optagelsesenheden og højttaleren, der udsender lyden, lydstyrken af den pågældende lyd, miljøstøj osv. Vores vandmærkningsteknologi har yderligere modstandsdygtighed over for at blive kodet flere gange, som det kan være tilfældet, når mediet deles.

Denne funktion er designet til at muliggøre en vellykket afkodning af vandmærke-identifikatoren under et bredt, men rimeligt sæt omstændigheder. Vores mål er, at en optagelsesenhed, som f.eks. en mobiltelefon, der ligger på et skrivebord i nærheden af et personligt slutpunkt eller en bærbar computer, altid skal oprette en optagelse, der resulterer i en vellykket analyse. Når optagelsesenheden flyttes væk fra kilden eller er skjult fra at høre det fulde lydspektrum, reduceres chancerne for en vellykket analyse.

For at kunne analysere en optagelse er det nødvendigt med et rimeligt billede af mødelyden. Hvis et mødes lyd optages på den samme computer, som er vært for klienten, bør begrænsninger ikke gælde.

Onboardenheder (intern nøglecenter)

Hvis dine enheder allerede er onboardet i din Control Hub-organisation, og du vil bruge Webex CA til automatisk at generere deres identitetscertifikater, behøver du ikke at fabriksnulstille enhederne.

Denne procedure vælger, hvilket domæne enheden bruger til at identificere sig selv, og er kun påkrævet, hvis du har flere domæner i din Control Hub-organisation. Hvis du har mere end ét domæne, anbefaler vi, at du gør dette for alle dine enheder, der har en "Cisco-bekræftet" identitet. Hvis du ikke fortæller Webex, hvilket domæne der identificerer enheden, vælges et automatisk, og det kan se forkert ud for andre mødedeltagere.

Før du begynder

Hvis dine enheder endnu ikke er onboardet, skal du følge Registrer en enhed til Cisco Webex ved hjælp af API eller lokal webgrænseflade eller Onboarding via Cloud for Board-, Desk- og Room-serien. Du skal også bekræfte det/de domæne(er), du vil bruge til at identificere enhederne i Administrer dine domæner.

1

Log ind på Control Hub, og vælg Enheder under Administration.

2

Vælg en enhed for at åbne dets konfigurationspanel.

3

Vælg det domæne, du vil bruge til at identificere denne enhed.

4

Gentag for andre enheder.

Onboarding enheder (ekstern nøglecenter)

Før du begynder

  • Hent et CA-signeret certifikat og en privat nøgle, i .pem format, for hver enhed.

  • Under fanen Forbered skal du læse emnet Forståelse af ekstern identitetsproces for enheder,

  • Forbered et JWE-krypteringsværktøj med hensyn til oplysningerne der.

  • Sørg for, at du har et værktøj til at generere tilfældige byte-sekvenser af givne længder.

  • Sørg for, at du har et værktøj til at base64url-kode byte eller tekst.

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

  • Sørg for, at du har et hemmeligt ord eller en hemmelig sætning for hver enhed.

1

Udfyld enhedens ClientSecret hemmelighed med almindelig tekst:

Første gang du udfylder Secret, leverer du den i almindelig tekst. Det er derfor, vi anbefaler, at du gør dette på konsollen for den fysiske enhed.

  1. Base64url-adresse koder den hemmelige sætning for denne enhed.

  2. Åbn TShell på enheden.

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

    Eksempelkommandoen ovenfor udfylder Secret med sætningen 0123456789abcdef. Du skal vælge din egen.

Enheden har sin oprindelige hemmelighed. Glem ikke dette. Du kan ikke gendanne det og skal fabriksnulstille enheden for at starte igen.
2

Tilknyt dit certifikat og din private nøgle:

  1. Ved hjælp af et tekstredigeringsprogram skal du åbne .pem-filerne, indsætte nøgleblob certifikatblob og gemme den som en ny .pem-fil.

    Dette er den nyttelasttekst, du vil kryptere og indsætte i din JWE-blok.

3

Opret en JWE-blob, der skal bruges som input til certifikattilføjelseskommandoen:

  1. Opret en tilfældig sekvens på mindst 4 byte. Dette er dit salt.

  2. Udfør en nøgle til kryptering af indhold med dit scrypt-værktøj.

    Til dette skal du bruge hemmeligheden, saltet og en nøglelængde, der passer til din valgte krypteringskode. Der er nogle andre faste værdier, der skal leveres (N=32768, r=8, p=1). Enheden bruger den samme proces og værdier til at udlede den samme indholdskrypteringsnøgle.

  3. Opret en tilfældig sekvens på præcis 12 byte. Dette er din initialiseringsvektor.

  4. Opret en JOSE-overskrift, indstilling alg, encog cisco-kdf nøgler som beskrevet i Forståelse af ekstern identitetsproces for enheder. Indstil handlingen "tilføj" ved hjælp af "cisco-action":"add" key:value i din JOSE-overskrift (fordi vi føjer certifikatet til enheden).

  5. Base64url-adresse koder JOSE-headeren.

  6. Brug dit JWE-krypteringsværktøj med den valgte kode og base64url-kodede JOSE-header til at kryptere teksten fra den koncatenerede pem-fil.

  7. Base64url-adresse koder initialiseringsvektoren, den krypterede PEM-nyttelast og godkendelseskoden.

  8. Konstruer JWE-blob som følger (alle værdier er base64url-kodet):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Åbn TShell på enheden, og kør tilføjelseskommandoen (flere linjer): 

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

Bekræft, at certifikatet er tilføjet ved at køre xcommand Security Certificates Services Show

Kopiér det nye certifikats fingeraftryk.

6

Aktivér certifikatet til formålet WebexIdentity:

  1. Læs certifikatets fingeraftryk, enten fra selve certifikatet eller fra output af xcommand Security Certificates Services Show.

  2. Opret en tilfældig sekvens på mindst 4 byte, og base64url koder denne sekvens. Dette er dit salt.

  3. Udfør en nøgle til kryptering af indhold med dit scrypt-værktøj.

    Til dette skal du bruge hemmeligheden, saltet og en nøglelængde, der passer til din valgte krypteringskode. Der er nogle andre faste værdier, der skal leveres (N=32768, r=8, p=1). Enheden bruger den samme proces og værdier til at udlede den samme indholdskrypteringsnøgle.

  4. Opret en tilfældig sekvens på præcis 12 byte, og base64url koder denne sekvens. Dette er din initialiseringsvektor.

  5. Opret en JOSE-overskrift, indstilling alg, encog cisco-kdf nøgler som beskrevet i Forståelse af ekstern identitetsproces for enheder. Indstil handlingen "Aktivér" ved hjælp af "cisco-action":"activate" key:value i din JOSE-overskrift (fordi vi aktiverer certifikatet på enheden).

  6. Base64url-adresse koder JOSE-headeren.

  7. Brug dit JWE-krypteringsværktøj med den valgte kode og base64url-kodede JOSE-header til at kryptere certifikatets fingeraftryk.

    Værktøjet skal levere en 16- eller 32-byte-sekvens, afhængigt af om du vælger 128- eller 256-bit AES-GCM og et godkendelsesmærke.

  8. Base64urlenkode det krypterede fingeraftryk og godkendelsestaget.

  9. Konstruer JWE-blob som følger (alle værdier er base64url-kodet):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Åbn TShell på enheden, og kør følgende aktiveringskommando:

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"

Enheden har et krypteret, aktivt, CA-udstedt certifikat, der er klar til at blive brugt til identifikation i slutpunkt-til-slutpunkt-krypterede Webex-møder.
7

Onboard enheden til din Control Hub-organisation.

Test slutpunkt-til-slutpunkt-kryptering med identitetsbekræftelse
1

Planlæg et møde af den korrekte type (Webex Meetings Pro-End to End Encryption_VOIPonly).

Se Planlæg et Webex-møde med slutpunkt-til-slutpunkt-kryptering.

2

Deltag i mødet som vært fra en Webex Meetings-klient.

Se Deltag i et Webex-møde med slutpunkt-til-slutpunkt-kryptering.

3

Deltag i mødet fra en enhed, hvor identiteten er bekræftet af Webex CA.

4

Som vært skal du bekræfte, at denne enhed vises i lobbyen med det korrekte identitetsikon.

Se Deltag i et Webex-møde med slutpunkt-til-slutpunkt-kryptering.

5

Deltag i mødet fra en enhed, hvor identiteten er bekræftet af et eksternt nøglecenter.

6

Som vært skal du bekræfte, at denne enhed vises i lobbyen med det korrekte identitetsikon. Få mere at vide om identitetsikoner.

7

Deltag i mødet som ikke-godkendt mødedeltager.

8

Som vært skal du bekræfte, at denne deltager vises i lobbyen med det korrekte identitetsikon.

9

Som vært skal du give personer/enheder adgang til eller afvise dem.

10

Valider deltager-/enhedsidentiteter, hvor det er muligt, ved at kontrollere certifikaterne.

11

Kontrollér, at alle i mødet ser den samme mødesikkerhedskode.

12

Deltag i mødet med en ny deltager.

13

Kontrollér, at alle ser den samme nye mødesikkerhedskode.

Indstil omfang og forventninger

  • Vil du gøre slutpunkt-til-slutpunkt-krypterede møder til standardmødeindstillingen, eller vil du kun aktivere den for nogle brugere eller tillade alle værter at beslutte? Når du har besluttet, hvordan du vil bruge denne funktion, skal du forberede de brugere, der vil bruge den, især med hensyn til begrænsningerne, og hvad du kan forvente i mødet.

  • Har du brug for at sikre, at hverken Cisco eller andre kan dekryptere dit indhold eller udgive dine enheder? Hvis det er tilfældet, skal du have certifikater fra et offentligt nøglecenter.

  • Hvis du har forskellige niveauer af identitetsbekræftelse, kan du give brugere mulighed for at bekræfte hinanden med identitet, der understøttes af certifikat. Selvom der er omstændigheder, hvor deltagere kan vises som ikke-bekræftede, og deltagerne bør vide, hvordan de skal kontrollere, er ikke-bekræftede personer muligvis ikke bedragere.

Identitetsadministration

Hvis du bruger et eksternt nøglecenter til at udstede dine enhedscertifikater, er det dig, der skal overvåge, opdatere og anvende certifikater igen.

Hvis du har oprettet den indledende hemmelighed, skal du forstå, at dine brugere muligvis ønsker at ændre deres enheds hemmelighed. Du skal muligvis oprette en grænseflade/distribuere et værktøj for at give dem mulighed for at gøre dette.

Sessionstype-id'er
Tabel 1. Sessionstype-id'er for slutpunkt-til-slutpunkt-krypterede møder

Sessionstype-ID

Navn på offentlig tjeneste

638

E2E-kryptering + kun VoIP

652

Pro-End til End-Encryption_VOIPonly

660

Pro 3 gratis slutpunkt til slutpunkt-Encryption_VOIPonly

E2E-kryptering + identitet

672

Pro 3 Free50-End til End Encryption_VOIPonly

673

Instruktør E2E Encryption_VOIPonly

676

BroadWorks-standard plus slutpunkt-til-slutpunkt-kryptering

677

Slutpunkt-til-slutpunkt-kryptering fra BroadWorks Premium Plus

681

Schoology Free plus slutpunkt-til-slutpunkt-kryptering

Relaterede xAPI-kommandoer

Disse tabeller beskriver Webex-enheders API-kommandoer, som vi har tilføjet til slutpunkt-til-slutpunkt-krypterede møder og bekræftet identitet. Få yderligere oplysninger om, hvordan du bruger API'et, i Adgang til API'et til Webex-lokale- og bordenheder og Webex Boards.

Disse xAPI-kommandoer er kun tilgængelige på enheder, der enten er:

  • Tilmeldt til Webex

  • Registreret på stedet og knyttet til Webex med Webex Edge til enheder

Tabel 2. Systemniveau-API'er til slutpunkt-til-slutpunkt-krypterede møder og bekræftet identitet

API-opkald

Beskrivelse

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Denne konfiguration foretages, når administratoren indstiller enhedens foretrukne domæne fra Control Hub. Kun nødvendig, hvis organisationen har mere end ét domæne.

Enheden bruger dette domæne, når den anmoder om et certifikat fra Webex CA. Domænet identificerer derefter enheden.

Denne konfiguration gælder ikke, når enheden har et aktivt, eksternt udstedt certifikat til at identificere sig selv.

xStatus Conference EndToEndEncryption Availability

Angiver, om enheden kan deltage i et slutpunkt-til-slutpunkt-krypteret møde. Cloud-API ringer til den, så en parret app ved, om den kan bruge enheden til at deltage.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Angiver, om enheden bruger External bekræftelse (har et eksternt udstedt certifikat).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Enhedens identitet som læst fra det eksternt udstedte certifikats fællesnavn.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

Læser specifikke oplysninger fra et eksternt udstedt certifikat.

I den viste kommando skal du # erstatte med nummeret på certifikatet. Erstat specificinfo med en af:

  • Fingerprint

  • NotAfter Slutdato for gyldighed

  • NotBefore Gyldighedsstartdato

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name En liste over emnerne for certifikatet (f.eks. e-mailadresse eller domænenavn)

  • Validity Angiver gyldighedsstatus for dette certifikat (f.eks. valid eller expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

Status for enhedens eksterne identitet (f.eks. valid eller error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

Angiver, om enheden har et gyldigt certifikat udstedt af Webex CA.

xStatus Conference EndToEndEncryption InternalIdentity Identity

Enhedens identitet som læst fra det Webex-udstedte certifikats fælles navn.

Indeholder et domænenavn, hvis organisationen har et domæne.

Er tom, hvis organisationen ikke har et domæne.

Hvis enheden er i en organisation, der har flere domæner, er dette værdien fra PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Læser specifikke oplysninger fra det Webex-udstedte certifikat.

I den viste kommando skal du # erstatte med nummeret på certifikatet. Erstat specificinfo med en af:

  • Fingerprint

  • NotAfter Slutdato for gyldighed

  • NotBefore Gyldighedsstartdato

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name En liste over emnerne for certifikatet (f.eks. e-mailadresse eller domænenavn)

  • Validity Angiver gyldighedsstatus for dette certifikat (f.eks. valid eller expired)

Tabel 3. I opkalds-API'er til slutpunkt-til-slutpunkt-krypterede møder og bekræftet identitet

API-opkald

Beskrivelse

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Disse tre begivenheder omfatter nu EndToEndEncryptionStatus, EndToEndEncryptionIdentity og EndToEndEncryptionCertInfo for den berørte deltager.

Tabel 4. ClientSecret-relaterede API'er til slutpunkt-til-slutpunkt-krypterede møder og bekræftet identitet

API-opkald

Beskrivelse

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

eller

xCommand Security ClientSecret Populate Secret: JWEblob

Accepterer en base64url-kodet almindelig tekstværdi til sening af klienthemmeligheden på enheden for første gang.

Hvis du vil opdatere hemmeligheden efter denne første gang, skal du levere en JWE-blob, der indeholder den nye hemmelighed krypteret af den gamle hemmelighed.

xCommand Security Certificates Services Add JWEblob

Tilføjer et certifikat (med privat nøgle).

Vi har udvidet denne kommando til at acceptere en JWE-blob, der indeholder de krypterede PEM-data.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Aktiverer et specifikt certifikat til WebexIdentity. Til dette Purpose kræver kommandoen, at identifikationsfingeraftrykket krypteres og serialiseres i en JWE-blob.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Deaktiverer et specifikt certifikat til WebexIdentity. Til dette Purpose kræver kommandoen, at identifikationsfingeraftrykket krypteres og serialiseres i en JWE-blob.