10 oktober 2026 | 1233 visning(ar) | 1 personer tyckte att detta var till hjälp
Distribuera Zero-Trust-möten
list-menuHar du feedback?
Zero-Trust Security från Webex ger end-to-end-kryptering och stark identitetsverifiering i dina schemalagda och personliga rumsmöten.

Användarupplevelse

Användare väljer mötestyp när de schemalägger ett möte. Vid antagning av deltagare från lobbyn, såväl som under mötet, kan värden se identitetsverifieringsstatusen för varje deltagare. 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 att deras möte inte har avlyssnats av en oönskad tredjeparts Meddler In The Middle (MITM) attack.

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

Identitetsverifiering med intern eller extern certifikatutfärdare

Verifiera identitet

End-to-end-kryptering med identitetsverifiering ger ytterligare säkerhet till ett end-to-end-krypterat möte.

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

Webex App-användare autentiserar sig mot Webex identitetsbutik, som ger dem en åtkomsttoken när autentiseringen lyckas. Om de behöver ett certifikat för att verifiera sin identitet i ett end-to-end-krypterat möte utfärdar Webex CA 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 tredjepart/extern certifikatutfärdare.

Enheter kan autentisera sig själva med hjälp av ett certifikat som utfärdats av den interna (Webex) certifikatutfärdaren eller ett certifikat utfärdat av en extern certifikatutfärdare:

  • Intern CA — WebEx utfärdar ett internt certifikat baserat på åtkomsttoken för enhetens datorkonto. Certifikatet är signerat av Webex CA. Enheter har inte användar-ID på samma sätt som användare gör, så Webex använder (en av) organisationens 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, direkt ladda upp och auktorisera certifikaten med hjälp av en hemlighet som bara är känd för dig.

    Cisco är inte inblandat, vilket gör detta till ett sätt att garantera äkta end-to-end-kryptering och verifierad identitet, och förhindra den teoretiska möjligheten att Cisco kan avlyssna ditt möte/dekryptera ditt media.

Internt utfärdat enhetscertifikat

Webex utfärdar ett certifikat till enheten när den registrerar sig 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 certifikatutfärdaren certifikatet utan en domän.

Om din organisation har flera domäner kan du använda Control Hub för att berätta för Webex vilken domän enheten ska använda för sin identitet. Du kan också 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 certifikatutfärdarna.

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

Värdena i certifikatet är enligt organisationens bedömning. Vanligt namn (CN) och Subject Alternative Name (SAN) visas i Webex-mötesanvändargränssnittet, enligt beskrivningen i End-to- end-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. Till exempel ”meeting-room-1.example.com” för organisationen som äger domänen ”example.com”.

För att helt skydda det externa certifikatet från manipulation används en klient-hemlig funktion för att kryptera och signera olika xkommandon.

När du använder klientens hemlighet är det möjligt att säkert hantera det externa Webex-identitetscertifikatet 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

Molnregistrerade Cisco Board-, Desk- och Room Series-enheter kan delta i E2EE-möten.

Följande enheter kan inte ansluta till E2EE-möten:

  • 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 gå med i E2EE-möten.

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

Identitet

  • Genom design tillhandahåller vi inte Control Hub-alternativ för dig att hantera externt verifierad enhetsidentitet. För äkta end-to-end-kryptering bör du bara känna/komma åt hemligheterna och nycklarna. Om vi introducerade en molntjänst för att hantera dessa nycklar finns det en chans att de fångas upp.

  • För närvarande tillhandahåller vi ett ”recept” för dig att utforma dina egna verktyg, baserat på branschstandardkrypteringstekniker, för att hjälpa till med att begära eller kryptera dina enhetsidentitetscertifikat och deras privata nycklar. Vi vill inte ha någon verklig eller upplevd tillgång till dina hemligheter eller nycklar.

Möten

  • E2EE-möten stöder för närvarande maximalt 1000 deltagare.

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

Hanteringsgränssnitt

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

Ytterligare resurser
Förutsättningar

  • Webex Meetings41.7.

  • Molnregistrerade Cisco Board-, Desk- och Room Series-enheter som kör 10.6.1- RoomOS_August_2021 eller senare.

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

  • En eller flera verifierade domäner i din Control Hub-organisation (om du använder Webex certifikatutfärdare för att utfärda enhetscertifikat för verifierad identitet).

  • Mötesrum för samarbete måste vara aktiverat så att personer kan gå med från sitt 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 externt verifierade identiteter.

För högsta säkerhetsnivå och för identitetsverifiering bör varje enhet ha ett unikt certifikat utfärdat av en betrodd publik Certificate Authority (CA).

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

  • Certifikatet måste utfärdas och undertecknas 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 äventyrar du din säkerhet.

  • Vanligt namn (CN) och Subject Alternate Namn/s (SAN/s): Dessa är inte viktiga för Webex, men bör vara värden som människor kan läsa och associera med enheten. CN visas för andra mötesdeltagare som enhetens primära verifierade identitet, och om användare inspekterar 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 formatet .pem.

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

  • Generera nycklar: Certifikaten måste baseras på ECDSA P-256-nyckelpar (Elliptical Curve Digital Signature Algorithm som använder P-256-kurvan).

    Detta krav gäller inte signeringsnyckeln. Certifikatutfärdaren kan använda en RSA-nyckel för att signera certifikatet.

Förbered dig på inbyggda 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 på Webex ännu. För att vara säker, anslut dem inte till nätverket just nu.

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 en stegvis metod. Meddela användare 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, var medveten om att hemligheter reser i vanlig text och att du äventyrar din säkerhet.

När du har slutfört dessa steg tillåter du 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 enhetens media inte kan krypteras av någon annan än enheten måste du kryptera den privata nyckeln på enheten. Vi utformade 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 äkta end-to-end-kryptering via vårt moln kan vi inte vara involverade i att kryptera och ladda upp certifikatet och nyckeln. Om du behöver denna säkerhetsnivå måste du:

  1. Begär dina certifikat.

  2. Generera dina certifikats nyckelpar.

  3. Skapa (och skydda) en första hemlighet för varje enhet för att utöka enhetens krypteringsförmåga.

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

    Processen och de (icke-hemliga) parametrar du behöver förklaras nedan, liksom ett recept att följa i dina utvecklingsverktyg du väljer. Vi tillhandahåller också några testdata och de resulterande JWE-blobbarna som vi förväntar oss dem, för att hjälpa dig att verifiera din process.

    En referensimplementering som inte stöds med Python3 och JWCrypto-biblioteket är tillgänglig från Cisco på begäran.

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

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

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

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

Hur vi använder JWE-formatet

Det här avsnittet beskriver hur vi förväntar oss att JWE skapas som input till enheterna, så att du kan bygga ditt eget verktyg för att skapa blobs 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-blobs. Parametrarna du behöver inkludera när du skapar JWE-blobs är:

  • JOSE Rubri k (skyddad). I rubriken JSON-objektsignering och kryptering MÅSTE du inkludera följande nyckelvärde-par:

    • ”alg” :"dir”

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

    • ”enc”: ”A128GCM” eller ”enc”: ”A256GCM”

      Vi stöder dessa två krypteringsalgoritmer.

    • ”cisco-action”: ”lägg till” eller ”cisco-action”: ”fylla” eller ”cisco-action”: ”aktivera” eller ”cisco-action”: ”inaktivera”

      Detta är en proprietär nyckel och fyra värden den kan ta. Vi introducerade denna nyckel för att signalera syftet med de krypterade uppgifterna till målenheten. Värdena är uppkallade efter xAPI-kommandona på enheten där du använder krypterade data.

      Vi kallade det cisco-action för att mildra potentiella konflikter med framtida JWE-förlängningar.

    • ”cisco-kdf”: {”version”: ”1", ”salt”: ”base64URLEncodeDrandom4+byte”}

      En annan proprietär nyckel. Vi använder de värden du anger som ingångar för nyckelhärledning på enheten. Versionen måste vara 1 (versionen av vår nyckelhärledningsfunktion). 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 ursprungliga ClientSecret.

  • JWE Initialiseringsvektor. Du måste ange en base64url-kodad initialiseringsvektor för att dekryptera nyttolasten. IV MÅSTE vara ett slumpmässigt 12 byte värde (vi använder AES-GCM-chifferfamiljen, vilket kräver att IV är 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 Compact Serialization.

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

    Nyttolasten KAN vara tom. Till exempel, för att återställa klientens hemlighet 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” är chiffertexten den nya ClientSecret.

    • Med "”cisco-action” :"add” är chiffertexten en PEM-blob som bär certifikatet och dess privata nyckel (sammanfogad).

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

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

  • JWE-autentiseringstagg: Det här fältet innehåller autentiseringstaggen för att fastställa integriteten för hela JWE-kompakt serialiserade blob

Hur vi härleder krypteringsnyckeln från ClientSecret

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

Enhetsprogramvaran använder klientens hemlighet som en ingång till en nyckelhärledningsfunktion (kdf) och använder sedan den härledda nyckeln för innehållsdekryptering/kryptering på enheten.

Vad detta betyder för dig är att ditt verktyg för att producera JWE-blobs måste följa samma procedur för att härleda samma krypterings-/dekrypteringsnyckel från klientens hemlighet.

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

  • ParallelizationFactor (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 AES-GCM 128-algoritmen) eller 32 byte (om du väljer AES-GCM 256-algoritmen)

  • Max minnesgräns är 64 MB

Denna uppsättning parametrar är den enda konfigurationen av scrypt som är kompatibel med nyckelderivationsfunktionen på enheterna. Denna kdf på enheterna kallas ”version”: ”1", vilket är den enda versionen som för närvarande tas av cisco-kdf-parametern.

Arbetat 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 processen vi skapade på enheterna.

Exempelscenariot är att lägga till en PEM-blob till enheten (efterliknar att lägga till ett certifikat, med en mycket kort sträng istället för en fullständig cert +-nyckel). Klientens hemlighet i exemplet är ossifrage.

  1. Välj en krypteringschifer. I det här exemplet används A128GCM (AES med 128-bitars tangenter i Galois-räknarläget). Ditt verktyg kan använda A256GCM om du föredrar det.

  2. Välj ett salt (måste vara en slumpmässig sekvens på minst 4 byte). I det här exemplet används (hexbyte) E5 E6 53 08 03 F8 33 F 6. Base64URL kodar sekvensen för att få 5eztcap4 m_y (ta bort base64-stoppningen).

  3. Här är ett exempel på ett 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 bör vara 16 byte (hex) enligt följande: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac som base64url kodar till LZ66BDeiaqv4_mqdinj_ra.

  4. Välj en slumpmässig sekvens på 12 byte att använda som en initialiseringsvektor. Detta exempel använder (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 som base64url kodar till nLnd3v9te68tkpwd.

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

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

    Den base64url-kodade JOSE-rubriken är EyjhbGcioIJkAxiiLcJjaXnJBY1hy3rpb24ioiJhzgqIlcJjaXnjby1rzGyionSiC2fsdCi6ijvLwLrdqVA0tV9ziiWIDmVyc2LvBii6iJEifsWiZw5JiJoiqTeYoEddTSj9

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

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

  7. Det tredje elementet i JWE-bloben är initialiseringsvektorn NlnD3v9TE68tkpwd.

  8. Använd ditt JWE-krypteringsverktyg för att producera en krypterad nyttolast och tagg. I det här exemplet kommer den okrypterade nyttolasten att vara den falska PEM-bloben, detta är en PEM-fil

    Krypteringsparametrarna du bör använda är:

    • Payload är det här är en PEM-fil

    • Krypteringskoder är AES 128 GCM

    • Den base64url-kodade JOSE-rubriken som ytterligare autentiserade data (AAD)

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

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

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

    Detta är det femte elementet i JWE-bloben.

  10. Sammanfoga de fem elementen i JWE-bloben med prickar (JoseHeader.. iv.CipherText.tag) för att få:

    EYJhbgCIOIjkAxiiLcJaxNjby1hy3rpb24ioiJhzgQiLCJjaXnJbY1RzgyiOnSiC2FsdCi6ijVLrdQva0tV9ZiiWiDMvYc2LvBiI6iJeiFsWiZw5jiJoiqTeyOeddTSj.. 9nLnd3v9TE68pWlLd.f5tKf5tKlLf9nLnd3v9tE68pWf5lLf5JiJoIQtEYoEDDtSj.. VUWNfkfmzyco1yjfodhq.pe-wdfwgxffbeo928cfz1q

  11. Om du härledde samma base64url-kodade värden som vi visar här, med dina egna verktyg, är du redo att använda dem för att säkra E2E-kryptering och verifierad identitet på dina enheter.

  12. Det här exemplet fungerar faktiskt inte, men i princip skulle ditt nästa steg vara att använda JWE-bloben du skapade ovan som indata till xcommand på enheten som lägger till certifikatet:

    XCommand Säkerhetscertifikat Lägg till eyJhbgCIoIJkAxiiLcJjaXnjbY1hy3rpb24ioiJhzgQiLCJjaXnjby1rzGyIONSiC2fsdci6ijVLWLrdqVA0tV9ziiWIDmvyC2LvBii6iJEifsWiZw5jiJoiqTeyOeDdDtSj.. 9nLnND3v9tK68TkJ.. PWD.F5LLVUWNfkfmzyco1yjfodhq.pe-wdfwg xffbeo928cfz1q

Sessionstyper för möten med nollförtroende är tillgängliga för alla mötesplatser utan extra kostnad. En av dessa sessionstyper kallas Pro-End to End Encryption_ VoipOnly. Detta är Public Service Name, som vi kan ändra i framtiden. För aktuella namn på sessionstyperna, se Sessionstyp-ID i avsnittet Refer ens 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ötesprivilegium) till användare. Du kan göra detta individuellt via användarens konfigurationssida eller i bulk med en CSV-export/import.

Kontrollera 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 Vanliga inställningar väljer du Sessionstyper.

Du bör se en eller flera end-to-end-krypteringssessionstyper. Se listan över sessionstyp-ID:n i avsnittet Refer ens i den här artikeln. Du kan till exempel se Pro-End to End Encryption_ VoipOnly.

Det finns en äldre sessionstyp med ett mycket liknande namn: Pro-End to End Encryption. Den här sessionstypen inkluderar icke-krypterad PSTN-åtkomst till möten. Se till att du har _VoIPonly- versionen för att säkerställa end-to-end-kryptering. Du kan kontrollera genom att hålla muspekaren över PRO- länken i kolumnen sessionskod. I det här exemplet ska länkens mål vara JavaScript :showFeature (652).

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

4

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

Vad du ska göra härnäst

Aktivera den här sessionstypen/mötesbehörigheten 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 Han tering > Användare.

2

Välj ett användarkonto som ska uppdateras och välj sedan Möten.

3

Välj mötesplatsen som ska uppdateras i listrutan Inställningar gäller för.

4

Markera rutan bredvid Pro-End to End Encryption_ VoipOnly.

5

Stäng användarkonfigurationspanelen.

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å Webb platser, välj den Webex-webbplats som du vill ändra inställningarna för.

3

Klicka på Masshantering i avsnittet Licenser och användare.

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å Ladda ner.)

6

Öppna den nedladdade CSV-filen för redigering.

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

7

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

Webex CSV File Format Reference innehåller information om syftet med och innehållet i CSV-filen.

8

Öppna konfigurationspanelen Mötesplats i Control Hub.

Om du redan var på listsidan Mötesplats kan du behöva uppdatera den.

9

Klicka på Masshantering i avsnittet Licenser och användare.

10

Klicka på Importera och välj den redigerade CSV-filen och klicka sedan på Importera. Vänta medan filen laddas upp.

11

När importen är klar kan du klicka på Importera resultat 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 ett ljudvattenstämpel för säkerhet

Du kan lägga till en vattenstämpel i mötesinspelningar med session Webex Meetingsstypen Pro-End to End Encryption_VoipOnly, som låter dig 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 slår 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 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 bara analysera inspelningar för möten som hålls av personer i organisationen.
  • Vattenmärkesinformation sparas under samma tid som organisationens mötesinformation.

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

  1. Logga in på Control Hub och välj sedan Organisationsinställningar under Han tering.
  2. I avsnittet Mötesvattenmärken, växla på Lägg till ljudvattenstämpel.

    Någon gång efter att detta har aktiverats visas ett alternativ för digital vattenmärkning i avsnittet Säkerhet för användare som planerar möten med sessionstypen Webex Meetings Pro-End to End Encryption_VoipOnly.

Ladda upp och analysera ett vattenmärkt möte

  1. Välj Fel sökning under Övervakning i Control Hub.
  2. Klicka på Vatten stämpelanalys.
  3. Sök efter eller välj mötet i listan och klicka sedan på Analysera.
  4. Ange ett namn för analysen 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 resultaten av analysen. Klick Download button för att ladda ner resultaten.

Funktioner och begränsningar

Faktorer som är involverade i att framgångsrikt avkoda ett inspelat vattenstämpel inkluderar avståndet mellan inspelningsenheten och högtalaren som matar ut ljudet, volymen på det ljudet, 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 framgångsrik avkodning av vattenstämpelidentifieraren 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 bärbar klient, alltid ska skapa en inspelning som resulterar i en framgångsrik analys. När inspelningsenheten flyttas bort från källan, eller döljs från att höra hela ljudspektrumet, minskar chansen för en framgångsrik analys.

För att framgångsrikt 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.

Inbyggda 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 deras 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 krävs endast om du har flera domäner i din Control Hub-organisation. Om du har mer än en domän rekommenderar vi att du gör detta för alla dina enheter som har ”Cisco-verifierad” identitet. Om du inte berättar för Webex vilken domän som identifierar enheten väljs en automatiskt och den kan se fel ut för andra mötesdeltagare.

Innan du börjar

Om dina enheter ännu inte är anslutna följer du Registrera en enhet för att Cisco Webex använda API eller lokalt webbgränssnitt eller Cloud onboarding för Board, Desk och Room Series. Du bör också 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 välj Enh eter under Hantering.

2

Välj en enhet för att öppna dess konfigurationspanel.

3

Välj den domän du vill använda för att identifiera den här enheten.

4

Upprepa för andra enheter.

Inbyggda enheter (extern certifikatutfärdare)

Innan du börjar

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

  • Under fliken För bered läser du avsnittet För stå 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 bytesekvenser med givna längder.

  • Se till att du har ett verktyg för att base64url koda byte eller text.

  • Se till att du har en scrypt-implementering.

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

1

Fyll enhetens ClientSecret med en vanlig texthemlighet:

Första gången du fyller i Hemligheten tillhandahåller du den i vanlig text. Det är därför vi rekommenderar 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 Hemligheten med frasen 0 123456789abcdef. Du måste välja din egen.

Enheten har sin ursprungliga hemlighet. Glöm inte detta; du kan inte återställa den och måste fabriksåterställa enheten för att starta igen.
2

Sammanfoga ditt certifikat och din privata nyckel:

  1. Öppna filen.pem med hjälp av en textredigerare, klistra in nyckelbloben i certifikatbloben och spara den som en ny.pem-fil.

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

3

Skapa en JWE-blob som ska användas som indata till certifikattilläggskommandot:

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

  2. Härleda en innehållskrypteringsnyckel med ditt scrypt-verktyg.

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

  3. Skapa en slumpmässig sekvens på exakt 12 byte. Detta är din initialiseringsvektor.

  4. Skapa en JOSE-rubrik, ange alg-, enc - och cisco-kdf- nycklar enligt beskrivningen i För stå extern identitet sprocess för enheter. Ställ in åtgärden ”lägg till” med hjälp av nyckel:value ”cisco-action” :"add” i JOSE-rubriken (eftersom vi lägger till certifikatet på enheten).

  5. Base64URL kodar JOSE-rubriken.

  6. Använd ditt JWE-krypteringsverktyg med den valda krypteringen och base64url-kodade JOSE-rubriken för att kryptera texten från den sammanfogade pem-filen.

  7. Base64URL kodar initieringsvektorn, den krypterade PEM-nyttolasten och autentiseringstaggen.

  8. Konstruera JWE-blob enligt följande (alla värden är base64url-kodade):

    JoseHeader.. initVector.encryptedPem.AuthTag

4

Öppna TShell på enheten och kör kommandot (multiline) add: 

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 Visa

Kopiera det nya certifikatets fingeravtryck.

6

Aktivera certifikatet för ändamålet Web ExIdentity:

  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 byte, och base64url kodar den sekvensen. Det här är ditt salt.

  3. Härleda en innehållskrypteringsnyckel med ditt scrypt-verktyg.

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

  4. Skapa en slumpmässig sekvens på exakt 12 byte, och base64url kodar den sekvensen. Detta är din initialiseringsvektor.

  5. Skapa en JOSE-rubrik, ange alg-, enc - och cisco-kdf- nycklar enligt beskrivningen i För stå extern identitet sprocess för enheter. Ställ in åtgärden ”aktivera” med hjälp av nyckel:value ”cisco-action” :"aktivera” i JOSE-rubriken (eftersom vi aktiverar certifikatet på enheten).

  6. Base64URL kodar JOSE-rubriken.

  7. Använd ditt JWE-krypteringsverktyg med den valda krypteringen och den base64url-kodade JOSE-rubriken för att kryptera certifikatets fingeravtryck.

    Verktyget ska mata ut en sekvens på 16 eller 32 byte, beroende på om du valde 128 eller 256 bitars AES-GCM, och en autentiseringstagg.

  8. base64URLEnkoda det krypterade fingeravtrycket och autentiseringstaggen.

  9. Konstruera JWE-blob enligt följande (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, redo att användas för att identifiera det i end-to-end-krypterade Webex-möten.
7

Ombord enheten till din Control Hub-organisation.

Testa end-to-end-kryptering med identitetsverifiering
1

Schemalägg ett möte av rätt typ (Webex MeetingsPro-End to End Encryption_ VoipOnly).

Se S chemalägg ett Webex-möte med end-to-end-kryptering.

2

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

Se Gå med i ett Webex-möte med end-to-end-kryptering.

3

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

4

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

Se Gå med i ett Webex-möte med end-to-end-kryptering.

5

Gå med i mötet från en enhet vars identitet har verifierats av en extern certifikatutfärdare.

6

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

7

Gå med i mötet som en oautentiserad mötesdeltagare.

8

Som värd, verifiera att den här deltagaren visas i lobbyn med rätt identitetsikon.

9

Som värd, erkänna eller avvisa 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

Gå med i mötet med en ny deltagare.

13

Kontrollera att alla ser samma, nya säkerhetskod för möten.

Ställ in omfattning och förväntningar

  • Ska du göra end-to-end-krypterade möten till standardmötesalternativet, eller aktivera det bara för vissa användare, eller låta alla värdar bestämma? När du har bestämt hur du ska använda den här funktionen, förbered de användare som kommer att använda den, särskilt med avseende på begränsningarna och vad du kan förvänta dig i mötet.

  • Behöver du se till att varken Cisco eller någon annan kan dekryptera ditt innehåll eller utge dig för att vara dina enheter? Om så är fallet behöver du certifikat från en offentlig certifikatutfärdare.

  • Om du har olika nivåer av identitetsverifiering, ge användarna möjlighet att verifiera varandra med certifikatstödd identitet. Även om det finns omständigheter där deltagare kan visas som Overifierade, och deltagarna bör veta hur man kontrollerar, kanske obekräftade personer inte är bedragare.

Identitetshantering

Om du använder en extern certifikatutfärdare för att utfärda dina enhetscertifikat är det upp till dig att övervaka, uppdatera och återanvända certifikat.

Om du skapade den ursprungliga hemligheten, förstå att dina användare kanske vill ändra enhetens hemlighet. Du kan behöva skapa ett gränssnitt/distribuera ett verktyg för att göra det möjligt för dem att göra detta.

Sessionstyp-ID
Tabell 1. Sessionstyp-ID:n för end-to-end-krypterade möten

Sessionstyp-ID

Namn på offentlig tjänst

638

Endast E2E-kryptering+VoIP

652

End-till-slut-kryptering_VoipOnly

660

Pro 3 Free-End-to-End Encryption_VoipOnly

E2E-kryptering+Identitet

672

Pro 3 Free50-änd-till-slut-kryptering_VoipOnly

673

Utbildningsinstruktör E2E Encryption_VoipOnly

676

Broadworks Standard plus slut-till-slut-kryptering

677

Broadworks Premium plus slut-till-slut-kryptering

681

Schoology Free plus slut-till-änd-kryptering

Relaterade XAPI-kommandon

Dessa tabeller beskriver API-kommandon för Webex-enheter som vi har lagt till för end-to-end-krypterade möten och verifierad identitet. Mer information om hur du använder API:et finns i Å tkomst till API för enheter i Board, Desk och Room Series.

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

  • Registrerad till Webex

  • Registrerad lokalt och länkad 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-anrop

Beskrivning

XConfiguration Conference EndToEndEncryption Identity PreferredDomain: ”example.com”

Den här konfigurationen görs när administratören ställer in enhetens föredragna domän från Control Hub. Endast nödvändigt om organisationen har mer ä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 utfärdat certifikat för att identifiera sig själv.

Tillgänglighet för XStatus Conference EndToEndEncryption

Anger om enheten kan ansluta till ett end-to-end-krypterat möte. Cloud API anropar det så att en ihopkopplad app vet om den kan använda enheten för att gå med.

XStatus Conference EndToEndEncryption ExternalIdentity Verification

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

XStatus Conference EndToEndEncryption ExternalIdentity Identity

Enhetens identitet som lästs från det externt utfärdade certifikatets gemensamma 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 en av:

  • Fingeravtryck

  • NotAfter Giltighetens slut datum

  • NotBefore Gil tighetens startdatum

  • Primärt namn

  • PublicKeyAlgoritm

  • Serienummer

  • SignaturAlgoritm

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

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

XStatus Conference EndToEndeCryption ExternalIdentity Status

Statusen för enhetens externa identitet (t.ex. giltig eller felaktig).

XStatus Conference EndToEndEncryption InternalIdentity Verification

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

XStatus Conference EndToEndEncryption InternalIdentity Identity

Enhetens identitet som lästs från det Webex-utfärdade certifikatets gemensamma 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 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 en av:

  • Fingeravtryck

  • NotAfter Giltighetens slut datum

  • NotBefore Gil tighetens startdatum

  • Primärt namn

  • PublicKeyAlgoritm

  • Serienummer

  • SignaturAlgoritm

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

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

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

API-anrop

Beskrivning

xEvent KonferensdeltagareLista deltagareTillagt

XEvent KonferensdeltagareLista deltagareUppdaterad

xEventkonferensdeltagareLista deltagareBorttagen

Dessa tre händelser inkluderar nu EndToEndenCryptionStatus, EndToEndenCryptionIdentity och EndToEndenCryption Cert Info för den drabbade deltagaren.

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

API-anrop

Beskrivning

XCommand Security ClientSecret Fyll i hemlighet: ”base64url-kodad”

eller

XCommand Security ClientSecret Fyll hemlighet: JWeBlob

Accepterar ett base64url-kodat vanligt textvärde för att sätta klientens hemlighet 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-blob som innehåller den nya hemligheten krypterad av den gamla hemligheten.

XCommand Security Certificates Services Lägg till JWEblob

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

Vi utökade detta kommando för att acceptera en JWE-blob som innehåller krypterade PEM-data.

XCommand Security Certificates Services Aktivera syfte:WebExIdentity FingerPrint: JWEblob

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

XCommand Security Certificates Services Inaktivera syfte:WebExIdentity FingerPrint: JWEblob

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

Var den här artikeln användbar?
Var den här artikeln användbar?
PrissättningWebex-appenMötenCallingMeddelandenSkärmdelning
Webex SuiteCallingMötenMeddelandenSlidoWebbseminarierEventsContact CenterCPaaSSäkerhetControl Hub
HeadsetKamerorSkrivbordsserieRoom-serienBoard-serienTelefonserienTillbehör
UtbildningHälso- och sjukvårdStatliga myndigheterEkonomiSport och nöjeFrontlinjeIdeella organisationerNystartade företagHybridarbete
HämtningarDelta i ett testmöteOnlinekurserIntegreringarHjälpmedelInklusivitetWebbseminarier live och på begäranWebex CommunityWebex för utvecklareNyheter och innovationer
CiscoKontakta supportKontakta försäljningsavdelningenWebex BlogWebex tankeledarskapWebex Merch StoreJobba hos oss
  • X
  • LinkedIn
  • Facebook
  • Youtube
  • Instagram
VillkorSekretesspolicyCookiesVarumärken
©2026 Cisco och/eller dess dotterbolag. Med ensamrätt.
VillkorSekretesspolicyCookiesVarumärken