Skip to the content.

TD 5 : DANE/PGP

François Lesueur (francois.lesueur@insa-lyon.fr)

Ce TD présente les modèles de PKI “DANE” et “PGP/Web of trust”. Comme pour le cas de la CA, ces PKI doivent permettre de valider la clé publique tierce obtenue pour une identité demandée.

Dans le mode distanciel, réfléchissez en groupes de 4 dans des salons de discussion spécifiques. Des éléments de réponse sont accessibles pour chaque question (en cliquant sur les questions) : réfléchissez sans ces éléments, puis regardez et intégrez ces éléments. L’enseignant fera le tour des groupes pour échanger sur les points nécessaires.

Notations

DANE

Avec DANE, les certificats ou clés publiques sont stockés directement dans les zones DNS, qui doivent alors être signées avec DNSSEC.

Un peu de DNS

Allez vraiment lire la ressource donnée dans le cours Bortzmeyer, pages 3 à 9 et 18 à 19, ainsi que Sebsauvage jusque “Dans ce cas, ils sont à la fois registry et registrar.”. Les caches sont aussi illustrés ici @b0rk.

  1. Qui héberge le contenu de la zone `'.fr'` ?L'AFNIC (un registry)
  2. Qui vend le service d'enregistrer un `'.fr'` ?OVH, Gandi, etc. (des registrars)
  3. Quelle chaîne commerciale/interactions d'un possesseur de nom de domaine à un registry ?INSA Lyon cliente d'un registrar (Gandi par exemple), ce registrar en interaction avec un grand nombre de registries (Afnic par exemple, un registry par extension/TLD proposé (plus ou moins))
  4. Pour résoudre `www.insa-lyon.fr`, quels acteurs sont impliqués ?L'ICANN pour donner l'IP de `.fr`, l'AFNIC pour donner l'IP de `insa-lyon.fr`, l'INSA Lyon pour donner l'IP de `www.insa-lyon.fr`

Un peu de DNSSEC (principe simplifié)

DNSSEC dispose d’une paire de clés racine, responsable de signer la zone racine '.'. Chaque niveau de hiérarchie (TLD, domaine, etc.) possède ensuite sa propre paire de clés (donc Pubfr./Privfr., Pubinsa-lyon.fr./Privinsa-lyon.fr., etc.), signée par la zone supérieure et utilisée pour signer la zone courante et les clés des zones descendantes directes.

  1. Proposez un schéma clés/signatures allant jusqu'à la zone `'insa-lyon.fr'` contenant notamment une entrée pour `'www'` (quelle clés, qui signe qui, avec quelle clé, qui connaît quelle clé).Les clés impliquées : Pub./Priv., Pubfr./Privfr., Pubinsa-lyon.fr./Privinsa-lyon.fr.
    Priv. est sous le contrôle de l'ICANN, Privfr. est sous le contrôle de l'AFNIC, Privinsa-lyon.fr. sous le contrôle de l'INSA. Quand un insa-lyon.fr enregistre sa clé via son registrar (ex par GANDI), GANDI pousse cette clé vers l'AFNIC qui l'enregistre dans la zone .fr et la signe avec sa clé privée.

    Et on a :

    Pubfr.. (signé par .)
    Pub.insa-lyon.fr..fr. (signé par .fr)
    le champ A `www.insa-lyon.fr` signé par Privinsa-lyon.fr.
  2. La modification d'une zone demande-t-elle du travail supplémentaire aux zones supérieures ?Non, tout est cloisonné, la modification de l'IP de www.insa-lyon.fr demande juste à être re-signée par la clé de insa-lyon.fr. Besoin d'au-dessus uniquement pour changer la clé de insa-lyon.fr

Il s’agit ici du principe très simplifié (et donc faux) de DNSSEC. Il y a en réalité 2 paires de clés à chaque instant pour chaque zone, la paire KSK (Key Signing Key) et ZSK (Zone Signing Key), des règles de roulement et un grand nombre de détails, DNSSEC est un protocole très compliqué. Ces spécificités ne sont cependant pas nécessaires pour comprendre le principe de DANE.

Mise en œuvre

  1. Comment intégrer un enregistrement contenant une clé publique à la zone ?Un champ spécifique (TLSA au lieu de A pour une IP) contient une clé publique/un hash de clé publique
  2. Comment cet enregistrement est-il signé ?Par la clé privée de la zone
  3. Quelle est sa chaîne de confiance associée ?zone, TLD, root DNS

Risques

  1. Quel impact si un attaquant obtient ma clé privée de zone (`'insa-lyon.fr'`) ?Compromission de ma zone pour tous les clients du monde
  2. Quel impact si ma zone parente est maveillante ou compromise (`'.fr'`) ?Compromission de ma zone pour tous les clients du monde
  3. Quel impact si une zone DNS non liée (par exemple `'.tv'` dans notre cas) est compromise ?Aucun impact sur ma zone (différent du modèle CA, les défaillances sont cloisonnées, 1 mauvais ne compromet pas l'ensemble du système)

Gestion de la révocation

  1. En cas de vol de la clé privée du serveur web, comment révoquer son certificat ? Sous quel délai cela sera-t-il effectif ? Qui est impacté par la vérification de cette mise à jour ?Modif de la zone, resignage avec ma clé de zone. Délai : pas immédiat, pas de contrôle, temps de propagation DNS. Court (heures/jour) mais pas immédiat et sans contrôle. Contrairement aux CRL, c'est l'infra DNS qui supporte ce coût et il n'y a pas vraiment de surcoût (sauf si on réduit les TTL)
  2. En cas de vol de la clé privée de la zone, comment la révoquer ? Sous quel délai cela sera-t-il effectif ? Quel est le coût associé ?Révocation par la zone parente, qui est donc à impliquer. Délai de propagation aussi mais non maîtrisé (ie, le TTL de la zone .fr). Pas de coût particulier.
  3. En cas de vol de la clé privée racine, comment réagir ?Là, on a un gros problème, c'est l'ancre de confiance. De manière similaire à une CA compromise, il faut déployer une nouvelle clé chez les clients et donc mise à jour software des clients DNS pour intégrer une autre clé racine.

Le modèle et les risques associés sont donc assez différents. Mais, fondamentalement, c’est profiter d’un annuaire live et (presque) à jour déjà existant pour rendre ce service.

PGP

Avec PGP, chaque utilisateur est représenté par une paire de clés et peut être vu comme une mini autorité de certification.

Initialisation

Chaque utilisateur génère sa paire de clés publique/privée. La clé publique est classiquement téléversée sur un serveur afin de pouvoir être téléchargée par quiconque le souhaitant.

Quelles garanties peut-on avoir sur une clé simplement téléchargée pour l'adresse mail `'toto@acme.org'` ?Aucune évidemment, c'est comme la demander directement à la personne à travers ce medium de communication non sécurisé

Reconnaissance de clés tierces

L’idée au centre de la toile de confiance (web of trust) est de signer les clés tierces que l’on a vérifiées (personnes que l’on connaît, key-signing parties). Chaque signature est décorée d’une valeur exprimant la confiance associée, par exemple :

L’agrégation de toutes ces signatures permet de modéliser le graphe de confiance.

Considérons ce graphe de confiance (chaque nom est l’alias d’une adresse mail) : pgp

Chaque arc allant de A vers B a 2 valeurs :

Évaluez la récupération de quelques clés et le score associé :

  1. La clé de Henry par JesseLe meilleur chemin est Jesse-Walter-Henry. Jesse a une confiance correcte en Walter pour certifier (la flèche moyenne), puis Henry a une forte confiance en l'identité qu'il associe à la clé de Henry. C'est un bon chemin et Jesse peut récupérer la clé de Henry ainsi avec une bonne confiance.
  2. La clé de Jesse par SaulLe meilleur chemin est Saul-Walter-Jesse. Saul a très peu confiance en Walter (flèche pointillée) pour vérifier les identités et donc le chemin ne valide pas. L'autre chemin Saul-Mike-Walter-Jesse bute également sur le chemin pointillé entre Mike et Walter

Concrètement, chaque arc/valuation est signée par son émetteur, Walter signe ainsi par exemple un message décrivant qu’il a une confiance (3, gras) vis-à-vis de la clé de Henry. Ces messages signés sont déposés et accessibles publiquement sur un serveur de clés. L’ensemble de tous ces messages signés définit le graphe de confiance tel que représenté ici.

Il s’agit ainsi de parcourir le graphe, trouver les meilleurs chemins satisfaisant un seuil de confiance minimal. Plus le chemin est long plus la confiance va baisser (très vite), la présence de chemins multiples et disjoints peut ré-améliorer ce score. Il faut bien distinguer la confiance dans une identité (le nombre, ne dépend pas de l’attitude de la cible) de la confiance dans le comportement de la cible (l’épaisseur de la flèche). Chaque utilisateur a un rôle à jouer : bien faire son travail, et évaluer le travail qui sera fait par les autres. C’est difficile !

Composantes malicieuses

Imaginons qu’un attaquant crée un grand nombre d’identités et signe une clé pour l’adresse mail 'Henry@fbi.gov'.

pgp2

  1. Évaluez la récupération de la clé de Henry par JesseAucun changement, la recherche ne peut pas rentrer dans la composante malicieuse qui est inatteignable pour Jesse
  2. Considérons maintenant que certaines personnes du graphe de confiance ne sont pas très regardantes sur leur validation et que Mike certifie William (score 3, gras). Évaluez la récupération de la clé de Henry par SaulCette fois-ci, Saul va récupérer une mauvaise clé. Évidemment, il ne peut pas le savoir. Le chemin, pour cet exemple, est un peu long (Saul-Mike-William-Henry) et serait peut-être, en pratique, refusé, chaque saut dégradant le score. Mais c'est l'idée de ce risque.
  3. Quelles conclusions pouvons-nous en tirer sur la robustesse aux attaquants ?La robustesse aux attaquants est liée au bon usage de l'outil par chacun (ici, Mike n'a pas bien évalué la confiance à accorder à William, mais Saul est également en faute d'avoir lui-même accordé trop de confiance à Mike). L'usage est donc complexe, ce qui nuit à la sécurité finale.

Révocation

Comme pour toute PKI, il faut prévoir le cas de la perte ou du vol de clés privées.

  1. Dans le cas où une clé privée serait compromise mais toujours connue, quelle réaction est possible ? on peut signer une révocation et l'enregistrer dans les serveurs de clés
  2. Dans le cas où une clé privée est perdue, quelle réaction est possible ? rien, plein de clés fantômes dans les serveurs de clé. Pire, si un attaquant la vole et nous l'efface, il l'a, peut l'utiliser légitimement, et nous on ne peut pas la révoquer... À la création de clé, l'outil gpg prépare une révocation, qu'il demande de stocker à part et de manière pérenne pour pouvoir garantir qu'on pourra révoquer si besoin, mais plein de gens ne le font pas. Pas d'autorité supérieure qui peut révoquer des clés.