Chiffrement de fichiers AES

a marqué ce sujet comme résolu.

Bonjour,

Pour un projet perso, je souhaite effectué le chiffrement de fichiers (côté serveur, en AES avec clé symétrique). (J’avais d’abord imaginé un chiffrement côté client, mais ceci complique sensiblement les choses, et m’empêche tout traitement ultérieur côté serveur, et.. ne garanti aucunement l’intégrité des données envoyé par le client). J’ai imaginé 3 solutions.

La première solution, on génère une clé aléatoire pour un utilisateur et on mémorise cette clé en base de données dans les informations de l’utilisateur:

Clé utilisateur
Clé utilisateur

Pour la deuxième solution, c’est identique à la première, mais avec une clé d’application (aussi générer aléatoirement) mais cette dernière serait mémorisé dans le fichier de configuration de l’application (donc sur un autre super, et unique pour tous les utilisateurs):

Clé application + clé utilisateur
Clé application + clé utilisateur

Pour la dernière solution, ce serait la même chose que les deux premières, mais avec en plus une clé unique générer aléatoirement pour chaque fichier, mémorisé en base de données:

Clé application + clé utilisateur + clé fichier
Clé application + clé utilisateur + clé fichier

Ma question est: est-ce qu’un des sytèmes proposé ci-dessus est OK (dans le sens sécurité, pour autant que ce soit implémenter correctement) ? Est-ce qu’il y a mieux ? Est-ce que je suis à coté de la plaque dans ma façon de voir les choses ?

Je vous remercie d’avance ;)

Bonjour, c’est dans un but de transmettre les fichiers de façon sécurisé ? Ou de les stocker ? Ou les deux ?

Une clé AES par fichier me paraît lourd pour pas grand chose… Une par utilisateur suffit. Si tu as l’idée de partitionner les fichiers par serveur de stockage et/ou application, ça peut valoir le coup effectivement de décliner ta clé (éviter les attaques multiservices).

+0 -0

Bonjour, c’est dans un but de transmettre les fichiers de façon sécurisé ? Ou de les stocker ? Ou les deux ?

Yarflam

Stockage uniquement, il s’agit d’un service REST, donc le transfert se fait sous https.

Edit: je précise également, actuellement le stockage se fait en local, mais à terme, il pourra être soit en remote (FTP, S3, ..) ou local.

+0 -0

Salut,

Pourquoi cherches tu as faire cela ? La première étape c’est établir un modèle de l’attaquant : contre quoi veux tu te défendre ? vol de disque dur, écoute sur le réseau etc) En fonction de ça tu peux analyser ta solution technique :)

Effectivement, c’est une bonne question.

En résumé, j’offre une API qui permet d’enregistrer des fichiers. J’aimerais sécurisé au mieux ces fichiers afin qu’un attaquant ne puisse pas en récupérer le contenu.

Concernant les modèles d’attaque, je vois ceci:

  • l’API déchiffre les données et les renvoies (à l’attaquant) en clair
    • Ce cas de figure est à sécurisé au niveau de l’API, le chiffrement ne va pas aider
  • l’API à une faille et permet de récupérer la liste des fichiers (non déchiffrer)
    • Le chiffrement va sécurisé cette partie la (même si l’API devra être sécurisé en amont pour éviter cela).

Maintenant côté serveur, c’est là que ça se complique pour moi.

Qu’arrive-t-il si l’attaquant parvient à avoir un accès au serveur ? Imaginon que les sécurités de base aient été mise en place pour protégé les élévations mais que l’attaquant y parvient tout de même. Comment faire en sorte qu’il ne puisse pas déchiffrer le contenu des fichiers ?

Si la clé (Application key + User key dans le cas ci-dessus) sont sur le même serveur, l’attaquant pour déchiffrer à sa guise les documents (peut importe que les fichiers soit en local ou non, puisque s’ils sont en remote, les informations de connexion devront bien être enregistré sur le serveur).

J’aimerais pouvoir au mieux gérer ce cas (et peut-être d’autres qui ne me vienne pas à l’esprit ?) J’ai imaginé, un deuxième serveur qui s’occuperait du chiffrement, qui lui contient une des deux clés nécessaire au chiffrement/déchiffrement. Mais comment s’assurer que la demande est légitime et non effectué par l’attaquant ?

J’imagine qu’il existe des patternes et que ces cas ont été étudier par des personnes bien plus au point que moi. Peut-être sauriez-vous m’aiguiller vers des ressources ou des "patterne" pour mettre en place ceci ?


Je suis navré, je sais que ma demande est vaste et confuse, et c’est là, j’imagine, mon principale problème. Car je suis un peu perdu, et j’aimerais faire ceci au mieux.

Je précise, ma question ne porte pas sur comment sécurisé le serveur pour éviter que l’attaquant y aie accès, mais plutôt "si l’attaquant y a accès, que se passe-t-il et comment protéger les documents au mieux ?"


Edit:

J’ai également imaginé une autre solution: imaginons que la clé de chiffrement User Key soit elle même chiffré à l’aide du mot de passe de l’utilisateur. L’API ne mémoriserait que la clé chiffré, et l’envoie au départ à l’utilisateur. Lors de l’envoie ou la réception d’un document, le client fourni cette clé déchiffré (l’opération de chiffrement/déchiffrement se ferait donc en local, par le client). Ceci ferait en sorte que les documents non chiffré/clé de chiffrement non chiffré ne se trouverait sur le serveur que temporairement dans sa mémoire, réduisant ainsi grandement les risques.

+0 -0

Si le serveur tombe et que l’attaquant peut lire la mémoire du serveur alors tu ne peux pas protéger complètement les fichiers.

Tu as donc besoin d’utiliser des infos externes. Tu peux effectivement utiliser le mot de passe utilisateur pour chiffrer une clé de chiffrement (C’est ce qui est fait sur Android par exemple).

Ainsi le seul risque est losqu’un utilisateur se connecte. Tu peux encore améliorer ça mais c’est déjà pas mal, si un problème de sécurité se pose, tu désactives la page de connexion (qui idéalement à un DNS séparé afin de pouvoir le désactivé séparement ex: login.ache.one).

+2 -0

Hello,

Je ne comprends pas ce qui t’empêche de chiffrer/déchiffrer en local avec une clef dérivée de ton mot de passe ? Un peu comme ce que tu proposes avec ton UserKey/mot de passe mais pas sur le serveur, comme ça ton serveur ne voit jamais la partie de la clef qu’il ne connait pas ? (J’espère que je ne dis pas de conneries je suis un peu fatigué :D )

Le problème, c’est si la clé est dérivée du mot de passe, tu fais comment si l’utilisateur change de mot de passe ?

Tu lui retransmet tous les fichiers et tu le laisses déchiffrer puis rechiffrer ? C’est inconcevable. C’est pour ça qu’on chiffre juste une la clé de chiffrement.

Mais effectivement, on peut transmettre la clé de chiffrement chiffrée à l’utilisateur. Et en local, déchiffrer la clé de chiffrement puis déchiffrer le fichier au téléchargement.

Après, ça nécessite de garder le mot de passe en session… :( Ou le redemander à chaque fois qu’il veut télécharger un fichier.

+0 -0

Mais effectivement, on peut transmettre la clé de chiffrement chiffrée à l’utilisateur. Et en local, déchiffrer la clé de chiffrement puis déchiffrer le fichier au téléchargement.

J’ai pas tout suivi, mais oui, généralement c’est assez commun.

@WinXaito, ton projet est "assez classique". Je veux dire par là que des projets similaires existent. Et des applications qui stockent des données/fichiers utilisateurs chiffrés sur un serveur il y en a. Tu peux regarder comment ils fonctionnent. La, en exemple rapide qui me vient c’est les password managers. Et ca tombe bien, en général les projets ont souvent de la doc plus ou moins bien.

En projet un peu similaire en tete y a Dashlane qui me vient. Ils ont un papier qui peut t’intéresser: https://www.dashlane.com/download/Dashlane_SecurityWhitePaper_March2021.pdf

Je te recommande d’en explorer quelques autres. Ca clarifiera peut-

@ache : malin ! C’est donc bien ce que WinXaito propose mais en local plutôt que sur le serveur il me semble :)

Par contre tu ne garderais pas le mot de passe en session mais "juste" la clef dérivée non ? Les pkdf sont conçues pour rendre difficile les attaque par force brute/dictionnaire.

Par contre tu ne garderais pas le mot de passe en session mais "juste" la clef dérivée non ? Les pkdf sont conçues pour rendre difficile les attaque par force brute/dictionnaire.

Fantasio

Effectivement ! Je sais pas pourquoi j’ai dis ça. J’avais peut-être en tête 1 clé par fichier ? 🤔
Mais c’est bien plus simple comme tu dis.

+0 -0

Je vous remercie pour tout vos messages très intéressants.

Après, effectivement, le serveur ne peut plus du tout avoir accès aux fichiers, donc cela empêche tout traitement ultérieur sur les fichiers, mais d’un autre côté, si le serveur peut avoir accès au fichier, alors l’attaquant aussi. J’imagine qu’on se trouve dans le cas du "On ne peut pas avoir le beurre et l’argent du beurre…".

Je vais donc regarder tout ceci plus en détail, merci !

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte