Copyright © Yves MARCOUX - GRDS1 Signature numérique et XML Signature Yves MARCOUX GRDS – EBSI – Université de Montréal

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

Copyright © Yves MARCOUX - GRDS3 Mise en garde terminologique « Signature numérique » désigne un ensemble de technologies, et non une notion juridique ! La notion juridique de signature serait apparamment incompatible avec celle de signature numérique Pour cette raison, lexpression « signature numérique » (en anglais, digital signature), bien quextrêmement répandue, est déconseillée par certains juristes

Copyright © Yves MARCOUX - GRDS4 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é

Copyright © Yves MARCOUX - GRDS5 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)

Copyright © Yves MARCOUX - GRDS6 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...

Copyright © Yves MARCOUX - GRDS7 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

Copyright © Yves MARCOUX - GRDS8 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

Copyright © Yves MARCOUX - GRDS9 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, relation qui leur confère leurs propriétés

Copyright © Yves MARCOUX - GRDS10 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"}

Copyright © Yves MARCOUX - GRDS11 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é...

Copyright © Yves MARCOUX - GRDS12 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

Copyright © Yves MARCOUX - GRDS13 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

Copyright © Yves MARCOUX - GRDS14 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

Copyright © Yves MARCOUX - GRDS15 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

Copyright © Yves MARCOUX - GRDS16 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...

Copyright © Yves MARCOUX - GRDS17 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)

Copyright © Yves MARCOUX - GRDS18 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)

Copyright © Yves MARCOUX - GRDS19 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...

Copyright © Yves MARCOUX - GRDS20 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

Copyright © Yves MARCOUX - GRDS21 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é...

Copyright © Yves MARCOUX - GRDS22 À 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!)

Copyright © Yves MARCOUX - GRDS23 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

Copyright © Yves MARCOUX - GRDS24 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

Copyright © Yves MARCOUX - GRDS25 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

Copyright © Yves MARCOUX - GRDS26 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

Copyright © Yves MARCOUX - GRDS27 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

Copyright © Yves MARCOUX - GRDS28 Considérations diverses (plan) 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

Copyright © Yves MARCOUX - GRDS29 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é]

Copyright © Yves MARCOUX - GRDS30 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)

Copyright © Yves MARCOUX - GRDS31 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é)

Copyright © Yves MARCOUX - GRDS32 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

Copyright © Yves MARCOUX - GRDS33 Autorités de certification, ICP RA autorité de certification (AC, CA) –« Tiers de confiance » 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

Copyright © Yves MARCOUX - GRDS34 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

Copyright © Yves MARCOUX - GRDS35 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

Copyright © Yves MARCOUX - GRDS36 XML Signature... enfin!

Copyright © Yves MARCOUX - GRDS37 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)

Copyright © Yves MARCOUX - GRDS38 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)

Copyright © Yves MARCOUX - GRDS39 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"

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

Copyright © Yves MARCOUX - GRDS41 Exemple XML Signature détachée dun fichier JPEG

Copyright © Yves MARCOUX - GRDS42 [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

Copyright © Yves MARCOUX - GRDS43 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

Copyright © Yves MARCOUX - GRDS44 Acquérir un certificat personnel? Endroit où vous pouvez vous procurer un certificat personnel gratuit: