Brugere vælger den nye mødetype, når de planlægger et møde. Når deltagere tillades 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:
Planlæg en Webex Meeting med slutpunkt-til-slutpunkt-kryptering
Deltag i Webex Meeting med slutpunkt-til-slutpunkt-kryptering
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, hvorpå 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 måden til at garantere ægte slutpunkt-til-slutpunkt-kryptering og bekræftet identitet og forhindrer, at det kan udelukke, 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.
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-serie
Webex MX-serien
Tredjeparts SIP-enheder
Softwareklienter
Fra 41.6 kan Webex Meetings desktopklient 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 for at 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 chance 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å standard krypteringsteknikker i industri, 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 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.
Tilknyttede oplysninger
Nul-tillidssikkerhed for Webex (teknisk papir til sikkerhed): https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html
Cisco Live 2021-præsentation (du skal bruge en Cisco Live-tilmelding): https://www.ciscolive.com/2021/learn/session-catalog.html?tab.digitalbundle=Anytime21&search.sessiontype=BRK&search.learningmap=1614364767910003wzD6#/session/16106298425360015zrh
JSON-webkryptering (JWE) (Udkast til IETF-standard): https://datatracker.ietf.org/doc/html/rfc7516
Brugervendt dokumentation: https://help.webex.com/5h5d8ab
Rysten prøve JWE-klats
Eksempel på korrekt krypteret JWE baseret på givne parametre (bilag)
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).
Mødelokaler til samarbejde skal være aktiveret, så personer kan deltage fra deres videosystem. Få yderligere oplysninger i Tillad videosystemer at deltage i Webex Meetings begivenheder på dit Webex-websted.
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.
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.
Når du har fuldført disse trin, skal du tillade videosystemer at deltage i møder og begivenheder på dit Webex-websted.
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 afkryptering3 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 udvidelsesmuligheder med fremtidige JWE-forlængelser."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ære1
(versionen af vores nøglefunktioner). Værdien afsalt
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 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 Ciphertext: Dette er den krypterede nyttedata, som du ønsker at hemmeligholde.
Nyttelasten kan være tom (For eksempel, for at nulstille klient hemmeligheden, 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 den nyeClientSecret
Med "
"cisco-action":"add"
kodetekst er en PEM-blob, der flimmer certifikatet og dets private nøgle (sammenkoncateret)Med "
"cisco-action":"activate"
kodetekst er fingeraftrykket (hexadecimal repræsentation af sha-1) af det certifikat, vi aktiverer, for enhedsidentitetsbekræftelseMed "
"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 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 bytes; du skal levere den samme
salt
når der angivescisco-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
.
Vælg en krypteringskode. Dette eksempel bruger
A128GCM
(AES med 128 bit-taster i den amerikanske tællertilstand). Dit værktøj kunne brugeA256GCM
hvis du foretrækker det.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).Her er et eksempel
scrypt
opkald 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 tillZ66bdEiAQV4_mqdInj_rA
.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 tilNLNd3V9Te68tkpWD
.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.
Det andet element i JWE-klaten er tomt, fordi vi ikke har nogen forbindelse til et JWE-krypteringsnøgle.
Det tredje element i JWE-klaten er initialiseringsvektoren
NLNd3V9Te68tkpWD
.- 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.
Base64url indkode tagget du skabte i trin 8, hvilket skulle resultere i
PE-wDFWGXFFBeo928cfZ1Q
Dette er det femte element i JWE-klaten.
Rysten de fem elementer i JWE-blob med punkter (JOSEheader.. IV.Ciphertext.Tag) for at få:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
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.
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 vil være tilgængelige for 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/-import.
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 Reference i denne artikel. Du kan for eksempel se Pro-End til End Encryption_VOIPonly.
|
||
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.
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. |
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 |
||
7 | For hver bruger, du vil tildele den nye sessionstype, tilføj Den Cisco Webex CSV-filformat reference indeholder oplysninger om formålet og indholdet af CSV-filen. |
||
8 | Åbn konfigurationspanelet for Meeting-webstedet i Control Hub.
|
||
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. |
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 Tilmeld en enhed for at få Cisco Webex via API eller lokal webgrænseflade eller Cloud Onboarding tilenheder. Du skal også bekræfte det/de domæne/domæner, du vil bruge til at identificere enhederne i Administrer dine enheder.
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. |
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.
For at læse emnet Forståelse ekstern identitetsproces forenheder , i Forbered delen 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 af bestemt 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 Første gang du udfylder 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: |
3 | Opret en JWE-blob, der skal bruges som input til certifikat tilføj kommandoen: |
4 | Åbn TShell på enheden, og kør kommandoen (multiline) tilføj:
|
5 | Bekræft, at certifikatet tilføjes ved at køre Kopier det nye certifikats fingeraftryk. |
6 | Aktivér certifikatet til formålet 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. |
1 | Planlæg et møde af den korrekte type (Webex Meetings Pro-End til End Encryption_VOIPonly). |
2 | Deltag i mødet som vært fra en Webex Meetings klient. |
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. |
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. Læs mere 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 deltagernes/enhedens identiteter, hvor det er muligt, ved at tjekke 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. |
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.
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.
Kommer snart.
Sessionstype-id |
Navn på offentlig tjeneste |
---|---|
638 |
Kun E2E-kryptering+VoIP |
652 |
Pro-End til end Encryption_VOIPonly |
660 |
Pro 3 gratis slut til slut Encryption_VOIPonly E2E-kryptering + identitet |
672 |
Pro 3 Free50-end til slut Encryption_VOIPonly |
673 |
Uddannelsesinstruktør 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 |
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
API-opkald |
Beskrivelse |
---|---|
|
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. |
|
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. |
|
Angiver, om enheden bruger |
|
Enhedens identitet som læst fra det eksternt udstedte certifikats fællesnavn. |
|
Læser specifikke oplysninger fra et eksternt udstedt certifikat. I den viste kommando, erstat
|
|
Status for enhedens eksterne identitet (f.eks. |
|
Angiver, om enheden har et gyldigt certifikat udstedt af Webex CA. |
|
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 |
|
Læser specifikke oplysninger fra det Webex-udstedte certifikat. I den viste kommando, erstat
|
API-opkald |
Beskrivelse |
---|---|
|
Disse tre begivenheder omfatter nu |
API-opkald |
Beskrivelse |
---|---|
eller
|
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. |
|
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. |
|
Aktiverer et specifikt certifikat for WebexIdentity. For dette |
|
Deaktiverer et specifikt certifikat for WebexIdentity. For dette |