Merci pour votre commentaire.

Des millions d'utilisateurs dans le monde font confiance à Webex pour une collaboration sécurisée. Qu'il s'agisse des conseils d'administration des entreprises, des sessions législatives gouvernementales ou des consultations sensibles entre médecins et patients, Webex constitue une plateforme fiable pour les communications critiques.

À mesure que la demande de travail à distance augmente, le besoin d'outils de collaboration fiables et confidentiels augmente également. Webex répond à ce besoin depuis plus longtemps que tout autre fournisseur. Compte tenu de l'essor de l'usurpation d'identité grâce à l'IA et des menaces sophistiquées liées aux deepfake, il est primordial d'exiger une collaboration fondée sur des règles et vérifiée par des règles. Pour nos clients, la sécurité n'est pas simplement une fonctionnalité, c'est un élément intégré au cycle de vie complet des réunions, qui couvre la planification, l'identité des participants et la protection du contenu.

Webex soutient depuis longtemps le chiffrement robuste de bout en bout (E2EE). Notre modèle Webex Zero Trust Security fait évoluer cet héritage grâce à trois piliers principaux :

• Établir les bases d'une cryptographie normalisée et formellement vérifiée
• Renforcer le cryptage de bout en bout grâce à une identité vérifiée de bout en bout
• Étendre le support aux appareils Webex actuels ainsi qu'à l'application Webex

Ce document technique fournit des informations générales sur la sécurité de bout en bout et expose les fondements techniques du fonctionnement de WebExZero Trust Security. Pour la sécurité opérationnelle des réunions, telle que les types de sessions de réunion, les différences de sécurité entre les réunions planifiées et les salles de réunion personnelles, les contrôles de l'administrateur et de l'hôte, le partage et la conservation du contenu des réunions, et la résilience accrue de l'IA et des deepfake dans l'expérience des réunions, consultez le document technique complémentaire de WSMP Meetings Security.

18 ans d'expérience en matière de sécurité E2E

Webex a été la première à utiliser le cryptage E2E pour les réunions en 2008. Par définition, la sécurité E2E garantit que le contenu est crypté dès son envoi jusqu'à ce qu'il soit affiché par le destinataire, empêchant ainsi le fournisseur de cloud ou tout autre tiers d'accéder aux données ou de les falsifier.

En fonction de l'investissement réalisé par un fournisseur de visioconférence dans les mécanismes de sécurité E2E, il peut fournir différents niveaux de protection, comme le montre la Figure 1. Toute sécurité E2E vaut mieux que le simple cryptage en transit et au repos.

Niveau de protection	Attaquants réseau	Attaques passives (écoutes)	Attaques actives (usurpation d'identité)	Exemples
Chiffrement en transit et au repos	Oui	Non	Non	Applications autres que E2EE
Chiffrement E2E	Oui	Oui	Non	Anciennes applications E2EE et grand public
Chiffrement E2E et identité E2E	Oui	Oui	Oui	Sécurité Webex Zero Trust

La plupart des applications qui prétendent fournir une sécurité E2E ne fournissent qu'une protection contre les attaques passives. Les protections uniquement passives sont toujours utiles car elles permettent aux acteurs malveillants d'écouter une réunion uniquement pendant qu'elle est en cours. La meilleure approche consiste toutefois à se protéger contre les attaques passives et actives, au cours desquelles le fournisseur de services de conférence lui-même pourrait prétendre être un participant légitime pour participer à la réunion. Pour cela, une couche d'identité E2E est nécessaire en plus du cryptage E2E.

Avec Zero Trust Security, Webex renforce la cryptographie des réunions et renforce le cryptage de bout en bout grâce à une identité vérifiée de bout en bout afin de protéger les réunions contre tout type d'attaques.

Avant d'entrer dans les détails techniques, il est utile de comprendre l'expérience utilisateur. Pour créer une réunion cryptée E2E, l'hôte sélectionne le type de réunion approprié lors de la planification dans l'application Webex (Figure 2).

Lorsque les participants se joignent, ils voient une icône « bouclier verrouillé » indiquant que la réunion est cryptée E2E (Figure 3). Le fait d'appuyer sur cette icône fournit des informations sur la protection de la réunion.

Enfin, dans la liste des participants à la réunion, l'application Webex indique si l'identité du participant a été vérifiée de manière sécurisée par E2E, c'est-à-dire si quelqu'un d'autre que Cisco s'est porté garant de l'identité du participant (Figure 4).

Les participants peuvent également vérifier qu'ils possèdent tous le même code de sécurité pour s'assurer qu'ils ont tous la même vision de la réunion et qu'ils sont donc à l'abri des attaques par usurpation d'identité. Dans les déploiements qui utilisent des certificats d'identité de bout en bout fournis par le client, l'état de la liste assure la transparence en matière de garantie d'identité.

Zero Trust Security repose sur des protocoles cryptographiques standard, que Cisco développe en collaboration avec d'autres leaders en matière de sécurité et de confidentialité, notamment Google, Cloudflare, Wickr et Wire. Cisco a été à la pointe de la première génération de solutions de voix sur IP (VoIP) sécurisées grâce à des technologies telles que le protocole SRTP (Secure Real-Time Protocol), le DTLS-SRTP, le STIR/SHAKEN et le WebRTC, et Cisco fait de même avec Zero Trust Security (Figure 5).

Couche	Aujourd'hui	Zero Trust Security
Identité	SSO (SAML, OpenID)	Certificat X.509
Échange de clés	SDES/DTLS	Sécurité de la couche de messagerie (MLS)
Cryptage des médias	SRTP	Cadres sécurisés (SFrame)

Le système comporte essentiellement trois couches, et à chaque couche, nous reprenons l'ancienne technologie saut par saut et la renforçons par une couche de protection supplémentaire de bout en bout. Les trois couches incluent :

• Identité : l'identité E2E nécessite que les clients possèdent des informations d'identification prouvant leur identité. Avec Zero Trust E2E Identity, les informations d'identification des clients sont fournies par un Webex Independent. Certificate Authority
• Échange de clés : les clients participant à une réunion E2E doivent configurer des clés pour le cryptage E2E sans que le fournisseur de services de conférence ne puisse accéder à ces clés. Le protocole Messaging Layer Security (MLS) est une norme ratifiée, la RFC 9420, qui s'appuie sur des technologies développées au sein de la communauté open source et les place dans un cadre rigoureux et officiellement vérifié.
• Protection du contenu — Enfin, le contenu multimédia de la réunion doit être protégé de bout en bout. SFrame (pour « Secure Frames ») correspond à la norme RFC 9605. Il s'agit d'un framework de cryptage simple et rapide pour crypter les contenus multimédias en temps réel, qui permet d'ajouter une couche de cryptage supplémentaire avec un minimum de frais.

Examinons ces technologies un peu plus en détail, en commençant par le bas.

Un système de cryptage multimédia est un moyen de prendre une clé partagée par les participants à une réunion et de l'utiliser pour protéger le contenu réellement partagé pendant la réunion, comme le son, la vidéo et le partage d'écran. Au niveau du protocole, le système de cryptage doit envoyer des informations supplémentaires pour chaque unité de données cryptée, surtout :

1. Un en-tête qui indique au destinataire comment déchiffrer le paquet, et
2. Une étiquette d'authentification que le récepteur utilise pour vérifier que le paquet n'a pas été falsifié.

Par exemple, dans le SRTP, l'unité de cryptage est un paquet RTP ; le SRTP se base sur l'en-tête RTP pour sa configuration et ajoute une balise d'authentification à la fin du paquet.

Comme toutes ces informations supplémentaires augmentent la bande passante requise pour une réunion cryptée E2E, SFrame fournit le minimum de cadrage nécessaire. L'en-tête SFrame indique quelle touche doit être utilisée, permet la rotation des touches, et fournit un numéro de séquence unique qui définit le vecteur d'initialisation. Vient ensuite le contenu crypté à l'aide de la clé E2E et d'une balise d'authentification. L'en-tête, le contenu et la balise SFrame sont ensuite encapsulés dans un paquet SRTP, afin que le SRTP protège contre toute inspection ou modification par des attaquants du réseau, et que SFrame protège contre les éléments multimédias du fournisseur de services de conférence (voir l'exemple sur la Figure 6).

Cette approche minimaliste présente d'autres avantages. SFrame est indépendant du transport sous-jacent. Il est donc compatible avec les technologies émergentes telles que le RTP sur QUIC et le RIPT. Il est également possible de configurer SFrame pour qu'il fonctionne sur des unités contenant plusieurs paquets, telles que des trames entières, afin de réduire encore les frais de cryptage.

Créer une clé secrète au sein d'un groupe alors que celui-ci n'a accès qu'à une chaîne non fiable semble magique. Les techniques pour ce faire ont été développées pour la première fois dans les années 1980, et aujourd'hui, plus de 90 % de la navigation sur le Web utilise le protocole Transport Layer Security (TLS) pour y parvenir. Messaging Layer Security (MLS) étend cette fonctionnalité aux groupes, alors que le TLS ne fonctionne que point à point. Webex peut donc utiliser le MLS pour configurer les clés de conférence même lorsque le fournisseur de conférence n'est pas fiable.

Le MLS propose trois fonctionnalités de sécurité essentielles :

1. Clé partagée : seuls les membres authentifiés du groupe connaissent la clé.
2. Cohérence : permet à tous les membres d'avoir une vision cohérente de la composition du groupe.
3. Rotation : met automatiquement à jour les clés lorsqu'un membre rejoint un membre ou le quitte.

La première fonctionnalité nous fournit les clés que nous utilisons pour crypter les contenus multimédias avec SFrame. Associée à la deuxième fonctionnalité, elle constitue le point de départ de l'identité E2E. La troisième fonctionnalité garantit que les seules personnes qui peuvent déchiffrer les médias sont celles qui assistent à la réunion en ce moment. Vous ne pouvez pas déchiffrer les médias datant d'avant votre inscription ou après votre départ (ou votre expulsion).

Pour y parvenir, les clients participant à une réunion échangent des messages MLS à des moments critiques de la réunion afin de maintenir un groupe MLS contenant exactement les participants à la réunion à tout moment. Webex achemine les messages entre les clients, mais le MLS protège ces messages afin que Webex puisse les traiter en toute sécurité. La figure 7 montre le flux des messages.

Création : La première personne à rejoindre la réunion, qu'elle soit animatrice ou non, crée le groupe MLS pour la réunion et devient le « leader » aux fins de la MLS. À tout moment, un seul participant à la réunion est désigné comme leader. Dans la plupart des cas, ce participant sera l'hôte de la réunion. Une fois la session lancée, le MLS garantit que chaque participant à la réunion dispose des informations cryptographiques nécessaires pour agir en tant que leader ; Webex désigne simplement un responsable pour éviter toute confusion.

Rejoindre : Lorsqu'un nouveau participant souhaite participer à la réunion, il demande à être autorisé à entrer en envoyant un message MLS Key Package au leader, qui fournit sa clé publique et ses informations d'authentification. Le leader répond par un message de bienvenue qui donne au menuisier des informations sur les autres participants à la réunion. Le leader diffuse également un message d'ajout et un message de validation au groupe. Le message Ajouter annonce le nouveau membre à ceux qui ont déjà participé à la réunion. Le message de validation demande à tous les participants actuels de hacher l'ancienne clé de groupe afin d'obtenir une nouvelle clé pour le groupe désormais étendu ; le message de bienvenue fournit cette clé au membre.

Congé : Quand quelqu'un quitte la réunion, c'est au leader de le bloquer. Pour ce faire, le leader diffuse des messages MLS Remove and Commit à tous les participants à la réunion. Le message Supprimer indique aux autres participants qui sont partis, et le Commit chiffre une nouvelle clé pour tous les participants restants, mais pas pour la personne qui est partie. Les autres participants hachent la nouvelle clé avec l'ancienne clé de groupe pour obtenir une clé que la personne qui est partie n'a pas. Si le participant qui est parti est le leader, Webex désigne un nouveau leader et le nouveau leader destitue l'ancien leader.

La rotation des clés peut prendre quelques secondes supplémentaires pour rejoindre une réunion ou supprimer quelqu'un, mais cela donne une garantie de sécurité claire : si quelqu'un n'apparaît pas dans la liste des participants à la réunion, il n'a pas les clés nécessaires pour déchiffrer le contenu.

La liste des participants à une réunion cryptée E2E indique la vérification d'identité de chaque utilisateur. L'utilisation de certificats d'identité émis par les clients permet d'obtenir une véritable identité vérifiée E2E, dans le sens où Cisco ne peut pas la modifier. Dans ces cas, la liste des participants indique le domaine auquel appartient le participant en bleu. Par exemple, lors de la réunion illustrée à la Figure 8, vous pouvez voir que Kevin possède une adresse e-mail vérifiée sur example.com et qu'Isabella possède une adresse e-mail vérifiée sur company.com.

Les certificats d'identité émis par un WebexCertificate Authority, comme l'identité d'un appareil vidéo, offrent une protection plus limitée. Seul un attaquant qui compromet le Webex Certificate Authority peut se faire passer pour un utilisateur. Même si c'est mieux que l'absence totale de protection d'identité, les participants à la réunion ne sont pas marqués en bleu car Zero Trust a vérifié leur identité de bout en bout. Ils sont affichés avec du texte gris pour indiquer la vérification d'identité par Webex Trust.

Pour renforcer ces procédures, Webex fournit également un code de sécurité pour la réunion. Un code de sécurité est une courte chaîne lisible par l'homme, calculée en sortie du processus MLS. Le code de sécurité résume l'état cryptographique de la réunion, y compris les clés du groupe et les certificats présentés par les participants. Ce code peut être utilisé pour détecter une attaque par usurpation d'identité, car une telle attaque ferait en sorte qu'au moins un participant aurait un état cryptographique différent de celui des autres. Mais cela exclut l'usurpation d'identité uniquement si tout le monde vérifie qu'il possède le même code. Si un sous-groupe de participants vérifie qu'ils possèdent le même code, ils savent que leur identité est fidèlement représentée les uns aux autres, mais que quelqu'un qui ne confirme pas son code aurait pu se faire passer pour quelqu'un d'autre. La figure 9 montre un exemple de la façon dont le code de sécurité est affiché lors d'une réunion.

Ce code constitue une très bonne défense contre les attaques par usurpation d'identité. Il fait partie du protocole MLS et a donc fait l'objet d'une analyse de sécurité approfondie. Comme il est étroitement lié à l'état de la réunion, le code de sécurité change à chaque fois que quelqu'un y rejoint. Par conséquent, les participants à la réunion doivent revérifier leurs codes de sécurité à chaque fois que quelqu'un y rejoint. Le code ne change pas quand quelqu'un part, car partir ne peut pas introduire d'imitateur.

Webex Zero Trust Security a été lancé en 2021. En 2026, Ultra Secure Webex Meetings a introduit la prise en charge de points de terminaison supplémentaires dans les réunions Webex cryptées E2E, des réunions Zero Trust E2EE complètes avec Video Mesh Node (VMN) et des fonctionnalités de cryptage et d'identité de bout en bout pour les réunions standard :

• Cryptographie normalisée et formellement vérifiée
• Chiffrement Zero Trust E2E
• Identité vérifiée Zero Trust E2E
• Support pour tous les appareils Webex disponibles à la vente
• Support de l'application Webex sur ordinateur, mobile et Web
• Support de l'application Web Webex et du SDK Web (prévu pour le premier trimestre de l'année financière 27)
• Support pour Webex Calling téléphones (prévu pour le troisième trimestre de l'année 2016)
• Support pour Video Mesh Node
• Prise en charge du cryptage E2E dans les réunions programmées et les salles de réunion personnelles

Zero Trust a certaines limites. Les réunions cryptées E2E ne prennent pas en charge :

• Fonctionnalités fournies par les services cloud de Cisco qui nécessitent l'accès à des médias en texte brut, notamment :
  • Enregistrements et services Webex basés sur le AI Assistant cloud. Ces services peuvent être fournis par le biais de déploiements hybrides avec Video Mesh Node (VMN).
  • Enregistrer les discussions, les fichiers, les tableaux blancs et les annotations des réunions.
  • Interopérabilité PSTN ou SIP.

À l'avenir, Webex améliorera les réunions cryptées E2E à certains égards, en suivant les principes qui consistent à accorder au cloud le moins de privilèges nécessaires et à donner aux clients le contrôle de leurs données.

Sécurité E2E omniprésente : tout doit être sécurisé E2E, pas seulement certaines réunions. La première étape pour réaliser cette vision a été la sécurité E2E pour les téléphones Webex Web App et Cisco connectés au cloud. À terme, l'architecture E2E ouverte et basée sur des normes devrait permettre à Webex d'intégrer également une infrastructure SIP (Session Initiation Protocol).

Les innovations évoquées dans cet article indiquent clairement la voie à suivre pour atteindre la vision à long terme d'un cryptage E2E permanent. Une fois que les utilisateurs peuvent se connecter de n'importe où et que les clients peuvent accéder en toute sécurité aux fonctionnalités qu'ils souhaitent lors d'une réunion, le cryptage E2E peut être utilisé pour chaque réunion Webex, qu'il s'agisse de réunions ad hoc informelles où toutes les fonctionnalités sont activées ou de réunions verrouillées et hautement sécurisées. Le cryptage E2E garantit toujours que le contenu de la réunion n'est accessible qu'aux participants autorisés, et ce sont les clients et les utilisateurs qui décideront quel groupe de participants convient le mieux à une réunion donnée.

Usurpation d'identité grâce à l'IA et résilience aux deepfake

Webex répond aux menaces d'usurpation d'identité liées à l'IA grâce à une approche multicouche qui complète le modèle de cryptage de bout en bout Zero Trust. Bien que cet article se concentre sur les fondements techniques de l'identité vérifiée de bout en bout, y compris la vérification basée sur des certificats fournis par le client et les contrôles d'intégrité cryptographique, Webex propose également des contrôles de sécurité opérationnels lors de l'expérience des réunions afin de réduire le risque d'accès non autorisé et d'interactions nuisibles.

Pour les types de sessions de réunion, les différences de sécurité entre les réunions planifiées et les salles de réunion personnelles, les contrôles des hôtes et des administrateurs dans Control Hub, ainsi que la détection et la prévention supplémentaires de l'IA et des deepfake dans le cadre de l'expérience de réunion au sens large, consultez le document technique complémentaire sur la sécurité de WSMP Meetings.

Webex définit l'avenir des réunions sécurisées grâce à une cryptographie normalisée et à une identité vérifiée. L'engagement en faveur d'un écosystème ouvert permet aux clients de garder le contrôle absolu de leurs données, quel que soit le scénario de la réunion.