XML Signature Yves MARCOUX GRDS 30 octobre 2003

© 2003 Yves MARCOUX - GRDS2 Plan Signature numérique: concepts de base XML Signature: objectifs Mécanique générale Structure générale

© 2003 Yves MARCOUX - GRDS3 Concepts de base La signature numérique est basée sur la cryptographie à clé publique, dans laquelle: Chaque individu d'une collectivité possède une paire de clés: –une clé secrète (privée) connue seulement de l'individu –une clé publique, connue de toute la collectivité

© 2003 Yves MARCOUX - GRDS4 Cryptage avec une clé secrète Tout individu peut crypter un message avec sa clé secrète (en utilisant un algorithme standard, connu de tous) Exemple: –Individu: A –Sa clé secrète: S A –Message: M –Message crypté avec la clé secrète de A: S A (M)

© 2003 Yves MARCOUX - GRDS5 Décryptage avec une clé publique Tout individu peut décrypter un message crypté avec une clé publique (en utilisant un algorithme standard, connu de tous), mais... Le décryptage ne va donner quelque chose de sensé que si la clé publique utilisée correspond à la clé secrète utilisée pour le cryptage! Exemple...

© 2003 Yves MARCOUX - GRDS6 Exemple 1 Individu qui crypte: A Clé secrète de A: S A Message crypté: S A (M) = C Clé publique de A: P A Décryptage avec la clé publique de A: P A (C) = P A ( S A (M)) = M On obtient le message originel M

© 2003 Yves MARCOUX - GRDS7 Exemple 2 Individu qui crypte: A Clé secrète de A: S A Message crypté: S A (M) = C Clé publique de X (autre que A): P X Décryptage avec la clé publique de X: P X (C) = P X ( S A (M)) = M', différent de M M' a l'air d'une suite aléatoire de bits

© 2003 Yves MARCOUX - GRDS8 Pourquoi c'est comme ça? Au moment ou un individu se joint à la collectivité, les deux clés de sa paire sont générées ensemble, selon une méthode très précise (mais bien connue), de sorte que... Il existe une relation mathématique particulière très forte entre la clé secrète et la clé publique d'une paire, de sorte que... c'est comme ça!

© 2003 Yves MARCOUX - GRDS9 Idée de signature numérique (1/3) Les individus stockent ou transmettent leurs messages en double: une fois en clair, une fois cryptés avec leur clé secrète Ils stockent ou transmettent aussi (en clair) une métadonnée indiquant qu'ils sont l'auteur du message: A => {M, S A (M), "AU=A"}

© 2003 Yves MARCOUX - GRDS10 Idée de signature numérique (2/3) Tout le monde connaît la clé publique ( P A ) de l'auteur prétendu (A) et peut l'utiliser pour décrypter le message crypté S A (M) Si le message en clair M et le message décrypté P A ( S A (M)) sont identiques, cela prouve que c'est bien la clé secrète de l'auteur prétendu (A) qui a été utilisée pour générer le message crypté...

© 2003 Yves MARCOUX - GRDS11 Idée de signature numérique (3/3) Comme la clé secrète de l'auteur prétendu n'est connue que de celui-ci, on déduit que l'auteur réel est bien l'auteur prétendu! Les deux éléments S A (M) et "AU=A" constituent en quelque sorte la signature numérique de M par A, car ils nous permettent d'être sûrs que l'auteur réel de M est bien A

© 2003 Yves MARCOUX - GRDS12 Essais de forger une signature (1/3) Z veut produire un triplet {M, C, "AU=A"} et faire croire que A en est l'auteur Pour que ça marche, il faudrait que C = S A (M) Mais Z est incapable de produire S A (M), puisqu'il ne connaît pas S A

© 2003 Yves MARCOUX - GRDS13 Essais de forger une signature (2/3) Z produit donc un triplet {M, C, "AU=A"} où C est n'importe quoi, par exemple S Z (M), ou encore S A (M'), tiré de la signature d'un autre message M' produit précédemment par A

© 2003 Yves MARCOUX - GRDS14 Essais de forger une signature (3/3) Mais personne ne va croire que A est l'auteur de ce triplet, puisque: P A ( S A (M')) = M', qui n'a rien à voir avec M ou bien: P A ( S Z (M)) = M'', un message apparemment aléatoire qui n'a rien à voir avec M non plus

© 2003 Yves MARCOUX - GRDS15 Comment gérer les paires de clés? Première hypothèse: un responsable unique, jugé digne de confiance par toute la collectivité, génère les paires de clés de tout le monde et fait une distribution adéquate Problème: le responsable connaît toutes les clés secrètes et peut (de son plein gré ou sous une menace quelconque) signer n'importe quoi au nom de n'importe qui...

© 2003 Yves MARCOUX - GRDS16 On peut faire mieux... (1/4) Deuxième hypothèse: chacun génère sa paire de clés sur son propre ordinateur et la clé secrète ne sort jamais de cet ordinateur Chaque membre de la collectivité fait connaître sa clé publique et prouve son identité aux autres membres à l'occasion de rencontres en personne (Internet n'étant pas assez sécuritaire)

© 2003 Yves MARCOUX - GRDS17 On peut faire mieux... (2/4) Une preuve d'identité suffisante (bail, hypothèque, etc.) doit être fournie par un membre à un autre Cette preuve doit être notée pour référence en même temps que la clé publique Dans une collectivité de n individus, chaque personne doit effectuer n-1 rencontres (pour une vérifiabilité universelle)

© 2003 Yves MARCOUX - GRDS18 On peut faire mieux... (3/4) Au moment où un membre A communique sa clé publique à un autre membre B, B vérifie que A possède bien la clé secrète correspondante en lui demandant de crypter (sans consulter personne) un message aléatoire Sans ce test, A pourrait refiler à B une clé publique obtenue d'un autre membre...

© 2003 Yves MARCOUX - GRDS19 On peut faire mieux... (4/4) Voici ma clé publique: P A A Je te crois, mais juste pour être sûr, crypte donc ce message aléatoire R B Pas de problème, voici: S A (R) Attends, je vérifie que P A ( S A (R)) = R OK, cool, j'ai noté que ta clé publique est P A

© 2003 Yves MARCOUX - GRDS20 Problèmes de croissance... Chaque nouveau membre se joignant à la collectivité doit rencontrer tout le monde en personne pour un échange de clés publiques et de preuves d'identité (pour une vérifiabilité universelle) Fastidieux, surtout quand n devient grand! Aussi: tout le monde n'est pas en mesure de vérifier à fond une preuve d'identité...

© 2003 Yves MARCOUX - GRDS21 À ne pas faire! Accepter une clé publique sans preuve d'identité ou sans faire le test précédent Noter une clé publique sans noter aussi pour référence la preuve d'identité Accepter une preuve d'identité par courriel (à moins que la possession de l'adresse courriel de l'envoyeur soit une preuve jugée suffisante!)

© 2003 Yves MARCOUX - GRDS22 Rentabiliser les rencontres... La collectivité s'entend sur un responsable des adhésions, jugé digne de confiance, qui vérifie une seule fois (mais rigoureusement) l'identité des nouveaux membres, par une rencontre en personne Les membres effectuent un seul échange de clés publiques, avec le responsable des adhésions seulement

© 2003 Yves MARCOUX - GRDS23 Comment ça marche? (1/4) Après vérification de l'identité du candidat et de sa clé publique, le responsable des adhésions (RA) génère un certificat d'identité (CI) qu'il signe (avec sa clé secrète de RA) et remet directement au candidat

© 2003 Yves MARCOUX - GRDS24 Comment ça marche? (2/4) Le CI est un triplet contenant: –Comme message en clair: L'identité du candidat telle qu'établie par le RA Les preuves d'identité vérifiées par le RA La clé publique du candidat –Comme message crypté: le même message, crypté avec la clé secrète du RA –Une métadonnée identifiant le RA comme auteur du triplet

© 2003 Yves MARCOUX - GRDS25 Comment ça marche? (3/4) Pour signer un message M, un individu A produit maintenant un triplet de la forme: {M, S A (M), CI A } où CI A est le CI remis à A par le RA

© 2003 Yves MARCOUX - GRDS26 Comment ça marche? (4/4) Si on fait confiance au RA, un CI prouve que la clé publique qu'il contient appartient à la personne qui y est identifiée et que l'identité de cette personne a été contrôlée Vérifiabilité universelle sans échange préalable de clés publiques ou de CI La croissance de la collectivité touche seulement le RA, pas les autres membres

© 2003 Yves MARCOUX - GRDS27 Menus détails d'implantation... Condensés de messages (digest) Omettre / pointer vers le certificat Algorithmes: cryptage, condensation Formats de certificats Autorités de certification, ICP Chaînes de certificats Révocation de certificats

© 2003 Yves MARCOUX - GRDS28 Condensés de messages Inefficace de crypter le message au long On calcule puis on crypte un "condensé" mathématique plus court (digest) du message => plus efficace Fonction de condensation: la moindre modification à un message donne un condensé différent [avec grande probabilité]

© 2003 Yves MARCOUX - GRDS29 Omettre / pointer vers un certificat Un certificat n'a rien de confidentiel Il suffit que le certificat soit accessible quelque part et qu'on puisse y pointer Un pointeur au certificat peut se trouver dans le message en clair Le certificat peut être implicite (si c'est toujours la même personne qui signe)

© 2003 Yves MARCOUX - GRDS30 Algorithmes: cryptage, condensation Il existe plusieurs algorithmes différents pour le cryptage et la condensation Pour interopérabilité, la signature doit faire mention des algorithmes utilisés Plus connus: –Cryptage: DSA, RSA (1978, Turing Award 2002) –Condensation: SHA-1, MD5 (déconseillé)

© 2003 Yves MARCOUX - GRDS31 Formats de certificats Certificats contiennent beaucoup de choses: –Owner's public key –Owner's name –Expiration date –Name of the issuer –Serial number of the certificate –Digital signature of the issuer –Mentions d'utilisation Pour interopérabilité, format normalisé X509v3 est le format le plus répandu

© 2003 Yves MARCOUX - GRDS32 Autorités de certification, ICP RA autorité de certification (AC, CA) Une seule AC a trop de travail Une AC va autoriser d'autres instances à agir à sa place en leur émettant un certificat spécial à cette fin Détermine une hiérarchie d'AC ICP Une ou quelques AC "racines" prédéfinies

© 2003 Yves MARCOUX - GRDS33 Chaînes de certificats À cause de la structure d'ICP, on peut avoir besoin d'une chaîne de certificats remontant jusqu'à une AC racine pour vérifier une signature numérique

© 2003 Yves MARCOUX - GRDS34 Révocation de certificats En plus d'une date d'expiration interne, les ICP prévoient la possibilité de révoquer prématurément un certificat Dans le monde X.509: les AC diffusent des "listes de révocation": Certificate Revocation List (CRL) Mécanique semble lourde, peu implantée

XML Signature... enfin!

© 2003 Yves MARCOUX - GRDS36 XML Signature: objectifs Fournir un cadre normalisé pour la signature numérique, entre autres de documents XML, mais pas exclusivement Préoccupation d'interopérabilité des signatures numériques, et donc en particulier, des certificats Supporte aussi les MAC (clés secrètes)

© 2003 Yves MARCOUX - GRDS37 Mécanique générale Canonicalisation (c14n) du XML Transformations arbitraires Permet de signer conjointement n'importe quel ensemble de ressources (instance, schéma, feuilles de styles, scripts, etc.) Identification normalisée des différents algorithmes (c14n, transformations, condensation, cryptage)

© 2003 Yves MARCOUX - GRDS38 Canonicalisation (c14n) But: rendre la signature indépendante des différentes représentations internes d'un document XML, de façon à obtenir la vérifiabilité universelle Trois versions standard: –Avec commentaires (seule obligatoire) –Sans commentaires –C14n "exclusive"

© 2003 Yves MARCOUX - GRDS39 Transformations arbitraires Pour le XML: XPath, XSLT, Enveloped Signature (seule requise) Aussi, transformations arbitraires pour XML et d'autres formats

© 2003 Yves MARCOUX - GRDS40 [s01] <Signature Id="MyFirstSignature" xmlns=" [s02] [s03] <CanonicalizationMethod Algorithm=" [s04] [s05] [s06] [s07] [s08] [s09] [s10] j6lwx3rvEPO0vKtMup4NbeVu8nk= [s11] [s12] [s13] MC0CFFrVLtRlk=... [s14] [s15a] [s15b] [s15c] [s15d] [s15e] [s16] [s17] Structure générale

© 2003 Yves MARCOUX - GRDS41 Caractéristiques additionnelles Encodage "base-64" pour toutes les valeurs binaires Possibilité de références multiples dans SignedInfo, et même de référer à un "manifest", contenant lui-même plusieurs références Enveloped, enveloping, detached signature

Merci!