Discussion :

[Micke7]

Bonjour,

Je souhaiterai rendre inutilisable (hors appli) des fichiers d'une dizaine de Mo. Vu la taille de ceux-ci, le cryptage complet de ces fichiers ne me parait être la meilleure des solutions, je pensais donc à l'ajout d'un en-tête d'une centaine de bits au début (ou à la fin) du fichier. Le problème est qu'il me semble qu'il est impossible de modifier un fichier sans le ré-écrire totalement, ce qui engendrerait là encore des pertes de performances énorme.

Auriez-vous une idée de comment protéger ces fichiers?

[Logan Mauzaize]

Il n'existe aucun moyen fiable de protéger des fichiers pour les exploiter sur une machine cliente :

1. Tôt ou tard il te faudra enlever la protection et le contenu sera accessible.
2. Tu dois fournir l'algorithme de dé-protection dans ton application

Un algo simple : l'application d'un masque ou l'inversion bit-à-bit.

En ce qui concerne la gestion du fichier, tu peux très bien le protéger au moment de l'écriture.
Autrement il est possible d'ajouter des données dans un fichier avec RandomAccessFile. J'ai déjà essayé de copier les données in-place en utilisant deux channel sur le même RandomAccessFile mais la copie n'était pas correcte, j'ai donc "déplacé" manuellement les octets par tranche. Ca ne prend pas plus d'une seconde pour un fichier de quelques méga.

[Micke7]

Je souhaite protéger ces fichier simplement car c'est une condition obligatoire pour pouvoir les exploiter (fichiers achetés à un organisme). Les utilisateurs du logiciel que je développe ne sont pas des utilisateurs avertis, je suis donc sûr qu'il ne chercheront pas à le décoder, d'ailleurs La simple modification de l'extension aurait largement suffit (non ce n'est pas une blague) . Ce n'est donc pas grave si la protection du fichier est faible.
Par contre j'ai oubli de préciser, les fichiers étant encodés d'une certaine manière, il sont lu par une librairie externe dont je n'ai pas les sources. Le seul moyen que j'ai pour les protéger est donc de les recréer bit par bit. Tes solutions sont elles toujours valables?

[Logan Mauzaize]

Tu fournies quoi à ton API pour lire les fichiers, un InputStream ou un File, une URI/URL ou un chemin ?
Si tu peux utiliser un flux, alors codes toi une classe qui lit le fichier et le décode à la volée.

Sinon la copie ne devrait pas être trop longue. Mais ça reste moins performant.
Ca dépend grandement du besoin en réactivité, du nombre de fois où les fichiers sont exploités, de la taille minimale/moyenne/médiane/maximale de tes fichiers.

[Micke7]

A L'API je lui fournis le chemin du fichier, donc impossible de passer par un flux.

[Logan Mauzaize]

La copie du fichier reste donc la seule solution.
Je créerais une sous-classe FilterInputStream pour gérer la transformation du fichier.

[adiGuba]

Salut,

A L'API je lui fournis le chemin du fichier, donc impossible de passer par un flux.

Il n'y a vraiment aucun autre moyen ? Pas moyen d'utiliser un InputStream ou une URL ?


Car sinon tu vas devoir réécrire les fichiers à chaque fois ce qui risque d'être très lourd !


a++

[tchize_]

et ce qui ne va rien protéger puisque le fichier sera stocké sur le disque

[Logan Mauzaize]

Tu peux le placer dans un répertoire temporaire bien caché, ca c'est déjà vu avec Deezer

[Djakisback]

Quelques autres idées pas très sécu mais bon :
- tu les colles en fichiers cachés
- tu splites tes fichiers et t'arranges pour les charger par morceaux et les reconstituer mais ton API t'empêchera sans doute de faire ça. Dommage car l'utilisateur ne pourrait pas ouvrir les fichiers splités, à part peut-être le fichier contenant le header.

Mais au fait, si tes fichiers contiennent du texte, que t'ajoutes ou modifies le header ou que tu ajoutes du bruit au début ou à la fin ne changera rien. Le fichier pourra être ouvert quand même par des applis comme Notepad à mon avis et le texte sera lisible. Même si ce sont des images, des progs comme IrfanView arrivent à détecter le format d'image et a recréer le header, il me semble.

Une autre idée serait de jouer sur les droits mais là ça devient compliqué, il faudrait un compte utilisateur pour l'appli et qu'elle ouvre une session, je ne sais même pas si c'est possible en Java et ça poserait sans doute des problèmes de portabilité, à moins qu'il n'y ait un truc de prévu.

[Logan Mauzaize]

D'où mon idée d'inversé les bits ou d'appliquer un XOR avec un masque.

Un bon vieux Vigenere binaire quoi

[Micke7]

Après 1 mois (congés + réunion etc etc), de retour avec mon problème .
Tout d'abord merci pour vos réponses.

Afin d'éviter de recréer à chaque fois le fichier, j'avais pensé à modifier les n premiers bytes, mais je ne sais pas s'il c'est possible(sans repasser par la recréation complète du fichier donc)?

Sinon ta proposition Nemek ne me déplaît pas. Elle me parait assez simple à mettre en place et sans aucun doute moins lourde que passer par une API de "cryptage". A tester si ma première solution n'est pas possible.

[EDIT]Bon et bien finalement inverser les bytes va prendre énormément de temps, car sauf erreur de ma part, je vais devoir lire le fichier bytes par bytes (15Mo pour rappel), rendant l'utilisation d'un buffer inutile.

[Micke7]

Je up juste pour avoir une réponse à ma question: est-il possible de modifier les n premiers octets d'un fichier sans devoir le réécrire totalement.

Merci.

[tchize_]

RandomAccessFile.

[Micke7]

Roooh, je me suis fié au nom de la classe (Random) sans même creuser le sujet.
Merci beaucoup