Tout savoir sur Seald et sa technologie de chiffrement bout en bout

Qu’est-ce que Seald-SDK

Le Seald-SDK est pensé comme un « moteur » de chiffrement de données dans des applications Web, mobile ou bureau.

Le Seald-SDK est pensé comme un « moteur » de chiffrement de données dans des applications Web, mobile ou bureau.

« Les développeurs vont placer une porte Seald-SDK en en-tête de leur application et pouvoir programmatiquement décider de chiffrer une ligne de messagerie avec une clé de leur choix, par exemple. Nous guidons toute la gestion de la clé privée dans un espace de stockage secret dans une application mobile, la gestion multiappareil, la restauration, etc. Bref, toutes les problématiques qui deviennent un calvaire pour les développeurs et conduisent souvent à l’abandon des projets de chiffrement bout en bout, nous allons les abstraire et fournir une solution – sans mauvais jeu de mots – clés en main », vante le directeur général.

Sur son site Web, la startup affirme faire gagner de long mois de développement avec sa solution qui s’intègre en moyenne en trois heures, après l’écriture de 150 lignes de code.

Comme beaucoup de systèmes de chiffrement bout en bout, les produits de la startup s’appuient sur une interaction serveur client. Le Seald-SDK représente la partie client « qui considère que le reste du monde est malveillant, y compris nos propres serveurs », explique Timothée Rebours. Selon ce principe, ces solutions sont configurées par défaut de telle sorte que les serveurs n’aient pas accès aux clés de chiffrement.

Côté serveur justement, le système de la startup dépend d’une instance dédiée hébergée sur OVH, ou on premise, suivant le choix des clients. « La partie serveur joue le rôle de l’intermédiaire des clés symétriques chiffrées pour les destinataires », indique le responsable.

Dans la description du SDK soumis à audit de l’ANSSI et à un prestataire agréé (Synacktiv, également sollicité par Olvid), la version 2.1 du SDK est présentée comme une bibliothèque NodeJS. Elle interagit avec le serveur Beard, qui expose une API Rest chargée de la centralisation et la maintenance de l’annuaire des utilisateurs, des chaînes de signatures, en plus « des clés symétriques des messages chiffrés par les clés publiques des destinataires ».

Le serveur Dashboard héberge une application Web dédiée aux administrateurs pour gérer les rôles utilisateurs, les révoquer tout comme les clés et les fichiers et obtenir des pistes d’audit relatives aux événements.

Seald mise sur le chiffrement côté client

Le SDK a pour charge de créer et de récupérer des identités Seald pour les utilisateurs, d’établir des sessions de chiffrement, ou encore d’ajouter et supprimer des destinataires.

Mais c’est bien côté client que les traitements essentiels ont lieu, à l’instar de la messagerie Whatsapp ou encore Keybase (racheté par Zoom). Voilà ce qui explique, entre autres, la décision de certifier seulement le Seald-SDK. La bibliothèque est considérée telle une brique de génération bi-clés de signature et de chiffrement, dotée de capacité de renouvellement des clés ainsi que du chiffrement et de déchiffrement de fichiers et d’e-mails. Le SDK a pour charge de créer et de récupérer des identités Seald pour les utilisateurs, d’établir des sessions de chiffrement, ou encore d’ajouter et supprimer des destinataires. Il maintient également une base de données locale contenant les chaînes de signatures.

Avec Seald-SDK, une clé privée peut être protégée de trois manières. « Il est possible de la placer dans un espace de stockage sécurisé, par exemple une enclave sécurisée d’un smartphone. Il est éventuellement permis de protéger cela par une clé symétrique chiffrée par un secret connu du serveur », liste Timothée Rebours.

La deuxième méthode consiste à recourir à un mot de passe. « Nous effectuons un double hash côté client, le premier hash sert de clé symétrique chiffrant les clés privées que l’on stocke dans une base de données clés-valeurs sur un service soit chez Seald, soit chez nos clients. Le second hash correspond à une autre dérivation de clé qui sera utilisée comme mot de passe auprès du serveur ».

La troisième possibilité n’est pas considérée comme de bout en bout, mais se révèle pertinente dans certains cas : le Two-man Rule (principe des quatre yeux en français). « Schématiquement, nous “coupons” la clé privée en deux : une partie se trouve sur le serveur, remis contre authentification du service. La seconde partie est remise au client contre une authentification indépendante et le client réunit les deux éléments », décrit le CEO.

Cette troisième technique qui déroge à la promesse de base de Seald serait nécessaire en cas de perte de tous les appareils ou d’oubli de mot de passe afin de pouvoir récupérer les clés. Dans la documentation de la startup, il s’agit du mode de chiffrement authentifié.

« Dans certains cas, par exemple en authentification fédérée, nous n’avons pas le choix : la méthode de pré-hashage de mot de passe n’est pas applicable parce que le serveur dédié est utilisé pour l’authentification d’autres services et qu’il a besoin du mot de passe en clair, tout du moins au runtime », assure Timothée Rebours. Toutefois, avec le Two-man rule « ni Seald ni l’entreprise n’ont accès aux données, il n’y a que le client (Seald-SDK) qui peut le faire. Dans ce mode-là, il n’y a pas de lien API entre le serveur et le client, il faudrait compromettre individuellement deux environnements pour atteindre la clé privée ».

Algorithmes de chiffrement et protocole de transmission

Seald a configuré la taille des clés asymétriques RSA OAEP sur 4 096 bits pour le cryptage des messages. Avec le mode de chiffrement bout en bout, lorsque l’émetteur et le destinataire utilisent une application qui recourt au Seald-SDK, les documents et les mails sont sécurisés par l’algorithme AES 256 CBC, vérifié par le biais de l’algorithme HMAC SHA256.

Pour l’instant, la jeune pousse ne prétend pas à la mention « cryptographie post-quantique », c’est-à-dire qu’elle ne dispose pas des capacités techniques pour résister à une attaque réalisée à l’aide d’un calculateur quantique. « Nous pouvons changer les primitives de cryptographie pour passer à du post-quantique. Nous en avons discuté avec Guillaume Poupard (Directeur général de l’ANSSI) qui juge, de par notre architecture, que nous sommes “post-quantum ready” (sic). […] Nous n’allons pas nous jouer les apprentis sorciers en choisissant des primitives asymétriques nous-même, nous attendons les directives et les conventions européennes en la matière », tempère Timothée Rebours.

« Nous utilisons notre propre format propriétaire. »

En revanche, Seald a décidé de se passer de la norme x509, utilisée pour certifier les clés publiques. Ce standard encadre notamment les certificats SSL/TLS. « Nous utilisons notre propre format propriétaire parce que nous trouvons que x509 comporte beaucoup de choses inutiles pour nous en matière de structuration des certificats et de chaînes de certificats », précise le CEO de Seald.
C’est là qu’intervient la chaîne de signature dont le rôle est d’assigner des blocs JSON afin de gérer la fonctionnalité multiappareil. « Un appareil va signer les appareils successifs et les différentes opérations de renouvellement de révocation et de création de nouveaux appareils. Si l’on a confiance en la clé publique d’un appareil, on aura confiance en la clé publique de tous ses descendants ».

Concernant la couche de transport, la startup emploie tout de même TLS 1.2. « Ce serait très bizarre de ne pas utiliser le TLS, mais en soi, la cible de sécurité n’a pas besoin de ce protocole pour répondre à une quelconque hypothèse », assure Timothée Rebours. Dit plus simplement, au vu de l’architecture mise en place, le CEO considère que l’interaction entre le client et le serveur « pourrait être en clair que ça ne poserait pas de problème ».

À qui s’adresse Seald ?

« Nous ne faisons pas de la cryptographie homomorphe. »

Maintenant que nous avons déroulé les mécanismes d’un tel service, une question subsiste : il y a-t-il des données plus susceptibles de profiter de ce chiffrement bi-clés ? Selon notre interlocuteur, bien qu’elle prenne en charge la plupart des formats, les méthodes utilisées ne permettent pas de réaliser de la recherche full texte et encore moins des traitements algorithmiques de données côté serveur.
« Nous ne faisons pas de la cryptographie homomorphe [technique qui doit permettre de traiter et analyser des données sans avoir à les déchiffrer au préalable, N.D.L.R.]. Certains clients ne comprennent pas, au premier abord, qu’ajouter une couche de chiffrement de bout en bout va les contraindre en matière de fonctionnalités », déclare Timothée Rebours.

Avec sa solution d’entreprise, la startup peut s’adresser à toute organisation qui souhaite protéger ses documents et ses mails. L’un des clients historiques de Seald n’est autre que le constructeur automobile PSA qui depuis deux ans emploie cette technologie pour chiffrer des données médicales d’assurance.

« À l’époque, nous avions proposé cela comme une prestation en développant un outil sur-mesure pour leur besoin », relate le directeur général. « Au fur et à mesure, des mutuelles, des courtiers en assurance, des entreprises nous demandaient de petites adaptations », ajoute-t-il.
Là, la startup a préféré bâtir un produit plutôt que devenir une ESN spécialisée dans le chiffrement. Si ces acteurs peuvent plus facilement se tourner vers l’offre entreprise de Seald, ce n’est pas le cas de certains éditeurs qui souhaitent déployer ce mode de chiffrement E2EE dans leur produit, d’où la disponibilité du Seald-SDK. Ceux-ci veulent protéger des données à caractère privées, « en particulier des informations médicales ».

« C’est là où nous voyons le plus d’appétence, car briser le secret médical est un délit pénal, et qu’il est impossible de payer une assurance pour s’en protéger comme les sanctions administratives, comme celles encourues pour non respect du RGPD. Deuxième point, c’est une question d’image : la fuite d’une adresse mail, d’un mot de passe c’est embêtant. Une fuite d’un dossier médical c’est vital pour une entreprise de ce secteur », relate Timothée Rebours.

La jeune pousse aperçoit également des opportunités dans la protection de la propriété intellectuelle, mais ce sujet n’est pas encore la priorité des organisations. « La réalité des menaces fait que ce sera un marché d’ici quelques années », prévient le CEO. « L’on observe des attaques visant des sous-traitants pour atteindre une cible de plus grande envergure, par exemple ».

Pour Seald, la certification CSPN n’a pour intérêt réglementaire que de lui offrir l’accès au marché des OIV, ce qui ne l’affecte pas plus que ça. « Là où ça a de l’importance, c’est que nous prétendons mieux faire ce qui est proposé depuis des années [par certains acteurs], que nous sommes une entreprise où la moyenne d’âge est en dessous des trente ans et que nos prospects et clients nous demandent des preuves quant à la robustesse de nos solutions. Le tampon de l’ANSSI est vraiment reconnu à la fois par des DPO, des RSSI, des CTO ou des ingénieurs spécialisés en cybersécurité. De plus, il n’y a que 30 % des candidats à la CSPN qui l’obtiennent ».

« La technologie est prête : nous allons capitaliser sur la certification CSPN, consolider nos métriques et préparer notre arrivée sur le marché européen. »

Une ambition européenne

En 2018, la startup avait reçu un soutien financier de BPIfrance avec un fonds d’amorcage de 800 000 euros. « Nous envisageons une levée de fonds en série A en fin d’année ou au début de l’année prochaine pour faciliter notre croissance. Actuellement, nous avons assez de liquidité pour tenir 18 mois, donc il n’y a pas un besoin immédiat. La technologie est prête : nous allons capitaliser sur la certification CSPN, consolider nos métriques et préparer notre arrivée sur le marché européen ». Sans réelle surprise, le chiffrement bout en bout intéresse principalement les entreprises européennes, et en entre en résonnance avec les questions de souveraineté, selon le dirigeant de Seald.