Copyright © 2003-2008 Yves MARCOUX - GRDS1 Signature numérique et XML Signature Yves MARCOUX GRDS...

Copyright © 2003-2008 Yves MARCOUX - GRDS 1

Signature numériqueet XML Signature

Yves MARCOUX

GRDS – EBSI – Université de Montréal


Plan

• Signature numérique: concepts de base

• XML Signature: objectifs

• Mécanique générale

• Structure générale


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, l’expression « signature numérique » (en anglais, digital signature), bien qu’extrêmement répandue, est déconseillée par certains juristes


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é


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: SA

– Message: M– Message crypté avec la clé secrète de A: SA(M)


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...


Exemple 1

• Individu qui crypte: A

• Clé secrète de A: SA

• Message crypté: SA(M) = C

• Clé publique de A: PA

• Décryptage avec la clé publique de A: PA(C) = PA(SA(M)) = M

• On obtient le message originel M


Exemple 2

• Individu qui crypte: A

• Clé secrète de A: SA

• Message crypté: SA(M) = C

• Clé publique de X (autre que A): PX

• Décryptage avec la clé publique de X: PX(C) = PX(SA(M)) = M', différent de M

• M' a l'air d'une suite aléatoire de bits


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


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, SA(M), "AU=A"}



• Tout le monde connaît la clé publique (PA) de l'auteur prétendu (A) et peut l'utiliser pour décrypter le message crypté SA(M)

• Si le message en clair M et le message décrypté PA(SA(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é...



• 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 SA(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


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 queC = SA(M)

• Mais Z est incapable de produire SA(M), puisqu'il ne connaît pas SA



• Z produit donc un triplet

{M, C, "AU=A"}

où C est n'importe quoi, par exemple SZ(M), ou encore SA(M'), tiré de la signature d'un autre message M' produit précédemmentpar A



• Mais personne ne va croire que A est l'auteur de ce triplet, puisque:

PA(SA(M')) = M', qui n'a rien à voir avec M

ou bien:

PA(SZ(M)) = M'', un message apparemment aléatoire qui n'a rien à voir avec M non plus


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...


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)



• 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)



• 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...



Voici ma clé publique: PA

A Je te crois, mais juste pour être sûr, crypte donc ce message aléatoire R

BPas de problème, voici: SA(R)

Attends, je vérifie que PA(SA(R)) = R

OK, cool, j'ai noté que taclé publique est PA


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é...


À 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!)


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


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



• 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



• Pour signer un message M, un individu A produit maintenant un triplet de la forme:

{M, SA(M), CIA}

où CIA est le CI remis à A par le RA



• 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


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


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é]


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)


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é)


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


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


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


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!


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)


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)


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"


Transformations arbitraires

• Pour le XML: XPath, XSLT, Enveloped Signature (seule requise)

• Aussi, transformations arbitraires pour XML et d'autres formats


Exemple

• XML Signature détachée d’un fichier JPEG


[s01] <Signature Id="MyFirstSignature"xmlns="http://www.w3.org/2000/09/xmldsig#">

[s02] <SignedInfo>[s03] <CanonicalizationMethod

Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>[s04] <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>[s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">[s06] <Transforms>[s07] <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>[s08] </Transforms>[s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>[s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>[s11] </Reference>[s12] </SignedInfo>[s13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>[s14] <KeyInfo>[s15a] <KeyValue>[s15b] <DSAKeyValue>[s15c] <P>...</P><Q>...</Q><G>...</G><Y>...</Y>[s15d] </DSAKeyValue>[s15e] </KeyValue>[s16] </KeyInfo>[s17] </Signature>

Structure générale


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


Acquérir un certificat personnel?

• Endroit où vous pouvez vous procurer un certificat personnel gratuit:

http://www.thawte.com/email/index.html

Copyright © 2003-2008 Yves MARCOUX - GRDS1 Signature numérique et XML Signature Yves MARCOUX GRDS...

Documents

Transcript of Copyright © 2003-2008 Yves MARCOUX - GRDS1 Signature numérique et XML Signature Yves MARCOUX GRDS...