Webserver à la volée décryptage?

Question

Je traite d'un concept pour un projet qui invente des données absolument critiques.

La partie la plus importante est qu'elle doit être stockée cryptée.

Un système de fichiers chiffré monté à partir duquel le serveur Web dessert les fichiers ne suffit pas.

La clé pour déchiffrer les données doit être transmise dans l'URI de la requête sur une connexion sécurisée avec un hachage et un horodatage.

Le hachage, basé sur l'horodatage, la clé et le nom de fichier valide l'URI et le stocke sur une liste, de sorte qu'il ne peut être consulté qu'une seule fois. La partie importante maintenant est que le serveur web doit prendre le fichier du disque, et le servir déchiffré en utilisant la clé qu'il a obtenue de l'URI de la demande.

Il devrait également être efficace et rapide. Cela nécessite également une méthode de chiffrement qui n'exige pas l'analyse du fichier entier. afin que le fichier puisse être décrypté progressivement. Je pense qu'AES peut le faire avec des tailles de blocs spécifiées qui sont atomiques cryptées. Donc, une option serait de lire le fichier source dans un script PHP en morceaux de quelques megs où je décrypte en utilisant aes et imprimer le contenu déchiffré. Le script oublie alors les données précédentes et continue avec le morceau suivant jusqu'à ce que eof.

Si aes ne supporte pas que je peux simplement crypter des morceaux de taille définie du fichier séparément, les concaténer et faire la même chose lors du service des fichiers. Cependant, je voudrais m'en tenir à une norme que je n'ai pas à réinventer, donc je peux aussi utiliser des bibliothèques standard pour crypter les fichiers.

Cependant, ce sera très inefficace.

Connaissez-vous un module apache/lighttpd/nginx ou une meilleure méthode?

Answer 1

Vous devez ouvrir le fichier avec nmap(), puis crypter les données à la volée si nécessaire.

Je ne vois rien de plus approprié pour ce que G-Wan (200 KB), qui offre des scripts natifs C et cryptage AES (pas de bibliothèques externes nécessaires, même si les scripts C peuvent créer un lien avec une bibliothèque existante).

Si vous avez besoin d'atteindre les meilleures performances possibles, alors c'est la voie à suivre.

Answer 2

Vous voudrez peut-être regarder dans les filtres de flux de PHP (http://php.net/stream.filters); avec un peu de code de colle, vous pourriez lui faire lire un fichier crypté avec les fonctions d'accès au fichier PHP habituelles, et ce serait surtout transparent pour le code existant.

Answer 3

Si vous ne pouvez pas trouver un module PHP qui vous permet de déchiffrer les blocs/blocs, vous pouvez toujours pré-scinder le fichier en blocs de taille appropriée et les chiffrer séparément. Bien sûr, rappelez-vous que même si vous n'envoyez que de petites parties du texte en clair à la fois, il y a encore beaucoup d'autres endroits où ces données vulnérables peuvent être conservées - en particulier dans les tampons de sortie du serveur Web. Considérons le cas extrême d'un fichier de taille importante en cours de téléchargement par quelqu'un coincé sur un modem 2400 bauds. Vous pouvez très bien décrypter et mettre en file d'attente le fichier entier avant même que le premier morceau ait été téléchargé, laissant le fichier entier en clair dans un tampon quelque part.

Answer 4

Il n'existe pas de solution prête à l'emploi pour répondre à vos besoins. Et même si vous avez fourni un peu d'information sur les données qui seront récupérées, vous n'avez pas donné beaucoup d'indices quant à la façon dont les données seront transmises au serveur Web en premier lieu. Vous faites un grand nombre d'opérations pour éviter que les données ne soient compromises - mais si vous les décryptez sur le serveur, les données risquent non seulement d'être compromises, mais aussi la clé sera compromise. c'est-à-dire qu'il y a plus de théâtre que de substance dans l'architecture.

Vous semblez être flexible dans l'algorithme utilisé pour le chiffrement - ce qui implique que vous avez un certain contrôle sur l'architecture - donc il y a une certaine marge pour résoudre ces problèmes.

Le hachage, basé sur l'horodatage, la clé et le nom de fichier valide l'URI et l'enregistre dans une liste, de sorte qu'il ne peut être accédé qu'une seule fois.

Comment cela garantit-il qu'il n'est accessible qu'une seule fois? Certes, il pourrait être utilisé pour réduire la fenêtre d'opportunité pour CSRF - mais il ne l'élimine pas.

Le script oublie alors les données précédentes et continue avec le bloc suivant jusqu'à ce que eof.

Cette situation porte atteinte fondamentalement l'objectif de cryptage - les modèles dans les données seront toujours évident - et cela fournit un machanism pour tirer parti des attaques par force brute contre les données - même si la taille du bloc est relativement importante. Jetez un oeil à the images here pour une démonstration simple.

Une approche beaucoup plus sécurisée serait d'utiliser CBC, et de faire le cryptage/décryptage sur le client.

Il existe des implémentations javascript de plusieurs algorthms de cryptage (y compris AES) this page a une bonne boîte à outils. Et avec HTML5/localstorage, vous pouvez créer une application client complète en HTML/javascript. Comme vous commencez à le découvrir, le simple fait d'utiliser un algorithme de cryptage intelligent ne sécurise pas votre application. Il semble que vous deviez revenir en arrière et réfléchir à la façon dont vous stockez et récupérez les données avant de vous inquiéter de la méthode utilisée. pour le crypter.