Il y a quelques jours, j’ai eu la bonne surprise de voir ma demande a la beta de Let’s Encrypt être acceptée. A moi l’argent, la gloire et la crypto !

letsencrypt
Pour rappel, letsencrypt est une autorité de certification (CA) qui ne demande aucune validation humaine de leur part. Pas d’envoie de papiers d’identité ou autre preuves. Pour prouver que vous etes bien possesseur du domaine, il suffit que, lors de la génération du certificat, vous placiez un fichier json accessible a une url « mondomaine.com/.well-known/… ».

La procédure de génération est donnée (et risque d’évoluer d’ici la fin de la beta) mais en résumé:

Make sure your web server displays the following content at                                                                                           
http://mart-e.be/.well-known/acme-challenge/abcdef... before continuing:

{"header": ...}

Content-Type header MUST be set to application/jose+json.

If you don't have HTTP server configured, you can run the following
command on the target server (as root):

mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
cd /tmp/letsencrypt/public_html
echo -n '{"header": ...}' > .well-known/acme-challenge/abcdef...
# run only once per server:
$(command -v python2 || command -v python2.7 || command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map = {'': 'application/jose+json'}; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()"
Press ENTER to continue

Super, seulement wordpress ne me laisse pas créer des dossiers arbitraires dans mon dossier contenant le code (et c’est une bonne nouvelle en soit). Pour résoudre cela, un petit bricolage nginx s’imposait.

HTTPS sur un blog, c'est comme un éléphant-mitrailleuse. Ça ne sert pas a grand chose mais c'est cool!

HTTPS sur un blog, c’est comme un éléphant-mitrailleuse. Ça ne sert pas a grand chose mais c’est cool!


Dans la config nginx du blog, ajoutez un bloc location:

Mise à jour: Michel propose une solution plus simple sans s’ennuyer avec un serveur local en python!

server {
       listen 80;
       server_name mart-e.be;
       location ~ /.well-known {
            proxy_pass  http://127.0.0.1:7890;
       }
       
       # reste de la config pour wordpress
}

Où 7890 est un numero de port totalement arbitraire.
Ensuite, suivant +/- les conseils du wizard de letsencrypt

$ mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
$ cd /tmp/letsencrypt/public_html
$ echo -n '{"header":...}  > .well-known/acme-challenge/abcdef...
$ python -c "import BaseHTTPServer, SimpleHTTPServer; SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map = {'': 'application/jose+json'}; s = BaseHTTPServer.HTTPServer(('', 7890), SimpleHTTPServer.SimpleHTTPRequestHandler); s.serve_forever()"

Notez que j’ai changé le numéro de port de 80 a 7890 dans les paramètres de HTTPServer.

On relance NGINX (nginx -s reload), continue l’exécution du wizard (press ENTER) et victoire !

Press ENTER to continue

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/mart-e.be/fullchain.pem. Your cert will
   expire on 2016-01-26. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.

Vous pouvez tuer la commande python une fois validé et retirer la config nginx (ou commentez, le certificat beta ne vaut que 90 jours).

En bonus, la config nginx qui va bien:

ssl_certificate /etc/letsencrypt/live/mart-e.be/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mart-e.be/privkey.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
ssl_protocols TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparams.pem;

Avec le fichier dhparams.pem servant à la génération d’une clef diffie-helman, via la commande openssl dhparam -out dhparam.pem 2048

Mozilla a un super générateur de config. J’ai prit la config moderne, désolé utilisateurs de vieux soft, je décroche ainsi un beau A sur le CryptCheck un peu nazi de Aeris !

CrptCheck

Vous pouvez maintenant accéder a mart-e.be en https !

En ses temps de mesures sécuritaires, j’ai voulu également augmenter ma propre protection. Comme tout le monde j’ai des choses à cacher et l’utilisation d’un VPN chiffré devient une nécessité. Pour corser l’expérience, j’ai voulu payer en Bitcoin. Je précise que je n’ai jamais acheté ni l’un ni l’autre. Ce n’était pas de tout repos.

William Clinton and President Boris Nikolayevich Yeltsin

– J’arrive pas, dis le toi!
– Nous ne procédons pas à d’écoutes massives de la population et respectons votre vie p…

1. trouver un provider VPN
3 jours à parcourir les comparateurs foireux ou juste demander (plus efficace). Je choisi finalement cryptostorm. Une société tenu des hacktivistes basés en Islande, un peu bordélique (il faut aimer fouiller les forums), pas trop cher (3-4$/mois), utilisant token anonymes assez original (en gros on achète des tokens à eux ou revendeurs indépendant, pas besoin de compte) et possibilité de payer en Bitcoin, Doguecoin & co.

Je parlerai probablement de Cryptostorm après quelques semaines/mois de tests mais j’avoue être assez fan jusqu’à présent.

2. trouver un revendeur Bitcoin
2 jours de comparateurs. J’avais tenté une fois bitstamp avant d’avoir ma transaction refusée par ma banque. Cette fois, j’ai essayé avec Kraken, pas trop de frais, clean, sécurisé (2 factors, ils envoient des emails signés avec GPG…. refusés par enigmail).

3. acheter des bitcoin
4 jours pour se rendre compte qu’on ne peut pas faire de virement, donner son nom et date de naissance pour passer en tier 2 (level up!), se rendre compte qu’on ne peut toujours pas déposer d’euro, donner son adresse pour passer en tier 3, faire un virement SEPA (50€ min), attendre qu’il soit réceptionné, se prendre déjà pour un tradeur, lire des articles de trading, abandonner l’idée, acheter quelques bitcoin à 213€/BTC sans savoir si c’est un bon prix.

femme assemblant un ordinateur

1975, un des premiers prototypes d’Asic Miner

4. réceptionner les bitcoins
2 jours à chercher un client bitcoin, pleurer en comprenant qu’il me faut 33GB d’espace disque pour stocker la blockchain, se faire conseiller sur twitter d’utiliser Multibit, découvrir vanitygen, perdre une journée pour avoir une adresse toujours aussi immémorable mais commençant par « 1marte », stresser comme un fou de perdre sa tune, se rendre compte qu’en fait c’est rapide et facile.

5. acheter l’accès VPN
2 jours à payer sur bitpay, se dire que mettre mon adresse email perso n’est pas la chose la plus intelligente, attendre, vérifier toutes les 5 minutes sa boite mail, aller consulter les logs de son serveur mail, se dire qu’on a probablement foiré un truc, installer Bitmessage pour contacter le support de cryptostorm, ne pas recevoir de réponse, se dire qu’en fin de compte Twitter c’est aussi un bon moyen de communication, recevoir une réponse d’excuse comme quoi ils étaient occupé à gérer SauronsEye (un méga-malware bien flippant), recevoir un token de 3 mois au lieu de 2 pour s’excuser, les pardonner.

6. se connecter au VPN
5 minutes à choper un fichier de config au choix (il y a une dizaine de points de sortie), utiliser le sha512 du token comme nom d’utilisateur sur OpenVPN (en ligne de commande, le client de NetworkManager me donne plus de fil à retordre), aller sur IPleak pour voir que je ne laisse rien filtrer, se rendre compte que je peux maintenant résoudre les URLs .i2p et .bit avec leurs DNS, retourner voir des gifs sur reddit.

Police dog

On the internet, nobody knows you are a dog…

Que retenir de tout ça ? Que cela m’a prit un temps assez délirant, principalement passé à faire des recherches (et heureusement, ça ira plus vite la prochaine fois). Il existe des tonnes d’alternatives pour chaque point (et je n’ai surement pas choisi les meilleures ou les plus faciles). C’est une très bonne chose d’avoir le choix mais ça noie le néophyte, il faut sacrément être motivé pour se protéger aujourd’hui.

Je précise aussi que si j’ai fais cela pour des raisons de sécurité, je suis bien conscient de pas être anonyme, on peut probablement me retracer à mes bitcoin ou achat du VPN, ce n’était pas le but (mais ça serait un beau challenge pour une prochaine fois).

On en reparle dans quelques semaines pour faire le point sur Cryptostorm.

Dans mon article précédent C’est décidé, je retourne sous Linux, je me moquais gentiment sur le Windows livré sur mon nouveau pc (un Dell Vostro 3360, comme ça vous saurez tout). Après tant d’amusement trollesque, j’ai voulu installer un système Archlinux aux petits oignons qui me convenait. Comme je trouve que la ligne de commande reste le moyen le plus efficace et rapide de faire du peaufinage de système, on va en bouffer ! La procédure ci-dessous explique comment obtenir une installation d’Archlinux dans un conteneur LVM chiffré avec dm-crypt et LUKS (système et SWAP) avec l’activation de TRIM pour SSD et une utilisation de Enlightenment E17 comme windows manager.

Kwa ? G rien compri !

Voici ce dont on parle :

  • Archlinux : mon coup de coeur dans les distributions de linux, les explications devraient pouvoir être adaptable à d’autres systèmes tant que vous avez un terminal à disposition.
  • LVM : méthode de gestion de partitions non continues. On peut ajouter, supprimer, modifier les partitions un peu comme on veut, plus besoin de rester 3h devant GParted en priant le dieu Bécup.
  • LUKS : norme de chiffrement par blocs, idéal sous linux pour chiffrer une partition (en opposition à par exemple à eCryptfs qui sert à chiffrer un dossier comme le propose Ubuntu avec le dossier home)
  • dm-crypt : sous-système permettant de gérer le chiffrement LUKS (où se trouvent les clefs…) utilisé par le noyau Linux. Propose notamment cryptsetup que l’on utilise ici.
  • SSD : nouvelle génération de disques remplaçant les vieux HDD. Plus rapides, silencieux, économes en énergie et surtout plus chers. Mon Vostro est équipé d’un SSD de 128GB (pas de HDD en hybride)
  • TRIM : sur un HDD, lorsque l’on écrit là où se trouvaient des données « supprimées », on écrase l’ancienne valeur par la nouvelle. Avec un SSD, on doit d’abord supprimer le contenu du secteur puis écrire la nouvelle (perte de performances). TRIM permet d’indiquer au système lorsque l’on n’a plus besoin de certaines données, l’autorise à les supprimer et l’on gagner du temps pour la future réécriture. Une sorte de garbage collector. De par son mode de fonctionnement, TRIM rend aussi inefficace toute tentative de récupération de données en cas de rm mal placé.
  • SWAP : espace du disque dédié à soulager la RAM lorsque celle-ci se retrouve surchargée. Il est nécessaire de la chiffrer pour éviter les fuites d’information (des mots de passe pouvant être chargé dans la RAM).
  • E17 : window manager léger et hyper personnalisable (*tousse*opposé de GNOME*tousse*). Une version stable vient de sortir après 12 ans de développement. Au passage ne venez pas m’ennuyez sur le window manager vs desktop environment, on met un peu n’importe quoi dans les deux catégories et puis c’est moi qui décide ici, na !

Voici une image permettant de mieux comprendre ce que l’on va réaliser :

luks-graph

Le /boot est sur une petite partition séparée (on a besoin d’un certain nombre de modules pour déchiffrer la partition), le reste du système se trouvant dans une partition chiffrée. En déchiffrant cette partition, on ouvre un conteneur LVM. Cela permet d’avoir toutes les partitions chiffrées avec la même clef. Si l’on voulait chiffrer une seule partition (ou plusieurs avec des clefs différentes), l’on aurait fait le contraire (LUKS dans LVM). Dans mon cas, n’ayant qu’Archlinux sur un petit disque, j’ai préféré utiliser uniquement une SWAP et une partition pour le système. Libre à vous de diviser le conteur LVM en plus de parties pour un home séparé ou pour du multiboot.

La manipulation va donc permettre de chiffrer sa machine, cela ne rendra pas la machine invisible contre tout types d’attaque. Les implications exactes en termes de sécurité sont mentionnées dans la conclusion, lisez là bien avant de commencer toute manipulation si vous n’êtes pas certains de bien comprendre.

Préparation

Attention, cette procédure va écraser lamentablement vos précédentes données tel le scarabée rhumatisant sous la patte du vaillant hippopotame. Si vous voulez conserver une copie de votre disque, je vous conseille de suivre cette procédure. Suumitsu a donné une procédure permettant de convertir un disque en machine virtuelle. J’ai testé mais perso la machine virtuelle ne fonctionne pas chez moi (récup système qui échoue).

Créez un live CD ou USB, démarrez dessus jusqu’à obtenir un terminal utilisable (je passe cette étape, pour arch c’est ici que ça se passe, jusqu’au 2.2). Fait ? Maintenant on efface le tout. D’abord on met de l’aléatoire pour maximiser la sécurité (on ne peut pas différencier les données aléatoires des données chiffrées). Note : l’activation de TRIM réduit l’intérêt de cette manipulation, lisez la dernière section sur les limites pour vous faire une opinion. Si vous jugez cela inutile, passez cette étape (je la laisse sans être certain à 100% de ce que j’avance). Si vous avez un HDD, faites le.

$ dd if=/dev/urandom of=/dev/sda

Ouille pauvre disque, ça prend du temps (6 MB/s sur mon disque de 128GB, soit 6 heures, glups). C’est pas le mode le plus parano du monde mais ça suffit. Faire plusieurs réécritures a été montré comme superflu. En parlant de suppression efficace, n’utilisez pas non plus des outils comme shred en pensant bien effacer vos fichiers, c’est inefficace sur un SSD.

Partitions

On crée ensuite une nouvelle table de partition. J’ai utilisé cfdisk, c’est très facile et interactif, même pas besoin de lire la man page pour comprendre. Les partitions sont à définir selon vos gouts mais comme je vous le disais plus haut, je vais uniquement séparer /boot du reste. 200MB pour /boot sur sda1, le reste sur sda2.

# cfisk /dev/sda
# mkfs.ext4 /dev/sda1 -L boot # EXT4 est bien mais c’est un choix personnel après

Pour chiffrer sda2, on a plusieurs choix d’algorithmes, de modes de stockage de clef, etc. On peut par exemple utiliser une suite de bytes aléatoires qui sont stockés sur une clefs USB chiffrée avec GPG (not bad). Mais nous, on ne vise pas la top sécurité (trop contraignant je trouve), on va faire au plus simple : un mot de passe à entrer au boot. Lisez la man page ou ce wiki pour des variations. (désolé pour cet idiot de wordpress qui me remplace les doubles tiret par un caractère spécial)

# cryptsetup –cipher aes-cbc-essiv:256 –key-size 256 –hash sha256 –iter-time 1000 –use-random –verify-passphrase luksFormat /dev/sda2

On choisi un super mot de passe (que vous irez écrire sur un post-it collé à l’écran) et on confirme (n’oubliez pas les majuscules pour le « yes »).

Pour ouvrir le conteneur, on utilise la commande suivante (très important, c’est cette commande que vous allez utiliser si jamais vous crachez votre système et devez faire la réparation avec un live cd, notez la aussi sur le post-it) :

# cryptsetup luksOpen /dev/sda2 sda2_crypt

La partition est maintenant accessible à /dev/mapper/sda2_crypt (vous pouvez évidement choisir un autre nom).

La partition sda2_crypt va être convertie en Primary Volume LVM contenant la swap et /. Je conseille encore une fois la doc archlinux pour les variations mais dans mon cas :

# modprobe dm-mod
# pvcreate /dev/mapper/sda2_crypt
# vgcreate MyGroup /dev/mapper/sda2_crypt
# lvcreate -C y -L 1G MyGroup -n lvswap
# lvcreate -l +100%FREE MyGroup -n lvarch
# mkswap /dev/mapper/MyGroup-lvswap
# mkfs.ext4 /dev/mapper/MyGroup-lvarch -L arch
squelette à un bar

Kevin attend patiemment que son algorithme de brute force trouve votre clef LUKS

Installation

Maintenant on peut continuer normalement l’installation comme n’importe quel système. Dans le cas d’Archlinux avec arch-chroot, il faut d’abord monter les partitions dans /mnt.

# mount /dev/mapper/MyGroup-lvarch /mnt
# swapon /dev/mapper/MyGroup-lvswap
# mkdir /mnt/boot
# mount /dev/sda1 /mnt/boot

Dans le beginner’s guide d’archlinux, on peut reprendre au point 2.6. select a mirror. Les partitions montées étant déchiffrées, la génération du fichier fstab devrait donner les bons UUID.

Dans le cas de mon Dell Vostro 3360, le wifi était reconnu nativement mais pas ethernet, la faute à l’Atheros AR8161. J’ai expliqué la marche à suivre mais à ce jour (à adapter à sa version du noyau, deviendra compat-driver dès linux 3.7), les commandes sont :

# wget http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.6/compat-wireless-3.6.8-1-snpc.tar.bz2
# tar xjf compat-wireless-3.6.8-1-snpc.tar.bz2
# cd compat-wireless-3.6.8-1-snpc
# ./scripts/driver-select alx
# make
# make install
# modprobe alx

Avant que vous ne redémarriez, il faut faire quelques modifications pour activer le déchiffrement et TRIM. Dans le fichier /etc/mkinitcpio.conf, on défini les modules à charger dans le noyau au démarrage. Voici ce qu’il faut dans notre cas :

MODULES="... sd_mod .."
...
HOOKS="... keymap encrypt lvm2 resume filesystems ..."

sd_mod étant pour LVM, keymap pour charger la disposition du clavier que vous aurez spécifié dans /etc/vconsole.conf (attention, si pas présente, vous devrez déchiffrer votre partition en qwerty), encrypt pour LUKS, LVM2 pour LVM (inattendu je sais), resume pour sortir de l’hibernation et tout cela devant se trouver avant filesystems. Vous pouvez également faire un nettoyage ici en supprimant et déplaçant quelques modules. Je ne suis pas spécialiste de cette partie donc ne vais pas trop m’aventurer là dedans de peur de dire des conneries. Si ça vous intéresse Postblue en donne quelques unes (des optimisations, pas des conneries).

On régénère l’image à charger avec :

# mkinitcpio -p linux

(ou autres paramètres en cas de noyau différent ou optimisation)

Pour indiquer à GRUB la marche à suivre, on va modifier le fichier /etc/default/grub à la ligne GRUB_CMDLINE_LINUX pour mettre :

GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:sda2_crypt:allow-discards resume=/dev/mapper/MyGroup-lvswap pcie_aspm=force elevator=noop"

N’oubliez pas de regénérer un nouveau fichier grub.cfg avec grub-mkconfig. Le allow-discards permettant d’activer TRIM. On va d’ailleurs également modifier le fichier /etc/fstab qui chez moi ressemble à ça :

# /dev/mapper/MyGroup-lvarch LABEL=arch
UUID=8f42... / ext4 defaults,noatime,nodiratime,discard 0 1

# /dev/sda1 LABEL=boot
UUID=dd30... /boot ext4 rw,relatime,data=ordered 0 2

# /dev/mapper/MyGroup-lvswap
UUID=2142... none swap defaults,noatime,nodiratime,discard 0 0

J’avoue ne pas être certain à 100% des paramètres en dehors du discard, les nomachin permettant de réduire le nombre d’écriture nécessaire (mais peut poser des problèmes dans certains cas de figure). Lisez SSD Tuning For Linux ou Archlinux SSD pour plus d’info.

Démarrage et E17

J’ai choisi d’installer E17 comme environnement de bureau. C’est très léger et très personnalisable. Tellement personnalisable que je n’ai pas encore réussi à l’adapter complètement à mes envies mais je suis sur que ça arrivera (j’ai commencé à mettre une série d’astuces ici). Voila à quoi ça ressemble chez moi après installation.

bureau-e17

Sobre et léger, moi j’aime ( fond d’écran)

Il suffit d’installer le paquet enlightenment17 pour obtenir le bureau ainsi que tous vos programmes favoris et légers pour les tâches voulues (connman pour la gestion du wifi, mirage pour les images, 7-zip pour les archives… à vous de voir). Comme pour n’importe quel environnement de bureau en somme.

Là par contre où une modification devient intéressante est la connexion automatique. Si l’on chiffre le disque, l’intérêt de demander le mot de passe de l’utilisateur directement après est diminué. L’optimisation vient de chez postblue qui la tient du wiki Archlinux. Connexion automatique sur votre utilisateur qui va lancer Enlightenment avec un exec enlightenment_start dans le fichier ~/.xinitrc.

Grâce à ces optimisations, sur mon Vostro, une fois le mot de passe LUKS entré, j’ai besoin de 3 secondes pour être sur un bureau prêt à l’utilisation, c’est moins que ce qu’il me fallait pour sortir d’hibernation sur mon ancienne machine !

Vérification TRIM

Alors là, pour être honnête, j’ai une incertitude. Cela a été le sujet d’une discussion sur les forums Archlinux (ici) sans arriver à de solution convenant tout le monde. De nombreux sites affirment que le flag « allow-discards » suffit à activer TRIM. On peut le vérifier ainsi :

# dmsetup table /dev/mapper/sda2_crypt –showkeys
0 249583634 crypt aes-cbc-essiv:sha256 f7[… ]95 0 8:2 4096 1 allow_discards

Si on leur fait confiance (ce que j’ai envie de faire), cela devrait suffire.

Seulement « discard » indique que l’on active TRIM, pas que TRIM fonctionne (vous voyez la subtilité ?). Un test un peu plus sophistiqué est donné ici. Cela consiste en la création d’un fichier, regarder où il se trouve en mémoire, le supprimer et vérifier que le registre a bien été vidé (les commandes sont dans le lien). Cependant lors du test, je découvre que les secteurs en questions sont vides avant d’avoir supprimé le fichier.

Avec un peu de recherche, j’ai trouvé ce blog donnant une piste de réponse. Il faudrait en réalité faire une addition sur l’alignement des partitions pour obtenir la bonne valeur. J’ai réalisé l’exercice ici avec un résultat différent mais tout autant décevant : une série de bytes aléatoires dans le secteur calculé mais pas supprimés à la suppression du fichier. Erreur de calcul ? Non activation de TRIM ? Problème avec la couche d’abstraction LUKS+LVM ? Mystère. Si quelqu’un a plus d’idées, je suis sur que ça en intéressera certains.

Conclusion et limites du chiffrement

La sécurité obtenue n’est pas absolue mais est déjà très raisonnable. Chiffrer votre disque ne vous protègera pas complètement. Il n’y a pas de problèmes si vous perdez votre machine hors ligne (pas de logiciels types Prey donc, pas grave, je préfère) mais il existe des cas plus problématiques. Le fait d’entrer votre mot de passe signifie qu’un attaquant ayant accès à votre PC est potentiellement capable de modifier vos fichiers de boot pour y ajouter un keylogger par exemple. Le cas de la clef sur une clef USB diminue un peu ce risque mais est assez contraignant (à vous de voir votre besoin de sécurité).

L’activation de TRIM réduit également la sécurité. Lisez cet article par un développeur de cryptsetup pour comprendre le problème. En autorisant le système à vider tous les secteurs inutilisés, l’on va permettre la détection des secteurs utilisés et ceux qui ne le sont pas. C’est pour cela que j’affirmais plus haut que le remplissage du disque de random était sans doute inutile. Cela ne me pose pas de problème pour mon utilisation de la machine mais il faut le savoir.

Une fois la partition déchiffrée, LUKS ne sert plus à rien évidement. Le chiffrement ne vous protègera pas contre les failles de sécurité dans vos logiciels. Il est par exemple important de verrouiller votre machine en veille. Il n’est pas à ma connaissance possible d’accéder au contenu d’une machine verrouillée sans faire d’attaque physique (contenu de la RAM par ex), vous devriez donc être à l’abri des script-kiddies si vous n’avez pas laissé de failles grosse comme une maison (si vous voulez vous protégez contre des gouvernements, pensez qu’ils possèdent d’autres moyens d’obtenir les clefs que de pirater votre machine).

Au passage, je conseille vivement de ne pas choisir le même mot de passe pour LUKS et votre utilisateur. Il est beaucoup plus facile d’avoir un keylogger ou d’accéder aux hash de votre mot de passe lorsque votre machine fonctionne.

Bonus : détectez les modifications de /boot

Je disais plus haut que le problème sécurité le plus préoccupant avec cette configuration était qu’une manipulation offline pouvait tout foutre en l’air. Si l’attaquant arrive à bidouiller les fichiers dans /boot, il peut faire beaucoup ; même une clef présente sur une clef USB peut se faire enregistrer avec un script malveillant. Heureusement, une publication dans ct-magazine donne une solution : vérifier le hash du MBR et des fichiers une fois la partition déchiffrée (les hash sont chiffrés évidement). Si une modification est détectée, grosse alerte !

Téléchargez l’archive suivante 1203-146.zip par l’auteur de l’article ou ma version qui utilise sha256 plutôt que sha1 (qui, si toujours sécurisé aujourd’hui, risque de ne plus l’être très longtemps, surtout depuis cette nouvelle attaque), ajoute le fichier de config systemd, enlève un espace au début de chkboot.sh (plantait le lancement de systemd) et ajoute un fichier .desktop pour chkbook_user.sh. Si je suis pas trop sympa quand même !

# cp chkboot.sh /usr/local/bin/chkboot.sh
# chmod +x /usr/local/bin/chkboot.sh
# cp chkboot_user.sh /usr/local/bin/chkboot_user.sh
# chmod +x /usr/local/bin/chkboot_user.sh
# cp chkboot@.service /etc/systemd/system/chkboot@.service
# systemctl enable chkboot@.service
# mkdir /var/chkboot
# /usr/local/bin/chkboot.sh

Le script chkboot_user.sh utilise zenity pour les alertes. Veillez à ce qu’il soit installé. Démarrez ce script au démarrage de votre session. Cela peut se faire via l’interface graphique de window manager préféré ou en ajoutant un fichier .desktop (comme celui dans l’archive que je vous donne par exemple) dans le dossier ~/.config/autostart/. Dans le cas de E17, le dossier autostart n’est pas utilisé (juste pour GNOME, KDE et XFCE). À la place, placez le fichier .desktop dans ~/.local/share/applications/ et allez ensuite dans settings > apps > startup applications >
applications
et activez l’application Chkboot.

alert-changes-detected-boot

Avec la liste des fichiers ayant changé de hash

Attention, le script chkboot.sh est à faire tourner à chaque modification du dossier /boot. Cela peut arriver souvent sous Archlinux (à chaque mise à jour du noyau ou de grub par exemple). Si vous trouvez cela trop contraignant, n’hésitez pas créer un alias type alias sysupdate="/usr/local/bin/chkboot_user.sh && yaourt -Syua && /usr/local/bin/chkboot.sh".

PS : j’ai commencé la rédaction de la page en français au sujet de LUKS sur le wiki archlinux.fr. N’hésitez pas à venir contribuer, c’est encore bien vide.

Mise à jour: le script a été mit à jour, les possibilités et commandes ont légèrement changé, lisez le README pour plus de détail ou suivez mes annonces avec le tag smailarchiver.

Faisant un peu le nettoyage dans mes boites à emails, j’ai voulu sauver tous mes vieux messages avant suppression. Cependant, je voulais un moyen de faire cela de manière automatisée (possible d’utiliser cron), incrémental (ne pas tout retélécharger à chaque fois), supportant la compression et surtout garder une certaine confidentialité (chiffrement).

J’ai trouvé des bouts de codes pour faire chaque partie séparément (ici et ici par exemple) mais pas de programme permettant de faire tout cela ensemble. A que cela ne tienne, j’ai donc créé un petit script python contentant mes besoins. Ainsi est né SMailArchiver (avec S pour Secured ou Suicide, question de point de vue) que je partage ici.

Ce petit bout de code (approchant des 400 lignes de python) permet facilement de faire des backup de plusieurs comptes emails avec toute une série d’option comme la compression des mails avant le chiffrement (une compression après le chiffrement pourrait également être utile mais est moins efficace) ou le choix d’une clef constituée uniquement de bytes aléatoires ou renforcée par un mot de passe de votre choix. Le chiffrement se fait avec AES 256 avec une signature HMAC-SHA256 histoire d’empêcher les manipulations. C’est pas Truecrypt mais ça suffit pour cacher les conversations avec votre maitresse des yeux indiscrets de madame votre femme (ou inversement).

big mess

Avant d’utiliser SMailArchiver, ma gestion des emails ressemblait à ça… et mes cheveux étaient secs et cassants.

Le programme peut recevoir les paramètres nécessaires par la console, via des arguments ou via un fichier de config (regardez le fichier d’exemple dans le dépot).

$ python smailarchiver.py 
Enter your email username: foo@bar.com
Enter your imap server: imap.bar.com
Enter your password: 
Enc key: 6MIiWqNiJ4h1qDmp5Z4OpWKRLst7eAbirWOPHIm9zqk=
Sig key: 9JmR0593CWwtnJhRWqdLHk7tXvX/h6l6A2GLKA4iVq4=
$ python smailarchiver.py --user foo@bar.com --imap imap.bar.com --passwd monkey1 --key foo@bar.com.keys --promp --compress
Enter your encryption/signature password: 
Enc salt: KNwhv7kuNs0/iCZZTUyd05IuOylzG/n2oBALj1UMJ0c=
Sig salt: A99CxfzwRbU4P4lse6eN5O+g2wethRzL4gMH7xqFkgE=
Hash: oNcX7GAyHsS+bNOT8UCYAYM/ltCmx34E9Gmmpky02AE=
$ python2 smailarchiver.py -c config.json
Enter your encryption/signature password: 
Enc salt: m87TeE9fmr5XPf7yvN0w3PYOv3ivlNKpKGp35hC+N/k=
Sig salt: 2k9Wu5HBEo7G0J0EzlglOqV0Zko1LmhfiGnxD2QEzhE=
Hash: FA3TdkhWNZqy9BjGOk2UVZ6AeqgHSrparH3ynHdvj38=
$ python2 smailarchiver.py --decrypt foo@bar.com/ --key foo@bar.com.keys --promp
Enter your encryption/signature password: 
Decrypting 16.gz.mbox
Decrypting 11.gz.mbox
Decrypting 45.gz.mbox
...

Code évidement open source que vous pouvez trouver le code sur mon dépot gitorious. C’est compatible python 2.7 et plus (python 3 c’est l’avenir !) et nécessite pycrypto (qui est compatible python 2.1 et 3.2, j’imagine même pas le bordel que ça doit être). Mes tests très scientifiques type àvuedenezçapasse montrent que le programme fonctionne mais on est jamais à une erreur prêt, n’hésitez pas à me communiquer vos idées d’améliorations ou corrections.

PS: fait amusant concernant AES 256, saviez vous que l’énergie contenue dans une supernova ne suffirait pas rien que pour énumérer les 2²⁵⁶ états possibles (calcul non compris donc). A moins de trouver une faille de sécurité, il est donc impossible, avec les notions de la physique actuelle, de faire un brute force sur une clef AES 256. Source: Applied Cryptography, Bruce Schneier (extrait en question).

Imaginons…

Imaginons un lointain pays limitrophe (par facilité nous l’appellerons Cefran). En Cefran, on a décidé de permettre à ses électeurs résidents à l’étranger de voter via un site internet. A la grosse louche, ça fait 700.000 personnes concernées. En patrie Cefranaise, on est moderne, on flirte avec les nouvelles technologies, tiens on est tellement branché qu’on ferait bien une application iPhone la prochaine fois.

Cependant, pas possible de déployer un système pareil soit même (on sait pas faire un « hello world » en python, alors pensez un système de vote électronique). Heureusement, leurs potes de chez Csytl (société fictive bien entendu) viennent leur tirer une belle épine du pied : ils se proposent « généreusement » de faire ça. Csytl est une société très connue dans le milieu, tellement qu’elle peut se permettre de faire n’importe quoi et quand même décrocher des contrats avec les états (lobyquoi ?). Le résultat est esthétiquement pas trop mal mais d’un point de vue sécurité une horreur: https non obligatoire, des injections sql, du chiffrement mal fait, vieille version de java requise, un applet mal torché et surtout aucune transparence. Le résultat du vote se trouve aux mains d’un société privée.

En voyant ça, vous pensez bien que les habitants imaginaires de Cefran ont clashé en masse le système de vote, en particulier un nouveau parti politique désirant se battre pour la liberté des citoyens (si ça c’est pas une preuve qu’on est en pleine fiction je sais pas ce qu’il vous faut). Au final, on en est arrivé au point où les gens ne pensent pas qu’il est possible d’avoir un bon système de vote par internet (j’avais essayé une fois d’en discuter sur StatusNet, ce fut laborieux).

C'était mieux avant ma bonne dame !

Améliorons…

Après cette trop longue introduction inutile, n’écoutant que mon cœur et mon courage, je veux défendre la veuve, l’orphelin et le vote électronique. Le vote électronique moi ça me botte, je trouve ça super intéressant, la technologie qui sert la démocratie, c’est beau. Non ? Soit. Bref j’affirme que, si, c’est possible de faire un système de vote valable pour peu qu’on ne s’y prenne pas comme un blaireau…

Pratiquement, pour améliorer la sécurité, il y a plusieurs mesures « de base » à appliquer : HTTPS obligatoire, audit de code bien à l’avance, authentification forte (via une carte d’identité électronique par exemple), ne pas impliquer de société privées comme seules responsables de certaines étapes critiques… L’exemple ci-dessus est un beau cas d’école de ce qu’il ne faut pas faire. Cependant si ces points sont plutôt sur la forme, le fond est très important aussi: on veut dépasser le stade d’une base mysql avec un compteur pour chaque candidat.

La confiance

D’abord partons d’un point sur lequel on est tous d’accord: on ne peut pas faire confiance au serveur distant. Le votant veut avoir la certitude de ce que fait la machine avec son vote. Si je clique sur le bouton pour voter pour X, je veux être sûr que mon vote ne sera pas comptabilisé pour Y. Pour cela, on peut obliger les gens à utiliser des systèmes ouverts, à montrer le code source de leurs programmes. Mais après qu’est-ce qui va me garantir que c’est bien le logiciel qu’ils utilisent ? La solution est de ne pas leur faire confiance et de faire le boulot soit même. Le vote doit être chiffré coté client dans un ballot et envoyé au serveur qui n’aura plus qu’à l’ajouter à la pile des autres ballot. Comment faire ça ? En javascript par exemple (oui on est capable de faire de la crypto en javascript). Si on pousse un cran plus loin, on pourrait avoir un système utilisant des clients externes. Vous n’avez pas confiance en le site officiel ? Utilisez l’application qu’aura développé votre parti ou le programme open source maintenu par la communauté. Le seul job du site officiel sera de vous authentifier et de comptabiliser votre bulletin.

La transparence ? Si tous les bulletins sont bien chiffrés, il n’y a aucun problème à donner un accès libre à tous ces bulletins. Aucune confiance dans le serveur, toutes les données sont publiques. Vous pouvez vérifier sur une pool publique sur base d’un hash de votre ballot qu’il est bien comptabilisé. Des bonnes tailles de clef garantissent le secret pour une centaine d’année, ça devrait suffire. Si ça ce n’est pas la transparence ultime ? N’importe qui, à n’importe quel moment, peut accéder à tous les votes, vérifier son bulletin et s’assurer ainsi que personne n’a été altéré n’a été ajouter, supprimer ou remplacer des bulletins.

Zero Knowledge Proof

Comment séparer le votant et son intention de vote ? C’est là que ça devient tricky. Il existe un concept en crypto qui s’appelle la « Zero Knowledge Proof » (ZKP ou « preuve à divulgation nulle de connaissance » pour les francophiles). C’est un très beau principe qui est, par exemple, implémenté dans OAuth, l’api de connexion pour les Twitter, StatusNet, Facebook & co. Le but est de prouver à un tiers que l’on connaît un secret sans révéler ce secret. Plutôt que de donner la clef du cadenas, on montre qu’on est capable de l’ouvrir. En appliquant ce principe, on est capable de créer un ballot et prouver qu’il appartient bien à un votant valide sans dire qui il est (le secret) ou pour prouver que le déchiffrement a été fait correctement sans révéler les clefs de déchiffrement. La zéro knownledge c’est bon, mangez en !

Exemple intuitif du ZKP avec le passage secret dans un tunnel

Une fois le vote clôturé, on a une phase d’audit publique. Chacun peut voir que son bulletin est toujours là et n’a pas été altéré. Les checksums sont également vérifiées pour détecter toute tentative de manipulation. Maintenant, le déchiffrement : on ne veut absolument pas donner le secret du déchiffrement à une seule personne. On va donc séparer la responsabilité en plusieurs personnes, les trustees. Les trustees sont des gens qui n’ont pas d’intérêt à tricher ensembles (des gens de partis opposés par exemple). Ainsi même si n-1 veulent tricher, pas moyen de déchiffrer le tout. Il existe ensuite plusieurs façon de faire selon le système choisi et le type de vote. On peut par exemple faire cela en deux phases (donc 2 groupes de trustees et 2 ensembles de clefs pour plus de sécurité). La première phase va être de rassembler tous les votes en une somme, le shuffling. Cette phase est essentielle pour la confidentialité car est le moment où l’on détache le choix de vote de la personne. Il est mathématiquement impossible de relier les votes aux gens après ça. La deuxième phase est le déchiffrement. Sur base du résultat du shuffling, on va « ouvrir l’urne » et compter le nombre de vote. Une fois fait, on détruit au moins une clef de trustee pour empêcher toute attaque sur la pool de vote. Tout cela doit se faire dans les conditions de sécurité optimales. Par exemple sur une machine virtuelle complètement offline supprimée après opération et tout le tsoin tsoin.

Les virus

Un des problèmes en terme de confiance en le vote électronique est le cas de machine corrompue. Si on considère que ma machine est infectée jusqu’à la moelle, je ne peux avoir aucune confiance en ce que je vois à l’écran. On peut trouver des méthodes qui diminuent le risque en cas d’infection (multitude d’applications, vérifications à plusieurs niveaux, authentification externe…) mais ne garantissent jamais une sécurité parfaite. La meilleur méthode dans ce cas est d’utiliser un nouveau canal. Il s’agit par exemple de codes unique transmis par courriers papiers. Sur mon papier il sera indiqué que: pour voter A, entrez le code 123 et pour voter B, entrez le code 321. L’ordinateur corrompu n’a aucun moyen de savoir quel code correspond à quoi. Ce qui est très étonnant est que pour les élections en France, l’on possédait ce canal (les accès sont transmis par courrier), Scytl possédait la technologie (utilisée en Norvège) mais ne l’a pas utilisé.

Helios

C’est bien beau tout ça, mais l’idéal serait de dépasser le stade de théorie. Ça tombe bien, je vous présente Helios Voting. Un beau logiciel open source (GPL). Pour la petite histoire, le système a été utilisés aux élections du recteur et des représentants étudiants dans mon université (avec vote papier toujours possible). J’ai d’ailleurs participé à la réalisation de ce dernier (la partie la plus importante : l’interface graphique et les animations jQuery). Le système a été testé par des milliers d’étudiants (à la 3eme reprise en 2012) et conçu par des profs et spécialistes en crypto. Détail amusant pendant les élections étudiantes: aucun bulletin de vote électronique n’a été invalidé, plusieurs papiers ont du être comptés comme nuls car mal remplis.

Hélios a été conçu pour être simple d’utilisation. Le vote se fait donc uniquement sur le site de l’élection et le bulletin est chiffré en javascript. En comparaison au système français, l’on ne garantit donc qu’une protection légèrement supplémentaire du coté client (les plus grosses bourdes sont évitées mais quand même pas de protection contre les machines corrompues) mais par contre on fait beaucoup mieux du coté de la vérifiabilité et surtout on ne demande plus une confiance aveugle en un système fermé. (oui oui le système utilisé pour nos élections étudiantes était donc meilleur que le système Français).

Remotegrity

Remotegrity est un système de vote qui a été utilisé par exemple à Takoma Park dans l’état du Maryland pour les élections municipales de 2011. Ce système utilisait le canal papier pour transmettre des codes, le tout étant totalement vérifiable. Pour comprendre plus le fonctionnement de ce système, je vous conseille de regarder la vidéo ci-dessous (anglais) ou de lire la FAQ.

Acceptons…

Un des soucis que les gens rencontrent avec les votes électroniques est le fait que n’importe qui ne peut pas comprendre le fonctionnement du système de vote. C’est évident, je ne suis pas rentré dans les détails (parce que je ne les maîtrise pas) et je suis sûr que la partie de la population qui comprend les concepts décrits ci-dessus est très faible. L’on affirme ainsi que si madame Michu ne comprend pas, ce n’est pas démocratique. Alors là je ne suis pas d’accord. Comme le dit si bien PostBlue (il va attraper le gros cou maintenant qu’on le cite):

C’est une mécompréhension du système de vote démocratique, à mon sens, de croire que la multiplicité de la vérification rend ce système moins-faillible. C’est estimer, de façon complètement naïve, que plus il y a de monde en charge, moins cela est détournable. La vérification par un expert peut être tout aussi publique qu’une vérification par 8 débiles bas de plafond qui n’ont aucune idée de ce qu’ils font.

Si une chiée d’experts reconnus en sécurité et cryptographie disent que oui ce système est sûr, je trouve normal qu’il soit adopté. En comparaison, on pourrait dire que, lorsque je suis malade, j’ai le choix entre prendre des remèdes de grand-mère (je comprend, c’est simple) ou d’aller voir un médecin à qui je ferai confiance pour appliquer des méthodes que je ne comprend pas mais que je sais sont reconnues par d’autres médecins comme efficaces. On passe notre vie à déléguer la compréhension à des gens plus spécialisés que nous dans le domaine et c’est une bonne chose. D’ailleurs on le fait déjà en politique, les gens que nous élisons ont généralement des bonnes connaissances du droit et du domaine dont ils sont responsables (en principe). Ce n’est pas parce que moi tout seul je ne comprend plus l’entièreté du processus de vote qu’il n’est plus démocratique. Je suis très fan de KISS mais il ne faut pas rejeter un système efficace parce qu’il est compliqué.

Tout le monde comprend le processus de vote papier et pourtant on peut chier à la pelle des exemples de votes falsifiés ou dont la sécurité n’est pas garantie. Si théoriquement, je peux suivre toute la vie de l’urne et il existe plein de modes de vérification, on ne peut pas garantir que les milliers d’urnes utilisées ont été, en permanence, surveillées efficacement pendant les transports et autres. On se base sur la fiabilité de l’humain, c’est très naïf. Je peux recompter des billets ? Oui, je peux recompter un gros tas de papier mais je recompte quoi ? Est-ce que j’ai la preuve que je compte des papiers originaux, qu’il n’y a pas eu échanges ? Je ne dis pas que le vote papier est mauvais et est toujours trafiqué. Juste qu’il ne faut pas penser que c’est un système infaillible. L’important est d’avoir un esprit critique sur ce qu’on me dit.

Le problème n’est pas que les gens ne comprennent pas mais que les gens ne font pas confiance dans les nouvelles technologies, ils ont peur que si ça se passe sur une machine, on peut tout bidouiller ou qu’un hacker (vous savez ces gens dans les films qui n’utilisent jamais la souris) prennent contrôle du système et fassent tout exploser. Cela ne peut se régler que par une éducation informatique claire. C’est très important de ne pas négliger cet aspect si on veut éviter un rejet par la population.

« Voter sans compter » par nojhan

Pour conclure, aucun de ces systèmes n’est parfait. On ne garantit par exemple pas le fait que la personne qui a voté sur le pc est bien la personne qui le devrait (on diminue un peu ce problème en donnant la possibilité de revoter dans Helios par exemple). L’utilisation d’un deuxième canal dépend également de la fiabilité de ce canal (la Poste ici, ça s’annonce fort). Le vote électronique peut donc être techniquement meilleur que le vote papier mais il restera des aspects qui ne peuvent être corrigés. La question est quelles sont les aspects que doivent garantir notre vote ? La transparence ? L’absence de fraude ? La sécurité du votant ? La fiabilité du résultat ? La confiance que peut avoir l’électeur dans le vote (pas uniquement du point de vue technique) ? En ayant ça en tête il faut réfléchir si les aspects qu’on gagnent et perdent sont cohérents pour l’importance de notre élection.

J’espère vous avoir convaincu qu’était possible de faire un vote électronique sécurisé, démocratique et au moins aussi sécurisé que le vote papier.

PS: merci à Olivier Pereira et Richard Mathot pour leurs temps passés à m’expliquer le fonctionnement d’Helios et les principes de crypto utilisés.

css.php