Skip to main content

Chiffrement

Le contexte

Voici quelques temps, j'ai reçu un courriel (dans mes spams) me réclamant une rançon. L'auteur ayant craqué mon mot de passe prétendait "troller" mes comptes (Google, Facebook, ...) si je ne lui versais pas plusieurs milliers de dollars en bitcoin. Mon mot de passe en clair figurait dans le courriel. Hmmm, inquiétant...

Bon, après quelques instants, je me suis rassuré:

  1. Je l'utilise ce mot de passe très simple que sur des sites sans importance
  2. Mes mots de passes Facebook, Gmail, banques, ... sont plus complexes et tous différents entre eux

Mais, comme les récentes affaires de Facebook l'ont démontré, le risque existe néanmoins de se faire craquer un mot de passe important, avec des conséquences fâcheuses. Que faire pour s'en prémunir ?

Certains proposent l'utilisation d'une voûte de mots de passe (password vault); celle-ci étant elle même protégée par un mot de passe, le risque, bien qu'atténué, est toujours présent.

Existe-t-il une meilleure option?

Pour être efficace, un mot de passe doit être:

  • Suffisamment complexe
  • Différents pour chaque site
  • Facile à retrouver en cas d'oubli

Il existe des solutions logicielles pour ça: les Single Sign-On (SSO). J'ai eu l'occasion d'implanter des solutions similaires en entreprise, entre autre Oracle Enterprise Single Sign-On (Oracle ESSO), qui a été vendu également sous le nom Passlogix, puis IBM Tivoli Password Manager. En "modélisant" le comportement du logiciel client (page web, logiciel "lourd", écran de connexion), on instruit ESSO à reconnaître différents objets Windows et à réagir aux demandes d'authentification, erreurs de connexion, expiration de mots de passe, etc... L'ensemble est protégé idéalement par 2 facteurs d'authentification, par exemple un mot de passe général + une carte sans contact. On définit pour chaque logiciel des politiques de complexité (durée de vie, longueur, pourcentage de majuscules, minuscules, chiffres et caractères spéciaux), puis ESSO générera et changera seul les nouveaux mots de passe dans les applications modélisées; plus personne ne connaîtra alors le mot de passe "en clair". L'ensemble requiert un ou plusieurs dépôts centralisés et encryptés (annuaire, base de donnée,...), un dépôt local sur chaque poste succeptible d'être utilisés par un utilisateur donné, et un mécanisme de synchronisation entre tous les dépôts. C'est performant, efficace, puissant, mais ce sont des solutions d'entreprise complexes, onéreuses et peu adaptées aux particuliers.

Et ça ne fonctionne que sous Windows!

La solution

Notons que certains sites utilisent le principe de délégation d'authentification: on voit ça souvent quand un site donné (ex: Soundcloud) demande d'utiliser un compte Google ou Facebook pour se connecter. J'ai une confiance limitée dans ce principe...

J'ai alors pensé à une approche différente: générer des mots de passe complexe en mélangeant deux chaînes de caractères, une "clef" secrète et le nom du site. J'utilise une clef identique pour tous les sites similaires (réseaux sociaux, sites musicaux, sites banquaires,...). La clef est mélangée avec le nom du site par des opérations logiques, le tout formant une graine unique (seed) pour un générateur pseudo-aléatoire de mot de passe complexe, impossible à deviner, mais simple à regénérer grâce à une petite application javascript figurant sur ma page perso.

Cette approche a plusieurs avantages:

  1. Simple.
  2. Aucun dépôt centralisé succeptible d'être corrompu.
  3. Utilisable de n'importe où.
  4. Mots de passe complexes impossible à deviner.
  5. Aucune vérification du résultat: quelqu'un utilisant mon site en "brute force" n'obtiendrait que des chaînes, sans pouvoir déterminer si celles-ci sont exactes ou non.
  6. Exécution locale; aucun transfert de la clef sur le réseau.

Version 1

Ma première version était un simple intercalage des lettres; facile à faire manuellement, mais peu sécuritaire.

Version 2

Ma seconde version consistait à parcourir chaque chaîne lettre par lettre, prendre le code ASCII de chaque lettre et les ajouter entre eux, en faire le modulo 93 puis ajouter 33 pour générer un résultat compris entre 33 (code ASCII du "!") et 126 (code ASCII du "~"). Mécanisme certe plus évolué et non linéaire (à cause du modulo), mais j'ai trouvé des cas où le mot de passe créé était refusé: caractères spéciaux interdis, ou deux caractères consécutifs identiques. De plus, en utilisant deux chaînes identiques (par exemple "aaaaa"), on pouvait relativement facilement déduire le mécanisme sous jacent.

Version 3

J'ai finalement abouti à la version actuelle qui utilise un générateur de nombres pseudo-aléatoire (PRNG) dont la graine est formée par le mécanisme expliqué précédemment. Cette version permet de spécifier la longueur et des options (caractères interdits et autorisés, répétition). Grâce au PRNG, les mêmes chaînes de départ créront un résultat identique.

Enfin, j'ai également créé une version API qui me permet d'appeler l'algorithme à partir d'une autre application, par exemple Excel.

http://(...)/chiffrement-api.html?c1?c2?ln?uc?lc?dg?sp?rp

Les paramètres sont les suivants:

  • c1: chaîne 1 (obligatoire)
  • c2: chaîne 2 (obligatoire)
  • ln: longueur du mot de passe à générer (22 par défaut)
  • uc: nombre de majuscules (0, 1, >1=autant que nécessaire - valeur par défaut)
  • lc: nombre de minuscules ( idem )
  • dg: nombre de chiffres ( idem )
  • sc: nombre de caractères spéciaux ( idem )
  • rp: autoriser les répétitions (0=non, >0=oui)

Pour appeller cette API à partir d'Excel, si A1 et B1 contiennent ma clef et le nom du site, je mets la formule suivante dans I1

 =WEBSERVICE("http://(...)/chiffrement-api.html?"&A1&"?"&B1"?"&C1&"?"&D1&"?"&E1&"?"&F1&"?"&G1&"?"&H1&"") 

Version 4

Les versions précédentes avaient 2 soucis majeurs: les permutations de caractères dans les chaînes n'étaient pas gérées (autrement dit "abc" et "bac" donnaient le même résultat), et toute la saisie se faisant au clavier, l'ensemble est sensible au keylogger ou au sniffage du Bluetooth (que je n'utilise pas pour cette raison précise, l'encryption de Bluetooth étant notoirement faible).

J'ai donc abouti à une version plus évoluée, qui ajoute un clavier virtuel (comme les banques) et une signature MD5 des chaînes avant la génération de la graine.

Comments

Tony Keys said…
Hi Francios

You sent me a message regarding the DMT8 and Eproms if you remember. I managed to get a copy of the ROMS from FOSTEX in the end and replaced the originals with the updated versions.
I also tried to upgrade to Flash drive and all sorts of other SSD's using adapters and even hard wiring but also had no sucess and was receiving same messages as you. I ended up putting a 2.5 inch IDE 40gb Hard drive which works perfectly. (but would have preferred Flash or SSD)
It's nice to know that others are still using this great recorder. Maybe we'll speak again in the future.

Take care
Kind Regards
Tony
Hi Tony,
thanks for your update, really appreciated.
I'll probably manage to get a 2.5" HD as well, as they are usually less noisy than 3.5".
What does the new ROM update bring to the unit?

Best Regards,
François

Popular posts from this blog

Drive replacement for Fostex DMT8-vl

The IDE hard drive on my Fostex DMT8-vl multitrack recorder shows signs of its imminent death; when getting hot, I could not record anymore. Must be said this drive comes from an old Sun Station, and has been replaced because I/O failures were detected by Solaris. It worked at least 5 years in my recorder: not so bad. However, time is now to replace it. The DMT8-vl is not able to handle drives bigger than 8.4 GB. Well, it is able to (the current drive is 15 GB), but only 8.4 GB will be usable. My tought was to use a 8 GB CompactFlash; having no moving parts means no noise, which is quite temptating for a music recording device. I purchased a CompactFlash-IDE adapter on the internet (8$) and I had to build a male-male IDE cable adapter (4$). Unfortunately, this doesn't work. The drive is correctly discovered by the operating system, which proposes to format it ("format IDE?"). After answering "yes", the formating runs pretty fast (faster than on a real drive), ...

Samba: Clients get "system error 1223" (or 123) after a server reboot

Facts: a Linux+Samba server shares anonymously a folder. After a reboot, Win clients could not attach the share drive anymore. C:\>net use \\mylinux\folder Enter the user name for 'mylinux': System error 1223 has occurred. The operation was canceled by the user. C:\>net view \\mylinux\ System error 123 has occurred. The filename, directory name, or volume label syntax is incorrect. The process are present, and tcpdump doesn't provide much information. What's going on? After hours of headscratching, the light came: the firewall was on and no rules for the Samba protocol! Grrr!

Issue with Soundpool MO4

I have a Atari STe with a Soundpool MO4 MIDI extension. It used to work very well, but unfortunatelly doesn't anymore: Cubase still detects it, and I can output MIDI to it but nothing is coming out from any MIDI Out. It took me a while to tackle it (lack of time, lack of tool, other items to play with), but I gave a glance last week-end. The parallel port on the Atari uses only the following signals: Pin 1 : Strobe (Atari -> MO4) Pin 2 : Data 0 (Atari -> MO4) Pin 3 : Data 1 (Atari -> MO4) Pin 4 : Data 2 (Atari -> MO4) Pin 5 : Data 3 (Atari -> MO4) Pin 6 : Data 4 (Atari -> MO4) Pin 7 : Data 5 (Atari -> MO4) Pin 8 : Data 6 (Atari -> MO4) Pin 9 : Data 7 (Atari -> MO4) Pin 11: Busy (MO4 -> Atari) The MO4 also decodes few other pins, but since the Atari doesn't, my guess is the MO4 was also targeted for PC. Inside the box, the MO4 is architectured around a CPLD (IspLSI1016 from Lattice) which contains the logi...