Sécurité et programme de bug bounty

Comment vos données sont protégées, en termes simples

L'appairage commence par un code QR affiché sur votre PC. Il contient un secret à usage unique qui expire au bout de deux minutes : seul un appareil qui a réellement vu votre écran peut donc s'appairer. Les deux écrans affichent ensuite le même code à 6 chiffres, et vous confirmez qu'ils sont identiques.

• Chaque connexion est chiffrée de bout en bout avec le protocole Noise (X25519, ChaCha20-Poly1305, BLAKE2s). Chaque appareil possède sa propre clé, qui ne le quitte jamais, et les appareils se reconnaissent grâce à cette clé, et non par l'adresse IP, le nom ou un compte.
• Chaque connexion et chaque flux de données utilisent de nouvelles clés (confidentialité persistante) : une clé volée plus tard ne permet pas de déchiffrer le trafic enregistré auparavant.
• Le chiffrement se situe au-dessus du réseau : il vous protège de la même façon sur le Wi-Fi, via internet (QUIC, TCP ou WebRTC) et à travers notre service de rendez-vous, qui ne fait que relayer des messages scellés qu'il ne peut pas lire.
• Être appairé ne donne pas tous les droits : chaque appareil n'obtient que les autorisations que vous accordez, et la saisie à distance comme la caméra demandent votre accord à chaque session.
• Les fichiers, liens et contenus du presse-papiers reçus sont vérifiés avant utilisation : ils ne peuvent pas sortir du dossier de téléchargement, les types de liens dangereux sont refusés et les tailles sont limitées.

La spécification technique complète et le modèle de menaces figurent dans notre documentation de sécurité, que nous partageons avec les chercheurs et les auditeurs.

État de l'audit

Nous préférons être précis plutôt qu'impressionnants :

• Revue de sécurité interne : effectuée. La conception, l'appairage, le chiffrement des sessions, les autorisations et la validation des entrées ont été examinés au regard d'un modèle de menaces écrit, et les règles de sécurité sont couvertes par des tests automatisés exécutés à chaque modification.
• Contrôles automatisés : les alertes de sécurité et les licences des dépendances sont vérifiées à chaque modification, et les parties qui lisent des données non fiables sont soumises chaque semaine à du fuzzing.
• Audit externe : prévu avant la version 1.0 et pas encore réalisé. Une fois terminé, nous publierons ici l'auditeur, le périmètre et une synthèse des constats.

D'ici là, Personal Device Bridge reste une préversion. Gardez-le à l'esprit avant de l'utiliser pour des données très sensibles.

Vérifiez ce que vous téléchargez

Vous n'avez pas à nous croire sur parole pour savoir qu'un téléchargement est authentique :

• Sommes de contrôle : chaque version comprend un fichier SHA256SUMS couvrant tous ses fichiers, pour vérifier que votre copie est exactement celle que nous avons publiée.
• Builds reproductibles : l'outil en ligne de commande pour Linux est compilé de manière déterministe. Toute personne disposant du code source au tag de la version peut le recompiler et obtenir un fichier identique bit à bit ; un contrôle automatique le compile deux fois dans des environnements différents et échoue si un seul octet diffère.
• Provenance de la compilation : notre chaîne de publication est prête à joindre à chaque fichier une attestation de provenance SLSA signée (Sigstore), indiquant quel workflow et quel commit l'ont produit ; vous pouvez la vérifier avec la commande « gh attestation verify ». GitHub l'active une fois le dépôt de code public, et nous l'annoncerons ici dès qu'elle sera en service.
• Signature de code : notre chaîne de publication signe les programmes et installateurs Windows avec Authenticode (Azure Artifact Signing) ; avant d'exécuter un fichier, vous pouvez vérifier l'éditeur dans Propriétés → Signatures numériques.

Les versions Windows et Android ne sont pas encore reproductibles ; ce travail est prévu. Les instructions de vérification pas à pas pour bash et PowerShell figurent dans notre guide des builds reproductibles, disponible sur demande.

Tests en continu

Chaque décodeur qui lit des données provenant d'un autre appareil ou du réseau (enveloppes de messages, liens d'appairage, balises de découverte, noms de fichiers et messages des fonctionnalités) est soumis chaque semaine à du fuzzing avec libFuzzer, qui lui envoie des millions d'entrées malformées pour détecter les plantages et les contrôles de sécurité défaillants.

En outre, des tests unitaires, d'intégration et de bout en bout s'exécutent sur Windows et Linux à chaque modification, y compris des tests où deux processus réels s'appairent et échangent des fichiers sur le réseau.

Ce qui entre dans le périmètre

Signalez tout ce qui pourrait nuire à la sécurité ou à la vie privée de nos utilisateurs dans :

• Le moteur principal : identité des appareils et stockage des clés, appairage par QR, sessions chiffrées, protocole de communication, transports (QUIC, TCP, WebRTC), découverte, confiance et autorisations, ainsi que toutes les fonctionnalités (transfert de fichiers, presse-papiers, liens, Continue, MyDrop, SmartPrint, explorateur de fichiers, notifications, saisie à distance, caméra).
• Les applications : l'outil en ligne de commande pdb, l'application de bureau Windows et ses installateurs, et l'application Android.
• Le service de rendez-vous que nous exploitons pour les connexions par internet.
• Ce site web, personaldevicebridge.com.
• Notre processus de publication : workflows de compilation et de publication, signature de code, sommes de contrôle et provenance.

Nous nous intéressons particulièrement aux cas suivants : s'appairer sans voir le code QR, casser le chiffrement ou l'authentification des appareils, un appareil appairé qui fait plus que ce qui lui est permis, lire ou écrire des fichiers hors du dossier prévu, exécuter du code via des données reçues, et un service de rendez-vous qui découvre ou modifie le contenu des messages.

Ce qui est hors périmètre

• Le déni de service par simple volume de trafic, les tests de charge de nos services hébergés et le spam.
• L'ingénierie sociale ou le hameçonnage visant notre équipe ou nos utilisateurs, et les attaques physiques.
• Les attaques qui supposent un appareil ou un compte utilisateur déjà compromis (par exemple un logiciel malveillant exécuté sous l'identité de l'utilisateur), un téléphone rooté ou jailbreaké, ou un accès physique à un appareil déverrouillé.
• Les informations visibles par conception sur le réseau local, comme la présence d'un appareil ou le volume du trafic.
• Les limites déjà décrites dans notre documentation de sécurité, sauf si vous démontrez un impact plus grave.
• Les bogues des plateformes tierces elles-mêmes (Cloudflare, Railway, GitHub, Google) : signalez-les à l'éditeur concerné. La manière dont nous les utilisons, elle, entre dans le périmètre.
• Les signalements sans impact de sécurité démontré : en-têtes manquants sur des pages statiques, configuration SPF/DMARC de la messagerie, self-XSS, numéros de version, ou résultats d'outils d'analyse sans preuve de concept.

Comment signaler

Écrivez à [email protected] avec l'objet « [SECURITY] titre court », en coréen ou en anglais. Merci d'indiquer :

• l'application ou le composant concerné et sa version ;
• la nature du problème et ce qu'un attaquant pourrait en faire (un vecteur CVSS est bienvenu) ;
• les étapes de reproduction ou une preuve de concept, et la plateforme utilisée pour vos tests ;
• si et comment vous souhaitez être crédité.

Merci de ne pas signaler de vulnérabilités via des tickets publics ou les réseaux sociaux.

Chiffrement : nous n'avons pas encore publié de clé PGP. Lorsque ce sera le cas, elle sera placée dans le dossier /.well-known/ de ce site et indiquée dans personaldevicebridge.com/.well-known/security.txt. D'ici là, si votre signalement contient des détails sensibles sur l'exploitation, envoyez d'abord un court message sans ces détails et nous conviendrons avec vous d'un canal sécurisé.

Notre code source est propriétaire. Si vous avez besoin d'y accéder pour mener vos recherches ou confirmer une découverte, demandez-le-nous ; chaque demande est examinée individuellement.

Ce qui se passe après votre signalement

• Nous accusons réception de votre signalement sous 72 heures.
• Nous le qualifions (validité, gravité et versions concernées) sous 7 jours, puis nous vous tenons informé au moins tous les 14 jours jusqu'à sa résolution.
• Objectifs de correction à partir de la qualification : Critique sous 30 jours (avec une mesure d'atténuation sous 7 jours si possible), Élevée sous 60 jours, Moyenne sous 90 jours, Faible dans une version planifiée ultérieure.

Nous sommes une petite équipe. Si nous ne pouvons pas tenir un délai, nous vous expliquerons pourquoi et quand attendre le correctif.

Récompenses

Les récompenses sont discrétionnaires. Elles dépendent de l'impact, de la qualité du signalement et du fait que le problème nous soit inconnu ou non ; la première personne à signaler un problème y est éligible. Nous évaluons la gravité avec CVSS (v3.1 ou v4.0) sur la dernière version et vous expliquons notre évaluation.

Les doublons, les problèmes hors périmètre et les signalements qui enfreignent cette politique ne sont pas récompensés. Plusieurs problèmes enchaînés comptent comme une seule découverte, à la gravité qui en résulte.

Les récompenses sont versées en wons coréens ; les montants en dollars sont approximatifs. Le paiement nécessite les informations exigées par la fiscalité coréenne et notre banque, et ne peut pas être effectué lorsque la loi ou des sanctions l'interdisent. Vous pouvez aussi nous demander de reverser votre récompense à une association caritative.

Sphère de sécurité (safe harbour)

Si vous vous efforcez de bonne foi de respecter cette politique, nous considérons vos recherches comme autorisées. Nous n'engagerons ni ne soutiendrons aucune action en justice contre vous et ne vous signalerons pas aux autorités pour ces recherches. Si un tiers agit contre vous pour des recherches conformes à cette politique, nous ferons savoir que vous disposiez de notre autorisation.

Agir de bonne foi signifie que vous :

• ne testez que vos propres appareils, installations, appairages et boîtes du service de rendez-vous ;
• n'accédez pas aux données d'autrui, ne les modifiez pas et ne les conservez pas ; si vous en rencontrez, vous arrêtez, vous nous prévenez et vous les supprimez ;
• ne perturbez pas nos services et ne laissez pas de modifications durables ;
• nous laissez le temps de corriger le problème avant de le divulguer ;
• ne demandez jamais d'argent en échange de votre silence.

Nous ne pouvons pas autoriser de tests sur des systèmes qui ne nous appartiennent pas. En cas de doute, demandez-nous d'abord.

Divulgation coordonnée

Merci de nous laisser 90 jours à compter de votre signalement (ou jusqu'à la publication d'un correctif, si elle intervient plus tôt) avant de publier des détails. Pour un correctif complexe, nous pouvons demander une courte prolongation et fixerons la date avec vous.

Après la correction, nous publions un avis de sécurité dans les notes de version et vous créditons, sauf si vous préférez rester anonyme. Si un problème est activement exploité, nous pouvons le divulguer plus tôt, en accord avec vous.

Coordonnées pour les outils

Nos coordonnées sont aussi publiées au format standard lisible par machine (RFC 9116) à l'adresse personaldevicebridge.com/.well-known/security.txt, qui renvoie vers cette page. Nous répondons en coréen ou en anglais.

Tableau d'honneur

Merci à toutes les personnes qui contribuent à la sécurité de nos utilisateurs. Les chercheurs qui signalent des problèmes valides figurent ici, avec leur accord.

Aucun chercheur n'a encore été crédité : votre signalement pourrait être le premier.