Användarupplevelse

Användare väljer mötestyp när de schemalägger ett möte. När värden släpper in mötesdeltagare från lobbyn, samt under mötet, kan de se identitetsverifieringsstatus för varje mötesdeltagare. Det finns också en möteskod som är gemensam för alla aktuella mötesdeltagare och 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 från tredje part.

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 möte som är krypterat från slutpunkt-till-slutpunkt.

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

Webex-appanvändare autentiserar sig mot Webex identitetslager, som ger dem en åtkomsttoken när autentiseringen lyckas. Om de behöver ett certifikat för att verifiera sin identitet i ett möte med kryptering från slutpunkt till slutpunkt utfärdar Webex CA dem ett certifikat baserat på deras å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 med ett certifikat som utfärdats av den interna (Webex) CA eller ett certifikat som utfärdats av en extern CA:

  • Intern CA – Webex utfärdar ett internt certifikat baserat på åtkomsttoken för enhetens maskinkonto. Certifikatet är signerat av Webex CA. Enheter har inte användar-ID:n på samma sätt som användare, 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, överföra direkt och auktorisera certifikaten med hjälp av en hemlighet som endast du känner till.

    Cisco är inte inblandad, vilket gör detta till ett sätt att garantera sann slutpunkt-till-slutpunkt-kryptering och verifierad identitet och förhindra den teoretiska möjligheten att Cisco kan förbise ditt möte/dekryptera dina media.

Internt utfärdat enhetscertifikat

Webex utfärdar ett certifikat till enheten när den registreras efter start och förnyar det vid behov. 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 xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Om du har flera domäner och inte anger önskad domän för enheten väljer Webex en åt dig.

Externt utfärdat enhetscertifikat

En administratör kan tillhandahålla en enhet med sitt eget certifikat som har signerats med en av de offentliga CA:erna.

Certifikatet måste baseras på ett ECDSA P-256-nyckelpar, även om det kan signeras av en RSA-nyckel.

Organisationen bestämmer värdena i certifikatet. Det vanliga namnet (CN) och det alternativa ämnesnamnet (SAN) visas i Webex-mötets användargränssnitt 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 en unik CN per enhet. Till exempel ”meeting-room-1.example.com” för organisationen som äger domänen ”example.com”.

För att fullständigt skydda det externa certifikatet från manipulering används en klient-hemlig funktion för att kryptera och signera olika Xcommands.

När klienthemligheten används är det möjligt att hantera det externa Webex-identitetscertifikatet på ett säkert sätt via xAPI. Detta är för närvarande begränsat till onlineenheter.

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

  • 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 sann slutpunkt-till-slutpunkt-kryptering bör endast du känna till/komma åt hemligheterna och nycklarna. Om vi introducerade en molntjänst för att hantera dessa nycklar finns det en risk att de kommer att avlyssnas.

  • För närvarande tillhandahåller vi ett ”recept” där du kan utforma dina egna verktyg, baserade på branschstandard-krypteringstekniker, för att hjälpa dig att begära eller kryptera dina enhetsidentitetscertifikat och deras privata nycklar. Vi vill inte ha verklig eller upplevd åtkomst till dina hemligheter eller nycklar.

Möten

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

  • Du kan dela nya whiteboardtavlor i E2EE-möten. Det finns vissa skillnader jämfört med whiteboardtavlor i vanliga 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 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ör 10.6.1-RoomOS_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 vara aktiverade så att personer kan delta från sitt videosystem. Mer information finns i Tillåt att videosystem deltar 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 externt verifierade identiteter.

För högsta säkerhet och för identitetsverifiering bör varje enhet ha ett unikt certifikat som utfärdats av en betrodd offentlig certifikatutfärdare (CA).

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

  • Certifikatet måste utfärdas och undertecknas av en välkänd offentlig certifikatutfärdare.

  • Unikt: Vi rekommenderar att du använder ett unikt certifikat för varje enhet. Om du använder ett certifikat för alla enheter äventyrar du din säkerhet.

  • Vanligt namn (CN) och alternativt ämnesnamn (SAN/s): Dessa är inte viktiga för Webex, men de bör vara värden som människor kan läsa och koppla till enheten. CN visar andra mötesdeltagare som enhetens primära verifierade identitet, och om användare inspekterar certifikatet via mötets användargränssnitt ser de SAN/s. Du kanske vill använda namn som name.model@example.com.

  • Filformat: Certifikaten och nycklarna måste vara i .pem formatet.

  • Syfte: Certifikatets syfte måste vara Webex Identity.

  • Generera nycklar: Certifikaten måste baseras på ECDSA P-256-nyckelpar (elliptical Curve Digital Signature Algorithm med P-256-kurvan).

    Detta krav 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 externt verifierad identitet med dina enheter.

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

Om du har befintliga enheter som du vill uppgradera för att använda externt 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 ett stegvist tillvägagångssätt. Meddela användarna om de ändringar de kan förvänta sig.

  • Säkerställ fysisk åtkomst till enheter. Om du måste komma åt enheter via nätverket bör du vara medveten om att hemligheter reser med oformaterad text och att du äventyrar din säkerhet.

När du har slutfört dessa steg kan du tillåta att videosystem deltar 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 den privata nyckeln på enheten. Vi har utformat API:er för enheten för att möjliggöra hantering av den krypterade nyckeln och certifikatet med hjälp av JSON Web Encryption (JWE).

För att säkerställa sann slutpunkt-till-slutpunkt-kryptering via vårt moln kan vi inte delta i kryptering och överföring av certifikatet och nyckeln. Om du behöver den här säkerhetsnivån måste du:

  1. Begär dina certifikat.

  2. Generera nyckelpar för dina certifikat.

  3. Skapa (och skydda) en initial hemlighet för varje enhet för att utsäde av enhetens krypteringsfunktion.

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

    Processen och de (icke-hemliga) parametrar som du behöver förklaras nedan, samt ett recept som du kan följa i dina valfria utvecklingsverktyg. Vi tillhandahåller även vissa testdata och de resulterande JWE-blåser som vi förväntar oss, för att hjälpa dig att verifiera din process.

    Ett referensprogram som inte stöds med Python3 och JWCrypto-biblioteket är tillgängligt på begäran från Cisco.

  5. Sammanfoga och kryptera certifikatet och nyckeln med ditt verktyg och enhetens inledande hemlighet.

  6. Ladda upp den resulterande JWE-blob till enheten.

  7. Ställ in syftet med det krypterade certifikatet som ska användas för Webex-identitet och aktivera certifikatet.

  8. (Rekommenderas) Tillhandahåll ett gränssnitt till (eller distribuera) ditt verktyg så att enhetsanvändare kan ändra den ursprungliga hemligheten och skydda sina medier från dig.

Hur vi använder JWE-formatet

I det här avsnittet beskrivs hur vi förväntar oss att JWE ska skapas som indata till enheterna, så att du kan skapa ditt eget verktyg för att skapa blocken från dina certifikat och nycklar.

Se JSON Web Encryption (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-block. De parametrar som du måste inkludera när du skapar JWE-blocken är:

  • JOSE-sidhuvud (skyddad). I rubriken JSON Object Signing and Encryption MÅSTE du inkludera följande nyckelvärdepar:

    • "alg":"dir"

      Den direkta algoritmen är den enda som vi stöder för att kryptera nyttolasten, och du måste använda enhetens ursprungliga klienthemlighet.

    • "enc":"A128GCM" eller "enc":"A256GCM"

      Vi har stöd för dessa två krypteringsalgoritmer.

    • "cisco-action": "add" eller "cisco-action": "populate""cisco-action": "activate" eller "cisco-action": "deactivate"

      Detta är en egenutvecklad nyckel och fyra värden som den kan ta. Vi introducerade den här nyckeln 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 namngav den cisco-action för att mildra potentiella kollisioner med framtida JWE-anknytningar.

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

      En annan egenutvecklad nyckel. Vi använder de värden du tillhandahåller som indata för nyckelhärledning på enheten. version måste vara 1 (versionen av vår nyckelhärledda funktion). Värdet på salt måste vara en base64-URL-kodad sekvens på minst 4 byte, som du måste välja slumpmässigt.

  • JWE-krypterad nyckel. Det här fältet är tomt. Enheten härleder den från den inledande ClientSecret.

  • JWE-initieringsvektor. Du måste ange en bas64URL-kodad initieringsvektor för att avkryptera nyttolasten. IV MÅSTE vara ett slumpmässigt 12 byte-värde (vi använder AES-GCM-krypteringsfamiljen, vilket kräver att IV ska vara 12 byte lång).

  • JWE AAD (ytterligare autentiserade data). Du måste utelämna det här fältet eftersom det inte stöds i den komprimerade serialiseringen.

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

    Nyttolasten 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 nyttolaster och du måste ange syftet med nyttolasten med cisco-action -nyckeln enligt följande:

    • Med "cisco-action":"populate" ciphertexten är den nya ClientSecret.

    • Med ”"cisco-action":"add" ciphertexten är ett PEM-block som bär certifikatet och dess privata nyckel (sammankopplad).

    • Med ”"cisco-action":"activate" ciphertexten är fingeravtrycket (hexadecimal representation av sha-1) för certifikatet som vi aktiverar för verifiering av enhetsidentitet.

    • Med ”"cisco-action":"deactivate" ciphertexten är fingeravtrycket (hexadecimal representation av sha-1) för certifikatet som vi inaktiverar från att användas för verifiering av enhetsidentitet.

  • JWE-autentiseringstagg: Det här fältet innehåller autentiseringstaggen för att kontrollera integriteten hos hela JWE kompakta serialiserade band

Hur vi hämtar krypteringsnyckeln från ClientSecret

Efter den första populationen av hemligheten accepterar vi inte eller skriver ut hemligheten som oformaterad text. Detta för att förhindra potentiella ordboksattacker från någon som kan komma åt enheten.

Enhetens programvara använder klienthemligheten som en inmatning till en nyckelderivatfunktion (kdf) och använder sedan den härledda nyckeln för innehållsdekryptering/kryptering på enheten.

Vad detta innebär för dig är att ditt verktyg för att producera JWE-block måste följa samma procedur för att härleda samma krypteringsnyckel/dekrypteringsnyckel från klienthemligheten.

Enheterna använder scrypt för nyckelhärledning (se https://en.wikipedia.org/wiki/Scrypt), med följande parametrar:

  • CostFactor (N) är 32768

  • BlockSizeFactor (r) är 8

  • Paralleliseringsfaktor (p) är 1

  • Salt är en slumpmässig sekvens på minst 4 byte. Du måste ange samma salt när du anger cisco-kdf parametern.

  • Nyckellängder är antingen 16 byte (om du väljer algoritmen AES-GCM 128) eller 32 byte (om du väljer algoritmen AES-GCM 256)

  • Maximal minneskapacitet är 64 MB

Denna uppsättning parametrar är den enda konfiguration av scrypt som är kompatibel med nyckelhärledningsfunktionen på enheterna. Denna kdf på enheterna heter "version":"1", som är den enda versionen som för närvarande används av parametern cisco-kdf .

Fungerade exempel

Här är ett exempel som du kan följa för att kontrollera att din JWE-krypteringsprocess fungerar på samma sätt som den process som vi skapade på enheterna.

Exemplet är att lägga till en PEM-blob till enheten (liknar att lägga 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 krypteringsalgoritm. Detta exempel använder A128GCM (AES med 128-bitarsknappar i Galois-räknarläget). Ditt verktyg kan användas A256GCM om du vill.

  2. Välj ett salt (måste vara en slumpmässig sekvens på minst 4 byte). Detta exempel använder (hexadecimala byte)E5 E6 53 08 03 F8 33 F6. Base64URL kodar sekvensen för att hämta 5eZTCAP4M_Y (ta bort base64-utfyllnad).

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

    cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

    Den härledda nyckeln ska vara 16 byte (hexadecimal) enligt följande:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac vilken bas64URL kodar till lZ66bdEiAQV4_mqdInj_rA.

  4. Välj en slumpmässig sekvens på 12 byte som ska användas som initieringsvektor. I det här exemplet används (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 som bas64URL kodar till NLNd3V9Te68tkpWD.

  5. Skapa JOSE-sidhuvudet med kompakt serialisering (följ samma ordning av parametrar som vi använder här) och koda sedan base64url den:

    {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

    Sidhuvudet för bas64url som kodats med JOSE är eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Detta kommer att vara det första elementet i JWE-blob.

  6. Det andra elementet i JWE-gruppen är tomt, eftersom vi inte tillhandahåller en JWE-krypteringsnyckel.

  7. Det tredje elementet i JWE-blob är initieringsvektorn NLNd3V9Te68tkpWD.

  8. Använd ditt JWE-krypteringsverktyg för att skapa en krypterad nyttolast och tagg. I det här exemplet kommer den okrypterade nyttolasten att vara den falska PEM-blob this is a PEM file

    De krypteringsparametrar du ska använda är:

    • Nyttolast är this is a PEM file

    • Krypteringsalgoritmen är AES 128 GCM

    • JOSE-sidhuvudet för bas64URL som ytterligare autentiserade data (AAD)

    Base64URL kodar den krypterade nyttolasten, vilket bör resultera i f5lLVuWNfKfmzYCo1YJfODhQ

    Det här är det fjärde elementet (JWE Ciphertext) i JWE-gruppen.

  9. Base64URL kodar taggen som du producerade i steg 8, vilket bör resultera i PE-wDFWGXFFBeo928cfZ1Q

    Detta är det femte elementet i JWE-blob.

  10. Sammanfoga de fem elementen i JWE-gruppen med punkter (JOSEheader..IV.Ciphertext.Tag) för att få:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Om du har härlett samma bas64URL-kodade värden som vi visar här, med dina egna verktyg, är du redo att använda dem för att skydda dina enheters E2E-kryptering och verifierad identitet.

  12. Det här exemplet kommer inte att fungera, men i princip är nästa steg att använda JWE-blob som du skapade ovan som indata till xcommand på enheten som lägger till certifikatet:

    xCommand Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

Sessionstyper för nollförtroendemöten är tillgängliga för alla möteswebbplatser utan extra kostnad. En av dessa sessionstyper kallas Pro-End to End Encryption_VOIPonly. Det här är namnet på den offentliga tjänsten, som vi kan ändra i framtiden. För aktuella namn på sessionstyperna, se ID:n för sessionstyp i avsnittet Referens i den här artikeln.

Du behöver inte göra något för att få den här funktionen för din webbplats. Du måste bevilja användare den nya sessionstypen (kallas även Mötesprivilegier). Du kan göra detta individuellt via användarens konfigurationssida eller i bulk med en CSV-export/import.

Verifiera den nya sessionstypen
1

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

2

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

3

Under Allmänna inställningar väljer du Sessionstyper.

Du bör se en eller flera sessionstyper för slutpunkt-till-slutpunkt-kryptering. Se listan över ID:n för sessionstyper i avsnittet Referens i den här artikeln. Du kan till exempel se Pro-End to End Encryption_Endast internettelefoni (VoIP).

Det finns en äldre sessionstyp med ett mycket liknande namn: Pro-slutpunkt-till-slutpunkt-kryptering. Den här sessionstypen inkluderar icke-krypterad PSTN-åtkomst till möten. Se till att du har versionen _VoIP only för att säkerställa slutpunkt-till-slutpunkt-kryptering. Du kan markera genom att hålla muspekaren över PRO -länken i kolumnen sessionskod. I detta exempel ska länken vara javascript:ShowFeature(652).

Vi kan ändra Public Service-namnen för dessa sessionstyper i framtiden.

4

Om du inte har den nya sessionstypen än kontaktar du din Webex-representant.

Nästa steg

Aktivera den här sessionstypen/mötesbehörigheten för vissa eller alla 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

Från den nedrullningsbara listan Inställningar tillämpa för väljer du den mötesplats som ska uppdateras.

4

Markera rutan bredvid Pro-End to End Encryption_Endast internettelefoni (VoIP).

5

Stäng panelen för användarkonfiguration.

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å 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 på 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 MeetingPrivilege kolumnen innehåller deras mötestyp-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 MeetingPrivilege cellen.

Referens för Webex CSV-filformat innehåller information om CSV-filens syfte och innehåll.

8

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

Om du redan fanns på sidan Mötesplats kan du behöva 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 har laddats upp.

11

När importen är klar kan du klicka på Importresultat för att granska om det fanns några fel.

12

Gå till sidan Användare och öppna en av användarna för att verifiera att de har den nya sessionstypen.

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

Du kan lägga till en vattenstämpel för mötesinspelningar med Webex Meetings Pro-End to End Encryption_VOIPonly sessionstypen, 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 ladda upp ljudinspelningar till Control Hub, som sedan analyserar inspelningen och söker upp de unika identifierarna. Du kan titta på resultaten för att se vilken källklient eller enhet som spelade in mötet.

  • För att inspelningen ska kunna analyseras måste den 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 bara analysera inspelningar för möten som hålls av personer i din organisation.
  • Information om tröskelvärden sparas under samma tid som organisationens mötesinformation.

Lägg till ljudvattenstämplar i E2EE-möten

  1. Logga in på Control Hub och välj sedan Organisationsinställningar under Hantering.
  2. I avsnittet Tröskelvärden för möte aktiverar du Lägg till ljudvattenstämpel.

    En tid efter att detta har aktiverats ser användare som schemalägger möten med Webex Meetings Pro-End to End Encryption_VOIPonly sessionstypen ett alternativ för Digital vattenstämpel i avsnittet Säkerhet.

Ladda upp och analysera ett vattenmarkerat möte

  1. Under Övervakning i Control Hub väljer du Felsökning.
  2. Klicka på Vattenstämpelanalys.
  3. Sök efter eller välj mötet i listan och klicka sedan på Analysera.
  4. Ange ett namn för din analys i fönstret Analysera ljudvattenstämpel .
  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 listan med resultat på sidan Analysera vattenstämpel .

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

Funktioner och begränsningar

Faktorer som påverkar avkodningen av en inspelad vattenstämpel är avståndet mellan inspelningsenheten och högtalaren som avger ljudet, ljudvolymen, miljöbrus osv. Vår vattenstämpelteknik har ytterligare motståndskraft mot kodning flera gånger, vilket kan hända när media delas.

Den här funktionen är utformad för att möjliggöra en lyckad avkodning av tröskelvärdesidentifieraren under 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 är dold från att höra hela ljudspektrumet minskar sannolikheten 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 ska 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 identifieringscertifikat behöver du inte fabriksåterställa enheterna.

Denna procedur väljer vilken domän enheten använder för att identifiera sig själv och krävs endast 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 ”Cisco-verifierad” identitet. Om du inte talar om för Webex vilken domän som identifierar enheten väljs en automatiskt 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 i Cisco Webex via API eller lokalt webbgränssnitt eller Molnregistrering för Board-, Desk- och Room-serien. Du bör även verifiera domänen/domänerna du vill använda för att identifiera enheterna i Hantera dina domäner.

1

Logga in på Control Hub och under Hantering väljer du 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 den här enheten.

4

Upprepa för andra enheter.

Registrera enheter (extern CA)

Innan du börjar

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

  • Under fliken Förbered läser du avsnittet Förstå processen för extern identitet 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 koda byte eller text till bas64URL.

  • Se till att du har en scrypt implementering.

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

1

Fyll i enhetens ClientSecret med en oformaterad texthemlighet:

Första gången du fyller i Secret anger du det 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 ditt eget.

Enheten har sin ursprungliga hemlighet. Glöm inte detta. Du kan inte återställa det och du måste göra en fabriksåterställning för att starta om.
2

Sammanfoga ditt certifikat och din privata nyckel:

  1. Med hjälp av en textredigerare öppnar du .pem-filerna, klistrar in nyckelfliken certifikatfliken och sparar den som en ny .pem-fil.

    Det här är nyttolasttexten som du krypterar och lägger i din JWE-flik.

3

Skapa ett JWE-block att använda som indata i kommandot Lägg till certifikat:

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

  2. Härleda en krypteringsnyckel för innehåll med ditt krypteringsverktyg.

    För detta behöver du hemligheten, saltet och en nyckellängd för att matcha din valda krypteringsalgoritm. Det finns några andra fasta värden att ange (N=32768, r=8, p=1). Enheten använder samma process och värden för att härleda samma krypteringsnyckel för innehåll.

  3. Skapa en slumpmässig sekvens på exakt 12 byte. Det här är din initieringsvektor.

  4. Skapa en JOSE-rubrik, inställningar alg, enc och cisco-kdf nycklar enligt beskrivningen i 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 JOSE-sidhuvudet (eftersom vi lägger till certifikatet till enheten).

  5. Base64url kodar JOSE-sidhuvudet.

  6. Använd ditt JWE-krypteringsverktyg med vald chiffer och JOSE-sidhuvudet för bas64url för att kryptera texten från den sammanlänkade pem-filen.

  7. Base64URL kodar initieringsvektorn, krypterad PEM-nyttolast och autentiseringstaggen.

  8. Skapa JWE-blob enligt följande (alla värden är kodade på base64URL):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Öppna TShell på enheten och kör tilläggskommandot (multilinje): 

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 ändamålet WebexIdentity:

  1. Läs fingeravtrycket på certifikatet, 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 byte och base64URL kodar den sekvensen. Det här är ditt salt.

  3. Härleda en krypteringsnyckel för innehåll med ditt krypteringsverktyg.

    För detta behöver du hemligheten, saltet och en nyckellängd för att matcha din valda krypteringsalgoritm. Det finns några andra fasta värden att ange (N=32768, r=8, p=1). Enheten använder samma process och värden för att härleda samma krypteringsnyckel för innehåll.

  4. Skapa en slumpmässig sekvens på exakt 12 byte och base64url kodar den sekvensen. Det här är din initieringsvektor.

  5. Skapa en JOSE-rubrik, inställningar alg, enc och cisco-kdf nycklar enligt beskrivningen i 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 JOSE-sidhuvudet (eftersom vi aktiverar certifikatet på enheten).

  6. Base64url kodar JOSE-sidhuvudet.

  7. Använd ditt JWE-krypteringsverktyg med den valda chiffren och JOSE-sidhuvudet för bas64url för att kryptera certifikatets fingeravtryck.

    Verktyget ska visa en sekvens på 16 eller 32 byte, beroende på om du har valt 128 eller 256 bitar AES-GCM, och en autentiseringstagg.

  8. Base64urlencode det krypterade fingeravtrycket och autentiseringstaggen.

  9. Skapa JWE-blob enligt följande (alla värden är kodade på base64URL):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

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

                      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 kryptering från slutpunkt-till-slutpunkt.
7

Registrera enheten i din Control Hub-organisation.

Testa end-to-end-kryptering med identitetsverifiering
1

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

Se Schemalägg ett Webex-möte med slutpunkt-till-slutpunkt-kryptering.

2

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

Se Delta i ett Webex-möte med totalsträckskryptering.

3

Delta i mötet från en enhet som har sin identitet verifierad av Webex CA.

4

Som värd kontrollerar du att den här enheten visas i lobbyn med rätt identitetsikon.

Se Delta i ett Webex-möte med totalsträckskryptering.

5

Delta i mötet från en enhet som har sin identitet verifierad av en extern certifikatutfärdare.

6

Som värd kontrollerar du att den här enheten visas i lobbyn med rätt identitetsikon. Läs mer om identitetsikoner.

7

Delta i mötet som en oautentiserad mötesdeltagare.

8

Som värd kontrollerar du att den här mötesdeltagaren visas i lobbyn med rätt identitetsikon.

9

Som värd släpper du in eller avvisar personer/enheter.

10

Validera deltagar-/enhetsidentiteter nä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öten.

Ange omfattning och förväntningar

  • Kommer du att göra möten med kryptering från slutpunkt till slutpunkt till standardalternativet, eller aktivera det endast för vissa användare, eller tillåta att alla värdar bestämmer? När du har bestämt dig för hur du ska använda den här funktionen ska du förbereda de användare som kommer att använda den, särskilt med hänsyn till begränsningarna och vad du kan förvänta dig under mötet.

  • Behöver du säkerställa att varken Cisco eller någon annan kan dekryptera ditt innehåll eller personifiera dina enheter? I så fall behöver du certifikat från en offentlig certifikatutfärdare.

  • Om du har olika nivåer av identitetsverifiering kan användare verifiera varandra med certifikatbaserad identitet. Även om det finns omständigheter där deltagare kan visas som overifierade, och deltagarna bör veta hur de ska kontrollera, kan overifierade personer inte vara impostorer.

Identitetshantering

Om du använder en extern CA för att utfärda dina enhetscertifikat är det upp till dig att övervaka, uppdatera och tillämpa certifikat igen.

Om du skapade den inledande hemligheten ska du förstå att dina användare kanske vill ändra hemligheten för sin enhet. Du kan behöva skapa ett gränssnitt/distribuera ett verktyg för att göra detta.

ID:n för sessionstyp
Tabell 1. ID:n för sessionstypen för möten med kryptering från slutpunkt till slutpunkt

ID för sessionstyp

Namn på offentlig tjänst

638

E2E-kryptering + endast VoIP

652

Pro-slutpunkt till slutpunktncryption_Endast internettelefoni (VoIP)

660

Pro 3 Free-End to End Encryption_VoIPonly

E2E-kryptering + identitet

672

Pro 3 Free50-slutpunkt till slutpunktncryption_Endast internettelefoni (VoIP)

673

Instruktör E2E Encryption_Endast internettelefoni (VoIP)

676

BroadWorks-standard plus end-to-end-kryptering

677

BroadWorks Premium plus kryptering från slutpunkt till slutpunkt

681

Skoologi Free plus kryptering från slutpunkt till slutpunkt

Relaterade xAPI-kommandon

Dessa tabeller beskriver Webex-enheters API-kommandon som vi har lagt till för möten som är krypterade från slutpunkt-till-slutpunkt och verifierad identitet. Mer information om hur du använder API finns i Åtkomst till API för Webex Room- och Desk-enheter samt Webex Boards.

Dessa xAPI-kommandon är endast tillgängliga på enheter som antingen:

  • Registrerad för Webex

  • Registrerad lokalt och länkad till Webex med Webex Edge for Devices

Tabell 2. API:er på systemnivå för möten med kryptering från slutpunkt till slutpunkt och verifierad identitet

API-samtal

Beskrivning

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 den här domänen 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 certifikat som identifierar sig själv.

xStatus Conference EndToEndEncryption Availability

Anger om enheten kan delta i ett möte med kryptering från slutpunkt till slutpunkt. Molnet-API ringer upp den så att en parkopplad app vet om den kan använda enheten för att delta.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Anger om enheten använder External verifiering (har ett externt utfärdat certifikat).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

Enhetens identitet enligt det externt utfärdade certifikatets vanliga namn.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

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

I kommandot som visas ersätter du # med certifikatets nummer. Ersätt specificinfo med något av:

  • Fingerprint

  • NotAfter Slutdatum för giltighet

  • NotBefore Startdatum för giltighet

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

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

  • Validity Ger detta certifikats giltighetsstatus (t.ex. valid eller expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

Status för enhetens externa identitet (t.ex. valid eller error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

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

xStatus Conference EndToEndEncryption InternalIdentity Identity

Enhetens identitet enligt det vanliga namnet på det Webex-utfärdade certifikatet.

Innehåller ett domännamn om organisationen har en domän.

Är tomt om organisationen inte har en domän.

Om enheten finns i en organisation som har flera domäner är detta värdet från PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Läser specifik information från det Webex-utfärdade certifikatet.

I kommandot som visas ersätter du # med certifikatets nummer. Ersätt specificinfo med något av:

  • Fingerprint

  • NotAfter Slutdatum för giltighet

  • NotBefore Startdatum för giltighet

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

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

  • Validity Ger detta certifikats giltighetsstatus (t.ex. valid eller expired)

Tabell 3. I API:er för samtal för slutpunkt-till-slutpunkt-krypterade möten och verifierad identitet

API-samtal

Beskrivning

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Dessa tre händelser inkluderar nu EndToEndEncryptionStatus, EndToEndEncryptionIdentity och EndToEndEncryptionCertInfo för den berörda deltagaren.

Tabell 4. ClientSecret-relaterade API:er för slutpunkt-till-slutpunkt-krypterade möten och verifierad identitet

API-samtal

Beskrivning

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

eller

xCommand Security ClientSecret Populate Secret: JWEblob

Accepterar ett base64URL-kodat oformaterat textvärde för sökning av klienthemligheten på enheten för första gången.

För att uppdatera hemligheten efter den första gången måste du tillhandahålla ett JWE-block som innehåller den nya hemligheten krypterad med den gamla hemligheten.

xCommand Security Certificates Services Add JWEblob

Lägger till ett certifikat (med privat nyckel).

Vi har utökat det här kommandot för att acceptera ett JWE-block som innehåller krypterade PEM-data.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Aktiverar ett specifikt certifikat för WebexIdentity. För detta Purpose kräver kommandot att identifierande fingeravtryck krypteras och serialiseras i ett JWE-block.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Inaktiverar ett specifikt certifikat för WebexIdentity. För detta Purpose kräver kommandot att identifierande fingeravtryck krypteras och serialiseras i ett JWE-block.