Gebruikers kiezen het vergaderingstype wanneer ze een vergadering plannen. Bij het toelaten van deelnemers vanuit de lobby en tijdens de vergadering kan de host de identiteitsverificatiestatus van elke deelnemer zien. Er is ook een vergaderingscode die voor alle huidige deelnemers aan de vergadering geldt en die ze kunnen gebruiken om elkaar te verifiëren.

Deel de volgende informatie met uw vergaderingshosts:

Identiteit verifiëren

End-to-end-codering met identiteitsverificatie biedt extra beveiliging voor een end-to-end-gecodeerde vergadering.

Wanneer deelnemers of apparaten deelnemen aan een gedeelde MLS-groep (Messaging Layer Security), presenteren ze hun certificaten aan de andere groepsleden, die de certificaten vervolgens valideren tegen de uitgevende certificeringsinstanties (CA). Door te bevestigen dat de certificaten geldig zijn, verifieert de CA de identiteit van de deelnemers en geeft de vergadering de deelnemers/apparaten weer als geverifieerd.

Gebruikers van de Webex -app verifiëren zichzelf met het Webex -identiteitsarchief, dat hen een toegangstoken geeft wanneer de verificatie is geslaagd. Als ze een certificaat nodig hebben om hun identiteit te verifiëren in een end-to-end-gecodeerde vergadering, geeft de Webex -CA hun een certificaat uit op basis van hun toegangstoken. Op dit moment bieden we Webex Meetings -gebruikers geen manier om een certificaat te verkrijgen dat is uitgegeven door een externe/externe certificeringsinstantie.

Apparaten kunnen zichzelf verifiëren met een certificaat dat is uitgegeven door de interne (Webex) CA of een certificaat dat is uitgegeven door een externe CA:

  • Interne CA : Webex geeft een intern certificaat uit op basis van het toegangstoken van het computeraccount van het apparaat. Het certificaat is ondertekend door de Webex CA. Apparaten hebben geen gebruikers-id's op dezelfde manier als gebruikers, dus Webex gebruikt (een van) de domeinen van uw organisatie bij het schrijven van de identiteit van het apparaatcertificaat (Algemene naam (CN)).

  • Externe CA: vraag en koop apparaatcertificaten rechtstreeks bij de door u gekozen uitgever. U moet de certificaten coderen, rechtstreeks uploaden en autoriseren met een geheim dat alleen aan u bekend is.

    Cisco is er niet bij betrokken, waardoor dit de manier is om echte end-to-end-codering en geverifieerde identiteit te garanderen en de theoretische mogelijkheid te voorkomen dat Cisco uw vergadering zou afluisteren of uw media zou kunnen decoderen.

Intern uitgegeven apparaatcertificaat

Webex geeft een certificaat uit aan het apparaat wanneer het wordt geregistreerd na het opstarten en vernieuwt het wanneer dat nodig is. Voor apparaten bevat het certificaat de account Id en een domein.

Als uw organisatie geen domein heeft, geeft de Webex CA het certificaat uit zonder domein.

Als uw organisatie meerdere domeinen heeft, kunt u Control Hub gebruiken om Webex te laten weten welk domein het apparaat moet gebruiken voor de identiteit. U kunt ook de API gebruiken xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Als u meerdere domeinen hebt en niet het voorkeursdomein voor het apparaat instelt, kiest Webex er een voor u.

Extern uitgegeven apparaatcertificaat

Een beheerder kan een apparaat inrichten met een eigen certificaat dat is ondertekend met een van de openbare CA's.

Het certificaat moet zijn gebaseerd op een ECDSA P-256-sleutelpaar, hoewel het kan worden ondertekend met een RSA -sleutel.

De waarden in het certificaat zijn ter beoordeling van de organisatie. De Common Name (CN) en de Onderwerp alternatieve naam (SAN) worden weergegeven in de gebruikersinterface van de Webex-vergadering , zoals beschreven in End-to-end-codering met identiteitsverificatie voor Webex Meetings .

We raden u aan een afzonderlijk certificaat per apparaat te gebruiken en een unieke CN per apparaat te hebben. Bijvoorbeeld 'vergaderruimte-1.example.com' voor de organisatie die eigenaar is van het domein 'example.com'.

Om het externe certificaat volledig te beschermen tegen manipulatie, wordt een clientgeheime functie gebruikt om verschillende x-opdrachten te coderen en te ondertekenen.

Wanneer u het clientgeheim gebruikt, is het mogelijk om het externe Webex -identiteitscertificaat veilig te beheren via de xAPI. Dit is momenteel beperkt tot online apparaten.

Webex biedt momenteel API -opdrachten om dit te beheren.

Apparaten

De volgende in de cloud geregistreerde Webex Room Series- en Webex Desk Series-apparaten kunnen deelnemen aan end-to-end versleutelde vergaderingen:

  • Webex Board

  • Webex Desk Pro

  • Webex-bureau

  • Webex Room Kit

  • Webex Room Kit Mini

De volgende apparaten kunnen niet deelnemen aan end-to-end-versleutelde vergaderingen:

  • Webex C-serie

  • Webex DX-serie

  • Webex EX-serie

  • Webex MX-serie

  • SIP -apparaten van derden

Softwareclients
  • Vanaf versie 41.6 kan de Webex Meetings -bureaubladclient deelnemen aan end-to-end versleutelde vergaderingen.

  • Als uw organisatie de Webex-app om deel te nemen aan vergaderingen door de Meetings-bureaubladtoepassing te starten, kunt u die optie gebruiken om deel te nemen aan end-to-end versleutelde vergaderingen.

  • De Webex -webclient kan niet deelnemen aan end-to-end versleutelde vergaderingen.

  • SIP -softclients van derden kunnen niet deelnemen aan end-to-end versleutelde vergaderingen.

Identiteit
  • Door het ontwerp bieden we geen Control Hub-opties waarmee u extern geverifieerde apparaatidentiteit kunt beheren. Voor echte end-to-end-versleuteling moet alleen u de geheimen en sleutels kennen/toegang hebben. Als we een cloudservice hebben geïntroduceerd om deze sleutels te beheren, bestaat de kans dat ze worden onderschept.

  • Momenteel bieden we u een 'recept' waarmee u uw eigen hulpprogramma's kunt ontwerpen, op basis van industriestandaard versleutelingstechnieken, om u te helpen bij het aanvragen of versleutelen van de identiteitscertificaten van uw apparaat en hun persoonlijke sleutels. We willen geen echte of vermeende toegang tot uw geheimen of sleutels.

Vergaderingen
  • End-to-end versleutelde vergaderingen ondersteunen momenteel maximaal 200 deelnemers.

  • Van die 200 deelnemers kunnen maximaal 25 extern geverifieerde apparaten deelnemen moeten de eerste deelnemers zijn die deelnemen aan de vergadering .

    Wanneer een groter aantal apparaten deelneemt aan een vergadering, proberen onze back-endmediaservices de mediastreams te transcoderen. Als we de media niet kunnen decoderen, transcoderen en opnieuw coderen (omdat we de coderingssleutels van de apparaten niet hebben en niet mogen hebben), mislukt de transcodering.

    Als u deze beperking wilt beperken, raden we u aan kleinere vergaderingen voor apparaten te houden of de uitnodigingen te spreiden tussen apparaten en Meetings-clients.

Beheerinterface

We raden u ten zeerste aan Control Hub te gebruiken om uw vergaderingssite te beheren, aangezien Control Hub-organisaties een gecentraliseerde identiteit voor de hele organisatie hebben, terwijl in Sitebeheer de identiteit per site wordt beheerd.

Gebruikers die worden beheerd via Sitebeheer kunnen niet beschikken over de door Cisco geverifieerde identiteitsoptie. Deze gebruikers krijgen een anoniem certificaat om deel te nemen aan een end-to-end-gecodeerde vergadering en kunnen worden uitgesloten van vergaderingen waarbij de host identiteitsverificatie wil garanderen.

  • Webex Meetings 41.7.

  • In de cloud geregistreerde Webex Room- en Webex Desk-apparaten, actief 10.6.1-RoomOS_August_2021.

  • Beheerderstoegang tot de vergaderlocatie in Control Hub om het nieuwe Sessietype voor gebruikers in te schakelen.

  • Een of meer geverifieerde domeinen in uw Control Hub-organisatie (als u de Webex -CA gebruikt om apparaatcertificaten uit te geven voor geverifieerde identiteit).

  • Samenwerkingsvergaderruimten moeten zijn ingeschakeld zodat mensen kunnen deelnemen vanuit hun videosysteem. Zie voor meer informatie Toestaan dat videosystemen deelnemen aan vergaderingen en gebeurtenissen op uw Webex-site .

U kunt deze stap overslaan als u geen extern geverifieerde identiteiten nodig hebt.

Voor het hoogste beveiligingsniveau en voor identiteitsverificatie moet elk apparaat een uniek certificaat hebben dat is uitgegeven door een vertrouwde openbare Certificate Authority (CA).

U moet communiceren met de CA om de digitale certificaten aan te vragen, aan te schaffen en te ontvangen en om de bijbehorende persoonlijke sleutels te maken. Gebruik deze parameters wanneer u het certificaat aanvraagt:

  • Het certificaat moet zijn uitgegeven en ondertekend door een bekende openbare CA.

  • Uniek: We raden u ten zeerste aan voor elk apparaat een uniek certificaat te gebruiken. Als u één certificaat voor alle apparaten gebruikt, brengt u uw beveiliging in gevaar.

  • Algemene naam (CN) en alternatieve naam(en) onderwerp (SAN/s): Deze zijn niet belangrijk voor Webex, maar moeten waarden zijn die mensen kunnen lezen en koppelen aan het apparaat. De CN wordt aan andere deelnemers aan de vergadering weergegeven als de primaire geverifieerde identiteit van het apparaat. Als gebruikers het certificaat inspecteren via de gebruikersinterface van de vergadering, zien ze de SAN/s. U kunt namen als . gebruiken name.model@example.com.

  • Bestandsindeling: De certificaten en sleutels moeten zich in de .pem formaat.

  • Doel: Het doel van het certificaat moet Webex -identiteit zijn.

  • Sleutels genereren: De certificaten moeten zijn gebaseerd op ECDSA P-256-sleutelparen (Elliptical Curve Digital Signature Algorithm met behulp van de P-256-curve).

    Deze vereiste geldt niet voor de ondertekeningssleutel. De CA kan een RSA sleutel gebruiken om het certificaat te ondertekenen.

U kunt deze stap overslaan als u geen extern geverifieerde identiteit voor uw apparaten wilt gebruiken.

Als u nieuwe apparaten gebruikt, moet u deze nog niet registreren bij Webex . Maak voor de zekerheid nog geen verbinding met het netwerk.

Als u bestaande apparaten hebt die u wilt upgraden om een extern geverifieerde identiteit te gebruiken, moet u de apparaten terugzetten op de fabrieksinstellingen.

  • Sla de bestaande configuratie op als u deze wilt behouden.

  • Plan een venster wanneer de apparaten niet worden gebruikt, of gebruik een gefaseerde aanpak. Stel gebruikers op de hoogte van de wijzigingen die ze kunnen verwachten.

  • Zorg voor fysieke toegang tot apparaten. Als u toegang moet krijgen tot apparaten via het netwerk, moet u er rekening mee houden dat geheimen in platte tekst worden verzonden en dat u uw beveiliging in gevaar brengt.

Nadat u deze stappen hebt voltooid, videosystemen toestaan deel te nemen aan vergaderingen en gebeurtenissen op uw Webex-site .

Om ervoor te zorgen dat uw apparaatmedia alleen door het apparaat kan worden versleuteld, moet u de persoonlijke sleutel op het apparaat versleutelen. We hebben API's voor het apparaat ontworpen om het beheer van de gecodeerde sleutel en het certificaat mogelijk te maken, met behulp van JSON Web Encryption (JWE).

Om echte end-to-end-codering via onze cloud te garanderen, mogen we niet betrokken zijn bij het coderen en uploaden van het certificaat en de sleutel. Als u dit beveiligingsniveau nodig hebt, moet u:

  1. Vraag uw certificaten aan.

  2. Genereer de sleutelparen van uw certificaten.

  3. Maak (en beveilig) een initieel geheim voor elk apparaat om de versleutelingscapaciteit van het apparaat te zaaien.

  4. Ontwikkel en onderhoud uw eigen tool voor het coderen van bestanden met behulp van de JWE-standaard.

    Het proces en de (niet-geheime) parameters die u nodig hebt, worden hieronder uitgelegd, evenals een recept dat u kunt volgen in uw ontwikkeltools naar keuze. We bieden ook enkele testgegevens en de resulterende JWE-blobs zoals we ze verwachten, om u te helpen uw proces te verifiëren.

    Een niet-ondersteunde referentie-implementatie met Python3 en de JWCrypto-bibliotheek is op aanvraag verkrijgbaar bij Cisco .

  5. Voeg het certificaat en de sleutel samen en versleutel ze met uw hulpprogramma en het aanvankelijke geheim van het apparaat.

  6. Upload de resulterende JWE-blob naar het apparaat.

  7. Stel het doel in van het versleutelde certificaat dat moet worden gebruikt voor de Webex identiteit en activeer het certificaat.

  8. (Aanbevolen) Zorg voor een interface voor (of distribueer) van uw hulpprogramma zodat apparaatgebruikers het oorspronkelijke geheim kunnen wijzigen en hun media tegen u kunnen beschermen.

Hoe we de JWE-indeling gebruiken

In deze sectie wordt beschreven hoe we verwachten dat de JWE wordt gemaakt als invoer voor de apparaten, zodat u uw eigen hulpprogramma kunt bouwen om de blobs te maken op basis van uw certificaten en sleutels.

Raadpleeg JSON- Web (JWE)https://datatracker.ietf.org/doc/html/rfc7516en JSON- Web (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

We gebruiken de Compacte serialisatie van een JSON-document om JWE-blobs te maken. De parameters die u moet opnemen bij het maken van de JWE-blobs zijn:

  • JOSE-koptekst (beveiligd). In de koptekst JSON-objectondertekening en -codering MOET u de volgende sleutel-waardeparen opnemen:

    • "alg":"dir"

      Het directe algoritme is het enige dat we ondersteunen voor het versleutelen van de payload. U moet het oorspronkelijke clientgeheim van het apparaat gebruiken.

    • "enc":"A128GCM" of "enc":"A256GCM"

      We ondersteunen deze twee versleutelingsalgoritmen.

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

      Dit is een eigen sleutel en kan vier waarden aannemen. We hebben deze sleutel geïntroduceerd om het doel van de versleutelde gegevens door te geven aan het doelapparaat. De waarden zijn genoemd naar de xAPI-opdrachten op het apparaat waarop u de versleutelde gegevens gebruikt.

      We noemden het cisco-action om mogelijke botsingen met toekomstige JWE-extensies te beperken.

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

      Een andere eigen sleutel. We gebruiken de waarden die u opgeeft als invoer voor het afleiden van sleutels op het apparaat. Het version moet zijn 1(de versie van onze belangrijkste afleidingsfunctie). De waarde van salt moet een base64 URL-gecodeerde reeks van ten minste 4 bytes zijn, die u moet willekeurig kiezen.

  • Gecodeerde JWE-sleutel . Dit veld is leeg. Het apparaat leidt het af van de initiaal ClientSecret.

  • JWE-initialisatievector . U moet een met base64url gecodeerde initialisatievector opgeven voor het decoderen van de payload. De IV MOET een willekeurige waarde van 12 bytes zijn (we gebruiken de AES-GCM-coderingsfamilie, waarvoor de IV 12 bytes lang moet zijn).

  • JWE AAD (aanvullende geverifieerde gegevens). U moet dit veld weglaten omdat het niet wordt ondersteund in Compacte serialisatie.

  • JWE-versleutelde tekst : Dit is de versleutelde payload die u geheim wilt houden.

    De payload MOGELIJK leeg zijn. Als u bijvoorbeeld het clientgeheim opnieuw wilt instellen, moet u dit overschrijven met een lege waarde.

    Er zijn verschillende soorten payloads, afhankelijk van wat u op het apparaat probeert te doen. Verschillende xAPI-opdrachten verwachten verschillende payloads en u moet het doel van de payload opgeven met de cisco-action toets, als volgt:

    • Met "cisco-action":"populate" de cijfertekst is het nieuwe ClientSecret.

    • Met ' "cisco-action":"add" de cijfertekst is een PEM-blob met het certificaat en de bijbehorende persoonlijke sleutel (aaneengeschakeld).

    • Met ' "cisco-action":"activate" de cijfertekst is de vingerafdruk (hexadecimale weergave van sha-1) van het certificaat dat we activeren voor verificatie van de apparaatidentiteit.

    • Met ' "cisco-action":"deactivate" de cijfertekst is de vingerafdruk (hexadecimale weergave van sha-1) van het certificaat dat we deactiveren voor gebruik voor apparaatidentiteitsverificatie.

  • JWE-verificatietag: Dit veld bevat de verificatietag om de integriteit van de gehele JWE compact geserialiseerde blob vast te stellen

Hoe we de coderingssleutel afleiden van de ClientSecret

Nadat het geheim voor het eerst is ingevuld, wordt het geheim niet meer geaccepteerd of uitgevoerd als tekst zonder opmaak. Dit is bedoeld om mogelijke woordenboekaanvallen te voorkomen door iemand die toegang zou kunnen krijgen tot het apparaat.

De apparaatsoftware gebruikt het clientgeheim als invoer voor een sleutelafleidingsfunctie (kdf) en gebruikt vervolgens de afgeleide sleutel voor het ontsleutelen/versleutelen van inhoud op het apparaat.

Dit betekent voor u dat uw hulpprogramma voor het produceren van JWE-blobs dezelfde procedure moet volgen om dezelfde versleutelings-/decoderingssleutel af te leiden van het clientgeheim.

De apparaten gebruiken versleutelen voor sleutelafleiding (ziehttps://en.wikipedia.org/wiki/Scrypt ), met de volgende parameters:

  • Kostenfactor (N) is 32768

  • BlockSizeFactor (r) is 8

  • Parallellisatiefactor (p) is 1

  • Salt is een willekeurige reeks van ten minste 4 bytes; u moet hetzelfde opgeven salt bij het opgeven van de cisco-kdf gebruiken.

  • De sleutellengte is 16 bytes (als u het algoritme AES-GCM 128 selecteert) of 32 bytes (als u het algoritme AES-GCM 256 selecteert)

  • Max. geheugenlimiet is 64 MB

Deze set parameters is de enige configuratie van: versleutelen die compatibel is met de functie voor het afleiden van toetsen op de apparaten. Deze kdf op de apparaten heet "version":"1", de enige versie die momenteel wordt gebruikt door de cisco-kdf gebruiken.

Uitgewerkt voorbeeld

Hier is een voorbeeld dat u kunt volgen om te controleren of uw JWE-coderingsproces hetzelfde werkt als het proces dat we op de apparaten hebben gemaakt.

Het voorbeeldscenario is het toevoegen van een PEM-blob aan het apparaat (nabootsen van het toevoegen van een certificaat, met een zeer korte tekenreeks in plaats van een volledige cert + sleutel). Het clientgeheim in het voorbeeld is ossifrage.

  1. Kies een versleutelingscode. In dit voorbeeld wordt gebruik gemaakt van A128GCM(AES met 128-bits sleutels in de Galois-tellermodus). Uw tool zou kunnen gebruiken A256GCM als u wilt.

  2. Kies een salt (moet een willekeurige reeks van minimaal 4 bytes zijn). In dit voorbeeld worden (hex bytes) E5 E6 53 08 03 F8 33 F6. Base64url codeert de reeks die moet worden opgehaald 5eZTCAP4M_Y(verwijder de base64-opvulling).

  3. Hier is een voorbeeld: scrypt aanroep om de coderingssleutel (cek) te maken:

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

    De afgeleide sleutel moet als volgt 16 bytes (hex) zijn: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac waarvoor base64url codeert naar lZ66bdEiAQV4_mqdInj_rA.

  4. Kies een willekeurige reeks van 12 bytes die u als initialisatievector wilt gebruiken. In dit voorbeeld wordt (hex) gebruikt 34 b3 5d dd 5f 53 7b af 2d 92 95 83 waarvoor base64url codeert naar NLNd3V9Te68tkpWD.

  5. Maak de JOSE-header met compacte serialisatie (volg dezelfde volgorde van parameters die we hier gebruiken) en codeer deze vervolgens met base64url:

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

    De met base64url gecodeerde JOSE-header is eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Dit wordt het eerste element van de JWE-blob.

  6. Het tweede element van de JWE-blob is leeg, omdat we geen JWE- coderingssleutel leveren.

  7. Het derde element van de JWE-blob is de initialisatievector NLNd3V9Te68tkpWD.

  8. Gebruik uw JWE-coderingstool om een gecodeerde payload en tag te produceren. In dit voorbeeld wordt de niet-versleutelde payload de nep-PEM-blob this is a PEM file

    De coderingsparameters die u moet gebruiken, zijn:

    • Payload is this is a PEM file

    • Versleutelingscodering is AES 128 GCM

    • De met base64url gecodeerde JOSE-header als aanvullende geverifieerde gegevens (AAD)

    Base64url codeert de versleutelde payload, wat zou moeten resulteren in: f5lLVuWNfKfmzYCo1YJfODhQ

    Dit is het vierde element (JWE Ciphertext) in de JWE-blob.

  9. Base64url codeert de tag die u in stap 8 hebt gemaakt, wat zou moeten resulteren in: PE-wDFWGXFFBeo928cfZ1Q

    Dit is het vijfde element in de JWE-blob.

  10. Voeg de vijf elementen van de JWE-blob samen met punten (JOSEheader..IV.Ciphertext.Tag) om het volgende te krijgen:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Als u dezelfde met base64url gecodeerde waarden hebt afgeleid die hier worden weergegeven, met uw eigen hulpprogramma's, bent u klaar om deze te gebruiken om de E2E-codering en geverifieerde identiteit van uw apparaten te beveiligen.

  12. Dit voorbeeld werkt niet, maar in principe is uw volgende stap het gebruik van de JWE-blob die u hierboven hebt gemaakt als invoer voor de x-opdracht op het apparaat waarmee het certificaat wordt toegevoegd:

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

Sessietypen voor vergaderingen zonder vertrouwen zijn beschikbaar voor alle vergaderingssites zonder extra kosten. Een van deze sessietypen wordt genoemd Pro-End to End Encryption_VOIPonly. Dit is de naam van de openbare dienst, die we in de toekomst mogelijk zullen wijzigen. Zie voor de huidige namen van de sessietypen Sessietype-id's in de Referentie: gedeelte van dit artikel.

U hoeft niets te doen om deze mogelijkheid voor uw site te krijgen. U moet gebruikers wel het nieuwe sessietype (ook wel Meeting Privilege genoemd) toekennen. U kunt dit afzonderlijk doen via de configuratiepagina van de gebruiker of in bulk met een CSV -export/import.

1

Meld u aan bij Control Hub en ga naar Services > Meeting.

2

Klik op Sites, kies de Webex-site waarvoor u de instellingen wilt wijzigen en klik vervolgens op Instellingen.

3

Onder Algemene instellingen , selecteer Sessietypen .

4
U zou een of meer sessietypen voor end-to-end-versleuteling moeten zien. Raadpleeg de lijst met: Sessietype-id's in de Referentie: gedeelte van dit artikel. U ziet bijvoorbeeld Pro-End to End Encryption_ Alleen VoIP .

 

Er is een ouder Sessietype met een vergelijkbare naam: Pro-End-to-end-codering . Dit Sessietype omvat niet-versleutelde PSTN-toegang tot vergaderingen. Zorg ervoor dat u de_ Alleen VoIP versie om end-to-end-codering te garanderen. U kunt dit controleren door de muisaanwijzer op de . te plaatsen PRO koppeling in de kolom sessiecode; voor dit voorbeeld moet het doel van de koppeling zijn javascript:ShowFeature(652).

We kunnen de namen van openbare services voor deze sessietypen in de toekomst wijzigen.

5

Als u het nieuwe Sessietype nog niet hebt, neemt u contact op met uw Webex -vertegenwoordiger.

De volgende stappen

Schakel dit Sessietype /vergaderingrecht in voor sommige of al uw gebruikers.

1

Aanmelden bij Besturingshub en ga naar Beheer > Gebruikers .

2

Selecteer een gebruikersaccount om bij te werken en selecteer vervolgens Vergaderingen .

3

Selecteer in de vervolgkeuzelijst Instellingen toepassen op de vergaderingssite die u wilt bijwerken.

4

Vink het selectievakje aan naast Pro-End to End Encryption_ Alleen VoIP .

5

Sluit het gebruikerconfiguratie .

6

Herhaal indien nodig voor andere gebruikers.

Als u dit aan veel gebruikers wilt toewijzen, gebruikt u de volgende optie, E2EE-vergaderingen inschakelen voor meerdere gebruikers .

1

Meld u aan bij Control Hub en ga naar Services > Meeting.

2

Klik op Sites, kies de Webex-site waarvoor u de instellingen wilt wijzigen.

3

Klik in het gedeelte Licenties en gebruikers op In bulk beheren.

4

Klik op Generate Report (Rapport genereren) en wacht terwijl we het bestand voorbereiden.

5

Wanneer het bestand gereed is, klikt u op Resultaten exporteren en dan Downloaden . (U moet dat pop-upvenster handmatig sluiten nadat u op Downloaden .)

6

Open het gedownloade CSV-bestand om het te bewerken.

Er is een rij voor elke gebruiker en de MeetingPrivilege kolom bevat hun Sessietype id's als een door komma's gescheiden lijst.

7

Voor elke gebruiker die u het nieuwe Sessietype wilt toekennen, voegt u toe 1561 als een nieuwe waarde in de door komma's gescheiden lijst in de MeetingPrivilege cel.

De Referentie voor Webex CSV -bestandsindeling bevat details over het doel en de inhoud van het CSV-bestand.

8

Open het configuratievenster Vergaderingssite in Control Hub.


 

Als u zich al op de lijstpagina Vergaderingssite bevond, moet u deze mogelijk vernieuwen.

9

Klik in het gedeelte Licenties en gebruikers op In bulk beheren.

10

Klik op Importeren en selecteer de bewerkte CSV en klik vervolgens op Importeren . Wacht terwijl het bestand is geüpload.

11

Wanneer het importeren is voltooid, klikt u op Resultaten importeren om te controleren of er fouten zijn opgetreden.

12

Ga naar de Gebruikers en open een van de gebruikers om te controleren of ze het nieuwe Sessietype hebben.

U kunt een watermerk toevoegen aan vergaderingsopnamen met de Webex Meetings Pro-End to End Encryption_VOIPonly sessietype, waarmee u de bronclient of het apparaat van onbevoegde opnamen van vertrouwelijke vergaderingen kunt identificeren.

Wanneer deze functie is ingeschakeld, bevat de audio van de vergadering een unieke id voor elke deelnemende client of elk apparaat. U kunt audio-opnamen uploaden naar Control Hub, die vervolgens de opname analyseert en de unieke id's opzoekt. U kunt de resultaten bekijken om te zien welke bronclient of apparaat de vergadering heeft opgenomen.

  • Om te worden geanalyseerd, moet de opname een AAC-, MP3-, M4A-, WAV-, MP4-, AVI- of MOV-bestand zijn dat niet groter is dan 500 MB.
  • De opname moet langer zijn dan 100 seconden.
  • U kunt alleen opnamen analyseren voor vergaderingen die worden gehost door personen in uw organisatie.
  • Watermerk-informatie wordt bewaard voor dezelfde duur als de vergaderingsinformatie van de organisatie.
Audiowatermerken toevoegen aan E2EE-vergaderingen
  1. Aanmelden bij Control Hub , dan onder Beheer , selecteer Organisatie-instellingen .
  2. In de Watermerken voor vergaderingen sectie, schakel in Audiowatermerk toevoegen .

    Enige tijd nadat dit is ingeschakeld, plannen gebruikers vergaderingen met de Webex Meetings Pro-End to End Encryption_VOIPonly sessietype zie de optie Digital Watermarking in het gedeelte Beveiliging.

Een vergadering met watermerk uploaden en analyseren
  1. In Control Hub, onder Bewaking , selecteer Problemen oplossen .
  2. Klik op Watermerkanalyse .
  3. Zoek of selecteer de vergadering in de lijst en klik vervolgens op Analyseren.
  4. In de Audiowatermerk analyseren voert u een naam in voor uw analyse.
  5. (Optioneel) Voer een notitie in voor uw analyse.
  6. Sleep het audiobestand dat u wilt analyseren, of klik op Bestand kiezen om naar het audiobestand te bladeren.
  7. Klik op Sluiten.

    Wanneer de analyse is voltooid, wordt deze weergegeven in de lijst met resultaten op het Watermerk analyseren pagina.

  8. Selecteer de vergadering in de lijst om de resultaten van de analyse te bekijken. Klik opDownloadknop om de resultaten te downloaden.
Functies en beperkingen

Factoren die betrokken zijn bij het succesvol decoderen van een opgenomen watermerk zijn de afstand tussen het opnameapparaat en de luidspreker die de audio uitzet, het volume van die audio, omgevingsgeluid, enz. Onze watermarkeringstechnologie heeft een extra veerkracht om meerdere keren gecodeerd te worden, zoals kan gebeuren wanneer de media worden gedeeld.

Deze functie is ontworpen om succesvolle decodering van de watermerk-id in een brede maar redelijke reeks omstandigheden mogelijk te maken. Ons doel is dat een opnameapparaat, zoals een mobiele telefoon, dat op een bureau ligt in de buurt van een persoonlijk eindpunt of een laptopclient, altijd een opname maakt die resulteert in een succesvolle analyse. Als het opnameapparaat wordt verwijderd van de bron of wordt verduisterd van het horen van het volledige audiospectrum, neemt de kans op een succesvolle analyse af.

Voor een geslaagde analyse van een opname is een redelijke opname van de audio van de vergadering nodig. Als de audio van een vergadering wordt opgenomen op dezelfde computer als die waarop de client wordt gehost, zijn er geen beperkingen van toepassing.

Als uw apparaten al zijn geïntegreerd in uw Control Hub-organisatie en u de Webex -CA wilt gebruiken om hun identificerende certificaten automatisch te genereren, hoeft u de apparaten niet terug te zetten op de fabrieksinstellingen .

Deze procedure selecteert welk domein het apparaat gebruikt om zichzelf te identificeren en is alleen vereist als u meerdere domeinen hebt in uw Control Hub-organisatie. Als u meer dan één domein heeft, raden we u aan dit te doen voor al uw apparaten met de identiteit 'Cisco-geverifieerd'. Als u Webex niet vertelt welk domein het apparaat identificeert, wordt er automatisch een gekozen en kan het er verkeerd uitzien voor andere deelnemers aan de vergadering.

Voordat u begint

Als uw apparaten nog niet aan boord zijn, volgt u Een apparaat registreren bij Cisco Webex met behulp van API of lokale Web of Onboarding in de cloud voor Board-, Desk- en Room Series . U moet ook de domeinen verifiëren die u wilt gebruiken om de apparaten in Uw domeinen beheren .

1

Aanmelden bij Control Hub en onder Beheer , selecteer Apparaten .

2

Selecteer een apparaat om het configuratievenster te openen.

3

Selecteer het domein dat u wilt gebruiken om dit apparaat te identificeren.

4

Herhaal dit voor andere apparaten.

Voordat u begint

U hebt het volgende nodig:

  • Als u een door een CA ondertekend certificaat en een persoonlijke sleutel wilt ophalen, .pem formaat, voor elk apparaat.

  • Het onderwerp lezen: Inzicht in het externe identiteitsproces voor apparaten , in de Voorbereiden deel van dit artikel.

  • Een JWE-coderingstool voorbereiden met betrekking tot de informatie daar.

  • Een hulpmiddel om willekeurige bytereeksen van bepaalde lengtes te genereren.

  • Een hulpprogramma voor het coderen van bytes of tekst met base64url.

  • An scrypt implementatie.

  • Een geheim woord of woordgroep voor elk apparaat.

1

De van het apparaat invullen ClientSecret met een geheim tekst zonder opmaak:

De eerste keer dat u de . invult Secret, levert u deze in platte tekst op. Daarom raden we u aan dit te doen op de console van het fysieke apparaat.

  1. Base64url codeert de geheime woordgroep voor dit apparaat.

  2. Open de TShell op het apparaat.

  3. Uitvoeren xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    De voorbeeldopdracht hierboven vult de Secret met de zin 0123456789abcdef. U moet uw eigen kiezen.

Het apparaat heeft zijn oorspronkelijke geheim. Vergeet dit niet; u kunt het niet herstellen en moet het apparaat terugzetten op de fabrieksinstellingen om opnieuw te kunnen starten.
2

Uw certificaat en persoonlijke sleutel samenvoegen:

  1. Gebruik een teksteditor om de PEM-bestanden te openen, plak de sleutelblob in de certificaatblob en sla deze op als een nieuw Pem-bestand.

    (Dit is de payloadtekst die u versleutelt en in uw JWE-blob plaatst)

3

Maak een JWE-blob om te gebruiken als invoer voor de opdracht voor het toevoegen van een certificaat:

  1. Maak een willekeurige reeks van minimaal 4 bytes. Dit is uw zout.

  2. Leid een inhoudscoderingssleutel af met uw coderingssleutel .

    Hiervoor hebt u het geheim, de salt en een sleutellengte nodig die overeenkomen met het door u gekozen versleutelingscijfer. Er zijn enkele andere vaste waarden die moeten worden opgegeven (N=32768, r=8, p=1). Het apparaat gebruikt hetzelfde proces en dezelfde waarden om dezelfde coderingssleutel af te leiden.

  3. Maak een willekeurige reeks van exact 12 bytes. Dit is uw initialisatievector.

  4. Een JOSE-koptekst maken, instelling alg, enc en cisco-kdf toetsen zoals beschreven in Inzicht in het externe identiteitsproces voor apparaten . Stel de actie 'toevoegen' in met de toets key:value "cisco-action":"add" in uw JOSE-koptekst (omdat we het certificaat aan het apparaat toevoegen).

  5. Base64url codeert de JOSE-header.

  6. Gebruik uw JWE-coderingstool met de gekozen codering en de met base64url gecodeerde JOSE-header om de tekst uit het aaneengeschakelde pem-bestand te coderen.

  7. Base64url codeert de initialisatievector, de versleutelde PEM-nettolading en de verificatietag.

  8. Construeer de JWE-blob als volgt (alle waarden zijn gecodeerd met base64url):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Open de TShell op het apparaat en voer de opdracht (meerdere regels) voor toevoegen uit:

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

Controleer of het certificaat is toegevoegd door uit te voeren xcommand Security Certificates Services Show

Kopieer de vingerafdruk van het nieuwe certificaat.

6

Activeer het certificaat voor dit doel WebexIdentity:

  1. Lees de vingerafdruk van het certificaat, hetzij van het certificaat zelf of van de uitvoer van xcommand Security Certificates Services Show.

  2. Maak een willekeurige reeks van ten minste 4 bytes en base64url codeert die reeks. Dit is uw zout.

  3. Leid een inhoudscoderingssleutel af met uw coderingssleutel .

    Hiervoor hebt u het geheim, de salt en een sleutellengte nodig die overeenkomen met het door u gekozen versleutelingscijfer. Er zijn enkele andere vaste waarden die moeten worden opgegeven (N=32768, r=8, p=1). Het apparaat gebruikt hetzelfde proces en dezelfde waarden om dezelfde coderingssleutel af te leiden.

  4. Maak een willekeurige reeks van exact 12 bytes en base64url codeert die reeks. Dit is uw initialisatievector.

  5. Een JOSE-koptekst maken, instelling alg, enc en cisco-kdf toetsen zoals beschreven in Inzicht in het externe identiteitsproces voor apparaten . Stel de actie 'activeren' in met de toets key:value "cisco-action":"activate" in uw JOSE-koptekst (omdat we het certificaat op het apparaat activeren).

  6. Base64url codeert de JOSE-header.

  7. Gebruik uw JWE-coderingstool met de gekozen codering en de met base64url gecodeerde JOSE-header om de vingerafdruk van het certificaat te coderen.

    Het hulpprogramma moet een reeks van 16 of 32 bytes uitvoeren, afhankelijk van of u 128 of 256-bits AES-GCM hebt gekozen, en een verificatietag.

  8. Base64urlencode de versleutelde vingerafdruk en de verificatietag.

  9. Construeer de JWE-blob als volgt (alle waarden zijn gecodeerd met base64url):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Open de TShell op het apparaat en voer de volgende activeringsopdracht uit:

                      xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint" 
                    
Het apparaat heeft een versleuteld, actief, door een CA uitgegeven certificaat dat klaar is om te worden gebruikt voor identificatie in end-to-end versleutelde Webex -vergaderingen.
7

Onboard het apparaat in uw Control Hub-organisatie.

1

Plan een vergadering van het juiste type ( Webex Meetings Pro-End to End Encryption_ Alleen VoIP ).

2

Neem als host deel aan de vergadering vanuit een Webex Meetings -client.

3

Neem deel aan de vergadering vanaf een apparaat waarvan de identiteit is geverifieerd door de Webex CA.

4

Controleer of dit apparaat als host wordt weergegeven in de lobby met het juiste identiteitspictogram.

5

Neem deel aan de vergadering vanaf een apparaat waarvan de identiteit is geverifieerd door een externe CA.

6

Controleer of dit apparaat als host wordt weergegeven in de lobby met het juiste identiteitspictogram. Meer informatie over identiteitspictogrammen .

7

Neem deel aan de vergadering als een niet-geverifieerde deelnemer aan de vergadering.

8

Controleer of deze deelnemer als host wordt weergegeven in de lobby met het juiste identiteitspictogram.

9

Als host kunt u personen/apparaten toelaten of weigeren.

10

Valideer de identiteiten van deelnemers/apparaten waar mogelijk door de certificaten te controleren.

11

Controleer of iedereen in de vergadering dezelfde beveiligingscode voor de vergadering ziet.

12

Neem deel aan de vergadering met een nieuwe deelnemer.

13

Controleer of iedereen dezelfde, nieuwe beveiligingscode voor de vergadering ziet.

Gaat u van end-to-end-versleutelde vergaderingen de standaardvergaderingsoptie maken, of deze alleen voor bepaalde gebruikers inschakelen of alle hosts laten beslissen? Wanneer u hebt besloten hoe u deze functie gaat gebruiken, bereidt u de gebruikers voor die deze functie gaan gebruiken, vooral met betrekking tot de beperkingen en wat u in de vergadering kunt verwachten.

Moet u ervoor zorgen dat noch Cisco , noch iemand anders uw inhoud kan decoderen of uw apparaten kan imiteren? Als dit het geval is, hebt u certificaten nodig van een openbare CA. U kunt maximaal 25 apparaten in een beveiligde vergadering hebben. Als u dit beveiligingsniveau nodig hebt, moet u niet toestaan dat vergaderingsclients deelnemen.

Voor gebruikers die deelnemen met beveiligde apparaten: laat apparaten eerst deelnemen en stel gebruikersverwachtingen in dat ze mogelijk niet kunnen deelnemen als ze te laat deelnemen.

Als u verschillende niveaus van identiteitsverificatie hebt, geeft u gebruikers de mogelijkheid om elkaar te verifiëren met een door certificaten ondersteunde identiteit en de beveiligingscode van de vergadering. Hoewel er omstandigheden zijn waarin deelnemers als niet-geverifieerd kunnen worden weergegeven en deelnemers moeten weten hoe ze dit moeten controleren, zijn niet-geverifieerde personen mogelijk geen bedriegers.

Als u een externe CA gebruikt om uw apparaatcertificaten uit te geven, moet u de certificaten controleren, vernieuwen en opnieuw toepassen.

Als u het eerste geheim hebt gemaakt, moet u er rekening mee houden dat uw gebruikers mogelijk het geheim van hun apparaat willen wijzigen. Mogelijk moet u een interface maken/een hulpprogramma distribueren om dit mogelijk te maken.

Tabel 1. Sessietype-id's voor end-to-end versleutelde vergaderingen

Sessietype- Id

Naam openbare service

638

Alleen E2E-codering+ VoIP

652

Pro-End to End Encryption_ Alleen VoIP

660

Pro 3 Free-End to End Encryption_ Alleen VoIP

E2E-codering + identiteit

672

Pro 3 Free50-End to End Encryption_ Alleen VoIP

673

Instructeur E2E Encryption_ Alleen VoIP

676

Broadworks Standard plus end-to-end-codering

677

Broadworks Premium plus end-to-end-codering

681

Schoology Gratis plus end-to-end-codering

In deze tabellen worden de API -opdrachten voor Webex -apparaten beschreven die we hebben toegevoegd voor end-to-end versleutelde vergaderingen en geverifieerde identiteit. Voor meer informatie over het gebruik van de API raadpleegt u Toegang tot de API voor Webex Room- en Desk-apparaten en Webex Boards .

Deze xAPI-opdrachten zijn alleen beschikbaar op apparaten die:

  • Geregistreerd bij Webex

  • On op locatie geregistreerd en gekoppeld aan Webex met Webex Edge voor apparaten

Tabel 2. API's op systeemniveau voor end-to-end versleutelde vergaderingen en geverifieerde identiteit

API-aanroep

Beschrijving

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Deze configuratie wordt gemaakt wanneer de beheerder het voorkeursdomein van het apparaat instelt via Control Hub. Alleen nodig als de organisatie meer dan één domein heeft.

Het apparaat gebruikt dit domein wanneer het een certificaat aanvraagt bij de Webex CA. Het domein identificeert vervolgens het apparaat.

Deze configuratie is niet van toepassing wanneer het apparaat een actief, extern uitgegeven certificaat heeft om zichzelf te identificeren.

xStatus Conference EndToEndEncryption Availability

Geeft aan of het apparaat kan deelnemen aan een end-to-end versleutelde vergadering. De cloud- API roept deze aan zodat een gekoppelde app weet of deze het apparaat kan gebruiken om deel te nemen.

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Geeft aan of het apparaat gebruikmaakt van External verificatie (heeft een extern uitgegeven certificaat).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

De identiteit van het apparaat zoals gelezen uit de algemene naam van het extern uitgegeven certificaat.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

Leest specifieke informatie van een extern uitgegeven certificaat.

In de weergegeven opdracht vervangt u # met het nummer van het certificaat. Replace specificinfo met een van:

  • Fingerprint

  • NotAfter einddatum geldigheid

  • NotBefore begindatum geldigheid

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Een lijst met de onderwerpen voor het certificaat (bijvoorbeeld e-mailadres of domeinnaam)

  • Validity Geeft de geldigheidsstatus van dit certificaat (bijv valid of expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

De status van de externe identiteit van het apparaat (bijv valid of error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

Geeft aan of het apparaat een geldig certificaat heeft dat is uitgegeven door de Webex CA.

xStatus Conference EndToEndEncryption InternalIdentity Identity

De identiteit van het apparaat zoals gelezen uit de algemene naam van het door Webex uitgegeven certificaat.

Bevat een domeinnaam als de organisatie een domein heeft.

Is leeg als de organisatie geen domein heeft.

Als het apparaat zich in een organisatie met meerdere domeinen bevindt, is dit de waarde uit de PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Leest specifieke informatie van het door Webex uitgegeven certificaat.

In de weergegeven opdracht vervangt u # met het nummer van het certificaat. Replace specificinfo met een van:

  • Fingerprint

  • NotAfter einddatum geldigheid

  • NotBefore begindatum geldigheid

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Een lijst met de onderwerpen voor het certificaat (bijvoorbeeld e-mailadres of domeinnaam)

  • Validity Geeft de geldigheidsstatus van dit certificaat (bijv valid of expired)

Tabel 3. In gesprek-API's voor end-to-end versleutelde vergaderingen en geverifieerde identiteit

API-aanroep

Beschrijving

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

Deze drie gebeurtenissen bevatten nu: EndToEndEncryptionStatus, EndToEndEncryptionIdentity en EndToEndEncryptionCertInfo voor de betrokken deelnemer.

Tabel 4. ClientSecret-gerelateerde API's voor end-to-end versleutelde vergaderingen en geverifieerde identiteit

API-aanroep

Beschrijving

xCommand Security ClientSecret Populate Secret: "base64url-encoded"

of

xCommand Security ClientSecret Populate Secret: JWEblob

Accepteert een met base64url gecodeerde waarde zonder opmaak voor het voor de eerste keer seeden van het clientgeheim op het apparaat.

Als u het geheim na die eerste keer wilt bijwerken, moet u een JWE-blob opgeven met het nieuwe geheim dat is versleuteld met het oude geheim.

xCommand Security Certificates Services Add JWEblob

Voegt een certificaat toe (met persoonlijke sleutel).

We hebben deze opdracht uitgebreid om een JWE-blob te accepteren die de versleutelde PEM-gegevens bevat.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Activeert een specifiek certificaat voor WebexIdentity. Hiervoor: Purpose, vereist de opdracht dat de identificerende vingerafdruk wordt versleuteld en geserialiseerd in een JWE-blob.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Deactiveert een specifiek certificaat voor WebexIdentity. Hiervoor: Purpose, vereist de opdracht dat de identificerende vingerafdruk wordt versleuteld en geserialiseerd in een JWE-blob.