4.1.2. Interaction client-serveur
Durant les échanges entre plusieurs machines distantes
à travers TinyCE v2, les opérations de synchronisation et de
(re)distribution sont réalisées sur l'une des machines : c'est le
serveur. Les autres machines sont des postes clients et donc, ils ne servent
qu'à l'édi-tion des répliques partielles. Mais il n'y a
pas de TinyCE v2 Client et de TinyCE v2 Server; ces deux
entités sont intégrées dans TinyCE v2. N'importe quel site
peut donc être client puis serveur : cela dépend des
échanges effectués (via le communicateur). Cette faculté,
permet d'ouvrir le chemin au développement des échanges en pair
à pair.
Le communicateur est mis en oeuvre avec la technologie RMI
(Remote Method Invocation). Pour l'aspect sécurité, les
informations échangées sont cryptées, avec une clé
et un vecteur d'initialisation partagés, grâce à
l'algorithme AES (Advanced Encryption Standard) combiné au mode
d'opération CBC (Cipher Block Chaining). Les informations
reçues sont décryptées avec la même clé et le
même vecteur d'initialisation. Le mode de cryptographie est donc
symétrique, la clé et le vecteur d'initialisation étant
inscrits en dur dans le code source de TinyCE v2; ce qui constitue un risque de
sécurité (reverse engineering). Pour réduire la
taille de ce risque, TinyCE v2 crypte chaque workflow. Ainsi, chaque workflow
possède une clé et un vecteur d'initialisation partagés
par ses participants (sites) et permettant de sécuriser ce dernier; ces
outils de chiffrement sont renouvelés à chaque synchronisation.
Néanmoins cette stratégie n'est pas infaillible vu que les outils
de chiffrement des workflows sont eux mêmes cryptés avec les
outils de chiffrement généraux de TinyCE v2. Il serait donc
judicieux d'envisager d'autres moyens plus sûrs pour protéger les
informations circulant entre les utilisateurs de TinyCE v2. Le chiffrement des
clés partagées grâce à un algorithme de
cryptographie à clé publique (asymétrique) pourrait
être une bonne piste.
| 
