Détails techniques de sécurité
Ceci est une traduction. En cas de divergence, la version italienne fait foi.
Cette page s’adresse à celles et ceux qui doivent évaluer Walkie Desk d’un point de vue technique. Pour une vue d’ensemble, consultez Sécurité.
Elle décrit le service tel qu’il est aujourd’hui, en bêta : quand quelque chose change, nous la mettons à jour.
Vue d’ensemble
Walkie Desk comporte quatre éléments : le programme sur le PC à joindre, le navigateur de la personne qui se connecte, le serveur de coordination sur walkiedesk.app et un serveur relais (TURN), utilisé uniquement quand les deux appareils ne parviennent pas à se connecter directement.
- Navigateur et walkiedesk.app : HTTPS et WebSocket sécurisé (TLS). Servent à se connecter au compte et à échanger les paramètres de la session, signés par les appareils.
- PC et walkiedesk.app : WebSocket sécurisé (TLS) ouvert par le service Windows, qui vérifie toujours le certificat et le nom du serveur, y compris le contrôle de révocation.
- PC et navigateur : la session elle-même (vidéo, son de l’ordinateur, clavier, souris, presse-papiers, fichiers et chat), via WebRTC et chiffrée de bout en bout. Le serveur de coordination ne se trouve pas sur ce chemin.
- Relais : si une connexion directe n’est pas possible, les mêmes paquets chiffrés passent par le serveur relais, qui n’a pas les clés pour les lire.
Chiffrement
La session utilise WebRTC. La vidéo et le son de l’ordinateur circulent en SRTP, avec des clés négociées via DTLS (DTLS-SRTP) ; le clavier, la souris, le presse-papiers, les fichiers, les messages du chat et les commandes circulent dans des data channels, c’est-à-dire du SCTP dans du DTLS. Les clés sont négociées entre le PC et le navigateur et y restent : ni le serveur de coordination ni le serveur relais ne les connaissent.
Lors de la négociation DTLS, chaque appareil présente un certificat dont l’empreinte est inscrite dans les paramètres de la session (SDP). Ces paramètres sont signés par les appareils (ci-dessous) : ainsi, le navigateur sait qu’il parle au bon PC, et le PC au bon navigateur.
Entre les appareils et walkiedesk.app, tout passe par HTTPS et WebSocket sécurisé (TLS), avec HSTS.
- Vidéo et son de l’ordinateur
- SRTP avec clés DTLS (DTLS-SRTP) ; audio encodé en Opus
- Clavier, souris, presse-papiers, fichiers, chat
- data channels WebRTC : SCTP sur DTLS
- Signatures des appareils
- ECDSA P-256
- Empreinte des paramètres signés
- SHA-256
- Association, QuickSupport et ID et mot de passe
- CPace, échange de clés authentifié par mot de passe
- Appels
- DTLS-SRTP entre les deux navigateurs ; paramètres authentifiés par HMAC-SHA-256 et une clé dérivée par HKDF d’un secret à usage unique
- Mots de passe des comptes
- Argon2id
- Second facteur
- TOTP ou WebAuthn (clé de sécurité ou clé d’accès)
- Composants sur le PC
- libdatachannel, OpenSSL, libsrtp, libsodium, Opus
- Composants dans le navigateur
- l’implémentation WebRTC de Chrome, Edge ou Firefox
Nous utilisons des composants open source largement répandus, que nous tenons à jour ; la liste complète de chaque version (SBOM), avec les versions, les licences et la provenance, est publique : Composants logiciels.
Identité des appareils et signature des sessions
Chaque PC équipé de Walkie Desk et chaque navigateur de confiance possède sa propre paire de clés ECDSA P-256 :
- sur le PC, la clé privée est créée dans la puce TPM, non exportable, quand le PC en possède une ; sinon dans le magasin de clés de Windows, également non exportable ;
- dans le navigateur, c’est une clé WebCrypto non extractible, conservée dans IndexedDB : la page peut l’utiliser pour signer, mais pas la lire.
Les navigateurs de confiance d’une personne forment une chaîne signée : le premier la crée, et chaque navigateur suivant n’y entre qu’avec une entrée signée par un appareil déjà présent dans la chaîne. Il existe trois façons de le faire :
- l’approbation depuis un navigateur déjà de confiance, avec un code à usage unique échangé via CPace : le navigateur de confiance signe l’entrée après que la personne a confirmé la connexion avec l’application d’authentification ou la clé d’accès (protection contre un ordinateur laissé déverrouillé) ; elle est active immédiatement et un e-mail est envoyé ;
- la clé d’accès de l’utilisateur (WebAuthn, ES256 ou RS256), qui est le même identifiant que celui utilisé pour se connecter : liée à l’appareil ou synchronisée, elle a les mêmes pouvoirs et l’entrée est active immédiatement, avec un e-mail. L’assertion de connexion utilise un challenge avec un préfixe différent de celui des signatures de la chaîne, de sorte que le serveur ne peut pas faire passer une connexion pour une signature ;
- le code de récupération : à partir du code, le navigateur obtient la clé de récupération (sa partie privée est chiffrée avec le code, qui ne quitte jamais le navigateur). Un navigateur ajouté de cette façon ne devient actif sur les PC que 10 minutes après qu’ils l’ont reçu ; entre-temps, l’utilisateur reçoit un e-mail avec un lien pour l’interrompre, et une entrée signée par un navigateur de confiance ou une clé d’accès annule l’ajout.
Chaque PC vérifie toutes les signatures de la chaîne avant d’accepter un navigateur, et décompte lui-même les 10 minutes. Le serveur conserve la chaîne mais ne peut pas y ajouter de navigateur, car il n’a pas les clés pour la signer. Un PC doté d’une version antérieure de Walkie Desk applique les règles précédentes (par exemple, il exige aussi la clé d’accès pour approuver un navigateur) : tant qu’il n’est pas mis à jour, l’espace utilisateur le signale et ne propose que les opérations acceptées par ce PC.
Avant chaque session, le PC signe sa proposition de connexion et le navigateur signe sa réponse, empreintes DTLS comprises. Chaque partie vérifie la signature de l’autre avec une clé qu’elle connaît déjà, avant d’utiliser les paramètres.
Ce que cela protège : si quelqu’un sur le chemin de coordination, serveur compris, remplaçait une empreinte DTLS pour s’interposer entre le PC et le navigateur, la signature ne serait plus valide et la session serait refusée. Le serveur met les appareils en relation, mais ne peut pas se faire passer pour eux. Ce que cela ne couvre pas est expliqué dans Limites connues.
Ce que le serveur voit et ne voit pas
Il voit
- les PC (identifiant, clé publique, nom de l’ordinateur, versions de Windows et du programme), les comptes et les clés publiques des navigateurs de confiance ;
- les données de chaque session : qui se connecte à quel PC, quand et pour combien de temps, si elle passe par le relais, si elle a été enregistrée (oui ou non), des statistiques techniques de qualité ;
- les journaux techniques des serveurs, comme les adresses IP et les pages demandées ;
- pour l’accès avec ID et mot de passe, les tentatives échouées (compte, adresse IP, PC, heure) et, pour chaque utilisateur, la liste « Récents » des PC d’autres personnes auxquels il s’est connecté ;
- pour les appels, qui a appelé quel PC et quand, ainsi que les paramètres de connexion (adresses réseau et empreintes DTLS).
Il ne voit pas
- le contenu des sessions : écran, son de l’ordinateur, frappes au clavier, souris, presse-papiers, fichiers transférés et messages du chat ;
- l’audio et la vidéo des appels, ni si le micro et la webcam sont allumés ;
- les enregistrements de session, qui restent sur l’appareil de la personne qui enregistre ;
- le mot de passe de QuickSupport, celui de l’accès avec ID et mot de passe et la partie secrète du code d’association ;
- les clés privées des PC et des navigateurs.
Le serveur relais, quand la session passe par lui, ne transporte que des paquets chiffrés : il n’a pas les clés pour les lire et ne conserve ni le contenu des sessions, ni les fichiers, ni les messages.
Les serveurs sont en Italie ; les données et les sauvegardes restent dans l’Union européenne. Ce que nous conservons, pendant combien de temps et avec quels prestataires : politique de confidentialité.
Compte
- Mots de passe de 12 à 128 caractères, sans règles de composition, stockés uniquement sous forme d’empreinte Argon2id.
- Un second facteur est obligatoire pour chaque compte dès l’inscription : une application d’authentification (TOTP) ou une clé d’accès (WebAuthn, y compris une clé de sécurité), ou les deux. Ni SMS ni e-mail comme facteur.
- Un code de récupération unique (128 bits) créé dans le navigateur : le serveur ne conserve que l’empreinte d’une valeur dérivée par HKDF, jamais le code. Des tentatives erronées répétées bloquent le code pendant un certain temps.
- Les tentatives de connexion échouées répétées sont bloquées ; les connexions et les changements de mot de passe ou de second facteur sont journalisés comme événements de sécurité.
- Bientôt : la connexion sans mot de passe, uniquement avec une clé d’accès.
Accès sans surveillance
- Un PC équipé de Walkie Desk n’est pas joignable tant que vous ne l’avez pas associé à un compte.
- Pour l’associer, vous générez un code de 9 caractères dans l’espace utilisateur et vous le saisissez sur le PC. Le code expire au bout de quelques minutes et n’accepte que très peu de tentatives. Une partie du code est un secret créé dans votre navigateur, qui n’arrive jamais au serveur : le PC et le navigateur l’utilisent avec CPace pour se reconnaître et échanger leurs clés publiques, si bien que le serveur ne peut pas associer un PC à votre place.
- Vous pouvez retirer un PC de votre compte dans l’espace utilisateur, et la personne qui administre le PC peut révoquer l’accès d’un compte depuis l’application Walkie Desk sur le PC.
- Pendant chaque session, le PC affiche par défaut un cadre rouge autour de l’écran avec le nom de la personne connectée et un bouton Terminer. La personne qui administre le PC peut masquer le cadre dans les sessions avec compte ; si la session est enregistrée, le PC le signale malgré tout.
- La personne qui administre le PC décide si le transfert de fichiers est autorisé, doit être confirmé à chaque fois ou n’est pas autorisé, et dans quels sens. Le réglage se trouve sur le PC : ni le serveur ni un compte ne peuvent l’élargir.
QuickSupport
- Il s’exécute sans installation et avec les droits de l’utilisateur ; la personne aidée n’a pas besoin de compte.
- Il affiche un ID de 9 chiffres et un mot de passe de 6 caractères. Le mot de passe n’est jamais envoyé au serveur : l’ordinateur et le navigateur du technicien l’utilisent avec CPace pour se reconnaître. Il n’est valable que pour une seule session et change après quelques tentatives erronées.
- La clé de l’ordinateur est créée à chaque démarrage et reste uniquement dans la mémoire du programme : elle disparaît quand vous le fermez.
- Avant chaque session, une fenêtre indique qui veut se connecter : la session ne démarre que si vous appuyez sur Autoriser ; si personne ne répond, la demande est refusée peu après.
- Pendant la session, un cadre rouge entoure l’écran et le bouton Terminer la ferme à tout moment. Le cadre ne peut pas être masqué.
- Un enregistrement de la session ne démarre que si la personne devant le PC l’autorise dans une fenêtre dédiée, à chaque enregistrement.
- À la fermeture, le programme supprime le dossier temporaire qu’il avait créé.
Contre les arnaques au faux support technique : Protection contre les arnaques.
ID et mot de passe
- Depuis la version 0.10.0, chaque PC équipé de Walkie Desk pour Windows, Linux ou Mac possède, en plus de son ID, un mot de passe : aléatoire, généré sur le PC et affiché dans l’application, ou choisi par l’administrateur du PC.
- Le mot de passe n’est jamais envoyé au serveur : le navigateur de la personne qui se connecte et le PC l’utilisent avec CPace pour se reconnaître, comme dans QuickSupport. Le serveur achemine les messages mais ne peut ni vérifier le mot de passe ni s’interposer : l’offre de connexion du PC est signée avec sa clé et authentifiée avec la clé issue de l’échange CPace.
- La personne qui se connecte doit avoir un compte Walkie Desk, avec un second facteur, depuis un navigateur de confiance ; la session porte son nom signé.
- Par défaut, après le bon mot de passe, le PC demande à la personne qui se trouve devant lui de confirmer, dans une fenêtre qui n’accepte que le clavier et la souris physiques : quelqu’un qui contrôle déjà le PC ne peut pas confirmer à sa place. La confirmation ne peut être supprimée qu’avec un mot de passe choisi par l’administrateur du PC, car le mot de passe aléatoire est visible par toute personne qui utilise le PC.
- Les tentatives erronées sont limitées sur le serveur (par compte, adresse IP et PC) et sur le PC, qui bloque l’accès par mot de passe pendant une durée croissante et le signale dans l’application ; le blocage ne concerne que l’accès par mot de passe, pas les comptes associés.
- Sur le PC, le mot de passe aléatoire est stocké de façon protégée (sous Windows avec la protection des données de la machine, sous Linux dans un fichier lisible uniquement par l’administrateur système) ; pour un mot de passe choisi par l’administrateur, seule une valeur dérivée est conservée.
Son de l’ordinateur et appels
- Son de l’ordinateur. Le PC capture ce qu’il diffuse uniquement si un technicien le demande, et l’envoie sous forme de piste audio WebRTC (Opus sur DTLS-SRTP), avec les mêmes clés et les mêmes paramètres signés que la vidéo. Il est coupé au début de chaque session et le cadre sur le PC indique qui le reçoit.
- Appels (fonction en bêta). La voix et la webcam ne passent pas par le programme sur le PC : une fois que la personne devant le PC a répondu, le programme ouvre la page d’appel de walkiedesk.app dans son navigateur par défaut, avec un secret à usage unique dans la partie de l’adresse que le navigateur n’envoie pas au serveur. Le même secret parvient au navigateur du technicien à l’intérieur de la session, déjà chiffrée et authentifiée.
- Les deux pages se connectent par une connexion WebRTC distincte (DTLS-SRTP), directe ou via le serveur relais. L’offre et la réponse portent un code d’authentification (HMAC) avec une clé dérivée du secret, que le serveur ne connaît pas : un serveur qui remplacerait une empreinte DTLS serait détecté par les deux parties.
- Le serveur sait qu’il y a un appel, entre qui et quand, mais pas ce qui est dit ; les appels ne sont pas enregistrés et l’enregistrement de session ne les inclut pas.
- La fenêtre qui annonce l’appel sur le PC n’accepte que le clavier et la souris physiques. Avec QuickSupport, les appels ne sont pas disponibles après un redémarrage en tant qu’administrateur, car le navigateur démarrerait avec ces droits.
Programmes signés et codec OpenH264
Le programme d’installation de Walkie Desk pour Windows, ses programmes et QuickSupport sont signés avec Authenticode par l’éditeur iDev srl, avec un horodatage : la signature reste vérifiable même après l’expiration du certificat. Les bibliothèques tierces incluses ne sont pas signées par nous.
Le codec OpenH264 n’est pas inclus : le programme le télécharge depuis le site de Cisco et ne l’utilise que si son empreinte SHA-256 est celle attendue.
Comment vérifier l’éditeur et l’empreinte d’un fichier téléchargé : Sécurité.
Mises à jour et période de support
- Walkie Desk pour Windows se met à jour tout seul depuis la version 0.8.0, sans interrompre les sessions en cours : il n’installe une mise à jour que si son manifeste est signé avec la clé de publication de Walkie Desk et si le programme d’installation porte la signature numérique d’iDev srl. Walkie Desk pour Linux et pour Mac (en bêta) ne se met pas encore à jour tout seul : les nouvelles versions s’installent depuis la page Téléchargement.
- QuickSupport n’est pas mis à jour : il est téléchargé depuis le site à chaque fois, c’est donc toujours la dernière version.
- Période de support : pendant la bêta, seule la dernière version reçoit des correctifs. À partir du lancement, chaque version reçoit des correctifs de sécurité jusqu’à 12 mois après la sortie de la version suivante, et le produit est pris en charge pendant au moins 5 ans à compter du lancement.
- Les vulnérabilités corrigées sont publiées dans les avis de sécurité, avec les versions concernées et la version qui les corrige.
- La nomenclature logicielle de chaque version (SBOM, format CycloneDX) est publique : Composants logiciels.
Mise à jour automatique, signature des versions avec la clé de publication, réglages pour la désactiver, vérification publique d’une version et versions précédentes : Mises à jour.
Limites connues
Le code de l’application web, c’est-à-dire l’espace utilisateur et le viewer depuis lequel le technicien se connecte, est fourni par le serveur walkiedesk.app à chaque visite. La signature des paramètres protège les sessions contre quiconque modifierait les messages de coordination, mais pas contre un serveur compromis qui fournirait au navigateur un code modifié.
Mesure d’atténuation actuelle : une Content Security Policy stricte, qui n’autorise que les scripts du même domaine et aucune ressource tierce, à l’exception du composant de paiement de Stripe, sur la seule page Abonnement. Un viewer signé, vérifiable sans faire confiance au serveur, est une amélioration prévue.
Il en va de même pour la page d’appel qui s’ouvre dans le navigateur du PC, elle aussi servie par walkiedesk.app. Un technicien qui contrôle déjà le PC pourrait ouvrir lui-même une page d’appel sans passer par la fenêtre de réponse : c’est un pouvoir qu’il a de toute façon, puisque le contrôle lui permet de lancer n’importe quel programme ou site ; l’onglet du navigateur et l’indicateur d’utilisation du micro du système restent visibles.
Signaler un problème
- Politique de divulgation : comment signaler une vulnérabilité et à quoi vous attendre.
- Avis de sécurité, également sous forme de flux Atom.
- Signaler un problème : vulnérabilités, abus, autres problèmes de sécurité ou de confidentialité.
- E-mail : security@walkiedesk.app.