Imaginez que je souhaite télécharger mes informations personnelles sensibles (photos, numérisation de documents, liste de mots de passe, sauvegardes par e-mail, informations de carte de crédit, etc.) sur Google Drive (ou tout autre service cloud).
Je veux m'assurer que tout ce tas de données est aussi sûr que possible (contre les pirates qui pourraient en quelque sorte mettre la main sur ces données, et contre Google et ses employés, et aussi à l'avenir, c'est-à-dire si je supprime ces données de Google, je veux être sûr qu'ils ne pourront pas "l'ouvrir" même s'ils gardent sa sauvegarde pour toujours).
Donc, dans ce cas, au lieu de télécharger toutes ces données immédiatement dans le cloud, je créerai plutôt un dossier contenant toutes les données que je veux télécharger, puis je compresserai tout ce dossier à l'aide de 7-Zip et bien sûr, le protégerez par mot de passe. en utilisant 7-Zip.
Je ne le ferai pas une fois, mais quelques fois, c'est-à-dire une fois que l'archive protégée par mot de passe 7-Zip sera prête, je la compresserai à nouveau à l'aide de 7-Zip et utiliserai un mot de passe complètement différent. Je vais le faire cinq fois. Donc, à la fin, mes données sont compressées cinq fois et elles ont été protégées par mot de passe à l'aide de 7-Zip par cinq mots de passe totalement différents. Donc, pour accéder à mes données, je dois les extraire cinq fois et fournir cinq mots de passe différents.
Ce que je ferai ensuite, c'est que je prendrai cette archive cinq fois protégée par mot de passe, et je la compresserai à nouveau en utilisant 7-Zip et encore un sixième mot de passe différent, mais en plus de cela cette fois, je choisirai également pour diviser l'archive en morceaux plus petits.
Disons qu'à la fin, je me retrouve avec 10 archives divisées, où chacune d'entre elles est une archive de 200 Mo, sauf que la 10e n'est qu'une archive de 5 Mo.
L'hypothèse est que tous ces six mots de passe sont au moins des mots de passe de 32 caractères et qu'ils sont complètement indépendants et qu'ils contiennent tous des minuscules/majuscules, des chiffres et des symboles.
Maintenant, je prends ces neuf archives de 200 Mo et les mets dans un conteneur et je crypte le conteneur en utilisant VeraCrypt (en supposant le cryptage en cascade à trois niveaux), puis je télécharge ce conteneur sur mon Google Drive.
Je garde la 10e archive (celle de 5 Mo) sur un service complètement différent (disons sur Dropbox - et ce compte Dropbox n'est en aucun cas connecté/lié à mon compte Google) (également crypté par VeraCrypt).
- Ai-je créé un théâtre de sécurité ? Ou ai-je vraiment empêché quiconque d'accéder à mes données et de les extraire? Après tout, ils doivent passer un niveau de cryptage par VeraCrypt et même après cela, les archives sont protégées par un mot de passe six fois et l'une des archives (la dixième) est stockée ailleurs!
- Si quelqu'un a accès à mon Google Drive et télécharge toutes ces neuf archives, est-il possible d'extraire l'archive sans avoir la dernière (la dixième) archive de 5 Mo? Est-il possible d'accéder aux données de quelque manière que ce soit avec l'une des archives fractionnées manquante?
- Même si quelqu'un met la main sur ces 10 archives et parvient à contourner le cryptage VeraCrypt de quelque manière que ce soit, sera-t-il toujours possible de casser les six mots de passe restants?
Tout d'abord, ce schéma de multi-cryptage est ridicule.
L'algorithme utilisé par 7-Zip est AES-256 qui est considéré comme sécurisé. Mais si quelqu'un y trouve une faille qui le rendrait cassable, il serait probablement en mesure de casser toutes vos couches de chiffrement avec un effort égal.
Donc, soit vous faites confiance à l'algorithme de chiffrement utilisé par 7-Zip, alors une application serait suffisante. Ou vous ne lui faites pas confiance, alors vous feriez une autre passe de cryptage avec un algorithme différent. La superposition du même algorithme plusieurs fois n'a souvent pas autant d'effet qu'on pourrait le penser, comme l'attaque de rencontre au milieu sur Triple-DES l'a démontré.
Concernant le fractionnement d'un fichier crypté: Il est souvent possible de récupérer certaines données d'une archive 7-Zip si des parties de l'archive sont manquantes. 7-Zip utilise AES en mode CBC pour émuler le comportement de chiffrement de flux (chaque bloc de 128 bits est combiné avec le bloc de 128 bits précédent). Cela signifie que si quelqu'un manque une partie du message, il ne peut décrypter rien de ce qui suit (à moins d'avoir un texte en clair connu quelque part), mais tout ce qui précède. Cela signifie que si vous voulez empêcher un attaquant de décrypter l'archive en en retenant une partie, vous devez retenir le premier morceau, pas le dernier .
C'est une ingénierie à une échelle que je n'ai jamais vue. C'est une MAUVAISE CHOSE ™ car elle augmente la complexité de votre solution sans ajouter aucun avantage de sécurité.
Le mécanisme de cryptage est sûr ou non. Vous ne serez plus protégé en chiffrant plusieurs fois. Si le cryptage est sécurisé, il est inutile d'ajouter des couches de cryptage supplémentaires. S'il y a une faille dans votre modèle de sécurité, par exemple, vos clés de cryptage pourraient fuir, plusieurs couches de cryptage ne corrigeront pas cette faille.
Il en va de même pour le fractionnement de l'archive: cela ne sert à rien. Il n'améliore ni ne diminue la protection de vos documents.
Vous devriez regarder la situation dans son ensemble: où enregistrez-vous votre phrase secrète? Qui peut y accéder? Quelle est votre solution de sauvegarde si vous ne pouvez pas accéder ou vous souvenir de votre phrase secrète? Votre ordinateur est-il protégé contre les logiciels malveillants (qui rendraient tout cryptage inutile)? Votre solution est-elle si complexe que vous ne l'utiliserez jamais?
Tout d'abord, respirez. Les efforts de chiffrement échouent souvent si vous oubliez de respirer. Quelque chose au sujet de l'inconscience nous fait avoir du mal à crypter les choses!
Deuxièmement, il semble que vous ayez besoin d'un modèle de menace. Un modèle de menace décrit le type d'adversaires qui vous inquiètent. Sans modèle de menace, tous la sécurité est un théâtre de sécurité parce que vous vous battez follement en espérant que vos actions incontrôlées arrêtent un adversaire dont vous ne savez rien. Essayez-vous d'empêcher votre sœur de lire votre journal intime, ou essayez-vous de vous cacher de la foule? Avez-vous récemment fait des ennemis avec des agences à trois lettres?
Avez-vous envisagé si votre adversaire est prêt ou non à effectuer une cryptanalyse avec un tuyau en caoutchouc?
( XKCD )
C'est pourquoi un modèle de menace est si essentiel. Considère ceci. Il est généralement admis qu'un fichier crypté AES-256 protégé par un mot de passe suffisamment long n'est pas craquable par quoi que ce soit de moins qu'une agence gouvernementale, et son généralement supposait que les agences gouvernementales ne pouvaient pas non plus le casser. Ainsi, une seule couche d'AES-256 vous protégera très certainement de tout ce qui se passe jusqu'aux sortes de personnages louches qui sont prêts à vous battre avec un tuyau en caoutchouc jusqu'à ce que vous crachiez le mot de passe. Il n'y a aucune raison de faire plus d'une couche d'AES-256, sauf si vous avez un modèle de menace pour le sauvegarder.
Maintenant, pourquoi pensez-vous que le fractionnement du fichier vous aidera? Vous utilisez déjà certains des outils de cryptage les plus puissants de la planète. Pourquoi le fait de retenir une section aiderait-il vraiment? Bien sûr, si vous êtes confronté à un attaquant qui connaît une fissure AES-256 actuellement non révélée mais ne sait pas comment désosser un format de fichier divisé 7Zip, cela pourrait aider. Tout comme le papier d'aluminium.
Je ne dirais pas que vous avez un théâtre de sécurité. La première étape est bonne: stocker les données dans un format crypté avec un bon mot de passe fort. Le reste du processus, cependant, est le théâtre de la sécurité. Ne perdez pas votre temps à mettre des couches sur des couches de cryptage.
Le pire des cas est que votre effort excessif vous empêche d'accéder aux données car vous avez rendu 10 fois plus difficile l'accès à vos propres données. La probabilité d'une erreur dans le processus qui rend vos données inaccessibles est grande et vous n'avez obtenu aucune sécurité réelle appréciable.
Je ne connais pas aussi bien 7-Zip pour bien comprendre ses capacités. Cependant, en supposant qu'il ne s'agit que d'un fichier Zip protégé par mot de passe, alors non, ce n'est pas sécurisé. Cependant, je vois certains commentaires où 7-Zip peut offrir un cryptage basé sur AES qui serait sécurisé (en supposant qu'aucun bogue n'existe avec la mise en œuvre de 7-Zip, il a donc créé un fichier crypté AES vrai et valide).
En bref, tout ce qui peut être téléchargé et craqué hors ligne doit être supposé pouvoir être craqué avec suffisamment de temps. En supposant que votre fichier 7-Zip est crypté avec AES-256 (encore une fois, pas de bugs), vous serez à la merci de l'entropie de vos mots de passe et de la vitesse de la machine de l'attaquant.
Au lieu de créer 5 ou 6 niveaux d'archives fractionnées, l'utilisation d'une seule archive de mot de passe à haute entropie serait suffisante. Le fractionnement de l'archive ne fait rien car il vous suffit de pouvoir "déverrouiller" le premier pour pouvoir décrypter la chaîne d'archives.
En fin de compte, la réponse à votre question est qu'il suffit purement d'utiliser 7-Zip avec AES-128 ou 256 tant que vous utilisez un mot de passe vraiment aléatoire et sécurisé avec autant d'entropie que possible. 64 caractères en majuscules, minuscules, chiffres et symboles sans motifs perceptibles ou répétition est parfaitement acceptable. N'écrivez simplement pas le mot de passe sur un pense-bête et laissez-le sur votre moniteur. Utilisez un vrai gestionnaire de mots de passe pour garder une trace de ce mot de passe de 64 caractères et assurez-vous d'utiliser un mot de passe maître sécurisé Nice sur ce gestionnaire de mots de passe. Vous n'êtes aussi sûr que la méthode la moins sécurisée - coller votre mot de passe sous forme de fichier texte sur votre bureau n'est pas sécurisé.
Gardez également à l'esprit qu'il peut être plus facile en tant qu'attaquant d'accéder simplement à votre PC pour capturer ces mêmes données - gardez à l'esprit contre qui vous essayez de vous protéger. Dans ce cas, ce qui précède est parfaitement acceptable pour quelque chose comme Google Drive/Dropbox et s'inquiète de leur exposition (ou d'employés curieux).
Toutes les réponses données jusqu'à présent sont excellentes! Cependant, je pense qu'il y a encore une possibilité à mentionner. J'ai remarqué dans la question d'origine que l'OP mentionnait la longueur du mot de passe (mots de passe de 32 caractères) et la mise d'un élément sur un deuxième service cloud qui serait nécessaire pour décrypter les données d'origine.
Je crois que VeraCrypt prend en charge les fichiers de clés et cela résoudrait deux ou trois points dans la question d'origine.
En plus des autres réponses, je voulais souligner que vous devrez stocker les mots de passe quelque part. S'ils obtiennent les mots de passe, ils peuvent facilement accéder aux données. Si vous souhaitez les sécuriser, vous devrez crypter les mots de passe et stocker leurs mots de passe quelque part, etc.
C'est bon. Certaines parties sont probablement redondantes (en utilisant le même système de chiffrement plusieurs fois), mais si vous aviez à la place le premier Zip, puis ajouté des données brutes, puis mettez tout cela dans un Zip et ainsi de suite, cela aurait du sens, donc c'est comme passez le colis avec vos fichiers les plus anciens au milieu.
Ensuite, pour l'étape où vous sortez un morceau pour le rendre illisible, c'est possible mais pas aussi simple que vous le dites. Vous devez utiliser une implémentation du partage secret de Shamir, ou XOR le fichier encodé compressé final avec des données aléatoires, puis enregistrer le résultat en ligne et les données aléatoires ailleurs.
Votre méthode de partage Zip est absurde et n'ajoute aucune valeur protectrice. Utilisez simplement une méthode de compression bien comprise, bien testée et fortement cryptée et vous serez suffisamment sécurisé pour répondre à votre besoin déclaré. Si vous ne pouvez pas faire confiance à la compression (Zip ou autre), séparez la compression des données du conteneur de cryptage si cela vous fait vous sentir mieux. Les multiples et les divisions que vous décrivez ajoutent de la complexité sans ajouter de sécurité significative (comme la force des clés ou la vérification des processus). Vous ne résoudrez pas les implémentations défectueuses de compression + cryptage en le faisant plusieurs fois.