Déployer des réunions sans confiance
La solution de sécurité « zéro confiance » de Webex assure un chiffrement de bout en bout et une vérification robuste des identités durant vos réunions programmées et dans des salles personnelles.
Les utilisateurs choisissent le type de réunion lorsqu'ils programment une réunion. Lors de l’admission de participants à partir du lobby, ainsi que 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 qui est 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 tierce indésirable Meddler In The Middle (MITM).
Partagez les informations suivantes avec les organisateurs de votre réunion :
-
Programmer un Réunion Webex avec chiffrement de bout en bout
-
Rejoindre une Réunion Webex avec chiffrement de bout en bout
Vérifier l’identité
Le chiffrement de bout en bout avec vérification de l’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 partagé (Messaging Layer Security), ils présentent leurs certificats aux autres membres du groupe, qui valident ensuite les certificats par rapport aux autorités de certification (CA) é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 émet 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 émet un certificat en fonction de leur jeton d'accès. Pour le moment, nous ne fournissons pas un moyen pour les utilisateurs de Webex Meetings d’obtenir un certificat émis par une autorité de certification tierce/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 :
-
AC 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’AC 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)).
-
AC externe—Demandez et achetez des certificats de périphérique directement à 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 en fait le moyen de garantir un véritable chiffrement de bout en bout et une identité vérifiée, et d’empêcher la possibilité théorique que Cisco puisse écouter 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.
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 totalement le certificat externe contre toute falsification, une fonctionnalité de secret client est utilisée pour chiffrer et signer diverses xcommandes.
Lors de l'utilisation du secret client, il est possible de gérer en toute sécurité le certificat d'identité externe Webex via xAPI. Ceci est actuellement limité aux périphériques en ligne.
Webex fournit actuellement des commandes API pour gérer cela.
Terminaux
Les périphériques de la série Webex Room et de la série Webex Desk enregistrés sur le Cloud suivants peuvent rejoindre les réunions E2EE :
-
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 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 vous fournissons pas d’options Control Hub pour gérer l’identité des périphériques vérifiée en externe. Pour un véritable chiffrement de bout en bout, vous seul devez connaître/accéder aux secrets 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.
-
Actuellement, nous vous fournissons une « recette » pour concevoir vos propres outils, basés sur des techniques de cryptage standard de l'industrie, pour vous aider à demander ou à chiffrer les certificats d'identité de vos appareils et leurs clés privées. Nous ne souhaitons avoir aucun accès réel ou perçu à vos keys ou à vos keys.
Meetings
-
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 lors des 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 lors 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é avec des annotations.
Interface de gestion
Nous vous recommandons vivement d’utiliser Control Hub pour gérer votre site de réunions, car les organisations Control Hub ont une identité centralisée pour l’ensemble de l’organisation.
Informations connexes
-
Sécurité sans confiance pour Webex (document technique sur la sécurité)
-
JSON Web Encryption (JWE) (Projet de norme IETF)
-
Webex Meetings 41.7.
-
Périphériques des séries Webex Room et Webex Desk enregistrés sur le Cloud, fonctionnant sous
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’AC Webex pour émettre des certificats de périphérique pour une identité vérifiée).
-
Les salles de réunions de collaboration doivent être allumées pour que les personnes peuvent la rejoindre à 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.
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 de l'identité, chaque périphérique doit disposer d'un certificat unique délivré par une autorité de certification (AC) 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. Lorsque vous demandez le certificat, utilisez les paramètres suivants :
-
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 comme
name.model@example.com
. -
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 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 à ce stade.
Si vous avez des périphériques existants que vous souhaitez mettre à niveau pour utiliser une identité vérifiée en externe, vous devez réinitialiser les périphériques aux paramètres 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.
Une fois ces étapes terminées, autorisez les systèmes vidéo à rejoindre les réunions et les événements sur votre site Webex.
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 afin de permettre la gestion de la clé chiffrée et du certificat, en utilisant JSON Web Encryption (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é, 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.
Le processus et les paramètres (non secrets) dont vous aurez besoin sont expliqués ci-dessous, ainsi qu’une recette à suivre dans les 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 de l'appareil de modifier le secret initial et de protéger leurs médias contre 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.
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 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": "ajouter"
ou"cisco-action": "remplir"
ou"cisco-action": "activer"
ou"cisco-action": "désactiver"
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. La
version
doit être1
(la version de notre fonction de dérivation des clés). La valeur desalt
doit être une séquence codée en base64 par URL d'au moins 4 octets, que vous devez choisir au hasard.
-
-
Clé chiffrée JWE. Ce champ est vide. L’appareil le dérive du
ClientSecret
initial. -
Vecteur 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 supplémentaires authentifiées). Vous devez omettre ce champ car il n’est pas pris en charge dans la série compacte.
-
Texte de chiffrement JWE : Ceci est la charge utile chiffrée que vous souhaitez secret.
La charge utile PEUT être vide. Par exemple, pour réinitialiser le secret client, vous devez l'écraser 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. Différentes commandes xAPI s'attendent à des charges utiles différentes, et vous devez spécifier l'objet de la charge utile avec la touche
cisco-action
, comme suit :-
Avec
"cisco-action":"populate"
, le texte chiffré est le nouveauClientSecret
. -
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":"désactiver"
, le texte chiffré est l'empreinte digitale (représentation hexadécimale de sha-1) du certificat que nous désactivons pour la vérification de l'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
Comment obtenir la clé de chiffrement à partir du 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
-
Salt est une séquence aléatoire d’au moins 4 octets ; vous devez fournir ce même
salt
lorsque vous spécifiez le paramètrecisco-kdf
. -
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 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 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 client dans l’exemple est ossifrage
.
-
Choisissez un chiffrement chiffrement. Cet exemple utilise
A128GCM
(AES avec des clés 128 bits en mode compteur Galois). Votre outil peut utiliserA256GCM
si vous préférez. -
Choisissez un juin (doit être une suite aléatoire d’au moins 4 octets). Cet exemple utilise (octets hexadécimaux)
E5 E6 53 08 03 F8 33 F6
. Base64url codent la séquence pour obtenir5eZTCAP4M_Y
(retirez le rembourrage base64). -
Voici un exemple d'appel
scrypt
pour créer la clé de chiffrement de contenu (cek) :cek=scrypt(password="ossifrage", salt=séquence de 4 octets, 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
qui base64url code àlZ66bdEiAQV4_mqdInj_rA
. -
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
que la base64url code pourNLNd3V9Te68tkpWD
. -
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 codé à l'url de base64url est
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9
Ce sera le premier élément duob JWEob.
-
Le second élément duob JWE est vide, car nous ne fournissons pas de clé JWE algorithme de chiffrement.
-
Le troisième élément du blob JWE est le vecteur d'initialisation
NLNd3V9Te68tkpWD
. - 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 sera le faux blob PEM
il s'agit d'un fichier PEM
Les paramètres de chiffrement que vous devez utiliser sont :
La charge utile est
un fichier PEM
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)
Base64url codent la charge utile chiffrée, ce qui devrait entraîner
f5lLVuWNfKfmzYCo1YJfODhQ
Ceci est le quatrième élément (JWE Ciphertext) dans l’objet JWE.
-
Base64url codent la balise que vous avez produite à l'étape 8, ce qui devrait conduire à
PE-wDFWGXFFBeo928cfZ1Q
Ceci est le cinquième élément duob JWE.
-
Concaténer les cinq éléments du jWE blob avec des points (JOSEheader.. IV.Ciphertext.Tag) pour obtenir :
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
-
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.
-
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
Les types de sessions pour les réunions sans confiance sont disponibles pour tous les sites de réunions sans frais supplémentaires. L’un de ces types de sessions 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 sessions, voir ID des types de sessions 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 via la page de configuration de l’utilisateur, ou en bloc avec une exportation/importation CSV.
1 |
Connectez-vous à Control Hub, et allez à . |
2 |
Cliquez sur Sites, choisissez le site Webex dont vous souhaitez modifier les paramètres, puis cliquez sur Paramètres. |
3 |
Sous Paramètres communs, sélectionnez Types de sessions. |
4 |
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 VOIPonly De bout en boutncryption_E .
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 disposez de la version _VOIPonly pour garantir 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 Nous pourrions modifier les noms de la fonction publique pour ces types de sessions à l'avenir. |
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 |
Connectez-vous à Control Hub, puis allez dans . |
2 |
Sélectionnez un compte utilisateur à mettre à jour, puis sélectionnez Réunions. |
3 |
Dans la liste déroulante Les paramètres s’appliquent à , sélectionnez le site de réunion à mettre à jour. |
4 |
Cochez la case située à côté de 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. Pour affecter ce paramètre à plusieurs utilisateurs, utilisez l'option suivante, Activer les réunions E2EE pour plusieurs utilisateurs. |
1 |
Connectez-vous à Control Hub, et allez à . |
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 que nous préparions 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 contextuelle manuellement après avoir cliqué sur Télécharger.) |
6 |
Ouvrez le fichier CSV téléchargé pour l’éditer. Il y a une ligne pour chaque utilisateur et la colonne |
7 |
Pour chaque utilisateur auquel vous souhaitez accorder le nouveau type de session, ajoutez La Référence au format de fichier CSV Webex contient des détails sur l'objet et le 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 le chargement du 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. |
Vous pouvez ajouter un filigrane aux enregistrements de réunions à l'aide du type de session Webex Meetings Pro-End to End Encryption_VOIPonly
, qui vous permet d'identifier le client ou le périphérique source 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 Control Hub, qui analyse ensuite l’enregistrement et recherche les identifiants uniques. Vous pouvez consulter les résultats pour voir quel client ou périphérique source 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 ne pouvez analyser les enregistrements que pour les réunions organisées par des personnes de votre organisation.
- Les informations du filigrane sont conservées pendant la même durée que les informations de la réunion de l’organisation.
Ajouter des filigranes audio aux réunions E2EE
- Connectez-vous à Control Hub, puis sous Gestion, sélectionnez Paramètres de l’organisation.
- Dans la section Filigranes de la réunion , activez Ajouter un filigrane audio.
Quelque temps après cette activation, les utilisateurs qui programment des réunions avec le type de session
Webex Meetings Pro-End to End Encryption_VOIPonly
voient une option Filigrane numérique dans la section Sécurité.
Télécharger et analyser une réunion filigranée
- Dans Control Hub, sous Surveillance, sélectionnez Dépannage.
- Cliquez sur Analyse des filigranes.
- Recherchez ou sélectionnez la réunion dans la liste, puis cliquez sur Analyser.
- Dans la fenêtre Analyser le filigrane audio , saisissez un nom pour votre analyse.
- (Facultatif) Saisissez une note pour votre analyse.
- Faites glisser et déposez le fichier audio à analyser, ou cliquez sur Choisir le fichier pour accéder au fichier audio.
- Cliquez sur Fermer.
Lorsque l'analyse est terminée, elle apparaît dans la liste des résultats sur la page Analyser le filigrane .
- Sélectionnez la réunion dans la liste pour voir les résultats de l'analyse. Cliquez sur 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 émettant l'audio, le volume de cet audio, le bruit ambiant, etc. Notre technologie de filigrane a une résilience supplémentaire à être codée plusieurs 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 larges mais raisonnables. Notre objectif est qu'un appareil d'enregistrement, tel qu'un téléphone portable, qui est couché sur un bureau près d'un terminal personnel ou d'un client d'ordinateur portable, crée toujours un enregistrement qui aboutit à une analyse réussie. Lorsque le dispositif d'enregistrement est éloigné de la source, ou est empêché d'entendre tout le spectre audio, les chances d'une analyse réussie sont réduites.
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.
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 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 ne dites pas à Webex quel domaine identifie le périphérique, l’un d’eux est automatiquement choisi et les autres participants de la réunion peuvent avoir l’air mal.
Avant de commencer
Si vos périphériques ne sont pas encore intégrés, suivez Enregistrer un périphérique sur Cisco Webex en utilisant l'API ou l'interface Web locale ou Intégration sur le Cloud pour les séries Board, Desk et Room. Vous devez également vérifier le ou les domaines que vous souhaitez utiliser pour identifier les périphériques dans Gérer vos domaines.
1 |
Connectez-vous au 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éter pour d’autres périphériques. |
Avant de commencer
-
Obtenez un certificat signé par une autorité de certification et une clé privée, au format
.pem
, pour chaque périphérique. -
Sous l'onglet Préparer , lisez la rubrique Comprendre le processus d'identité externe des périphériques,
-
Préparer un outil de chiffrement JWE par rapport aux informations qui s'y trouvent.
-
Assurez-vous d'avoir un outil pour générer des séquences aléatoires d'octets de longueurs données.
-
Assurez-vous que vous disposez d'un outil pour baser64url encoder des octets ou du texte.
-
Assurez-vous d'avoir une implémentation
scrypt
. -
Assurez-vous d'avoir un mot ou une phrase secret pour chaque périphérique.
1 |
Renseignez le champ La première fois que vous remplissez le Le périphérique a son secret initial. N'oubliez pas cela ; vous ne pouvez pas le récupérer et devez réinitialiser le périphérique aux paramètres d'usine pour le redémarrer.
|
2 |
Concaténer votre certificat et votre clé privée : |
3 |
Créez un objet JWE à utiliser comme entrée pour la commande d’ajout de certificat : |
4 |
Ouvrez le TShell sur le périphérique et exécutez la commande d’ajout (multi lignes) : |
5 |
Vérifiez que le certificat est ajouté en exécutant Copier l’empreinte digitale du nouveau certificat. |
6 |
Activez le certificat dans le but de 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 Meetings Pro-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. En savoir plus sur les icônes d'identité. |
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 dans la mesure du possible en vérifiant 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.
-
Si vous avez des niveaux variables de vérification d'identité, autorisez les utilisateurs à vérifier les uns les autres avec l'identité avec certificat. 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.
Session Type ID |
Nom du service public |
---|---|
638 |
Cryptage E2E+VoIP uniquement |
652 |
Voix sur l’EVOIPONse de bout enncryption_bout |
660 |
Auto-réponse de bout en bout Proncryption_3 Chiffrement E2E + Identité |
672 |
Pro 3 Gratuit50-Bout à Fin EVOIPonlyncryption_ |
673 |
Formation Formateur E2E Réponsencryption_électronique |
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 plus d’informations sur la façon d’utiliser l’API, voir Accéder à l’API pour les périphériques Webex Room et de bureau et Webex Boards.
Ces commandes xAPI sont disponibles uniquement sur les périphériques qui sont soit :
-
Enregistré sur Webex
-
Enregistré sur site et lié à Webex avec Webex Edge pour les périphériques
appel API |
Description |
---|---|
|
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. |
|
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. |
|
Indique si le périphérique utilise la vérification |
|
L’identité du périphérique comme lue à partir du nom commun du certificat délivré en externe. |
|
Lit des informations spécifiques à partir d’un certificat délivré en externe. Dans la commande affichée, remplacez
|
|
Le statut de l’identité externe du périphérique (par exemple |
|
Indique si le périphérique a un certificat valide émis par l’AC Webex. |
|
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, il s'agit de la valeur du |
|
Lit les informations spécifiques du certificat délivré par Webex. Dans la commande affichée, remplacez
|
appel API |
Description |
---|---|
| Ces trois événements incluent désormais |
appel API |
Description |
---|---|
ou
| 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. |
| Ajoute un certificat (avec clé privée). Nous avons étendu cette commande pour accepter unob JWE contenant les données PEM chiffrées. |
| Active un certificat spécifique pour WebexIdentity. Pour ce |
| Désactive un certificat spécifique pour l’entité WebexId. Pour ce |