Les utilisateurs choisissent la nouvelle type de réunion lorsqu’ils programment une réunion. Lors de l’admettre des participants à partir du lobby et pendant la réunion, l’organisateur peut voir le statut de vérification d’identité de chaque participant. Il existe également un code de réunion commun à tous les participants actuels de la réunion, qu’ils peuvent utiliser pour vérifier les uns et les autres.

Partagez les informations suivantes avec les organisateurs de votre réunion :

Vérification de l’identité

De bout en bout vérification d’identité fournit une sécurité supplémentaire pour une réunion cryptée de bout en bout.

Lorsque les participants ou les périphériques rejoignent un groupe PARTAGÉS CAT (Messaging Layer Security), ils présentent leurs certificats aux autres membres du groupe qui valident ensuite les certificats par rapport à l’autorité de certification/ies (AC) émettrice. En confirmant que les certificats sont valides, l’AC vérifie l’identité des participants et la réunion montre les participants/périphériques comme vérifiés.

Les utilisateurs des Application Webex Meetings s’authentifier eux-mêmes par rapport à la boutique d’identité Webex qui leur donne un jeton d’accès lorsqu’ils ont réussi. S’ils ont besoin d’un certificat pour vérifier leur identité - dans une réunion cryptée de bout en bout - l’AC Webex leur donne un certificat en fonction de leur jeton d’accès. Nous ne fournissons pas encore de moyen pour Webex Meetings utilisateurs d’obtenir un certificat délivré par une tierce partie/une AC externe.

Les périphériques peuvent s’authentifier en utilisant un certificat délivré par l’AC (Webex) interne, ou un certificat délivré par une AC externe :

  • Pour le cas de l’AC interne, Webex présente un certificat interne basé sur le jeton d’accès du compte de la machine du périphérique. Le certificat est signé par l’AC Webex. Les périphériques n’ont pas d’ID utilisateur de la même façon que les utilisateurs, donc Webex utilise (un) domaine(s) de votre organisation lors de l’écriture de l’identité du certificat du périphérique (Nom commun (NC).)

  • Pour le cas de l’AC externe, vous demandez et achetez les certificats des périphériques directement à partir de l’émetteur de votre choix. Vous devez chiffrer, charger directement et autoriser les certificats en utilisant un secret connu uniquement de vous.

    Cisco n’est pas impliqué, ce qui fait que ceci permet de garantir un vrai chiffrement de bout en bout et une identité vérifiée et empêche la possibilité que l’équipe puisse écouter parler de votre réunion/déchiffrer votre média.

Certificat du périphérique fourni en interne

Webex cause un certificat au périphérique lorsqu’il s’enregistre après le démarrage et le renouvele si nécessaire. Pour les périphériques, le certificat inclut l’ID du compte et un domaine.

Si votre organisation n’a pas de domaine, l’AC Webex émettra le certificat sans domaine.

Si votre organisation a plusieurs domaines, vous pouvez utiliser Control Hub pour dire à Webex quel domaine le périphérique à utiliser pour son identité. Vous pouvez également utiliser l’API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".

Si vous avez plusieurs domaines et que vous ne définissez pas le domaine préféré pour le périphérique, Webex en choisit un pour vous.

Certificat du périphérique délivré en externe

Un administrateur peut fournir un périphérique avec son propre certificat qui a été signé avec l’un des CAs publics.

Le certificat doit être basé sur une paire de clés ECDSA P-256, bien qu’il puisse être signé par une clé RSA.

Les valeurs du certificat sont à la discrétion de l’organisation. Le nom commun (NC) et le Nom alternatif de l’objet (SAN) seront affichés dans l’interface utilisateur de la réunion Webex, comme décrit dans Chiffrement de bout en bout avec vérification d’identité pour Webex Meetings.

Il est recommandé d’utiliser un certificat séparé par périphérique et d’avoir un NC unique par périphérique. Ceci peut, par exemple, être « meeting-room-1.example.com », pour l’organisation propriétaire du domaine example.com ».

Afin de protéger totalement le certificat externe contre toute falsification, une fonctionnalité de secret client est utilisée pour chiffrer et signer diverses xcommandes.

Lorsque vous utilisez le secret du client, il est possible de gérer le certificat d’identité webex externe en toute sécurité via l’XAPI. Ceci est actuellement limité aux périphériques en ligne.

Actuellement, Webex fournit des commandes API pour gérer ce.

Périphériques

Les périphériques Webex Room enregistrés sur le Cloud et les séries Webex Desk peuvent rejoindre les réunions cryptées de bout en bout, y compris :

  • Webex Board

  • Bureau Pro Webex

  • Bureau Webex

  • Webex Room Kit

  • Webex Room Kit Mini

Les périphériques suivants ne peuvent pas rejoindre les réunions chiffrées de bout en bout :

  • Série Webex C

  • Série Webex DX

  • Série Webex EX

  • Série Webex MX

  • Périphériques SIP tiers

Clients logiciels

  • À partir de la version 41.7, le client Webex Meetings bureau peut rejoindre les réunions cryptées de bout en bout.

  • L’application Webex ne peut pas rejoindre les réunions chiffrées de bout en bout.

    Si votre organisation active l’application Webex pour rejoindre les réunions en lançant l’application de bureau Meetings, alors vous pouvez utiliser cette option pour rejoindre les réunions chiffrées de bout en bout.

  • Le client Web Webex ne peut pas rejoindre les réunions chiffrées de bout en bout.

  • Les clients SIP soft tiers ne peuvent pas rejoindre les réunions cryptées de bout en bout.

Identité

  • Nous ne fournissons aucune option Control Hub pour que vous gériez l’identité des périphériques vérifiés en externe. Cette décision est de par le design, car pour un chiffrement de bout en bout, seul vous devez connaître/accéder aux clés et aux clés. Si nous avons introduit un service sur le Cloud pour gérer ces clés, il y a de chances qu’elles soit interceptées.

  • Nous ne fournissons actuellement aucun outil pour vous aider à demander ou à crypter les certificats d’identité de vos périphériques ainsi que leurs clés privées. Nous fournissons actuellement une « recette » à la conception de vos propres outils, basées sur des techniques de chiffrement standard de l’industrie, pour vous assister dans ces processus. Nous ne souhaitons avoir aucun accès réel ou perçu à vos keys ou à vos keys.

Meetings

  • De bout en bout réunions cryptées supportent actuellement un maximum de 200 participants.

  • De ces 200 participants, un maximum de 25 périphériques vérifiés en externe peuvent rejoindre la réunion et ils doivent être les premiers participants à rejoindre laréunion.

    Lorsqu’un plus grand nombre de périphériques rejoignent une réunion, nos services média backend tentent de transcoder les flux média. Si nous ne pouvons pas déchiffrer, transcoder et recrypter le média (car nous n’avons pas et ne devons pas avoir les clés de chiffrement des périphériques), alors le transcodage échoue.

    Pour mitiger cette limite, nous recommandons des réunions de plus petite taille pour les périphériques, ou legger les invitations entre les périphériques et les clients de réunions.

Interface de gestion

Nous vous recommandons vivement d’utiliser Control Hub pour gérer votre site Meeting.

La raison principale de ceci est la différence entre la façon dont Control Hub et Administration du site les identités. Les organisations Control Hub ont une identité centralisée pour l’ensemble de l’organisation, Administration du site l’identité est contrôlée sur un site par site.

Ceci signifie que vous ne pouvez pas avoir l’option d’identité vérifiée par Cisco pour les utilisateurs qui sont gérés à partir de Administration du site. Ces utilisateurs ont reçu un certificat anonyme pour rejoindre une réunion cryptée de bout en bout et ils peuvent être exclus des réunions au cours des quelles l’organisateur souhaite garantir leur identité.

Informations connexes

Modèle de dérisation JWEobs

Modèle de JWE correctement crypté en fonction des paramètres donnés (annexe)

  • Webex Meetings 41.7.

  • Périphériques enregistrés sur Webex Room cloud et webex Desk, en cours d’exécution 10.6.1-RoomOS_August_2021.

  • Accès administratif au site de réunion dans Control Hub, pour activer la nouvelle Type de session pour les utilisateurs.

  • Un ou plusieurs domaines vérifiés dans votre organisation Control Hub (si vous utilisez l’AC Webex pour émettre des certificats de périphérique pour une identité vérifiée).

Vous pouvez sauter cette étape si vous n’avez pas besoin d’une identité vérifiée en externe.

Pour le plus haut niveau de sécurité et pour la vérification d’identité, chaque périphérique doit avoir un certificat unique émis par une autorité de certification publique de confiance.

Vous devez interagir avec l’AC pour demander, acheter et recevoir les certificats numériques et créer les clés privées associées. Lors de la demande du certificat, ce sont les paramètres à utiliser :

  • Le certificat doit être émis et signé par une AC publique très connue.

  • Unique: Nous vous recommandons fortement d’utiliser un certificat unique pour chaque périphérique. Si vous utilisez un certificat pour tous les périphériques, vous êtes en mesure de compromettre votre sécurité.

  • Nom commun (NC) et Nom/s alternatif de l’objet (SAN/s) : Ce ne sont pas importants pour Webex, mais ce sont des valeurs que les êtres humains peuvent lire et associer au périphérique. Le NC s’affichera pour les autres participants de la réunion en tant que l’identité principale vérifiée du périphérique et si les utilisateurs inspecterent le certificat via l’IU de la réunion, ils voient le/les SAN. Vous pouvez utiliser des noms tels que name.model@example.com mais c’est votre choix.

  • Format de fichier : Les certificats et les clés doivent être au format .pem.

  • But: L’objectif du certificat doit être l’Identité Webex.

  • Génération des clés : Les certificats doivent être basés sur les paires de clés ECDSA P-256 (Algorithme de signature numérique Lipptical Curve en utilisant la courbe P-256).

    Cette exigence ne s’étend pas à la clé de signature. L’AC peut utiliser une clé RSA pour signer le certificat.

Vous pouvez sauter cette étape si vous ne souhaitez pas utiliser l’identité vérifiée par externe avec vos périphériques.

Si vous utilisez de nouveaux périphériques, ne les enregistrez pas encore sur Webex. Il est préférable de ne pas encore les connecter au réseau.

Si vous avez des périphériques existants que vous souhaitez mettre à niveau pour utiliser l’identité vérifiée par externe, vous devez réinitialiser les périphériques d’usine.

  • Enregistrez la configuration existante si vous souhaitez la conserver.

  • Programmer une fenêtre lorsque les périphériques ne sont pas utilisés, ou utilisez une approche par phases. Notifiez les utilisateurs des changements qu’ils peuvent s’attendre.

  • Assurez un accès physique aux périphériques. Si vous devez accéder aux périphériques sur le réseau, sachez que les doivent voyager en texte simple et que votre sécurité est compromise.

Pour vous assurer que le média de votre périphérique ne peut pas être chiffré par tout le monde à l’exception du périphérique, vous devez chiffrer la clé privée sur le périphérique. Nous avons conçu des API pour le périphérique pour permettre la gestion de la clé cryptée et du certificat, à l’aide du chiffrement Web JSON (JWE).

Pour garantir un chiffrement de bout en bout via notre Cloud, nous ne pouvons pas être impliqués dans le cryptage et le chargement du certificat et de la clé. Si vous avez besoin de ce niveau de sécurité, les vous devez :

  • Demandez vos certificats.

  • Générez les paires de clés de vos certificats.

  • Créez (et protégez) un secret initial pour chaque périphérique, pour semer la capacité de chiffrement du périphérique.

  • Développer et gérer votre propre outil de chiffrement des fichiers en utilisant la norme JWE.

    Ci-dessous nous expliquant le processus et les paramètres (non secret) dont vous aurez besoin et une recette à suivre dans vos outils de développement de votre choix. Nous fournissons également quelques données de test et les objets JWE qui en résultent comme nous les attendons, pour vous aider à vérifier votre processus.

    Une implémentation de référence non pris en compte en utilisant Python3 et la bibliothèque JWCrypto est disponible à partir de Cisco sur demande.

  • Concaténer et chiffrer le certificat et la clé en utilisant votre outil et le secret initial du périphérique.

  • Téléchargez leob JWE final sur le périphérique.

  • Définissez l’objet du certificat chiffré à utiliser pour l’identité Webex et activez le certificat.

  • (Recommandé) Fournissez une interface à (ou distribuez) votre outil pour permettre aux utilisateurs des périphériques de modifier le secret initial (pour protéger leur média de vous !).

Comment nous utilisons le format JWE

Cette section décrit comment nous attendons que le JWE soit créé en tant qu’entrée sur les périphériques, afin que vous pouvez créer votre propre outil pour créer les objets de vos certificats et clés.

Vous devez vous référer au chiffrement Web JSON (JWE)https://datatracker.ietf.org/doc/html/rfc7516 et JSON Web Signature (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Nous avons choisi d’utiliser la série compacte d’un document JSON pour créer des objets de jWE. Les paramètres que vous devez inclure lorsque vous créez lesobs JWE sont :

  • En-tête JOSE (protégé). Dans l’en-tête De signature et chiffrement de l’objet JSON, vous DEVEZ inclure les paires de valeurs de clés suivantes :

    • "alg":"dir"

      L’algorithme direct est le seul que nous ons en charge pour chiffrer la charge utile et vous devez utiliser le secret initial du client du périphérique.

    • "enc":"A128GCM" ou "enc":"A256GCM"

      Nous ons en charge ces deux algorithmes de chiffrement.

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

      Il s’agit d’une clé propriétaire et de quatre valeurs qu’elle peut prendre. Nous avons introduit cette clé pour signaler l’objet des données chiffrées au périphérique cible. Les valeurs sont nommées d’après les commandes xAPI sur le périphérique sur lequel vous utilisez les données chiffrées.

      Nous l’avons nommé cisco-action pour atténuer les conflits potentiels avec les futures extensions JWE.

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

      Une autre clé propriétaire. Nous utilisons les valeurs que vous fournissez comme entrées pour le dérision de clés sur le périphérique. Le version doit être 1(la version de notre fonction derivation de clé). La valeur de salt doit être une suite de codes URL de base64 d’au moins 4 octets, que vous devez choisir aléatoirement.

  • Clé chiffrée JWE. Ce champ est vide. Le périphérique le découle de l’initiale ClientSecret.

  • Vectoriel d’initialisation JWE. Vous devez fournir un vectoriel d’initialisation chiffré de base64url pour déchiffrer la charge utile. L’IV DOIT être une valeur aléatoire à 12 octets (nous utilisons la famille AES-GCM cipher, qui nécessite que l’IV d’être longue de 12 octets).

  • JWE AAD (données authentifiées supplémentaires). Vous devez omettre ce champ car il n’est pas pris en charge dans la série compacte.

  • Texte Ciphertext JWE: Ceci est la charge utile chiffrée que vous souhaitez secret.

    La charge utile PEUT être vide (par exemple, pour réinitialiser le mot de passe du client, vous devez l’riter avec une valeur vide).

    Il existe différents types de charges utiles, en fonction de ce que vous essayez de faire sur le périphérique. Des commandes xAPI différentes attendent des charges utiles différentes et vous devez spécifier l’objet de la charge utile avec le cisco-action clé, comme suit :

    • Avec "cisco-action":"populate" le chiffrement est le nouveau ClientSecret

    • Avec » "cisco-action":"add" le ciphertext est unob PEM qui transporte le certificat et sa clé privée (concatenée)

    • Avec » "cisco-action":"activate" le ciphertext est l’empreinte digitale (représentation hexadécimale de sha-1) du certificat que nous activons pour la vérification de l’identité du périphérique

    • Avec » "cisco-action":"deactivate" le ciphertext est l’empreinte digitale (représentation hexadécimale de sha-1) du certificat que nous désactivez d’être utilisé pour la vérification d’identité du périphérique

  • Balise d’authentification JWE : Ce champ contient la balise d’authentification pour vérifier l’intégrité de l’intégralité de la marque JWE compactée en série

La façon dont nous algorithme de chiffrement les ClientSecret

Après la première population de ce secret, nous n’acceptons pas et ne sortieons pas le secret en tant que texte simple. Ceci permet d’empêcher les attaques potentielles du dictionnaire par quelqu’un qui pourrait accéder au périphérique.

Le logiciel du périphérique utilise le secret du client comme entrée à une fonction de dérision de clé (kdf) puis utilise la clé obtenue pour le déchiffrage/chiffrement du contenu sur le périphérique.

Ce que cela signifie pour vous, c’est que votre outil de production JWEobs doit suivre la même procédure pour tirer la même clé de chiffrement/déchiffrement du secret du client.

Les périphériques utilisent scrypt pour le derivation de clés (voir https://en.wikipedia.org/wiki/Scrypt), avec les paramètres suivants :

  • Le coût (N) est 32768

  • BlockSizeRe (r) est 8

  • Parallelization (p) est 1

  • Le retent est une séquence aléatoire d’au moins 4 octets ; vous devez fournir la même salt lorsque vous spécifiez les cisco-kdf AUTOOC.

  • Les longueurs des touches sont soit de 16 octets (si vous sélectionnez l’algorithme AES-GCM 128) ou de 32 octets (si vous sélectionnez l’algorithme AES-GCM 256)

  • La mémoire maximale est de 64 Mo.

Cet ensemble de paramètres est la seule configuration de chiffrement compatible avec la fonction derivation de clé sur les périphériques. Ce kdf sur les périphériques est appelé "version":"1", qui est la seule version actuellement prise par cisco-kdf AUTOOC.

Exemple de travail

Voici un exemple que vous pouvez suivre pour vérifier que votre processus de chiffrement JWE fonctionne de la même façon que le processus que nous avons créé sur les périphériques.

L’exemple de scénario est l’ajout d’unob PEM au périphérique (imite l’ajout d’un certificat, avec une chaîne très courte au lieu d’une touche +cert complet). Le secret du client dans l’exemple est ossifrage.

  1. Choisissez un chiffrement chiffrement. Cet exemple utilise A128GCM(AES avec clés 128 bits en mode Galois Counter). Votre outil pourrait être utilisé A256GCM si vous préférez.

  2. Choisissez un juin (doit être une suite aléatoire d’au moins 4 octets). Cet exemple utilise (octets) E5 E6 53 08 03 F8 33 F6. L’url de Base64 encode la séquence pour obtenir 5eZTCAP4M_Y(supprimez le remplissage 64 de base).

  3. Voici un exemple scrypt appeler pour créer le contenu algorithme de chiffrement (cek) :

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

    La clé obtenue doit être de 16 octets (hex) comme suit : 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac à quelle encode l’authentification de base64 lZ66bdEiAQV4_mqdInj_rA.

  4. Choisissez une séquence aléatoire de 12 octets à utiliser comme vectoriel d’initialisation. Cet exemple utilise (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 à quelle encode l’authentification de base64 NLNd3V9Te68tkpWD.

  5. Créez l’en-tête JOSE avec une série compacte (suivez le même ordre de paramètres que celui que nous utilisons ici) puis encodez-le à l’encodage base64url :

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

    L’en-tête jose encodée base64l est eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Ce sera le premier élément duob JWEob.

  6. Le deuxième élément duob JWE est vide, car nous ne fournissons pas de clé JWE algorithme de chiffrement.

  7. Le troisième élément de JWEob est le vectoriel d’initialisation NLNd3V9Te68tkpWD.

  8. Utilisez votre outil de chiffrement JWE pour produire une charge utile cryptée et une balise. Dans cet exemple, la charge utile non chiffrée va être le faux gaffec PEM this is a PEM file

    Les paramètres de chiffrement que vous devez utiliser sont :

    • La charge utile est this is a PEM file

    • Le chiffrement cipher est AES 128 GCM

    • L’en-tête encodée base64url JOSE en tant que Données authentifiées supplémentaires (AAD)

    L’url de base code la charge utile chiffrée, ce qui devrait f5lLVuWNfKfmzYCo1YJfODhQ

    Ceci est le quatrième élément (JWE Ciphertext) dans l’objet JWE.

  9. L’authentification de base64 encode la balise que vous avez produite à l’étape 8, ce qui devrait PE-wDFWGXFFBeo928cfZ1Q

    Ceci est le cinquième élément duob JWE.

  10. Concaténer les cinq éléments du jWE blob avec des points (JOSEheader.. IV.Ciphertext.Tag) pour obtenir :

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Si vous avez obtenu les mêmes valeurs encodées base64url que nous le montrons ici, en utilisant vos propres outils, vous êtes prêt à les utiliser pour sécuriser le chiffrement E2E et l’identité vérifiée de vos périphériques.

  12. Cet exemple ne fonctionne pas réellement, mais en fait votre prochaine étape serait d’utiliser le but JWE que vous avez créé ci-dessus comme entrée de la comand x sur le périphérique qui ajoute le certificat :

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

Il existe de nouveaux types de session pour les réunions sans confiance que nous déployerons sur tous les sites de réunion sans frais supplémentaires. Un des nouveaux types de session est appelé Pro-End to End Encryption_VOIPonly. Il s’agit du nom du service public que nous allons changer à l’avenir. Pour les noms actuels des types de sessions, voir ID des types de sessions dans la section Référence de cet article.

Il n’y a rien que vous devez faire pour obtenir la nouvelle fonction pour votre site, mais vous devrez accorder la nouvelle Type de session (également appelée Privilège de réunion) aux utilisateurs. Vous pouvez le faire individuellement via la page de configuration de l’utilisateur, ou en bloc avec un aller-retour d’exportation/importation CSV.

1

Connectez-vous à Control Hub et ouvrez la page Réunion.

2

Cliquez sur le nom de votre site pour ouvrir le panneau de configuration du site.

3

Cliquez sur Configurer le site.

4

Dans la zone Paramètres communs, cliquez sur Types de sessions .

Sur cette page vous devriez voir un ou plusieurs types de session de chiffrement de bout en bout. Reportez-vous à la liste des ID des types de sessions dans la section Référence de cet article. Par exemple, vous pouvez voir De bout en bout Encryption_VOIPonly.

 

Il existe une ancienne Type de session ayant un nom très similaire : Chiffrement de bout en bout pro. Cette Type de session inclut l’accès RTCP l’accès aux réunions non chiffré. Assurez-vous que vous avez la version _VOIPonly pour garantir un chiffrement de bout en bout. Vous pouvez vérifier en survolant le lien PRO dans la colonne du code de session ; pour cet exemple, la cible du lien doit être javascript:ShowFeature(652).

Nous pouvons changer les noms des services publics pour ces types de sessions à l’avenir, par exemple, nous prévoyons de changer les noms des services De bout en bout Encryption_VOIPonly par Chiffrement E2E + Identité.

5

Si vous n’avez pas encore la nouvelle Type de session, contactez votre représentant Webex.

Ce qu’il faut faire ensuite

Activez ce privilège Type de session/réunion pour certains ou tous vos utilisateurs.

1

Cliquez sur Utilisateurs et sélectionnez un utilisateur pour ouvrir le panneau de configuration de l’utilisateur.

2

Dans la zone Services, cliquez sur Cisco Webex Meetings.

3

Sélectionnez le site (si l’utilisateur est dans plus d’un) et cliquez sur Organiser.

4

Cochez la case à côté de Webex Meetings saisie libellée Pro-End to End Encryption_VOIPonly.

5

Fermez le panneau de configuration de l’utilisateur.

6

Répétez pour d’autres utilisateurs si nécessaire.

Si vous souhaitez attribuer cette option à de nombreux utilisateurs, utilisez l’option de masse CSV.

1

Connectez-vous à Control Hub à https://admin.webex.com et ouvrez la page Réunion.

2

Cliquez sur le nom de votre site pour ouvrir le panneau de configuration du site.

3

Dans la section Licences et utilisateurs cliquez sur Gérer en bloc .

4

Cliquez sur Exporter , puispatientez pendant que nous préparons le fichier.

5

Lorsque le fichier est prêt, cliquez sur Exporter les résultats, puis téléchargez. (Vous devez fermer cette fenêtre pop up manuellement après avoir cliqué sur Téléchargerle .)

6

Ouvrez le fichier CSV téléchargé pour l’éditer.

Il y a une ligne pour chaque utilisateur et le MeetingPrivilege contient leurs ID Type de session de liste dans une liste délimitée par des virgules.

7

Pour chaque utilisateur à qui vous souhaitez accorder le nouveau Type de session, ajoutez 1561 comme nouvelle valeur dans la liste délimitée par des virgules dans le MeetingPrivilege Cellule.

La référence du format de fichier CSV à contient quelques détails sur l’objet et le https://help.webex.com/en-us/5vox83 contenu du fichier CSV.

8

Ouvrez le panneau de configuration du site Meeting dans Control Hub.

Si vous étiez déjà sur la page de la liste du site de réunion, vous devez peut-être la ré actualiser.

9

Dans la section Licences et utilisateurs, cliquez sur Gestion en bloc.

10

Cliquez sur Importer et sélectionnez le CSV modifié, puis cliquez sur Importer. Attendez pendant que nous téléchargeons le fichier.

11

Lorsque l’importation est terminée, vous pouvez cliquer sur Importer les résultats pour voir s’il y a eu des erreurs.

12

Allez à la page Utilisateurs et ouvrez l’un des utilisateurs pour vérifier qu’ils ont le nouvel Type de session.

Si vos périphériques sont déjà intégrés à votre organisation Control Hub et que vous souhaitez utiliser l’AC Webex pour générer leurs certificats d’identification automatiquement, vous n’avez pas besoin de réinitialiser les périphériques d’usine.

Cette procédure sélectionne quel domaine le périphérique utilise pour s’identifier et est requise uniquement si vous avez plusieurs domaines dans votre organisation Control Hub. Si vous avez plus d’un domaine, nous vous recommandons de le faire pour tous vos périphériques qui auront l’identité « Cisco vérifiée ». Si vous n’indiquez pas à Webex quel domaine identifie le périphérique, nous en choisirons un et il risque d’avoir des airs erronés pour les autres participants de la réunion.

Avant de commencer

Si vos périphériques ne sont pas encore intégrés, vous pouvez le https://help.webex.com/n25jyr8 suivre ou https://help.webex.com/nutc0dy. Vous devez également vérifier le/les domaine(s) que vous souhaitez utiliser pour identifier les périphériques (https://help.webex.com/cd6d84).

1

Connectez-vous à Control Hub (https://admin.webex.com) et ouvrez la page Périphériques.

2

Sélectionnez un périphérique pour ouvrir son panneau de configuration.

3

Sélectionnez le domaine que vous souhaitez utiliser pour identifier ce périphérique.

4

Répéter pour d’autres périphériques.

Avant de commencer

Tu as besoin de:

  • Pour obtenir un certificat ca signé et une clé privée, au format .pem, pour chaque périphérique.

  • Pour lire le sujet Comprendre le processus d’identité externe pour les périphériques, dans la partie Préparer de cet article.

  • Pour préparer un outil de chiffrement JWE en rapport avec les informations qu’il y a.

  • Un outil pour générer des séquences aléatoires de longueurs donnés.

  • Un outil pour baser 64url encoder des octets ou du texte.

  • Un scrypt Application.

  • Un mot ou une expression secrète pour chaque périphérique.

1

Remplir la zone de ClientSecret avec un secret de texte simple :

La première fois que vous remplirez le Secret, vous le fournissez en texte simple. C’est pourquoi nous vous recommandons de le faire sur la console du périphérique physique.

  1. L’url de base64 encode la phrase secrète pour ce périphérique.

  2. Ouvrez le TShell sur le périphérique.

  3. Exécuter xcommand Security ClientSecret Populate Secret: "MDEyMzQ1Njc4OWFiY2RlZg"

    La commande d’exemple ci-dessus remplit le Secret avec la phrase 0123456789abcdef. Vous devez choisir la vôtre.

Le périphérique a son secret initial. N’oubliez pas ceci, vous ne pouvez pas le récupérer et devez réinitialiser le périphérique sur les factorys pour le redémarrer.
2

Concaténer votre certificat et votre clé privée :

  1. À l’aide d’un éditeur de texte, ouvrez les fichiers .pem, collez la touche dans leob du certificat et enregistrez-le dans un nouveau fichier .pem.

    (Ceci est le texte de charge utile que vous chiffrerez et qui sera placé dans votre objet JWE)

3

Créez un objet JWE à utiliser comme entrée pour la commande d’ajout de certificat :

  1. Créez une suite aléatoire d’au moins 4 octets. C’est votre yeux.

  2. Tirer un contenu algorithme de chiffrement avec votre outil de déchiffrement.

    Pour cela, vous avez besoin du secret, du son, et d’une touche de chiffrement qui correspond au chiffrement que vous avez choisi. Il y a d’autres valeurs fixes à fournir (N=32768, r=8, p=1). Le périphérique utilise le même processus et les mêmes valeurs pour tirer profit du même contenu algorithme de chiffrement.

  3. Créez une suite aléatoire de 12 octets exactement. Ceci est votre vectoriel d’initialisation.

  4. Créer un en-tête JOSE, réglage alg, enc et cisco-kdf clés comme décrit dans Comprendre le processus d’identité externe pour les périphériques. Configurer l’action « ajouter » en utilisant la clé : valeur "cisco-action":"add" dans votre en-tête JOSE (car nous ajoutons le certificat au périphérique).

  5. Base64url encodez l’en-tête JOSE.

  6. Utilisez votre outil de chiffrement JWE avec le chiffrement choisi et l’en-tête encodée base64url JOSE pour chiffrer le texte du fichier pem concatenté.

  7. L’encodage de base64url est le vectoriel d’initialisation, la charge utile chiffrée PEM et la balise d’authentification.

  8. Construire le JWEob comme suit (toutes les valeurs sont encodées base64url) :

    JOSEHeader..InitVector.EncryptedPEM.AuthTag

4

Ouvrez le TShell sur le périphérique et exécutez la commande d’ajout (multi lignes) :

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

Vérifiez que le certificat est ajouté en cours d’exécution xcommand Security Certificates Services Show

Copier l’empreinte digitale du nouveau certificat.

6

Activer le certificat à des fins WebexIdentity:

  1. Lire l’empreinte digitale du certificat, soit à partir du certificat lui-même ou à partir de la sortie de xcommand Security Certificates Services Show.

  2. Créez une suite aléatoire d’au moins 4 octets et l’encodage de l’encodage de base64l. C’est votre yeux.

  3. Tirer un contenu algorithme de chiffrement avec votre outil de déchiffrement.

    Pour cela, vous avez besoin du secret, du son, et d’une touche de chiffrement qui correspond au chiffrement que vous avez choisi. Il y a d’autres valeurs fixes à fournir (N=32768, r=8, p=1). Le périphérique utilise le même processus et les mêmes valeurs pour tirer profit du même contenu algorithme de chiffrement.

  4. Créez une suite aléatoire de 12 octets exactement, et l’encodage de l’encodage de base64l. Ceci est votre vectoriel d’initialisation.

  5. Créer un en-tête JOSE, réglage alg, enc et cisco-kdf clés comme décrit dans Comprendre le processus d’identité externe pour les périphériques. Configurer l’action « activer » en utilisant la clé : valeur "cisco-action":"activate" dans votre en-tête JOSE (car nous activons le certificat sur le périphérique).

  6. Base64url encodez l’en-tête JOSE.

  7. Utilisez votre outil de chiffrement JWE avec le chiffrement choisi et l’en-tête encodée base64url JOSE pour chiffrer l’empreinte digitale du certificat.

    L’outil doit avoir une suite de 16 ou 32 byte, selon que vous choisissiez 128 ou 256 bits AES-GCM et une balise d’authentification.

  8. Base64coder l’empreinte chiffrée et la balise d’authentification.

  9. Construire le JWEob comme suit (toutes les valeurs sont encodées base64url) :

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Ouvrez le TShell sur le périphérique et exécutez la commande d’activation suivante :

    xcommand Security Certificates Services Activate Purpose: WebexIdentity Fingerprint: "Your..JWE.encrypted.fingerprint"
Le périphérique a un certificat chiffré, actif, délivré par une AC, prêt à être utilisé pour l’identifier au cours des réunions Webex chiffrées de bout en bout.
7

Intégrer le périphérique à votre organisation Control Hub.

1

Programmez une réunion du type correct ( Webex MeetingsPro-End to End Encryption_VOIPonly).

2

Rejoignez la réunion en tant qu’organisateur, à partir d’Webex Meetings client.

3

Rejoignez la réunion à partir d’un périphérique dont l’identité est vérifiée par l’AC Webex.

4

En tant qu’organisateur, vérifiez que ce périphérique s’affiche dans le lobby avec l’icône d’identité correcte.

5

Rejoindre la réunion à partir d’un périphérique dont l’identité est vérifiée par une AC externe.

6

En tant qu’organisateur, vérifiez que ce périphérique s’affiche dans le lobby avec l’icône d’identité correcte.

7

Rejoindre la réunion en tant que participant de réunions non authentifiés.

8

En tant qu’organisateur, vérifiez que ce participant s’affiche dans le lobby avec l’icône d’identité correcte.

9

En tant qu’organisateur, admettez ou rejetez les personnes/périphériques.

10

Validez les identités des participants/périphériques si possible, en cochant les certificats.

11

Vérifiez que toutes les personnes de la réunion voient le même code de sécurité de réunion.

12

Rejoindre la réunion avec un nouveau participant.

13

Vérifiez que tout le monde voit le même nouveau code de sécurité de réunion.

Allez-vous faire des réunions chiffrées de bout en bout l’option de réunion par défaut, ou l’activer uniquement pour certains utilisateurs, ou autoriser tous les organisateurs à le décider ? Lorsque vous avez décidé de l’utilisation de cette fonctionnalité, préparez les utilisateurs qui l’utiliseront, en ce qui concerne tout particulièrement les limites et à quoi vous attendez au cours de la réunion.

Devez-vous vous assurer que ni Cisco ni les autres personnes ne peuvent déchiffrer votre contenu ou se faire passer pour vos périphériques ? Si c’est le cas, vous avez besoin des certificats d’une AC publique. Vous pouvez avoir uniquement jusqu’à 25 périphériques dans une réunion sécurisée. Si vous avez besoin de ce niveau de sécurité, vous ne devez pas autoriser les clients des réunions à la rejoindre.

Pour les utilisateurs qui rejoignent les s’y joindre par des périphériques sécurisés, laissez les périphériques la rejoindre d’abord, et définissez les attentes des utilisateurs qu’ils ne pourront pas rejoindre la s’ils rejoignent la partie en retard.

Si vous avez différents niveaux de vérification d’identité, autorisez les utilisateurs à se vérifier les uns les autres avec l’identité avec certificat et le code de sécurité de la réunion. Même dans certaines circonstances, les participants peuvent apparaître comme Non vérifiés et les participants doivent savoir comment vérifier, les personnes non vérifiées peuvent ne pas être des impossibles.

Si vous utilisez une AC externe pour émettre les certificats de votre périphérique, les anglais sont sur vous pour contrôler, actualiser et réappliquer les certificats.

Si vous avez créé le secret initial, comprenez que vos utilisateurs peuvent vouloir changer le secret de leur périphérique. Vous devrez peut-être créer une interface/distribuer un outil pour lui permettre de le faire.

Tableau 1. ID des types de sessions pour les réunions chiffrées de bout en bout

Session Type ID

Nom du service public

638

Cryptage E2E+VoIP uniquement

652

Accès de bout en bout Encryption_VOIPonly

660

Pro 3 Accès gratuit de bout en bout Encryption_VOIPonly

Chiffrement E2E + Identité

672

Pro 3 Gratuit50-De bout en Encryption_VOIPonly

673

Formateur en formation E2E Encryption_VOIPonly

676

Broadworks Standard plus chiffrement de bout en bout

677

Broadworks Premium plus chiffrement de bout en bout

681

Gratuit En plus du chiffrement de bout en bout

Ces tableaux décrivent les commandes API des périphériques Webex que nous avons ajoutées pour les réunions chiffrées de bout en bout et l’identité vérifiée. Pour en savoir plus sur l’utilisation de l’API, voir https://help.webex.com/nzwo1ok.

Tableau 2. API au niveau du système pour les réunions chiffrées de bout en bout et l’identité vérifiée

appel API

Description

xConfiguration Conference EndToEndEncryption Mode: On

Se place en mode de chiffrement de bout en bout On ou Off.

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Cette configuration est réalisée lorsque l’administrateur définit le domaine préféré du périphérique à partir de Control Hub. Nécessaire uniquement si l’organisation a plusieurs domaines.

Le périphérique utilise ce domaine lorsqu’il demande un certificat de l’AC Webex. Le domaine identifie ensuite le périphérique.

Cette configuration n’est pas applicable lorsque le périphérique a un certificat actif, délivré en externe pour s’identifier lui-même.

xStatus Conference EndToEndEncryption Availability

Indique si le périphérique peut rejoindre une réunion cryptée de bout en bout. L’API du Cloud l’appelle afin qu’une application appariée sache si elle peut utiliser le périphérique pour la rejoindre.

xStatus Conference EndToEndEncryption ExternalIdentity Valid

Indique si le périphérique a un certificat valide délivré en externe.

xStatus Conference EndToEndEncryption ExternalIdentity Identity

L’identité du périphérique comme lue à partir du nom commun du certificat délivré en externe.

xStatus Conference EndToEndEncryption ExternalIdentity CertInfo

Lit les informations de certificat du certificat délivré en externe et les produit en tant que disque de jSON.

xStatus Conference EndToEndEncryption InternalIdentity Valid

Indique si le périphérique a un certificat valide émis par l’AC Webex.

xStatus Conference EndToEndEncryption InternalIdentity Identity

L’identité du périphérique comme lu à partir du nom commun du certificat Webex délivré.

Contient un nom de domaine si l’organisation a un domaine.

Est vide si l’organisation n’a pas de domaine.

Si le périphérique est dans une organisation qui a plusieurs domaines, c’est la valeur de PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertInfo

Lit les informations de certificat du certificat délivré par Webex et les produit en tant que point de titre JSON.

Tableau 3. API d’appel pour les réunions chiffrées de bout en bout et l’identité vérifiée

appel API

Description

xStatus Call # ServerEncryption Type

Lit le chiffrement cipher utilisé dans la connexion HTTPS à Webex. Ceci est affiché pour l’utilisateur.

xStatus Conference Call # EndToEndEncryption Status

Lit le statut de chiffrement de bout en bout des appels. Affiché à l’utilisateur comme étant la présence (ou l’absence) de l’icône du cadenas.

xStatus Conference Call # EndToEndEncryption SecurityCode

Lit le code de sécurité de la réunion. Ceci est affiché à l’utilisateur et il change lorsque les participants rejoignent la conférence.

xStatus Conference Call # EndToEndEncryption MediaEncryption Type

Lit le chiffrement cipher utilisé dans la connexion média. Ceci est affiché pour l’utilisateur.

xStatus Conference Call # EndToEndEncryption GroupEncryption Type

Lit le chiffrement cipher utilisé pour Messaging Layer Security (CRYPTOGRAPHS).

xStatus Conference Call # EndToEndEncryption Roster Participant

Répertorie les participants qui contribuent à l’état du groupe PERSONNES dans cette réunion. La liste est découverte parMLS, pas Par Webex.

xStatus Conference Call # EndToEndEncryption Roster Participant # Id

L’URL WDM d’un participant spécifié.

xStatus Conference Call # EndToEndEncryption Roster Participant # Status:

Le statut de vérification du participant spécifié.

xStatus Conference Call # EndToEndEncryption Roster Participant # Identity:

L’identité principale du participant spécifié, généralement un domaine (périphérique) ou une adresse électronique (utilisateur).

xStatus Conference Call # EndToEndEncryption Roster Participant # DisplayName:

Le nom d’affichage du participant spécifié. Signé par le participant/périphérique.

xStatus Conference Call # EndToEndEncryption Roster Participant # CertInfo:

Les informations de certificat du certificat du participant spécifié en tant que gaffen JSON.

xCommand Conference ParticipantList Search

Nous avons étendu cette commande pour inclure les informations de chiffrement de bout en bout pour les participants.

xCommand Conference ParticipantList Search

La recherche de la liste des participants inclut maintenant EndToEndEncryptionStatus, le statut de vérification d’identité du participant. Cette valeur est affichée dans l’IU.

xCommand Conference ParticipantList Search

La recherche de la liste des participants inclut maintenant EndToEndEncryptionIdentity, l’identité principale du participant. Ceci est généralement un domaine ou une adresse électronique. Cette valeur est affichée dans l’IU.

xCommand Conference ParticipantList Search

La recherche de la liste des participants inclut maintenant EndToEndEncryptionCertInfo, leob JSON contenant le certificat du participant. Cette valeur est affichée dans l’IU.

xEvent Conference ParticipantList Participant(Added)

xEvent Conference ParticipantList Participant(Updated)

xEvent Conference ParticipantList Participant(Deleted)

Ces trois événements comprennent maintenant EndToEndEncryptionStatus, EndToEndEncryptionIdentity et EndToEndEncryptionCertInfo pour le participant affecté.

Tableau 4. API liées au clientSecret pour les réunions chiffrées de bout en bout et l’identité vérifiée

appel API

Description

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

Accepte une valeur de texte simple encodée 64url de base pour semer le secret du client sur le périphérique pour la première fois.

Pour mettre à jour le secret après cette première fois, vous devez fournir un objet JWE contenant le nouveau secret chiffré par l’ancien secret.

xCommand Security Certificates Services Add JWEblob

Ajoute un certificat (avec clé privée).

Nous avons étendu cette commande pour accepter unob JWE contenant les données PEM chiffrées.

xCommand Security Certificates Services Activate Purpose:WebexIdentity FingerPrint: JWEblob

Active un certificat spécifique pour WebexIdentity. Pour cela Purpose, la commande nécessite que l’empreinte digitale d’identification soit chiffrée et numéro de série dans un objet JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Désactive un certificat spécifique pour l’entité WebexId. Pour cela Purpose, la commande nécessite que l’empreinte digitale d’identification soit chiffrée et numéro de série dans un objet JWE.