Användarupplevelse

Användare väljer mötestypen när de schemalägger ett möte. När värden släpper in mötesdeltagare från lobbyn och under mötet kan de se identitetsverifieringsstatusen för varje mötesdeltagare. Det finns också en möteskod som är gemensam för alla aktuella mötesdeltagare i mötet, som de kan använda för att kontrollera att deras möte inte har avlyssnats av en oönskad Meddler In The Middle (MITM)-attack.

Dela följande information med dina mötesvärdar:

Identitetsverifiering med intern eller extern CA

Verifiera identitet

Slutpunkt-till-slutpunkt-kryptering med identitetsverifiering ger ytterligare säkerhet för ett slutpunkt-till-slutpunkt-krypterat möte.

När mötesdeltagare eller enheter ansluter till en delad MLS-grupp (Messaging Layer Security) visar de sina certifikat till de andra gruppmedlemmarna, som sedan validerar certifikaten mot de utfärdande certifikatmyndigheterna (CA). Genom att bekräfta att certifikaten är giltiga verifierar CA mötesdeltagarnas identitet och mötet visar mötesdeltagarna/enheterna som verifierade.

Webex-appanvändare autentiserar sig själva mot Webex identitetsbutik, vilket ger dem en åtkomsttoken när autentiseringen lyckas. Om de behöver ett certifikat för att verifiera sin identitet i ett slutpunkt-till-slutpunkt-krypterat möte utfärdar Webex CA dem ett certifikat baserat på åtkomsttoken. För närvarande tillhandahåller vi inte ett sätt för Webex Meetings-användare att få ett certifikat utfärdat av en 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:

  • Intern CA – Webex utfärdar ett internt certifikat baserat på åtkomsttoken för enhetens maskinkonto. Certifikatet signeras av Webex CA. Enheter har inte användar-ID:er på samma sätt som användare gör, så Webex använder (en av) din organisations domäner när du skriver enhetscertifikatets identitet (Common Name (CN)).

  • Extern CA – Begär och köp 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 involverad, vilket gör det möjligt att garantera verklig slutpunkt-till-slutpunkt-kryptering och verifierad identitet och förhindra den teoretiska möjligheten att Cisco kan kringgå ditt möte/avkryptera dina medier.

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 också använda API xKonfigurationskonferens End-toEndEncryption 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. Gemensamt namn (CN) och alternativt ämnesnamn (SAN) 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 du har ett unikt CN per enhet. Till exempel ”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 du 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 att hantera detta.

Funktioner och begränsningar

Enheter

Följande molnregistrerade enheter i Webex Room- och Webex Desk-serien kan delta i E2EE-möten:

  • Webex Board

  • Webex Desk Pro

  • Webex-skrivbord

  • Webex Room-paket

  • Webex Room Kit Mini

Följande enheter kan inte delta i E2EE-möten:

  • Webex C-serien

  • Webex DX-serien

  • Webex EX-serien

  • Webex MX-serien

  • SIP-enheter från tredje part

Programvaruklienter

  • Webex-appen för stationära och mobila klienter kan delta i E2EE-möten.

  • Webex-webbklienten kan inte delta i E2EE-möten.

  • SIP-klienter från tredje part kan inte delta i E2EE-möten.

Identitet

  • Vi tillhandahåller inte Control Hub-alternativ som du kan hantera externt verifierad enhetsidentitet. För verklig slutpunkt-till-slutpunkt-kryptering bör endast du känna till/komma åt hemligheter och nycklar. Om vi har introducerat en molntjänst för att hantera nycklarna finns det en risk att de fångas upp.

  • För närvarande tillhandahåller vi ett ”recept” för att du ska designa dina egna verktyg, baserat på branschstandard krypteringstekniker, för att hjälpa dig att begära eller kryptera dina enhets identitetscertifikat och deras privata nycklar. Vi vill inte ha någon verklig eller upplevd åtkomst till din dator eller dina nycklar.

Meetings

  • E2EE-möten har för närvarande stöd för högst 1 000 deltagare.

  • Du kan dela nya whiteboardtavlor i E2EE-möten. Det finns vissa skillnader från whiteboardtavlor i regelbundna möten:
    • I E2EE-möten kan användare inte komma åt whiteboardtavlor som skapats utanför mötet, inklusive privata whiteboardtavlor, whiteboardtavlor som delas av andra och whiteboardtavlor från Webex-utrymmen.
    • Whiteboardtavlor som har skapats i E2EE-möten är endast tillgängliga under mötet. De sparas inte och är inte tillgängliga efter att mötet har avslutats.
    • Om någon delar innehåll i ett E2EE-möte kan du kommentera det. Mer information om kommentarer finns i Webex-appen | Markera delat innehåll med kommentarer.

Hanteringsgränssnitt

Vi rekommenderar starkt att du använder Control Hub för att hantera din Meetings-webbplats, eftersom Control Hub-organisationer har centraliserad identitet för hela organisationen.

Ytterligare resurser
Förutsättningar

  • Webex Meetings 41.7.

  • Molnregistrerade enheter i Webex Room- och Webex Desk-serien som körs 10.6.1-Room_August_2021.

  • Administrativ åtkomst till möteswebbplatsen i Control Hub.

  • 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 möten och händelser på din Webex-webbplats.

Hämta enhetscertifikat

Du kan hoppa över det här steget om du inte behöver externa verifierade identiteter.

För högsta säkerhetsnivå och för identitetskontroll bör varje enhet ha ett unikt certifikat utfärdat av en betrodd offentlig certifikatutfärdare (CA).

Du måste interagera med CA för att begära, köpa och ta emot digitala certifikat och skapa associerade privata nycklar. Använd följande parametrar när du begär certifikatet:

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

  • 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 dig på att registrera enheter

Du kan hoppa över det här steget om du inte vill använda extern verifierad identitet med dina enheter.

Om du använder nya enheter ska du inte registrera dem i Webex än. För att vara säker ska du inte ansluta dem till nätverket just nu.

Om du har befintliga enheter som du vill uppgradera till att använda extern verifierad identitet måste du fabriksåterställa enheterna.

  • Spara den befintliga konfigurationen 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.

När du har slutfört dessa steg tillåter videosystem att delta i möten och händelser på din Webex-webbplats.

Förstå den externa identitetsprocessen 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 denna säkerhetsnivå måste du:

  1. Begär dina certifikat.

  2. Skapa dina certifikats nyckelpar.

  3. Skapa (och skydda) en första hemlighet för varje enhet, för att start av enhetens krypteringskapacitet.

  4. Utveckla och underhålla ditt eget verktyg för kryptering av filer med hjälp av JWE-standarden.

    Processen och de (icke-hemliga) parametrar som du behöver förklaras nedan, samt ett recept att följa i dina valfria 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.

  5. Sammana och kryptera certifikatet och nyckeln med hjälp av ditt verktyg och enhetens ursprungliga hemlighet.

  6. Överför den resulterande JWE till enheten.

  7. Ange syftet med det krypterade certifikatet som ska användas för Webex-identiteten och aktivera certifikatet.

  8. (Rekommenderas) Tillhandahålla ett gränssnitt för (eller distribuera) ditt verktyg så att enhetsanvändare kan ändra den ursprungliga hemligheten och 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.

Se JSON webbkryptering (JWE) https://datatracker.ietf.org/doc/html/rfc7516 och JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Vi använder Compact Serialization av ett JSON-dokument för att skapa JWE-blobs. De parametrar som du behöver inkludera när du skapar JWE-blobs är:

  • JOSE-rubrik (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-åtgärd": "lägg till" eller "cisco-åtgärd": "populate" eller "cisco-åtgärd": "aktivera" eller "cisco-åtgärd": "inaktivera"

      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 kallade den för Cisco-åtgärd för att mildra potentiella sammanstötningar med framtida JWE-tillägg.

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

      En annan patentskyddad nyckel. Vi använder de värden du anger som inmatningar för nyckelinmatning på enheten. Versionen måste vara 1 (versionen av vår nyckelavledningsfunktion). Värdet på salt måste vara en bas64 URL-kodad sekvens på minst 4 byte, som du måste välja slumpmässigt.

  • JWE-krypterad nyckel. Fältet är tomt. Enheten härrör från den ursprungliga klienthemligheten.

  • JWE-initieringsvektor. 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.

  • JWE Ciphertext: Detta är den krypterade nyttolasten som du vill hålla hemlig.

    Nyttobelastningen KAN vara tom. Om du till exempel 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 nyttolast, och du måste ange syftet med nyttobelastningen med Cisco-åtgärdsnyckeln enligt följande:

    • Med "cisco-åtgärd":"fylla i" krypteringstexten är den nya klienthemligheten.

    • Med ""cisco-åtgärd":"lägg till" krypteringstexten är en PEM-blob som bär certifikatet och dess privata nyckel (sammankopplad).

    • Med ""cisco-åtgärd":"aktivera" är krypteringstexten fingeravtrycket (hexadecimal representation av sha-1) för det certifikat som vi aktiverar för verifiering av enhetens identitet.

    • Med ""cisco-åtgärd":"inaktivera" är krypteringstexten fingeravtrycket (hexadecimal representation av sha-1) för det certifikat som vi inaktiverar från att användas för verifiering av enhetens identitet.

  • 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

Så här hämtar vi krypteringsnyckeln från klienthemligheten

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. Du måste 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. Den här kdf på enheterna kallas "version":"1", vilket är den enda version som för närvarande tas 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. Det här exemplet använder A128GCM (AES med 128-bitarsnycklar i Galois Counter Mode). Ditt verktyg kan använda A256GCM om du föredrar det.

  2. Välj en salt (måste vara en slumpmässig sekvens på minst 4 bytes). Detta exempel använder (hex byte)E5 E6 53 08 03 F8 33 F6. Base64url kodar sekvensen för att få 5eZTCAP4M_Y (ta bort bas64-paddningen).

  3. Här är ett urval scrypt samtal för att skapa innehållskrypteringsnyckeln (cek):

    cek=scrypt(lösenord="ossifrage", salt=4-byte-sekvens, 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 vilken bas64url kodar till lZ66bdEi_mqdAQV4nj_rI.

  4. Välj en slumpmässig sekvens på 12 bytes som kan användas som en initialiserings-vektor. Detta exempel använder (hex) 34 b3 5d dd 5f 53 7b av 2d 92 95 83 som bas64url kodar till NLNd3V9Te68tkp.

  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":"lägg till","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

    Den bas64url-kodade JOSE-rubriken är eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJ jaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Detta är det första elementet i JWE jwe.

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

  7. Det tredje elementet i JWE blob är initieringsvektorn NLNd3V9Te68tkp.

  8. Använd ditt JWE-krypteringsverktyg för att generera en krypterad nyttolast och tagg. För det här exemplet kommer den okrypterade nyttobelastningen att vara den falska PEM-blob detta är en PEM-fil

    De krypteringsparametrar du ska använda är:

    • Nyttolast är detta är en PEM-fil

    • Krypteringskryptering är AES 128 GCM

    • Base64url kodade JOSE-rubriken som Ytterligare autentiserade data (AAD)

    Base64url kodar den krypterade nyttobelastningen, vilket bör resultera i f5lLVuWNfKfmzYCo1YJf

    Detta är det fjärde elementet (JWE Ciphertext) i JWEämnet.

  9. Bas64url kodar taggen du producerade i steg 8, vilket bör resultera i PE-wDFWGXFFBeo928cf

    Det här är det femte elementet i JWE jwe.

  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 att använda det JWE du skapade ovan som inmatning till xcommand på enheten som lägger till certifikatet:

    x Command Security Certifikat Lägg till eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQ iLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Sessionstyper för nollbetrodda möten är tillgängliga för alla möteswebbplatser utan extra kostnad. En av dessa sessionstyper kallas endast Pro-End to End Encryption_VOIP. Detta är namnet på allmännyttiga tjänster, som vi kan ändra i framtiden. För aktuella namn på sessionstyperna, se Sessionstyps-ID i avsnittet Referens i den här artikeln.

Det finns inget du behöver göra för att få den här funktionen för din webbplats. Du måste bevilja den nya sessionstypen (även kallad Mötesprivilegier) till användare. Du kan göra detta enskilt via användarens konfigurationssida eller i bulk med en CSV-export/-import.

Verifiera den nya sessionstypen
1

Logga in på Control Hub och gå sedan till Tjänster > Möte.

2

Klicka på Webbplatser, välj den Webex-plats som du vill ändra inställningarna för och klicka sedan på Inställningar.

3

Under Allmänna inställningarväljer du Sessionstyper.

4
Du bör se en eller flera typer av slutpunkt-till-slutpunkt-krypteringssessioner. 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.

Det finns en äldre sessionstyp med ett mycket liknande namn: Kryptering för slutpunkt till slutpunkt. Denna sessionstyp inte krypterad för PSTN åtkomst till möten. Se till att du har den _endast VOIP-versionen för att säkerställa slutpunkt-till-slutpunkt-kryptering. Du kan kontrollera genom att hålla muspekaren över PRO-länken i kolumnen för sessionskod. Till exempel bör länken vara javascript:Visafunktion(652).

Vi kan ändra namnen på offentliga tjänster för dessa sessionstyper i framtiden.

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

Logga in på Control Hub och gå till Hantering > Användare.

2

Välj ett användarkonto att uppdatera och välj sedan Möten.

3

I listrutan Inställningar gäller för väljer du mötesplatsen som ska uppdateras.

4

Markera rutan bredvid Pro-End till End Encryption_endast.

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änder du nästa alternativ, Aktivera E2EE-möten för flera användare.

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

Logga in på Control Hub och gå sedan till Tjänster > Möte.

2

Klicka på Webbplatser och välj den Webex-webbplats som du vill ändra inställningarna för.

3

I avsnittet Licenser och användare klickar du på Masshantera.

4

Klicka på Generera rapport och vänta medan vi fö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 när du klickar på Hämta.)

6

Öppna den hämtade CSV-filen för redigering.

Det finns en rad för varje användare och kolumnen Mötesprivilegier innehåller deras sessionstyp-ID som en kommaavgränsad lista.

7

För varje användare som du vill bevilja den nya sessionstypen lägger du till 1561 som ett nytt värde i den kommaavgränsade listan i cellen Mötesprivilegier .

Referensen för Webex CSV-filformat innehåller information om syftet med 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 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.

Lägg till en ljudvattenstämpel för säkerhet

Du kan lägga till ett vattenmärke till mötesinspelningar med mötestypen Webex Meetings Pro-End to End Encryption_VoIP , vilket gör att du kan identifiera källklienten eller enheten för obehöriga inspelningar av konfidentiella möten.

När den här funktionen är aktiverad innehåller mötesljudet en unik identifierare för varje deltagande klient eller enhet. Du kan överföra ljudinspelningar till Control Hub, som sedan analyserar inspelningen och söker upp unika identifierare. Du kan titta på resultaten för att se vilken källklient eller enhet som spelade in mötet.

  • För att kunna analyseras måste inspelningen vara en AAC-, MP3-, M4A-, WAV-, MP4-, AVI- eller MOV-fil som inte är större än 500 MB.
  • Inspelningen måste vara längre än 100 sekunder.
  • Du kan endast analysera inspelningar för möten som hålls av personer i din organisation.
  • Information om Watermark lagras under samma tid som organisationens mötesinformation.

Lägg till ljudvattenmärken i E2EE-möten

  1. Logga in på Control Hub, sedan under Hantering, välj Organisationsinställningar.
  2. I avsnittet Mötes vattenmärken växlar du på Lägg till ljudvattenmärke.

    En tid efter att detta har aktiverats ser användare som schemalägger möten med mötestypen Webex Meetings Pro-End till End Encryption_VoIP endast ett alternativ för digital vattenmärkning i avsnittet Säkerhet.

Ladda upp och analysera ett vattenmärkt möte

  1. Välj Felsökning under Övervakning i Control Hub.
  2. Klicka på Watermark Analysis.
  3. Sök efter eller välj mötet i listan och klicka sedan på Analysera.
  4. I fönstret Analysera ljudvattenmärke anger du ett namn för din analys.
  5. (Valfritt) Ange en anteckning för din analys.
  6. Dra och släpp ljudfilen som ska analyseras eller klicka på Välj fil för att bläddra till ljudfilen.
  7. Klicka på Stäng.

    När analysen är klar visas den i resultatlistan på sidan Analysera vattenmärket .

  8. Välj mötet i listan för att se resultaten av analysen. Klicka Knappen Hämta för att hämta resultaten.

Funktioner och begränsningar

Faktorer som är inblandade i att avkoda en inspelad vattenstämpel är avståndet mellan inspelningsenheten och den högtalare som släpper ut ljudet, ljudvolymen, miljöbrus etc. Vår vattenmärkningsteknik har ytterligare motståndskraft mot att kodas flera gånger, vilket kan hända när media delas.

Den här funktionen är utformad för att möjliggöra lyckad avkodning av vattenmärkesidentifieraren i en bred men rimlig uppsättning omständigheter. Vårt mål är att en inspelningsenhet, till exempel en mobiltelefon, som ligger på ett skrivbord nära en personlig slutpunkt eller en bärbar klient, alltid ska skapa en inspelning som resulterar i en lyckad analys. När inspelningsenheten flyttas bort från källan eller döljs från att höra hela ljudspektrumet minskar chanserna för en lyckad analys.

För att kunna analysera en inspelning krävs en rimlig inspelning av mötesljudet. Om ett mötes ljud spelas in på samma dator som är värd för klienten bör begränsningar inte gälla.

Registrera enheter (intern CA)

Om dina enheter redan är registrerade i 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älla 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äljs en automatisk och andra mötesdeltagare kan se fel ut.

Innan du börjar

Om dina enheter ännu inte har registrerats följer du Registrera en enhet till Cisco Webex med API eller lokalt webbgränssnitt eller molnregistrering för Board-, Desk- och Room-serien. Du bör även verifiera de domäner som du vill använda för att identifiera enheterna i Hantera dina domäner.

1

Logga in på Control Hub och välj Enheter under Hantering.

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.

Registrera enheter (extern CA)

Innan du börjar

  • Skaffa ett CA-signerat certifikat och en privat nyckel, i .pem -format, för varje enhet.

  • Under fliken Förbereda läser du avsnittet Förstå extern identitetsprocess för enheter,

  • Förbered ett JWE-krypteringsverktyg med avseende på informationen där.

  • Se till att du har ett verktyg för att generera slumpmässiga byte sekvenser av givna längder.

  • Se till att du har ett verktyg för att basera URL-kodbyte eller text.

  • Se till att du har en scrypt implementering.

  • Se till att du har ett hemligt ord eller fras för varje enhet.

1

Fyll i enhetens klienthemlighet med en enkel texthemlighet:

Första gången du fyller i Hemligheten levererar du den i enkel text. Det är därför vi rekommenderar att du gör detta på den fysiska enhetens konsol.

  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: "MDEyMzQ1Njc4OWFiY2Rl

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

Enheten har sin ursprungliga hemlighet. Glöm inte detta. Du kan inte återställa det och måste fabriksåterställa enheten för att starta om.
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 y spara den som en ny .pem-fil.

    Det här är nyttobelastningstexten som du kommer att kryptera och sätta i din JWE-blob.

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

  2. Härrör ett innehåll 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 initierings-vektor.

  4. Skapa en JOSE-rubrik, ställa in alg, enc och cisco-kdf enligt beskrivningen i Understanding External Identity Process för enheter. Ange åtgärden ”lägg till” med hjälp av nyckeln:value "cisco-åtgärd":"lägg till" i JOSE-rubriken (eftersom vi lägger till certifikatet på 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:en så här (alla värden är base64url kodade):

    JOSEH eader..InitVector.KrypteradPEM.Autentiseringstagg

4

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

xcommand Security Certificates Services Add ärkrypterad: True din..JWE.str.ing\n .\n
5

Kontrollera att certifikatet läggs till genom att köra xcommand Security Certificates Services Show

Kopiera det nya certifikatets fingeravtryck.

6

Aktivera certifikatet för ändamålet med Webex Identity:

  1. Läs fingeravtrycken på certifikatet, antingen från själva certifikatet eller från utgången av 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 salt.

  3. Härrör ett innehåll 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 initierings-vektor.

  5. Skapa en JOSE-rubrik, ställa in alg, enc och cisco-kdf enligt beskrivningen i Understanding External Identity Process för enheter. Ange åtgärden ”aktivera” med hjälp av nyckeln:value "cisco-åtgärd":"aktivera" i JOSE-rubriken (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:en så här (alla värden är base64url kodade):

    JOSEH eader..InitVector.KrypteradFingeravtryck.Autentiseringstagg

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

     xcommand Security Certificate Services Activate Purpose: WebexIdentity Fingeravtryck: "Ditt..JWE.encrypted.fingeravtryck"

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 slutpunkt-till-slutpunkt-kryptering med identitetsverifiering
1

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

Se Schemalägga ett Webex Meeting med slutpunkt-till-slutpunkt-kryptering.

2

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

Se Delta i Webex Meeting med slutpunkt-till-slutpunkt-kryptering.

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 Delta i Webex Meeting med slutpunkt-till-slutpunkt-kryptering.

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 deltagare-/enhetsidentiteter där det ä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.

  • Om du har olika nivåer av identitetsverifiering kan du tillåta användare att verifiera varandra med certifikatbaserad identitet. Ä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 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.

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 EVOIPonlyncryption_

660

Pro 3 kostnadsfri till slut EVOIPonlyncryption_

E2E-kryptering + identitet

672

Pro 3 Free50-End till end EVOIPonlyncryption_

673

Utbildningsinstruktör E2E EVOIPonlyncryption_

676

Broadworks Standard plus slutpunkt-till-slutpunkt-kryptering

677

Broadworks Premium plus slutpunkt-till-slutpunkt-kryptering

681

Gratis kodning plus end-to-end-kryptering

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

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

API-samtal

Beskrivning

xPrioriterad domän för konfigurationskonferens, slutpunkt till slutpunkt, kryptering: "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.

xStatuskonferens slutpunkt-till-slutpunkt-kryptering tillgänglighet

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.

xStatuskonferens slutpunkt till slutpunkt Kryptering Verifiering av externidentitet

Anger om enheten använder extern verifiering (har ett externt certifikat).

xStatuskonferens avslutningtill slutpunkt-kryptering Externidentitetsidentitet

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

xStatuskonferens slutpunkttill slutpunkt-kryptering ExterntidentitetscertifikatKedjecertifikat # specifikation

Läser in specifik information från ett externt ut utfärdat certifikat.

I kommandot som visas ersätter du # med certifikatets nummer. Ersätt specifikationen med en av följande:

  • Fingeravtryck

  • Inte efter slutdatum för giltighet

  • Inte före giltighetsstartdatum

  • Primärnamn

  • Algoritm för offentlignyckel

  • Serienummer

  • Signaturalgoritm

  • Ämne # Namn En lista över ämnen för certifikatet (t.ex. e-postadress eller domännamn)

  • Giltighet Ger giltighetsstatus för detta certifikat (t.ex. giltig eller utgått)

xStatuskonferens slutförtill slutpunkt Kryptering Externidentitetsstatus

Status på enhetens externa identitet (t.ex. giltigt eller fel).

xStatuskonferens avslutastill slutpunkt Kryptering – internidentitetsverifiering

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

xStatuskonferens avslutastill slutpunkt Kryptering Internidentitet Identitet

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 som har flera domäner är detta värdet från önskad domän.

xStatuskonferens avslutastill slutpunkt Kryptering InterntIdentitetscertifikatKedjecertifikat # specifikation

Läser in specifik information från Webex-utfärdade certifikat.

I kommandot som visas ersätter du # med certifikatets nummer. Ersätt specifikationen med en av följande:

  • Fingeravtryck

  • Inte efter slutdatum för giltighet

  • Inte före giltighetsstartdatum

  • Primärnamn

  • Algoritm för offentlignyckel

  • Serienummer

  • Signaturalgoritm

  • Ämne # Namn En lista över ämnen för certifikatet (t.ex. e-postadress eller domännamn)

  • Giltighet Ger giltighetsstatus för detta certifikat (t.ex. giltig eller utgått)

Tabell 3. I samtals-API:er för end-to-end-krypterade möten och verifierad identitet

API-samtal

Beskrivning

xDeltagarlista för händelsekonferensmötesdeltagare har lagts till

xMötesdeltagarlistan för konferensmötesdeltagare har uppdaterats

xDeltagarlista för händelsekonferensmötesdeltagare har tagits bort

Dessa tre händelser inkluderar nu slutpunkt-till-slutpunkt-kryptering, slutpunkt-till-slutpunkt-identitet och slutpunkt-till-slutpunkt-kryptering 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 Client Secret Populate Secret: "bas64url-kodad"

eller

xCommand Security Client Secret Populate Secret: JWE-blob

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.

xTjänster för kommandosäkerhet Lägg till JWE-blob

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.

xTjänster för kommandosäkerhetscertifikat Aktivera syfte:WebexIdentity FingerPrint: JWE-blob

Aktiverar ett specifikt certifikat för WebexIdentity. För detta Syfte kräver kommandot att det identifierande fingeravtrycket krypteras och serialiseras i en JWE-blob.

xTjänster för kommandosäkerhetscertifikat Inaktivera syfte:WebexIdentity FingerPrint: JWE-blob

Inaktiverar ett specifikt certifikat för WebexIdentity. För detta Syfte kräver kommandot att det identifierande fingeravtrycket krypteras och serialiseras i en JWE-blob.