L’architecture de sécurité de Remio, en toute simplicité.

§01 · Résumé

Remio est une application de bureau à distance bâtie sur une architecture de pair à pair à connaissance nulle. Le contenu de l’écran, les données de saisie et les flux audio sont chiffrés de bout en bout entre les appareils avec DTLS-SRTP, la norme du secteur — le même modèle de sécurité que celui sur lequel repose tout produit fondé sur WebRTC. Contrairement aux solutions centralisées, le serveur de signalisation de Remio ne facilite que l’établissement initial de la connexion — il ne voit, ne traite ni ne stocke jamais les données de session.

Aucun compte n’est requis, il n’y a aucun mot de passe à pirater, aucune base centrale d’identifiants. Le jumelage des appareils utilise des codes à six chiffres lus sur l’écran même de l’hôte, et toutes les clés de session sont éphémères avec confidentialité persistante parfaite (Perfect Forward Secrecy) : même si une clé est compromise, les sessions passées et futures restent cryptographiquement sûres. Cette architecture élimine des catégories entières d’attaques qui ont affligé les concurrents — parce qu’il n’y a tout simplement rien à voler.

§02 · Modèle de menaces

L’architecture de sécurité de Remio est conçue face à un ensemble de scénarios de menace pertinents pour l’usage du bureau à distance, en entreprise comme à titre personnel. Nous sommes explicites sur ce contre quoi nous protégeons, et sur l’emplacement des frontières de confiance.

Les menaces contre lesquelles nous protégeons

• L’écoute. Tous les flux médias (vidéo, audio) et canaux de données (saisie, clavier, curseur) sont chiffrés respectivement avec SRTP et DTLS. Un observateur du réseau ne voit que des paquets chiffrés, sans aucun moyen de reconstituer le contenu de la session.
• L’attaque de l’homme du milieu (MITM). La négociation DTLS avec vérification de l’empreinte du certificat empêche l’interception. Le canal de signalisation utilise TLS 1.3 avec confidentialité persistante parfaite.
• La compromission du serveur. Même si notre serveur de signalisation était entièrement compromis, les attaquants n’accéderaient qu’aux métadonnées de connexion (adresses IP, horodatages). Le contenu des sessions ne transite jamais par nos serveurs et n’y est jamais stocké.
• L’accès non autorisé. Le jumelage par code PIN exige une proximité physique ou la connaissance d’un code PIN affiché. Il n’existe aucune base d’identifiants accessible à distance à attaquer.
• Le vol d’identifiants. Ni mots de passe, ni comptes, ni magasin central d’identifiants. La confiance entre appareils est établie par le jumelage par code PIN ; les jetons de session (JWT) sont de courte durée et liés à l’appareil.
• Le rejeu de session. La protection intégrée de SRTP contre le rejeu et les numéros de séquence DTLS empêchent le rejeu de paquets capturés.
• Les attaques de la chaîne d’approvisionnement. Tous les binaires de Remio sont signés. Les versions macOS sont notarisées par Apple. Les versions iOS sont distribuées exclusivement via l’App Store.

Frontières de confiance

Notre modèle de menaces définit explicitement trois frontières de confiance :

1. Frontière de l’appareil. Chaque appareil n’est approuvé qu’après vérification du code PIN. Les protections au niveau de l’OS (bac à sable, Keychain, Secure Enclave) protègent les données présentes sur l’appareil.
2. Frontière du réseau. Toutes les données en transit sont chiffrées. Nous partons du principe que le réseau est hostile.
3. Frontière du serveur. Nos propres serveurs sont traités comme des relais non fiables. Ils facilitent les connexions mais ne peuvent pas inspecter le contenu.

§03 · Vue d’ensemble de l’architecture

Remio sépare le plan de signalisation (mise en place de la connexion) du plan de données (diffusion). Cette séparation est fondamentale pour notre conception à connaissance nulle — le serveur qui vous aide à vous connecter ne touche jamais aux données que vous échangez.

Signalisation et plan de données

La seule responsabilité du serveur de signalisation est de relayer les offres/réponses SDP et les candidats ICE entre les appareils pendant la mise en place de la connexion. Une fois la connexion P2P établie, le serveur de signalisation n’intervient plus.

Le serveur ne peut pas analyser le contenu relayé — c’est un blob binaire chiffré que seul l’appareil cible peut interpréter. Le protocole binaire ajoute une couche de structure supplémentaire qui rend les attaques par injection plus difficiles qu’avec une signalisation fondée sur JSON.

§04 · Couches de chiffrement

Remio emploie une stratégie de chiffrement à plusieurs couches où chaque canal de communication utilise le protocole cryptographique le mieux adapté à ses besoins.

Confidentialité persistante parfaite

Chaque session Remio génère un jeu unique de clés de chiffrement éphémères grâce à l’échange de clés ECDHE.

• Compromettre la clé de la session en cours n’expose pas les sessions passées.
• Compromettre la clé de la session en cours n’expose pas les sessions futures.
• Chaque paire de clés n’existe que pendant la durée d’une seule session.
• Les clés ne sont jamais écrites sur le disque — elles n’existent qu’en mémoire.

Suites de chiffrement

# Signalisation — suites de chiffrement TLS 1.3 (par ordre de préférence)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Médias — profil de protection SRTP (valeur par défaut du secteur pour WebRTC)
SRTP_AES128_CM_SHA1_80   # AES-128 en mode compteur, authentification HMAC-SHA1-80

# Certificats DTLS
Auto-signés ECDSA (P-256), vérifiés hors bande via les empreintes SDP

Rotation des clés

Les clés sont renouvelées automatiquement aux étapes suivantes :

• Début de session. Une nouvelle négociation DTLS génère de nouvelles clés pour chaque connexion.
• Dérivation des clés SRTP. Les clés des flux médias sont dérivées de la négociation DTLS et sont uniques pour chaque piste média.
• Reconnexion. Si une session est interrompue puis reconnectée, un tout nouvel échange de clés a lieu.

§05 · Authentification et jumelage

Remio évite délibérément l’authentification traditionnelle par nom d’utilisateur et mot de passe. Nous utilisons à la place un modèle de jumelage d’appareils par code PIN qui élimine les vecteurs d’attaque les plus courants des logiciels de bureau à distance.

Jumelage par code PIN

Quand un client veut se connecter à un hôte pour la première fois, le processus se déroule ainsi :

1. L'hôte affiche à l’écran un court code PIN numérique (ou sous forme de QR code).
2. Le client saisit le code PIN, qui est envoyé à l’hôte via le canal de signalisation.
3. L’hôte valide le code PIN et confirme ou refuse le jumelage.
4. En cas de succès, une relation de confiance entre appareils est établie.
5. Les connexions suivantes depuis le même appareil n’exigent pas de nouveau jumelage.

Modèle de confiance entre appareils

Une fois jumelé, chaque appareil est identifié par un identifiant d’appareil unique. L’hôte tient une liste locale des appareils de confiance. Cette relation de confiance est :

• Stockée localement sur l’appareil hôte uniquement, dans le Keychain de l’OS.
• Jamais transmise — le serveur ne sait pas quels appareils sont de confiance.
• Révocable — l’hôte peut retirer un appareil de confiance à tout moment.

Jetons de session (JWT)

Après le jumelage, des jetons signés de courte durée (expiration à 24 heures) servent à l’authentification auprès du serveur de signalisation.

Ces jetons authentifient un appareil auprès du serveur de signalisation pour la création de salles et le relais de messages. Ils ne donnent pas accès au contenu des sessions, qui est protégé par une négociation DTLS distincte.

Accès des agents IA (serveur MCP de Remio)

Remio étend ce même modèle de confiance aux agents IA. Des outils comme Claude Code, Codex ou l’app Claude peuvent piloter vos machines à distance via le serveur MCP de Remio — et la frontière de sécurité est identique à celle que franchit un client humain :

• Tout est conditionné par votre connexion. Un agent ne peut atteindre que les hôtes en ligne et jumelés au compte avec lequel vous vous êtes authentifié (connexion Google ou Apple, via OAuth). Pas de compte authentifié, pas d’outils.
• Remio est un courtier, pas un opérateur. Le seul rôle du serveur MCP est d’exposer un ensemble d’outils limités à votre compte authentifié et de les confier à l’outil d’IA que vous avez choisi de connecter. Remio ne peut pas démarrer de lui-même une session avec votre machine — un hôte n’accepte que les connexions qui présentent la preuve de l’autorisation de votre compte, exactement comme dans le modèle de confiance entre appareils ci-dessus.
• Le même transport chiffré. Les sessions d’agent circulent sur les mêmes canaux chiffrés de bout en bout décrits au §04. Nos serveurs ne voient toujours que des blobs chiffrés — les propriétés de connaissance nulle du §06 s’appliquent sans changement.
• Visible, révocable, auditée. Une session d’agent est affichée sur l’hôte pendant qu’elle s’exécute, peut être interrompue instantanément par un interrupteur d’arrêt et est enregistrée dans un journal d’audit local.

§06 · Conception à connaissance nulle

La connaissance nulle n’est pas un terme marketing chez Remio — c’est une contrainte d’architecture. Nos systèmes sont conçus pour que le contenu des sessions soit structurellement inaccessible à Remio, à ses employés ou à tout tiers.

Ce que nos serveurs peuvent voir

• Les adresses IP des appareils qui se connectent (nécessaires au réseau).
• Les horodatages des connexions.
• Les identifiants d’appareil (identifiants opaques, non liés à des informations personnelles).
• Les métadonnées de signalisation : échange d’offre/réponse SDP, candidats ICE.

Ce que nos serveurs ne peuvent pas voir

• Le contenu de l’écran — les images vidéo sont chiffrées de bout en bout avec SRTP.
• L’audio — le même chiffrement SRTP que la vidéo.
• Les événements de saisie — souris, clavier et toucher sont chiffrés avec DTLS.
• La position du curseur — transmise via un canal de données chiffré.
• Le contenu des fichiers — tout transfert de fichiers passe par des canaux chiffrés.
• Les données du presse-papiers — canal de données chiffré.
• L’état des applications — quelles apps vous exécutez, sur quoi vous travaillez.

Politique de conservation des données

En raison de notre architecture P2P, il n’y a en pratique rien à conserver :

• Contenu des sessions. Jamais stocké. Flux en temps réel uniquement.
• Journaux de signalisation. Les métadonnées de connexion sont conservées jusqu’à 30 jours pour le débogage, puis supprimées. Ne contiennent aucun contenu de session.
• Comptes d’utilisateurs. Aucun compte requis. Les données facultatives de Firebase Auth sont gérées par l’infrastructure de Google et peuvent être supprimées par l’utilisateur.
• Informations sur les appareils. Stockées localement sur chaque appareil. Si vous choisissez de vous connecter, votre liste d’appareils se synchronise avec votre compte (voir la politique de confidentialité).

Flux de données P2P d’abord

Dans la majorité des connexions (là où le traversement de NAT réussit), les données circulent directement entre les appareils sans toucher aucun serveur :

# Meilleur cas : P2P direct
Client <—— DTLS-SRTP (chiffré) ——> Hôte
              ↑ Aucun serveur impliqué

# Repli : relais TURN
Client <— DTLS-SRTP —> Serveur TURN <— DTLS-SRTP —> Hôte
                            ↑ Toujours chiffré de bout en bout
                            ↑ Le serveur ne voit que des blobs chiffrés

Même dans le scénario de repli sur relais TURN, le serveur relais ne gère que des paquets chiffrés. Il fait office de simple tuyau — il ne peut ni déchiffrer, ni inspecter, ni modifier les données.

§07 · Sécurité du réseau

Établissement de la connexion P2P

Remio utilise le protocole ICE (Interactive Connectivity Establishment) pour trouver le meilleur chemin de connexion possible entre les appareils :

1. Candidats hôtes — connexion directe sur le réseau local, sur le même réseau.
2. Candidats réflexifs du serveur (STUN) — traversement de NAT via des serveurs STUN pour découvrir l’IP publique.
3. Candidats relais (TURN) — relais chiffré quand une connexion directe ne peut pas être établie.

L’agent ICE teste simultanément toutes les paires de candidats et sélectionne le chemin à la latence la plus faible et le plus fiable. Le P2P direct est toujours préféré.

Politiques de transport configurables

Par défaut, les connexions préfèrent le P2P direct avec repli automatique sur le relais chiffré. Des politiques plus strictes — forcer tout le trafic par le relais, ou ignorer entièrement la découverte sur le réseau local — sont disponibles pour les environnements réseau verrouillés.

Limitation de débit

Le serveur de signalisation applique une limitation de débit agressive pour prévenir les abus :

Les limiteurs de débit expirés sont nettoyés automatiquement toutes les 5 minutes avec une durée de vie de 10 minutes, ce qui empêche l’épuisement de la mémoire lors d’attaques distribuées.

Protection contre le DDoS

Notre infrastructure de signalisation est protégée par Cloudflare, qui fournit :

• Un DNS Anycast avec un réseau périphérique mondial.
• Une atténuation du DDoS des couches 3, 4 et 7.
• Un pare-feu applicatif web (WAF).
• Une limitation de débit en périphérie avant que le trafic n’atteigne l’origine.
• Une détection des robots et des pages de vérification.

§08 · Sécurité du client

Remio s’appuie sur toute la pile de sécurité de chaque système d’exploitation pour protéger les données locales et garantir l’intégrité de l’application.

macOS

• Intégration du Keychain. Toutes les données sensibles (jetons de confiance des appareils, JWT) sont stockées dans le Keychain de macOS, protégé par les identifiants de session de l’utilisateur et le chiffrement matériel.
• App Sandbox. Remio s’exécute dans un environnement en bac à sable avec des autorisations minimales. La capture d’écran et l’accessibilité exigent l’approbation explicite de l’utilisateur.
• Signature du code. Toutes les versions sont signées avec des certificats Apple Developer.
• Notarisation. Les versions macOS sont notarisées par Apple, ce qui confirme qu’elles sont exemptes de logiciels malveillants connus.
• Hardened Runtime. Empêche l’injection de code, le détournement de bibliothèques et le débogage dans les versions de production.

iOS

• App Transport Security (ATS). Toutes les connexions réseau doivent utiliser HTTPS/TLS. Aucune exception configurée.
• Secure Enclave. Là où il est disponible, les clés cryptographiques sont générées et stockées dans le matériel Secure Enclave.
• Keychain Services. Les identifiants des appareils sont stockés dans le Keychain d’iOS avec la classe de protection kSecAttrAccessibleWhenUnlockedThisDeviceOnly.
• Examen de l’App Store. Toutes les versions iOS passent le processus d’examen de sécurité d’Apple.
• Aucune donnée en arrière-plan. L’application ne collecte ni ne transmet de données lorsqu’elle est en arrière-plan.

Signature du code & vérification

# Vérifier le binaire macOS de Remio — verify_signature.sh
$ codesign --verify --deep --strict "Remio Host.app"
# Remio Host.app: valid on disk

$ spctl --assess --verbose "Remio Host.app"
# Remio Host.app: accepted
# source=Notarized Developer ID

§09 · Réponse aux incidents

Historique de sécurité

En date de février 2026, Remio n’a aucun antécédent d’intrusion ni d’incident de sécurité. Notre architecture à connaissance nulle réduit nettement la surface d’attaque — il n’y a aucune base centrale d’identifiants ou de données de session à viser.

Signalement des vulnérabilités

Nous encourageons la divulgation responsable de la part des chercheurs en sécurité. Si vous découvrez une vulnérabilité potentielle :

1. Écrivez à [email protected] avec une description détaillée.
2. Indiquez les étapes de reproduction, le cas échéant.
3. Nous accusons réception sous 48 heures.
4. Nous visons à résoudre les vulnérabilités confirmées sous 30 jours.
5. Les auteurs de signalements sont cités dans notre journal des modifications de sécurité, sauf s’ils préfèrent l’anonymat.

Politique de divulgation responsable

• Nous demandons un délai de divulgation de 90 jours avant toute divulgation publique.
• Nous n’engageons aucune action en justice contre les chercheurs agissant de bonne foi.
• Nous priorisons les correctifs selon la gravité : critique, élevée, moyenne, faible.
• Un programme formel de bug bounty figure sur notre feuille de route.

Processus de réponse aux incidents

En cas de problème de sécurité confirmé :

1. Confinement. Isoler les systèmes touchés sous 1 heure.
2. Évaluation. Déterminer la portée et l’impact sous 24 heures.
3. Communication. Prévenir les utilisateurs concernés sous 72 heures (conformément au RGPD).
4. Remédiation. Déployer des correctifs via l’infrastructure de mise à jour automatique.
5. Bilan. Publier un rapport de transparence.

§10 · Conformité

Préparation au RGPD

L’architecture à connaissance nulle de Remio est intrinsèquement compatible avec le RGPD parce que nous réduisons la collecte de données au strict minimum technique :

• Minimisation des données. Nous ne collectons que ce qui est nécessaire à l’établissement de la connexion.
• Droit à l’effacement. Comme nous ne stockons pas de contenu d’utilisateur, il n’y a rien à supprimer. Les données facultatives de compte peuvent être supprimées sur demande.
• Portabilité des données. Les données de confiance entre appareils sont stockées localement et contrôlées par l’utilisateur.
• Consentement. Le jumelage par code PIN est un mécanisme de consentement explicite pour chaque appareil.
• Aucun transfert transfrontalier de contenu. Les connexions P2P gardent les données entre les appareils ; elles n’entrent jamais dans notre infrastructure.

Feuille de route SOC 2

Jalons de conformité prévus

• Audit de sécurité indépendant — tests d’intrusion et revue de code professionnels, prévus pour 2026.
• SOC 2 Type I — évaluation initiale des contrôles organisationnels.
• SOC 2 Type II — vérification continue de la conformité.
• Programme de bug bounty — récompenses formelles pour la divulgation responsable.

Résidence des données

Comme Remio est P2P d’abord, les données de session résident là où se trouvent vos appareils. Vos données ne quittent jamais la connexion directe entre vos appareils. Le serveur de signalisation (hébergé chez Cloudflare et DigitalOcean) ne traite que des métadonnées de connexion — et ces métadonnées ne sont liées à aucune information personnelle.

§11 · Comparaison avec les alternatives

Le secteur du bureau à distance a été marqué par des intrusions de sécurité très médiatisées. Voici en quoi l’architecture de Remio diffère fondamentalement des alternatives centralisées.

Pourquoi les architectures centralisées échouent

Le problème fondamental des services de bureau à distance centralisés est qu’une seule intrusion peut compromettre tous les utilisateurs. Quand les serveurs de production d’AnyDesk ont été piratés en février 2024, les attaquants ont volé des certificats de signature de code, ce qui pouvait leur permettre de distribuer des logiciels malveillants déguisés en logiciels AnyDesk légitimes. Tous les mots de passe des utilisateurs ont dû être réinitialisés.

Quand APT29 (un groupe soutenu par l’État russe) a pénétré le réseau d’entreprise de TeamViewer en juin 2024, cela a soulevé des questions sur l’intégrité du produit lui-même — car une architecture centralisée signifie que l’éditeur a la capacité technique d’accéder aux sessions.

Remio élimine entièrement cette catégorie d’attaque. Une intrusion sur notre serveur de signalisation ne livre que des métadonnées de connexion. Il n’y a aucun identifiant à voler, aucune session à laquelle accéder, aucun certificat utilisable pour signer des logiciels malveillants visant les appareils de nos utilisateurs.

§12 · Conclusion

La sécurité de Remio n’est pas un ensemble de fonctions greffées sur un produit — c’est la conséquence de décisions d’architecture prises dès le premier jour. En choisissant le P2P plutôt que le centralisé, le jumelage par code PIN plutôt que les mots de passe, et la connaissance nulle plutôt que la collecte de données, nous avons construit un bureau à distance où la sécurité est l’état par défaut, pas une mise à niveau facultative.

Nous pensons que la confidentialité n’est pas facultative, et que la confiance doit se gagner par la transparence, pas s’exiger par des conditions d’utilisation. Ce livre blanc fait partie de cet engagement.

Pour toute question, revue de sécurité en entreprise ou signalement de vulnérabilité :

• Demandes de sécurité : [email protected]
• Ventes aux entreprises : [email protected]
• Général : [email protected]