Bonjour à tous,
J'utilise ce projet pour debian pour raspberry.
J'essaie de chiffrer le rootfs d'une raspberry pi 4.
Les partitions sont sur une carte microSD.
Quelle méthode est réalisable et la plus simple parmi les suivante ?
-passer par l'initramfs
-passer par la méthode chroot
J'ai essayé des tutos pour le moment sans succès, si vous avez un tuto ou une procédure que vous avez déjà utilisé et vérifiée, je suis preneur !
Merci à vous.
# pas forcément compris
Posté par octane . Évalué à 3 (+1/-0).
J'ai pas forcément compris. Généralement, l'install d'un raspi de fait en dumpant une image toute faite sur une flash. Et ces installs ne sont pas chiffrées, donc pas de chiffrement de disque. Lorsqu'on veut chiffrer un disque, on utilise un installeur qui prévoit l'option durant l'install, avant formatage et copie des fichiers sur disque.
Je ne sais pas s'il y a un installeur pour raspi autre que des images disques toutes prêtes (mais je suis pas un expert).
Ensuite, j'utilise des raspis sans clavier ni écran. Et je ne chiffre pas les partitions pour cette raison: en cas de reboot, comment entrer le mot de passe de déchiffrement sans clavier?
# Pourquoi donc ?
Posté par Luc-Skywalker . Évalué à 4 (+2/-0).
Pourquoi ?
Si on doit chiffrer un truc, c'est /home/* (ou autre) mais pas le rootfs de debian qui est de toutes façons libre et à priori bien blindé ?
En plus, vu tes conditions (un RBPi4b qui démarre et tourne sur une SDcard) ça va être acrobatique de faire tout ça à la volée.
Par contre, si la SDcard est déjà correctement partitionnée, je pense que c'est faisable assez facilement de crypter ce qui doit l'être.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Pourquoi donc ?
Posté par legranblon (site web personnel) . Évalué à 2 (+0/-0).
Au hasard : éviter aux indélicats de devenir trop facilement root (en éditant le shadow à froid).
[^] # Re: Pourquoi donc ?
Posté par Voltairine . Évalué à 2 (+0/-0).
Ça implique un accès physique au Raspberry, un remontage de la carte SD dans une autre machine, un chroot ou autre pour se créer un compte avec les privilèges root, etc.
C'est quand même très peu probable. Et si la(es) partition(s) contenant les données ont été chiffrées cela ne servirait à rien.
[^] # Re: Pourquoi donc ?
Posté par octane . Évalué à 4 (+2/-0).
Dans le cas du raspberry, l'extraction du disque est super simple :-)
Bah je m'ajoute un user, j'ajoute un binaire suid, j'ajoute un reverse-shell dans une unit systemd, j'ajoute une clé SSH dans le /root/.ssh/authorized_keys (et tous les users aussi du coup, tiens), j'ajoute un backup automatique de la clé LUKS en clair lors du déverrouillage, j'ajoute l'envoi d'un email lors du rallumage du raspi, etc etc…
Puis j'attends que le raspi soit rallumé. Et j'accède aux données \o/
[^] # Re: Pourquoi donc ?
Posté par Voltairine . Évalué à 2 (+0/-0).
Et bien entendu l'administrateur de la machine ne s'est aperçu de rien.
[^] # Re: Pourquoi donc ?
Posté par legranblon (site web personnel) . Évalué à 3 (+1/-0).
Toutes les personnes qui mettent en oeuvre un raspi sont admin, dans les fait. En ont-ils pour autant les pratiques et réflexes ?
[^] # Re: Pourquoi donc ?
Posté par Voltairine . Évalué à 2 (+0/-0).
Même si tu n'as pas mis en place de surveillance du système avec alertes qui vont bien, cela fait au final un paquet de conditions improbables pour que ce type de compromission arrive :
- une personne malintentionné qui t'en veut personnellement ;
- une personne qui à un accès physique à ta machine ;
- une personne qui a suffisamment de temps et de compétences pour compromettre la machine suivant le processus décrit plus haut ;
- un propriétaire du système qui ne se rend pas compte que sa machine a été arrêtée et redémarrée (interruption des services fournis) alors qu'il/elle est suffisamment parano pour chiffrer sa partition système ;
- etc.
[^] # Re: Pourquoi donc ?
Posté par legranblon (site web personnel) . Évalué à 2 (+0/-0).
Je trouve ton avis assez arrêté, je vais donc illuster. J'ai par ici un ado qui n'a pas hésité à faire péter la régulation en temps de l'ordiphone qui lui avait été confié, la jugeant -bien sur- trop restrictive. En douce, hein, pas en le criant sur les toits. Les sbc n'ont généralement que peu de protections physiques et sont par essence destinés à des applications enfouies, le genre de truc qui le fait bien au tout les jours, mais qu'on a pas forcément envie de toucher tout le temps. Si j'avais un pi qui tournais chez moi, je serais plus serein si l'ensemble des partitions était illisible aussi trivialement.
[^] # Re: Pourquoi donc ?
Posté par Voltairine . Évalué à 2 (+0/-0).
Ce n'est pas un avis. J'essaie de mettre en balance l'investissement pour faire ce genre de chose et les très rares cas où cela apporterai réellement une sécurité.
Je peux éventuellement comprendre ton usage mais c'est un cas très marginal.
[^] # Re: Pourquoi donc ?
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
Absolument. Supposons donc que, subrepticement, tu retires la SDcard du RBPi,
"Si tous les cons volaient, il ferait nuit" F. Dard
# Mot de passe
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0).
Le soucis souvent c'est que au boot tu devras taper le mot de passe. Et ça c'est pas forcément possible, surtout si le RPi est hors de portée.
Calcule bien ton coup à l'avance :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Mot de passe
Posté par NeoX . Évalué à 5 (+2/-0).
j'ai vu un truc recemment chez Korben il me semble pour embarquer un dropbear-ssh dans le grub, pour ouvoir se connecter en SSH au grub pour justement deverrouiller un rootFS chiffré
mais j'ai plus le lien en tete
[^] # Re: Mot de passe
Posté par eric gerbier (site web personnel) . Évalué à 3 (+2/-0).
https://korben.info/deverrouillage-disque-chiffre-distance.html
# Finalement ?
Posté par Luc-Skywalker . Évalué à 4 (+2/-0). Dernière modification le 13 mars 2026 à 22:32.
tu nous diras comment tu as procédé car ça m'intéresse.
"Si tous les cons volaient, il ferait nuit" F. Dard
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.