2022/04/16 (Neutriton) : Chiffrement

• Réunion précédente
• Pad de la réunion
• Liste des sujets Neutriton

Présences :

• HgO
• Celo
• Tharyrok
• wget

Jitsi : https://conf.domainepublic.net/neutrinet

~~Si à 15h on est que trois personnes en présentiel, on ira au soleil, mais n'hésitez as à nous écrire sur Mattermost si vous souhaitez nous rejoindre.~~

Moment informel durant lequel on exprime en peu de mots comment on se sent et si on a une attente forte pour la réunion. Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire

Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.

Il y a différents usages autour de la table, allant de pas vraiment de connaissances, pratiques ou théoriques, sur le chiffrement, jusqu'au chiffrement de serveurs (en passant par iDRAC/iLO ou un initramfs modifié).

On va faire un petit tour d'horizon, des enjeux et des possibilités.

C'est souvent ce qui nous pousse à chiffrer. Mais on ne va pas chiffrer un ordinateur de la maison ou un portable de la même façon qu'un serveur.

Beaucoup de questions à se poser sur le modèle de menace, càd de quoi on veut se prémunir ?

C'est en fonction de ce modèle de menace qu'on choisit la méthode.

Par exemple, chiffrer un disque dur qui ne va protéger les données uniquement quand c'est à froid, ce n'est peut-être pas super intéressant pour un serveur.

Différence données chaudes, données froides. Les données chaudes sont les données déchiffrées, auxquelles on a accès en clair. Les données froides sont celles que l'on doit déchiffre à l'aide d'une clé.

Dans le cas d'une base de donnée, on a voulu utiliser le moteur d'une base de donnée pour chiffrer. Si on éteint les données, on ne sait pas y accéder. Mais si le moteur est allumé, si on a des données chaudes et qu'on a une injection sql, le chiffrement n'a pas d'effets.

Dans le cas de Neutrinet, si on a arrache physiquement un disque dur… veut-on avoir accès facilement aux données ?

La sécurité doit être proporionnelle au modèle de menace qu'on a défini. Si on a un serveur, et qu'on laisse les ports USB accessible, ce n'est pas en chiffrant les données qu'on se protège vraiment. Par exemple, il est possible d'avoir une clé usb qui va simuler un clavier et faire des scan pour trouver une faille.

En gros, la question c'est quelle est la confiance qu'on accorde aux tiers ? (accès au datacenter, par exemple)

Un autre exemple : certains SSD permettent un chiffrement natif via le contrôleur du SSD, sauf qu'il a été démontré que les firmware avait des bugs d'implémentation. On a alors une sensation de sécurité qui n'est en fait pas présente.

Ou les générateurs de nombre aléatoire sont généralement difficile à auditer. Or, les nombres aléatoires sont essentiel dans le chiffrement. S'il y a une faille à ce niveau-là, toute la sécurité s'effondre.

Est-ce qu'on souhaite se défendre contre la NSA ? contre des militaires ? ou bien ce n'est pas notre modèle de menace et on accepte de faire confiance à des tiers parce que le vecteur d'attaque n'est pas si grand que ça ?

Rélféchir à un modèle de menace prend beaucoup de temps et on peut partir très loin de l'informatique.

Est-ce que le boucher du coin est une menace ?

On va réfléchir au modèle de menace pour Neutrinet. En fonction des technologies à disposition, on va faire des choix ?

Au niveau légal, qu'est-ce qui est possible ou pas ?

C'est souvent un argument pour chiffrer les mediums de stockage.

En Belgique, aujourd'hui :

L’article 88 quater, §1 du Code d’instruction criminelle prévoit que le juge d’instruction peut ordonner à toute personne (y compris un suspect) qui est soupçonnée d’avoir une connaissance particulière d’un système informatique faisant l’objet d’une enquête ou des systèmes de sécurité et de cryptages utilisés, de fournir des informations sur son fonctionnement ou sur l’accès à celui-ci. Celui qui ne coopère pas est punissable sur base du même article 88 quater, §3 du Code d’instruction criminelle.

https://wvlaw.be/fr/en-ce-qui-concerne-le-droit-de-garder-le-silence-mais-lobligation-de-donner-le-code-dacces-de-son-g-s-m-cass-4-fevrier-2020-p-19-1086-n/

Cela entre en contradiction avec le droit de ne pas s'autoincriminer. Pour l'instant, nous avons l'arrêté P.19.1086.N qui considère que l’article 88 quater, §1 du Code d’instruction criminelle ne rentre pas en contradiction avec le droit ne pas de s'autoincriminer.

En d'autres termes, nous sommes obligés de fournir les informations pour le déchiffrage des mediums sous peine de prison.

En Belgique, avoir un système informatique qui est chiffré ne nous protège pas contre la justice, parce qu'elle a les moyens de nous faire déchiffrer. Sauf à accepter de faire de la prison…

Dans tous les cas, cela rejoint aussi la question du modèle de menace. Est-ce qu'on veut se protéger contre la justice, l'État, … ?

Il y a aussi la CCJ, qui permet de mettre en place des écoutes des communications en amont du chiffrement.

Les métadata peuvent être mobilisées… En fonction des méta données, on peut identifier le type d'activité du serveur (on ne fera pas gober que toutes ces données chiffrées sont une partition swap )

Une solution : avoir deux clés pour déchiffrer des données différentes… critiques et moins critiques. “Plausible deniability”, on montre qu'on coopère avec la justice, sans trop risquer de montrer qu'on ne veut pas coopérer.

Ici, c'est ce qu'il faut vraiment avoir en tête. S'il faut être trois pour déverrouiller un serveur… plus compliqué de le redémarrer. Si on doit se rendre physiquement sur place, c'est aussi compliqué.

À quel point cela doit être pénible pour déchiffrer ou pour valider qu'on peut bien se connecter ?

Être en binôme pour faire des actions, c'est très sécurisé, mais ça complexifie l'administration.

Après, la redondance peut nous aider, à savoir que c'est pas grave si un serveur est à l'arrêt pendant quelques jours, on a le temps de se rendre sur place pour le déchiffrer. Mais à l'inverse, si on a une machine qui doit absolument redémarrer dans les prochaines heures…

Sinon, on doit trouver de moyens de chiffrer qui ne sont pas trop pénibles et qui ne prennent pas trop de temps (attendre la validation d'une seconde personne, etc.).

Si on est en mode rescue, à quel point c'est acceptable que c'est compliqué de monter tous les disques manuellement ? Cela peut se produire si on veut cloner une machine pour faire des tests, donc ce n'est pas si rare que ça.

Mais tout tombe à l'eau si on a des failles de sécurité sur nos services… D'où l'importance d'avoir une bonne hygiène des serveurs et de mettre à jour régulièrement.

Un article qui parle du Kernel Linux et de comment certaines composantes peuvent poser des problèmes… et quelles recommandations :

https://madaidans-insecurities.github.io/guides/linux-hardening.html

C'est pas forcément facile à suivre comme recommendations. Cela demande aussi une bonne connaissance des options qu'on est en train de modifier.

Il y a aussi la question de signer son kernel, ce qui empêche de booter sur autre chose que le kernel qu'on a autorisé. https://twitter.com/wget42/status/1086233839989649413

On va se concentrer sur le chiffrement de données sur disque dur. C'est déjà pas mal.

https://wiki.archlinux.org/title/Data-at-rest_encryption

Une première manière est de chiffrer au niveau du système de fichier. C'est du chiffrement symétrique (toutes les solutions dont on va parler aujourd'hui sont du chiffrement symétrique).

Il y a plusieurs outils, mais eCryptfs est le plus connu :

• eCryptfs
• gocrypt
• cryptfs

Désavantage : à froid on peut voir la quantité de fichiers qu'il y a et leur taille.

Avantage : ça peut être lié à PAM.

C'est plutôt pour les ordinateurs personnels. Le /home/ est chiffré.

C'est assez simple à mettre en place, cela empêche l'accès aux données froides mais avec quand même certaines informations (taille, dernier accès, etc…)

On peut ensuite chiffrer au niveau block, et l'outil incontesté est LUKS (Linux Unified Key Setup). C'est souvent utilisé derrière crypt setup ou ?.

Il y a deux versions, la dernière gère plus d'algos dont des algos à courbe elliptique.

En général, ça s'utilise de la manière suivante : bonjour j'ai besoin de la passphrase pour déverrouiller mon volume. On fournit la passphrase, et il déchiffre le tout.

Cela permet par exemple de chiffrer la swap.

La version 2 apporte des notions comme discard et utilisation des primitives de chiffrement du CPU.

La bible pour installer / configurer LUKS c'est le wiki d'archlinux : https://wiki.archlinux.org/title/Data-at-rest_encryption

On peut passer beaucoup de temps sur la mise en place et l'optimisation de LUKS. Par exemple un volume /boot chiffré, un volume / chiffré. On peut aussi avoir plusieurs méthodes pour déverrouiller un volume, ce qui est pratique en mode recovery si on doit tout remonter à la main.

Mais on peut arriver à des situations où on a trois manières de déverrouiller par des personnes différentes qu'il faut réunir pour déverouiller le volume.

Un cas d'utilisation pratique, c'est le chiffrement de tout le système. C'est le moment où initram déverouille le volume.

L'initram déverouille les volumes.

Dans l'initram, on a plein de manières différentes de déverouiller Luks, cela peut être :

• la carte à puce → gpg
• la puce tpm → puce cryptographique sur les machines qui peut contenir un secret
• ssh → on se connecte au serveur pour déverouiller

TPM : empêche de mettre sur une autre machine qui ne contient pas le contenu de la puce.

On peut combiner des modèles, par exemple ssh + carte à puce.

Scaleway : ont implémenté de quoi taper sa passephrase dans la console.

Tout ça c'est bien, jusqu'au jour où un petit malin change le bootloader pour mettre son propre initram avec un keylogger.

Cela nous amène à la sécurisation du bootloader pour s'assurer de l'intégrité de l'initram.

On peut générer une PKI qui vient signer l'initram. On reconnaît donc une initram parce que vérifiée par une autorité connue. On ne boot alors que là-dessus.

C'est notamment utilisé par Windaube pour empêcher le démarrage d'autres OS dans son bootloader. Le certificat de Windaube est reconnu nativement par les ordinateurs. D'ailleurs, le certificat est désormais intégré dans grub pour permettre l'installation de linux.

Une autre manière de faire est de chiffrer /boot. C'est alors grub2 qui déverouille le /boot, qui démarre sur l'initram, qui déverouille /.

Cette méthode là ne marche plus lorsqu'on est en remote, parce qu'on est très très tôt dans la chaine de démarrage. En fait, on ne voit même pas encore le menu de grub.

A l'heure actuelle, grub ne supporte que LUKS version 1.

C'est là qu'on revient à l'iLo, iDrac ou même au VNC de Proxmox pour aller taper sa passphrase lors du démarrage du système.

La moins pire des idées paraît être de ne pas utiliser l'interface web des iLo et iDrac, mais d'avoir un bastion et de s'y connecter en ssh pour accéder à la console série.

La puce TPM est assez sympa parce qu'elle permet de ne pas devoir intéragir pour déchiffrer.

Elle protège néanmoins car si on extrait le disque, on ne pourra pas le lire sur une autre machine.

Ou alors on a une chaîne de démarrage signée, qui démarre un serveur ssh pour aller taper sa passephrase, mais alors le /boot n'est pas chiffré et c'est la signature qui protège des risques d'altération du kernel. Ici, pas de LUKS, le kernel est une app EFI (cf. https://wiki.archlinux.org/title/EFISTUB)

Chez Neutrinet, on a la possibilité de rajouter des OSD chiffré (dans CEPH, un OSD est l'équivalent d'un disque dur, c'est une unité de stockage). Ce sont alors les moniteurs de CEPH qui possèdent la clé de chiffrement et s'assurent que les OSD sont démarrés.

Mais du coup, on déplace le problème sur les machines physiques. Autre problème, CEPH ne supporte que LUKS version 1, et la clé de chiffrement est en clair sur les moniteurs.

Le chiffrement, c'est complikay (komplikey pask'il faut une clé). Si on reprend le modèle avec juste le /boot chiffré, c'est compliqué si on doit redémarrer un serveur.

Clavis, ce n'est pas un roi, mais une manière de chiffrer avec LUKS en utilisant la puce TPM. Ca permet de sécuriser l'accès physique à un matériel sans avoir d'interaction quand le serveur. On a des puces TPM donc ce serait possible.

L'idée ce serait que nos serveurs soient vus comme des boites noires où il n'est plus possible de venir brancher un truc USB. Et la manière la plus élégante est d'utiliser la puce TPM.

Pour la puce TPM, il y a deux versions principales, la 1.2 et la 2.0 et la grosse différence ce sont les algorithmes utilisés. C'est supporté nativement par la plupart des serveurs.

Le chiffrement est compliqué et n'est pas accessible à tous. C'est pourquoi on ne demande pas au gens qui viennent au install party d'avoir un ordinateur chiffré. Mais cela permet une tranquilité d'esprit, en tout cas pour les ordinateurs personnels.

Tout à l'heure on parlait des tiers de confiance. Est-ce que Neutrinet peut être un tiers de confiance ?

Dans le cadre de Chez Mémé, si Neutrinet chiffre les machines virtuelles à la place des utilisateurs, est-ce pertinent ? Sachant que ça a toujours un coup de performance, même si ici on a pu récupérer des performances on flashant les cartes RAID des serveurs, ce qui aura un « impact nul ».

Dans tous les cas, il faudra informer précisément les gens sur le niveau auquel on protège leurs données.

Mais Chez Mémé est la partie simple, parce que la question du chiffrement au sein des machines de Neutrinet est déjà plus complexe.

Les bases de données sont également un cas particulier, parce que c'est beau de chiffrer au démarrage, mais si tout le monde peut récupérer les infos dans la base de données, cela ne sert à rien.

Ce qu'on sait qui ne marche pas : utiliser la partie chiffrement de CEPH, car cela utilise LUKS v1 et cela pose trop de problème d'aller récupérer la clé de déchiffrement. Ce qui ne va pas non plus, c'est conserver des données dans un état chaud. Il vaut mieux déchiffrer à chaque moment les donées dont on a besoin et non tout déchiffrer au début (mais on a alors beaucoup de données chaudes, déchiffrées, qui ne sont pas immédiatement utiles).

On préférerait alors une situation où l'OS déchiffre des volumes, dont CEPH ne connaît pas la clé, lorsqu'il en a besoin.

On doit déja définir ce qu'est le modèle de menace de Neutrinet et en fonction de ça définir des actions.

A priori, on ne peut pas prétendre à se protéger de l'Etat ou de la justice. Cependant, se protéger d'une personne qui passerait au datacenter pourrait être utile. On est tansparent sur l'emplacement de nos serveurs, en plus, avec le projet Chez Mémé, ça va prendre de l'ampleur. On aura d'autres serveurs aussi qui s'ajouteront probablement. Ca va faire du passage.

Autant se concentrer sur la sécurité des accès aux serveurs (pas de mot de passe trop simple).

D'abord protéger les données au niveau block device, et s'occuper des données à chaud dans un second temps.

Éviter d'avoir trop de complexité, ou alors documenter absolument tout. Mais au niveau disponibilité humaine, ne pas se tirer une balle. Donc, ne pas obliger d'être à plusieurs pour déverouiller les serveurs, même si sur le papier ça a l'air sympa.

Attention, il ne faut pas toujours penser qu'on a fait quelque chose de super sécurisé. On peut avoir quelque chose de très sécurisé qu'on exploite mal.

L'aspect à protéger en premier lieu c'est l'accès physique. Donc chiffrement des devices et sécuriser les périphériques USB.

Idée : avoir tout qui est chiffré, même /boot, et passer par la partie série des iDrac et iLo pour déverouiller. Pourquoi ? La connexion série est agnostique sur les claviers, et cela demande peut de configurer (accès série iLo / iDrac).

Ensuite, dans l'initram, on a des clés qui servent à déverouiller tout le reste.

Des cas à réfléchir : quid d'un redémarrage électrique de toute l'armoire ? Si les machines virtuelles sont sur un Proxmox chiffré qui réclame une passephrase au démarrage… on devra aller sur place. Le problème ne se passerait pas avec un redémarrage volontaire, car nos sessions BGP sont toujours up et nos ip toujours annoncées, et on a accès aux iLo et iDrac, mais se passerait si tout disfonctionne.

Petit apparté sur les backups : Proxmox envoie ses backups vers le PBS, et les clés de chiffrement sont sur… le Proxmox mais aussi dans le gopass (ouf).

Si on chiffre les disques des Proxmox qui servent à Neutrinet, cela prendra encore plus de temps. Et ça en prend déjà. Donc on aura besoin de disque SSD pour ne pas perdre trop en performance.

Petit apparté sur les disques: un SSD de Chez Mémé est mort. Sans doute le covid.

Bref : on doit commander des SSD.

Au sujet de la documentation technique dans Neutrinet, on a Ansible pour redéployer les machines. Même si tout n'est pas automatisé (installation de Nextcloud, etc.). La doc technique se trouve aussi sur notre wiki, mais si Neutrinet est par terre ça sert à rien. Au niveau réseau, on aimerait installer Netbox pour avoir un truc un peu plus automatisé et à jour.

Le truc : refaire un Neutrinet ailleurs est compliqué parce qu'il faut aussi la partie BGP. Installer des machines ailleurs sans faire la partie BGP, ça n'est pas vraiment Neutrinet.

Pour revenir au chiffrement, la question est toujours : est-ce qu'on veut de l'interaction humaine ? est-ce qu'on veut utiliser les iDrac / iLo ? où est-ce qu'on veut déverouiller ? Et donc que faut-il à minima pour que ça foncitonne (par exemple, que les iDrac /iLo soient allumés)

Il y a aussi la possibilité d'avoir une yubikey ou Solokey en open source.

Prochaine réunion hub infra : 30/04 à 14h

Atelier Proxmox : 07/05, avec comme programme :

• à partir de 11h : installation des humains
• 12h - 13h : manger ensemble
• 14h : installation des proxmox
• 19h : fin

Prochain Neutriton : Keycloak ou Sécurité ? À décider lors du prochain hub infra. On note le 11/06 pour le Neutriton Keycloak et on confirme lors de la réunion du 30/04. Voir aussi le précédent Neutriton sur Keycloak : https://wiki.neutrinet.be/fr/rapports/2021/02-20 (mais les images ont disparues, snif)

Lieu : Caldarium

Moment informel durant lequel on exprime en peu de mots comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif. Si une ou plusieurs tension est née durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.

« Neutrinet ? J'aurai dû venir plus tôt ! »

TODO : Faire un article de blog de ce Neutriton.