Lun 08/07/2013 - Actualités
Posté : lun. 8 juil. 2013 22:14
Cryptage
Dans XT3 :
Tous ces services sont prévus pour travailler avec le mot de passe, qu'il faudra donc avoir demandé en amont... et c'est la prochaine étape.
Dans XT3, la demande de mot de passe se faisait lors de l'ouverture d'un outil protégé, ici il va falloir brancher cela lors des accès aux données protégées lors d'un un clic sur un dossier dans un TreeView.
Le déplacement d'une donnée non cryptée vers un dossier crypté doit donc déclencher son cryptage, et si le mot de passe n'a pas encore été saisi, il faut le demander. (Dans le cas d'un drag-and-drop, il est probable que l'opération sera simplement refusée.)
Dans XT3 :
- Les données qui sont manipulées en mémoire sont "en clair", c'est à dire décryptées.
- Le décryptage se fait lors de la lecture de chaque fichier protégé, et le cryptage lors de l'écriture.
- La granularité du cryptage étant l'outil, et chaque outil ayant son propre fichier, ce système fonctionne bien.
- Il n'y a qu'un seul fichier représentant un arbre de données hiérarchisées.
- Par contre, la granularité du cryptage est le dossier, ce qui fait que l'arbre est potentiellement partiellement crypté.
- Afin de permettre d'accéder aux dossiers non cryptés sans avoir à saisir le mot de passe, il a été nécessaire d'implémenter un système opposé : XT4 manipule donc en mémoire les données telles qu'elles sont stockées sur disque, et les décrypte lorsque c'est nécessaire. C'était LA décision qui était si difficile à prendre.
- Un nouveau service de [dé]cryptage d'une donnée a été implémenté. Il fonctionne en récursif pour les dossiers.
- Il a été décidé que les Properties seraient totalement cryptées. Ainsi, la Property [Name=Bob] sera cryptée en [********] et non pas [Name=***]. Les services Prop.Get et Prop.Set, devenus inopérants, ont dû être adaptés afin de décrypter l'intégralité des Properties avant d'y accéder, et de les recrypter après usage. Cette possible baisse de performance est compensée par une meilleure sécurité, car le service de cryptage d'une liste de chaîne ne réinitialise pas le Cipher après chaque chaîne, chacune d'entre elles étant donc dépendante des précédentes.
- Lors de la copie ou le déplacement d'une donnée vers un autre dossier, la donnée est automatiquement [dé]cryptée selon son nouveau parent grâce à un nouveau service d'héritage de cryptage.
- La gestion des dossiers est différente : un dossier copié ou déplacé sera crypté si son parent l'est et lui ne l'était pas, mais le contraire ne se fera pas : un dossier crypté le restera même si son nouveau parent ne l'est pas.
Tous ces services sont prévus pour travailler avec le mot de passe, qu'il faudra donc avoir demandé en amont... et c'est la prochaine étape.
Dans XT3, la demande de mot de passe se faisait lors de l'ouverture d'un outil protégé, ici il va falloir brancher cela lors des accès aux données protégées lors d'un un clic sur un dossier dans un TreeView.
Le déplacement d'une donnée non cryptée vers un dossier crypté doit donc déclencher son cryptage, et si le mot de passe n'a pas encore été saisi, il faut le demander. (Dans le cas d'un drag-and-drop, il est probable que l'opération sera simplement refusée.)