Sécurité : ce que nous protégeons, et ce que nous ne protégeons pas

Le principe de base

LiveSSH se connecte en SSH depuis votre appareil directement au serveur que vous choisissez. Vos informations de connexion ne passent pas par un serveur LiveSSH.

Si vous activez LiveSSH Cloud (payant), les éléments comme les hôtes, snippets et clés SSH sont chiffrés sur votre appareil avant d'être synchronisés. Les clés de déchiffrement ne peuvent être dérivées que de votre mot de passe principal et de votre clé de récupération. Cette conception s'appelle chiffrement de bout en bout, ou connaissance nulle.

Comment le coffre est chiffré

Les éléments synchronisés sont protégés ainsi :

• Les éléments sont chiffrés sur votre appareil avec XChaCha20-Poly1305 (chiffrement authentifié) à l'aide d'une clé de données générée aléatoirement.
• La clé de données est enveloppée par une clé dérivée de votre mot de passe principal avec Argon2id (64 Mio de mémoire, 3 itérations).
• La même clé de données est aussi enveloppée séparément avec votre clé de récupération, une chaîne base32 de 52 caractères dont une clé est dérivée avec HKDF.
• Les clés de données enveloppées sont stockées dans un keyset (JSON) sur le serveur.
• Changer de mot de passe principal ne ré-enveloppe que le keyset. Vos éléments restent tels quels et la clé de récupération continue de fonctionner.

La clé de récupération

Si vous oubliez votre mot de passe principal, la clé de récupération ouvre le coffre et vous permet d'en définir un nouveau.

Si vous perdez à la fois le mot de passe principal et la clé de récupération, personne ne peut récupérer vos données. Le serveur ne détient pas les clés nécessaires au déchiffrement, nous non plus donc. Il vous revient de conserver la clé de récupération en lieu sûr.

Ce que stocke le serveur

Le serveur LiveSSH Cloud est une instance Supabase auto-hébergée. Voici ce qu'il contient :

La base de données sépare les comptes par un contrôle d'accès au niveau des lignes, et le trafic vers le serveur est protégé par TLS. Les durées de conservation et les sous-traitants figurent dans la politique de confidentialité.

Épinglage de la clé d'hôte (TOFU)

À la première connexion à un serveur, l'application affiche l'empreinte de sa clé d'hôte (SHA-256) et, après votre confirmation, l'enregistre avec cet hôte (Trust On First Use).

Si l'empreinte diffère par la suite, l'application refuse de se connecter et vous avertit. Le serveur a peut-être été remplacé, ou quelqu'un intercepte la connexion. Vous pouvez réinitialiser l'empreinte enregistrée depuis l'écran de modification de l'hôte.

C'est à vous de juger si l'empreinte de la toute première connexion est authentique ; TOFU ne protège pas contre une attaque pendant cette première connexion.

Ce que contient une notification push

Les notifications push suivent un chemin distinct du coffre chiffré. Un hook de notification sur votre serveur envoie la notification au serveur LiveSSH, qui la transmet à votre appareil via Google Firebase Cloud Messaging (sur iOS, via l'Apple Push Notification service).

Une notification contient un titre, un corps (par exemple le texte de demande de confirmation produit par l'agent, jusqu'à 300 caractères), le nom de la session tmux et l'étiquette de l'hôte. Sur ce chemin, elle n'est pas chiffrée de bout en bout et transite donc par le serveur LiveSSH et par Google ou Apple. Le serveur est conçu pour ne pas écrire le corps des notifications dans ses journaux. Si les demandes de confirmation de votre agent peuvent contenir des informations sensibles, n'activez pas les notifications.

Rapports de plantage

Les rapports de plantage ne sont envoyés à Firebase Crashlytics que si vous y consentez au premier lancement, et vous pouvez les désactiver à tout moment dans Réglages → Sécurité. Les désactiver supprime les rapports non encore envoyés.

Un rapport contient la cause du plantage (trace de pile), la version du système et de l'application, et le modèle de l'appareil. Les messages d'erreur sont réduits à leur première ligne, et les adresses IP, e-mails, chemins et noms d'hôtes sont masqués avant l'envoi. Les adresses d'hôtes, noms d'utilisateur, commandes, sorties de terminal, noms de fichiers et clés n'en font jamais partie. L'application n'utilise aucun SDK publicitaire ni SDK d'analyse d'usage.

Ce que cette conception ne protège pas

• Un appareil infecté par un logiciel malveillant, ou déverrouillé, ne peut pas être protégé par l'application. Tant que le coffre est ouvert, l'application manipule des données déchiffrées, et si vous activez le déverrouillage biométrique, le mot de passe principal est conservé dans le stockage sécurisé de l'appareil.
• Un mot de passe principal faible est vulnérable aux attaques par force brute. Argon2id ralentit chaque essai ; il n'empêche pas de deviner.
• Le serveur LiveSSH voit des métadonnées comme les types d'éléments, les identifiants, les horodatages et le nombre d'éléments.
• La sécurité côté serveur SSH (gestion des clés, serveur compromis, conservation du jeton de hook de notification) relève de vous et de l'administrateur de votre serveur.
• Le code source de l'application n'est pas public et n'a pas été audité par un tiers. Les explications de cette page sont rédigées par le développeur et n'ont pas été vérifiées de manière indépendante.

Signaler un problème de sécurité

Si vous trouvez une vulnérabilité ou un comportement qui diffère de cette description, écrivez à contact@xiu.kr.