Expérience utilisateur

Les utilisateurs choisissent le type de réunion lorsqu’ils programment une réunion. Lors de l’admission des participants depuis le lobby, ainsi que pendant la réunion, l’organisateur peut voir le statut de vérification de l’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 que leur réunion n'a pas été interceptée par une attaque indésirable d'un tiers Meddler In The Middle (MITM).

Partagez les informations suivantes avec les organisateurs de vos réunions :

Vérification de l’identité avec une autorité de certification interne ou externe

Vérifier l’identité

Le chiffrement de bout en bout avec vérification d’identité fournit une sécurité supplémentaire à une réunion chiffrée de bout en bout.

Lorsque des participants ou des périphériques rejoignent un groupe MLS (Messaging Layer Security) partagé, ils présentent leurs certificats aux autres membres du groupe, qui valident ensuite les certificats par rapport aux autorités de certification (AC) émettrices. En confirmant que les certificats sont valides, l'autorité de certification vérifie l'identité des participants et la réunion affiche les participants/périphériques comme vérifiés.

Les utilisateurs de l’application Webex s’authentifient auprès du magasin d’identité Webex, qui leur fournit un jeton d’accès lorsque l’authentification réussit. S’ils ont besoin d’un certificat pour vérifier leur identité au cours d’une réunion chiffrée de bout en bout, l’autorité de certification Webex leur délivre un certificat basé sur leur jeton d’accès. Actuellement, nous ne fournissons pas de moyen aux utilisateurs de Webex Meetings d’obtenir un certificat délivré par une autorité de certification tierce/externe.

Les périphériques peuvent s’authentifier eux-mêmes à l’aide d’un certificat délivré par l’autorité de certification interne (Webex), ou d’un certificat délivré par une autorité de certification externe :

  • Autorité de certification interne : Webex émet un certificat interne basé sur le jeton d'accès du compte machine du périphérique. Le certificat est signé par l'autorité de certification Webex. Les périphériques n’ont pas d’ID utilisateur de la même manière que les utilisateurs, donc Webex utilise (l’un des) domaines de votre organisation lors de l’écriture de l’identité du certificat du périphérique (nom commun (NC)).

  • Autorité de certification externe : demandez et achetez des certificats de périphérique directement à partir de l'émetteur de votre choix. Vous devez chiffrer, télécharger directement et autoriser les certificats à l'aide d'un secret que vous seul connaissez.

    Cisco n’est pas impliqué, ce qui permet de garantir un véritable chiffrement de bout en bout et une identité vérifiée, et d’éviter la possibilité théorique que Cisco puisse écouter votre réunion/déchiffrer votre média.

Certificat de périphérique émis en interne

Webex délivre un certificat au périphérique lorsqu’il s’enregistre après le démarrage, et le renouvelle 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’autorité de certification Webex émet le certificat sans domaine.

Si votre entreprise possède plusieurs domaines, vous pouvez utiliser le Control Hub pour indiquer à Webex quel domaine le périphérique doit 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 de périphérique émis en externe

Un administrateur peut fournir à un périphérique son propre certificat qui a été signé avec l'une des autorités de certification publiques.

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 contenues dans le certificat sont à la discrétion de l'organisation. Le nom commun (NC) et le nom alternatif du sujet (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 les réunions Webex.

Nous vous recommandons d'utiliser un certificat séparé par périphérique et d'avoir un NC unique par périphérique. Par exemple, « meeting-room-1.example.com » pour l’organisation qui possède le domaine « example.com ».

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

Lors de l’utilisation du code secret du client, il est possible de gérer en toute sécurité le certificat d’identité Webex externe via l’xAPI. Ceci est actuellement limité aux périphériques en ligne.

Webex fournit actuellement des commandes API pour gérer cette situation.

Fonctionnalités et limites

Périphériques

Les périphériques des séries Webex Room et Webex Desk suivants enregistrés sur le Cloud peuvent rejoindre les réunions E2EE :

  • Tableau Webex

  • Bureau Pro Webex

  • Bureau Webex

  • Webex Room Kit

  • Webex Room Kit Mini

Les périphériques suivants ne peuvent pas rejoindre les réunions E2EE :

  • Série Webex C

  • Série Webex DX

  • Série Webex EX

  • Série Webex MX

  • Périphériques SIP tiers

Clients logiciels

  • L’application Webex pour les clients de bureau et mobiles peut rejoindre les réunions E2EE.

  • Le client Web Webex ne peut pas rejoindre les réunions E2EE.

  • Les clients logiciels SIP tiers ne peuvent pas rejoindre les réunions E2EE.

Identité

  • De par sa conception, nous ne fournissons pas d’options du Control Hub pour vous permettre de gérer l’identité des périphériques vérifiés en externe. Pour un véritable chiffrement de bout en bout, vous êtes le seul à connaître/accéder aux secrets et aux clés. Si nous introduisons un service cloud pour gérer ces clés, il y a un risque qu’elles soient interceptées.

  • Actuellement, nous vous fournissons une « recette » pour concevoir vos propres outils, basés sur des techniques de chiffrement standard de l'industrie, pour vous aider à demander ou chiffrer les certificats d'identité de vos périphériques et leurs clés privées. Nous ne voulons pas avoir un accès réel ou perçu à vos secrets ou clés.

Réunions

  • Les réunions E2EE prennent actuellement en charge un maximum de 1 000 participants.

  • Vous pouvez partager de nouveaux tableaux blancs au cours des réunions E2EE. Il existe certaines différences par rapport aux tableaux blancs dans les réunions régulières :
    • Au cours des réunions E2EE, les utilisateurs ne peuvent pas accéder aux tableaux blancs créés en dehors de la réunion, y compris les tableaux blancs privés, les tableaux blancs partagés par d’autres personnes et les tableaux blancs à partir des espaces Webex.
    • Les tableaux blancs créés au cours des réunions E2EE ne sont disponibles que pendant la réunion. Ils ne sont pas enregistrés et ne sont pas accessibles après la fin de la réunion.
    • Si une personne partage du contenu au cours d'une réunion E2EE, vous pouvez l'annoter. Pour plus d’informations sur l’annotation, voir Application Webex | Marquer le contenu partagé par des annotations.

Interface de gestion

Nous vous recommandons fortement d’utiliser Control Hub pour gérer votre site de réunions, car les organisations Control Hub disposent d’une identité centralisée pour l’ensemble de l’organisation.

Ressources supplémentaires
Prérequis

  • Webex Meetings 41.7.

  • Périphériques des séries Webex Room et Webex Desk enregistrés sur le Cloud, en cours d'exécution 10.6.1-RoomOS_August_2021.

  • Accès administratif au site de réunion dans Control Hub.

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

  • Les salles de réunion de collaboration doivent être activées pour que les personnes puissent rejoindre la réunion à partir de leur système vidéo. Pour plus d’informations, voir Autoriser les systèmes vidéo à rejoindre les réunions et les événements sur votre site Webex.

Obtenir des certificats de périphériques

Vous pouvez sauter cette étape si vous n’avez pas besoin d’identités vérifiées 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 délivré par une autorité de certification (AC) publique de confiance.

Vous devez interagir avec l'autorité de certification pour demander, acheter et recevoir les certificats numériques et créer les clés privées associées. Lorsque vous demandez le certificat, utilisez les paramètres suivants :

  • Le certificat doit être délivré et signé par une autorité de certification publique bien 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 compromettez votre sécurité.

  • Nom commun (NC) et nom(s) alternatif(s) du sujet (SAN(s) : Ces valeurs ne sont pas importantes pour Webex, mais doivent être des valeurs que les humains peuvent lire et associer à l’appareil. Le NC affichera aux autres participants de la réunion en tant qu’identité vérifiée principale du périphérique, et si les utilisateurs inspectent le certificat par le biais de l’interface utilisateur de la réunion, ils verront le/les SAN. Vous pouvez utiliser des noms tels que name.model@example.com.

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

  • Objectif : L’objet du certificat doit être Webex Identity.

  • Génération des clés : Les certificats doivent être basés sur les paires de clés ECDSA P-256 (Elliptical Curve Digital Signature Algorithm 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.

Préparer l’intégration de périphériques

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

Si vous utilisez de nouveaux périphériques, ne les enregistrez pas encore sur Webex. Pour être en sécurité, ne les connectez pas au réseau pour l'instant.

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

  • Enregistrez la configuration existante si vous souhaitez la conserver.

  • Programmez une fenêtre lorsque les périphériques ne sont pas utilisés, ou utilisez une approche par étapes. Informez les utilisateurs des modifications auxquelles ils peuvent s’attendre.

  • Assurez l’accès physique aux périphériques. Si vous devez accéder à des périphériques sur le réseau, sachez que les secrets circulent en texte brut et que vous compromettez votre sécurité.

Une fois que vous avez terminé ces étapes, autorisez les systèmes vidéo à rejoindre les réunions et événements sur votre site Webex.

Comprendre le processus d’identité externe des périphériques

Pour vous assurer que les médias de votre périphérique ne peuvent être chiffrés par personne sauf le 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 afin de permettre la gestion de la clé chiffrée et du certificat, en utilisant JSON Web Encryption (JWE).

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

  1. Demandez vos certificats.

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

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

  4. Développez et maintenez votre propre outil de chiffrement des fichiers à l’aide de la norme JWE.

    Le processus et les paramètres (non secrets) dont vous aurez besoin sont expliqués ci-dessous, ainsi qu'une recette à suivre dans vos outils de développement de votre choix. Nous fournissons également quelques données de test et les blobs JWE qui en résultent comme nous les attendons, pour vous aider à vérifier votre processus.

    Une implémentation de référence non prise en charge utilisant Python3 et la bibliothèque JWCrypto est disponible sur demande auprès de Cisco.

  5. Concaténez et chiffrez le certificat et la clé à l’aide de votre outil et du code secret initial du périphérique.

  6. Téléchargez le blob JWE résultant sur le périphérique.

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

  8. (Recommandé) Fournissez une interface à (ou distribuez) votre outil pour permettre aux utilisateurs des périphériques de modifier le secret initial et de protéger leurs médias de vous.

Comment nous utilisons le format JWE

Cette section décrit comment nous espérons que le JWE sera créé en tant qu'entrée sur les périphériques, afin que vous puissiez créer votre propre outil pour créer les blobs à partir de vos certificats et clés.

Reportez-vous à JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 et JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Nous utilisons la sérialisation compacte d'un document JSON pour créer des blobs JWE. Les paramètres que vous devez inclure lors de la création des blobs JWE sont :

  • EN-TÊTE JOSE (protégé). Dans l'en-tête de signature et de chiffrement de l'objet JSON, vous DEVEZ inclure les paires clé-valeur suivantes :

    • "alg":"dir"

      L'algorithme direct est le seul que nous prenons en charge pour le cryptage de la charge utile, et vous devez utiliser le code secret client initial du périphérique.

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

      Nous prenons 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 la finalité 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 de la JWE.

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

      Une autre clé propriétaire. Nous utilisons les valeurs que vous fournissez comme entrées pour la dérivation des clés sur le périphérique. Le version doit être 1 (la version de notre fonction de dérivation de clé). La valeur de salt doit être une séquence d'URL base64 d'au moins 4 octets, que vous devez choisir de manière aléatoire.

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

  • Vecteur d'initialisation JWE. Vous devez fournir un vecteur d'initialisation codé base64url pour déchiffrer la charge utile. L'IV DOIT être une valeur aléatoire de 12 octets (nous utilisons la famille de chiffrement AES-GCM, qui nécessite que l'IV ait une longueur de 12 octets).

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

  • Texte chiffré JWE : Il s'agit de la charge utile chiffrée que vous souhaitez garder secrète.

    La charge utile PEUT être vide. Par exemple, pour réinitialiser le code secret du client, vous devez le remplacer par une valeur vide.

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

    • Avec "cisco-action":"populate" le texte chiffré est le nouveau ClientSecret.

    • Avec « "cisco-action":"add" le texte chiffré est un blob PEM portant le certificat et sa clé privée (concaténée).

    • Avec « "cisco-action":"activate" le texte chiffré 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 texte chiffré est l’empreinte digitale (représentation hexadécimale de sha-1) du certificat que nous désactivons d’être utilisés pour la vérification de l’identité des périphériques.

  • Balise d’authentification JWE : Ce champ contient la balise d'authentification pour vérifier l'intégrité de l'ensemble du blob sérialisé compactly JWE

Comment obtenir la clé de chiffrement à partir du ClientSecret

Après la première population du secret, nous n'acceptons pas ou ne publions pas le secret en texte brut. Ceci permet d'empêcher les attaques potentielles du dictionnaire par une personne qui pourrait accéder au périphérique.

Le logiciel du périphérique utilise le secret client comme entrée d'une fonction de dérivation de clé (kdf), puis utilise la clé dérivée pour déchiffrer/chiffrer le contenu sur le périphérique.

Cela signifie pour vous que votre outil pour produire des blobs JWE doit suivre la même procédure pour obtenir la même clé de chiffrement/déchiffrement à partir du secret client.

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

  • Le facteur de coût (N) est 32768

  • BlockSizeFactor (r) est 8

  • Le facteur de parallélisation (p) est 1

  • Le sel est une séquence aléatoire d'au moins 4 octets ; vous devez le fournir salt lorsque vous spécifiez le cisco-kdf paramètre.

  • Les longueurs des clés sont soit 16 octets (si vous sélectionnez l'algorithme AES-GCM 128), soit 32 octets (si vous sélectionnez l'algorithme AES-GCM 256)

  • Le plafond de mémoire maximum est de 64 Mo

Cet ensemble de paramètres est la seule configuration de scrypt compatible avec la fonction de dérivation 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 le paramètre cisco-kdf .

Exemple de travail

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

L'exemple de scénario consiste à ajouter un blob PEM au périphérique (imite l'ajout d'un certificat, avec une chaîne très courte au lieu d'une clé + cert complète). Le code secret du client dans l'exemple est ossifrage.

  1. Choisissez un chiffrement. Cet exemple utilise A128GCM (AES avec des clés 128 bits en mode compteur de Galois). Votre outil peut utiliser A256GCM si vous préférez.

  2. Choisissez un sel (doit être une séquence aléatoire d'au moins 4 octets). Cet exemple utilise (octets hexadécimaux)E5 E6 53 08 03 F8 33 F6. L'URL de base64code la séquence pour obtenir 5eZTCAP4M_Y (supprimer le remplissage de base64).

  3. Voici un exemple d’scrypt appel pour créer la clé de chiffrement du contenu (cek) :

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

    La clé dérivée doit être de 16 octets (hexadécimaux) comme suit :95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac l'url de base64qui code pour lZ66bdEiAQV4_mqdInj_rA.

  4. Choisissez une séquence aléatoire de 12 octets à utiliser comme vecteur d'initialisation. Cet exemple utilise (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 que base64url code pour NLNd3V9Te68tkpWD.

  5. Créez l'en-tête JOSE avec une sérialisation compacte (suivez le même ordre de paramètres que nous utilisons ici), puis base64url l'encoder :

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

    L'en-tête JOSE codé base64url est eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

    Ce sera le premier élément du blob JWE.

  6. Le second élément du blob JWE est vide, car nous ne fournissons pas de clé de chiffrement JWE.

  7. Le troisième élément du blob JWE est le vecteur d'initialisation NLNd3V9Te68tkpWD.

  8. Utilisez votre outil de chiffrement JWE pour produire une charge utile chiffrée et une balise. Pour cet exemple, la charge utile non chiffrée sera le faux blob 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 du chiffrement est AES 128 GCM

    • L'en-tête JOSE codé en tant que données authentifiées supplémentaires (AAD)

    Base64url encode la charge utile chiffrée, ce qui devrait entraîner f5lLVuWNfKfmzYCo1YJfODhQ

    Il s'agit du quatrième élément (texte chiffré JWE) dans le blob JWE.

  9. Base64url encode la balise que vous avez produite à l'étape 8, ce qui devrait entraîner PE-wDFWGXFFBeo928cfZ1Q

    Il s'agit du cinquième élément du blob JWE.

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

  11. Si vous avez dérivé les mêmes valeurs codées de base64url que celles que nous montrons ici, en utilisant vos propres outils, vous êtes prêt à les utiliser pour sécuriser le chiffrement E2E et vérifier l'identité de vos périphériques.

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

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

Les types de sessions pour les réunions à confiance zéro sont disponibles pour tous les sites de réunions sans frais supplémentaires. L'un de ces types de session est appelé Pro-End to End Encryption_VOIPonly. Il s’agit du Nom du service public, que nous pourrions changer à l’avenir. Pour les noms actuels des types de session, voir ID des types de session dans la section Référence de cet article.

Vous n'avez rien à faire pour obtenir cette fonctionnalité pour votre site ; vous devez accorder le nouveau type de session (également appelé Privilège de réunion) aux utilisateurs. Vous pouvez le faire individuellement sur la page de configuration de l’utilisateur, ou en bloc à l’aide d’une exportation/importation CSV.

Vérifier le nouveau type de session
1

Connectez-vous à Control Hub, puis allez dans Services > Réunion.

2

Cliquez sur Sites, choisissez le site Webex pour lequel vous souhaitez modifier les paramètres, puis cliquez sur Paramètres.

3

Sous Paramètres communs, sélectionnez Types de sessions.

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 Pro-End to End Encryption_VOIPonly.

Il existe un type de session plus ancien avec un nom très similaire : Chiffrement pro-de bout en bout. Ce type de session inclut l’accès RTCP non chiffré aux réunions. Assurez-vous que vous disposez de la version _VOIPonly pour assurer le chiffrement de bout en bout. Vous pouvez vérifier en passant la souris sur le lien PRO dans la colonne du code de session ; pour cet exemple, la cible du lien doit être javascript:ShowFeature(652).

Nous pourrions changer les noms de la fonction publique pour ces types de sessions à l'avenir.

4

Si vous n'avez pas encore le nouveau type de session, contactez votre représentant Webex.

Que faire ensuite ?

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

Activer les réunions E2EE pour les utilisateurs individuels
1

Connectez-vous à Control Hub, puis allez dans Gestion > Utilisateurs.

2

Sélectionnez un compte utilisateur à mettre à jour, puis sélectionnez Réunions.

3

À partir de la liste déroulante Paramètres s’appliquer à , sélectionnez le site de réunion à mettre à jour.

4

Cochez la case à côté de Pro-End to End Encryption_VOIPonly.

5

Fermez le panneau de configuration de l'utilisateur.

6

Répétez l'opération pour les autres utilisateurs si nécessaire.

Pour attribuer cette option à plusieurs utilisateurs, utilisez l’option suivante, Activer les réunions E2EE pour plusieurs utilisateurs.

Activer les réunions E2EE pour plusieurs utilisateurs
1

Connectez-vous à Control Hub, puis allez dans Services > Réunion.

2

Cliquez sur Sites, choisissez le site Webex pour lequel vous souhaitez modifier les paramètres.

3

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

4

Cliquez sur Générer le rapport, puis attendez pendant que nous préparons le fichier.

5

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

6

Ouvrez le fichier CSV téléchargé pour modification.

Il y a une ligne pour chaque utilisateur, et la MeetingPrivilege colonne contient leurs ID de type de session sous forme de liste délimitée par des virgules.

7

Pour chaque utilisateur que vous souhaitez accorder au nouveau type de session, ajoutez 1561 en tant que nouvelle valeur dans la liste délimitée par des virgules dans la MeetingPrivilege cellule.

La référence du format de fichier CSV de Webex contient des détails sur l’objectif et le contenu du fichier CSV.

8

Ouvrez le panneau de configuration du site de réunion dans Control Hub.

Si vous étiez déjà sur la page de la liste des sites de réunion, vous devez l’actualiser.

9

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

10

Cliquez sur Importer et sélectionnez le fichier CSV modifié, puis cliquez sur Importer. Patientez pendant le téléchargement du fichier.

11

Lorsque l’importation est terminée, vous pouvez cliquer sur Importer les résultats pour vérifier 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 nouveau type de session.

Ajouter un filigrane audio pour la sécurité

Vous pouvez ajouter un filigrane aux enregistrements de réunions avec le Webex Meetings Pro-End to End Encryption_VOIPonly type de session, ce qui vous permet d’identifier le client source ou le périphérique des enregistrements non autorisés de réunions confidentielles.

Lorsque cette fonctionnalité est activée, l'audio de la réunion inclut un identifiant unique pour chaque client ou périphérique participant. Vous pouvez télécharger des enregistrements audio vers le Control Hub, qui analyse ensuite l’enregistrement et recherche les identifiants uniques. Vous pouvez consulter les résultats pour voir quel client source ou périphérique a enregistré la réunion.

  • Pour être analysé, l’enregistrement doit être un fichier AAC, MP3, M4A, WAV, MP4, AVI ou MOV ne dépassant pas 500 Mo.
  • L’enregistrement doit durer plus de 100 secondes.
  • Vous pouvez analyser les enregistrements uniquement pour les réunions organisées par des personnes de votre organisation.
  • Les informations sur le filigrane sont conservées pour la même durée que les informations sur la réunion de l’organisation.

Ajouter des filigranes audio aux réunions E2EE

  1. Connectez-vous au Control Hub, puis sous Gestion, sélectionnez Paramètres de l’organisation.
  2. Dans la section Filigranes de la réunion , activez Ajouter un filigrane audio.

    Quelque temps après que cette option soit activée, les utilisateurs qui programment des réunions avec le Webex Meetings Pro-End to End Encryption_VOIPonly type de session voient une option Filigrane numérique dans la section Sécurité.

Charger et analyser une réunion filigrane

  1. Dans Control Hub, sous Surveillance, sélectionnez Dépannage.
  2. Cliquez sur Analyse des filigranes.
  3. Recherchez ou sélectionnez la réunion dans la liste, puis cliquez sur Analyser.
  4. Dans la fenêtre Analyser le filigrane audio , saisissez un nom pour votre analyse.
  5. (Facultatif) Saisissez une note pour votre analyse.
  6. Faites glisser et déposez le fichier audio à analyser, ou cliquez sur Choisir le fichier pour parcourir le fichier audio.
  7. Cliquez sur Fermer.

    Lorsque l’analyse est terminée, elle s’affiche dans la liste des résultats sur la page Analyser le filigrane .

  8. Sélectionnez la réunion dans la liste pour voir les résultats de l'analyse. Cliquez Bouton Télécharger pour télécharger les résultats.

Fonctionnalités et limites

Les facteurs impliqués dans le décodage réussi d’un filigrane enregistré comprennent la distance entre le dispositif d’enregistrement et le haut-parleur produisant l’audio, le volume de cet audio, le bruit ambiant, etc. Notre technologie de filigrane offre une résilience supplémentaire à l’encodage multiple fois, comme cela peut se produire lorsque le média est partagé.

Cette fonctionnalité est conçue pour permettre un décodage réussi de l'identificateur de filigrane dans un ensemble de circonstances large mais raisonnable. Notre objectif est qu’un appareil d’enregistrement, tel qu’un téléphone portable, qui se trouve sur un bureau près d’un point de terminaison personnel ou d’un client d’ordinateur portable, devrait toujours créer un enregistrement qui donne lieu à une analyse réussie. Lorsque le périphérique d'enregistrement s'éloigne de la source, ou est masqué pour entendre l'intégralité du spectre audio, les chances d'une analyse réussie diminuent.

Afin d'analyser un enregistrement avec succès, une capture raisonnable de l'audio de la réunion est nécessaire. Si l'audio d'une réunion est enregistré sur le même ordinateur qui héberge le client, les limites ne doivent pas s'appliquer.

Périphériques intégrés (autorité de certification interne)

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

Cette procédure sélectionne le domaine que le périphérique utilise pour s’identifier et n’est requise que si vous avez plusieurs domaines dans votre organisation Control Hub. Si vous avez plusieurs domaines, nous vous recommandons de le faire pour tous vos périphériques qui auront une identité « vérifiée par Cisco ». Si vous ne indiquez pas à Webex quel domaine identifie le périphérique, l’un d’eux est automatiquement choisi et il peut sembler incorrect pour les autres participants de la réunion.

Avant de commencer

Si vos périphériques ne sont pas encore intégrés, suivez Enregistrer un périphérique dans Cisco Webex en utilisant une API ou une interface Web locale ou Intégration cloud pour les séries Board, Desk et Room. Vous devez également vérifier le(s) domaine(s) que vous souhaitez utiliser pour identifier les périphériques dans Gérer vos domaines.

1

Connectez-vous à Control Hub, puis sous Gestion, sélectionnez 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étez l'opération pour d'autres périphériques.

Périphériques intégrés (autorité de certification externe)

Avant de commencer

  • Obtenez un certificat signé par une autorité de certification et une clé privée, au .pem format, pour chaque périphérique.

  • Sous l’onglet Préparer , lisez le sujet Comprendre le processus d’identité externe pour les périphériques,

  • Préparez un outil de chiffrement JWE par rapport aux informations qui s'y trouvent.

  • Assurez-vous que vous disposez d'un outil pour générer des séquences d'octets aléatoires de longueurs données.

  • Assurez-vous que vous disposez d'un outil pour coder en octets ou en texte la base64url.

  • Assurez-vous que vous avez une scrypt mise en œuvre.

  • Assurez-vous que vous avez un mot ou une phrase secret pour chaque périphérique.

1

Remplir le périphérique ClientSecret avec un code secret en texte brut :

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

  1. Base64url encode la phrase secrète pour ce périphérique.

  2. Ouvrez le TShell sur l'appareil.

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

    L'exemple de commande ci-dessus remplit le Secret avec la phrase 0123456789abcdef. Vous devez choisir le vôtre.

Le périphérique a son secret initial. N'oubliez pas ceci ; vous ne pouvez pas le récupérer et vous devez réinitialiser le périphérique aux paramètres d'usine pour redémarrer.
2

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

  1. À l'aide d'un éditeur de texte, ouvrez les fichiers .pem, collez la clé blob du certificat blob et enregistrez-la en tant que nouveau fichier .pem.

    Ceci est le texte de la charge utile que vous allez chiffrer et mettre dans votre blob JWE.

3

Créez un blob JWE à utiliser comme saisie de la commande d'ajout de certificat :

  1. Créez une séquence aléatoire d'au moins 4 octets. C'est ton sel.

  2. Dériver une clé de chiffrement de contenu avec votre outil scrypt.

    Pour cela, vous avez besoin du secret, du sel et d'une clé pour correspondre 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 obtenir la même clé de chiffrement de contenu.

  3. Créez une séquence aléatoire de 12 octets exactement. Ceci est votre vecteur d'initialisation.

  4. Créez un en-tête JOSE, un paramètre alg, enc et des cisco-kdf clés comme décrit dans Comprendre le processus d’identité externe pour les périphériques. Configurez l’action « ajouter » à l’aide de la clé :valeur "cisco-action":"add" dans votre en-tête JOSE (car nous ajoutons le certificat au périphérique).

  5. L'url de base64code l'en-tête JOSE.

  6. Utilisez votre outil de chiffrement JWE avec le chiffrement choisi et l'en-tête JOSE codé base64url pour chiffrer le texte à partir du fichier pem concaténé.

  7. Base64url encode le vecteur d'initialisation, la charge utile PEM chiffrée et la balise d'authentification.

  8. Construisez le blob JWE 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 (multiligne) : 

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

Vérifiez que le certificat est ajouté en exécutant xcommand Security Certificates Services Show

Copiez l'empreinte digitale du nouveau certificat.

6

Activer le certificat dans le but WebexIdentity :

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

  2. Créez une séquence aléatoire d'au moins 4 octets, et base64url encode cette séquence. C'est ton sel.

  3. Dériver une clé de chiffrement de contenu avec votre outil scrypt.

    Pour cela, vous avez besoin du secret, du sel et d'une clé pour correspondre 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 obtenir la même clé de chiffrement de contenu.

  4. Créez une séquence aléatoire de 12 octets exactement, et base64url encode cette séquence. Ceci est votre vecteur d'initialisation.

  5. Créez un en-tête JOSE, un paramètre alg, enc et des cisco-kdf clés comme décrit dans Comprendre le processus d’identité externe pour les périphériques. Définissez l'action « activer » à l'aide de la clé :valeur "cisco-action":"activate" dans votre en-tête JOSE (car nous activons le certificat sur le périphérique).

  6. L'url de base64code l'en-tête JOSE.

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

    L'outil doit produire une séquence de 16 ou 32 octets, selon que vous avez choisi AES-GCM 128 ou 256 bits, ainsi qu'une balise d'authentification.

  8. Base64urlencode l'empreinte chiffrée et la balise d'authentification.

  9. Construisez le blob JWE comme suit (toutes les valeurs sont encodées base64url) :

    JOSEHeader..InitVector.EncryptedFingerprint.AuthTag

  10. Ouvrez 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 dispose d’un certificat chiffré, actif, délivré par une autorité de certification, prêt à être utilisé pour l’identifier lors des réunions Webex chiffrées de bout en bout.
7

Intégrez le périphérique à votre entreprise Control Hub.

Tester le chiffrement de bout en bout avec vérification d’identité
1

Programmer une réunion du bon type (Webex Meetings Pro-End to End Encryption_VOIPonly).

Voir Programmer une réunion Webex avec chiffrement de bout en bout.

2

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

Voir Rejoindre une réunion Webex avec chiffrement de bout en bout.

3

Rejoignez la réunion à partir d'un périphérique dont l'identité est vérifiée par l'autorité de certification 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.

Voir Rejoindre une réunion Webex avec chiffrement de bout en bout.

5

Rejoignez la réunion à partir d'un périphérique dont l'identité est vérifiée par une autorité de certification 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. En savoir plus sur les icônes d’identité.

7

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

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, autorisez ou rejetez des personnes/des périphériques.

10

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

11

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

12

Rejoignez la réunion avec un nouveau participant.

13

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

Définir la portée et les attentes

  • Allez-vous faire des réunions chiffrées de bout en bout l’option par défaut, ou l’activer uniquement pour certains utilisateurs ou autoriser tous les organisateurs à décider ? Lorsque vous aurez décidé comment vous allez utiliser cette fonctionnalité, préparez les utilisateurs qui l’utiliseront, en particulier en ce qui concerne les limites et ce à quoi vous attendre au cours de la réunion.

  • Devez-vous vous assurer que ni Cisco ni personne d’autre ne peut déchiffrer votre contenu ou usurper l’identité de vos périphériques ? Si tel est le cas, vous avez besoin de certificats d'une autorité de certification publique.

  • Si vous disposez de différents niveaux de vérification d’identité, autorisez les utilisateurs à se vérifier les uns les autres à l’aide d’un certificat d’identité. Même s'il y a des circonstances où les participants peuvent apparaître comme Non vérifiés, et que les participants doivent savoir comment vérifier, les personnes non vérifiées ne peuvent pas être des imposteurs.

Gestion des identités

Si vous utilisez une autorité de certification externe pour émettre des certificats de votre périphérique, il vous incombe de surveiller, d'actualiser et de réappliquer les certificats.

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

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

ID du type de session

Nom de la fonction publique

638

Chiffrement E2E+VoIP uniquement

652

Encryption_VOIP uniquement pro de bout en bout

660

Pro 3 Free-End to End Encryption_VOIP only

Chiffrement E2E + Identité

672

Pro 3 Free50-End to End Encryption_VOIPonly

673

Instructeur en éducation E2E Encryption_VOIPonly

676

Standard Broadworks plus chiffrement de bout en bout

677

Broadworks Premium plus chiffrement de bout en bout

681

Schoology Free plus chiffrement de bout en bout

Commandes xAPI connexes

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 plus d’informations sur la façon d’utiliser l’API, voir Accéder à l’API pour les périphériques de salle et de bureau Webex et les Webex Boards.

Ces commandes xAPI ne sont disponibles que sur les périphériques qui sont :

  • Inscrit(s) sur Webex

  • Enregistré sur site et lié à Webex avec Webex Edge for Devices

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

Appel API

Description

xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"

Cette configuration est effectuée lorsque l’administrateur configure le domaine préféré du périphérique à partir du Control Hub. Uniquement nécessaire si l’entreprise a plusieurs domaines.

Le périphérique utilise ce domaine lorsqu’il demande un certificat à partir de l’autorité de certification Webex. Le domaine identifie alors le périphérique.

Cette configuration n’est pas applicable lorsque le périphérique dispose d’un certificat actif, émis en externe, pour s’identifier.

xStatus Conference EndToEndEncryption Availability

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

xStatus Conference EndToEndEncryption ExternalIdentity Verification

Indique si le périphérique utilise la External vérification (a un certificat délivré en externe).

xStatus Conference EndToEndEncryption ExternalIdentity Identity

L'identité du périphérique telle que lue à partir du nom commun du certificat émis en externe.

xStatus Conference EndToEndEncryption ExternalIdentity CertificateChain Certificate # specificinfo

Lit des informations spécifiques d'un certificat émis en externe.

Dans la commande affichée, remplacez # par le numéro du certificat. Remplacez specificinfo par l'un des éléments suivants :

  • Fingerprint

  • NotAfter Date de fin de validité

  • NotBefore Date début validité

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Une liste des sujets du certificat (par exemple, adresse électronique ou nom de domaine)

  • Validity Indique l'état de validité de ce certificat (ex. valid ou expired)

xStatus Conference EndToEndEncryption ExternalIdentity Status

L’état de l’identité externe du périphérique (par ex. valid ou error).

xStatus Conference EndToEndEncryption InternalIdentity Verification

Indique si le périphérique dispose d'un certificat valide émis par l'autorité de certification Webex.

xStatus Conference EndToEndEncryption InternalIdentity Identity

L’identité du périphérique telle que lue dans le nom commun du certificat émis par Webex.

Contient un nom de domaine si l’entreprise en a un.

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

Si le périphérique est dans une organisation qui a plusieurs domaines, il s'agit de la valeur du PreferredDomain.

xStatus Conference EndToEndEncryption InternalIdentity CertificateChain Certificate # specificinfo

Lit des informations spécifiques du certificat délivré par Webex.

Dans la commande affichée, remplacez # par le numéro du certificat. Remplacez specificinfo par l'un des éléments suivants :

  • Fingerprint

  • NotAfter Date de fin de validité

  • NotBefore Date début validité

  • PrimaryName

  • PublicKeyAlgorithm

  • SerialNumber

  • SignatureAlgorithm

  • Subject # Name Une liste des sujets du certificat (par exemple, adresse électronique ou nom de domaine)

  • Validity Indique l'état de validité de ce certificat (ex. valid ou expired)

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

Appel API

Description

xEvent Conference ParticipantList ParticipantAdded

xEvent Conference ParticipantList ParticipantUpdated

xEvent Conference ParticipantList ParticipantDeleted

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

Tableau 4. API liées au secret du client 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 brut codée base64url pour semer le secret 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 blob 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 un blob 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 cette Purpose, la commande nécessite que l’empreinte digitale d’identification soit chiffrée et sérialisée dans un blob JWE.

xCommand Security Certificates Services Deactivate Purpose:WebexIdentity FingerPrint: JWEblob

Désactive un certificat spécifique pour WebexIdentity. Pour cette Purpose, la commande nécessite que l’empreinte digitale d’identification soit chiffrée et sérialisée dans un blob JWE.