Adapter son application

L'objectif de faire du chiffrement côté client (ou “de bout-en-bout”) dans une application est d'interdire au serveur applicatif la lecture des données chiffrées.

Dans certains cas, cela n'est pas souhaitable, parce qu'une fonctionnalité ne peut fonctionner que si le serveur peut lire la donnée, rendant ainsi les données exploitées pour fournir cette fonctionnalité inéligibles au chiffrement côté client tel quel.

Selon les cas, plusieurs stratégies peuvent être mises en place pour malgré tout rendre ces données éligibles à du chiffrement côté client.

Si vous souhaitez que nos équipes vous aiguillent sur la stratégie à adopter, n'hésitez pas à contacter nos équipes directement.

Rapatrier la fonctionnalité côté client

Certaines fonctionnalités traditionnellement implémentées côté serveur peuvent désormais dans certains cas être rapatriées côté client, notamment grâce à l'amélioration des navigateurs et des performances des appareils.

Dès lors, il n'est plus nécessaire de donner accès au serveur aux données pour fournir la fonctionnalité, rendant ces données éligibles à du chiffrement côté client.

Exemple : Génération de fichier

Un exemple concret peut être la génération de fichiers usuellement effectuée côté serveur.

Un fichier pdf est souvent généré en utilisant un template dans lequel est injecté du contenu (texte, images, etc.).

Pour effectuer cette opération, il est fréquent d'utiliser FPDF en Python par exemple.

L'alternative est de déporter cette génération côté client à l'aide d'une bibliothèque pour le navigateur comme pdf-lib qui est par exemple utilisée dans le générateur d'attestation de déplacement dérogatoire utilisé pendant les différents confinements en France :

Dans ce genre de scénario, le fichier pdf n'est pas connu en clair du backend et est donc éligible à du chiffrement de bout-en-bout avec le Seald-SDK.

Exemple : Recherche dans du texte

Un autre scénario est celui de la recherche dans du texte contenu dans des messages, des emails, des fichiers, etc. Dans la quasi-totalité des cas, le frontend envoie la requête en base de donnée ou à un service dédié comme Algolia en SaaS ou ElasticSearch si cela est géré de façon interne.

Ces services ont eu accès au corpus de textes dans lequel il faut rechercher et ont constitué un "index" de recherche qu'ils interrogent lors d'une requête pour répondre les meilleurs résultats très rapidement.

Dans des cas où le corpus est petit (par exemple un historique de messages), l'index peut être généré côté client avec des bibliothèques comme minisearch, utilisé par le navigateur directement sans interaction avec le backend, puis cet index est chiffré puis stocké sur le backend pour une utilisation ultérieure.

La recherche côté client est ce qui est utilisé par les clients lourds de messagerie comme Mozilla Thunderbird, Microsoft Outlook, ou tout simplement Whatsapp ou Signal pour la messagerie instantanée.

Octroi temporaire de droits

Lorsque aucune des deux stratégies ci-dessus n'est applicable parce que la fonctionnalité à développer nécessite absolument de la donnée en clair côté serveur, une stratégie possible est d'octroyer temporairement des droits de déchiffrement à ce serveur.

Cela semble contre-intuitif, étant donné que la cible de sécurité envisagée est de se prémunir d'une malveillance du serveur. En pratique néanmoins, une compromission d'un serveur est limitée dans le temps, de sorte que seules les données accessibles par le serveur pendant la durée de l'attaque sont compromises.

Cela présuppose de détecter la compromission rapidement avec des mesures de surveillance performantes.

Exemple : Archivage chiffré de bout-en-bout

Parfois, des données sont analysées une seule fois par un serveur (backend) pour en tirer un résultat (exécuter une OCR, un modèle de machine learning, etc.), puis la donnée est stockée pour une plus longue durée et seules des personnes physiques seront amenées à les consulter depuis un frontend. Ce résultat peut être lui-même sensible, ou non.

Une alternative consiste à chiffrer les données immédiatement après analyse, en n'autorisant que les personnes physiques habilitées à les déchiffrer et que le serveur (backend) ne conserve pas de copie de la clé de chiffrement.

Le serveur dispose au tout début du processus des données en clair, mais plus jamais après (ni de la capacité de les obtenir). Si le serveur subissait une fuite de données, seules les données en cours d'analyse lors de la fuite seraient compromises, mais pas les données déjà chiffrées.

Ce genre de mécanisme peut être implémenté en intégrant le Seald-SDK:

• dans le backend qui aurait une "identité de service" qui ne servirait qu'à chiffrer pour les utilisateurs du frontend, ou bien en utilisant le SDK anonyme ;
• dans le frontend qui permettrait à chaque utilisateur de gérer sa propre identité et de déchiffrer les données côté client uniquement.

Exemple : Octroi a posteriori de droits pour une durée limitée

Le mécanisme précédent n'est applicable que lorsque l'utilisation des données par le serveur est en début du cycle de vie de la donnée.

Lorsque le serveur a besoin d'utiliser les données plus tard dans le cycle de vie de la donnée, il faut un mécanisme pour que le frontend attribue des droits au backend pour le temps de son analyse.

Ce genre de mécanisme peut être implémenté en intégrant le Seald-SDK :

• dans le backend qui aurait une "identité de service" qui serait destinataire des droits attribués par les utilisateurs du frontend ;
• dans le frontend qui permettrait à chaque utilisateur de gérer sa propre identité, déchiffrer les données côté client, d'octroyer et de révoquer des droits sur leurs données au backend.

TIP

Pour éviter d'alourdir davantage le schéma, le chiffrement initial des données n'est pas indiqué. Il peut être effectué soit par le frontend, soit par le backend si on utilise le paradigme du paragraphe précédent.

Pseudonymiser

Lorsque des données sont exploitées côté serveur (pour faire une analyse automatisée quelconque, un algorithme de ML, une requête SQL, une recherche, etc.), il est fréquent que seule une partie des données collectées soit exploitée.

Il est possible d'appliquer des mesures de sécurité plus strictes aux données non exploitées côté serveur qu'aux données exploitées côté serveur. Une stratégie notamment recommandée par le RGPD à l'article 32 est de recourir à la "pseudonymisation".

Cela consiste à diviser en deux le jeu de données :

• les données "non identifiantes" exploitées côté serveur ;
• les données "identifiantes" qui ne sont pas exploitées côté serveur mais qui doivent être conservées pour une utilisation ultérieure.

Lors de la division, un identifiant unique aléatoire, appelé "pseudonyme", est généré pour chaque entrée du jeu de données et ce "pseudonyme" est le même pour une même entrée dans les données "identifiantes" et "non identifiantes", de sorte que l'opération de division soit réversible.

Usuellement, l'opération de pseudonymisation est effectuée de la façon suivante :

• d'abord, le backend dispose des données complètes et procède à la pseudonymisation ;
• puis, le backend stocke les données dans deux bases de données distinctes, avec des mesures de sécurité périmétriques (contrôle d'accès, authentification, etc.) différentes de sorte que les données identifiantes ne soient lisibles que par les personnes habilitées à reconstituer les données complètes ;
• enfin, lorsqu'une personne habilitée souhaite reconstituer les données complètes, il lui suffit de récupérer l'entrée correspondante à un pseudonyme dans les deux bases de données.

Une séparation simple comme celle-ci pose plusieurs problèmes :

• l'opération de pseudonymisation étant effectuée côté serveur, celui-ci a eu accès aux données et pourrait en avoir gardé une copie (y compris involontairement) ;
• si les deux bases de données sont sur le même serveur avec des mesures d'authentification disjointe : un administrateur système malveillant ou une compromission du serveur compromettrait les données complètes.

Une alternative est de procéder à un chiffrement côté client des données identifiantes pour les seules personnes habilitées et de placer les données identifiantes chiffrées et les données non identifiantes au backend.

Dans un tel mécanisme, les données identifiantes et non identifiantes sont correctement cloisonnées :

• les données non identifiantes sont lisibles et exploitables par le backend pour fournir les fonctionnalités voulues ;
• les données identifiantes ne sont lisibles que par les personnes habilitées après un déchiffrement côté client dans le frontend et le backend n'a accès qu'à une version chiffrée pour laquelle il ne dispose pas de la clé.

Une façon d'effectuer un tel chiffrement est d'utiliser le Seald-SDK.