Brugeroplevelse

Brugere vælger den nye mødetype, når de planlægger et møde. Når der tillades deltagere fra lobbyen og under mødet, kan værten se identitetsbekræftelsesstatus for hver deltager. Der findes også en mødekode, som er almindelig for alle aktuelle deltagere i mødet, som de kan bruge til at verificere hinanden.

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

Bekræfter identitet med internt eller eksternt CA

Bekræfter identitet

slutpunkt-til-slutpunkt identitetsbekræftelse giver yderligere sikkerhed til et slutpunkt-til-slutpunkt krypteret møde.

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

Brugere af -Webex Meetings-app sig selv mod Webex-identitetslager, hvilket giver dem en adgangstoken, når det lykkes. Hvis de har brug for et certifikat til at bekræfte deres identitet - i et slutpunkt-til-slutpunkt krypteret møde - udsteder Webex CA dem et certifikat baseret på deres adgangstoken. Vi tilbyder endnu ikke en måde, Webex Meetings brugere kan få et certifikat udstedt af en tredjeparts-/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:

  • For den interne CA-sag udsteder Webex 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 brugerne gør, så Webex bruger (et af) din eller dine organisations domæner, når du skriver enhedscertifikatets identitet (Common Name (CN)).

  • For den eksterne CA-sag kan du anmode om og købe 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 den måde til at garantere ægte slutpunkt-til-slutpunkt-kryptering og bekræftet identitet og forhindrer, at udpeg muligheden for, at Cisco kan aflytte på 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 API'en xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "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. Common Name (CN) og alternativt emnenavn (SAN) vises i Webex-mødets brugergrænseflade som beskrevet i Slutpunkt-til-slutpunkt-kryptering med identitetsbekræftelse for Webex Meetings.

Det anbefales at bruge et separat certifikat pr. enhed og at have en unik CN pr. enhed. Dette kan for eksempel være "meeting-room-1.example.com", for organisationen, der ejer domænet "example.com".

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 klientens hemmelighed bruges, er det muligt på sikker måde at administrere det eksterne webex-identitetscertifikat via xAPI. Dette er i øjeblikket begrænset til online-enheder.

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

Funktioner og begrænsninger

Enheder

Cloud-registrerede brugere Webex Room- og Webex Desk-serieenheder kan deltage i slutpunkt-til-slutpunkt krypterede møder, herunder:

  • Webex Board

  • Webex Desk Pro

  • Webex-skrivebord

  • Webex Room Kit

  • Webex Room Kit Mini

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

  • Webex C-serien

  • Webex DX-serien

  • Webex EX-serien

  • Webex MX-serien

  • Tredjeparts SIP-enheder

Softwareklienter

  • Fra 41.7 kan Webex Meetings desktopklient deltage i slutpunkt-til-slutpunkt krypterede møder.

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

    Hvis din organisation gør Det muligt for Webex-appen at deltage i møder ved at starte Meetings-desktopapplikationen, kan du bruge denne valgmulighed til at deltage i slutpunkt-til-slutpunkt krypterede møder.

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

  • Tredjeparts SIP-soft-klienter kan ikke deltage i slutpunkt-til-slutpunkt krypterede møder.

Identificer

  • Vi giver dig ingen valgmuligheder for control hub, så du kan administrere en eksternt bekræftet enheds identitet. Denne beslutning er pr. design, fordi for ægte slutpunkt-til-slutpunkt-kryptering bør kun du kende/tilgå hemmeligheden og tasterne. Hvis vi introducerede en cloud-tjeneste for at administrere disse nøgler, er der en mulighed for, at de bliver opsnappet.

  • Vi leverer i øjeblikket ikke nogen værktøjer til at hjælpe dig med at anmode om eller kryptere dine enheds identitetscertifikater og deres private nøgler. På nuværende tidspunkt tilbyder vi en "opskrift", så du kan designe dine egne værktøjer, baseret på branchestandard krypteringsteknikker, for at hjælpe med disse processer. Vi ønsker ikke at få nogen reelle eller oplevede adgang til dine hemmeligheds- eller nøgler.

Møder

  • slutpunkt-til-slutpunkt krypterede møder 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 imødet.

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

    For at begrænse denne begrænsning anbefaler vi mindre møder for enheder eller forskudte invitationer mellem enheder og Meetings-klienter.

Administrationsgrænseflade

Vi anbefaler på det kraftigste, at du bruger Control Hub til at administrere dit -mødewebsted.

Den primære årsag til dette er forskellen på den måde, Control Hub og webstedsadministration administrere identitet på. Control Hub-organisationer har centraliserede identiteter for hele organisationen, og i webstedsadministration kontrolleres identiteten på websted-basis.

Det betyder, at du ikke kan have valgmuligheden Cisco-bekræftet identitet for brugere, der administreres fra webstedsadministration. Disse brugere har et anonymt certifikat til at deltage i et slutpunkt-til-slutpunkt krypteret møde, og de kan blive udelukket fra møder, hvor værten ønsker at sikre identitet.

Yderligere ressourcer

Tilknyttede oplysninger

Rysten prøve JWE-klats

Eksempel på korrekt krypteret JWE baseret på givne parametre (bilag)

Forudsætninger

  • Webex Meetings 41.7.

  • Cloud-registrerede brugere Webex Room og Webex Desk-serieenheder, der kører 10.6.1-RoomOS_August_2021.

  • Administratoradgang til mødewebstedet 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 for bekræftet identitet).

Hent enhedscertifikater

Du kan springe dette trin over, hvis du ikke har brug for en eksternt bekræftet identitet.

For at opnå det højeste sikkerhedsniveau og for identitetsbekræftelse skal hver enhed have et unikt certifikat udstedt af en betroet offentlig certifikatmyndighed.

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 der anmodes om certifikatet, er disse parametre de parametre, der skal bruges:

  • 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 men det er dit valg.

  • 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 inden bord-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 ikke tilmelde dem til Webex endnu. Det er sikkert ikke engang at tilslutte dem til netværket endnu.

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

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

Forstå ekstern 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 certifikatet ved hjælp af JSON-webkryptering (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 gøre følgende:

  • Anmod om dine certifikater.

  • Generer dine certifikaters nøglepar.

  • Opret (og beskyt) en indledende hemmelighed for hver enhed for at beskytte enhedens krypteringsfunktion.

  • Udvikler og vedligeholder dit eget værktøj til kryptering af filer ved hjælp af JWE-standarden.

    Herunder forklarer vi processen og de (ikke-hemmelige) parametre, du skal bruge, og en opskrift, der skal følges i dine udviklingsværktøjer efter eget valg. 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 aftele3 og JWCrypto-biblioteket er tilgængeligt fra Cisco på anmodning.

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

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

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

  • (Anbefalet) Angiv en grænseflade til (eller distribuer) dit værktøj for at gøre det muligt for enhedsbrugere at ændre den oprindelige hemmelighed (for at beskytte deres medier fra 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.

Du skal se JSON-webkryptering (JWE) oghttps://datatracker.ietf.org/doc/html/rfc7516JSON Web Signature (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Vi valgte at bruge Compact Serialization af et JSON-dokument til at oprette JWE-klatter. De parametre, du skal inkludere ved oprettelse af JWE-klats er:

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

    • "alg":"dir"

      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-action": "add" eller "cisco-action": "populate" eller "cisco-action": "activate" eller "cisco-action": "deactivate"

      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 navngivne den cisco-action for at begrænse potentielle forlængelser med JWE-forlængelser i fremtiden.

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

      En anden navnebeskyttet nøgle. Vi bruger de værdier, du giver som input til vigtige oplysninger på enheden. , version skal være 1(versionen af vores nøglefunktioner). Værdien af salt skal være en base64 URL-kodet sekvens af mindst 4 bytes, som du skal vælge tilfældigt.

  • JWE krypteret nøgle. Dette felt er tomt. Enheden stammer fra den indledende ClientSecret.

  • JWE initialiserings vektor. 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 Ciphertext: Dette er den krypterede nyttedata, som du ønsker at hemmeligholde.

    Nyttelasten kan være tom (For eksempel, for at nulstille klientens hemmelighed, skal du 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 nyttedata, og du skal angive formålet med nyttelasten med cisco-action nøgle, som følger:

    • Med "cisco-action":"populate" kodetekst er det nye ClientSecret

    • Med " "cisco-action":"add" kodetekst er en PEM-flimmer, der krypter certifikatet og dets private nøgle (sammenkædt)

    • Med " "cisco-action":"activate" kodetekst er fingeraftrykket (hexadecimal repræsentation af sha-1) af det certifikat, vi aktiverer, for enhedsidentitetsbekræftelse

    • Med " "cisco-action":"deactivate" kodetekst er fingeraftrykket (hexadecimal repræsentation af sha-1) af certifikatet, som vi deaktiverer fra at blive brugt til enhedsidentitetsbekræftelse

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

Hvordan vi får krypteringsnøgle fra ClientSecret

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

Enhedssoftwaren bruger klient hemmeligheden som et input til en nøglenø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 https://en.wikipedia.org/wiki/Scrypt) med følgende parametre:

  • CostFaktorer (N) er 32768

  • BlockSizeKomponent (r) er 8

  • ParallelizationFaktorer (p) er 1

  • Salt er en tilfældig sekvens på mindst 4 bytes; du skal levere den samme salt når der angives cisco-kdf-parameter.

  • 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. Der kaldes denne kdf på enhederne "version":"1", som er den eneste version, der i øjeblikket er taget af cisco-kdf-parameter.

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). Klient hemmeligheden i eksemplet er ossifrage.

  1. Vælg en krypteringskode. Dette eksempel bruger A128GCM(AES med 128 bit-taster i den amerikanske 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 bytes). Dette eksempel bruger (hex bytes) E5 E6 53 08 03 F8 33 F6. Base64url indkode sekvensen for at få 5eZTCAP4M_Y(fjern base64-udfyldning).

  3. Her er et eksempel scrypt ring op for at oprette krypteringsnøgle (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 bytes (hex) som følger: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac hvilke base64url-koder til lZ66bdEiAQV4_mqdInj_rA.

  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 hvilke base64url-koder til NLNd3V9Te68tkpWD.

  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":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

    Den base64url-kodede JOSE-header er eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    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-blob'en er initialiseringsvektoren NLNd3V9Te68tkpWD.

  8. Brug dit JWE-krypteringsværktøj til at producere en krypteret nyttedata og -tag. For dette eksempel vil den ukrypterede nyttedata være den falske PEM blob this is a PEM file

    De krypteringsparametre, du skal bruge, er:

    • Nyttedata er this is a PEM file

    • Krypteringskode er AES 128 GCM

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

    Base64url indkode den krypterede nyttedata, hvilket bør resultere i f5lLVuWNfKfmzYCo1YJfODhQ

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

  9. Base64url indkode tagget du skabte i trin 8, som skulle resultere i PE-wDFWGXFFBeo928cfZ1Q

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

    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 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 Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Der findes nye sessionstyper for nul-tillidsmøder, som vi udruller til alle mødewebsteder uden ekstra omkostninger. En af de nye 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å sessionstyper, se Sessionstype-ID'er i afsnittet Reference i denne artikel.

Du skal ikke gøre noget for at få den nye funktion til dit websted, men 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/importrundrejse.

Bekræft ny sessionstype

1

Log ind på Control Hub, og åbn siden Møde.
2

Klik på dit websteds navn for at åbne webstedets konfigurationspanel.
3

Klik på Konfigurer websted.
4

I området Almindelige indstillinger skal du klikke påSessionstyper.

På den side bør du se en eller flere slutpunkt-til-slutpunkt-krypteringssessionstyper. Se listen over sessionstype-JEG'er i afsnittet Med henvisning til denne artikel. Du kan for eksempel se Pro-End to End Encryption_VOIPonly.

 

Der er en ældre sessionstype med et meget lignende navn: Pro-end-til-slutpunkt-kryptering. Denne sessionstype inkluderer ikke-krypteret PSTN adgang til møder. Sørg for, at du har den _VOIPonly for at sikre slutpunkt til slutpunkt kryptering. Du kan kontrollere ved at holde musen over PRO-linket i kolonnen sessionskode; for dette eksempel skal målet med linket være javascript:ShowFeature(652).

Vi kan ændre navnene på offentlige tjenester for disse sessionstyper i fremtiden, for eksempel planlægger vi at ændre Pro-End til End Encryption_VOIPonly til E2E Kryptering + Identitet.
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.

Aktiver E2EE-møder for individuelle brugere

1

Klik på Brugere, og vælg en bruger for at åbne brugerens konfigurationspanel.
2

I området Tjenester skal du klikke på Cisco Webex Meetings.
3

Vælg webstedet (hvis brugeren er i mere end ét), og klik på Vært.
4

Marker afkrydsningsfeltet ved siden af Webex Meetings, der er mærket Pro-End til End Encryption_VOIPonly.
5

Luk brugerkonfigurationspanelet.
6

Gentag for andre brugere, hvis nødvendigt.

Hvis du vil tildele dette til mange brugere, skal du bruge CSV-massevalgmuligheden.

Aktiver E2EE-møder for flere brugere

1

Log ind på Control Hub på https://admin.webex.com , og åbn siden Møde.
2

Klik på dit websteds navn for at åbne panelet webstedskonfiguration.
3

I afsnittet Licenser og brugere skal du klikke på Masse administrer.
4

Klik påEksporter , 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, efter du klikker på Download.)
6

Åbn den downloadede CSV-fil til redigering.

Der er en række for hver bruger, og MeetingPrivilege kolonne indeholder deres sessionstype-sessionstype som en kommasepareret liste.

7

For hver bruger, du vil tildele den nye sessionstype, tilføj 1561 som en ny værdi i den kommaseparerede liste i MeetingPrivilege Celle.

CSV-filformat reference på https://help.webex.com/en-us/5vox83 har nogle detaljer om formålet og indholdet af CSV-filen.
8

Åbn konfigurationspanelet for Meeting-websted 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 vi overfører filen.
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.

Inden bord-enheder (Intern 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 nulstille enhederne fra fabriksnulstilling.

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ælger vi et, og det kan se forkert ud for andre mødedeltagere.

Før du begynder

Hvis dine enheder endnu ikke er onboardet, kan du følge https://help.webex.com/n25jyr8 eller https://help.webex.com/nutc0dy. Du skal også bekræfte det/de domæne/domæner, du ønsker at bruge til at identificere enhederne (https://help.webex.com/cd6d84).

1

Log ind på Control Hub (https://admin.webex.com), og åbn siden 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 (ekstern CA)

Før du begynder

Du har brug for:

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

  • Læs emnet Forståelse af ekstern identitetsproces for enheder idelen Forbered i 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 af den givne længde.

  • Et værktøj til at base64url kode bytes eller tekst.

  • En scrypt Gennemførelsen.

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

1

Udfyld enhedens ClientSecret med en ren tekst hemmelig:

Første gang du udfylder Secret, du leverer den i ren tekst. Det er derfor, vi anbefaler, at du gør dette på den fysiske enheds konsol.

  1. Base64url indkode 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 indledende hemmelighed. Husk på, at du ikke kan gendanne den, og du skal nulstille enheden fra fabriksnulstilling for at starte den igen.
2

Aktiver dit certifikat og private nøgle:

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

    (Dette er teksten til nyttedata, du skal kryptere og putte 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 et JOSE-sidehoved, indstilling alg, enc og cisco-kdf nøgler som beskrevet i Forståelse af ekstern identitetsproces for enheder. Indstil "tilføj"-handlingen ved hjælp af tasten:value "cisco-action":"add" 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 den base64url-kodede 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):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag
4

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

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

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

Kopier det nye certifikats fingeraftryk.
6

Aktivér certifikatet til formålet WebexIdentity:

  1. Læs fingeraftrykket af certifikatet, enten fra certifikatet i sig selv 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 et JOSE-sidehoved, indstilling alg, enc og cisco-kdf nøgler som beskrevet i Forståelse af ekstern identitetsproces for enheder. Indstil "aktiver"-handlingen ved hjælp af tasten key:value "cisco-action":"activate" 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):

    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 brug til at identificere det i slutpunkt-til-slutpunkt krypterede Webex-møder.
7

Onboard enheden i din Control Hub-organisation.

Test E2EE-kryptering og bekræftet identitet

1

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

Se .https://help.webex.com/nsj2xpfb
2

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

Se https://help.webex.com/rzam8
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 https://help.webex.com/rzam8/Join-a-Webex-Meeting-with-End-to-End-Encryption#Cisco_Generic_Topic.dita_152cb705-3165-4bc8-8370-445411d656d3
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.
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 deltagernes/enhedens 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. Du har muligvis kun op til 25 enheder i et sikkert møde. Hvis du har brug for dette sikkerhedsniveau, bør du ikke tillade mødeklienter at deltage.

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

Hvis du har forskellige identitetsbekræftelsesniveauer, så giv brugere mulighed for at bekræfte hinanden med certifikat-understøttet identitet og mødets sikkerhedskode. 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.

Nul-tillidsmøder Ofte stillede spørgsmål

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

660

Pro 3 free-end til-Encryption_VOIPonly

E2E-kryptering + identitet

672

Pro 3 Free50-slut til Encryption_VOIPonly

673

Education Instructor E2E Encryption_VOIPonly

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. For at læse mere om, hvordan du bruger API, se https://help.webex.com/nzwo1ok.

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

API-opkald

Beskrivelse

xConfiguration Conference EndToEndEncryption Mode: On

Slår afslutning til slutpunkt-krypteringstilstand On eller Off.

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 er ikke gældende, 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 op til den, så en parret app ved, om den kan bruge enheden til at deltage.

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Angiver, om enheden har et gyldigt eksternt udstedt certifikat.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Læser certifikatoplysningerne fra det eksternt udstedte certifikat og udskriver det som et JSON-blob.

xStatus Conference EndToEndEncryption InternalIdentity Valid

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æ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 PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Læser certifikatoplysningerne fra det Webex-udstedte certifikat og udskriver det som et JSON-blob.
Tabel 3. Api'er til opkald for slutpunkt-til-slutpunkt krypterede møder og bekræftet identitet

API-opkald

Beskrivelse

xStatus Call # ServerEncryption Type

Læser den krypteringskode, der bruges i HTTPS-forbindelsen til Webex. Dette vises for brugeren.

xStatus Conference Call # EndToEndEncryption Status

Læser status for slutpunkt-til-slutpunkt-kryptering i opkald. Vises for brugeren som tilstedeværelsen (eller fraværet) af hængelås-ikonet.

xStatus Conference Call # EndToEndEncryption SecurityCode

Læser mødets sikkerhedskode. Dette vises for brugeren, og det ændres, når deltagerne deltager.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Læser den krypteringskode, der bruges i medieforbindelsen. Dette vises for brugeren.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Læser krypteringskrypteringsfunktionen, der bruges til Messaging Layer Security (VEDR.).

xStatus Conference Call # EndToEndEncryption Roster Participant

Angiver de deltagere, der bidrager til TILSTANDENS gruppetilstanden i dette møde. Listen bliver opdaget af NUS, ikke Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

WDM URL-adressen for en angivet deltager.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

Bekræftelsesstatussen for den angivne deltager.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

Den specifikke deltagers primære identitet, typisk et domæne (enhed) eller en e-mailadresse (bruger).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

Det viste navn på den angivne deltager. Underskrevet af deltageren/enheden.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

Certifikatoplysningerne fra den specificerede deltagers certifikat som en JSON-blob.

xCommand Conference ParticipantList Search

Vi udvidede denne kommando til at inkludere oplysninger om slutpunkt-til-slutpunkt-kryptering for deltagere.

xCommand Conference ParticipantList Search

Søgningen efter deltagerliste inkluderer nu EndToEndEncryptionStatus, deltagerens identitetsbekræftelsesstatus. Denne værdi vises i brugergrænsefladen.

xCommand Conference ParticipantList Search

Søgningen efter deltagerliste inkluderer nu EndToEndEncryptionIdentity, deltagerens primære identitet. Dette er typisk et domæne eller en e-mailadresse. Denne værdi vises i brugergrænsefladen.

xCommand Conference ParticipantList Search

Søgningen efter deltagerliste inkluderer nu EndToEndEncryptionCertInfo, den JSON-klat, der indeholder deltagerens certifikat. Denne værdi vises i brugergrænsefladen.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

Disse tre begivenheder omfatter nu EndToEndEncryptionStatus, EndToEndEncryptionIdentity og EndToEndEncryptionCertInfo for den påvirkede 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 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 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 for WebexIdentity. For dette Purpose, kræver, at det identificerende fingeraftryk krypteres og serieliseres i en JWE-blob.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Deaktiverer et specifikt certifikat for WebexIdentity. For dette Purpose, kræver, at det identificerende fingeraftryk krypteres og serieliseres i en JWE-blob.