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.

Collisions d’empreintes multi-algorithmique

On peut utiliser de multiples algorithmes pour calculer l’empreinte des objets. Certains algorithmes sont plus résistants, plus fiables ou plus sûrs que d’autres. Cette résistance est représenté par l’impossibilité (relative) d’inverser la fonction algorithmique, c’est à dire de retrouver l’objet source à partir de l’empreinte. Il en découle l’impossibilité (relative aussi) de calculer une collision dans les empreintes entre deux objets, c’est à dire de calculer un objet qui a une empreinte précise, par exemple la même empreinte qu’un autre objet pré-existant. Ces impossibilités sont relatives parce qu’il sera toujours possible dans le pire des cas (pour l’attaquant) de tester toutes les combinaisons possible afin de trouver une collision, mais cela lui prendra un temps tel que c’est jugé équivalent à impossible dans l’état actuel de nos connaissances mathématiques et de nos moyens informatiques.

Première conclusion, inutile de s’attarder sur des algorithmes de prise d’empreinte triviales comme CRC qui n’ont pour vocation que de permettre une vérification extrêmement rapide de données transmises (par exemple sur la couche TCP sur IP). Ces algorithmes ne sont pas prévus pour résister aux collisions volontaires.

Seconde conclusion, rappel de principes de base en sécurité informatique, on ne doit pas utiliser des algorithmes qui sont reconnus non fiables ou pour lesquels on est sur le point de réussir des collisions. Exit donc MD5, SHA0 et SHA1 par exemple.

Jusque là, on reste en territoire connu. SHA256 est encore aujourd’hui reconnu comme sûr et ne semble pas présenter de faiblesse à moyen terme. Il peut servir sans risque intrinsèque aux premières expériences nécessitant un bon niveau de sécurité. D’autres algorithmes connus sont susceptibles d’être utilisés dans un futur proche.

Mais que ce passe-t-il si on mélange plusieurs algorithmes différents pour le calcul d’empreinte ?
Ne risque-t-on pas d’affaiblir non pas les algorithmes mais le système dans son ensemble ?

En présentant un objets sous différentes empreintes générées par des algorithmes différents, ne risque-t-on pas d’affaiblir un ou plusieurs algorithmes ?

De façon plus générale, si une faille importante est découverte dans un algorithme et que celui-ci n’est plus jugé sûr, quelles conséquences pour l’ensemble du système ?