Användarupplevelse

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:

Verifierar identitet med intern eller extern CA

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ändarens användare kan Webex Meetings-app 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. Det vanliga namnet (COMMON Name, CN) och alternativt ämnesnamn (SAN) kommer att visas i användargränssnittet för Webex-möten enligt beskrivningen 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 "example.com"-domänen.

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.

Funktioner och begränsningar

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.7 Webex Meetings skrivbordsklienten delta i möten med end-to-end-kryptering.

  • Webex-appen kan inte 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 medan de webbplatsadministration identiteten styrs 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.

Ytterligare resurser

Relaterad information

Avivinga exempel JWE jwe

Exempel på korrekt krypterad JWE baserat på angivna parametrar (bilaga)

Förutsättningar

  • 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 användare.

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

Hämta enhetscertifikat

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.

Förbered för att registrera enheter

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 till dig och att du inte har någon säkerhet att ta del av.

Förstå extern identitetsprocess för enheter

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) parametrar som du kommer att behöva, och ett recept för att följa 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 av Eng. 3 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 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 vara 1(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 (för att till exempel å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 nya ClientSecret

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

    • Med " "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 anger cisco-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.

  1. Välj en krypteringschiffrering. I detta exempel används A128GCM(AES med 128 bitars nycklar i felsäkert räknareläge). Ditt verktyg kan använda A256GCM om du vill.

  2. 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).

  3. 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 till lZ66bdEiAQV4_mqdInj_rA.

  4. 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 till NLNd3V9Te68tkpWD.

  5. 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 y.

  6. Det andra elementet i JWE är tomt eftersom vi inte tillhandahåller någon JWE-krypteringsnyckel.

  7. Det tredje elementet i JWE är initialiserings-vektorn NLNd3V9Te68tkpWD.

  8. Använd ditt JWE-krypteringsverktyg för att generera en krypterad nyttolast och tagg. I det här exemplet kommer den okrypterade nyttolasten att vara 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.

  9. 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 ögonblicksbilden.

  10. De fem elementen i JWE har tillsammans med punkter (JOSEheader.) IV.Ciphertext.Tag) för att få:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

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

  12. Det här exemplet fungerar inte, men i det här exemplet är nästa steg det första steget 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 vi rullar ut till 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 tur och retur.

Verifiera ny sessionstyp

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 till end-Encryption_VOIPonly.

 

Det finns en äldre sessionstyp med ett mycket liknande namn: Pro-end-till-slutpunkt-kryptering. Denna sessionstyp inkluderar icke-krypterad PSTN åtkomst till möten. Kontrollera att du har den _VOIPonly för att säkerställa end-to-end-kryptering. Du kan markera genom att hålla muspekaren över PRO-länken i kolumnen för sessionskoder. För det här exemplet bör länkens mål vara javascript:ShowFeature(652).

Vi kan ändra namnen på de allmänna tjänsterna för dessa sessionstyper i framtiden, till exempel om vi planerar att ändra Pro-End till Slutpunkt Encryption_VOIPonly till E2E Encryption + Identity.
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.

Aktivera E2EE-möten för enskilda 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 till 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.

Aktivera E2EE-möten för flera användare

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 MeetingPrivilege innehåller deras sessionstyp-NAMN som en kommaavgränsad lista.

7

Lägg till för varje användare som du vill bevilja det nya sessionstyp, 1561 som ett nytt värde i den kommaavgränsade listan i listan MeetingPrivilege Cell.

Referensen för CSV-filformat https://help.webex.com/en-us/5vox83 har vissa detaljer om syftet och innehållet i CSV-filen.
8

Öppna konfigurationspanelen för möteswebbplatsen i Control Hub.

Om du redan var på listsidan för möteswebbplatsen kanske du måste uppdatera den.
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 vi laddar upp filen.
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.

Onboard-enheter (intern CA)

Om dina enheter redan är anslutna till din Control Hub-organisation och du vill använda Webex CA för att automatiskt generera sina 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 någon registrering ännu kan du följa https://help.webex.com/n25jyr8 eller https://help.webex.com/nutc0dy. Du bör också verifiera de domäner som du vill använda för att identifiera enheterna (https://help.webex.com/cd6d84).

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.

Onboard-enheter (extern CA)

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 del av 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 ClientSecret med en oformaterad texthemlighet:

Första gången du fyller i Secret, skriver du in den i oformaterad text. Därför rekommenderar vi att du gör detta på den fysiska enhetskonsolen.

  1. Base64url kodar den hemliga frasen för den här enheten.

  2. Öppna TShell på enheten.

  3. Kör xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    Exempelkommandot ovan fyller i Secret med frasen 0123456789abcdef. Du måste välja själv.

Enheten har sin ursprungliga hemlighet. Glöm inte bort det här, du kan inte återställa den och måste fabriksåterställning av enheten för att starta igen.
2

Sätt ihop ditt certifikat och din privata nyckel:

  1. Med hjälp av en textredigerare öppnar du .pem-filerna, klistrar in nyckeln och certifikatet och sparar det som en ny .pem-fil.

    (Det här är nyttolasttexten som du kommer att kryptera och lägga in i din JWE and anda)
3

Skapa en JWEvälde som ska användas som ingång för kommandot Lägg till certifikat:

  1. Skapa en slumpmässig sekvens på minst 4 bytes. Det här är ditt salta.

  2. Härrör ett innehåll från krypteringsnyckel med ditt krypteringsverktyg.

    För detta behöver du hemligheten, älsningen och en nyckellängd som matchar din valda krypteringskryptering. Det finns några andra fasta värden att tillhandahålla (N=32768, r=8, p=1). Enheten använder samma process och värden för att härröra samma innehåll krypteringsnyckel.

  3. Skapa en slumpmässig sekvens på exakt 12 bytes. Det här är din initialiserings-vektor.

  4. Skapa en JOSE-rubrik, ställa in alg, enc och cisco-kdf enligt beskrivningen under Förstå den externa identitetsprocessen för enheter. Ställ in åtgärden "lägg till" med hjälp av nyckel:värde "cisco-action":"add" i din JOSE-rubrik (eftersom vi lägger till certifikatet till enheten).

  5. Base64url kodar JOSE-rubriken.

  6. Använd ditt JWE-krypteringsverktyg med det valda chiffert och det base64url-kodade JOSE-sidhuvudet för att kryptera texten från den sammanfällda pem-filen.

  7. Base64url kodar initierings-vektorn, den krypterade PEM-nyttolasten och verifieringstaggen.

  8. Skapa JWE: s? här (alla värden är base64url kodade):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag
4

Öppna TShell på enheten och kör (multiline) lägg till kommando:

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

Kontrollera att certifikatet har lagts till genom att köra xcommand Security Certificates Services Show

Kopiera det nya certifikatets fingeravtryck.
6

Aktivera certifikatet för detta ändamål WebexIdentity:

  1. Läs certifikatets fingeravtryck, antingen från själva certifikatet eller från utdata från xcommand Security Certificates Services Show.

  2. Skapa en slumpmässig sekvens på minst 4 bytes och base64url koda den sekvensen. Det här är ditt salta.

  3. Härrör ett innehåll från krypteringsnyckel med ditt krypteringsverktyg.

    För detta behöver du hemligheten, älsningen och en nyckellängd som matchar din valda krypteringskryptering. Det finns några andra fasta värden att tillhandahålla (N=32768, r=8, p=1). Enheten använder samma process och värden för att härröra samma innehåll krypteringsnyckel.

  4. Skapa en slumpmässig sekvens på exakt 12 bytes och base64url koda den sekvensen. Det här är din initialiserings-vektor.

  5. Skapa en JOSE-rubrik, ställa in alg, enc och cisco-kdf enligt beskrivningen under Förstå den externa identitetsprocessen för enheter. Ställ in åtgärden "aktivera" med hjälp av nyckel:värde "cisco-action":"activate" i din JOSE-rubrik (eftersom vi aktiverar certifikatet på enheten).

  6. Base64url kodar JOSE-rubriken.

  7. Använd ditt JWE-krypteringsverktyg med det valda chiffert och det base64url-kodade JOSE-sidhuvudet för att kryptera certifikatets fingeravtryck.

    Verktyget bör mata ut en sekvens på 16 eller 32 byte beroende på om du väljer 128 eller 256 bitars AES-GCM och en verifieringstagg.

  8. Base64urlencode det krypterade fingeravtrycket och verifieringstaggen.

  9. Skapa JWE: s? här (alla värden är base64url kodade):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Öppna TShell på enheten och kör följande aktiveringskommando:

    xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
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.

Testa E2EE-kryptering och verifierad identitet

1

Schemalägg ett möte av rätt typ(Webex Meetings Pro-end till end Encryption_VOIPonly).

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

Delta i mötet som värd från en Webex Meetings klient.

Se https://help.webex.com/rzam8
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.

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

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

Ange omfattning och förväntningar

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 denna säkerhetsnivå ska du inte tillåta att mötesklienter deltar.

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.

Identitetshantering

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 till deras enhet. Du kan behöva skapa ett gränssnitt/distribuera ett verktyg för att göra det möjligt för dem.

Möten utan förtroende Vanliga frågor

Sessionstyps-ID:er

Tabell 1. Sessionstyps-ID för möten med end-to-end-kryptering

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 kostnadsfria till slut-Encryption_VOIPonly

E2E-kryptering + identitet

672

Pro 3 kostnadsfria 50-end-Encryption_VOIPonly

673

Education Instructor E2E Encryption_VOIPonly

676

Broadworks Standard plus slutpunkt-till-slutpunktskryptering

677

Broadworks Premium plus slutpunkt-till-slutpunkt-kryptering

681

Gratis kodning plus slutpunkt-till-slutpunktskryptering

Relaterade xAPI-kommandon

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 https://help.webex.com/nzwo1ok.

Tabell 2. API:er på systemnivå för end-to-end-krypterade möten och verifierad identitet

API-samtal

Beskrivning

xConfiguration Conference EndToEndEncryption Mode: On

Stänger av slutpunkt-till-slutpunktskrypteringsläge On eller Off.

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

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.

xStatus Conference EndToEndEncryption Availability

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.

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Anger om enheten har ett giltigt externt utfärdat certifikat.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Enhetens identitet såsom läst från det externt utfärdade certifikatets vanliga namn.

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Läser in certifikatinformationen från det externt utfärdade certifikatet och utdatan som en JSON ögonblicksbild.

xStatus Conference EndToEndEncryption InternalIdentity Valid

Anger om enheten har ett giltigt certifikat utfärdat av Webex CA.

xStatus Conference EndToEndEncryption InternalIdentity Identity

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

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Läser in certifikatinformationen från Webex-utfärdade certifikat och utdatan som en JSON ögonblicksbild.
Tabell 3. I samtals-API:er för end-to-end-krypterade möten och verifierade identiteter

API-samtal

Beskrivning

xStatus Call # ServerEncryption Type

Läser in krypteringskryptering som används i HTTPS-anslutningen till Webex. Detta visas för användaren.

xStatus Conference Call # EndToEndEncryption Status

Läser in status för end-to-end-kryptering för samtal. Visas för användaren som närvaro (eller frånvaro) av låsikonen.

xStatus Conference Call # EndToEndEncryption SecurityCode

Läser in mötets säkerhetskod. Detta visas för användaren och det ändras när mötesdeltagare deltar.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Läser in krypteringskryptering som används i medieanslutningen. Detta visas för användaren.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Läser krypteringskryptering som används för Messaging Layer Security (MLS).

xStatus Conference Call # EndToEndEncryption Roster Participant

Listar de mötesdeltagare som bidrar till MLS-grupptillståndet i detta möte. Listan upptäcktes av MLS, inte Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

WDM-URL:en för en angiven mötesdeltagare.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

Den angivna mötesdeltagarens verifieringsstatus.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

Den angivna mötesdeltagarens primära identitet, vanligtvis en domän (enhet) eller en e-postadress (användare).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

Den angivna deltagarens visningsnamn. Signerad av mötesdeltagaren/enheten.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

Certifikatinformationen från den angivna mötesdeltagarens certifikat som JSON.

xCommand Conference ParticipantList Search

Vi har utökat detta kommando så att det inkluderar information om slutpunkt-till-slutpunkt-kryptering för mötesdeltagare.

xCommand Conference ParticipantList Search

Sökningen i deltagarlistan inkluderar nu EndToEndEncryptionStatus, deltagarens identitetsverifieringsstatus. Det här värdet visas i användargränssnittet.

xCommand Conference ParticipantList Search

Sökningen i deltagarlistan inkluderar nu EndToEndEncryptionIdentity, deltagarens primära identitet. Detta är vanligtvis en domän eller en e-postadress. Det här värdet visas i användargränssnittet.

xCommand Conference ParticipantList Search

Sökningen i deltagarlistan inkluderar nu EndToEndEncryptionCertInfo, det JSON som innehåller mötesdeltagarens certifikat. Det här värdet visas i användargränssnittet.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

Dessa tre händelser omfattar nu EndToEndEncryptionStatus, EndToEndEncryptionIdentity och EndToEndEncryptionCertInfo för den berörda mötesdeltagaren.

Tabell 4. ClientSecret-relaterade API:er för möten med end-to-end-kryptering och verifierad identitet

API-samtal

Beskrivning

xCommand Security ClientSecret Populate Secret: "base64url-encoded" eller xCommand Security ClientSecret Populate Secret: JWEblob

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.

xCommand Security Certificates Services Add JWEblob

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.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Aktiverar ett specifikt certifikat för WebexIdentity. För detta Purpose, kommandot kräver att det identifierande fingeravtrycket är krypterat och serialiserat i en JWEgrep.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Inaktiverar ett specifikt certifikat för WebexIdentity. För detta Purpose, kommandot kräver att det identifierande fingeravtrycket är krypterat och serialiserat i en JWEgrep.