Brugeroplevelse

Brugere vælger mødetype, når de planlæg et møde. Ved adgang til deltagere fra lobbyen samt under mødet kan værten se identitetsbekræftelsesstatussen for hver deltager. Der er også en mødekode, der er fælles for alle aktuelle deltagere i mødet, som de kan bruge til at bekræfte hinanden.

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

Identitetsbekræftelse med intern eller ekstern CA

Bekræft identiteten

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

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

Brugere af Webex appen godkender sig selv over for Webex identitetslagret, som udsteder 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 CA et certifikat til dem baseret på deres adgangstoken. På nuværende tidspunkt tilbyder vi ikke en måde, hvorpå Webex Meetings -brugere kan få et certifikat, der er udstedt af en tredjepart/ekstern certifikatudsteder.

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 et eksternt CA:

  • Internt CA – Webex udsteder et internt certifikat baseret på adgangstokenen for enhedens maskinkonto. Certifikatet er signeret af Webex CA. Enheder har ikke bruger-id'er på samme måde, som brugere har, 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 og godkende certifikaterne ved hjælp af en hemmelighed, som kun du kender.

    Cisco er ikke involveret, hvilket gør dette til den måde, du kan garantere ægte end-to-end-kryptering og verificeret identitet og forhindre den teoretiske mulighed for, at Cisco kunne aflytte dit møde/dekryptere dine medier.

Internt udstedt enhedscertifikat

Webex udsteder et certifikat til enheden, når den registreres efter start, og fornyer det, når det er nødvendigt. For enheder omfatter 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 sin identitet. Du kan også bruge API'et xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Hvis du har flere domæner og ikke angiver 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 CA'er.

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 bestemmes af organisationen. Common Name (CN) og Alternativt emnenavn (SAN) vil blive vist i Webex-møde brugergrænseflade, som beskrevet i Sluttepunkt-til-slutpunkt-kryptering med identitetsbekræftelse til Webex Meetings .

Vi anbefaler at bruge et separat certifikat pr. enhed og at have et entydigt CN pr. enhed. For eksempel "mødelokale-1.eksempel.dk" for den organisation, der ejer domænet "eksempel.dk".

For fuldt ud at beskytte det eksterne certifikat mod manipulation bruges en klienthemmelig funktion til at kryptere og signere forskellige x-kommandoer.

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

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

Funktioner og begrænsninger

Enheder

Følgende enheder i Webex Room-serien og Webex Desk-serien, der er registreret i skyen, kan deltage i krypterede møder fra slutpunkt-til-slutpunkt:

  • Webex Board

  • Webex Desk Pro

  • Webex-skrivebord

  • Webex Room Kit

  • Webex Room Kit Mini

Følgende enheder kan ikke deltage i slutpunkt-til-slutpunkt-krypterede møder:

  • Webex C-serie

  • Webex DX-serien

  • Webex EX-serien

  • Webex MX-serien

  • SIP -enheder fra tredjepart

Softwareklienter

  • Fra og med version 41.6 kan Webex Meetings -desktopklienten deltage i krypterede møder fra slutpunkt til slutpunkt.

  • Hvis din organisation gør det muligt for Webex-app at deltage i møder ved at starte desktopapplikationen Møder, kan du bruge denne valgmulighed til at deltage i krypterede møder fra slutpunkt-til-slutpunkt.

  • Webex -webklienten kan ikke deltage i slutpunkt-til-slutpunkt-krypterede møder.

  • Tredjeparts SIP -softklienter kan ikke deltage i end-to-end krypterede møder.

Identitet

  • Vi tilbyder ikke Control Hub-valgmuligheder, så du kan administrere eksternt bekræftet enhedsidentitet. For ægte slutpunkt-til-slutpunkt-kryptering er det kun dig, der har adgang til hemmelighederne og nøglerne. Hvis vi introducerede en cloud-tjeneste til at administrere disse nøgler, er der en chance for, at de bliver aflyttet.

  • I øjeblikket leverer vi en 'opskrift', så du kan designe dine egne værktøjer, baseret på krypteringsteknikker, der er standard i branchen, for at hjælpe med at anmode om eller kryptere din enheds identitetscertifikater og deres private nøgler. Vi ønsker ikke at have nogen reel eller opfattet adgang til dine hemmeligheder eller nøgler.

Møder

  • Krypterede møder fra slutpunkt til slutpunkt understøtter i øjeblikket maksimalt 200 deltagere.

  • Af disse 200 deltagere kan maksimalt 25 eksternt bekræftede enheder deltage, og de skal være de første deltagere til at deltage i mødet .

    Når et større antal enheder deltager i et møde, forsøger vores back-end medietjenester at omkode mediestreams. Hvis vi ikke kan dekryptere, omkode og genkryptere mediet (fordi vi ikke har og ikke skal have enhedernes krypteringsnøgler), så mislykkes omkodningen.

    For at mindske denne begrænsning anbefaler vi mindre møder for enheder eller fordeler invitationerne mellem enheder og Meetings-klienter.

Administrationsgrænseflade

Vi anbefaler på det kraftigste, at du bruger Control Hub til at administrere dit mødewebsted, da Control Hub-organisationer har en centraliseret identitet for hele organisationen, mens identiteten i Webstedsadministration kontrolleres fra websted til websted.

Brugere, der administreres fra Webstedsadministration , kan ikke have valgmuligheden Cisco-verificeret identitet. Disse brugere får udstedt et anonymt certifikat for at deltage i et slut-til-slutpunkt-krypteret møde, og de kan blive udelukket fra møder, hvor værten ønsker at sikre identitetsbekræftelse.

Yderligere ressourcer

Relaterede oplysninger

Forudsætninger

  • Webex Meetings 41.7.

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

  • Administrativ adgang til mødested i Control Hub for at aktivere den nye sessionstype for brugere.

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

  • Mødelokaler til samarbejde skal være aktiveret, så folk kan deltage fra deres videosystem. For yderligere oplysninger, se Tillad, at videosystemer deltager 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 det højeste sikkerhedsniveau og til identitetsbekræftelse skal hver enhed have et entydigt certifikat, der er udstedt af en godkendt offentlig Certificate Authority (CA).

Du skal interagere med CA 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 være udstedt og underskrevet af et velkendt offentligt CA.

  • Unik: Vi anbefaler kraftigt at bruge et entydigt certifikat for hver enhed. Hvis du bruger ét certifikat til alle enheder, kompromitterer du din sikkerhed.

  • Fælles navn (CN) og alternative emnenavn/-numre (SAN/s): 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 brugerne kontrollerer certifikatet via mødebrugergrænsefladen, vil de se SAN/'erne. Du kan bruge navne som f.eks name.model@example.com.

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

  • Formål: Certifikatformålet skal være Webex identitet.

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

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

Forbered enheder ombord

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 registrere dem til Webex endnu. For en sikkerheds skyld skal du ikke tilslutte dem til netværket på dette tidspunkt.

Hvis du har eksisterende enheder, som du vil opgradere til at bruge eksternt bekræftet identitet, skal du nulstille enhedernes fabriksindstillinger.

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

  • Planlæg et vindue, når enhederne ikke er i brug, eller brug en trinvis tilgang. Giv brugerne besked 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 færdes hemmeligheder i almindelig tekst, og at du kompromitterer din sikkerhed.

Når du har gennemført disse trin, tillad, at videosystemer deltager i møder og begivenheder på dit Webex-websted .

Forstå den eksterne identitetsproces for enheder

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 muliggøre administration af den krypterede nøgle og certifikatet ved hjælp af JSON Web Encryption (JWE).

For at sikre ægte end-to-end-kryptering via vores cloud kan vi ikke være involveret i kryptering og upload 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 se 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, er forklaret nedenfor, samt en opskrift, som du kan følge i dine foretrukne 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. Sammensæt og krypter certifikatet og nøglen ved hjælp af dit værktøj og enhedens oprindelige hemmelighed.

  6. Upload den resulterende JWE-blob til enheden.

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

  8. (Anbefales) Giv en grænseflade til (eller distribuer) dit værktøj for at gøre det muligt for enhedsbrugere 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 blobs fra dine certifikater og nøgler.

Der henvises til JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516og JSON Web Signature (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

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

  • JOSE Header (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 oprindelige 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 proprietær nøgle, og den kan have fire værdier. Vi introducerede denne nøgle for at signalere formålet med de krypterede data til målenheden. Værdierne er opkaldt efter xAPI-kommandoer på den enhed, hvor du bruger de krypterede data.

      Vi gav den navnet cisco-action for at afbøde potentielle sammenstød med fremtidige JWE-udvidelser.

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

      En anden proprietær nøgle. Vi bruger de værdier, du angiver, som input til tastafledning på enheden. Fil version skal være 1(versionen af vores funktion til nøgleafledning). 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 initialen ClientSecret.

  • JWE initialiseringsvektor . Du skal angive en base64url-kodet initialiseringsvektor til dekryptering af nyttelasten. Den 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 ønsker at holde hemmelig.

    Nyttelasten MÅ være tom. Hvis du f.eks. vil nulstille klienthemmeligheden, skal du overskrive den med en tom værdi.

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

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

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

    • Med " "cisco-action":"activate" krypteringsteksten er fingeraftrykket (hexadecimal repræsentation af sha-1) for det certifikat, vi aktiverer til bekræftelse af enhedsidentitet.

    • Med " "cisco-action":"deactivate" krypteringsteksten er 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 godkendelsestagget til at kontrollere integriteten af hele den kompakte JWE-blob med kompakt serialisering

Hvordan vi udleder krypteringsnøgle fra ClientSecret

Efter den første population af hemmeligheden accepterer eller udskriver vi ikke hemmeligheden som almindelig tekst. Dette er for at forhindre potentielle ordbogsangreb fra en person, der kan få adgang til enheden.

Enhedssoftwaren bruger klienthemmeligheden som input til en nøgleafledningsfunktion (kdf) og bruger derefter den afledte nøgle til indholdsdekryptering/kryptering af 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 krypterings-/dekrypteringsnøgle fra klienthemmeligheden.

Enhederne bruger kryptere for nøgleafledning (sehttps://en.wikipedia.org/wiki/Scrypt ), med følgende parametre:

  • CostFactor (N) er 32768

  • BlockSizeFactor (r) er 8

  • Paralleliseringsfaktor (p) er 1

  • Salt er en tilfældig sekvens på mindst 4 byte; du skal levere denne samme salt når du angiver cisco-kdf-parameter.

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

  • Det maksimale hukommelsesdæksel er 64 MB

Dette sæt af parametre er den eneste konfiguration af kryptere der er kompatibel med tastafledningsfunktionen på enhederne. Denne kdf på enhederne kaldes "version":"1", som er den eneste version, der i øjeblikket bruges af cisco-kdf-parameter.

Bearbejdet eksempel

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

Eksemplet 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 + tast). Klienthemmeligheden i eksemplet er ossifrage.

  1. Vælg en krypteringskrypteringskode. Dette eksempel bruger A128GCM(AES med 128-bit nøgler i Galois-tællertilstand). Dit værktøj kunne 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 indkode sekvensen for at få 5eZTCAP4M_Y(fjern base64-polstringen).

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

    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 til brug som 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 base64url-indkode den:

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

    Den base64url-kodede JOSE-header er eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Dette bliver det første element i JWE-blobben.

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

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

  8. Brug dit JWE-krypteringsværktøj til at producere 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

    • Krypteringskrypteringen er AES 128 GCM

    • Den base64url-kodede JOSE-header som AAD (Additional Authenticated Data)

    Base64url koder den krypterede nyttelast, hvilket skulle resultere i f5lLVuWNfKfmzYCo1YJfODhQ

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

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

    Dette er det femte element i JWE-klatten.

  10. Sammenknyt de fem elementer i JWE-klatten med prikker (JOSEheader..IV.Ciphertext.Tag) for at få:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.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 fungerer faktisk ikke, men i princippet vil dit næste trin være 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 møder med nultillid er tilgængelige for alle mødewebsteder uden ekstra omkostninger. En af disse sessionstyper kaldes Pro-End to End Encryption_VOIPonly. Det er navnet på den offentlige tjeneste, som vi kan ændre i fremtiden. For de aktuelle navne på sessionstyperne, se Sessionstype-id'er i Reference afsnit 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 samtidig 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 Fælles indstillinger , skal du vælge Sessionstyper .

4
Du bør se en eller flere slut-til-slutkrypteringssessionstyper. Se listen over Sessionstype-id'er i Reference afsnit i denne artikel. Du kan f.eks. se Pro-End to End Encryption_ Kun VOIP .

 

Der er en ældre sessionstype med et meget lignende navn: Pro-End to End-kryptering . Denne sessionstype omfatter ikke-krypteret PSTN-adgang til møder. Sørg for, at du har_ Kun VOIP version for at sikre end-to-end kryptering. Du kan kontrollere ved at holde markøren over PRO link i kolonnen sessionskode; i dette eksempel skal målet for linket være javascript:ShowFeature(652).

Vi kan ændre Public Service-navnene for disse sessionstyper i fremtiden.

5

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

Næste trin

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

Marker feltet ved siden af Pro-End to End Encryption_ Kun VOIP .

5

Luk brugerkonfiguration .

6

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

Hvis du vil 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 Download . (Du skal manuelt lukke pop op-vinduet, efter du har klikket Download .)

6

Åbn den downloadede CSV-fil til redigering.

Der er en række for hver bruger, og MeetingPrivilege indeholder deres 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 i den kommaseparerede liste i MeetingPrivilege celle.

Den Webex CSV -filformatreference indeholder oplysninger om formålet med og indholdet af CSV-fil.

8

Åbn konfigurationspanelet for mødested 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å Mængdeadministration.

10

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

11

Når importen er fuldført, kan du klikke på Importer resultater for at se, om der var nogen fejl.

12

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

Tilføj et lydvandmærke med henblik på sikkerheden

Du kan tilføje et vandmærke til mødeoptagelser med Webex Meetings Pro-End to End Encryption_VOIPonly sessionstype, 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 er større end 500 MB.
  • Optagelsen skal være længere end 100 sekunder.
  • Du kan kun analysere optagelser for møder, der er vært for personer i din organisation.
  • Watermark-oplysninger opbevares i samme varighed som organisationens mødeoplysninger.
Føj lydvandmærker til E2EE-møder
  1. Log på Control Hub – under Management (Administration) skal du derefter vælge Organization Settings (Organisationsindstillinger).
  2. I den Mødevandmærker sektionen skal du slå til Tilføj lydvandmærke .

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

Upload og analyser et møde med vandmærke
  1. I Control Hub, under Overvågning , skal du vælge Fejlfinding .
  2. Klik på Analyse af vandmærke .
  3. Søg efter eller vælg mødet på listen, og klik derefter på Analyser.
  4. I den Analysér lydvandmærke vindue, skal du angive et navn til din analyse.
  5. (Valgfrit) 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å Analysér vandmærke side.

  8. Vælg mødet på listen for at se resultaterne af analysen. Klik på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, der slukker lyden, 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.

Indbyggede enheder (internt CA)

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

Denne procedure vælger, hvilket domæne enheden bruger til at identificere sig selv, og er kun nødvendig, 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-verificeret" 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 med Registrer en enhed til Cisco Webex ved hjælp af API eller lokal webgrænseflade eller Cloudonboarding til board-, bord- og lokaleserier . 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 derunder Ledelse , skal du vælge Enheder .

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.

Indbyggede enheder (eksternt CA)

Før du begynder

Du skal bruge:

  • For at få et CA-signeret certifikat og en privat nøgle skal du ind .pem format for hver enhed.

  • For at læse emnet Forklaring af ekstern identitetsproces for enheder , i Forbered dig del af denne artikel.

  • For at forberede et JWE-krypteringsværktøj med hensyn til oplysningerne der.

  • Et værktøj til at generere tilfældige bytesekvenser med en given længde.

  • Et værktøj til base64url-kodning af byte eller tekst.

  • En scrypt implementering.

  • Et hemmeligt ord eller en hemmelig sætning for hver enhed.

1

Udfyld enhedens ClientSecret med en almindelig tekst-hemmelighed:

Første gang du udfylder Secret, angiver du den i ren tekst. Derfor anbefaler vi, at du gør dette på den fysiske enhedskonsol.

  1. Base64url 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 den og skal nulstille enheden til fabriksindstillinger for at starte igen.
2

Sammensæt dit certifikat og din private nøgle:

  1. Brug et tekstredigeringsprogram til at åbne .pem-filerne, indsætte key-blob-certifikatet og gemme den som en ny .pem-fil.

    (Dette er nyttelastteksten, du krypterer og lægger i din JWE-blob)

3

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

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

  2. Udled en indholdskrypteringsnøgle med dit krypteringsnøgle .

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

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

  4. Opret en JOSE-header, indstilling alg, enc og cisco-kdf taster som beskrevet i Forklaring af ekstern identitetsproces for enheder . Indstil handlingen "Tilføj" ved hjælp af nøglen:værdi "cisco-action":"add" i din JOSE-header (fordi vi tilføjer certifikatet til enheden).

  5. Base64url koder JOSE-headeren.

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

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

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

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

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

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

Kontrollér, 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 outputtet af xcommand Security Certificates Services Show.

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

  3. Udled en indholdskrypteringsnøgle med dit krypteringsnøgle .

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

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

  5. Opret en JOSE-header, indstilling alg, enc og cisco-kdf taster som beskrevet i Forklaring af ekstern identitetsproces for enheder . Indstil handlingen "aktiver" ved hjælp af tasten:værdi "cisco-action":"activate" i din JOSE-header (fordi vi aktiverer certifikatet på enheden).

  6. Base64url koder JOSE-headeren.

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

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

  8. Base64urlencode det krypterede fingeraftryk og godkendelseskoden.

  9. Konstruer JWE-blobben 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 at identificere den i end-to-end krypterede Webex -møder.
7

Indbygget enheden i din Control Hub-organisation.

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

1

Planlæg et møde af den rigtige type ( Webex Meetings Pro-end til slut Encryption_ Kun VOIP ).

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, hvis identitet er bekræftet af Webex CA.

4

Som vært skal du kontrollere, at denne enhed vises i lobbyen med det rigtige identitetsikon.

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

5

Deltag i mødet fra en enhed, der har sin identitet bekræftet af et eksternt CA.

6

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

7

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

8

Som vært skal du kontrollere, at denne deltager vises i lobbyen med det rigtige identitetsikon.

9

Som vært skal du tillade eller afvise personer/enheder.

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 slut-til-slutpunkt-krypterede møder til standard mødeindstilling, aktivere den kun for nogle brugere, eller tillade alle værter at bestemme? 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 de kan forvente af mødet.

Har du brug for at sikre, at hverken Cisco eller andre kan dekryptere dit indhold eller efterligne dine enheder? Hvis det er tilfældet, skal du have certifikater fra et offentligt CA. Du må kun have op til 25 enheder i et sikkert møde. Hvis du har brug for dette sikkerhedsniveau, bør du ikke tillade, at mødeklienter deltager.

For brugere, der deltager med sikre enheder, skal du først lade enheder deltage og indstille brugernes forventninger om, at de muligvis ikke kan deltage, hvis de deltager for sent.

Hvis du har forskellige niveauer af identitetsbekræftelse, skal du give brugerne mulighed for at bekræfte hinanden med certifikatbaseret identitet og mødesikkerhedskoden. Selvom der er omstændigheder, hvor deltagere kan vises som ikke-bekræftede, og deltagerne skal vide, hvordan de kontrollerer, er ikke-bekræftede personer muligvis ikke bedragere.

Identitetsstyring

Hvis du bruger et eksternt CA til at udstede dine enhedscertifikater, påhviler det dig at overvåge, opdatere og anvende certifikater igen.

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

Sessionstype-id'er

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

Sessionstype- ID

Public Service-navn

638

Kun E2E Encryption+ VoIP

652

Pro-End to End Encryption_ Kun VOIP

660

Pro 3 Free-End to End Encryption_ Kun VOIP

E2E-kryptering + identitet

672

Pro 3 Free50-End to End Encryption_ Kun VOIP

673

Uddannelsesinstruktør E2E Encryption_ Kun VOIP

676

Broadworks Standard plus slutpunkt-til-slutkryptering

677

Broadworks Premium plus slut-til-slutkryptering

681

Schoology Free plus ende-til-slut-kryptering

Relaterede xAPI-kommandoer

Disse tabeller beskriver Webex -enheders API-kommandoer, vi tilføjede til slutpunkt-til-slutpunkt-krypterede møder og bekræftet identitet. For yderligere oplysninger om, hvordan du bruger API'et, se Få adgang til API'et for Webex og bordenheder og Webex Boards .

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

  • Registreret til Webex

  • Registreret on-premise og linket til Webex med Webex Edge til enheder

Tabel 2. API'er på systemniveau 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ø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 kan ikke anvendes, 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 slut-til-slutpunkt-krypteret møde. Cloud API kalder det, så en parret app ved, om den kan bruge enheden til at deltage.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Angiver, om enheden bruger External verifikation (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. Replace specificinfo med en af:

  • Fingerprint

  • NotAfter Slutdato for gyldighed

  • NotBefore Gyldigheds startdato

  • 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, der er 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. Replace specificinfo med en af:

  • Fingerprint

  • NotAfter Slutdato for gyldighed

  • NotBefore Gyldigheds startdato

  • 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. In call 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 ren tekstværdi til såning af klienthemmeligheden på enheden for første gang.

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

xCommand Security Certificates Services Add JWEblob

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

Vi udvidede 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 bestemt certifikat for WebexIdentity. Til dette Purpose, kræver kommandoen, at det identificerende fingeraftryk krypteres og serialiseres i en JWE-blob.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

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