Brugeroplevelse

Brugere vælger mødetypen, når de planlægger et møde. Ved adgang til deltagere fra lobbyen samt under mødet kan værten se status for identitetskontrol for hver deltager. Der er også en mødekode, der er fælles for alle aktuelle deltagere i mødet, og som de kan bruge til at bekræfte, at deres møde ikke er blevet aflyttet af en uønsket tredjepart Meddler I Midten (MITM)-angrebet.

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

Identitetskontrol med intern eller ekstern CA

Bekræft identitet

Slutpunkt-til-slutpunkt-kryptering med identitetsbekræftelse giver ekstra sikkerhed til 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 certifikaterne mod de udstedende certifikatmyndigheder (CA). Ved at bekræfte, at certifikaterne er gyldige, bekræfter CA deltagernes identitet, og mødet viser deltagerne/enhederne som bekræftet.

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

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

  • Internt CA – Webex udsteder et internt certifikat baseret på adgangstokenet på enhedens maskinkonto. Certifikatet underskrives af Webex CA. Enheder har ikke bruger-id'er på samme måde som brugere, så Webex bruger (et af) din organisations domæner, når du skriver enhedscertifikatets identitet (Common Name (CN)).

  • Ekstern CA – Anmod om og køb enhedscertifikater direkte fra din valgte udsteder. Du skal kryptere, overføre direkte og autorisere certifikaterne ved hjælp af en hemmelighed, som kun kendes af dig.

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

Internt udstedt enhedscertifikat

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

Hvis din organisation ikke har et domæne, udsteder Webex CA 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 dens identitet. Du kan også bruge det foretrukne domæne for API x-konfigurationskonferencen, End To End Encryption Identity (API): "example.com".

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

Eksternt udstedt enhedscertifikat

En administrator kan klargøre en enhed med deres eget certifikat, som er blevet signeret med en af de offentlige CA'er.

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

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

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

For at beskytte det eksterne certifikat fuldt ud mod at ændre det, bruges en klient-hemmelig funktion til at kryptere og underskrive forskellige xcommands.

Når du bruger klienthemmeligheden, er det muligt at administrere det eksterne Webex-identitetscertifikat sikkert via xAPI. Dette er i øjeblikket begrænset til online-enheder.

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 Room Kit

  • Webex Room Kit Mini

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

  • Webex C-serien

  • Webex DX-serien

  • Webex EX-serie

  • Webex MX-serien

  • Tredjeparts SIP-enheder

Softwareklienter

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

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

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

Identificer

  • Som design giver vi ikke Control Hub-valgmuligheder, så du kan administrere eksternt-verificeret enhedsidentitet. For sand slutpunkt-til-slutpunkt-kryptering er det kun dig, der skal kende/få adgang til hemmelighederne og nøglerne. Hvis vi introducerede en cloud-tjeneste for at administrere disse nøgler, er der en chance for, at de bliver opsnappet.

  • I øjeblikket leverer vi en "opskrift", så du kan designe dine egne værktøjer baseret på industristandard krypteringsteknikker til at hjælpe med at anmode om eller kryptere din enheds identitetscertifikater og deres private nøgler. Vi ønsker ikke at få nogen reelle eller oplevede adgang til dine hemmeligheds- eller nøgler.

Møder

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

  • Du kan dele nye whiteboards i E2EE-møder. Der er nogle forskelle fra whiteboards i regelmæssige 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å flere oplysninger om kommentarer i Webex-appen | Markér 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-Room_OSugust_A 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å personer 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 for identitetskontrol skal hver enhed have et entydigt certifikat udstedt af en pålidelig offentlig certifikatmyndighed (CA).

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

  • Certifikatet skal udstedes og underskrives af en kendt offentlig CA.

  • Unikke: Vi anbefaler på det kraftigste, at der bruges et unikt certifikat til hver enhed. Hvis du bruger et certifikat til alle enheder, frameldes din sikkerhed.

  • Fælles navn (CN) og alternative emnenavn/-navne (SAN/s): Disse er ikke vigtige for Webex, men bør være værdier, der kan læse og associere med enheden. CN viser det til andre mødedeltagere som enhedens primære bekræftede identitet, og hvis brugere undersøge certifikatet via mødegrænsefladen, vil de se SAN/s. Du kan bruge navne som name.model@example.com.

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

  • Formål: Certifikatformålet 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 kurve).

    Dette krav omfatter ikke signeringsnøglen. CA kan bruge en RSA-nøgle til at underskrive certifikatet.

Forbered til onboarding af enheder

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

Hvis du bruger nye enheder, skal du ikke tilmelde dem til Webex endnu. For at være sikker skal du ikke oprette forbindelse til netværket på dette 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 trinvis tilgang. Underret brugere om de ændringer, de kan forvente.

  • Sørg for fysisk adgang til enheder. Hvis du skal tilgå enheder via netværket, skal du være opmærksom på, at der rejses skjulte ting i ren tekst, og at du risikerer 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å den eksterne identitetsproces for enheder

For at sikre, at din enheds medie 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 gennem vores cloud kan vi ikke være involveret i at kryptere og overføre 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 beskytte enhedens krypteringsfunktion.

  4. Udvikler og vedligeholder 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-klatter, som vi forventer dem, for at hjælpe dig med at bekræfte din proces.

    En ikke-understøttet referencegennemførelse ved hjælp afkryptering3 og JWCrypto-biblioteket er tilgængeligt fra Cisco på anmodning.

  5. Certifikataktiver og kryptering af certifikatet og nøglen ved hjælp af dit værktøj og enhedens indledende hemmelighed.

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

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

  8. (Anbefalet) Giv en grænseflade til (eller distribuer) dit værktøj for at give enhedsbrugere mulighed for at æ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 bygge dit eget værktøj til at oprette klatterne fra dine certifikater og nøgler.

Se JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 og JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Vi bruger kompakt serialisering af et JSON-dokument til at oprette JWE-blobber. De parametre, du skal inkludere, når du opretter JWE-blobbene, er:

  • JOSE-overskrift (beskyttet). I JSON-objektunderskrivning og krypteringsoverskrift skal du inkludere følgende nøgleværdi-par:

    • '''alg''':''

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

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

      Vi understøtter disse to krypteringsalgoritmer.

    • "cisco-handling": "tilføj" eller "cisco-handling": "udfyld" eller "cisco-handling": "aktivér" eller "cisco-handling": "deaktivér"

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

      Vi kaldte det Cisco-handling for at afbøde potentielle sammenstød med fremtidige JWE-udvidelser.

    • "cisco-kdf": { "version": "1", "salt": "base 64URLE-kodet Tilfældigt4+bytes" }

      En anden navnebeskyttet nøgle. Vi bruger de værdier, du giver som input til vigtige oplysninger på enheden. Versionen skal være 1 (versionen af vores nøgleafledte 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 klienthemmelighed.

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

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

  • JWE-krypteringstekst: Dette er den krypterede nyttedata, som du ønsker at hemmeligholde.

    Nyttelast KAN være tom. For at nulstille klienthemmeligheden skal du f.eks. overskrive den med en tom værdi.

    Der findes forskellige typer nyttedata, 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 nyttelasten med Cisco-handlingsnøglen som følger:

    • Med "cisco-handling":"udfyld" krypteringsteksten er den nye klienthemmelighed.

    • Med ""cisco-handling":"tilføj" krypteringsteksten er en PEM-blob, der bærer certifikatet og dets private nøgle (konkateneret).

    • Med ""Cisco-handling":"Aktivér" krypteringsteksten er fingeraftrykket (hexadecimal repræsentation af sha-1) af det certifikat, vi aktiverer til enhedsidentidentifikation.

    • Med ""Cisco-handling":"Deaktiver" er krypteringsteksten fingeraftrykket (hexadecimal repræsentation af sha-1) af det certifikat, vi deaktiverer, fra at blive brugt til bekræftelse af enhedsidentitet.

  • JWE godkendelsestag: Dette felt indeholder bekræftelsestagget for at opretholde integriteten af hele JWE'ens kompakt serieliserede blob

Hvordan vi udleder krypteringsnøglen fra klienthemmeligheden

Efter den første udgave af hemmeligheden accepterer eller output vi ikke hemmeligheden som ren tekst. Dette er for at forhindre potentielle ordbogsangreb fra en person, som har adgang til enheden.

Enhedssoftwaren bruger klienthemmelighed som et input til en nøglefunktion (kdf) og bruger derefter den afledte nøgle til indholdsdekryptering/kryptering på enheden.

Hvad dette betyder for dig er, at dit værktøj til at producere JWE-klatter skal følge den samme procedure for at aflæse den samme krypterings-/dekrypteringsnøgle fra klientens hemmelighed.

Enhederne bruger skrypt til nøgle kryptering (se ) med https://en.wikipedia.org/wiki/Scryptfølgende parametre:

  • CostFaktorer (N) er 32768

  • BlockSizeKomponent (r) er 8

  • ParallelizationFaktorer (p) er 1

  • Salt er en tilfældig sekvens på mindst 4 byte. Du skal levere det samme salt ved angivelse af cisco-kdf parameteren.

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

  • Maks. hukommelsesgrænse er 64 MB

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

Virkede eksempel

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 cert + nøgle). Klienthemmeligheden i eksemplet er ossifrage.

  1. Vælg en krypteringskode. Dette eksempel bruger A128GCM (AES med 128-bit nøgler i Galois Counter-tilstand). 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 bytes). Dette eksempel bruger (hex bytes)E5 E6 53 08 03 F8 33 F6. Base6url koder sekvensen for at få 5. ZTCAP4M_Y (fjern base64-padding).

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

    cek=scrypt (password="ossifrage", salt=4-byte-sekvens, N=32768, r=8, p=1, tastetængde=16)

    Den afledte nøgle skal være 16 bytes (hex) som følger:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac , som baserer 64 url koder til lZ66bd_mqdEinj_rAQV4 I.

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

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

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

    JOSE-headeren er kodet for base 64-URL eyJhbGciOiJkaXI iLCJ jaXNJby1hY3Rpb24iOiJhZGQ iLCJ jaXNJby1rZGY iOnsic2FsdCI6IjVlWlRDQVA0TV9ZI iwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEogOE dDTSJ9

    Dette vil være det første element i JWE-klaten.

  6. Det andet element i JWE-klaten er tomt, fordi vi ikke har nogen forbindelse til et JWE-krypteringsnøgle.

  7. Det tredje element i JWE-bloggen er initialiseringsvektoren NLN d3V9Te72 tkp.

  8. Brug dit JWE-krypteringsværktøj til at producere en krypteret nyttedata og -tag. For dette eksempel vil den ukrypterede nyttelast være den falske PEM-blob, dette er en PEM-fil

    De krypteringsparametre, du skal bruge, er:

    • Nyttelast er dette er en PEM-fil

    • Krypteringskode er AES 128 GCM

    • Den base64url kodet JOSE-header som Yderligere bekræftede data (AAD)

    Base6url koder den krypterede nyttelast, som skulle resultere i f5lLV uWN fKfmzYCO1YJ fODH

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

  9. Base6url koder det mærke, du producerede i trin 8, hvilket bør resultere i PE-wDFWGXFFBEO928CF

    Dette er det femte element i JWE-klaten.

  10. Rysten de fem elementer i JWE-blob med punkter (JOSEheader.. IV.Ciphertext.Tag) for at få:

    eyJhbGciOiJkaXI iLCJ jaXNJby1hY3Rpb24iOiJhZGQ iLCJ jaXNJby1rZGY iOnsic2FsdCI6IjVlWlRDQVA0TV9ZI iwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOE dDTSJ..9NLND3V9Te07 TKPWD.f5lLVUWNFFKFMZYCO1YJ fODhQ.PE-wDFWGXFFBEO928CFZ1Q

  11. Hvis du udledte 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-kryptering og bekræftet identitet for dine enheder.

  12. Dette eksempel vil ikke fungere, men efterhånden ser det ud til, at dit næste trin bliver at bruge JWE-blob, du oprettede ovenfor, som input til xcommand på enheden, der tilføjer certifikatet:

    xCommand-sikkerhedscertifikater tilføjes eyJhbGciOiJkaXI iLCJ jaXNJby1hY3Rpb24iOiJhZGQ iLCJ jaXNJby1rZGY iOnsic2FsdCI6IjVlWlRDQVA0TV9ZI iwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOE dDTSJ..9NLND3V9Te07 TKPWD.f5lLVUWNFFKFMZYCO1YJ fODhQ.PE-wDFWGXFFBEO928CFZ1Q

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

Der er intet, du behøver at 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 samlet 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 indstillinger for, og klik derefter på Indstillinger.

3

Under Almindelige indstillingerskal du vælge Sessionstyper.

4
Du bør se en eller flere slutpunkt-til-slutpunkt-krypteringssessionstyper. Se listen over sessionstype-JEG'er i afsnittet Reference i denne artikel. Du kan for eksempel se Pro-End til End Encryption_VOIPonly.

Der er en ældre sessionstype med et meget lignende navn: Kryptering mellem slutpunkt og slutpunkt. Denne sessionstype inkluderer ikke-krypteret PSTN adgang til møder. Sørg for, at du har _kun VOIP-versionen for at sikre slutpunkt-til-slutpunkt-kryptering. Du kan kontrollere ved at holde markøren over pr. link i sessionskodekolonnen; f.eks. bør målet for linket være javascript:Visfunktion(652).

Vi kan ændre navnene på offentlige tjenester for disse sessionstyper i fremtiden.

5

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

Hvad er næste trin?

Aktivér dette sessionstype/mødeprivilegiet til nogle eller alle dine brugere.

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

Log ind på Control Hubog gå til Ledelse > Brugere.

2

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

3

Fra rullegardinmenuen Indstillinger gælder , skal du vælge det mødested, der skal opdateres.

4

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

5

Luk brugerkonfigurationspanelet.

6

Gentag for andre brugere, hvis 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, vælg det Webex-websted, du vil ændre indstillingerne for.

3

I afsnittet Licenser og brugere skal du klikke på Mængdeadministration.

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 det pop op-vindue manuelt, når du klikker på Download.)

6

Åbn den downloadede CSV-fil til redigering.

Der er en række for hver bruger, og kolonnen Mødeprivilegier indeholder deres sessionstype-id'er som en kommaafgrænset liste.

7

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

Webex CSV-filformatreferencen indeholder oplysninger om formålet med og indholdet af CSV-filen.

8

Åbn konfigurationspanelet for Meeting-webstedet i Control Hub.

Hvis du allerede var på siden mødewebstedsliste, er du muligvis nødt til at genindfriske den.

9

I afsnittet Licenser og brugere skal du klikke på Mængdeadministration.

10

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

11

Når importen er færdig, kan du klikke på Importer resultater for at gennemgå, om der var nogen 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 af sikkerhedsmæssige hensyn

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

Når denne funktion er aktiveret, indeholder mødelyd et entydigt id for hver deltagende klient eller enhed. Du kan overføre lydoptagelser til Control Hub, som derefter analyserer optagelsen og ser frem til de unikke identifikatorer. Du kan se resultaterne for at se, hvilken kildeklient eller enhed der optog mødet.

  • For at blive analyseret skal optagelsen være en AAC-, MP3-, M4A-, WAV-, MP4-, AVI- eller MOV-fil, der ikke overstiger 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.
  • Watermark-oplysninger opbevares i samme varighed som organisationens mødeoplysninger.

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

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

    Et stykke tid efter dette er slået til, kan brugere, der planlægger møder med sessionstypen Webex Meetings Pro-End til End Encryption_VOIP kun se en valgmulighed Digital vandmærkning i afsnittet Sikkerhed.

Overfør og analyser et vandmærket møde

  1. I Control Hub under Overvågning, vælg Fejlfinding.
  2. Klik på Vandmærke-analyse.
  3. Søg efter eller vælg mødet på listen, og klik derefter på Analyser.
  4. I vinduet Analyser lydvandmærke skal du angive 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 gå til lydfilen.
  7. Klik på Luk.

    Når analysen er fuldført, vises den på listen over resultater på siden Analyser vandmærke .

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

Funktioner og begrænsninger

Faktorer, der er involveret i vellykket afkodning af et optaget vandmærke, omfatter afstanden mellem optagelsesenheden og højttaleren, lydstyrken af denne lyd, miljøstøj osv. Vores vandmærkningsteknologi har ekstra modstandsdygtighed over for at blive kodet flere gange, som det kan ske, når medierne deles.

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

For at kunne analysere en optagelse, er der behov for en rimelig optagelse af mødets lyd. Hvis et mødes lyd optages på den samme computer, som er vært for klienten, bør begrænsninger ikke gælde.

Onboard-enheder (internt CA)

Hvis dine enheder allerede er onboardet til din Control Hub-organisation, og du vil bruge Webex CA til automatisk at generere deres identifikationscertifikater, behøver du ikke fabriksnulstilling af 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, som vil have "Cisco-bekræftet" identitet. Hvis du ikke fortæller Webex, hvilket domæne der identificerer enheden, vælges en 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 Tilmeld en enhed til Cisco Webex ved hjælp af API eller lokal webgrænseflade eller cloud-onboarding til Board-, Desk- og Room-serien. Du skal også bekræfte det eller de domæner, 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 dens konfigurationspanel.

3

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

4

Gentag for andre enheder.

Onboardede enheder (eksternt CA)

Før du begynder

  • Få et CA-signeret certifikat og privat nøgle i .pem-format for hver enhed.

  • Under fanen Forbered skal du læse emnet Forståelse af den eksterne 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 bestemte længder.

  • Sørg for, at du har et værktøj til at basere 64url-koder bytes 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 klienthemmelighed med en almindelig teksthemmelighed:

Første gang du udfylder hemmeligheden, leverer du den i almindelig tekst. Det er derfor, vi anbefaler at gøre dette på den fysiske enhedskonsol.

  1. Base64url indkode den hemmelige sætning for denne enhed.

  2. Åbn TShell på enheden.

  3. Kør xcommand Security Client Secret Populate Secret: "MDEYMzQ1Njc4OWF iY2RlZg"

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

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

Aktiver dit certifikat og private nøgle:

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

    Dette er den nyttelast-tekst, du vil kryptere og indsætte i din JWE-blob.

3

Opret en JWE-blob, der skal bruges som input til certifikat tilføj kommandoen:

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

  2. Afduk en indholds krypteringsnøgle med dit skrypteringsværktøj.

    Til dette har du brug for hemmeligheden, saltet og en nøglelængde, der matcher din valgte krypterings kode. Der er nogle andre faste værdier at levere (N=32768, r=8, p=1). Enheden bruger den samme proces og værdier til at afsende det samme indhold krypteringsnøgle.

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

  4. Opret en JOSE-header, indstil alg, enc, og cisco-kdf-nøgler som beskrevet i Understanding External Identity Process for enheder. Indstil handlingen "tilføj" ved hjælp af nøgle:value "cisco-action":"tilføj" i din JOSE-header (fordi vi tilføjer certifikatet til enheden).

  5. Base64url indkode JOSE-overskriften.

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

  7. Base64url indkode initialiseringsvektoren, den krypterede PEM-nyttedata og godkendelsestagget.

  8. Konstruktion af JWE-klat som følger (alle værdier er base64url kodet):

    JOSEH eader..InitVector.KrypteretPEM.Godkendelsesmærke

4

Åbn TShell på enheden, og kør kommandoen (multiline) tilføj: 

Tilføjelse af xcommand-sikkerhedscertifikattjenester erkrypteret: Sandt din..JWE.str.ing\n .\n
5

Bekræft, at certifikatet er tilføjet ved at køre xcommand-sikkerhedscertifikattjenester

Kopier det nye certifikats fingeraftryk.

6

Aktivér certifikatet til formålet Webex:

  1. Læs fingeraftrykket af certifikatet, enten fra selve certifikatet eller fra resultatet af xcommand Security Certificates Services Show.

  2. Opret en tilfældig sekvens på mindst 4 bytes, og indkode den pågældende sekvens via base64url. Dette er dit salt.

  3. Afduk en indholds krypteringsnøgle med dit skrypteringsværktøj.

    Til dette har du brug for hemmeligheden, saltet og en nøglelængde, der matcher din valgte krypterings kode. Der er nogle andre faste værdier at levere (N=32768, r=8, p=1). Enheden bruger den samme proces og værdier til at afsende det samme indhold krypteringsnøgle.

  4. Opret en tilfældig sekvens med præcis 12 bytes, og kod den pågældende sekvens i base64url. Dette er din initialiseringsvektor.

  5. Opret en JOSE-header, indstil alg, enc, og cisco-kdf-nøgler som beskrevet i Understanding External Identity Process for enheder. Indstil handlingen "aktivér" ved hjælp af nøgle:value "cisco-action":"aktivér" i din JOSE-header (fordi vi aktiverer certifikatet på enheden).

  6. Base64url indkode JOSE-overskriften.

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

    Værktøjet skal have en 16- eller 32-bytesekvens, afhængigt af om du vælger 128 eller 256 bit AES-GCM og et godkendelsestag.

  8. Base64urlencode det krypterede fingeraftryk og godkendelsestagget.

  9. Konstruktion af JWE-klat som følger (alle værdier er base64url kodet):

    JOSEH eader..InitVector.Krypteretfingeraftryk.Godkendelsesmærke

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

     xcommand-sikkerhedscertifikattjenester til aktivering af formål: Webex-identitetsfingeraftryk: "Dit..JWE.encrypted.fingeraftryk"

Enheden har et krypteret, aktivt CA-udstedt certifikat, der er klar til brug til at identificere det i slutpunkt-til-slutpunkt krypterede Webex-møder.
7

Onboard enheden i 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 til End Encryption_VOIPonly).

Se Planlæg et Webex Meeting med slutpunkt-til-slutpunkt-kryptering.

2

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

Se Deltag i Webex Meeting med slutpunkt-til-slutpunkt-kryptering.

3

Deltag i mødet fra en enhed, som har dens identitet 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 Webex Meeting med slutpunkt-til-slutpunkt-kryptering.

5

Deltag i mødet fra en enhed, der har dens identitet bekræftet af en ekstern CA.

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 en 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 kan du give eller afvise personer/enheder.

10

Valider deltagers/enheds-identiteter, hvor det er muligt, ved at kontrollere certifikaterne.

11

Kontroller, at alle i mødet ser den samme mødesikkerhedskode.

12

Deltag i mødet med en ny deltager.

13

Kontroller, at alle ser den samme, nye mødesikkerhedskode.

Indstil rækkevidde og forventninger

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

  • Skal du sikre dig, at hverken Cisco eller andre kan dekryptere dit indhold eller udgive sig for at være dine enheder? Hvis det er nødvendigt, skal du have certifikater fra en offentlig CA.

  • Hvis du har forskellige niveauer af identitetsbekræftelse, skal du give brugere mulighed for at bekræfte hinanden med certifikatunderstøttet identitet. Selv om der er omstændigheder, hvor deltagere kan blive vist som ikke-verificerede, og deltagerne bør vide, hvordan de skal kontrollere, er ubekræftede personer muligvis ikke impostorer.

Identitetsadministration

Hvis du bruger en ekstern CA til at udstede dine enhedscertifikater, er onus på dig til at overvåge, genindpakke og genanvende certifikater.

Hvis du oprettede den indledende hemmelighed, skal du forstå, at dine brugere muligvis vil ændre deres enheds hemmelighed. Du skal muligvis oprette en grænseflade/distribuere et værktøj for at gøre dette muligt.

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

Sessionstype-id

Navn på offentlig tjeneste

638

Kun E2E-kryptering+VoIP

652

Pro-End til end EVOIPonlyncryption_

660

Pro 3 gratis slutpunkt til slut på EVOIPonlyncryption_

E2E-kryptering + identitet

672

Pro 3 Free50-end til slut EVOIPonlyncryption_

673

Uddannelsesinstruktør E2E EVOIPonlyncryption_

676

Broadworks Standard plus slutpunkt-til-slutpunkt-kryptering

677

Broadworks Premium plus slutpunkt-til-slutpunkt-kryptering

681

Fri skoleundervisning plus slutpunkt-til-slutpunkt-kryptering

Relaterede xAPI-kommandoer

Disse tabeller beskriver Webex-enheders API-kommandoer, vi har tilføjet til slutpunkt-til-slutpunkt krypterede møder og bekræftet identitet. Få yderligere oplysninger om, hvordan du bruger API, i Få adgang til API'en for Webex Room- og skrivebordsenheder og Webex Boards.

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

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

xForetrukket domæne for konfigurationskonference for slutpunkt-til-slutpunkt-krypteringsidentitet: "example.com"

Denne konfiguration foretages, når administratoren indstiller enhedens foretrukne domæne fra Control Hub. Kun nødvendigt, 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 er ikke gældende, når enheden har et aktivt, eksternt udstedt certifikat til at identificere sig selv.

xStatuskonference Slutpunkt-til-slutpunkt-kryptering

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

xStatuskonference Afslutningtilslutpunkt-kryptering Eksternidentitetskontrol

Angiver, om enheden bruger ekstern verifikation (har et eksternt certifikat).

xStatuskonference afslutningtil slutpunkt-kryptering Eksternidentitetsidentitet

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

xStatuskonference Afslutningtilslutpunkt-kryptering Eksternidentitetscertifikatkæde certifikat # specificinfo

Læser specifikke oplysninger fra et eksternt udstedt certifikat.

I den viste kommando skal # erstattes med certifikatets nummer. Erstat specificinfo med ét af:

  • Fingeraftryk

  • Ikke efter udløbsdato

  • Ikke før gyldighedsstartdato

  • Primærtnavn

  • Algoritme foroffentlig nøgle

  • Serienummer

  • Signaturalgoritme

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

  • Gyldighed Angiver valideringsstatus for dette certifikat (f.eks. gyldig eller udløbet)

xStatuskonference for slutpunkttil slutpunkt-kryptering eksternidentitetsstatus

Status for enhedens eksterne identitet (f.eks. gyldig eller fejl).

xStatuskonference Afslutningtilslutpunkt-kryptering Internidentitetskontrol

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

xStatuskonference afslutningtil afslutningkryptering Internidentitetsidentitet

Enhedens identitet som læst fra Det Webex-udstedte certifikats fællesnavn.

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

xStatuskonference Afslutningtilslutpunkt-kryptering af internidentitetscertifikatkæde-certifikat # specificinfo

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

I den viste kommando skal # erstattes med certifikatets nummer. Erstat specificinfo med ét af:

  • Fingeraftryk

  • Ikke efter udløbsdato

  • Ikke før gyldighedsstartdato

  • Primærtnavn

  • Algoritme foroffentlig nøgle

  • Serienummer

  • Signaturalgoritme

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

  • Gyldighed Angiver valideringsstatus for dette certifikat (f.eks. gyldig eller udløbet)

Tabel 3. Api'er til opkald for slutpunkt-til-slutpunkt krypterede møder og bekræftet identitet

API-opkald

Beskrivelse

xBegivenhedskonferencedeltagerlistedeltagertilføjet

xBegivenhedskonferencedeltagerlisteopdateretDeltager

xBegivenhedskonferencedeltagerlistedeltager slettet

Disse tre begivenheder omfatter nu slutpunkt-til-slutpunkt-krypteringsstatus, slutpunkt-til-slutpunkt-krypteringsidentitet, og slutpunkt-til-slutpunkt-krypteringscertifikat 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 Client Secret Populate Secret: "base 64-URL-kodet"

eller

xCommand Security Client SecretUdfyld hemmelighed: JWE-blob

Accepterer en base64url kodet almindelig tekstværdi for at understlette klient hemmeligheden på enheden for første gang.

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

xCommand Security Certificate Services Tilføj JWE

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-sikkerhedscertifikattjenester – aktivér formål:Webex-identitetsfingerudskrift: JWE-blob

Aktiverer et specifikt certifikat for WebexIdentity. Til dette formål kræver kommandoen, at det identificerende fingeraftryk krypteres og serialiseres i en JWE-blob.

xCommand-sikkerhedscertifikattjenester deaktiverer formål:WebexIdentity Finger Print: JWE-blob

Deaktiverer et specifikt certifikat for WebexIdentity. Til dette formål kræver kommandoen, at det identificerende fingeraftryk krypteres og serialiseres i en JWE-blob.