Dans nebule, à chaque fois que de la cryptographie intervient avec des entités d’un côté et du contenu de l’autre, on utilise de la cryptographie asymétrique et de la cryptographie symétrique.
La clé de session est l’un des éléments importants. Elle assure en quelque sorte le lien entre l’entité et le contenu. Le contenu peut être soit un objet soit un lien. La clé de session, c’est le mot de passe de la cryptographie symétrique pour chiffrer/déchiffrer le contenu. La clé de session est chiffrée/déchiffrée avec respectivement la clé publique ou la clé privée d’une entité.
La clé de session est le pivot du processus de chiffrement. Elle aurait pu être intégrée au contenu chiffré, ce qui nécessite une extraction pour le déchiffrement. Mais au titre de pivot, dans nebule elle est volontairement mis en avant et isolée plutôt que cachée comme une banale donnée technique.
Lors du processus de chiffrement d’un objet, la clé de session est un objet à part entière et lui aussi chiffré avec une clé privée d’entité.
Lors du processus d’offuscation d’un lien, son chiffrement en fait, la clé de session aurait pu aussi être fusionnée dans le registre avec le champ contenant le lien chiffré LienChiffré. Mais au contraire, elle occupe un champ à part entière CléSession.
Signature_Signataire_TimeStamp_c_EntitéCible_LienChiffré_CléSession
Cette sanctuarisation de la clé de session entraîne apparemment une plus grande complexité des processus de chiffrement. Cependant, cela apporte une grande simplification dans la gestion des objets chiffrés, mais rien pour la gestion des liens offusqués. Si un objet chiffré doit être partagé avec plusieurs entités, une clé de session différente entraînerait la nécessiter de rechiffrer l’objet source pour tous les destinataires, cà d le chiffrement symétrique et asymétrique. Avec une clé de session autonome, il suffit juste de la rechiffrer pour tous les destinataires la clé de session, donc juste opération de chiffrement asymétrique. Pour un petit objet, le gain est négligeable, mais il ne l’est pas pour un gros objet (plusieurs fois la taille de la clé de session).
Je rappelle que le chiffrement asymétrique est beaucoup plus gourmand en ressources processeur et en mémoire que le chiffrement symétrique.
On peut aussi imaginer que la clé de session soit réutilisée pour le chiffrement de plusieurs objets ou de plusieurs liens. Si c’est pour une seule entité, cela permet de ne réaliser le chiffrement asymétrique qu’une seule fois. Cela crée une sorte de groupe d’objets ou de liens, ceux-ci regroupés par leur clé de session commune. Il est aujourd’hui possible d’envisager deux cas où plusieurs objets ou plusieurs liens pourraient utiliser la même clé de session :
- La diffusion d’objets très fortement liés entre eux et qui auraient tout intérêts à « voyager » ensembles. Idem pour des liens fortement couplés comme lors de la nébulisation d’un objet.
- L’utilisation de matériels peu performants pour lesquels il serait incontournable de n’avoir à calculer qu’un seul chiffrement asymétrique pour plusieurs objets et/ou plusieurs liens.
Il faut cependant garder à l’esprit que ces deux cas entraînent un risque sur la divulgation de ces objets et liens. Si un seul d’entre eux est retransmit pour autrui, c’est à dire que sa clé de session est repartagée, alors c’est tous les autres qui sont de fait divulgués. Ces exceptions doivent être évitées à tout prix ou toujours utilisées avec intelligence et extrêmes précautions.
Une clé de session doit toujours être robuste et utilisée pour un seul objet ou un seul lien.