Modèle de sécurité

Seald est un logiciel permettant de chiffrer simplement des messages et documents, envers des destinataires ayant également l'application, mais aussi d'autres ne l'ayant pas.

Seald fonctionne de manière légèrement différente dans ces deux cas. Vous pouvez en apprendre plus ici.

Pré-requis de sécurité

Afin de construire la sécurité de Seald, plusieurs pré-requis de sécurité sont supposés acquis, et Seald ne prétend pas protéger ces utilisateurs de tels scénarios, bien que nous proposions des mécanismes de détection et de remédiation a posteriori.

Si un poste utilisateur était compromis par un logiciel malveillant, celui-ci pourrait accéder aux données de l'ordinateur comme l'utilisateur lui-même. Un appareil relié à un compte Seald ayant eu un tel logiciel malveillant doit être considéré comme malveillant et révoqué.

Si une session utilisateur était compromise par un accès physique illicite, la personne ayant eu accès au poste pourrait accéder aux données de l'ordinateur comme l'utilisateur lui-même. De la même façon un appareil relié à un compte Seald ayant été compromis par un accès physique illicite doit être considéré comme malveillant et révoqué.

Nous recommandons de prendre les précautions nécessaires pour assurer la sécurité du poste utilisateur. De façon non exhaustive, quelques recommandations sont d'ajouter un mot de passe de session, de mettre en place du chiffrement de disque dur, de faire les mises à jour de l'OS et des applications régulièrement, etc.

Attaques envisagées

Le service Seald pourrait aussi être la cible d'attaques, et nous faisons le maximum pour en protéger nos services et nos utilisateurs des catégories attaques suivantes:

  1. Compromission du serveur applicatif — envoi de données fausses aux utilisateurs
  2. Compromission du serveur de base de données — vol d'informations
  3. Compromission du serveur de mises à jour — envoi de code de mise à jour malveillant

Attaque 1: Compromission du serveur applicatif — envoi de données fausses aux utilisateurs

Si un attaquant compromet le serveur applicatif, il peut écouter les requêtes émises par les logiciels client et y répondre avec des données fausses pour tenter d'obtenir l'accès à des messages.

Le pire des cas serait que l'attaquant arrive à récupérer la clé d'un message. Pour se faire, on peut imaginer, dans une communication depuis Alice vers Bob, que l'attaquant fasse croire à Alice que Bob à rajouté un nouvel appareil, qui serait en fait la clé publique de l'attaquant. Lorsqu'Alice enverrait un message à Bob, elle chiffrerait donc la clé de message grâce aux clés publiques de Bob, et donc aussi pour la clé de l'attaquant.

Pour s'en protéger, Seald implémente un protocole de chaine de signatures, dans lequel tout nouvel appareil d'un utilisateur doit être validé par l'un de ses appareils existants grâce à une signature numérique. L'attaquant ne pourrait donc pas faire passer sa clé publique comme un nouvel appareil de Bob.

Par contre, lorsqu'Alice n'a encore jamais communiqué avec Bob, elle n'a d'autre choix que de faire confiance au serveur de Seald pour récupérer ses clés publiques (confiance au premier usage).

Aussi, lorsque Bob n'a pas de compte Seald, la méthode de chiffrement est différente. La clé du message est alors envoyée en clair au serveur, et l'attaquant pourrait y accéder.

Notons néanmoins que cela ne suffit jamais à accéder aux données déchiffrées, le serveur Seald n'y ayant jamais accès. Il faudrait donc, en plus de contourner nos sécurités pour récupérer la clé de message en clair, réussir à pirater le service d'échange de données utilisé pour accéder aux données chiffrés, et alors pouvoir les déchiffrer.

Attaque 2: Compromission du serveur de base de données — vol d'informations

Les données sensibles dans notre base de données sont chiffrées.

Un scénario d'attaque observé dans de telles infrastructures est un accès illicite en lecture à la base de donnée elle-même ou à une sauvegarde de celle-ci.

Un attaquant réussissant une telle attaque pourrait accéder à certaines métadonnées associées à un échange comme le nom de document, la date de différents évènements liés au document et la liste des destinataires, mais pas à une quelconque convention de déchiffrement, c'est-à-dire les clés symétriques mises en séquestre dans le cadre du chiffrement pour quelqu'un n'ayant pas Seald.

Attaque 3: Compromission du serveur de mises à jour — envoi de code de mise à jour malveillant

Étudions comment nous nous protégeons d'un attaquant qui parviendrait à compromettre le serveur de mise à jour hébergeant les exécutables de mise à jour. Cela peut arriver, par exemple, en usurpant le compte d'un administrateur, ou bien en exploitant une éventuelle faille de sécurité présente sur serveur permettant la modification d'un exécutable ou l'ajout d'un nouvel exécutable, ou alors une attaque active en Man-in-the-Middle pendant le téléchargement.

Tout d'abord la communication avec le serveur de mise à jour est sécurisée avec TLS empêchant une attaque de type Man-in-the-Middle.

Pour se prémunir du second scénario, ou d'un échec de TLS, nous signons tous nos exécutables sur macOS et Windows. Ils sont signés par un certificat non administré par le serveur de mise à jour. Cela assure ainsi que le serveur de mise à jour seul ne peut permettre la compromission d'une mise à jour. De plus, tout ajout d'une nouvelle version, même avant publication, sur le serveur de mise à jour notifie l'équipe de sécurité d'astreinte et nécessite une action manuelle de la part d'une personne habilitée pour la publier.