Doit-on compresser avant de chiffrer ou l’inverse ? 

Cet article a été publié il y a 7 ans 8 mois 9 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Même si je ne suis pas un expert, et que j’ai dû m’y reprendre à plusieurs fois pour tout comprendre, j’ai trouvé intéressant de vous partager le dilemme auquel on peut faire face quand on cherche à la fois performance et sécurité. Deux notions parfois difficiles à concilier.

L’auteur, Max Veytsman, est co-fondateur d’AppCanary, une société qui édite une application du même nom qui surveille vos applications pour vous notifier quand une faille de sécurité apparait dans la chaine de fonctionnement (serveur, dépendances logicielles…). L’article original a été publié le 25 juin 2016.

Imaginez ceci :

Vous travaillez pour une grosse société. Votre boulot est plutôt ennuyeux. Franchement, vos talents sont gâchés à écrire du code passe-partout pour une application dont les seuls utilisateurs sont trois personnes de la compta qui ne supporte pas de vous voir.

Votre vraie passion, c’est la sécurité. Vous lisez r/netsec tous les jours et participez aux chasses aux bugs après le travail. Au cours des trois derniers mois, vous jouez à un jeu de spéculation baroque et vous gagnez parce que vous avez trouvé une faille « heap-based » et écrit un bout de code en assembleur pour vous aider à acquérir des titres.

Tout change quand vous découvrez que ce que vous pensiez être un jeu vidéo était en fait un outil de recrutement intelligemment déguisé. Mont Piper, la meilleure société de consultant en sécurité du monde, recrute. Et vous venez de décrocher un entretien !

Un voyage en avion et un Uber plus tard, vous vous asseyez en face de votre potentiel futur boss : un hacker légèrement moite de transpiration prénommé Gary dans un t-shirt d’un groupe de métal norvégien et des lunettes de soleil qu’il refuse d’enlever à l’intérieur des bâtiments.

Vous explosez la première partie de l’entretien. Vous présentez une superbe explication de la différence entre vie privée et anonymat. Vous décrivez la même politique à l’origine dans les moindres détails, et donnez trois possibilités un attaquant peut contourner. Vous exposez même sur le tableau blanc les subtilités de __fastcall vs __stdcall. Finalement, vous arrivez à l’avant-dernière partie, la sécurité des protocoles.

Gary vous regarde dans les yeux et dit : « vous concevez un protocole réseau. Est-ce que vous compressez les données avant de les chiffrer, ou chiffrez-vous avant de compresser ? » Et ensuite il serre ses mains l’une contre l’autre et se sourit à lui-même.

Une question de sécurité classique d’entretien !

Prenez une seconde et réfléchissez-y.

A un haut niveau, la compression essaie d’utiliser des motifs dans les données pour en réduire la taille. Le chiffrement essaie de mélanger les données d’une manière que sans la clé, vous ne pouvez trouver aucun motif du tout dans les données.

Le chiffrement produit une sortie qui parait aléatoire : un fatras de bits avec beaucoup d’entropie (ndt : j’ai causé d’entropie dans un article avec un exemple d’utilisation). La compression ne fonctionne pas vraiment sur des données qui paraissent aléatoires — l’entropie peut alors être vu comme une mesure de la « compressabilité » des données.

Donc si vous chiffrez avant, votre compression ne servira à rien. La réponse doit alors être de compresser avant ! Même StackOverflow le pense.

Vous commencez à dire tout ça à Gary, et vous vous arrêtez au milieu de la phrase. Un attaquant qui sniffe un trafic chiffré ne récupère pas beaucoup d’informations, mais il peut apprendre la longueur des messages. Si ils peuvent utiliser ça d’une manière ou d’une autre pour en apprendre plus à propos du message, peut-être qu’ils peuvent déjouer le chiffrement.

Vous commencez à expliquer à Gary, et il vous interrompt – « Oh, vous voulez dire comme l’attaque CRIME ? »

Vous répondez « Oui ! ». Vous commencez à vous rappeler les détails. Toutes les attaques contre SSL avec des noms accrocheurs sont mélangés dans votre esprit, mais vous être plutôt certain que c’est celle-là. Ils contrôlent une partie de l’information renvoyée par le serveurs, et l’utilise pour générer des suppositions d’un token secret présent dans la réponse. La réponse était compressée d’une manière que vous pouviez valider les suppositions en regardant comment ça modifiait la taille du message compressé. Si le secret était AAAA et que vous aviez supposé AAAA, la réponse compressée-puis-chiffrée était plus courte que si vous aviez supposé BBBB.

Gary parait impressionné. « Mais et si un attaquant ne peut pas contrôler une partie de la réponse d’une aucune manière ? Est-ce que ce genre d’attaque est toujours possible ? », demande-t-il ?

CRIME était une démonstration très cool de pourquoi la méthode « compresser-puis-chiffrer » n’est pas toujours la bonne décision à prendre, mais mon attaque favorite fut publiée un an plus tôt par Andrew M. White, Austin R. Matthews, Kevin Z. Snow, et Fabian Monrose. Le papier « Phonotactic Reconstruction of Encrypted VoIP Conversations » donne une technique pour reconstruire la voix d’un appel VoIP chiffré. (ndt: désolé, j’ai pas trouvé de traduction propre à phonotactic, et dans les lignes qui suivent, ça ne va pas s’arranger).

Basiquement, voila l’idée : la compression VoIP ne va pas être un algorithme de compression audio générique, parce qu’on peut se reposer sur certains postulats sur le langage humain pour compresser plus efficacement. Citation :

Beaucoup de codecs « voix » modernes sont basés sur des variants d’un schéma de codage bien connu comme le « Code-Excited Linear Prediction (CELP), qui à son tour est basé sur un modèle de filtre source de prédiction de langage. Le modèle sépare l’audio en deux signaux : l’excitation du signal source, tel que produit par les cordes vocales, et le signal de forme ou de filtre, qui modélise la mise en forme du son dans l’air. Ceci permet de différencier les phonèmes; par exemple les voyelles ont un signal périodique quand les « sifflantes » (comme les « sh » ou les « f ») ont un signal similaire au bruit blanc.

Dans le CELP basique, le signal d’excitation est modélisé comme une entrée dans un « codebook » fixe (d’où le code-excited »). Dans des variantes de CELP, comme le mode VBR Speex (débit variable), les « codewords » peuvent êtres choisis depuis différents codebooks en fonction de la complexité de la trame d’entrée; chaque codebook contient des entrées de différentes tailles. Le signal filtre est modélisé en utilisant une prédiction linéaire, c’est à dire, comme un codebook adaptatif où les entrées sont choisies en cherchant la place pour des possibles codewords pour optimiser « perceptiblement » le signal de sortie par un procédé dit d’analyse par synthèse. En conséquence une trame encodée consiste en une entrée de codebook fixe et un gain (coefficient) pour le signal d’excitation et les coefficients de prédiction linéaire pour le filtre source.

Enfin, plusieurs fournisseurs de solutions VoIP (Skype inclus) utilisent des codecs à débit variables pour minimiser la bande passante consommée tout en conservant la qualité de l’appel. Dans ce mode, la taille d’une entrée de codebook, et par conséquent la taille de la trame encodée, peut varier en fonction de la trame d’entrée. La spécification pour le Secure RTP n’altère pas la taille de la charge originale; par conséquent les tailles de trames encodées sont préservées tout au long de la chaine d’encodage. La taille du paquet chiffré reflète alors les propriétés du signal d’entrée; c’est exactement la corrélation que notre approche met en avant pour modéliser les phonèmes à partir des longueurs des paquets chiffrés.

Ça résume assez bien le papier. CELP + VBR signifie que la longueur du message dépend de sa complexité, étant donné la façon donc fonctionne la prédictions linéaire, il faut plus d’information pour encoder un changement drastique dans le son — comme les pauses les phonèmes ! Ceci permet aux auteurs de construire un modèle qui peut casser un signal audio chiffré en phonèmes: c’est à dire, décider quels trames audio correspondent à une unité de langage.

Ensuite, ils ont construit un classificateur qui, en utilisant seulement l’information de la taille du paquet avec lequel ils démarrent, décide quelles unités segmentées d’audio chiffré représente en réalité des phonèmes. Ils utilisent ensuite un modèle de langage pour corriger la sortie des étapes précédentes et segmentent le flux de phonèmes en mots puis en phrases.

Le truc fou c’est que tout ce cirque fonctionne ! Ils ont utilisé une échelle appelée METEOR et obtenu des scores autour de 0.6. Sur une échelle où <0.5 est considéré « interprétable par un être humain ». Considérant que le vecteur de menace est ici un humain utilisant cette technique pour espionner vos appels VoIP chiffrés — c’est assez incroyable !

Épilogue

Après avoir passé le test du « vous correspondez à la culture de l’entreprise », vous finissez par avoir le job. Six mois plus tard, Mont Piper est vendu à un large conglomérat. Gary refuse de troquer ses T-Shirts de métal norvégien contre un costard et est sommairement viré. Vous passez maintenant vos journées à vous rendre « sur site » dans une grosse banque, « conseillant » une équipe qui déteste vos tripes.

Mais récemment, vous avez découvert le machine learning et trouvé ce jeu en ligne vraiment cool où vous essayez de faire marcher un robot à 6 pattes dans une simulation 3D de physique…