Hartelijk dank voor uw feedback
Feedback?
Gebruikers kiezen het vergadertype wanneer ze een vergadering plannen. Bij het toelaten van deelnemers uit de lobby, maar ook tijdens de vergadering, kan de gastheer de status van de identiteitsverificatie van elke deelnemer zien. Er is ook een vergadercode die alle huidige deelnemers aan de vergadering gemeen hebben, die ze kunnen gebruiken om te controleren of hun vergadering niet is onderschept door een ongewenste Meddler In The Middle-aanval (MITM) van een derde partij.
Deel de volgende informatie met de gastheren van uw vergadering:
-
Neem deel aan een Webex-vergadering met end-to-end encryptie
Identiteit verifiëren
End-to-end encryptie met identiteitsverificatie biedt extra beveiliging voor een versleutelde vergadering van begin tot eind.
Wanneer deelnemers of apparaten lid worden van een gedeelde MLS-groep (Messaging Layer Security), presenteren ze hun certificaten aan de andere groepsleden, die de certificaten vervolgens valideren aan de hand van de certificeringsinstanties (CA) die de certificaten hebben uitgegeven. Door te bevestigen dat de certificaten geldig zijn, verifieert de CA de identiteit van de deelnemers, en de vergadering toont aan dat de deelnemers/apparaten geverifieerd zijn.
Gebruikers van de Webex App verifiëren zichzelf aan de hand van de Webex Identity Store, die hen een toegangstoken geeft wanneer de authenticatie slaagt. Als ze een certificaat nodig hebben om hun identiteit te verifiëren tijdens een versleutelde vergadering, geeft de Webex CA hen een certificaat op basis van hun toegangstoken. Op dit moment bieden we Webex Meetings gebruikers geen manier om een certificaat te krijgen dat is uitgegeven door een derde/externe CA.
Apparaten kunnen zichzelf authenticeren met een certificaat dat is uitgegeven door de interne CA (Webex), 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 machineaccount van het apparaat. Het certificaat is ondertekend door de Webex CA. Apparaten hebben geen gebruikers-ID's op dezelfde manier als gebruikers, dus gebruikt Webex (een van) de domeinen van uw organisatie bij het schrijven van de identiteit van het apparaatcertificaat (Common Name (CN)).
-
Externe CA: apparaatcertificaten rechtstreeks aanvragen en kopen bij de uitgever van uw keuze. U moet de certificaten versleutelen, rechtstreeks uploaden en autoriseren met behulp van een geheim dat u alleen kent.
Cisco is er niet bij betrokken, waardoor dit de manier is om echte end-to-end encryptie en geverifieerde identiteit te garanderen, en om de theoretische mogelijkheid te voorkomen dat Cisco uw vergadering zou afluisteren/uw media zou kunnen ontsleutelen.
Intern uitgegeven apparaatcertificaat
Webex geeft een certificaat uit aan het apparaat wanneer het wordt geregistreerd na het opstarten, en vernieuwt het indien nodig. Voor apparaten bevat het certificaat de account-ID en een domein.
Als uw organisatie geen domein heeft, geeft de Webex CA het certificaat zonder domein uit.
Als uw organisatie meerdere domeinen heeft, kunt u Control Hub gebruiken om Webex te vertellen welk domein het apparaat moet gebruiken voor de identiteit. U kunt ook de API XConfiguration Conference EndEnEncryption Identity PreferredDomain gebruiken: „example.com”.
Als u meerdere domeinen hebt en niet het voorkeursdomein voor het apparaat instelt, dan kiest Webex er een voor u.
Extern uitgegeven apparaatcertificaat
Een beheerder kan een apparaat voorzien van een eigen certificaat dat is ondertekend door een van de openbare certificeringsinstanties.
Het certificaat moet gebaseerd zijn op een ECDSA P-256-sleutelpaar, hoewel het kan worden ondertekend met een RSA-sleutel.
De waarden in het certificaat worden door de organisatie bepaald. De Common Name (CN) en Subject Alternative Name (SAN) worden weergegeven in de gebruikersinterface van de Webex-vergadering, zoals beschreven in End-to-end-encryptie met identiteitsverificatie voor Webex Meetings.
We raden aan om per apparaat een apart certificaat te gebruiken en een unieke CN per apparaat te hebben. Bijvoorbeeld „meeting-room-1.example.com” voor de organisatie die eigenaar is van het domein „example.com”.
Om het externe certificaat volledig tegen manipulatie te beschermen, wordt een clientgeheime functie gebruikt om verschillende opdrachten te versleutelen en te ondertekenen.
Wanneer u het klantgeheim 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
In de cloud geregistreerde Cisco Board-, Desk- en Room Series-apparaten kunnen deelnemen aan E2EE-vergaderingen.
De volgende apparaten kunnen niet deelnemen aan E2EE-vergaderingen:
-
SIP-apparaten van derden
Softwareklanten
-
De Webex-app voor desktop- en mobiele clients kan deelnemen aan E2EE-vergaderingen.
-
De Webex-webclient kan niet deelnemen aan E2EE-vergaderingen.
-
SIP-softclients van derden kunnen niet deelnemen aan E2EE-vergaderingen.
Identiteit
-
We bieden u per definitie geen Control Hub-opties om extern geverifieerde apparaatidentiteit te beheren. Voor echte versleuteling van begin tot eind moet alleen u de geheimen en sleutels kennen of gebruiken. Als we een cloudservice zouden introduceren om die sleutels te beheren, bestaat de kans dat ze worden onderschept.
-
Momenteel bieden we u een 'recept' om uw eigen tools te ontwerpen, gebaseerd op coderingstechnieken die voldoen aan de industriestandaard, om u te helpen bij het aanvragen of versleutelen van de identiteitscertificaten van uw apparaat en de bijbehorende privésleutels. We willen geen echte of vermeende toegang hebben tot uw geheimen of sleutels.
Bijeenkomsten
-
E2EE-vergaderingen ondersteunen momenteel maximaal 1000 deelnemers.
- U kunt nieuwe whiteboards delen tijdens E2EE-vergaderingen. Er zijn enkele verschillen met whiteboards tijdens reguliere vergaderingen:
- Tijdens E2EE-vergaderingen hebben gebruikers geen toegang tot whiteboards die buiten de vergadering zijn gemaakt, waaronder privéwhiteboards, whiteboards die door anderen worden gedeeld en whiteboards uit Webex-ruimten.
- Whiteboards die tijdens E2EE-vergaderingen zijn gemaakt, zijn alleen beschikbaar tijdens de vergadering. Ze worden niet opgeslagen en zijn niet toegankelijk nadat de vergadering is afgelopen.
- Als iemand inhoud deelt tijdens een E2EE-vergadering, kunt u daar aantekeningen op maken. Voor meer informatie over aantekeningen, zie Webex App | Gedeelde inhoud markeren met aantekeningen.
Interface voor beheer
We raden u ten zeerste aan om Control Hub te gebruiken om uw vergaderlocatie te beheren, aangezien Control Hub-organisaties een gecentraliseerde identiteit hebben voor de hele organisatie.
Gerelateerde informatie
-
Zero-Trust Security voor Webex (technisch document over beveiliging)
-
JSON-webversleuteling (JWE) (ontwerp van de IETF-standaard)
-
Webex Meetings41,7.
-
Cisco Board-, Desk- en Room Series-apparaten die in de cloud zijn geregistreerd en waarop
10.6.1 RoomOS_august_2021 of hoger draait. -
Administratieve toegang tot de vergaderlocatie in Control Hub.
-
Een of meer geverifieerde domeinen in uw Control Hub-organisatie (als u de Webex CA gebruikt om apparaatcertificaten uit te geven voor geverifieerde identiteit).
-
Vergaderruimten voor samenwerking moeten ingeschakeld zijn, zodat mensen via hun videosysteem kunnen deelnemen. Zie Videosystemen toestaan deel te nemen aan vergaderingen en evenementen op uw Webex-site voor meer informatie.
U kunt deze stap overslaan als u geen extern geverifieerde identiteiten nodig hebt.
Voor het hoogste beveiligingsniveau en voor identiteitsverificatie moet elk apparaat beschikken over een uniek certificaat dat is uitgegeven door een vertrouwd publiek Certificate Authority (CA).
U moet contact opnemen met de CA om de digitale certificaten aan te vragen, te kopen en te ontvangen en de bijbehorende privésleutels aan te maken. Gebruik de volgende parameters wanneer u het certificaat aanvraagt:
-
Het certificaat moet worden uitgegeven en ondertekend door een bekende openbare CA.
-
Uniek: We raden ten zeerste aan om voor elk apparaat een uniek certificaat te gebruiken. Als u één certificaat gebruikt voor alle apparaten, brengt u uw beveiliging in gevaar.
-
Common Name (CN) en Subject Alternate Name/S (San/s): Deze zijn niet belangrijk voor Webex, maar moeten waarden zijn die mensen kunnen lezen en aan het apparaat kunnen koppelen. De CN toont aan andere deelnemers aan de vergadering de primaire geverifieerde identiteit van het apparaat, en als gebruikers het certificaat inspecteren via de gebruikersinterface van de vergadering, zien ze de SAN/s. Misschien wilt u namen gebruiken zoals
name.model@example.com. -
Bestandsindeling: De certificaten en sleutels moeten de indeling
.pemhebben. -
Doel: Het doel van het certificaat moet Webex Identity zijn.
-
Sleutels genereren: De certificaten moeten gebaseerd zijn op ECDSA P-256-sleutelparen (Elliptical Curve Digital Signature Algorithm dat de P-256-curve gebruikt).
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 wilt gebruiken voor uw apparaten.
Als u nieuwe apparaten gebruikt, registreer ze dan nog niet bij Webex. Verbind ze op dit moment voor alle zekerheid niet met het netwerk.
Als u bestaande apparaten hebt die u wilt upgraden om een extern geverifieerde identiteit te gebruiken, moet u de apparaten terugzetten naar de fabrieksinstellingen.
-
Sla de bestaande configuratie op als u die wilt behouden.
-
Plan een periode in wanneer de apparaten niet worden gebruikt, of maak gebruik van een gefaseerde aanpak. Stel gebruikers op de hoogte van de wijzigingen die ze kunnen verwachten.
-
Zorg voor fysieke toegang tot apparaten. Als u via het netwerk toegang moet hebben tot apparaten, moet u er dan rekening mee houden dat geheimen in gewone tekst worden verzonden en dat u uw veiligheid in gevaar brengt.
Zodra u deze stappen hebt voltooid, moet u videosystemen toestaan om deel te nemen aan vergaderingen en evenementen op uw Webex-site.
Om ervoor te zorgen dat de media van uw apparaat door niemand anders dan door het apparaat kunnen worden versleuteld, moet u de privésleutel op het apparaat versleutelen. We hebben API's voor het apparaat ontworpen om het beheer van de versleutelde sleutel en het certificaat mogelijk te maken met behulp van JSON Web Encryption (JWE).
Om echte versleuteling van begin tot eind via onze cloud te garanderen, kunnen we niet betrokken zijn bij het versleutelen en uploaden van het certificaat en de sleutel. Als u dit beveiligingsniveau nodig hebt, moet u:
-
Vraag uw certificaten aan.
-
Genereer de sleutelparen van uw certificaten.
-
Creëer (en bescherm) een eerste geheim voor elk apparaat, om de coderingscapaciteit van het apparaat te verbeteren.
-
Ontwikkel en onderhoud uw eigen tool voor het versleutelen van bestanden volgens 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 de ontwikkeltools van uw keuze. We verstrekken ook enkele testgegevens en de resulterende JWE-blobs zoals we die 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.
-
Voeg het certificaat en de sleutel samen en versleutel het met behulp van uw tool en het oorspronkelijke geheim van het apparaat.
-
Upload de resulterende JWE-blob naar het apparaat.
-
Stel het doel in van het gecodeerde certificaat dat moet worden gebruikt voor de Webex-identiteit en activeer het certificaat.
-
(Aanbevolen) Zorg voor een interface voor (of distributie) van uw tool zodat gebruikers van het apparaat het oorspronkelijke geheim kunnen wijzigen en hun media tegen u kunnen beschermen.
Hoe we het JWE-formaat gebruiken
In dit gedeelte wordt beschreven hoe we verwachten dat de JWE wordt aangemaakt als invoer voor de apparaten, zodat u uw eigen tool kunt bouwen om de blobs te maken op basis van uw certificaten en sleutels.
Raadpleeg JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 en JSON Web Signature (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 aanmaken van de JWE-blobs zijn:
-
JOSE-koptekst (beveiligd). In de JSON Object Signing and Encryption-header MOET u de volgende sleutel-waarde-paren opnemen:
-
„alg” :"dir”Het directe algoritme is het enige dat we ondersteunen voor het versleutelen van de payload, en u moet het initiële clientgeheim van het apparaat gebruiken.
-
„enc” :"A128GCM” of „enc” :"A256GCM”We ondersteunen deze twee coderingsalgoritmen.
-
„cisco-action”: „add” of „cisco-action”: „invullen” of „cisco-action”: „activeren”of „cisco-action”: „deactiveren”Dit is een gepatenteerde sleutel en er zijn vier waarden voor nodig. We hebben deze sleutel geïntroduceerd om het doel van de versleutelde gegevens aan het doelapparaat door te geven. De waarden zijn vernoemd naar de xAPI-opdrachten op het apparaat waarop u de versleutelde gegevens gebruikt.
We hebben het
cisco-actiongenoemd om mogelijke botsingen met toekomstige JWE-extensies te beperken. -
„cisco-kdf”: {„version”: „1", „salt”: „base64URLEncodedRandom4+bytes”}Nog een gepatenteerde sleutel. We gebruiken de waarden die u opgeeft als invoer voor de sleutelafleiding op het apparaat. De
versiemoet1zijn (de versie van onze belangrijkste afleidingsfunctie). De waarde vansaltmoet een base64 URL-gecodeerde reeks zijn van minstens 4 bytes, die u willekeurig moet kiezen.
-
-
JWE-gecodeerde sleutel. Dit veld is leeg. Het apparaat ontleent het aan de oorspronkelijke
ClientSecret. -
Initialisatievector van JWE. U moet een initialisatievector met base64URL-codering opgeven om de payload te ontcijferen. De IV MOET een willekeurige waarde van 12 bytes hebben (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 de compacte serialisatie.
-
JWE Ciphertext: Dit is de versleutelde payload die u geheim wilt houden.
Het laadvermogen kan leeg zijn. Als u bijvoorbeeld het cliëntgeheim opnieuw wilt instellen, moet u dat overschrijven met een lege waarde.
Er zijn verschillende soorten payloads, afhankelijk van wat u probeert te doen op het apparaat. Verschillende xAPI-opdrachten verwachten verschillende payloads, en u moet het doel van de payload specificeren met de
cisco-actietoets, en wel als volgt:-
Met„cisco-action” :"populate” is de cijfertekst de nieuwe ClientSecret. -
Met "
„cisco-action” :"add”is de cijfertekst een PEM-blob met het certificaat en de bijbehorende privésleutel (aaneengeschakeld). -
Met "
„cisco-action” :"activate”is de cijfertekst de vingerafdruk (hexadecimale weergave van sha-1) van het certificaat dat we activeren om de identiteit van het apparaat te verifiëren. -
Met "
„cisco-action” :"deactivate”is de cijfertekst de vingerafdruk (hexadecimale weergave van sha-1) van het certificaat dat we niet gebruiken voor de identiteitsverificatie van het apparaat.
-
-
Authenticatielabel van JWE: Dit veld bevat de authenticatietag om de integriteit van de volledige JWE-blob vast te stellen die compact is geserialiseerd
Hoe we de coderingssleutel afleiden uit de ClientSecret
Na de eerste populatie van het geheim accepteren we het niet en geven we het niet weer als gewone tekst. Dit is om mogelijke woordenboekaanvallen te voorkomen door iemand die toegang zou kunnen krijgen tot het apparaat.
De software van het apparaat 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 instrument om JWE-blobs te produceren dezelfde procedure moet volgen om dezelfde coderings- en decoderingssleutel uit het klantgeheim af te leiden.
De apparaten gebruiken scrypt voor het afleiden van sleutels (zie https://en.wikipedia.org/wiki/Scrypt), met de volgende parameters:
-
De kostenfactor (N) is 32768
-
De factor (r) van het blok is 8
-
De parallellisatiefactor (p) is 1
-
Salt is een willekeurige reeks van minstens 4 bytes; u moet ditzelfde
saltinvoeren wanneer u decisco-kdf-parameterspecificeert. -
De sleutellengtes zijn ofwel 16 bytes (als u het AES-GCM 128-algoritme selecteert) of 32 bytes (als u het AES-GCM 256-algoritme selecteert)
-
De maximale geheugenlimiet is 64 MB
Deze set parameters is de enige configuratie van scrypt die compatibel is met de functie voor het afleiden van sleutels op de apparaten. Deze kdf op de apparaten heet „version” :"1", de enige versie die momenteel wordt gebruikt met de parameter cisco-kdf.
Voorbeeld dat is gelukt
Hier is een voorbeeld dat u kunt volgen om te controleren of uw JWE-coderingsproces op dezelfde manier werkt als het proces dat we op de apparaten hebben gemaakt.
Het voorbeeldscenario is het toevoegen van een PEM-blob aan het apparaat (waarbij een certificaat wordt toegevoegd, met een zeer korte tekenreeks in plaats van een volledig certificaat + sleutel). Het geheim van de klant in het voorbeeld is ossifrage.
-
Kies een versleutelingscijfer. In dit voorbeeld wordt
A128GCMgebruikt (AES met 128-bits toetsen in de Galois Counter-modus). Uw gereedschap kanA256GCMgebruiken als u dat liever hebt. -
Kies een salt (moet een willekeurige reeks zijn van minstens 4 bytes). In dit voorbeeld wordt gebruik gemaakt van (hexadecimale bytes)
E5 E6 53 08 03 F8 33 F6. Base64URL codeert de reeks om5eZtCap4M_Yte krijgen (verwijder de base64-opvulling). -
Hier is een voorbeeld van een
scrypt-aanroepom de inhoudscoderingssleutel (cek) te creëren:cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)De afgeleide sleutel moet 16 bytes (hex) zijn, en wel als volgt:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac, waarbij base64url codeert naar LZ66BDEIAQV4_mqdinj_RA. -
Kies een willekeurige reeks van 12 bytes om als initialisatievector te gebruiken.
In dit voorbeeld wordt (hex)34 b3 5d dd 5f 53 7b af 2d 92 95 83gebruikt, waarbij base64url codeert naar NLNd3v9te68tkpwd. -
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 JOSE-header met basis64 URL is eYJHBGCIOIJKAXIiLCJJAxNJBY1HY3RpB24ioIJHZgQiLcJaxNJBY1RZgYionSiC2FSdCi6IJvLWLrDQVA0tV9zIiWidMvYc2LVBiI6iJeifsWiZW5JIoIQTEYOeTsdDj9Dit wordt het eerste element van de JWE-blob.
-
Het tweede element van de JWE-blob is leeg, omdat we geen JWE-coderingssleutel leveren.
-
Het derde element van de JWE-blob is de initialisatievector NLND3v9TE68TKPwd. - Gebruik uw JWE-coderingstool om een gecodeerde payload en tag te produceren. In dit voorbeeld zal de niet-versleutelde payload de valse PEM-blob zijn,
ditis een PEM-bestandDe coderingsparameters die u moet gebruiken zijn:
Payload:
is dit een PEM-bestand?Het coderingscijfer is AES 128 GCM
De JOSE-header met base64url als aanvullende geverifieerde gegevens (AAD)
Base64URL codeert de versleutelde payload, wat zou moeten resulteren in F5LLvUwNFKfMZYCo1YJFodHQDit is het vierde element (JWE Ciphertext) in de JWE-blob.
-
Base64URL codeert de tag die u in stap 8 hebt aangemaakt, wat zou moeten resulteren in PE-WDFWGXFFBEO928CFZ1QDit is het vijfde element in de JWE-blob.
-
Voeg de vijf elementen van de JWE-blob samen met punten (JoseHeader.. iv.CipherText.Tag) om het volgende te krijgen:
eYJHBGCIOIJKAXIiLCJJAxNJBY1HY3RpB24ioIJHZGQiLCJJAxNJBY1rZgYiOnSiC2FsdCi6IJvLwLrDqvA0tV9ZiiWiDmVyC2LVBiI6iJeiFSWiZW5JIiQTEYoeDDtsj. 9NLNd3V9TE68TkPwd.f5LLVUWNFKFMZYCO1YJFODHQ.PE-WDFWGXFFBEO928CFZ1Q -
Als u met uw eigen tools dezelfde base64url-gecodeerde waarden hebt afgeleid als we hier weergeven, bent u klaar om ze te gebruiken om de E2E-versleuteling en de geverifieerde identiteit van uw apparaten te beveiligen.
-
Dit voorbeeld zal niet echt werken, maar in principe zou uw volgende stap zijn om de JWE-blob te gebruiken die u hierboven hebt gemaakt als invoer voor het xcommando op het apparaat dat het certificaat toevoegt:
XCommand-beveiligingscertificaten Voeg eYJHBGCIOIJKAxiiLCJJAXNJBY1HY3RpB24ioIJHZgQiLCJJAxNJBY1RZGYIONSIC2FSdCi6IJVLWLrDQVA0TV9ZiIWIDMVyC2LVBii6IJiFSWiZW5JIoIQTEYOEDDTSJ.. 9nL3Ndv9TE68TEJtEdTsJ toetkpwd.f5LLvUwNFKFMzyCo1YJFODHQ.PE-WDFWGXFFBEO928CFZ1Q
Sessietypen voor vergaderingen zonder vertrouwen zijn beschikbaar op alle vergaderlocaties zonder extra kosten. Eén van deze soorten sessies heet Pro-End to End Encryption_VoipOnly. Dit is de naam van de openbare dienst, die we in de toekomst kunnen wijzigen. Voor de huidige namen van de sessietypen, zie Sessietype-ID's in de sectie Referentie van dit artikel.
U hoeft niets te doen om deze mogelijkheid voor uw site te krijgen; u moet wel het nieuwe sessietype (ook wel Meeting Privilege genoemd) toekennen aan gebruikers. U kunt dit individueel 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 . |
| 2 |
Klik op Sites, kies de Webex-site waarvoor u de instellingen wilt wijzigen en klik vervolgens op Instellingen. |
| 3 |
Selecteer onder Algemene instellingen de optie Sessietypen. U zou een of meer sessietypen voor end-to-end encryptie moeten zien. Raadpleeg de lijst met sessietype-ID's in de sectie Referentie van dit artikel. U kunt bijvoorbeeld Pro-End to End Encryption_VoipOnly zien.
Er bestaat een ouder sessietype met een zeer vergelijkbare naam: Pro-End to End Encryption. Dit sessietype omvat niet-versleutelde PSTN-toegang tot vergaderingen. Zorg ervoor dat u de _VoIP-Only-versie hebt om versleuteling van begin tot eind te garanderen. U kunt dit controleren door met de muis over de PRO-link in de kolom met de sessiecode te gaan; in dit geval moet de link bijvoorbeeld We kunnen de namen van openbare diensten voor deze sessietypen in de toekomst wijzigen. |
| 4 |
Als u het nieuwe sessietype nog niet hebt, neem dan contact op met uw Webex-vertegenwoordiger. |
Wat nu te doen
Schakel dit sessietype/vergaderprivilege in voor enkele of al uw gebruikers.
| 1 |
Meld u aan bij Control Hub en ga naar . |
| 2 |
Selecteer een gebruikersaccount om bij te werken en selecteer vervolgens Vergaderingen. |
| 3 |
Selecteer in de keuzelijst Instellingen zijn van toepassing op de vergaderlocatie die u wilt bijwerken. |
| 4 |
Vink het vakje aan naast Pro-End to End Encryption_VoipOnly. |
| 5 |
Sluit het configuratiepaneel voor de gebruiker. |
| 6 |
Herhaal dit voor andere gebruikers, indien nodig. Om dit aan veel gebruikers toe te wijzen, gebruikt u de volgende optie: E2EE-vergaderingen inschakelen voor meerdere gebruikers. |
| 1 |
Meld u aan bij Control Hub en ga naar . |
| 2 |
Klik op Sites, kies de Webex-site waarvoor u de instellingen wilt wijzigen. |
| 3 |
Klik in de sectie Licenties en gebruikers op Bulkbeheer. |
| 4 |
Klik op Rapport genereren en wacht tot we het bestand klaarmaken. |
| 5 |
Als het bestand klaar is, klikt u op Resultaten exporteren en vervolgens op Downloaden. (U moet dat pop-upvenster handmatig sluiten nadat u op Downloaden hebt geklikt.) |
| 6 |
Open het gedownloade CSV-bestand om het te bewerken. Er is een rij voor elke gebruiker, en de |
| 7 |
De Webex CSV-bestandsindeling bevat informatie over het doel en de inhoud van het CSV-bestand. |
| 8 |
Open het configuratiescherm van de vergaderlocatie in de Control Hub. Als u al op de lijstpagina van de vergadersites stond, moet u deze wellicht vernieuwen. |
| 9 |
Klik in de sectie Licenties en gebruikers op Bulkbeheer. |
| 10 |
Klik op Importeren en selecteer het bewerkte CSV-bestand, en klik vervolgens op Importeren. Wacht even terwijl het bestand is geüpload. |
| 11 |
Wanneer het importeren is voltooid, kunt u op Resultaten importeren klikken om te controleren of er fouten zijn opgetreden. |
| 12 |
Ga naar de pagina Gebruikers en open een van de gebruikers om te controleren of ze het nieuwe sessietype hebben. |
U kunt een watermerk toevoegen aan opnamen van vergaderingen met het sessietype Webex MeetingsPro-End to End Encryption_VoipOnly, waarmee u de bronclient of het apparaat kunt identificeren van ongeoorloofde opnames van vertrouwelijke vergaderingen.
Als deze functie is ingeschakeld, bevat de audio van de vergadering een unieke identificatiecode voor elke deelnemende client of apparaat. U kunt audio-opnamen uploaden naar de Control Hub, die vervolgens de opname analyseert en de unieke identificatiegegevens opzoekt. U kunt de resultaten bekijken om te zien welke bron, client of welk apparaat de vergadering heeft opgenomen.
- Om te kunnen 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 opnames analyseren voor vergaderingen die worden georganiseerd door mensen in uw organisatie.
- De informatie over het watermerk wordt even lang bewaard als de informatie over de vergadering van de organisatie.
Audiowatermerken toevoegen aan E2EE-vergaderingen
- Meld u aan bij Control Hub en selecteer vervolgens onder Beheer de optie Organisatie-instellingen.
- Schakel in het gedeelte Watermerken voor vergaderingen de optie Audiowatermerk toevoegen in.
Enige tijd nadat dit is ingeschakeld, zien gebruikers die vergaderingen plannen met het sessietype
Webex MeetingsPro-End to End Encryption_VoipOnlyeen optie voor digitale watermerken in de sectie Beveiliging.
Een vergadering met watermerk uploaden en analyseren
- Selecteer in de Control Hub onder Monitoring de optie Probleemoplossing.
- Klik op Watermerkanalyse.
- Zoek of selecteer de vergadering in de lijst en klik vervolgens op Analyseren.
- Voer in het venster Audiowatermerk analyseren een naam in voor uw analyse.
- (Optioneel) Voer een opmerking in voor uw analyse.
- Sleep het audiobestand dat moet worden geanalyseerd, of klik op Bestand kiezen om naar het audiobestand te bladeren.
- Klik op Sluiten.
Als de analyse is voltooid, wordt deze weergegeven in de lijst met resultaten op de pagina Watermerk analyseren.
- Selecteer de vergadering in de lijst om de resultaten van de analyse te zien. Klik
om de resultaten te downloaden.
Kenmerken en beperkingen
Factoren die een rol spelen bij het succesvol decoderen van een opgenomen watermerk zijn onder meer de afstand tussen het opnameapparaat en de luidspreker die het geluid uitvoert, het volume van dat geluid, omgevingsgeluid, enz. Onze watermerktechnologie is extra veerkrachtig om meerdere keren te worden gecodeerd, zoals kan gebeuren wanneer de media worden gedeeld.
Deze functie is ontworpen om een succesvolle decodering van de watermerk-ID mogelijk te maken in een breed maar redelijk aantal omstandigheden. 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 uit de buurt van de bron wordt geplaatst of niet meer het volledige audiospectrum kan horen, neemt de kans op een succesvolle analyse af.
Om een opname met succes te kunnen analyseren, is een redelijke opname van het geluid van de vergadering nodig. Als het geluid van een vergadering wordt opgenomen op dezelfde computer waarop de client wordt gehost, zouden er geen beperkingen van toepassing moeten zijn.
Als uw apparaten al zijn geïntegreerd in uw Control Hub-organisatie en u de Webex CA wilt gebruiken om automatisch hun identificatiecertificaten te genereren, hoeft u de apparaten niet terug te zetten naar 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 hebt, raden we u aan dit te doen voor al uw apparaten met een „door Cisco geverifieerde” identiteit. Als u Webex niet vertelt welk domein het apparaat identificeert, wordt automatisch een domein gekozen, en dat ziet er misschien verkeerd uit voor andere deelnemers aan de vergadering.
Voordat u begint
Als uw apparaten nog niet aan boord zijn, volg dan Registreer een apparaat om API of lokale webinterface te Cisco Webex gebruiken of onboarding in de cloud voor Board, Desk and Room Series. Controleer ook het domein (en) dat u wilt gebruiken om de apparaten te identificeren in Beheer uw domeinen.
| 1 |
Meld u aan bij Control Hub en selecteer onder Beheer de optie Apparaten. |
| 2 |
Selecteer een apparaat om het configuratiescherm te openen. |
| 3 |
Selecteer het domein dat u wilt gebruiken om dit apparaat te identificeren. |
| 4 |
Herhaal dit voor andere apparaten. |
Voordat u begint
-
Ontvang een door de CA ondertekend certificaat en een privésleutel, in
.pem-formaat, voor elk apparaat. -
Lees op het tabblad Voorbereiden het onderwerp Understanding External Identity Process for Devices,
-
Bereid een JWE-coderingstool voor met betrekking tot de informatie daar.
-
Zorg ervoor dat u een hulpmiddel hebt om willekeurige bytesequenties van bepaalde lengtes te genereren.
-
Zorg ervoor dat u een hulpmiddel hebt om 64url-bytes of tekst te coderen.
-
Zorg ervoor dat u een
scrypt-implementatiehebt. -
Zorg ervoor dat u voor elk apparaat een geheim woord of geheime zin hebt.
| 1 |
Vul de De eerste keer dat u het Het apparaat heeft zijn oorspronkelijke geheim. Vergeet dit niet; u kunt het niet herstellen en u moet het apparaat terugzetten naar de fabrieksinstellingen om opnieuw te kunnen starten.
|
| 2 |
Voeg uw certificaat en privésleutel samen: |
| 3 |
Maak een JWE-blob om te gebruiken als invoer voor de opdracht voor het toevoegen van certificaten: |
| 4 |
Open de TShell op het apparaat en voer de opdracht add (uit meerdere regels) uit: |
| 5 |
Controleer of het certificaat is toegevoegd door Kopieer de vingerafdruk van het nieuwe certificaat. |
| 6 |
Activeer het certificaat voor Het apparaat heeft een versleuteld, actief, door de CA uitgegeven certificaat, dat klaar is om te worden gebruikt om het te identificeren tijdens versleutelde Webex-vergaderingen van begin tot eind.
|
| 7 |
Maak het apparaat aan boord van uw Control Hub-organisatie. |
| 1 |
Plan een vergadering van het juiste type (Webex MeetingsPro-End to End Encryption_VoipOnly). |
| 2 |
Neem deel aan de vergadering als gastheer, van een Webex Meetings klant. |
| 3 |
Neem deel aan de vergadering vanaf een apparaat waarvan de identiteit is geverifieerd door de Webex CA. |
| 4 |
Controleer als host of dit apparaat in de lobby verschijnt met het juiste identiteitspictogram. |
| 5 |
Neem deel aan de vergadering vanaf een apparaat waarvan de identiteit is geverifieerd door een externe CA. |
| 6 |
Controleer als host of dit apparaat in de lobby verschijnt met het juiste identiteitspictogram. Meer informatie over identiteitspictogrammen. |
| 7 |
Neem deel aan de vergadering als niet-geverifieerde deelnemer aan de vergadering. |
| 8 |
Controleer als gastheer of deze deelnemer in de lobby verschijnt met het juiste identiteitspictogram. |
| 9 |
Als gastheer kunt u personen/apparaten toelaten of weigeren. |
| 10 |
Valideer waar mogelijk de identiteit van de deelnemers/apparaten door de certificaten te controleren. |
| 11 |
Controleer of iedereen in de vergadering dezelfde beveiligingscode ziet. |
| 12 |
Neem deel aan de vergadering met een nieuwe deelnemer. |
| 13 |
Controleer of iedereen dezelfde, nieuwe beveiligingscode voor vergaderingen ziet. |
-
Gaat u van end-to-end versleutelde vergaderingen de standaardvergaderoptie maken, of deze alleen voor bepaalde gebruikers inschakelen, of alle hosts laten beslissen? Als u hebt besloten hoe u deze functie gaat gebruiken, bereid dan de gebruikers voor die deze zullen gebruiken, vooral met betrekking tot de beperkingen en wat u tijdens de vergadering kunt verwachten.
-
Moet u ervoor zorgen dat noch Cisco, noch iemand anders uw inhoud kan ontsleutelen of zich als uw apparaten kan voordoen? Zo ja, dan hebt u certificaten nodig van een openbare CA.
-
Als u verschillende niveaus van identiteitsverificatie hebt, stel gebruikers dan in staat elkaar te verifiëren met een identiteitsbewijs dat ondersteund wordt door een certificaat. Hoewel er omstandigheden zijn waarin deelnemers als niet-geverifieerd kunnen verschijnen en deelnemers moeten weten hoe ze dit moeten controleren, zijn niet-geverifieerde mensen misschien geen bedriegers.
Als u een externe CA gebruikt om certificaten voor uw apparaat uit te geven, is het aan u om certificaten te controleren, te vernieuwen en opnieuw toe te passen.
Als u het oorspronkelijke geheim hebt gemaakt, begrijp dan dat uw gebruikers misschien het geheim van hun apparaat willen wijzigen. Misschien moet u een interface maken/een tool distribueren om hen in staat te stellen dit te doen.
|
Type-ID van de sessie |
Naam van de openbare dienst |
|---|---|
|
638 |
E2E-codering+alleen VoIP |
|
652 |
Encryptie van begin tot eind, alleen voor VoIP |
|
660 |
Pro 3: Encryptie van begin tot eind: alleen VoIP E2E-versleuteling + identiteit |
|
672 |
Pro 3 Gratis versleuteling van begin tot eind, alleen VoIP |
|
673 |
Onderwijsinstructeur E2E Encryption_Alleen VoIP |
|
676 |
Broadworks Standard plus versleuteling van begin tot eind |
|
677 |
Broadworks Premium plus versleuteling van begin tot eind |
|
681 |
Schoology Free plus versleuteling van begin tot eind |
In deze tabellen worden API-opdrachten van Webex-apparaten beschreven die we hebben toegevoegd voor versleutelde vergaderingen van begin tot eind en voor geverifieerde identiteit. Zie Toegang tot de API voor apparaten uit de Board-, Desk- en Room-serie voor apparaten uit de Board-, Desk- en Room Series voor meer informatie over het gebruik van de API.
Deze xAPI-opdrachten zijn alleen beschikbaar op apparaten die:
-
Geregistreerd bij Webex
-
Op locatie geregistreerd en gekoppeld aan Webex met for Devices Webex Edge
|
API-aanroep |
Beschrijving |
|---|---|
|
|
Deze configuratie wordt gemaakt wanneer de beheerder via de Control Hub het voorkeursdomein van het apparaat instelt. 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 beschikt over een actief, extern uitgegeven certificaat om zichzelf te identificeren. |
|
|
Geeft aan of het apparaat kan deelnemen aan een versleutelde vergadering van begin tot eind. De cloud-API roept dit aan, zodat een gekoppelde app weet of de app het apparaat kan gebruiken om lid te worden. |
|
|
Geeft aan of het apparaat |
|
|
De identiteit van het apparaat zoals afgelezen uit de Common Name van het extern uitgegeven certificaat. |
|
|
Leest specifieke informatie uit een extern uitgegeven certificaat. In de getoonde opdracht vervangt u
|
|
|
De status van de externe identiteit van het apparaat (bijvoorbeeld |
|
|
Geeft aan of het apparaat een geldig certificaat heeft dat is uitgegeven door de Webex CA. |
|
|
De identiteit van het apparaat zoals gelezen uit de Common Name 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 bevindt die meerdere domeinen heeft, is dit de waarde van het |
|
|
Leest specifieke informatie uit het door WebEx uitgegeven certificaat. In de getoonde opdracht vervangt u
|
|
API-aanroep |
Beschrijving |
|---|---|
|
|
|
API-aanroep |
Beschrijving |
|---|---|
of
| Accepteert een basis64url-gecodeerde waarde in platte tekst om het cliëntgeheim voor de eerste keer op het apparaat te plaatsen. Om het geheim na die eerste keer bij te werken, moet u een JWE-blob aanleveren met het nieuwe geheim, versleuteld met het oude geheim. |
| Voegt een certificaat toe (met privésleutel). We hebben deze opdracht uitgebreid om een JWE-blob te accepteren die de gecodeerde PEM-gegevens bevat. |
| Activeert een specifiek certificaat voor WebExIdentity. Voor dit |
| Deactiveert een specifiek certificaat voor WebExIdentity. Voor dit |
