Un partenaire envoie une clé publique et demande un lot chiffré. Le chiffrement fonctionnera, et il peut livrer un justificatif parfaitement protégé à quelqu’un qui ne devrait pas l’avoir. Le secret et l’identité du destinataire sont deux questions différentes auxquelles répondent des mécanismes différents. Répondez aux deux avant que le lot quitte votre machine.

Deux questions différentes : le secret et le destinataire

Le chiffrement répond qui peut lire le fichier, en supposant que la clé appartient à la personne prévue. Une signature répond qui l’a produit, et ne dit rien de la confidentialité, car un fichier signé peut rester lisible. Une empreinte identifie une clé, et seule une vérification indépendante relie cette empreinte à une personne ou à un rôle. Traiter l’une de ces choses comme les autres est l’échec habituel d’une remise qui paraît soignée.

Le fichier a aussi un cycle de vie : un lien qui expire limite la récupération ultérieure, mais il ne révoque pas un justificatif déjà téléchargé.

Vérifiez l’empreinte hors bande

Obtenez l’empreinte attendue par un canal qui ne dépend pas du message vous demandant de chiffrer. Comparez-la ensuite avec ce que contient le trousseau local.

gpg --fingerprint [email protected]
gpg --list-keys --with-fingerprint [email protected]

Les lignes d’empreinte sont la valeur à comparer, et la seconde commande montre les mêmes identités avec leurs empreintes complètes pour un second regard. Confirmez la chaîne complète par un appel, un inventaire signé ou un registre d’inscription géré ; un nom affiché familier ne prouve rien. Si la clé est arrivée dans le même message que celui qui demandait la livraison, son empreinte n’est pas une preuve indépendante. N’importez la clé qu’après cette vérification, et chiffrez vers l’empreinte vérifiée plutôt que vers un nom.

Ne livrez que le matériel dont l’appareil a besoin

Inventoriez le lot avant de choisir un transport. Les paramètres publics de la passerelle et un certificat de confiance public relèvent de la configuration, une clé privée de client est un secret, et une clé de signature d’émetteur est un actif entièrement différent. Là où le modèle d’inscription le permet, gardez la clé privée sur l’appareil et ne livrez que ce qui achève l’inscription. Un client VPN n’a pas besoin de la clé de signature de l’autorité de certification pour valider un serveur, et une clé vivante partagée entre partenaires rend la révocation individuelle impossible.

Signez aussi l’artefact lorsque le destinataire doit détecter une substitution, et gardez les deux opérations séparées dans les instructions. Gardez un lot de plusieurs fichiers dans une seule archive, afin que le destinataire ne puisse pas installer la moitié d’une configuration puis signaler que la passerelle refuse l’identité.

Fermez le cycle de vie après la livraison

Enregistrez le destinataire, l’appareil, la révision de configuration et la voie de révocation, mais jamais la valeur privée elle-même. Confirmez que la personne prévue peut s’inscrire et qu’une autre identité est refusée. Si le lot tombe entre de mauvaises mains, remplacez ou révoquez le secret accepté par son émetteur, car supprimer une pièce jointe n’invalide rien de ce qui a déjà été téléchargé. Une archive protégée par un mot de passe qui circule dans la même conversation n’est pas non plus une vérification indépendante.

Une remise est terminée quand la bonne identité est active sur le bon appareil, pas quand le fichier chiffré se téléverse avec succès.

Articles similaires