Användare väljer mötestyp när de schemalägger ett möte. När du släpper in deltagare från lobbyn, såväl som under mötet, kan värden se identitetsverifieringsstatus för varje deltagare. Det finns också en möteskod som är gemensam för alla aktuella mötesdeltagare, som de kan använda för att verifiera varandra.

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

Verifiera identiteten

Kryptering från slutpunkt till slutpunkt med identitetsverifiering ger ytterligare säkerhet för ett krypterat möte från slutpunkt till slutpunkt.

När deltagare eller enheter deltar 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 CA deltagarnas identitet och mötet visar deltagarna/enheterna som verifierade.

Webex-appanvändare autentiserar sig mot Webex-identitetsarkivet, vilket ger dem en åtkomsttoken när autentiseringen lyckas. Om de behöver ett certifikat för att verifiera sin identitet i ett krypterat möte från slutpunkt till slutpunkt utfärdar Webex CA ett certifikat baserat på deras åtkomsttoken. För närvarande tillhandahåller vi inget sätt för Webex Meetings användare att få ett certifikat som utfärdats av en tredjeparts/extern certifikatutfärdare.

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

  • Intern certifikatutfärdare – 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 har, 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 vald utfärdaren. Du måste kryptera, överföra och auktorisera certifikaten med hjälp av en hemlighet som endast du känner till.

    Cisco är inte inblandat, vilket gör detta till ett sätt att garantera äkta end-to-end-kryptering och verifierad identitet, samt förhindra den teoretiska möjligheten att Cisco kan avlyssna 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 också använda API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Om du har flera domäner och inte anger den prioriterade domänen 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, men det kan signeras med en RSA-nyckel.

Värdena i certifikatet bestäms av organisationen. Common Name (CN) och Alternativt ämnesnamn (SAN) kommer att visas i Webex-möte 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 ett unikt CN per enhet. Till exempel ”mötesrum-1.example.com” för den organisation som äger domänen ”example.com”.

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

När du använder klienthemligheten är det möjligt att säkert 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.

Enheter

Följande molnregistrerade enheter i Webex Room-serien och Webex Desk-serien kan delta i krypterade möten från slutpunkt till slutpunkt:

  • Webex Board

  • Webex Desk Pro

  • Webex-skrivbord

  • Webex Room-paket

  • Webex Room Kit Mini

Följande enheter kan inte delta i krypterade möten från slutpunkt till slutpunkt:

  • Webex C-serien

  • Webex DX-serien

  • Webex EX-serien

  • Webex MX-serien

  • SIP-enheter från tredje part

Programklienter
  • Från och med version 41.6 kan Webex Meetings -skrivbordsklienten delta i krypterade möten från slutpunkt till slutpunkt.

  • Om din organisation tillåter att Webex-app deltar i möten genom att starta skrivbordsprogrammet Meetings kan du använda det alternativet för att delta i krypterade möten från slutpunkt till slutpunkt.

  • Webex-webbklienten kan inte delta i krypterade möten från slutpunkt till slutpunkt.

  • Tredjeparts-SIP-programklienter kan inte delta i krypterade möten från slutpunkt till slutpunkt.

Identitet
  • Genom designen tillhandahåller vi inga Control Hub-alternativ för dig att hantera externt verifierad enhetsidentitet. För äkta kryptering från slutpunkt till slutpunkt bör endast du känna till/åtkomst till hemligheterna och nycklarna. Om vi införde en molntjänst för att hantera nycklarna finns det en risk för att de kan avlyssnas.

  • För närvarande tillhandahåller vi ett ”recept” så att du kan designa dina egna verktyg, baserade på krypteringstekniker enligt branschstandard, för att hjälpa dig att begära eller kryptera dina enhets-ID och deras privata nycklar. Vi vill inte ha någon verklig eller uppfattad tillgång till dina hemligheter eller nycklar.

Möten
  • Möten med krypterad slutpunkt till slutpunkt har för närvarande plats för högst 200 deltagare.

  • Av de 200 deltagarna kan högst 25 externt verifierade enheter delta, och de måste vara de första deltagarna som deltar i mötet .

    När ett större antal enheter deltar i ett möte försöker våra back-end medietjänster koda om medieströmmarna. Om vi inte kan dekryptera, omkoda och omkryptera media (eftersom vi inte har eller bör ha enhetens krypteringsnycklar) misslyckas kodningen.

    För att mildra den här begränsningen rekommenderar vi mindre möten för enheter eller dela inbjudningarna mellan enheter och Meetings-klienter.

Hantering gränssnitt

Vi rekommenderar starkt att du använder Control Hub för att hantera din möteswebbplats, eftersom Control Hub-organisationer har en centraliserad identitet för hela organisationen, och i Webbplatsadministration kontrolleras identiteten plats för webbplats.

Användare som hanteras från Webbplatsadministration kan inte ha alternativet Cisco-verifierad identitet. Dessa användare får ett anonymt certifikat för att delta i ett krypterat möte från slutpunkt till slutpunkt, och de kan uteslutas från möten där värden vill säkerställa identitetsverifiering.

  • Webex Meetings 41.7.

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

  • Administratörsåtkomst till mötesplatsen i Control Hub för att aktivera den nya sessionstyp för användare.

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

  • Mötesrum för samarbete måste vara aktiverat så att personer kan delta från sitt videosystem. Mer information finns i Tillåt videosystem att delta i möten och händelser på din Webex-plats .

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

För högsta möjliga säkerhetsnivå och för identitetsverifiering bör varje enhet ha ett unikt certifikat som utfärdats av en betrodd offentlig Certifikatsauktoritet (CA).

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

  • Certifikatet måste vara utfärdat och signerat av en välkänd offentlig certifikatutfärdare.

  • Unikt: 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 säkerheten.

  • Allmänt namn (CN) och alternativa ämnesnamn (SAN/n): Dessa är inte viktiga för Webex, utan bör vara värden som människor kan läsa och associera med enheten. CN visas för andra mötesdeltagare som den primära verifierade identiteten för enheten, och om användare kontrollerar certifikatet via mötet UI ser de SAN/s. Du kanske vill använda namn som t.ex name.model@example.com.

  • Filformat: Certifikaten och nycklarna måste finnas i .pem format.

  • Syfte: Certifikatets syfte måste vara Webex-identitet.

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

    Detta krav omfattar inte signeringsnyckeln. CA kan använda en RSA-nyckel för att signera certifikatet.

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

Om du använder nya enheter ska du inte registrera dem till Webex än. För säkerhets skull ska du inte ansluta dem 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 återställa fabriksinställningarna.

  • 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 stegvis tillvägagångssätt. Meddela användarna vilka ändringar de kan förvänta sig.

  • Säkerställ fysisk åtkomst till enheter. Om du måste komma åt enheter via nätverket ska du tänka på att hemligheter sprids i vanlig text och att du äventyrar din säkerhet.

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

För att säkerställa att ditt enhetsmedie 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 verklig kryptering från slutpunkt till slutpunkt via vårt moln kan vi inte vara inblandade i kryptering och uppladdning av certifikatet och nyckeln. Om du behöver den här säkerhetsnivån måste du:

  1. Begär dina certifikat.

  2. Generera dina certifikats nyckelpar.

  3. Skapa (och skydda) en initial hemlighet för varje enhet för att se enhetens krypteringsfunktion.

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

    Processen och de (icke-hemliga) parametrarna du behöver förklaras nedan, samt ett recept som du kan följa i ditt val av utvecklingsverktyg. Vi tillhandahåller även vissa 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 finns tillgänglig från Cisco på begäran.

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

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

  7. Ange syftet med det krypterade certifikatet som ska användas för Webex-identitet 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 media från dig.

Hur vi använder JWE-formatet

Det här avsnittet beskriver hur vi förväntar oss att JWE skapas som indata till enheterna, så att du kan bygga ditt eget verktyg för att skapa blobbar från dina certifikat och nycklar.

Se JSON-webbkryptering (JWE)https://datatracker.ietf.org/doc/html/rfc7516och JSON-webbsignatur (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Vi använder Kompakt serialisering i ett JSON-dokument för att skapa JWE-blobbar. Parametrarna du behöver inkludera när du skapar JWE-blobbarna är:

  • Sidhuvud för JOSE (skyddad). I rubriken JSON-objektsignering och kryptering MÅSTE du inkludera följande nyckel-värdepar:

    • "alg":"dir"

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

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

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

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

      Det här är en patentskyddad nyckel och kan ha fyra värden. Vi introducerade den här nyckeln för att signalera syftet med den krypterade datan till målenheten. Värdena har fått sitt namn efter xAPI-kommandon på enheten där du använder krypterad data.

      Vi döpte den cisco-action för att mildra potentiella konflikter med framtida JWE-tillägg.

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

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

  • Krypterad JWE-nyckel . Fältet är tomt. Enheten härleder det från initialen ClientSecret.

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

  • JWE-chiffertext : Det här är den krypterade nyttolasten som du vill hålla hemlig.

    Nyttolasten KAN vara tom. För att till exempel återställa klienthemligheten måste du skriva över den med ett tomt värde.

    Det finns olika typer av nyttolaster, beroende på vad du försöker göra på enheten. Olika xAPI-kommandon förväntar sig olika nyttolast, och du måste ange syftet med nyttolasten med cisco-action nyckel enligt följande:

    • Med "cisco-action":"populate" chiffertexten är ny ClientSecret.

    • Med ” "cisco-action":"add" chiffreringstexten är en PEM-blobb som bär certifikatet och dess privata nyckel (konkatenerad).

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

    • Med ” "cisco-action":"deactivate" chiffreringstexten är 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 försäkra sig om integriteten för hela JWE-kompakt serialiserade blob

Hur vi härleder krypteringsnyckel från ClientSecret

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

Enhetsprogrammet använder klienthemligheten som en inmatning till en nyckelhärledningsfunktion (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 skapa JWE-blobbar måste följa samma procedur för att härleda samma krypterings-/avkrypteringsnyckel från klienthemligheten.

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

  • Kostnadsfaktor (N) är 32768

  • BlockSizeFactor (r) är 8

  • Parallelliseringsfaktor (p) är 1

  • Salt är en slumpmässig sekvens på minst 4 byte; du måste tillhandahålla densamma salt när du anger cisco-kdf parametern.

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

  • Max minneskapacitet är 64MB

Denna uppsättning parametrar är den enda konfigurationen av krypt som är kompatibel med tangenthärledningsfunktionen på enheterna. Denna kdf på enheterna anropas "version":"1", vilket är den enda version som för närvarande används 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-blobb på enheten (liknar tillägg av ett certifikat, med en mycket kort sträng istället för en fullständig cert + nyckel). Klienthemligheten i exemplet är ossifrage.

  1. Välj ett krypteringschiffer. I det här exemplet används A128GCM(AES med 128-bitars nycklar i Galois-räknelä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 F6. Base64url kodar sekvensen som ska hämtas 5eZTCAP4M_Y(ta bort base64-stoppningen).

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

    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 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 base64url kodar till NLNd3V9Te68tkpWD.

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

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

    Den base64url-kodade JOSE-rubriken är eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Detta blir det första inslaget i JWE-blobben.

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

  7. Det tredje elementet i JWE-blobben ä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-blobben this is a PEM file

    De krypteringsparametrar du bör använda är:

    • Nyttolasten är this is a PEM file

    • Krypteringschifferet ä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-blobben.

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

    Detta är det femte elementet i JWE-blobben.

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.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 för dina enheter.

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

    xCommand Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..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 Pro-End to End Encryption_VOIPonly. Detta är namnet på allmännyttiga tjänster, som vi kan ändra i framtiden. De aktuella namnen på sessionstyperna finns i ID:n för sessionstyp i 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 individuellt via användarens konfigurationssida eller samtidigt med en CSV-export/ -import.

1

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

2

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

3

Under Allmänna inställningar , välj Sessionstyper .

4
Du bör se en eller flera sessionstyper för kryptering från slutpunkt till slutpunkt. Se listan över ID:n för sessionstyp i Referens i den här artikeln. Du kan till exempel se Pro-End to End Encryption_ Endast VoIP .

 

Det finns en äldre sessionstyp med ett mycket liknande namn: Professionell kryptering från slutpunkt till slutpunkt . Den här sessionstyp inkluderar icke-krypterad PSTN-åtkomst till möten. Se till att du har_ Endast VoIP version för att säkerställa kryptering från slutpunkt till slutpunkt. Du kan kontrollera genom att hålla muspekaren över PRO länk 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.

5

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

Nästa steg

Aktivera den här sessionstyp /mötesprivilegierna för några eller alla dina 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 to End Encryption_ Endast VoIP .

5

Stäng panelen för användarkonfiguration .

6

Upprepa för andra användare vid behov.

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 .

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 manuellt stänga popup-fönstret när du har klickat Hämta .)

6

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

Det finns en rad för varje användare och MeetingPrivilege innehåller deras sessionstyp ID som en kommaseparerad lista.

7

För varje användare som du vill bevilja den nya sessionstyp lägger du till 1561 som ett nytt värde i den kommaseparerade listan i MeetingPrivilege cell.

Den Referens för Webex CSV-filformat innehåller information om syftet med och innehållet i CSV-fil.

8

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


 

Om du redan var på listsidan för möteswebbplatser kan du behöva uppdatera den.

9

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

10

Klicka på Importera och markera den redigerade CSV-filen. 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 kontrollera om det fanns några fel.

12

Gå till Användare och öppna en av användarna för att bekräfta att de har den nya sessionstyp.

Du kan lägga till en vattenstämpel i mötesinspelningar med Webex Meetings Pro-End to End Encryption_VOIPonly sessionstyp, som 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 ljudvattenstämplar i E2EE-möten
  1. Logga in på Control Hub, gå till Hantering och välj sedan Organisationsinställningar.
  2. I Mötesvattenstämplar sektionen slår du på Lägg till vattenstämpel för ljud .

    En tid efter att detta är aktiverat schemalägger användare möten med Webex Meetings Pro-End to End Encryption_VOIPonly Sessionstypen ser ett alternativ för digital vattenmärkning i avsnittet Säkerhet.

Ladda upp och analysera ett möte med vattenstämpel
  1. I Control Hub, under Övervakning , välj Felsökning .
  2. Klicka på Analys av vattenstämpel .
  3. Sök efter eller välj mötet i listan och klicka sedan på Analysera.
  4. I Analysera ljudvattenstämpel fönstret anger du ett namn för analysen.
  5. (Valfritt) Ange en anteckning för analysen.
  6. Dra och släpp ljudfilen som ska analyseras eller klicka Välj fil för att bläddra till ljudfilen.
  7. Klicka Nära.

    När analysen är klar visas den i listan över resultat på Analysera vattenstämpel sida.

  8. Välj mötet i listan för att se resultaten av analysen. Klicka påKnappen Hämta för att hämta resultaten.
Funktioner och begränsningar

Faktorer som är inblandade i att avkoda ett inspelat vattenmärke är avståndet mellan inspelningsenheten och den högtalare som släpper ut ljudet, ljudvolymen, miljöbuller 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.

Om dina enheter redan finns ombord i din Control Hub-organisation och du vill använda Webex CA för att automatiskt generera sina identifieringscertifikat behöver du inte återställa fabriksinställningarna för 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 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, vilket kan se fel ut för andra mötesdeltagare.

Innan du börjar

Om dina enheter inte har registrerats ännu följer du Registrera en enhet till Cisco Webex med API eller det lokala webbgränssnittet eller Molnbaserad introduktion för Board-, Desk- och Room-serien . Du bör även verifiera den eller 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 under Hantering , välj Enheter .

2

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

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.

Innan du börjar

Du behöver:

  • För att hämta ett CA-signerat certifikat och en privat nyckel, in .pem format för varje enhet.

  • För att läsa ämnet Förstå extern identitetsprocess för enheter , i Förbered del av den här artikeln.

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

  • Ett verktyg för att generera slumpmässiga bytesekvenser med given längd.

  • Ett verktyg för att base64url-koda byte eller text.

  • An scrypt genomförande.

  • Ett hemligt ord eller en hemlig fras för varje enhet.

1

Fyll i enhetens ClientSecret med en vanlig texthemlighet:

Första gången du fyller i Secret anger du det i vanlig text. Det är därför som 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 i Secret med frasen 0123456789abcdef. Du måste välja din egen.

Enheten har sin initiala hemlighet. Glöm inte detta; du kan inte återställa den och måste återställa enhetens fabriksinställningar för att starta igen.
2

Sammanfoga ditt certifikat och den privata nyckeln:

  1. Öppna .pem-filerna med en textredigerare, klistra in nyckelblobben i certifikatblobben och spara den som en ny .pem-fil.

    (Detta är nyttolasttexten som du kommer att kryptera och lägga i din JWE-blobb)

3

Skapa en JWE-blobb som ska användas som indata för certifikatkommandot:

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

  2. Härled en innehållskrypteringsnyckel med ditt krypteringsnyckel .

    För detta behöver du hemligheten, saltet och en nyckellängd som matchar ditt valda krypteringschiffer. 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.

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

  4. Skapa ett JOSE-huvud, inställning alg, enc och cisco-kdf nycklar enligt beskrivningen i Förstå extern identitetsprocess för enheter . Ställ in åtgärden ”lägg till” med nyckel:värde "cisco-action":"add" i JOSE-huvudet (eftersom vi lägger till certifikatet i enheten).

  5. Base64url kodar JOSE-huvudet.

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

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

  8. Konstruera JWE-blobben 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 Show

Kopiera det nya certifikatets fingeravtryck.

6

Aktivera certifikatet för ändamålet WebexIdentity:

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

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

  3. Härled en innehållskrypteringsnyckel med ditt krypteringsnyckel .

    För detta behöver du hemligheten, saltet och en nyckellängd som matchar ditt valda krypteringschiffer. 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.

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

  5. Skapa ett JOSE-huvud, inställning alg, enc och cisco-kdf nycklar enligt beskrivningen i Förstå extern identitetsprocess för enheter . Ställ in åtgärden ”aktivera” med nyckel:värde "cisco-action":"activate" i JOSE-rubriken (eftersom vi aktiverar certifikatet på enheten).

  6. Base64url kodar JOSE-huvudet.

  7. Använd ditt JWE-krypteringsverktyg med det valda chiffret och den base64url-kodade JOSE-rubriken 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 autentiseringstagg.

  8. Base64urlenkoda det krypterade fingeravtrycket och autentiseringstaggen.

  9. Konstruera JWE-blobben 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 som är redo att användas för att identifiera det i Webex-möten som krypteras från slutpunkt till slutpunkt.
7

Installera enheten till din Control Hub-organisation.

1

Schemalägg ett möte av rätt typ ( Webex Meetings Pro-ände till slut Encryption_ Endast VoIP ).

2

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

3

Delta i mötet från en enhet vars identitet har verifierats av Webex CA.

4

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

5

Delta i mötet från en enhet vars identitet har verifierats av en extern CA.

6

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

7

Delta i mötet som en icke-autentiserad mötesdeltagare.

8

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

9

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

10

Validera mötesdeltagar-/enhetsidentiteter om möjligt genom att kontrollera certifikaten.

11

Kontrollera att alla i mötet ser samma säkerhetskod.

12

Delta i mötet med en ny mötesdeltagare.

13

Kontrollera att samma nya mötessäkerhetskod visas för alla.

Kommer du att göra krypterade möten från slutpunkt till slutpunkt till standardmötesalternativ, aktivera det endast 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 förbereder du de användare som ska använda den, särskilt med avseende på begränsningarna och vad som kan förväntas under mötet.

Behöver du säkerställa att varken Cisco eller någon annan kan dekryptera ditt innehåll eller utge sig för att vara dina enheter? I så fall behöver du certifikat från en offentlig certifikatutfärdare. Du kan bara ha upp till 25 enheter i ett säkert möte. Om du behöver den här säkerhetsnivån bör du inte tillåta mötesklienter att delta.

För användare som deltar med säkra enheter ska du först låta enheter delta och ange förväntningar på att de kanske inte kan delta om de deltar sent.

Om du har olika nivåer av identitetsverifiering ger användare möjlighet att verifiera varandra med certifikatbaserad identitet och mötessäkerhetskoden. Även om det finns omständigheter där deltagare kan visas som ej verifierade, och deltagarna bör veta hur man kontrollerar, kan överifierade personer inte vara bedragare.

Om du använder en extern certifikatutfärdare för att utfärda dina enhetscertifikat åligger det dig att övervaka, uppdatera och tillämpa certifikat på nytt.

Om du skapade den ursprungliga hemligheten bör du förstå att dina användare kan vilja ändra sin enhets hemlighet. Du kan behöva skapa ett gränssnitt/distribuera ett verktyg för att de ska kunna göra detta.

Tabell 1. Sessionstyp-ID för möten som krypteras från slutpunkt till slutpunkt

ID för sessionstyp

Public Service-namn

638

Endast E2E-kryptering+VoIP

652

Pro-End to End Encryption_ Endast VoIP

660

Pro 3 Free-End to End Encryption_ Endast VoIP

E2E-kryptering + identitet

672

Pro 3 Free50-End to End Encryption_ Endast VoIP

673

Utbildningsinstruktör E2E Encryption_ Endast VoIP

676

Broadworks Standard plus slutpunkt-tillslut-kryptering

677

Broadworks Premium plus slutpunkt-till-slut-kryptering

681

Schoology Free plus slutpunkt-till-slut-kryptering

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

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

  • Registrerad på Webex

  • Registrerad på plats och länkad till Webex med Webex Edge för enheter

Tabell 2. API:er på systemnivå för krypterade möten 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 anger enhetens prioriterade 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 utfärdat certifikat för att identifiera sig själv.

xStatus Conference EndToEndEncryption Availability

Anger om enheten kan delta i ett krypterat möte från slutpunkt till slutpunkt. Molnet API anropar det så att en parkopplade 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 som lästs från det externt utfärdade certifikatets Common Name.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

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

Ersätt i kommandot som visas # med certifikatets nummer. Replace specificinfo med en av:

  • Fingerprint

  • NotAfter Slutdatum för giltighet

  • NotBefore Giltighetsstartdatum

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

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

  • Validity Anger giltighetsstatus för detta certifikat (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 som lästs från det Webex-utfärdade certifikatets Common Name.

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.

Ersätt i kommandot som visas # med certifikatets nummer. Replace specificinfo med en av:

  • Fingerprint

  • NotAfter Slutdatum för giltighet

  • NotBefore Giltighetsstartdatum

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

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

  • Validity Anger giltighetsstatus för detta certifikat (t.ex valid eller expired)

Tabell 3. API:er i samtal för krypterade möten från slutpunkt till slutpunkt och verifierad identitet

API-samtal

Beskrivning

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

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

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

API-samtal

Beskrivning

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

eller

xCommand Security ClientSecret Populate Secret: JWEblob

Godkänner ett base64url-kodat oformaterad textvärde för att visa klienthemligheten på enheten för första gången.

För att uppdatera hemligheten efter den första gången måste du ange en JWE-blobb 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 utökade detta kommando för att acceptera en JWE-blobb som innehåller krypterad 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 det identifierande fingeravtrycket krypteras och serialiseras i en JWE-blobb.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

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