De la même façon que l’on a implémenté des entités de recouvrement pour récupérer les objets protégés, il serait peut-être utile de pouvoir mettre en place des entités de recouvrement des liens dissimulés.
Catégorie : protection
Protection des objets – les origines
Le problème de protection des objets de faible taille, tel que décrit dans l’article Protection et faible entropie, n’a pas de solution simple ou élégante. Peut-être qu’il est temps de se questionner sur la pertinence de la façon dont est assurée la protection des objets, de revoir les réflexions à l’origine de la protection des objets.
D’ailleurs, dans le même ordre d’idée, il faudra peut-être aussi se poser des questions par rapport à la dissimulation des liens qui crée un problème différent mais sans solution simple, performante et élégante.
A l’origine, l’usage de la protection des objets n’avait pas été vu avec autant de cas d’usages. L’idée était de pouvoir dissimuler le contenu d’une objet tout en continuant de le tracer, c’est à dire de l’identifier par son empreinte. Il semblait peu utile de dissimuler des choses aussi simple que « oui » ou « non ».
La capacité de pouvoir tracer devait aussi permettre de pouvoir bannir un objet en se basant sur son empreinte en claire. Une fois protégé un objet a une infinité d’empreintes possibles, donc il devient non traçable en pratique.
L’idée était aussi de pouvoir vérifier que le contenu protégé que l’on recevait d’une autre entité correspondait bien au contenu en clair attendu. Ceci avait pour but de ne pas ce retrouver avec un code offensif une fois déprotégé en lieu et place d’un objet anodin. Dans ce cas un contenu offensif peut être écarté rapidement par un simple lien de mise en liste d’exclusion.
Le problème vient du fait que le lien de protection de type k, en particulier le lien de chiffrement symétrique, fait l’association entre la valeur claire et la valeur chiffrée de l’information. En disposant de l’empreinte de l’information en claire on peut, si la valeur totale de son entropie est faible (ou si, déduit des parties prévisibles, la valeur totale résiduelle de l’entropie de l’information est faible), on peut dans ce cas recalculer l’information.
Il est théoriquement possible que le recalcule de l’information en claire donne une autre information ayant la même empreinte. Mais l’espace des valeurs calculables étant inférieur à la taille de l’empreinte des objets, cà d la valeur totale de l’entropie de l’information recalculée en rapport avec la valeur totale de l’entropie d’une empreinte, et en considérant l’algorithme de prise d’empreinte cryptographique suffisamment robuste, il est très peu probable (de l’ordre de l’inverse de la taille des empreintes) de trouver une autre information de même empreinte. Ce serait même très inquiétant pour l’algorithme de prise d’empreinte cryptographique.
En parcourant le code et les cas d’usages actuels, il apparaît que l’on fait déjà indistinctement référence à un objet en clair ou protégé en utilisant son empreinte pour son contenu en clair ou protégé. Le code se charge de remettre dans le bon sens les deux identifiants.
Ne faire référence que à la partie protégée ne pose pas plus de problème que ça dans les usages actuels puisque l’on a juste besoin d’un identifiant.
Il est alors possible de recalculer l’empreinte, donc l’identifiant, du contenu en clair, et donc de pouvoir potentiellement le confronter à lien de mise en liste d’exclusion.
Le temps est encore à la réflexion mais la solution est peut-être là …
Protection des objets – faible entropie
Les messages que l’on protège peuvent être courts ou peuvent être dans certains cas facilement recalculés lorsque la seule partie variable du contenu a une faible entropie. C’est un problème général qui prend tout son sens dans la messagerie.
Le lien de chiffrement relie le hash de l’objet en clair avec le hash de l’objet chiffré. c’est indispensable si on veut pouvoir retrouver le contenu d’un objet en clair sans avoir à parcourir l’intégralité des hashs des objets protégés. C’est pour éviter le problème que l’on a avec l’implémentation des liens dissimulés.
Nous sommes dans le cas d’un modèle MAC-then-encrypt-then-MAC. Il faut trouver un moyen de renforcer l’entropie des objets protégés. Jouer sur le salage ou l’IV du chiffrement ne résout pas le problème puisque le problème vient du MAC avant chiffrement.
Et ce problème ne concerne pas des objets dont le contenu a une entropie supérieure à 128 bits et qui ne sont pas prédictibles. Il n’est pas utile, voire contre productif, de systématiser une solution de renforcement de l’entropie des objets protégés.
Il y a peut-être deux solutions. La première serait d’ajouter au contenu un aléa que l’on serait capable de retirer lors de l’exploitation de l’objet, comme du bourrage (padding). La seconde serait d’opérer sur l’objet une valeur d’un autre objet et de ne pas lié l’objet initial mais uniquement l’objet opéré. Cependant cette seconde méthode parait assez fragile en l’état.
La suite au prochain épisode…
Liens de classification des objets
Les objets que l’on affiche dans les applications sont déjà affublés de certains marquages, même si ils ne sont pas encore tous fonctionnels.
Par exemple, un objet peut être marqué comme dangereux et donc son contenu masqué par défaut. Cependant, les enfers n’ayant toujours pas ouverts, ce marquage n’est pas utilisé.
D’un autre côté, un objet protégé se verra affublé d’un message d’avertissement pour prévenir que son contenu ne doit pas être affiché en public. Ou dans certains cas comme sur les messages, c’est un indicateur qui donne l’état de protection d’un message.
Mais il est un autre type de message qu’il peut être utile de délivrer à un utilisateur. Au delà du fait qu’un objet est protégé, cette protection se justifie sûrement par rapport à la sensibilité du contenu de l’objet. Il est alors légitime de préciser une classification du contenu de l’objet dans certaines circonstances.
Cela permet d’avoir aussi une liste des informations importantes et de les tracer plus facilement.
C’est ce que font les militaires pour marquer les documents sensibles et classifiés. C’est ce que font les industriels pour marquer leurs secrets industriels.
La difficulté ici c’est qu’il n’y a pas de marquage type. Chacun emploie ses propres références de marquages. Il faut donc permettre cette souplesse. De plus, les marques doivent s’additionner et non se remplacer.
On peut imaginer un nouvel objet réservé destiné à gérer les marquages et qui servirait comme champ méta dans les liens de marquage. Les liens de marquages, type l, feront le lien entre l’objet à marquer et un objet de marquage via l’objet de référence.
Peut-être que l’objet de marquage sera lui-même aussi un objet de référence de ce marquage en particulier. Ceci permet de gérer des attributs liés au marquage comme un nom long, un nom court, une couleur, etc…
L’étape suivante sera ensuite de faire apparaître les marquages autours des objets. Est-ce géré comme les messages d’information actuels ? Est-ce géré différemment pour être clairement différencié ? Comme sera géré le multi-marquage ?
Enfin, comme ce système de marquage aura un impact sur les performances, il sera activable au besoin mais pas par défaut.
Pour l’instant c’est une idée non encore implémentée…
Relais d’authentification sans partage de secret
Dans l’article sur les relais d’authentification, on a vu qu’il était possible très simplement de déverrouiller une entité sur un serveur distant en rejouant l’authentification. Mais cela implique de transmettre le mot de passe de cette entité. Et cela veut dire aussi que la clé privée est déverrouillée sur le serveur distant.
Il est théoriquement possible de réaliser un mécanisme d’authentification sans partage de secret. Dans ce cas une instance déverrouillée sur un serveur distant ne disposerait ni du mot de passe ni de la clé privée de l’entité. Il faut donc implémenter un mécanisme qui permette au serveur distant de venir interroger le serveur local avec la session de l’entité en cours. Le mot de passe de l’entité étant stocké dans le cache de la session PHP, il serait impossible au serveur distant de l’obtenir. Mais il peut dans ce cas accéder aux objets protégés et notamment aux secrets de chiffrement des objets. Pour les liens dissimulés c’est par contre plus complexe.
Avec un tel relai il est possible de se connecter sur un serveur distant sans divulguer son mot de passe tout en disposant de l’accès aux objets protégés et à la possibilité de signer des liens.
Un serveur distant compromis pourrait le temps de la session accéder aux objets protégés. Mais une fois la session fermée, dans la fenêtre du navigateur sur le serveur local, aucun autre objet protégé ne pourrait plus être ouvert. Au minimum, tous les nouveaux objets protégés ne seraient pas accessibles. Pour les plus anciens… ça dépend du temps d’ouverture de la session…
Options de désactivation de protection et de dissimulation
La protection des objets est fonctionnelle. La dissimulation des liens des objets pas encore. Les deux sont implémentés dans la bibliothèque nebule.
Mais il y a désormais des options pour les désactiver, elles sont activées par défaut :
permitProtectedObject: Cette option active la possibilité de gérer la protection des objets et la possibilité de prendre en compte les liens de typek.permitObfuscatedLink: Cette option active la possibilité de gérer la dissimulation (offuscation) des liens des objets et la possibilité de prendre en compte les liens de typec.
Lorsque une option est désactivée, le type de lien correspondant n’est plus géré, il est explicitement refusé. C’est à dire que les liens existants sont ignorés et les nouveaux liens sont rejetés comme invalides.
Ces options sont encore en cours d’ajout dans le code mais sont déjà fonctionnels pour les liens.
Non vérification crypto et lecture seule
Dans la réflexion de créer une application dédiée à la manipulation de photos et de vidéos se pose invariablement la question des vidéos HD, FHD et UHD. La taille de ce genre de vidéo, pour conserver une qualité de restitution optimale, est assez conséquente.
Le problème ici dans nebule c’est la vérification systématique de la validité du contenu d’un objet manipulé, c’est à dire le re-calcul de son empreinte cryptographique. Si la librairie nebule mémorise le temps d’une session un objet vérifié, dans un cache, ce qui peut déjà présenter un problème de sécurité, il faut cependant toujours faire cette prise d’empreinte au moins une fois.
Par exemple l’empreinte SHA256 d’un fichier de 1,6Go va nécessiter environ 30s sur un disque dur à plateaux normal. La consommation de temps vient principalement de la lecture du support et non du calcul cryptographique. Et la prise d’empreinte cryptographique est un calcul relativement simple…
Il peut en être de même avec les liens qui nécessitent une vérification de signature de type RSA ou équivalent. Ce calcul en cryptographie asymétrique est beaucoup plus long rapporté à la quantité de données. Si un lien ne faire que quelques kilo-octets tout au plus, le nombre de liens à vérifier pour un seul objet peut être potentiellement gigantesque. Au cours du développement des applications de nebule il n’est pas rare de devoir nettoyer à la main les liens de la bibliothèque parce qu’il y en a plus de 80.000 … soit systématiquement 80.000 lien à lire et à vérifier. Là aussi un cache des liens déjà validés dans la session est en place pour accélérer le travail mais ce n’est pas toujours suffisant.
Une possible résolution de ce problème peut être de changer de disque et de passer sur SSD, ou de nettoyer sévèrement les liens utilisés. Mais ces deux cas sont extrêmes et pas toujours réalisables.
Une autre solution peut être envisageable dans le cas de machines de relais ou de partage d’informations en particulier. Comme on l’a vu dans l’article Frontal et relai d’information verrouillé en écriture, il est possible d’avoir des serveurs en lecture seule en activant l’option de lecture seule ou en figeant le système de fichiers. Cela pose des contraintes particulières sur la synchronisation des objets et des liens et sur le fait qu’ils doivent être vérifiés à un moment ou à un autre. Dans ce cas on peut coupler une option de non vérification des objets et des liens avec une option de lecture seule.
Avec cet exemple une entité peut toujours d’authentifier afin d’accéder à du contenu protégé mais ne pourra réaliser aucune action.
On peut imaginer aussi que l’application de mise à jour (upload) peut être autorisée à mettre à jours des liens et des objets en les vérifiant et ainsi avoir un serveur partiellement en lecture seule.
Donc il serait possible d’avoir un serveur de relai d’information en lecture seule uniquement mais avec un fonctionnement accéléré.
Ceci n’est pas implémenté actuellement.
Définition des groupes
La gestion des groupes est entièrement revue et corrigée dans la bibliothèque nebule en PHP orienté objet et dans les applications (sylabe, klicty, messae).
Une fois les applications mises à jour, les groupes existants disparaîtront.
Cet article invalide la définition de groupe telle que définit dans l’article Définition des groupes du 14/01/2016.
Cette implémentation des groupes sera aussi utilisée pour les conversations contenant des messages.
OG / Groupe
Le groupe est un objet définit comme tel, c’est à dire qu’il doit avoir un type mime nebule/objet/groupe.
Fondamentalement, le groupe est un ensemble de plusieurs objets. C’est à dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Mais la définition du groupe doit être plus restrictive afin que celui-ci soit utilisable. Pour cela, dans nebule, le groupe n’est reconnu comme tel uniquement si il est marqué de son type mime. Il est cependant possible d’instancier explicitement un objet comme groupe et de l’utiliser comme tel en cas de besoin.
Le groupe va permettre de regrouper, et donc d’associer et de retrouver, des objets. L’objet du groupe va avoir des liens vers d’autres objets afin de les définir comme membres du groupe.
Un groupe peut avoir des liens de membres vers des objets définis aussi comme groupes. Ces objets peuvent être vus comme des sous-groupes. La bibliothèque nebule ne prend en compte qu’un seul niveau de groupe, c’est à dire que les sous-groupes sont gérés simplement comme des objets.
Messages et protection
Une protection des messages basés les objets et liens de nebule peut être mise en place. Cette protection ne vise pas à dissimiler la présence d’un message mais à dissimuler son contenu. La dissimulation de la présence d’un message, plutôt nommée offuscation, est un autre sujet à part entière.
Mais cette protection peut ne pas être efficiente et elle peut se retrouver mise à mal du fait du fonctionnement même des liens de chiffrement (type k). Le lien de chiffrement va associer l’empreinte du message en clair avec l’empreinte du message chiffré. Hors un message de petite taille va avoir une forte probabilité avec le temps d’être (re-)créé par ailleurs et donc de dévoiler le contenu d’un message protégé. Et même pour un message plus conséquent, si il est partiellement ou complètement redécoupé en sous-objets via des liens de subdivision (type s), peut voir une partie de son contenu protégé dévoilé. La subdivision peut être par ailleurs légitime dans le cas d’un pré-découpage par mots pour la recherche sur mots clés.
La protection doit donc être adaptée dans le cas de la messagerie.
L’ajout d’un sel avant chiffrement ne résout pas le problème puisqu’il ne masque pas le lien entre le texte clair et chiffré. Par contre il est peut-être possible de pré-saler l’objet à chiffre et ne le reconnaître que sur son empreinte pré-salée.
A travailler…
PFS sans connexion
La confidentialité persistante (Perfect Forward Secrecy – PFS pour les intimes) permet lors d’échanges entre personnes via un support protégé d’oublier le contenu des échanges précédents. Lorsqu’elle est bien implémentée, il est impossible de pouvoir reconstituer les échanges précédents d’une « conversation », y compris pour les personnes concernées.
Lors de la compromission du moyen de communication, seules les conversations en cours sont accessibles. Les précédentes conversations sont définitivement inaccessibles y compris pour un adversaire qui aurait enregistré tous les échanges chiffrés et obtiendrait par la force le compte d’un utilisateur.
La meilleur méthode pour arriver à ce résultat est d’utiliser un secret de session partagé entre les personnes qui communiques, négocié en début de conversation et volontairement oublié en fin de conversation. La négociation peut être faite notamment via un échange de type Diffie-Hellman (DH).
La PFS a donc principalement deux contraintes. Il faut échanger un secret temporaire avec ses correspondants. Et il faut que ce secret soient privés, c’est à dire stockés uniquement en interne sur les machines destinataires.
De par sa conception acentrée et potentiellement non directement inter-connecté, nebule ne permet pas la mise en place directe d’une forme de PFS. Fondamentalement, nebule permet de gérer de l’information et non des connexions. La non connexion directe entre les correspondants empêche une négociation préalable instantanée d’un secret partagé type DH. Ensuite, toute la protection de la partie privée des entités repose sur le chiffrement des objets et l’offuscation des liens, mais tous les liens et objets ainsi protégés sont partagés publiquement et donc enregistrables. Il n’est pas possible de se baser sur ces mécanismes de protection pour la PFS.
Il existe peut-être un moyen d’implémenter une PFS sûr dans nebule mais au prix d’un grand nombre d’objets à synchroniser, à voir…
Entit̩ multi-r̫les Рsuite
Suite de l’article sur les Entité multi-rôles.
La gestion de multiples clés cryptographiques asymétriques dépendantes d’une seule clé principale impose des contraintes lors de la synchronisation d’entité mais il n’est pas difficile à mettre en place.
La première idée serait de protéger les mots de passe des clés secondaires avec la clé primaire. Mais cette clé primaire a avant tout le rôle d’authentification, elle ne doit donc pas servir à faire du chiffrement.
La seconde idée consiste à dériver (PBKDF) les mots de passe des clé secondaires du mot de passe de déverrouillage de la clé primaire. Ainsi la clé primaire ne sert qu’à l’authentification. Cela implique aussi que la modification du mot de passe de la clé primaire force le changement de mot de passe de toutes les clés secondaires associées.
La dérivation des mots de passe peut prendre en compte la partie publique de la clé primaire et de la clé secondaire concernée. Elle peut aussi prendre en compte, en plus, l’ID dans nebule du rôle associé. Une implémentation complète devra être proposée.
Entité multi-rôles
D’un point de vue robustesse et sécurisation des clés cryptographiques, il est recommandé de séparer les rôles des différentes clés utilisées. Une clé crypto ne doit avoir qu’un seul usage, c’est à dire un seul rôle. Dans l’implémentation des entités dans nebule, les entités étant des clés cryptographiques avec de multiples rôles, il va falloir les scinder.
Les rôles les plus fréquents sont :
- L’authentification. C’est utilisé pour le déverrouillage des entités.
- La signature. Tous les liens sont signés.
- Le chiffrement. Il intervient dans la protection des objets et la dissimulation des liens.
Toutes les clés liées à des rôles peuvent être rattachées à une clé cryptographique asymétrique principale et reliées à celle-ci par des liens. Il est possible par la suite d’étendre sans problème les rôles comme par exemple les rôles d’autorités locales.
La segmentation des clés par rôles impose la gestion de multiples clés pour une entité, notamment lors de la synchronisation sur différents supports. Mais elle permet en cas de compromission d’une clé de limiter l’étendu des dégâts.
Échange ou téléchargement d’objet
Un objet peut être récupéré de deux façons.
- Via un lien web avec comme argument
/o/idon télécharge le contenu de l’objet avec comme nom son identifiantid. L’empreinte est ensuite vérifié pour voir si elle correspond à l’identifiant. - Via un lien web avec comme argument
?o=idon télécharge le contenu de l’objet avec comme nom le nom déclaré par les liens nebule. cela permet de télécharger l’objet sous une forme de fichier classique. On fait ainsi une dé-nébulisation de l’objet. C’est aussi le seul moyen d’avoir accès au contenu protégé hors nebule.
Mais pour un utilisateur, ces deux méthodes ne se valent pas. La première méthode sert à la synchronisation et l’échange d’objets entre programmes et n’a pas pas d’intérêt direct pour l’utilisateur. La seconde lui permet au contraire de reprendre un objet sous une forme classique de fichier.
Actuellement un problème existe dans klicty puisque un objet non protégé peut être téléchargé, c’est le but de l’application, mais c’est fait avec la mauvaise méthode. Donc le fichier téléchargé n’a pas le bon nom. Alors que pour un objet protégé ce problème n’existe pas puisqu’il faut impérativement passer par la deuxième méthode pour avoir accès au contenu non protégé.
La première méthode doit être exclusivement réservée à la synchronisation d’objets.