gouttegd a écrit 1805 commentaires

Il faut donc les renouveler régulièrement, ce qui implique des coûts d'exploitation, soit pour le renouvellement manuel, soit pour l'exploitation du script d'automatisation.

Un des objectifs de Let’s Encrypt est clairement de pousser à l’automatisation. En fait, c’est leur deuxième key principle :

Automatic: Software running on a web server can interact with Let’s Encrypt to painlessly obtain a certificate, securely configure it for use, and automatically take care of renewal.

Des avis ?

Je suis pour ma part à fond pour l’automatisation. Avec ou sans Let’s Encrypt d’ailleurs (avant de passer à Let’s Encrypt, j’utilisais des certificats signés par ma propre autorité de certification, et l’une des raisons était justement de pouvoir créer/renouveller/remplacer des certificats en une seule commande sans aucune étape manuelle).

Le souci avec les certificats à longue durée de vie (outre le fait que la révocation dans le monde HTTPS ne fonctionne pas en pratique), c’est que si tu n’installes un nouveau certificat qu’une fois tous les trois ans, c’est une opération trop rare pour que tu sois bien familiarisée avec.

On a vu le résultat lors de la faille Heartbleed : des dizaines de messages d’administrateurs en herbe sur divers forums, demandant « on me dit que mon certificat actuel est compromis, comment je fais pour le remplacer ? » Et tous ceux qui ne faisaient pas la différence entre renouveller un certificat (en gardant la même clef privée, ce qu’il ne fallait pas faire dans le cas d’Heartbleed) et générer un certificat avec une nouvelle clef.

L’installation d’un certificat devrait être une opération de routine qu’un administrateur doit pouvoir faire immédiatement sans avoir à se replonger dans ses notes d’il y a trois ans (dans l’hypothèse heureuse où il avait pris des notes). Idéalement, ce doit être complètement automatisé ; a minima, l’administrateur doit avoir une procédure écrite à laquelle il n’a qu’à se référer.

Des certificats valides pendant trois ans n’incitent pas les administrateurs à mettre en place une telle procédure.

Personnellement, j’utilise le test suivant : supposons que j’apprenne à l’instant que je dois remplacer mon certificat (cas d’une faille Heartbleed-like), combien de temps me faut-il pour le faire¹ (en supposant que je suis devant mon ordinateur lorsque j’apprends la nouvelle) ? Si la réponse est « plus de deux minutes », c’est que la procédure n’est pas assez automatique.

---

¹ Sans casser les épingles TLSA et/ou HSTS, bien sûr, sinon c’est trop facile.

Ça je dirais que c’est à chacun de faire sa propre évaluation. Je peux détailler mes choix mais je ne peux pas les conseiller comme s’ils étaient applicables à tout le monde.

Pour ma part, j’ai tendance à penser que le risque de perte accidentelle (crash disque, incendie, vol à l’arraché du téléphone — non pas par quelqu’un qui voudrait ma clef, mais juste par quelqu’un qui voudrait le téléphone lui-même —, etc.) est plus vraisemblable que le vol, raison pour laquelle je fais légèrement pencher la balance en faveur de la facilité de reconstitution.

J’ai donc opté pour m = 4, n = 2.

ça devient "facile" de me voler 2 des 5 fragments et avoir ma clé.

Facile, facile… Faut quand même le dire vite. Dans mon cas, si je soupèse les risques qui pèsent sur mes quatre fragments :

• le fragment stocké sur une clef USB chez moi : hors scénario à la 007 (l’espion monte-en-l’air qui pénètre chez moi en passant par la fenêtre, trouve la clef, en fait une copie, et repart sans laisser de traces), je le considère raisonnablement à l’abri ;
• le fragment stocké sur une clef USB sur mon lieu de travail : pareil (le lieu de travail en question est un labo de recherche, ce n’est pas le bâtiment le mieux sécurisé du monde mais on n’y rentre quand même pas comme ça) ;
• le fragment stocké sur mon téléphone portable : le stockage est chiffré, il faut donc non seulement me subtiliser le téléphone mais aussi le déverouiller (je ne dis pas que c’est impossible, mais il faut quand même y mettre les moyens, demandez au FBI ce qu’ils en pensent…) ;
• le fragment stocké sur mon ordinateur portable : pareil, disque dur chiffré, il faut soit mettre la main dessus à chaud, soit obtenir ma phrase de passe, soit casser le chiffrement.

J’estime pour ma part que c’est amplement suffisant. Ou plutôt, j’estime que si ils sont après moi, ils m’attaqueront sur un point plus faible, ce n’est pas ma clef OpenPGP fragmentée qui me perdra.

(Sur ce dernier point, et puisqu’il est question d’Adi Shamir dans le journal, il a aussi énoncé ce qui est devenu la « loi de Shamir » : “Cryptography is bypassed, not penetrated” — l’adversaire ne s’en prend jamais à la cryptographie de front, il la contourne. Au grand dam des crypto-nerds qui s’imaginent que la toute puissante crypto va automagiquement les mettre à l’abri de tout — mais seulement si vous avez une grosse clef, c’est très important d’avoir une grosse clef.)

Non, justement un des intérêts du secret réparti est que la perte d’un fragment est sans conséquences (tant qu’il te reste au moins autant de fragments que le seuil fixé lors du partage).

Si mon appartement brûle, je perds le fragment stocké sur une clef USB dans le tiroir de mon bureau, mais j’ai toujours le fragment stocké sur mon ordinateur portable, celui stocké sur mon téléphone, et celui stocké sur une clef USB sur mon lieu de travail.

Pour que je perde tout, il faudrait qu’une catastrophe frappe simultanément mon appartement et mon lieu de travail, à 4 km l’un de l’autre, et moi-même… J’aime bien me préparer au pire, mais pas au point d’imaginer des scénarios à la Michael Bay. :)

Au moins un shred permettrait que les données ne soient pas récupérables à froid.

Je ne suis pas vraiment convaincu de l’efficacité de shred (ou plus généralement du principe consistant à ré-écrire plusieurs fois « au même endroit » — avec toutes les couches qui s’intercalent entre le disque physique et le système de fichiers, peut-on être sûr que l’on ré-écrit bien « au même endroit » ?).

Cela dit, si ça ne fait pas de bien, j’admets que ça ne peut probablement pas faire de mal d’ajouter un appel à shred à la fermeture.

il me semble que udisksctl loop-delete ait besoin d'un accès root.

Pas pour détruire un périphérique loop que tu as toi-même créé avec udisksctl loop-setup — du moins pas si Polkit est bien configuré.

Du coup, je ne vois pas comment, avec ton outil, faire m fragments donc n nécessaires pour reconstruire la clef

Ce n’est peut-être pas assez clairement expliqué.

Le fait est qu’il n’y a pas d’options pour spécifier m (le nombre de fragments total à générer). C’est le nombre de fois que tu utilises l’option -s (qui spécifie l’emplacement d’un fragment) qui détermine le nombre de fragments.

Donc, si tu veux générer 5 fragments, tu appeleras gfsec-split avec l’option -s répétée cinq fois.

Avec le recul, je réalise que cette interface n’est pas des plus logiques. Notamment, -s ne devrait pas être une option (elle n’est pas du tout optionnelle puisqu’il faut obligatoirement la spécifier, et plusieurs fois en plus). Il aurait sans doute été plus logique d’avoir une syntaxe dans ce genre-là :

$ gfsec-split [options] fichier_à_partager fragment1 fragment2 fragment3...

qui a l’avantage de bien séparer les arguments optionnels des arguments obligatoires.

je manque de temps pour comparer. Si quelqu'un a un avis…

Pour commencer, je dirais déjà que ce n’est pas tant à mon projet (celui présenté dans le journal) que ssss doit être comparé, mais plutôt au projet libgfshare.

Après un bref coup d’œil au code et sauf erreur de ma part, je pense que la différence la plus importante est que ssss semble appliquer l’algorithme de Shamir sur l’intégralité du secret en un seul bloc, raison pour laquelle le programme est limité au partage de secret d’au maximum 128 octets (1024 bits).

Libgfshare, de son côté, applique l’algorithme octet par octet, et n’a de fait pas de limitation intrinsèque sur la taille du secret à partager.

Sur un plan plus pratique, le mode de fonctionnement de ssss-combine, où l’utilisateur est supposé rentrer les valeurs des fragments « à la main » à l’invite du programme, me semble beaucoup plus fastidieux et error-prone que le mode de fonctionnement de gfcombine, qui lit les fragments depuis des fichiers.

c'et mieux d'utiliser le souligné _ que le tiret - dans les noms de programme

Je trouve ça moche. (Comment ça, c’est pas une raison valable ?)

Mais si le programme a un tiret dans son nom, cette technique est plus laborieuse à mettre en œuvre.

Si c’est réellement important, tu peux utiliser l’option --program-transform-name lors de la configuration des sources :

$ ./configure --program-transform-name='s/-/_/'

Ça changera automatiquement le nom des programmes et des pages de manuel associées (mais pas la documentation, évidemment…).

Sinon une petite question mathématique: tu utilises des corps finis pour faire ton interpolation de Lagrange? Comment est-ce que tu choisis la caractéristique? Z/pZ ou bien des extensions?

Pour ces questions, le mieux est que je te renvoie à la page de la bibliothèque libgfshare, l’implémentation de la méthode d’Adi Shamir que j’utilise. Mais en gros, oui, c’est un corps fini de cardinal 256.

C’est une légère incohérence de ma part, désolé (voilà ce que c’est que de ne pas écrire le paragraphe d’intro le même jour que le reste du journal…).

Le m de l’introduction (le seuil, le nombre de fragments nécessaires) est devenu n dans le reste du journal.

À l’occasion, si quelqu’un peut corriger (le plus simple serait d’inverser n et m dans la phrase d’introduction)…

Tu pourrais décrire mieux la raison pour laquelle tu fais ca?

En gros, c’est pour concilier deux besoins a priori irréconciliables : m’assurer de ne pas perdre ma clef OpenPGP quoi qu’il arrive¹ (pour ça j’ai besoin de copies de sauvegarde, et pas toutes réunies au même endroit), et limiter le risque de compromission de ladite clef (pour ça le mieux serait qu’il n’en existe qu’une seule et unique copie, de préférence toujours sous mon contrôle — dans ma poche par exemple).

Le secret réparti est une solution à ce dilemme. Je peux créer de multiples fragments et je n’ai aucune crainte à l’idée d’en laisser quelques-uns dans des endroits non-protégés et hors de ma vue, sachant que ces fragments isolés ne sont d’aucune utilité.

---

¹ Quand je dis « quoi qu’il arrive », j’entends par là « même si je rentre un jour du boulot et que je découvre que mon appartement a brûlé pendant mon absence » — et je ne plaisante pas, ça fait partie des scénarios auxquels je pense : j’ai la hantise de me retrouver, après une catastrophe imprévisible, dans une situation où j’aurais tous mes backups sous la main… mais sans la possibilité de les lire, parce que comme un con je les ai trop bien protégés et que j’ai perdu les clefs de déchiffrement dans la catastrophe.

Bref, prêt pour pour ce challenge? :D

Alors, euh… oui, mais non. Mais alors, pas du tout.

La problématique que tu soulèves (partage d’un secret entre plusieurs acteurs) est intéressante, mais dépasse largement le cas d’utilisation que j’avais en tête.

Gfsecret fait ce que je voulais, c’est-à-dire permettre à un utilisateur de partager un secret entre plusieurs supports à sa disposition. J’ai encore quelques idées d’améliorations en tête, mais je ne pense pas aller beaucoup plus loin que ça.

C'est bien la clef privée (ou une sous-clef privée) qui est utilisée pour signer ?

Oui. Et l’interlocuteur utilise la clef publique correspondante pour vérifier la signature.

Si la sous-clef privée est compromise, est-il possible de la remplacer sans compromettre l'intégrité de la clef primaire privée?

Oui. Mathématiquement, la clef primaire et les sous-clefs sont indépendantes. Une compromission d’une sous-clef n’entraîne pas la compromission de la clef primaire à laquelle elle est rattachée. On peut donc simplement remplacer la sous-clef, sans conséquences sur la clef primaire.

Toutefois, si une sous-clef a été compromise, et si les sous-clefs et la clef primaire sont stockées au même endroit et dans les mêmes conditions, on peut raisonnablement craindre que la clef primaire a été compromise en même temps que la sous-clef.

Et à quoi peut bien servir une sous-clef publique (qui n'est, sauf erreur de ma part, utilisée que pour chiffrer les messages) ?

Alors, attention, les notions de clefs primaires/sous-clefs d’une part, et de clefs publiques/clefs privées d’autre part, sont complètement orthogonales. Chaque sous-clef (de même que la clef primaire) est en réalité une paire de clefs, composée d’une clef publique et d’une clef privée.

Une sous-clef publique sert soit à vérifier une signature (si c’est une sous-clef de signature), soit à chiffrer un message (si c’est une sous-clef de chiffrement).

D’abord, elles permettent d’utiliser des clefs différentes pour des usages différents. Typiquement, une clef pour signer et une clef pour chiffrer (et éventuellement encore une autre clef pour authentifier).

C’est important d’une part parce que tous les types de clefs ne se prêtent pas à tous les usages (une clef ElGamal ne peut être utilisée que pour chiffrer, une clef DSA ne peut être utilisée que pour signer), et d’autre part, parce que même pour les types de clefs qui peuvent servir à la fois pour signer et pour chiffrer, c’est généralement considéré comme une mauvaise idée.

L’autre grand intérêt des sous-clefs est qu’elles peuvent être remplacées à tout moment.

Remplacer une clef primaire est une opération délicate. Une telle clef a un historique, tes interlocuteurs la connaissent (certains l’ont peut-être signée) et savent que c’est la tienne. La nouvelle clef, elle, est « vierge » — elle n’a pas d’historique, et il faut recommencer un long travail d’introduction pour amener tes interlocuteurs à avoir confiance que c’est bel et bien ta clef (une méthode courante pour faciliter ce travail est de signer la nouvelle clef avec l’ancienne, et/ou de signer avec les deux clefs une déclaration de transition comme celle-ci).

Remplacer une sous-clef est au contraire totalement transparent pour tes interlocuteurs. Seule la clef primaire est importante à leurs yeux, c’est la seule clef à laquelle ils sont directement confrontés (c’est GnuPG qui s’occupe en arrière-plan de sélectionner la sous-clef appropriée une fois que l’utilisateur a sélectionné une clef primaire). Tu peux donc remplacer une sous-clef à n’importe quel moment (pour quelque raison que ce soit) sans craindre de conséquences sur la validité de ta clef aux yeux de tes interlocuteurs.

Le souci du déni plausible, c’est que ça ne marche que si ton adversaire n’en a jamais entendu parler…

Or les programmes de chiffrement de volume qui offrent cette possibilité ne la cachent pas, bien au contraire (c’est largement expliqué dans la documentation de Veracrypt par exemple). Dès l’instant où ton adversaire se rend compte que tu utilises un programme permettant les volumes cachés, s’il n’est pas trop bête il soupçonnera que tu en as un (surtout si ① tu as lâché ton premier mot de passe un peu trop facilement et ② il ne trouve pas ce qu’il cherche dans le volume non-caché).

Le pire, c’est que s’il n’est pas possible de démontrer la présence d’un volume caché, il n’est pas non plus possible de démontrer qu’il n’y en a pas. Du coup, celui qui n’utilise pas de volume caché risque de se retrouver face à un adversaire qui continuera à exiger le « second mot de passe » (qui n’existe pas, mais va donc persuader ton adversaire de ça).

Sans aucunement critiquer la méthode présentée dans le journal, je me permets de présenter ma propre solution.

Elle est basée sur GnuPG (pour le chiffrement) et udisksctl (pour la manipulation de volumes, en gros la même chose que ce pour quoi est utilisé losetup dans le journal, mais sans avoir besoin de sudo).

J’utilise GnuPG plutôt que cryptsetup pour pouvoir « ouvrir le coffre » avec ma carte OpenPGP.

Sans fioritures, le code complet :

#!/bin/bash
# vault - Manages encrypted archives
# Copyright (C) 2014,2015 Damien Goutte-Gattat
# 
# Copying and distribution of this file, with or without modification,
# are permitted in any medium without royalty provided the copyright
# notice and this notice are preserved.

encrypted_vault_dir=${XDG_DATA_HOME:-$HOME/.local/share}/vaults
decrypted_vault_dir=$XDG_RUNTIME_DIR/vaults
default_size=8

die()
{
    echo "${0##*/}: $@" >&2
    exit
}

usage()
{
    cat <<EOU
Usage:
    [1] vault new <name> [size]
        Create a new vault with the specified name and size (in Mb).
        If size is not specified, default is ${default_size}Mb.

    [2] vault open <name>
        Open the specified vault.

    [3] vault close <name>
        Close the specified vault.

    [4] vault dclose [name]
        Close the specified vault without saving changes.
        If no vault is specified, all currently opened vaults
        are closed.

    [5] vault is-open [name]
        Return 0 if the specified vault is open, 1 otherwise.

    A default vault name may be specified in the DEFAULT_VAULT
    environment variable.
EOU

    exit 0
}

open_vault()
{
    local encrypted_vault=$encrypted_vault_dir/$1.gpg
    local decrypted_vault=$decrypted_vault_dir/$1.img

    [ -f $decrypted_vault ] && die "Vault $1 is already opened"
    [ -f $encrypted_vault ] || die "Cannot found vault $1"

    if ! gpg2 -o $decrypted_vault -d $encrypted_vault ; then
        rm -f $decrypted_vault
        die "Cannot decrypt vault $1"
    fi
    loop_device=$(udisksctl loop-setup --file $decrypted_vault | sed -nre 's,Mapped file .+ as (.+)\.,\1,p')
    udisksctl mount --block-device $loop_device --options fmask=0177
}

close_vault()
{
    local encrypted_vault=$encrypted_vault_dir/$1.gpg
    local decrypted_vault=$decrypted_vault_dir/$1.img

    [ -f $decrypted_vault ] || die "Vault $1 is not opened"

    volume_name=$(echo $1 | tr a-z A-Z)
    loop_device=$(mount | grep /run/media/$USER/$volume_name | cut -d' ' -f1)

    udisksctl unmount --block-device $loop_device
    udisksctl loop-delete --block-device $loop_device

    if [ "x$2" = x1 ]; then
        gpg2 -o $encrypted_vault.$$ -e $decrypted_vault \
            && mv $encrypted_vault.$$ $encrypted_vault
    fi
    rm $decrypted_vault
}

close_all_vault()
{
    ls $decrypted_vault_dir/*.img 2>/dev/null | while read vault ; do
        vault=${vault##*/}
        close_vault ${vault%.img} 0
    done
}

new_vault()
{
    dd if=/dev/zero of=$1.img bs=1M count=$2
    /sbin/mkfs.vfat -n $(echo $1 | tr a-z A-Z) $1.img
    gpg2 -o $encrypted_vault_dir/$1.gpg -e $1.img
    rm $1.img
}

[ -d $encrypted_vault_dir ] || mkdir -p $encrypted_vault_dir
[ -d $decrypted_vault_dir ] || mkdir -p $decrypted_vault_dir

case "$1" in
-h|--help|"")
    usage
    ;;

-v|--version)
    sed -n '2,/^$/ s/^# //p' $0
    exit 0
    ;;

new)
    [ -n "$2" ] || die "Missing vault name"

    new_vault $2 ${3:-$default_size}
    ;;

open)
    vault=${2:-$DEFAULT_VAULT}
    [ -n "$vault" ] || die "Missing vault name"

    open_vault $vault
    ;;

close)
    vault=${2:-$DEFAULT_VAULT}
    [ -n "$vault" ] || die "Missing vault name"

    close_vault $vault 1
    ;;

dclose)
    vault=$2
    if [ -n "$vault" ]; then
        close_vault $vault 0
    else
        close_all_vault
    fi
    ;;

is-open)
    vault=${2:-$DEFAULT_VAULT}
    [ -f $decrypted_vault_dir/$vault.img ] && exit 0 || exit 1
    ;;

esac

Petite subtilité supplémentaire permise par l’utilisation d’une carte OpenPGP : j’ai un script ~/.gnupg/scd-event appelé automatiquement par GnuPG à chaque « évènement » sur le lecteur de carte (insertion ou retrait de carte), avec le code suivant :

#!/bin/bash

card_status=$8

case "$card_status" in
NOCARD)
    vault dclose
    ;;
esac

qui me permet de refermer automatiquement le coffre simplement en retirant ma carte OpenPGP du lecteur.

D'un coté, il fournit une commande Linux honteusement compliquée, alors qu'un hostname -I suffit.

Petite précision, la commande hostname fournie par le projet net-tools ne reconnaît pas d’option -I. Cette option est une invention de l’implémentation propre à Debian.

Toutes les distributions n’ont pas repris cette implémentation et fournissent à la place la commande hostname d’origine du projet net-tools (sans l’option -I, donc).

Je me réponds parce que je ne peux plus éditer, juste pour enfoncer un peu plus le clou en rappelant que Stéphane Bortzmeyer faisait déjà une analyse similaire il y a quatre ans :

Les politiques ne prennent pas de mauvaises décisions par ignorance. C’est délibéré.
Exemple typique : HADOPI n’est pas une erreur technique, c’est un choix politique de droite délibéré.
Ne pas croire naïvement que, s’ils étaient mieux informés par des geeks gentils, les politiques voteraient de meilleures lois.

Ces gens qui nous gouvernent n'ont aucune culture scientifique ou technique, ils ne comprennent pas le monde où nous vivons, ils sont encore moins capables d'envisager le futur. On dit que gouverner, c'est prévoir, mais ces infirmes en sont totalement incapables.

Pas sûr :

Ne croyez donc pas qu'ils soient incompétents. C'est faux. Ils sont compétents. Ils sont entourés de gens brillants. Ils ont été avertis, par les bonnes personnes, qu'il ne fallait pas faire ça. Et ils le font quand-même.

Toute analyse qui s'appuie sur l'idée que nos ministres sont idiots est invalide. Toute analyse qui s'appuie sur le fait qu'ils soient incompétents, ou mal informés, cherche à leur trouver une excuse qui n'est pas la bonne.

Un schéma vaut sans doute mieux qu’on long discours :

+---------+
|PHYSICAL |       /dev/sda            /dev/sdb       /dev/sdc    /dev/sdd
|VOLUMES  |       (320 Go)            (320 Go)        (1 To)      (1 To)
|         |       /      \            /      \          |           |
|         |      /        \          /        \         |           |
|         |    sda1      sda2      sdb1      sdb2      sdc1        sdd1
|         |  (128 Mo)  (314 Go)  (128 Mo)  (314 Go)     |           |
|         |     |         |         |         |         |           |
|         |     +-----+---|---------+         |         +-----+-----+
|         |           |   +--------------+----+               |
+---------+           |                  |                    |
|RAID 1   |        /dev/md0           /dev/md1             /dev/md2
|         |           |                  |                    |
+---------+           |                  |                    |
|DM-CRYPT |           |           /dev/mapper/luks    /dev/mapper/luks2
|         |           |                  |                    |
+---------+           |                  +---------+----------+
|LVM2     |           |                            |
|         |           |                       /dev/cryptvg
|         |           |                            |
|         |           |        +-------+-------+---+---+-------+-------+
+---------+           |        |       |       |       |       |       |
|MOUNT    |         /boot      /     /home   /data   /var    /tmp     swap
|POINTS   |
+---------+

(La configuration initiale ne comportait que les deux disques de 320 Go, les disques de 1 To ont été rajoutés a posteriori — quand j’ai commencé à manquer de place sur /dev/md1. J’aurais peut-être organisé ça différemment si j’avais disposé des quatre disques depuis le début…)

Dans le cas de GnuPG je ne pense pas que ni systemd ni polkit soient impliqués.

Si tu n’avais pas ce comportement « il y a quelques années » c’est probablement que tu es passé de GnuPG 1.x à GnuPG 2.x.

Le mot de passe est demandé par l’agent GnuPG par l’intermédiaire d’une famille de programmes appelés pinentry-, dont il existe plusieurs versions : pinentry-tty, pinentry-curses, pinentry-gtk2, pinentry-qt, etc. (L’idée étant que l’interface de saisie du mot de passe apparaisse « intégrée » à l’environnement graphique utilisé.)

Sur la plupart des distributions, /usr/bin/pinentry (le programme appelé par défaut par l’agent GnuPG quand il a besoin d’un mot de passe) est généralement un lien symbolique vers l’une des variantes de pinentry-XXX.

On peut changer le programme appelé soit en modifiant ce lien pour le faire pointer vers le programme voulu, soit en modifiant la configuration de l’agent GnuPG (option pinentry-program dans $GNUPGHOME/gpg-agent.conf).

Sur les disques WD, c’est le contrôleur USB qui fournit au système le programme permettant la saisie du mot de passe.

Si le disque est verrouillé, le contrôleur présente au système, non pas un disque dur, mais un pseudo-CD contenant le programme de saisie du mot de passe (pour Windows et Mac OS X¹). Le système exécute ce programme (via un mécanisme de type autorun je suppose pour Windows — je ne sais pas comment ça marche sous Mac OS X), après quoi le contrôleur présente au système le disque déverrouillé.

Donc si, il est apparemment possible d’implémenter toute la logique nécessaire dans le contrôleur USB du disque. « Possible » ne voulant naturellement pas dire « faisable par le premier bidouilleur venu ».

---

¹ La portabilité de ce dispositif est donc toute relative.

Mais qu'en est-il alors des disque durs WD plus précisement la gamme Passeport qui ont cette fonctionalité native ?

Sur ces disques aussi les données sont chiffrées.

C’est le contrôleur USB du disque qui se charge de chiffrer et déchiffrer les données de manière transparente pour le système (une fois que l’utilisateur a « déverouillé » le disque avec son mot de passe). Si tu veux plus de détails, une analyse de ces disques durs est disponible (en anglais).

Pour répondre à ta question initiale, non, ce n’est pas quelque chose que tu peux ajouter à un disque quelconque (ou alors il faut être un sacré bidouilleur, du genre à aller remplacer le contrôleur USB d’origine).

mon entropie disponible chute souvent¹

Un appel de note sans la note correspondante, c’est triste…

dès que je fais une mise à jour dynamique DNS, il descend à 0 pendant quelques minutes)

En général, c’est révélateur d’un programme qui fait un mauvais usage du générateur de nombres aléatoires, notamment en puisant directement tous les nombres dont il a besoin dans le pool d’entropie, au lieu de prendre seulement quelques octets et de les utiliser pour initialiser son propre CSPRNG (qu’il peut ensuite faire tourner à sa guise sans plus rien demander au système).

Par ailleurs, si le programme tape par défaut dans /dev/random (c’est le cas de dnssec-signzone il me semble), il ne faut pas hésiter à lui dire d’aller voir du côté de /dev/urandom.

Dans le même genre, il y a NeuG, un RNG pour microprocesseur STM32F103. Il est développé par Niibe Yutaka, un des développeurs de GnuPG qui est aussi à l’origine du token Gnuk, une implémentation de la carte OpenPGP.

Il peut être obtenu auprès de la FSF.

Bien pourri chez Adobe quand même de standardiser PDF et ensuite de balancer ces formulaires

Ils ont fait le même coup avec l’inclusion de vidéo dans un PDF. La version standardisée du format dispose de deux méthodes différentes pour inclure une vidéo (qui sont, au moins partiellement, prises en charge par les lecteurs libres), mais juste après la parution du standard ISO Adobe a ajouté une troisième méthode non-standard à base de Flash, que seules les versions Windows et Mac OS X de Acrobat Reader savent lire… Et évidemment, c’est maintenant devenue la méthode utilisée par défaut par Acrobat.

pour le moment Adobe fournit à 99% de la population (Mac et Windows)

Sachant que même Adobe a renoncé à implémenter la prise en charge des formulaires XFA dans les versions iOS et Android d’Acrobat Reader, et vu qu’il y a, me semble-t-il, de plus en plus de gens qui n’utilisent plus autre chose qu’une tablette (ou une « phablette ») en lieu et place d’un ordinateur généraliste (donc sans Windows ni MacOS X), je ne suis pas sûr que ce 99% reste vrai encore longtemps, ni même qu’il le soit encore maintenant.

Je suis quand même assez étonné qu'il n'y a pas plus de plaintes sur ce genre de documents quand ça vient de l'administration française (ce n'est pas le cas la, c'est du business), pas foule ne part en guerre contre l'administration à ce niveau?

Je ne suis pas plus étonné que ça.

J’ai été confronté à ce problème lors de mon embauche (fiche de renseignement à remplir). Qu’est-ce que j’allais faire, « partir en guerre » contre mon futur employeur et lui envoyer une longue explication sur la différence entre un PDF « standard » et un PDF « avec des bouts non-standard dedans » ? Bah non, j’ai rouspété dans mon coin tout en ressortant une vieille machine sous Windows XP…