Billet bixi portant le code 21213

Ça semble bien peu, mais si les codes ne sont utilisables qu’au point de service où ils sont émis, et pour une durée limitée, avec peut-être une détection d’attaque en force brute, on devrais pouvoir dormir tranquille…

Je me suis rappellé une attaque mathémaitque sur des codes de ce genre. Avec une location de 24 heures à 5$, on peut prendre et remettre le vélo plusieurs fois, histoire de tester la théorie… Bonne nouvelle, Bixi n’est pas vulnérable. Mais j’écris quand même la démarche, c’est trop rare qu’on a l’occasion d’utiliser des math pour (tenter de) contourner les règles d’un système.

La vulnérabilité apparais lorsque l’implémentation utilise une fenêtre coulissante pour vérifier les codes entrés. Cette attaque a déjà été utilisée pour dévérouiller une porte de voiture à combinaison.

Pour les Bixi, les chiffres du codes de dévérouillage de vélo peuvent être 1, 2 ou 3. Le dictionnaire des valeurs possibles à une taille k=3. Il faut entrer 5 chiffres, on dit que n=5. Avec ces variables, une fenêtre coulissante fonctionne comme ceci :

1. On entre n chiffres (par exemple 12222)
2. Ce ne sera pas le bon code
3. On entre un chiffre supplémentaire, disons 3
4. Pour accomoder le chiffre supplémentaire, l’implémentation décale les chiffres déjà entrés pour faire de la place. Dans notre exemple, c’est le 1 qui disparaît à gauche à la faveur du 3 à droite.
5. L’implémentation vérifie le nouveau code dans la fenêtre, soit 22223.

On réussi ainsi à tester 2 codes en ne saisissant que 6 chiffres, au lieu de 10. Et ainsi de suite, à chaque fois qu’on ajoute un seul chiffre, on se trouve à tester un nouveau code de 5 chiffres. La première étape ne sert qu’à initialiser le processus, sans affecter la complexité de l’attaque.

C’est une vielle idée. Un mathématicien Hollandais, Nicolaas Govert de Bruijn, a formalisé une séquence de chiffres dans laquelle n’importe quelle séquence de n chiffres n’apparait qu’une seule fois. Autrement dit, si vous générez une séquence de Bruijn avec k=3 et n=5 (les codes Bixi) et que vous y cherchez votre code Bixi, il n’y sera qu’une seule fois. C’est la façon la plus optimale d’attaquer un système de codes comme celui de Bruijn.

Voici la séquence dans l’ordre. Elle se lit de gauche à droite, de haut en bas. 1111121111311…… Le 1111 de la fin de la séquence est en fait les premiers chiffres qui se répêtent.

11111 21111 31112 21112 31113 21113 31121 21121 31122 21122

31123 21123 31131 21131 31132 21132 31133 21133 31212 21212

31213 21213 31221 31222 21222 31223 21223 31231 31232 21232

31233 21233 31313 21313 31322 21322 31323 21323 31332 21332

31333 21333 32222 23222 33223 23223 33232 33233 33311 11

La protection contre cette attaque est heureusement toute simple : à l’étape 2, effacer tous les chiffres et en redemander n autres. C’est ce qu’on fait les designers de Bixi. L’histoire ne dit pas s’ils connaissaient l’attaque, ou s’ils ont été chanceux… Au moins il pourrons dire qu’il m’ont fais marcher et pédaler !

After a few lines in, I realized that I would be less work to order the tests in a way that would minimize the change to the configuration between any two tests. In other words, when a n+1 test case required a change to the registry, then the user group membership should not change, and vice-versa. That would also make it easy to investigate a failed test, because only one thing would change between any two tests.

Then it hit me.

Well actually, I had to stop and think for a while. Kind of like my mind restoring a dusty old tape archive… I remembered that mathematician Richard Hamming had a code for that. It’s a numbering scheme where only 1 bit changes between any two numbers. The number of bits that change is the Hamming distance between two numbers. Using four information bits to represent each possible use case, I came up with the following table. The first two rows (MSB, in blue) are user membership to a group, and the two last rows (LSB, in green) is the presence of that group in the registry. Ordering my tests that way gave me a constant Hamming distance of 1.

The only drawback to this is that all the typing I saved writing my test batch file, I wasted on this blog post !

Many numbers in the linked article are wrong, stick to your calculator for accuracy…

The idea is rather simple, though having thought of it in 1940 is really avant-garde. The Z1 computer was built only a few years before !

If you look on the Internet, you will find many resources showing how to represent a number on your fingers. What was cool was his ability to add, subtract, divide and multiply just by fiddling his fingers. He identified some patterns and he reproduces them at each calculation step, without really knowing what number he is at. When he is done, he just reads the binary number back in decimal for a usable answer.

If you have bc, set obase=2 and give a try. Start by reprenting easy, one-handed 2-bit numbers, like 10, 20 or 24. Then add one bit on your other hand, with numbers like 74, 84 or 88. You should see a pattern right about now…

Come up with a few numbers and represent them on your fingers. Aim for accuracy, not speed. Then start to look for numbers around you: license plates, subway car number, the time or date. You are surrounded by numbers…

I am at the point of trying to do simple operations. Subtracting looks like the easiest one to do. M. Hebert is 86, and he would like for his tricks to survive him. I will try to whip up a tutorial – my laptop was stolen, so all my other projects are on hold.

Until then, I give M. Hébert a 48 (that’s two thumbs up, in binary)