Gebruikers kiezen de nieuwe vergaderingstype ze een vergadering plannen. Wanneer de host deelnemers vanuit de lobby toelaat en tijdens de vergadering, kan de host de identiteitsverificatiestatus van elke deelnemer zien. Er is ook een vergaderingscode die gebruikelijk is voor alle huidige deelnemers aan de vergadering, die ze kunnen gebruiken om elkaar te verifiëren.

Deel de volgende informatie met de hosts van uw vergadering:

Identiteit verifiëren

end-to-end identiteitsverificatie biedt aanvullende beveiliging voor een end-to-end gecodeerde vergadering.

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

Gebruikers van de Webex Meetings-app zich verifiëren bij de Identiteitsopslag van Webex, waarmee ze een toegangstoken krijgen als het lukt. Als ze een certificaat nodig hebben om hun identiteit te verifiëren - in een end-to-end gecodeerde vergadering - geeft de Webex CA een certificaat uit op basis van hun toegangs token. We bieden gebruikers nog geen manier Webex Meetings een certificaat te krijgen dat is uitgegeven door een externe/externe CA.

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

  • In het geval van een interne certificeringsinstantie geeft Webex een intern certificaat uit op basis van het toegangs token 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. Webex gebruikt (een van) het domein(en) van uw organisatie bij het schrijven van de identiteit van het apparaatcertificaat (Common Name (CN)).

  • Voor het externe CA-geval vraagt u apparaatcertificaten aan en aankoopt u rechtstreeks bij de door u gekozen vergever. U moet de certificaten coderen, rechtstreeks uploaden en autoreren met een geheim dat alleen aan u bekend is.

    Er is geen cisco betrokken. Dit is de manier waarop u waar end-to-end-codering en geverifieerde identiteit kunt garanderen en voorkom dat Cisco uw vergadering kan afsluisteren/decoderen van uw media.

Apparaatcertificaat dat intern is uitgegeven

Webex geeft een certificaat aan het apparaat uit wanneer dit is 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 uit zonder domein.

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 gebruikmaken van de API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

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

Extern uitgegeven apparaatcertificaat

Een beheerder kan een apparaat voorzien van zijn/haar eigen certificaat dat is ondertekend met een van de openbare certificeringscertificaten.

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

De waarden in het certificaat hebben de discretie van de organisatie. De algemene naam (CN) en alternatieve naam van onderwerp (SAN) worden weergegeven in de gebruikersinterface van Webex-vergadering, zoals beschreven in End-to-end-codering met identiteitsverificatie voor Webex Meetings.

Het wordt aanbevolen om een afzonderlijk certificaat per apparaat en een unieke cn per apparaat te gebruiken. Dit kan bijvoorbeeld 'meeting-room-1.example.com' zijn voor de organisatie die eigenaar is van het example.com domein.

Om het externe certificaat volledig te beschermen tegen manipulatie, wordt een geheime functie van de client gebruikt om verschillende xcommands te coderen en te ondertekenen.

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

Momenteel bevat Webex API-opdrachten om dit te beheren.

Apparaten

In de cloud Webex Room apparaten uit de Webex Desk-serie kunnen end-to-end gecodeerde vergaderingen worden bijwonen, waaronder:

  • Webex Board

  • Webex Desk Pro

  • Webex-bureau

  • Webex Room Kit

  • Webex Room Kit Mini

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

  • Webex C-serie

  • Webex DX-serie

  • Webex EX-serie

  • Webex MX-serie

  • SIP-apparaten van derden

Software-clients

  • Vanaf 41.7 kan de Webex Meetings aan end-to-end gecodeerde vergaderingen deelnemen.

  • De Webex-app kan niet deelnemen aan end-to-end gecodeerde vergaderingen.

    Als uw organisatie de Webex-app in staat stelt deel te nemen aan vergaderingen door de Meetings-bureaubladtoepassing te starten, kunt u die optie gebruiken om end-to-end gecodeerde vergaderingen bij te wonen.

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

  • Sip-soft clients van derden kunnen niet deelnemen aan end-to-end-gecodeerde vergaderingen.

Identiteit

  • We bieden u geen Control Hub-opties voor het beheren van extern geverifieerde apparaatidentiteiten. Deze beslissing is zo'n ontwerp, omdat voor echte end-to-end-codering alleen u het geheimen en de sleutels kent/dient te openen. Als we een cloudservice geïntroduceerd hebben om deze sleutels te beheren, kunnen ze worden onderschept.

  • We bieden momenteel geen hulpprogramma's om u te helpen bij het aanvragen of versleutelen van uw apparaatidentiteitscertificaten en hun privésleutels. We bieden u nu een 'recept' voor het ontwerpen van uw eigen tools, op basis van coderingstechnieken op basis van branchestandaarden, om te helpen bij deze processen. We willen geen echte of ervaren toegang tot uw geheimen of sleutels.

Vergaderingen

  • end-to-end gecodeerde vergaderingen ondersteunen momenteel maximaal 200 deelnemers.

  • Van deze 200 deelnemers kunnen maximaal 25 extern geverifieerde apparaten deelnemen en moeten zij de eerste deelnemers zijn die aan de vergaderingdeelnemen.

    Wanneer een groter aantal apparaten deel gaat nemen aan een vergadering, proberen onze backend-mediaservices de mediastreams te transcoderen. Als we de media niet kunnen decoderen, transcoderen en opnieuw coderen (omdat de coderingssleutels van het apparaat niet en mogen we deze niet hebben), mislukt de transcodering.

    Als u deze beperking wilt verminderen, raden we kleinere vergaderingen voor apparaten aan of verzenden we de uitnodigingen tussen apparaten en Meetings-clients.

Beheerinterface

We raden u met veel raad aan Control Hub te gebruiken om uw vergaderingssite te beheren.

De hoofd reden hiervoor is het verschil tussen de manier waarop Control Hub en Sitebeheer beheren van identiteit. Control Hub-organisaties hebben de identiteit voor de hele organisatie gecentraliseerd en tegelijkertijd Sitebeheer wordt de identiteit op site-basis beheerd.

Dit betekent dat u de optie Geverifieerde identiteit van Cisco niet kunt hebben voor gebruikers die worden beheerd vanuit Sitebeheer. Deze gebruikers krijgen een anoniem certificaat om deel te nemen aan een end-to-end gecodeerde vergadering, en ze kunnen worden uitgesloten van vergaderingen waar de host de identiteit wil garanderen.

Gerelateerde informatie

Voorbeeld van JWE-amanmanen

Voorbeeld van een correct gecodeerd JWE op basis van bepaalde parameters (bijlage)

  • Webex Meetings 41.7.

  • Cloud-geregistreerde Webex Room en Webex Desk-apparaten, uitgevoerd 10.6.1-RoomOS_August_2021.

  • Beheertoegang tot de vergaderingssite in Control Hub om de nieuwe versie van sessietype gebruikers in teschakelen.

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

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

Voor het hoogste beveiligingsniveau en voor identiteitsverificatie moet elk apparaat een uniek certificaat hebben dat is uitgegeven door een vertrouwde openbare certificeringsinstantie.

U moet communiceren met de CA om de digitale certificaten aan te vragen, aan te schaffen en te ontvangen en de bijbehorende privésleutels te maken. Bij het aanvragen van het certificaat zijn dit de parameters die moeten worden gebruikt:

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

  • Unieke: We raden sterk aan om een uniek certificaat voor elk apparaat te gebruiken. Als u één certificaat voor alle apparaten gebruikt, doet u niet meer uw veiligheid.

  • Algemene naam (CN) en Onderwerp alternatieve naam/namen (SAN/s): Deze zijn niet belangrijk voor Webex, maar moeten waarden zijn die mensen kunnen lezen en aan het apparaat kunnen koppelen. De algemene naam wordt aan andere deelnemers van de vergadering weergeven als 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 deze namen gebruiken als name.model@example.com maar het is uw keuze.

  • Bestandsindeling: De certificaten en sleutels moeten de indeling .pem hebben.

  • Purpose: 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 niet een externe geverifieerde identiteit wilt gebruiken met uw apparaten.

Als u nieuwe apparaten gebruikt, registreert u deze nog niet bij Webex. Het is nog niet mogelijk om deze met het netwerk te verbinden.

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

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

  • Plan een venster wanneer de apparaten niet worden gebruikt of gebruik een gefaseeerde aanpak. Informeer gebruikers over de wijzigingen die ze kunnen verwachten.

  • Zorg voor fysieke toegang tot apparaten. Als u apparaten via het netwerk moet openen, moet u weten dat geheimen in platte tekst reizen en u uw veiligheid in gevaar brengen.

Om te verzekeren dat de media van uw apparaat niet door iedereen behalve het apparaat kan worden gecodeerd, moet u de privésleutel op het apparaat coderen. We hebben API's ontworpen voor het apparaat om het beheer van de gecodeerde sleutel en het certificaat mogelijk te maken met behulp van JSON Web Encryption (JWE).

Om een waar end-to-end-codering via onze cloud te waarborgen, kunnen we niet worden betrokken bij het coderen en uploaden van het certificaat en de sleutel. Als u dit beveiligingsniveau nodig hebt, kunt u het volgende doen:

  • Verzoek uw certificaten.

  • Genereer de sleutelparen van uw certificaat.

  • Maak (en bescherm) een geheim in eerste instantie voor elk apparaat, om de coderingsfunctie van het apparaat te gebruiken.

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

    Hieronder worden het proces en de (niet-geheime) parameters uitgelegd die u nodig hebt en een recept dat u kunt volgen in uw ontwikkelhulpmiddelen. We bieden ook enkele testgegevens en de resulterende JWE-gegevens zoals we deze verwachten, om u te helpen uw proces te verifiëren.

    Een niet-ondersteunde referentie-implementatie met Cisco JWCrypto en de JWCrypto-bibliotheek is op aanvraag beschikbaar in Cisco.

  • Het certificaat en de sleutel samenvoegen en coderen met behulp van uw hulpmiddel en het eerste geheim van het apparaat.

  • Upload het hieruit voortkomende JWE naar het apparaat.

  • Stel het doel van het gecodeerde certificaat in dat wordt gebruikt voor de Webex-identiteit en activeer het certificaat.

  • (Aanbevolen) Een interface aan uw hulpprogramma leveren (of distribueren), zodat apparaatgebruikers het aanvankelijke geheim kunnen wijzigen (om hun media tegen u te beschermen!).

Hoe gebruiken we de JWE-indeling

Dit gedeelte beschrijft hoe we verwachten dat het JWE zal worden gemaakt als invoer voor de apparaten, zodat u uw eigen hulpprogramma kunt maken om de certificaten en sleutels te maken.

U raadpleegt JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516 en JSON Web Signature (JWS).https://datatracker.ietf.org/doc/html/rfc7515

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

  • JOSE Header (beveiligd). In de koptekst JSON-objectondertekening en -codering moet u de volgende sleutelwaardeparen opnemen:

    • "alg":"dir"

      Het directe algoritme is het enige algoritme dat we ondersteunen voor de versleuteling van de payload. U moet het initiale client geheim van het apparaat gebruiken.

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

      We ondersteunen deze twee coderingsalgoritmen.

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

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

      We hebben de naam ervan genoemd cisco-action om potentiële klanten met toekomstige JWE-extensies te verminderen.

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

      Een andere eigen sleutel. We gebruiken de waarden die u opgeef als invoer voor sleutelcodes op het apparaat. Het bericht version moet zijn 1(de versie van onze sleutelhangerfunctie). De waarde van salt moet een reeks met basis64-URL's van ten minste 4 bytes zijn, die u willekeurig moet kiezen.

  • JWE gecodeerde sleutel. Dit veld is leeg. Het apparaat is afgeleid van de eerste ClientSecret.

  • JWE initialisatie Vector. U moet een in base64url gecodeerde initialisatie-vector invoeren voor het decoderen van de payload. De IV MOET een willekeurige waarde van 12 byte zijn (we gebruiken de AES-GCM-versleutelingsketen, waarvoor de IV 12 bytes lang moet zijn).

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

  • JWEVersleuteling: Dit is de gecodeerde payload die u geheim wilt houden.

    De payload KAN leeg zijn (bijvoorbeeld om het client geheim te herstellen, moet u het 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. U moet het doel van de payload opgeven met de cisco-action sleutel als volgt:

    • Met "cisco-action":"populate" de versleuteling is de nieuwe ClientSecret

    • Met " "cisco-action":"add" de codetekst is een PEM-certificaat en de privésleutel (samengegaan)

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

    • Met " "cisco-action":"deactivate" de codetekst is de vingerafdruk (hexadecimale weergave van sha-1) van het certificaat dat wordt gedeactiveerd voor verificatie van de apparaatidentiteit

  • JWE-verificatie tag: Dit veld bevat de verificatietag om de integriteit van het gehele JWE-compact seriële codeer te bepalen

Hoe we de coderingssleutel afgeleid zijn van de ClientSecret

Na de eerste inwoners van het geheim accepteren of output we deze geheim niet als platte tekst. Dit is om mogelijke woordenboekaanvallen te voorkomen door iemand die toegang heeft tot het apparaat.

De apparaatsoftware gebruikt het client geheim als invoer voor een sleutelversleutelingsfunctie (kdf) en gebruikt vervolgens de afgeleide sleutel voor inhoudsdecodering/-codering op het apparaat.

Wat dit voor u betekent, is dat uw tool voor het produceren van JWE-gegevens dezelfde procedure moet volgen om dezelfde codering/decoderingssleutel te afgeleid van het client geheim.

De apparaten gebruiken scrypten voor sleutelcodering (zie https://en.wikipedia.org/wiki/Scrypt), met de volgende parameters:

  • CostFactor (N) is 32768

  • BlockSizeFactor (r) is 8

  • Parallelisatiefactor (p) is 1

  • Het gaat om een willekeurige reeks van minimaal 4 bytes; moet u deze dezelfde salt bij het opgeven van de cisco-kdf gebruiken.

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

  • Max. geheugen cap is 64 MB

Deze set parameters is de enige configuratie van scrypt die compatibel is met de sleutelcodefunctie op de apparaten. Dit kdf op de apparaten wordt gebeld "version":"1", dit is de enige versie die momenteel wordt gebruikt door de cisco-kdf gebruiken.

Voorbeeld gewerkt

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

In het voorbeeldscenario wordt een PEM-certificaat aan het apparaat toegevoegd (nabootsen bij het toevoegen van een certificaat, met een zeer korte tekenreeks in plaats van een volledig cert + key). Het client geheim in het voorbeeld is ossifrage.

  1. Kies een coderingscode. In dit voorbeeld wordt A128GCM(AES met 128-bits toetsen in de Galois-tellermodus). Uw tool kan A256GCM als u dat wilt.

  2. Kies eenje (moet een willekeurige volgorde zijn van ten minste 4 bytes). In dit voorbeeld wordt gebruikgemaakt van (hex bytes) E5 E6 53 08 03 F8 33 F6. De volgorde van de base64url coderen om 5eZTCAP4M_Y(verwijder de basis64-opvulling).

  3. Hier is een voorbeeld scrypt gesprek om de inhoud coderingssleutel maken (cek):

    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 die base64url-coderingen aan lZ66bdEiAQV4_mqdInj_rA.

  4. Kies een willekeurige volgorde van 12 bytes om te gebruiken als initialisatie vector. In dit voorbeeld wordt (hex) gebruikt 34 b3 5d dd 5f 53 7b af 2d 92 95 83 die base64url-coderingen aan NLNd3V9Te68tkpWD.

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

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

    De base64url gecodeerde JOSE-koptekst is eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Dit is het eerste element van het JWE-bestand.

  6. Het tweede element van het JWE-bestand is leeg, omdat we geen JWE-ruimte hebben coderingssleutel.

  7. Het derde element van de JWE-initiatie-vector is de initialisatie-vector NLNd3V9Te68tkpWD.

  8. Gebruik uw JWE-coderingstool om een gecodeerde payload en tag te produceren. Voorbeeld: de ongecodeerde payload wordt de valse PEM-bel this is a PEM file

    De coderingsparameters die u moet gebruiken zijn:

    • Payload is this is a PEM file

    • Coderingscode is AES 128 GCM

    • De base64url-koptekst van JOSE gecodeerd als Additional Authenticated Data (AAD)

    Base64url de gecodeerde payload coderen, wat zou moeten resulteren in f5lLVuWNfKfmzYCo1YJfODhQ

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

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

    Dit is het vijfde element in het JWE-bestand.

  10. De vijf elementen van het JWE- of het JWE- of de stippen samenvoegen met dots (OOK WELDE-header). IV.Ciphertext.Tag) voor het volgende:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Als u dezelfde base64url-gecodeerde waarden hebt afgeleid als wij hier met behulp van uw eigen tools, bent u klaar om deze te gebruiken om de E2E-codering en de geverifieerde identiteit van uw apparaten te beveiligen.

  12. Dit voorbeeld werkt niet echt, maar binnen de volgende stap zou u het JWE-bericht moeten gebruiken dat u hierboven hebt gemaakt als invoer voor de xcommand op het apparaat waarin het certificaat is toegevoegd:

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

Er zijn nieuwe sessietypen voor vergaderingen zonder vertrouwen die we zonder extra kosten naar alle vergaderingssites worden uitgerold. Een van de nieuwe sessietypen wordt genoemd Pro-End to End Encryption_VOIPonly. Dit is de naam van de openbare service die we in de toekomst kunnen wijzigen. Zie Sessietype-ID's in het gedeelte Referentie van dit artikel voor de huidige namen van de sessietypen.

Er is niets dat u hoeft te doen om de nieuwe functionaliteit voor uw site te krijgen, maar u zult de nieuwe sessietype (ook wel Vergaderrecht genoemd) aan gebruikers moeten geven. U kunt dit individueel doen via de configuratiepagina van de gebruiker, of in bulk met een retour met CSV-export/-import.

1

Meld u aan bij Control Hub en open de pagina Vergadering.

2

Klik op uw sitenaam om het configuratiescherm van de site te openen.

3

Klik op Site configureren.

4

Klik in het gedeelte Algemene instellingen opSessietypen.

Op die pagina wordt een of meer sessietypen voor end-to-end-codering weergegeven. Raadpleeg de lijst met sessietype-ED's in het gedeelte met referentie van dit artikel. Zie bijvoorbeeld Pro-end tot end-Encryption_VOIPonly.

 

Er is een ouder sessietype met een zeer vergelijkbare naam: Pro-end-to-end-codering. Deze sessietype bevat niet-gecodeerde PSTN toegang tot vergaderingen. Zorg ervoor dat u over de _VOIPonly-versie hebt om end-to-end-codering te garanderen. U kunt controleren door met de muis over de PRO-koppeling in de kolom sessiecode te bewegen. In dit voorbeeld moet het doel van de koppeling zijnjavascript:ShowFeature(652).

Mogelijk wijzigen we de namen van openbare service voor deze sessietypen in de toekomst. We zijn bijvoorbeeld van plan om Pro-end te wijzigen voor end-Encryption_VOIPonly naarE2E-codering +identiteit.

5

Als u de nieuwe versie nog niet sessietype, neem dan contact op met uw Webex-vertegenwoordiger.

De volgende stap

Schakel deze sessietype/vergaderingsrechten in voor bepaalde of al uw gebruikers.

1

Klik op Gebruikers en selecteer een gebruiker om het configuratiescherm van de gebruiker te openen.

2

Klik in het gedeelte Services op Cisco Webex Meetings.

3

Selecteer de site (als de gebruiker er meer dan één heeft) en klik op Host.

4

Vink het selectievakje naast het Webex Meetings de vermelding Pro-end-to-end Encryption_VOIPonly.

5

Sluit het configuratiescherm van de gebruiker.

6

Herhaal dit indien nodig voor andere gebruikers.

Als u dit aan veel gebruikers wilt toewijzen, gebruikt u de csv-bulkoptie.

1

Meld u aan bij Control Hub op https://admin.webex.com en open de vergaderingspagina.

2

Klik op uw sitenaam om het configuratiescherm van de site te openen.

3

Klik in het gedeelte Licenties en gebruikers op Bulkbeheren.

4

Klik op Exporteren en wacht terwijl we het bestandvoorbereiden.

5

Wanneer het bestand gereed is, klikt u op Exportresultaten en vervolgens opDownloaden. (U moet dat pop-upvenster handmatig sluiten nadat u op Downloaden.)

6

Open het gedownloade CSV-bestand om te bewerken.

Er is een rij voor elke gebruiker en de MeetingPrivilege kolom bevat sessietype de lijst met door komma's scheidingstekens vermelde tekst.

7

Voor elke gebruiker die u de nieuwe versie wilt sessietype, voegt u 1561 als een nieuwe waarde in de door komma's scheidingstekens van de lijst MeetingPrivilege Cel.

De verwijzing naar de CSV-bestandsindeling in heeft enige https://help.webex.com/en-us/5vox83 informatie over het doel en de inhoud van het CSV-bestand.

8

Open het configuratiescherm van de Vergaderingssite in Control Hub.

Als u al op de pagina met de lijst met vergaderingssite's staat, moet u deze mogelijk vernieuwen.

9

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

10

Klik op Importeren en selecteer het bewerkte CSV-bestand en klik vervolgens op Importeren. Wacht terwijl we het bestand uploaden.

11

Wanneer het importeren is voltooid, kunt u klikken op Importeerresultaten om te controleren of er fouten zijn.

12

Ga naar de pagina Gebruikers en open een van de gebruikers om te controleren of de nieuwe versie sessietype.

Als uw apparaten al zijn aangesloten op uw Control Hub-organisatie en u de Webex CA wilt gebruiken om de identificerende certificaten automatisch te genereren, hoeft u de apparaten niet opnieuw in te stellen in 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 identiteit 'Geverifieerde identiteit van Cisco'. Als u niet weet welk domein het apparaat identificeert, kiezen wij er een en ziet het er mogelijk verkeerd uit voor andere deelnemers aan de vergadering.

Voordat u begint

Als uw apparaten nog niet zijn aangesloten, kunt u volgen https://help.webex.com/n25jyr8 of https://help.webex.com/nutc0dy. U moet ook het domein/de domeinen verifiëren die u wilt gebruiken om de apparaten te identificeren (https://help.webex.com/cd6d84).

1

Meld u aan bij Control Hub (https://admin.webex.com) en open de pagina 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

U hebt het volgende nodig:

  • Als u een certificaat en privésleutel met EEN CA-handtekening wilt krijgen, moet u voor elk apparaat de indeling .pem hebben.

  • Als u het onderwerp Begrijpen van extern identiteitsproces voor apparaten wilt lezen, gaat u naar Het gedeelte voorbereiden van dit artikel.

  • Een JWE-coderingstool voorbereiden op de informatie daar.

  • Een tool om willekeurige bytereeksen van de opgegeven lengtes te genereren.

  • Een tool om base64url gecodeerde bytes of tekst te gebruiken.

  • Een scrypt Uitvoering.

  • Een geheim woord of woordgroep voor elk apparaat.

1

Vul het apparaat ClientSecret met een geheim tekst zonder platte tekst:

De eerste keer dat u de Secret, u levert deze in platte tekst. Daarom raden we u aan dit op de fysieke apparaatconsole te doen.

  1. Base64url het geheime zinsdeel voor dit apparaat coderen.

  2. Open het TShell op het apparaat.

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

    Met de voorbeeldopdracht hierboven wordt het Secret met de zin 0123456789abcdef. U moet uw eigen kiezen.

Het apparaat heeft een initieel geheim. Vergeet dit niet, u kunt deze niet herstellen en moet het apparaat terugzetten naar de fabrieksinstellingen om opnieuw te starten.
2

Uw certificaat en privésleutel samenvoegen:

  1. Gebruik een teksteditor om de .pem-bestanden te openen, plak de sleutel in het certificaat en sla het op als een nieuw .pem-bestand.

    (Dit is de payloadtekst die u codert en in uw JWE-ruimte zet)

3

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

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

  2. Afgeleid van een coderingssleutel met uw scrypt-tool.

    Hiervoor hebt u het geheim, de gegevens en een keylength nodig die overeenkomen met uw gekozen coderingscode. Er zijn enkele andere vaste waarden om op te geven (N=32768, r=8, p=1). Het apparaat gebruikt hetzelfde proces en de waarden zijn afgeleid van dezelfde inhoud coderingssleutel.

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

  4. Een JOSE-koptekst maken, instellen alg, enc en cisco-kdf toetsen zoals beschreven in Het proces voor externe identiteit begrijpen voor apparaten. Stel de actie 'toevoegen' in met behulp van de key:value "cisco-action":"add" in de koptekst JOSE (omdat het certificaat aan het apparaat wordt toegevoegd).

  5. Base64url decoderen van de JOSE-koptekst.

  6. Gebruik uw JWE-coderingstool met de gekozen versleuteling en de base64url-gecodeerde JOSE-koptekst om de tekst uit het samengestelde pem-bestand te coderen.

  7. Base64url de initialisatie vector, de gecodeerde PEM-payload en de verificatietag coderen.

  8. Bouw de JWE-eer als volgt (alle waarden zijn base64url gecodeerd):

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Open het TShell op het apparaat en voer de opdracht (meerregelen) toevoegen uit:

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

Controleer of het certificaat is toegevoegd door het actief te maken xcommand Security Certificates Services Show

Kopieer de vingerafdruk van het nieuwe certificaat.

6

Activeer het certificaat met het doel WebexIdentity:

  1. De vingerafdruk van het certificaat lezen, ofwel van het certificaat zelf, of van de uitvoer van xcommand Security Certificates Services Show.

  2. Maak een willekeurige reeks van minimaal 4 bytes en codeer die reeks base64url. Dit is uw naam.

  3. Afgeleid van een coderingssleutel met uw scrypt-tool.

    Hiervoor hebt u het geheim, de gegevens en een keylength nodig die overeenkomen met uw gekozen coderingscode. Er zijn enkele andere vaste waarden om op te geven (N=32768, r=8, p=1). Het apparaat gebruikt hetzelfde proces en de waarden zijn afgeleid van dezelfde inhoud coderingssleutel.

  4. Maak een willekeurige reeks van exact 12 bytes en codeer die reeks base64url. Dit is uw initialisatie vector.

  5. Een JOSE-koptekst maken, instellen alg, enc en cisco-kdf toetsen zoals beschreven in Het proces voor externe identiteit begrijpen voor apparaten. Stel de actie 'activeren' in met behulp van de key:value "cisco-action":"activate" in uw koptekst JOSE (omdat het certificaat op het apparaat wordt geactiveerd).

  6. Base64url decoderen van de JOSE-koptekst.

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

    De tool moet een reeks van 16 of 32 byte uitvoeren, afhankelijk van of u 128- of 256-bits AES-GCM hebt gekozen en een verificatietag.

  8. Base64urlencode de gecodeerde vingerafdruk en de verificatietag.

  9. Bouw de JWE-eer als volgt (alle waarden zijn base64url gecodeerd):

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Open het 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 gecodeerd, actief, ca-uitgegeven certificaat dat kan worden gebruikt om het te identificeren in end-to-end gecodeerde Webex-vergaderingen.
7

Onboard het apparaat naar uw Control Hub-organisatie.

1

Plan een vergadering van het juiste type(Webex Meetings End-to-end -Encryption_VOIPonly).

2

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

3

Deelnemen aan de vergadering vanaf een apparaat dat is geverifieerd door de Webex CA.

4

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

5

Deelnemen aan de vergadering vanaf een apparaat dat is geverifieerd door een externe CA.

6

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

7

Deelnemen aan de vergadering als een niet-nautische deelnemer aan de vergadering.

8

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

9

Als host kunt u personen/apparaten toelaten of weigeren.

10

Valideer waar mogelijk de identiteiten van deelnemers/apparaten 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 een vergadering ziet.

Gaat u end-to-end gecodeerde vergaderingen instellen als de standaardversleutelingsoptie voor vergaderingen, of wilt u deze alleen voor bepaalde gebruikers inschakelen, of wilt u alle hosts laten beslissen? Wanneer u hebt besloten hoe u deze functie gaat gebruiken, bereidt u de gebruikers voor die deze gaan gebruiken, vooral met betrekking tot de beperkingen en wat er in de vergadering te verwachten is.

Moet u ervoor zorgen dat Cisco en niemand anders uw inhoud kan decoderen of zich kan uitgeven voor uw apparaten? In dat certificaat hebt u certificaten van een openbare certificerings- of certificeringsstantie nodig. Mogelijk hebt u maximaal 25 apparaten in een beveiligde vergadering. Als u dit beveiligingsniveau nodig hebt, mag u niet toestaan dat vergaderingsklanten deelnemen.

Voor gebruikers die met een beveiligd apparaat deelnemen, moet u apparaten eerst laten deelnemen en de verwachtingen van gebruikers stel dat ze mogelijk niet kunnen deelnemen als ze te laat deelnemen.

Als u verschillende niveaus van identiteitsverificatie hebt, kunnen gebruikers elkaar in staat stellen om elkaar te verifiëren met identiteit die is teruggeboekt en de beveiligingscode voor de vergadering. Zelfs als er omstandigheden zijn waarin deelnemers als Niet geverifieerd kunnen worden weergegeven en deelnemers moeten weten hoe ze moeten controleren, zijn niet-geverifieerde personen mogelijk geen chatpostors.

Als u een externe CA gebruikt om uw apparaatcertificaten uit te geven, staat de e-mail op u om certificaten te controleren, vernieuwen en opnieuw toe te staan.

Als u het aanvankelijke geheim hebt gemaakt, begrijpt u dat uw gebruikers het geheim van hun apparaat kunnen 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 gecodeerde vergaderingen

Sessietype-id

Naam openbare service

638

E2E-codering+VoIP

652

Pro-end-to-end Encryption_VOIPonly

660

Pro 3 gratis end-to-end Encryption_VOIPonly

E2E-codering + identiteit

672

Pro 3 Free50-End tot eind Encryption_VOIPonly

673

Education Instructeur E2E Encryption_VOIPonly

676

Broadworks Standard plus end-to-end-codering

677

Broadworks Premium plus end-to-end-codering

681

Een gratis dataologie plus end-to-end-codering

Deze tabellen beschrijven webex-apparaten API-opdrachten die we hebben toegevoegd voor end-to-end gecodeerde vergaderingen en geverifieerde identiteit. Zie voor meer informatie over het gebruik van de https://help.webex.com/nzwo1okAPI.

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

API-aanroep

Beschrijving

xConfiguration Conference EndToEndEncryption Mode: On

Schakelt end-to-end-coderingsmodus in On of Off.

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Deze configuratie wordt gemaakt wanneer de beheerder het voorkeursdomein van het apparaat in stelt vanuit Control Hub. Alleen noodzakelijk als de organisatie meer dan één domein heeft.

Het apparaat gebruikt dit domein als er een certificaat wordt gevraagd van 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 gecodeerde vergadering. De cloud-API belt deze aan zodat een gekoppelde app weet of het apparaat kan worden gebruikt om deel te nemen.

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Geeft aan of het apparaat een geldig extern uitgegeven certificaat heeft.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

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

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Leest de certificaatgegevens van het extern uitgegeven certificaat en outputs het als een JSON-certificaat.

xStatus Conference EndToEndEncryption InternalIdentity Valid

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 vanuit de algemene naam van het Webex-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 heeft, is dit de waarde uit de PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Leest de certificaatgegevens van het door Webex uitgegeven certificaat en outputs het als een JSON-certificaat.

Tabel 3. API's in het gesprek voor end-to-end gecodeerde vergaderingen en geverifieerde identiteit

API-aanroep

Beschrijving

xStatus Call # ServerEncryption Type

Leest de coderingscode die wordt gebruikt in de HTTPS-verbinding met Webex. Dit wordt weergegeven voor de gebruiker.

xStatus Conference Call # EndToEndEncryption Status

Leest de end-to-end-coderingsstatus van de gesprekken. Weergegeven voor de gebruiker als de aanwezigheid (of afwezigheid) van het hangslotpictogram.

xStatus Conference Call # EndToEndEncryption SecurityCode

Leest de beveiligingscode van de vergadering. Dit wordt weergegeven voor de gebruiker en deze verandert wanneer deelnemers zich aansluiten.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Leest de coderingscode die in de mediaverbinding wordt gebruikt. Dit wordt weergegeven voor de gebruiker.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Leest de coderingscode die wordt gebruikt voor MESSAGING Layer Security (HOES).

xStatus Conference Call # EndToEndEncryption Roster Participant

Geeft een overzicht van de deelnemers die bijdragen aan de status van de ISS-groep in deze vergadering. De lijst wordt ontdekt door ERVENS, niet Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

De WDM-URL van een opgegeven deelnemer.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

De verificatiestatus van de opgegeven deelnemer.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

De primaire identiteit van de opgegeven deelnemer, meestal een domein (apparaat) of e-mailadres (gebruiker).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

De weergavenaam van de opgegeven deelnemer. Ondertekend door de deelnemer/het apparaat.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

De certificaatgegevens van het certificaat van de opgegeven deelnemer als een JSON-certificaat.

xCommand Conference ParticipantList Search

We hebben deze opdracht uitgebreid om end-to-end-coderingsinformatie voor deelnemers op te nemen.

xCommand Conference ParticipantList Search

De zoekfunctie in de lijst met deelnemers bevat nu EndToEndEncryptionStatus, de identiteitsverificatiestatus van de deelnemer. Deze waarde wordt weergegeven in de gebruikersinterface.

xCommand Conference ParticipantList Search

De zoekfunctie in de lijst met deelnemers bevat nu EndToEndEncryptionIdentity, de primaire identiteit van de deelnemer. Meestal is dit een domein of een e-mailadres. Deze waarde wordt weergegeven in de gebruikersinterface.

xCommand Conference ParticipantList Search

De zoekfunctie in de lijst met deelnemers bevat nu EndToEndEncryptionCertInfo, de JSON- of het JSON-certificaat dat het certificaat van de deelnemer bevat. Deze waarde wordt weergegeven in de gebruikersinterface.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

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

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

API-aanroep

Beschrijving

xCommand Security ClientSecret Populate Secret: "base64url-encoded" of xCommand Security ClientSecret Populate Secret: JWEblob

Accepteert een basis64url-gecodeerde waarde voor platte tekst voor het eerste gebruik van het client geheim op het apparaat.

Om het geheim na die eerste keer bij te werken, moet u een JWE-bestand met het nieuwe geheim dat is gecodeerd door het oude geheim, leveren.

xCommand Security Certificates Services Add JWEblob

Een certificaat (met privésleutel) toegevoegd.

We hebben dit commando uitgebreid om een JWE-bestand te accepteren dat de gecodeerde PEM-gegevens bevat.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Activeert een specifiek certificaat voor WebexIdentity. Voor deze Purpose, voor de opdracht moet de vingerafdruk worden gecodeerd en als serienummer worden opgenomen in een JWE-bestand.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Deactiveert een specifiek certificaat voor WebexIdentity. Voor deze Purpose, voor de opdracht moet de vingerafdruk worden gecodeerd en als serienummer worden opgenomen in een JWE-bestand.