Användare väljer den nya mötestyp när de schemalägger ett möte. När deltagare släppas in från lobbyn och under mötet kan värden se varje mötesdeltagares identitetsverifieringsstatus. Det finns också en möteskod som är gemensam för alla nuvarande deltagare i mötet, som de kan använda för att verifiera varandra.
Dela följande information med dina mötesvärdar:
Schemalägg ett Webex Meeting med slutpunkt-till-slutpunkt-kryptering
Delta i Webex Meeting med end-to-end-kryptering
Verifierar identitet
slutpunkt-till-slutpunkt identitetsverifiering ger extra säkerhet för ett ände-till-ände-krypterat möte.
När mötesdeltagare eller enheter ansluter till en delad MLS-grupp (Messaging Layer Security) presenterar de sina certifikat för andra gruppmedlemmar som sedan validerar certifikaten mot den certifikatutfärdare/ies (CA). Genom att bekräfta att certifikaten är giltiga verifierar CA deltagarnas identitet och mötet visar mötesdeltagarna/enheterna som verifierade.
Användare av -Webex Meetings-app autentisera sig själva mot Webex identitets lagring, vilka utfärdar dem en åtkomsttoken när de lyckas. Om de behöver ett certifikat för att verifiera sin identitet – i ett end-to-end-krypterat möte – skickar Webex CA ut ett certifikat baserat på deras åtkomsttoken. Vi tillhandahåller ännu inte ett sätt för Webex Meetings att få ett certifikat utfärdat av tredje part/extern CA.
Enheter kan autentisera sig själva med ett certifikat utfärdat av intern (Webex) CA, eller ett certifikat utfärdat av en extern CA:
I det interna CA-ärendet utfärdar Webex ett internt certifikat baserat på åtkomsttoken till enhetens datorkonto. Certifikatet signeras av Webex CA. Enheter har inte användar-ID på samma sätt som användare gör, så Webex använder (en av) din organisations domäner när de skriver in enhetscertifikatens identitet (Common Name (CN)).
I det externa CA-fallet begär och köper du enhetscertifikat direkt från din valda utfärdare. Du måste kryptera, direktuppladda och auktorisera certifikaten med en hemlighet som endast är känd av dig.
Cisco är inte engagerade, vilket gör det här sättet att garantera sann end-to-end-kryptering och verifierad identitet, och förhindrar den eventuellt föraktade möjligheten att Cisco kan avlyssna på ditt möte/dekryptera din media.
Internt utfärdat enhetscertifikat
Webex utfärdar ett certifikat till enheten när den registrerar sig efter start, och förnyar det när det behövs. För enheter innehåller certifikatet konto-ID och en domän.
Om din organisation inte har en domän utfärdar Webex CA certifikatet utan en domän.
Om din organisation har flera domäner kan du använda Control Hub för att tala om för Webex vilken domän enheten ska använda för sin identitet. Du kan även använda API:et xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"
.
Om du har flera domäner och inte anger enhetens önskade domän väljer Webex en åt dig.
Externt utfärdat enhetscertifikat
En administratör kan tillhandahålla en enhet med sina egna certifikat som har signerats med en av de offentliga certifikatutfärdaren.
Certifikatet måste baseras på ett ECDSA P-256-nyckelpar, även om det kan signeras med en RSA-nyckel.
Värdena i certifikatet ligger efter organisationens omdöme. Common Name (CN) och alternativt ämnesnamn (SAN) kommer att visas i webex-mötets användargränssnitt, så som beskrivs i slutpunkt-till-slutpunkt-kryptering med identitetsverifiering för Webex Meetings.
Vi rekommenderar att du använder ett separat certifikat per enhet och att ha en unik CN per enhet. Det kan till exempel vara "meeting-room-1.example.com", för organisationen som äger domänen "example.com".
För att fullt ut skydda det externa certifikatet från manipulering används en klienthemlig funktion för att kryptera och signera olika xcommands.
När man använder klienthemligheten är det möjligt att på ett säkert sätt hantera det externa Webex-identitetscertifikatet via xAPI. Detta är för närvarande begränsat till online-enheter.
Webex tillhandahåller för närvarande API-kommandon för hantering av detta.
Enheter
Enheter i molnregistrerade Webex Room och Webex Desk-serien kan delta i möten med end-to-end-kryptering, däribland:
Webex Board
Webex Desk Pro
Webex-skrivbord
Webex Room-paket
Webex Room Kit Mini
Följande enheter kan inte delta med end-to-end-krypterade möten:
Webex C-serien
Webex DX-serien
Webex EX-serien
Webex MX-serien
SIP-enheter från tredje part
Programvaruklienter
Från och med 41.6 Webex Meetings skrivbordsklienten delta i möten med end-to-end-kryptering.
Om din organisation gör det möjligt för Webex-appen att delta i möten genom att starta Meetings-skrivbordsprogrammet, kan du använda det alternativet för att delta i möten som är end-to-end-krypterade.
Webex-webbklienten kan inte delta i möten med end-to-end-kryptering.
SIP-klienter från tredje part kan inte delta i möten som är end-to-end-krypterade.
Identitet
Vi tillhandahåller inga Control Hub-alternativ för att du ska kunna hantera externt verifierade enhetsidentiteter. Detta beslut är per design eftersom det endast är du som ska känna till/få åtkomst till nyckeln för den rätta slutpunkt-till-slutpunkt-krypteringen. Om vi har introducerat en molntjänst för att hantera nycklarna finns det en risk att de fångas upp.
Vi tillhandahåller för närvarande inga verktyg som hjälper dig att begära eller kryptera dina enhets identitetscertifikat och deras privata nycklar. För närvarande tillhandahåller vi ett "recept" som hjälper dig att utforma dina egna verktyg, baserade på tekniker för branschstandardkryptering, för att hjälpa till med dessa processer. Vi vill inte ha någon verklig eller upplevd åtkomst till din dator eller dina nycklar.
Meetings
slutpunkt-till-slutpunkt möten har för närvarande stöd för högst 200 mötesdeltagare.
Av de 200 deltagarna kan maximalt 25 externt verifierade enheter delta, och de måste vara de första mötesdeltagarna som deltar imötet.
När ett större antal enheter ansluter till ett möte försöker våra backend-medietjänster koda om medieströmmarna. Om vi inte kan avkryptera, omkoda och omkryptera mediet (eftersom vi inte har och inte bör ha enheternas krypteringsnycklar) misslyckas omkodningen.
För att begränsa denna begränsning rekommenderar vi mindre möten för enheter eller tagga inbjudningarna mellan enheter och Meetings-klienter.
Hanteringsgränssnitt
Vi rekommenderar starkt att du använder Control Hub för att hantera din möteswebbplats.
Huvudorsaken är skillnaden mellan hur Control Hub och webbplatsadministration hanterar identitet. Control Hub-organisationer har centraliserad identitet för hela organisationen och i webbplatsadministration kan identiteten styras på webbplats-per-webbplatsbasis.
Det innebär att du inte kan ha alternativet Cisco-verifierad identitet för användare som hanteras från webbplatsadministration. Dessa användare har utfärdat ett anonymt certifikat för att delta i ett end-to-end-krypterat möte och de kan uteslutas från möten där värden vill garantera identiteten.
Relaterad information
Zero-Trust Security för Webex (säkerhetsdokument): https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html
Cisco Live 2021-presentation (du behöver en Cisco Live-registrering): https://www.ciscolive.com/2021/learn/session-catalog.html?tab.digitalbundle=Anytime21&search.sessiontype=BRK&search.learningmap=1614364767910003wzD6#/session/16106298425360015zrh
JSON Web Encryption (JWE) (utkast till IETF-standard): https://datatracker.ietf.org/doc/html/rfc7516
Användarriktad dokumentation: https://help.webex.com/5h5d8ab
Avivinga exempel JWE ögonblicksbilder
Exempel på korrekt krypterad JWE baserat på angivna parametrar (bilaga)
Webex Meetings 41.7.
Enheter i molnregistrerade Webex Room och Webex Desk-serien som körs
10.6.1-RoomOS_August_2021
.Administrativ åtkomst till möteswebbplatsen i Control Hub för att aktivera det nya sessionstyp för användarna.
En eller flera verifierade domäner i din Control Hub-organisation (om du använder Webex CA för att utfärda enhetscertifikat för verifierad identitet).
Mötesrum för samarbete måste aktiveras så att personer kan delta från sina videosystem. Mer information finns i Tillåt videosystem att delta i Webex Meetings och Händelser på din Webex-webbplats.
Du kan hoppa över det här steget om du inte behöver verifiera din identitet externt.
För högsta säkerhetsnivå och för identitetsverifiering bör varje enhet ha ett unikt certifikat utfärdat av en betrodd offentlig certifikatutfärdare.
Du måste interagera med CA för att begära, köpa och ta emot digitala certifikat och skapa associerade privata nycklar. När du begär att få certifikatet är detta de parametrar som ska användas:
Certifikatet måste utfärdas och signeras av en välkänd offentlig CA.
Unik: Vi rekommenderar starkt att du använder ett unikt certifikat för varje enhet. Om du använder ett certifikat för alla enheter utser du säkerheten.
Vanligt namn (CN) och ämnets alternativa namn/n (SAN/s): Dessa är inte viktiga för Webex, men det bör vara värden som har lästs in och associeras med enheten. CN visar för andra mötesdeltagare som enhetens primära verifierade identitet och om användare kontrollerar certifikatet via mötesgränssnittet ser de SAN/s. Du kanske vill använda namn som
name.model@example.com
men det är ditt val.Filformat: Certifikaten och nycklarna måste vara i .pem-format.
Syfte: Certifikatets syfte måste vara Webex-identitet.
Genererar nycklar: Certifikaten måste baseras på nyckelpar för ECDSA P-256 (Elliptical Curve Digital Signature Algorithm med P-256-curve).
Det här kravet omfattar inte signeringsnyckeln. CA kan använda en RSA-nyckel för att signera certifikatet.
Du kan hoppa över det här steget om du inte vill använda externt verifierad identitet med dina enheter.
Om du använder nya enheter ska du inte registrera dem i Webex än. Det är säkrast att inte ens ansluta dem till nätverket än.
Om du har befintliga enheter som du vill uppgradera för att använda externt verifierad identitet måste du fabriksåterställning av enheterna.
Spara befintlig konfiguration om du vill behålla den.
Schemalägg ett fönster när enheterna inte används, eller använd en fasad metod. Meddela användarna om de ändringar som de kan förvänta sig.
Säkerställ fysisk åtkomst till enheter. Om du måste ha tillgång till enheter över nätverket ska du tänka på att det finns en oformaterad resa och att du inte har någon säkerhetsrisk.
Låt videosystemen delta i Meetings och Events på din Webex-webbplats när du har slutfört dessasteg.
För att säkerställa att din enhetsmedia inte kan krypteras av någon annan än enheten måste du kryptera enhetens privata nyckel. Vi har utformat API:er för enheten för att aktivera hantering av den krypterade nyckeln och certifikatet med JSON Web Encryption (JWE).
För att säkerställa sann end-to-end-kryptering via vårt moln kan vi inte vara med om att kryptera och överföra certifikatet och nyckeln. Om du behöver den här säkerhetsnivån kan du använda onus för att:
Begär dina certifikat.
Skapa dina certifikats nyckelpar.
Skapa (och skydda) en första hemlighet för varje enhet, för att start av enhetens krypteringskapacitet.
Utveckla och underhålla ditt eget verktyg för kryptering av filer med hjälp av JWE-standarden.
Nedan förklarar vi processen och de (icke-hemliga) parametrarna som du kommer att behöva, och ett recept som följer i dina val av utvecklingsverktyg. Vi tillhandahåller även vissa testdata och resultatet JWE- som vi förväntar oss att de ska innehålla för att hjälpa dig att verifiera din process.
En referensimplementering som inte stöds med Hjälp avWag3 och JWCrypto-biblioteket är tillgänglig från Cisco på begäran.
Sammana och kryptera certifikatet och nyckeln med hjälp av ditt verktyg och enhetens ursprungliga hemlighet.
Överför den resulterande JWE till enheten.
Ange syftet med det krypterade certifikatet som ska användas för Webex-identiteten och aktivera certifikatet.
(Rekommenderas) Tillhandahåll ett gränssnitt till (eller distribuera) ditt verktyg för att göra det möjligt för enhetsanvändare att ändra den inledande hemligheten (för att skydda sina medier från dig!).
Så här använder vi JWE-formatet
I det här avsnittet beskrivs hur vi förväntar oss att JWE ska skapas som inmatning till enheterna, så att du kan skapa ditt eget verktyg för att skapa verktygen från dina certifikat och nycklar.
Du måste hänvisa till JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516 och JSON Web Signature (JWS)https://datatracker.ietf.org/doc/html/rfc7515.
Vi valde att använda den kompakta serialiseringen av ett JSON-dokument för att skapa JWE-rar. De parametrar som du behöver inkludera när du skapar JWE:en är:
JOSE Header (skyddad). I sidhuvudet för JSON-objektsignering och kryptering måste du inkludera följande nyckelvärdespar:
"alg":"dir"
Direktalgoritmen är den enda som vi har stöd för för kryptering av nyttolasten och du måste använda enhetens ursprungliga klienthemlighet.
"enc":"A128GCM"
eller"enc":"A256GCM"
Vi stöder dessa två krypteringsalgoritmer.
"cisco-action": "add"
eller"cisco-action": "populate"
eller"cisco-action": "activate"
eller"cisco-action": "deactivate"
Detta är en patentskyddad nyckel och fyra värden som det kan ta. Vi introducerade denna nyckel för att signalera syftet med krypterade data till målenheten. Värdena namnges efter xAPI-kommandona på enheten där du använder krypterade data.
Vi döpte om det
cisco-action
för att begränsa potentiella kunder med framtida JWE-tillägg."cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }
En annan patentskyddad nyckel. Vi använder de värden du anger som inmatningar för nyckelinmatning på enheten. Symbolen
version
måste vara1
(versionen av vår nyckelfunktion. Värdet påsalt
måste vara en base64 URL-kodad sekvens på minst 4 bytes, som du måste välja slumpmässigt.
JWE-krypterad nyckel. Fältet är tomt. Enheten hämtar den från initialen
ClientSecret
.JWE Initierings-vektor. Du måste tillhandahålla en base64url-kodad initialiseringsanalys för att avkryptera nyttolasten. IV MÅSTE vara ett slumpmässigt 12 byte-värde (vi använder chifferfamiljen AES-GCM, vilket kräver att IV är 12 byte långt).
JWE AAD (ytterligare autentiserade data). Du måste utelämna detta fält eftersom det inte stöds i den kompakta serialiseringen.
JWEChihertext: Detta är den krypterade nyttolasten som du vill hålla hemlig.
Nyttolasten KAN vara tom (om du exempelvis vill återställa klienthemligheten måste du skriva över den med ett tomt värde).
Det finns olika typer av nyttolaster, beroende på vad du försöker göra på enheten. Olika xAPI-kommandon förväntar sig olika nyttolaster och du måste ange syftet med nyttolasten med
cisco-action
enligt följande:Med
"cisco-action":"populate"
chiffertext är den nyaClientSecret
Med "
"cisco-action":"add"
chiffertext är en PEM som innehåller certifikatet och dess privata nyckel (infogad)Med "
"cisco-action":"activate"
chiffertexten är fingeravtrycket (hexadecimal representation av sha-1) av certifikatet som vi aktiverar för enhetsidentifieringsverifieringMed "
"cisco-action":"deactivate"
chiffertexten är fingeravtrycket (hexadecimal representation av sha-1) av certifikatet som vi avaktiverar för enhetsidentitetsverifiering
Verifieringstagg för JWE: Det här fältet innehåller verifieringstaggen för att säkerställa integriteten hos hela JWE kompakta serialiserade dator
Hur vi härrör krypteringsnyckel från ClientSecret
Efter den första delen av hemligheten godkänner eller utser vi inte hemligheten som oformaterad text. Detta för att förhindra att potentiella ordlistor används av någon som kan få åtkomst till enheten.
I enhetsprogramvaran används klienthemligheten som inmatning till en nyckelfunktion (kdf) och använder sedan den härlett nyckeln för innehållskryptering/kryptering på enheten.
Det innebär att ditt verktyg för att skapa JWE-klienter måste följa samma procedur för att erhålla samma krypterings-/dekrypteringsnyckel från klienthemligheten.
Enheterna använder skryptering för nyckelkryptering (se ) med följande https://en.wikipedia.org/wiki/Scryptparametrar:
Cost Den här (N) är 32768
BlockSize Etter (r) är 8
Parallellisering P är 1
Salt är en slumpmässig sekvens på minst 4 byte. måste du tillhandahålla samma
salt
när du angercisco-kdf
parametern.Nyckellängderna är antingen 16 bytes (om du väljer AES-GCM 128-algoritmen) eller 32 bytes (om du väljer AES-GCM 256-algoritm)
Max minnestaket är 64 MB
Den här uppsättningen parametrar är den enda konfigurationen av kryptering som är kompatibel med nyckelfunktionsfunktionen på enheterna. Denna kdf på enheterna kallas "version":"1"
, vilket är den enda versionen som för närvarande används av cisco-kdf
parametern.
Ett fungerat exempel
Här är ett exempel som du kan följa för att verifiera att din JWE-krypteringsprocess fungerar på samma sätt som den process vi skapade på enheterna.
Exempelscenariot är att lägga till en PEM-dator till enheten (efterliknar lägger till ett certifikat med en mycket kort sträng i stället för en full certifikat + nyckel). Klienthemligheten i exemplet är ossifrage
.
Välj en krypteringschiffrering. I detta exempel används
A128GCM
(AES med 128 bitars tangenter iLäge av Den här kontringsräknaren). Ditt verktyg kan användaA256GCM
om du vill.Välj en salt (måste vara en slumpmässig sekvens på minst 4 bytes). I detta exempel används (hex byte)
E5 E6 53 08 03 F8 33 F6
. Base64url kodar sekvensen för att få5eZTCAP4M_Y
(ta bort bas64-utfyllnaden).Här är ett exempel
scrypt
samtal för att skapa innehållet krypteringsnyckel (cek):cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)
Den är en är på 16 bytes (hex) enligt följande:
95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac
vilka base64url kodar tilllZ66bdEiAQV4_mqdInj_rA
.Välj en slumpmässig sekvens på 12 bytes som kan användas som en initialiserings-vektor. I det här exemplet används (hex)
34 b3 5d dd 5f 53 7b af 2d 92 95 83
vilka base64url kodar tillNLNd3V9Te68tkpWD
.Skapa JOSE-rubriken med kompakt serialisering (följ samma ordning för parametrarna vi använder här) och sedan base64url koda den:
{"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}
Base64url-kodad JOSE-rubrik är
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9
Detta är det första elementet i JWE jwe.
Det andra elementet i JWE är tomt eftersom vi inte tillhandahåller någon JWE-krypteringsnyckel.
Det tredje elementet i JWE är initialiserings-vektorn
NLNd3V9Te68tkpWD
.- Använd ditt JWE-krypteringsverktyg för att generera en krypterad nyttolast och tagg. I det här exemplet blir den okrypterade nyttolasten den falska PEM-inläsningen
this is a PEM file
De krypteringsparametrar du ska använda är:
Nyttolast är
this is a PEM file
Krypteringskryptering är AES 128 GCM
Base64url kodade JOSE-rubriken som Ytterligare autentiserade data (AAD)
Base64url krypterar den krypterade nyttolasten, vilket bör leda till
f5lLVuWNfKfmzYCo1YJfODhQ
Detta är det fjärde elementet (JWE Ciphertext) i JWEämnet.
Base64url kodar taggen som du skapade i steg 8, vilket bör resultera i
PE-wDFWGXFFBeo928cfZ1Q
Det här är det femte elementet i JWE jwe.
De fem elementen i JWE har tillsammans med punkter (JOSEheader.) IV.Ciphertext.Tag) för att få:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
Om du härlett samma base64url-kodade värden som vi visar här och använder dina egna verktyg är du redo att använda dem för att skydda E2E-krypteringen och din enhets verifierade identitet.
Det här exemplet fungerar inte, men i det här exemplet är nästa steg att använda det JWE du skapade ovan som inmatning till xcommand på enheten som lägger till certifikatet:
xCommand Security Certificates Add
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
Det finns nya sessionstyper för möten utan förtroende, som kommer att finnas tillgängliga för alla möteswebbplatser utan extra kostnad. En av de nya sessionstyperna kallas Pro-End to End Encryption_VOIPonly
. Det här är namnet på den allmänna tjänsten som vi kan ändra i framtiden. För aktuella namn på sessionstyperna, se Sessionstyps-ID i avsnittet Referens i den här artikeln.
Du behöver inte göra något för att få den nya funktionen på din webbplats, men du måste bevilja användare den nya sessionstyp (även kallat Mötesprivilegier). Du kan göra detta enskilt via användarens konfigurationssida eller i bulk med en CSV-export/-import.
1 | Logga in på Control Hub och öppna mötessidan. |
||
2 | Klicka på namnet på din webbplats för att öppna webbplatsens konfigurationspanel. |
||
3 | Klicka på Konfigurera webbplats. |
||
4 | I området Allmänna inställningar klickar du påSessionstyper. På den sidan bör du se en eller flera sessionstyper med slutpunkt-till-slutpunkt-kryptering. Se listan över sessionstyps-ID i referensavsnittet i den här artikeln. Du kan till exempel se Pro-end för att avsluta Encryption_VOIPonly.
|
||
5 | Om du inte har den nya sessionstyp du kontakta din Webex-representant. |
Nästa steg
Aktivera detta sessionstyp privilegier/mötesprivilegier för vissa eller alla dina användare.
1 | Klicka på Användare och välj en användare för att öppna användarens konfigurationspanel. |
2 | I området Tjänster klickar du på Cisco Webex Meetings. |
3 | Välj -webbplatsen (om användaren är i flera) och klicka på Värd. |
4 | Markera rutan bredvid posten Webex Meetings Pro-end to End Encryption_VOIPonly. |
5 | Stäng användarens konfigurationspanel. |
6 | Upprepa för andra användare om det behövs. Om du vill tilldela detta till många användare, använd CSV-massalternativet. |
1 | Logga in på Control Hub https://admin.webex.com på och öppna mötessidan. |
||
2 | Klicka på ditt webbplatsnamn för att öppna webbplatsens konfigurationspanel. |
||
3 | I avsnittet Licenser och användare klickar du på Hantera flerasamtidigt. |
||
4 | Klicka på Exportera och vänta medan viförbereder filen. |
||
5 | När filen är klar klickar du på Exportera resultat och sedan Hämta. (Du måste stänga popup-fönstret manuellt efter att du har klickat Hämta.) |
||
6 | Öppna den hämtade CSV-filen för redigering. Det finns en rad för varje användare och |
||
7 | Lägg till för varje användare som du vill bevilja det nya sessionstyp, Den Cisco Webex csv-filformat referensen innehåller information om syftet och innehållet i CSV-filen. |
||
8 | Öppna konfigurationspanelen för möteswebbplatsen i Control Hub.
|
||
9 | I avsnittet Licenser och användare klickar du på Masshantera. |
||
10 | Klicka på Importera och välj den redigerade CSV-filen och klicka sedan på Importera. Vänta medan filen överförs. |
||
11 | När importen är klar kan du klicka på Importresultat för att granska om det har uppstått några fel. |
||
12 | Gå till sidan Användare och öppna en av användarna för att bekräfta att de har den nya sessionstyp. |
Om dina enheter redan är anslutna till din Control Hub-organisation och du vill använda Webex CA för att automatiskt generera deras identifierande certifikat, behöver du inte fabriksåterställning för enheterna.
Den här proceduren väljer vilken domän enheten använder för att identifiera sig själv, och den behövs bara om du har flera domäner i din Control Hub-organisation. Om du har fler än en domän rekommenderar vi att du gör detta för alla dina enheter som har en "Cisco-verifierad" identitet. Om du inte berättar för Webex vilken domän som identifierar enheten väljer vi en och den kan se fel ut för andra mötesdeltagare.
Innan du börjar
Om dina enheter inte har registrerats ännu kan du följa Registrera en enhet för att Cisco Webex med API, lokalt webbgränssnitt eller cloud-registrering förenheter. Du bör också verifiera de domäner som du vill använda för att identifiera enheterna i Hantera dinaenheter.
1 | Logga in på Control Hubhttps://admin.webex.com() och öppna sidan Devices (Enheter). |
2 | Välj en enhet för att öppna konfigurationspanelen. |
3 | Välj den domän som du vill använda för att identifiera denna enhet. |
4 | Upprepa för andra enheter. |
Innan du börjar
Du behöver:
För att få ett CA-signerat certifikat och privat nyckel, i PEM-format, för varje enhet.
Läs ämnet Förstå den externa identitetsprocessen för enheter iavsnittet Förbered i den här artikeln.
För att förbereda ett JWE-krypteringsverktyg med avseende på informationen där.
Ett verktyg för att generera slumpmässiga bytesekvenser av givna längder.
Ett verktyg för att base64url kryptera byte eller text.
En
scrypt
Genomförandet.Ett hemlighet ord eller fras för varje enhet.
1 | Fyll i enhetens Första gången du fyller i Enheten har sin ursprungliga hemlighet. Glöm inte detta, du kan inte återställa den och måste fabriksåterställning enheten för att starta igen.
|
2 | Sätt ihop ditt certifikat och din privata nyckel: |
3 | Skapa en JWEvälde som ska användas som ingång för kommandot Lägg till certifikat: |
4 | Öppna TShell på enheten och kör (multiline) lägg till kommando:
|
5 | Kontrollera att certifikatet har lagts till genom att köra Kopiera det nya certifikatets fingeravtryck. |
6 | Aktivera certifikatet för detta ändamål Enheten har ett krypterat, aktivt CA-utfärdat certifikat som är redo att användas för att identifiera det i Webex-möten med end-to-end-kryptering.
|
7 | Registrera enheten i din Control Hub-organisation. |
1 | Schemalägg ett möte av rätt typ(Webex Meetings Pro-end till slutet Encryption_VOIPonly). |
2 | Delta i mötet som värd från en Webex Meetings klient. |
3 | Delta i mötet från en enhet som har sin identitet verifierad av Webex CA. |
4 | Som värd bekräftar du att den här enheten visas i lobbyn med korrekt identitetsikon. |
5 | Delta i mötet från en enhet som har sin identitet verifierad av en extern CA. |
6 | Som värd bekräftar du att den här enheten visas i lobbyn med korrekt identitetsikon. Läs mer om identitetsikoner. |
7 | Delta i mötet som en oauticerad mötesdeltagare. |
8 | Som värd bekräftar du att mötesdeltagaren visas i lobbyn med korrekt identitetsikon. |
9 | Som värd släpper du in eller nekar personer/enheter. |
10 | Validera deltagar-/enhetsidentiteter när så är möjligt genom att kontrollera certifikaten. |
11 | Kontrollera att alla i mötet ser samma säkerhetskod för mötet. |
12 | Delta i mötet med en ny mötesdeltagare. |
13 | Kontrollera att alla ser samma, nya säkerhetskod för mötet. |
Ska du göra end-to-end-krypterade möten till standardmötesalternativ, eller bara aktivera det för vissa användare eller tillåta alla värdar att bestämma? När du har bestämt dig för hur du ska använda den här funktionen måste du förbereda de användare som kommer att använda den, särskilt med avseende på begränsningarna och vad du kan förvänta dig under mötet.
Behöver du se till att varken Cisco eller någon annan kan avkryptera ditt innehåll eller efterlikna dina enheter? I så fall behöver du certifikat från en offentlig CA. Du får endast ha upp till 25 enheter i ett säkert möte. Om du behöver den här säkerhetsnivån ska du inte tillåta mötesklienter att delta.
Låt enheter ansluta först och ställ in användarnas förväntningar på att de inte kommer att kunna delta om de ansluter för sent, om de ansluter sig för sent för att delta.
Om du har olika nivåer av identitetsverifiering kan användare verifiera varandra med certifikat-säkerhetskopierad identitet och mötets säkerhetskod. Även om det finns fall där mötesdeltagare kan visas som overifierade, och mötesdeltagare bör veta hur de ska kontrollera, kan overifierade personer inte vara snabbmeddelandedeltagare.
Om du använder en extern CA för att utfärda dina enhetscertifikat kan dina onus övervaka, uppdatera och tillämpa om certifikaten.
Om du skapade den ursprungliga hemligheten ska du förstå att dina användare kanske vill ändra hemligheten i deras enhet. Du kan behöva skapa ett gränssnitt/distribuera ett verktyg för att göra det möjligt för dem.
Kommer snart.
ID för mötestyp |
Namn på offentlig tjänst |
---|---|
638 |
Endast E2E Encryption+VoIP |
652 |
Pro-end till slutet Encryption_VOIPonly |
660 |
Pro 3 kostnadsfri till slut Encryption_VOIPonly E2E-kryptering + identitet |
672 |
Pro 3 Free50-end till slutet Encryption_VOIPonly |
673 |
Utbildningsinstruktör E2E Encryption_VOIPonly |
676 |
Broadworks Standard plus slutpunkt-till-slutpunkt-kryptering |
677 |
Broadworks Premium plus slutpunkt-till-slutpunkt-kryptering |
681 |
Gratis kodning plus end-to-end-kryptering |
Dessa tabeller beskriver Webex-enheternas API-kommandon som vi har lagt till för möten med end-to-end-kryptering och verifierad identitet. Mer information om hur du använder API:et finns i Åtkomst till API:et för Webex Room- och skrivbordsenheter och Webex Boards.
Dessa xAPI-kommandon är endast tillgängliga på enheter som är antingen:
Registrerad på Webex
Registrerade lokalt och länkade till Webex med Webex Edge för enheter
API-samtal |
Beskrivning |
---|---|
|
Den här konfigurationen görs när administratören ställer in enhetens önskade domän från Control Hub. Endast nödvändigt om organisationen har fler än en domän. Enheten använder denna domän när den begär ett certifikat från Webex CA. Domänen identifierar sedan enheten. Den här konfigurationen är inte tillämplig när enheten har ett aktivt externt utfärdat certifikat för att identifiera sig själv. |
|
Anger om enheten kan delta i ett end-to-end-krypterat möte. Moln-API:et ringer upp det så att ett parkopplat program vet om det går att använda enheten för att delta. |
|
Anger om enheten använder |
|
Enhetens identitet såsom läst från det externt utfärdade certifikatets vanliga namn. |
|
Läser in specifik information från ett externt ut utfärdat certifikat. I kommandot som visas ersätter
|
|
Status på enhetens externa identitet (t.ex. |
|
Anger om enheten har ett giltigt certifikat utfärdat av Webex CA. |
|
Enhetens identitet såsom läst från Webex-utfärdat certifikats vanliga namn. Innehåller ett domännamn om organisationen har en domän. Är tom om organisationen inte har en domän. Om enheten finns i en organisation med flera domäner är detta värdet från |
|
Läser in specifik information från Webex-utfärdade certifikat. I kommandot som visas ersätter
|
API-samtal |
Beskrivning |
---|---|
|
Dessa tre händelser omfattar nu |
API-samtal |
Beskrivning |
---|---|
eller
|
Accepterar ett base64url-kodat oformaterad textvärde för start av klienthemlighet på enheten för första gången. För att uppdatera hemligheten efter den första gången måste du tillhandahålla en JWE som innehåller den nya hemliga krypterade av den gamla hemligheten. |
|
Lägger till ett certifikat (med privat nyckel). Vi förlängt detta kommando så att det godkänner en JWE som innehåller de krypterade PEM-datan. |
|
Aktiverar ett specifikt certifikat för WebexIdentity. För detta |
|
Inaktiverar ett specifikt certifikat för WebexIdentity. För detta |