certification electronique en cryptographie.ppt

• 1. Besoins en sécurité sur Internet
1.1 Limites de la sécurité par mot de passe
1.2 Authentification sur Internet
1.3 Confidentialité et non répudiation
1.4 Intégrité des échanges
• 2. Technologie à clé publique
2.1 Techniques utilisées par la certification
2.2 Chiffrement
2.2.1 Chiffrement symétrique
2.2.2 Chiffrement asymétrique
2.3 Hachage
2.4 Signature

• 3. Certificats et infrastructure de gestion de clés
3.1 Contenu d’un certificat
3.2 Rôle des serveurs de certification
3.3 Processus de certification
3.4 Annulation des certificats
3.5 Hiérarchies de certification
3.6 Éléments de l’infrastructure de gestion de clés
3.7 Standardisation
• 4. Utilisation des certificats
4.1 Protocoles et formats utilisant les certificats
4.1.1 Authentification dans les transactions électroniques par SSL/T
4.1.2 Courrier électronique
4.1.3 EDI et XML
4.1.4 Paiement sécurisé avec SET
4.1.5 Réseaux privés virtuels

4.2 Utilisation pratique des certificats
4.2.1 Commerce d’entreprise à entreprise
4.2.2 Carte professionnelle de santé
4.2.3 Paiement de la TVA et déclaration de revenus
4.2.4 Notaires
4.2.5 Appels d’offres
4.2.6 Industrie pharmaceutique
5. Sécurité et support des certificats
6. Conclusion
Annexe
1 Réglementation
2 Organismes

• Tout échange ou tout type de commerce sur un réseau informatique, et
notamment sur Internet, nécessite une fonction qui permette aux parties en
présence de s’identifier mutuellement. Une fois identifiées, les parties vont
ensuite vouloir participer à des transactions, celles-ci consistant en des
échanges de commandes, de factures, de paiements et de documents en
général.
• Considérons, par exemple, le cas de l’achat d’actions sur Internet auprès
d’un courtier. Le problème se pose pour le courtier et l’acheteur de
s’identifier mutuellement, c’est-à-dire de s’assurer de l’identité du
partenaire. Mais cela n’est pas suffisant : le courtier doit pouvoir prouver
que l’acheteur a bien commandé le type et le nombre donné d’actions, et
l’acheteur doit être sûr que sa commande a bien été prise en compte par le
courtier.
• Afin d’atteindre, au cours d’échanges sur un réseau informatique, le même
degré de confiance que dans la vie réelle où les documents physiques
échangés sont munis d’une signature manuscrite, il va falloir être capable de
reproduire de façon électronique l’identification mutuelle des acteurs d’une
transaction ainsi que la signature des documents liés à cette transaction.

• L’identification par mot de passe et même le chiffrement des informations
échangées ne suffisent pas à répondre au besoin décrit précédemment. La
réponse est fournie par un processus de certification des utilisateurs
s’appuyant sur un ensemble de fonctions constituant une infrastructure de
gestion de clés et permettant une signature numérique des documents
échangés.
• Ce type de processus est déjà employé de façon opérationnelle aujourd’hui
dans des échanges transactionnels, et notamment dans le protocole de
paiement sécurisé SET (Secure Electronic Transaction). Les fonctions et les
produits que nous allons décrire vont permettre de réaliser tout autre type
de commerce sur les réseaux, au sens large, débordant largement le cadre
du paiement pour le commerce électronique.
• Nous allons tout d’abord citer les besoins en sécurité sur Internet puis
nous décrirons brièvement les techniques utilisées pour répondre à
l’exigence d’identification et par conséquent au besoin de certification.
• Ensuite, nous présenterons la notion de « certificat électronique » ainsi
que les fonctions des autorités de certification chargées de délivrer des
certificats.

• Afin d’illustrer notre propos, nous présenterons quelques protocoles
standards ainsi que des applications pratiques faisant usage des
certificats.
• Nous insistons sur Internet parce que c’est le mode d’utilisation du réseau
présentant le plus de risques en terme de sécurité. Mais puisque la
certification s’applique à tout mode d’utilisation et à tout protocole de
réseau, elle peut très bien être employée pour assurer l’identification
d’utilisateurs d’une même entreprise sur un réseau intranet.

• 1. Besoins en sécurité sur Internet
• 1.1 Limites de la sécurité par mot de
passe
1.2 Authentification sur Internet
1.3 Confidentialité et non répudiation
1.4 Intégrité des échanges

• Parler du problème de la sécurité des échanges sur Internet est chose
courante, en général pour dire combien commercer sur ce réseau est
risqué. Le fait que les données circulent sur des réseaux ouverts à tous et
que les serveurs ou postes de travail soient susceptibles d’être accédés de
n’importe quel point du globe peut donner des inquiétudes. Quels sont
donc les problèmes de sécurité à résoudre lorsque l’on veut faire du
commerce électronique (au sens de transaction commerciale) sur
Internet ? Nous en voyons plusieurs que nous allons décrire après une
parenthèse relative à une question de terminologie.
• En langage informatique, on distingue l’identification consistant à
associer un identificateur simple (par exemple un nom court) à une
personne donnée et l’authentification consistant à vérifier, par tout
moyen approprié (mot de passe, carte à puce, etc.), que la personne ainsi
identifiée est bien celle se présentant sous cet identificateur. Cette
terminologie provient des pays anglo-saxons (par simple analogie avec
authentication). En France, le terme authentification désigne
principalement l’action de créer des actes authentiques en faisant
intervenir des officiers publics (notaires, officiers d’État civil, etc.).

• Afin de respecter l’usage courant chez les informaticiens, nous utiliserons
dorénavant le terme d’authentification dans son sens de vérification
informatique d’une identité.
• Authentification des acteurs des transactions : il est important que les
acteurs d’une transaction puissent vérifier mutuellement leur identité.
• Exemple :
• la banque doit pouvoir authentifier son client qui effectue des transactions à
l’aide de son application de banque à domicile qu’elle a mise à sa disposition.
• Intégrité des données échangées : il ne faut pas que les données échangées
entre les acteurs puissent être modifiées de façon frauduleuse par
quiconque. C’est notamment le cas du contenu des commandes et des prix
associés à cette commande, ou bien le nombre et le prix des actions achetées
à un courtier.
• Confidentialité des données : certaines données n’ont pas à être connues de
tiers, par exemple les données d’une carte de paiement, le montant d’une
transaction, le solde d’un compte ou bien l’état des stocks d’une entreprise.
Elles pourraient être utilisées frauduleusement par une personne indélicate.

• Non répudiation : la répudiation d’une transaction (bancaire ou autre)
consiste, pour l’initiateur de la transaction, à nier avoir effectué cette
transaction. Cela serait d’autant plus facile en informatique s’il n’y avait pas
de signature attachée à la transaction. Il faut donc pouvoir créer
électroniquement l’équivalent de la signature manuscrite qui, habituellement,
authentifie l’auteur de la transaction.
• Contrôle d’accès : il faut pouvoir mettre en place des politiques et des
protocoles d’accès aux données sensibles d’un système. Ces politiques vont
définir, pour chaque personne ayant un droit d’accès au système, le type de
données accessibles et les droits de cette personne sur ces données.
• Auditabilité : la sécurité n’est pleinement assurée que si l’on prend note de
tout événement important lié à la sécurité (délivrance d’un certificat,
tentative d’accès non autorisé, etc.).
• 1.1 Limites de la sécurité par mot de passe
• Traditionnellement, les organisations enregistraient leurs utilisateurs et
contrôlaient leur accès aux applications (sur un réseau intranet généralement)
à l’aide d’identificateurs et de mots de passe.

• L’identificateur permettait de relier l’utilisateur à un individu, le mot de passe
étant la preuve de ce lien. Cependant, un mot de passe n’assure pas toujours
la sécurité demandée car il présente les inconvénients suivants :
• 1. il peut être observé au moment de la frappe ;
• 2. il peut être intercepté sur le réseau s’il n’est pas chiffré ;
• 3. il ne permet une authentification que dans un seul sens ; il ne permet pas à
l’utilisateur d’authentifier le serveur ;
• 4. il peut souvent être découvert par essai/erreur ;
• 5. une fois l’authentification terminée sur le réseau, l’information échangée
par la suite n’est pas protégée contre une modification éventuelle. Les
données reçues ultérieurement par le serveur ne proviennent pas forcément
de l’utilisateur ayant présenté initialement son mot de passe ;
• 6. les mots de passe doivent être stockés sur un serveur. Même chiffrés, ils
restent vulnérables car les utilisateurs assignent souvent des mots de passe
triviaux.
• Ces points énumérés sont valables quel que soit le type de réseau employé.
Toutefois, Internet augmente encore le danger d’utilisation des mots de passe
car le réseau est accessible à tous.

• Ainsi les fraudeurs peuvent soit « écouter » la ligne de communication
(point 2), soit modifier le contenu des messages (point 5), soit se substituer
à un vrai serveur pour en extraire des informations confidentielles (point 3).
Enfin, avec Internet, les entreprises souhaitent fournir un accès à un grand
nombre d’utilisateurs qu’elles ne connaissent pas nécessairement.
Comment attribuer un nom d’utilisateur et un mot de passe à une personne
que vous ne connaissez pas ? Il peut être plus simple de faire certifier
l’identité de ces personnes par un tiers auquel l’entreprise peut se fier.
• 1.2 Authentification sur Internet
• Il faut donc disposer d’un moyen d’authentification beaucoup plus sûr et
plus adapté au contexte de l’Internet que les mots de passe. Ce moyen
repose sur une infrastructure de gestion de clés utilisant notamment :
• des techniques de chiffrement à clé publique;
• des certificats permettant de décrire et de prouver l’identité de ceux qui les
possèdent ;

• des serveurs, autorités de certification, permettant de délivrer des certificats
à des utilisateurs, après vérification approfondie de leur identité ;
• un annuaire pour publier les certificats créés ;
• des moyens de vérification de la validité des certificats.
• 1.3 Confidentialité et non répudiation
• Le fait de réaliser une authentification n’assure pas pour autant la sécurité
des échanges qui vont suivre. Il faut, en plus, chiffrer les données échangées,
ce qui suppose que les deux parties en relation partagent la même méthode
de chiffrement.
• Cette protection du contenu des échanges vis-à-vis des tiers ne protège
pourtant pas suffisamment un partenaire par rapport à l’autre. En effet, l’un
des deux partenaires peut ultérieurement réfuter le contenu des messages
qu’il a envoyés. Pour assurer la non répudiation, il faut ajouter une signature
électronique aux messages échangés. On peut même obtenir une protection
supplémentaire en faisant établir un acte authentique sous la supervision
d’un notaire .

• 1.4 Intégrité des échanges
• Le maintien de l’intégrité des données échangées est un autre élément
important de la confiance. Il faut pouvoir s’assurer que ces données n’ont
pas pu être modifiées entre l’envoi par l’expéditeur et la réception par le
destinataire, ni après que le destinataire aura reçu le message. Nous
verrons que la signature électronique, en plus de fournir la non
répudiation, garantit l’intégrité des données.

• 2. Technologie à clé publique
• 2.1 Techniques utilisées par la
certification
2.2 Chiffrement
2.2.1 Chiffrement symétrique
2.2.2 Chiffrement asymétrique
2.3 Hachage
2.4 Signature

• 2.1 Techniques utilisées par la certification
• Pour répondre aux besoins de sécurité sur Internet, des techniques de
cryptographie sont utilisées. Parmi celles-ci, la technique de cryptographie
dite à clé publique est essentielle. Nous allons rappeler ici quelques-unes
des techniques utilisées (voir l’article Cryptographie appliquée) :
• le chiffrement et le déchiffrement de données par des techniques à clé
secrète et à clé publique ;
• la technique de création de condensés d’informations obtenus par des
opérations de hachage ;
• la signature des messages échangés afin de permettre l’authentification
de leurs émetteurs.
• 2.2 Chiffrement
• Le chiffrement est destiné à cacher les informations échangées entre deux
personnes, de telle sorte qu’un tiers ne puisse pas facilement en
interpréter le contenu.

• Afin de répondre aux besoins exprimés, deux techniques de chiffrement
doivent être employées, une technique de chiffrement symétrique et une
technique asymétrique. Nous allons en voir les avantages et inconvénients
respectifs. Pour des explications complémentaires sur les méthodes de
chiffrement, on se référera à Cryptographie appliquée et The SSL Protocol
Version 3.
• 2.2.1 Chiffrement symétrique
• C’est le moyen le plus répandu, le plus ancien et le plus simple à mettre en
œuvre. Une même clé (nombre aléatoire généré par l’émetteur) est utilisée
pour chiffrer puis déchiffrer un message. Le chiffrement consiste à appliquer
à chaque bloc de longueur fixe du message un algorithme dont le paramètre
est la clé de chiffrement. Plusieurs standards de chiffrement existent,
notamment :
• le DES (Data Encryption Standard) qui utilise une clé de taille 56 bits (+ 8 bits
de parité) ;
• l’AES (Advanced Encryption Standard), successeur probable du DES,
récemment adopté par le ministère de la Défense aux États-Unis ;

• le RC4 (Ron’s Code#4), mode de chiffrement d’une chaîne de caractères
utilisant une clé de taille variable. À taille égale, l’algorithme RC4 est plus
rapide que le DES.
• Le chiffrement symétrique permet de coder de grandes quantités de
données avec des performances raisonnables. Toutefois, il a pour
inconvénient de devoir partager la même clé entre l’émetteur et le
destinataire du message. Or, il n’est pas facile de transmettre de façon
sûre, à l’abri des écoutes indiscrètes, la clé de l’émetteur vers le
destinataire du message. D’où l’intérêt du chiffrement asymétrique décrit
ci-après.
• 2.2.2 Chiffrement asymétrique
• Le chiffrement asymétrique porte aussi le nom de « chiffrement à clé
publique ». L’un des partenaires de l’échange de messages génère une
biclé : une clé publique et une clé privée. La clé publique peut être
donnée à tout le monde ; la clé privée est gardée secrète par celui qui a
créé la biclé.

• La propriété du chiffrement à clé publique est que les deux clés (privée et
publique) sont reliées mathématiquement entre elles de telle sorte que
tout message chiffré avec l’une des clés ne peut être déchiffré que par
l’autre clé. En outre, il est quasiment impossible de déduire la clé privée à
partir de la seule connaissance de la clé publique.
• On voit ainsi que le chiffrement asymétrique simplifie la distribution des
clés, la clé publique pouvant être distribuée à tout le monde. En revanche,
son utilisation est plus consommatrice de puissance de calcul.
• Le chiffrement asymétrique est utilisé dans deux cas intéressants, bases
de l’utilisation pratique des certificats que nous décrirons plus loin :
• pour transporter une clé symétrique entre l’émetteur et le destinataire
d’un message, facilitant ainsi l’utilisation du chiffrement symétrique ;
• pour créer des signatures numériques.
• L’algorithme asymétrique le plus connu porte le nom de RSA (du nom de
ses auteurs : Rivest, Shamir et Adleman). La taille des clés utilisées peut
varier de 512 bits à 2 048 bits suivant le degré de sécurité que l’on veut
atteindre (à ne pas comparer avec la taille des clés DES).

•Figure 1 - Principe de la signature électronique

• 2.3 Hachage
• Le hachage d’un message consiste en l’application d’une fonction
mathématique qui permet d’en créer un condensé, beaucoup plus petit
que le message lui-même. La fonction de hachage n’est donc pas
réversible : il n’est pas possible de reconstituer le message à partir de son
condensé.
• La technique de hachage est utilisée pour préserver l’intégrité d’une
information en associant celle-ci à son condensé, ce dernier étant
éventuellement chiffré. La fonction de hachage est telle qu’il est
pratiquement impossible statistiquement de produire deux messages
dont les condensés seraient identiques. Le message et son condensé sont
donc liés : on ne peut pas modifier l’un sans devoir modifier l’autre.
• L’association du hachage et du chiffrement permet de réaliser la fonction
de signature décrite ci-après. C’est la technique essentielle utilisée par
l’infrastructure de gestion de clés.

• 2.4 Signature
• La notion de signature numérique d’un message est fondamentale dans
l’authentification de l’émetteur d’une transaction ainsi que dans sa garantie de
non répudiation. Elle s’obtient en associant une opération de hachage et une
opération de chiffrement asymétrique, comme indiqué sur la figure 1 :
• 1. création par l’émetteur d’un condensé du message par une opération de
hachage ;
• 2. chiffrement asymétrique du condensé par la clé privée de l’émetteur. Cela
constitue la signature ;
• 3. envoi des deux informations (message et signature) au destinataire. Le
destinataire, à la réception de ces deux informations, doit, pour vérifier la
signature, procéder comme décrit ci-après ;
• 4. calcul à nouveau du condensé du message par le même algorithme que celui
utilisé par l’émetteur ;
• 5. déchiffrement de la signature en utilisant la clé publique de l’émetteur, ce
qui permet de reconstituer le condensé créé par l’émetteur ;
• 6. comparaison des deux condensés ainsi obtenus. S’ils sont identiques, seul
l’émetteur (le possesseur de la clé privée) a pu envoyer ce message.

• L’opération de vérification de la signature suppose que le destinataire
possède la clé publique de l’émetteur. Ce dernier pourrait la lui
transmettre manuellement ou par courrier électronique sécurisé. Si ce
processus est envisageable à petite échelle quand les interlocuteurs se
connaissent, il n’est plus possible à grande échelle car, alors, émetteur et
destinataire ne se connaissent pas. C’est pourquoi, le plus souvent,
l’émetteur envoie sa clé publique en même temps que le message signé.
• Comment s’assurer alors que la clé publique ainsi échangée est bien celle
de l’émetteur ? Nous voyons ici l’importance d’une autorité externe fiable
permettant de certifier la clé publique fournie par l’émetteur d’un
message. C’est précisément le rôle de la fonction de certification que de
produire et signer un certificat contenant cette clé publique. La signature
de cette autorité externe constitue cette preuve.
• Un sous-produit important de la signature est l’intégrité du message. En
effet, un tiers qui modifierait le contenu d’un message signé ne pourrait
pas modifier sa signature : celle-ci ne serait donc plus valable. Sa
vérification, comme dans la procédure précédente, ferait ressortir une
différence des condensés.

• Résumons ici, en quelques mots, les techniques classiquement utilisées
dans les protocoles de sécurité :
• le chiffrement d’une quantité importante de données utilise des clés
symétriques ;
• la signature est obtenue en chiffrant avec la clé privée du signataire ; la clé
publique, accessible à tous, permet de vérifier la signature ;
• le transport de clés symétriques se fait dans une enveloppe chiffrée par la
clé publique du destinataire ; ce dernier est le seul à posséder la clé privée
permettant de déchiffrer (ouvrir) cette enveloppe.

• 3. Certificats et infrastructure de gestion
de clés
• 3.1 Contenu d’un certificat
3.2 Rôle des serveurs de certification
3.3 Processus de certification
3.4 Annulation des certificats
3.5 Hiérarchies de certification
3.6 Éléments de l’infrastructure de gestion de
clés
3.7 Standardisation

• Une infrastructure de gestion de clés (IGC) est un ensemble organisé de
composants fournissant divers types de prestations dans le but de gérer les clés
publiques des utilisateurs. Ces prestations peuvent couvrir l’enregistrement des
demandes de certificat, la certification, la publication ou la conservation des
certificats Secure Electronic Transaction (SET) Specification Book 1. Le terme
anglais correspondant est Public Key Infrastructure (PKI).
• La fonction de certification (appelée quelquefois accréditation, notamment
dans le cadre de transactions bancaires) est le composant central de l’IGC. Elle
vise à distribuer à chacun des acteurs d’une transaction électronique un
document numérique, appelé certificat, attestant son identité. Ces certificats
permettent d’authentifier de façon sûre les acteurs ainsi que de préciser les
rôles qui leur sont attribués en vue de participer à des transactions.
• 3.1 Contenu d’un certificat
• Un certificat électronique est un document qui lie entre elles un certain
nombre d’informations décrivant et identifiant de façon sûre une entité (une
personne, un équipement informatique, etc.), à la manière d’une carte
d’identité.

•Figure 2 - Contenu simplifié d’un certificat (d’après la
recommandation ITU X.509)
•

• La norme couramment utilisée pour représenter et décrire le contenu d’un
certificat est la recommandation ITU X.509. Cette norme prévoit qu’un certificat
doit contenir notamment (figure 2) :
• la version ;
• le numéro de série du certificat ;
• l’algorithme utilisé pour la signature du certificat ;
• l’organisme émetteur du certificat ;
• la période de validité ;
• le sujet, c’est-à-dire les identificateurs décrivant de façon assez détaillée l’entité
associée à ce certificat (pour une personne, il s’agira des nom et prénoms), ainsi
que l’organisation à laquelle appartient cette entité ;
• la clé publique du détenteur du certificat ;
• la signature de l’émetteur.
• L’authenticité d’un certificat est assurée par le fait qu’il est signé par une
autorité compétente (appelée autorité de certification) qui a pris toutes les
mesures nécessaires pour vérifier les éléments contenus dans le certificat. Cette
signature rend sa falsification impossible et permet ainsi de lier tous les
éléments du certificat entre eux.

• En plus d’attester une information d’identification, un certificat contient
et certifie la clé publique du détenteur. Comme ce dernier garde cachée
sa clé privée, il pourra avec celle-ci signer les messages qu’il enverra à un
certain nombre de destinataires. Ces derniers, recevant un message et le
certificat de l’émetteur, seront capables d’authentifier de façon sûre
l’émetteur, par vérification de la signature du message, en utilisant la clé
publique certifiée de l’émetteur. Nous verrons plus loin en quoi consiste le
processus complet de vérification.
• La plupart du temps, un certificat n’a qu’un seul usage. C’est pourquoi il
est courant de posséder au moins deux types de certificats :
• un certificat de signature permettant de signer les messages à envoyer, en
chiffrant avec la clé privée un condensé du message ;
• un certificat de chiffrement permettant de chiffrer (à l’aide de la clé
publique du destinataire) les enveloppes des messages échangés.
L’enveloppe contient la clé symétrique qui aura servi à chiffrer le message
en entier.

• Les certificats se distinguent aussi par l’usage que l’on veut en faire ; nous
verrons plus loin que l’on peut posséder un certificat distinct pour chacun
des usages suivants :
• le paiement sur Internet ;
• la déclaration de son impôt sur le revenu ;
• la réponse à un appel d’offres.
• L’usage que l’on peut faire d’un certificat est défini dans la politique de
certification établie par l’autorité de certification ayant délivré le certificat
et spécifiée dans un de ses champs.
• 3.2 Rôle des serveurs de certification
• Les acteurs d’une transaction électronique obtiennent leur certification en
s’adressant à une autorité habilitée à distribuer des certificats, appelée
autorité de certification (ou bien autorité d’accréditation ou encore
prestataire de services de certification).

• Cette autorité, du fait du niveau de confiance qu’elle doit procurer, est
aussi appelée parfois tiers de confiance. Ces autorités existent sous
plusieurs formes :
• des services accessibles publiquement sur Internet et qui délivrent sur
demande soit des certificats de test gratuitement, soit des certificats
permanents et réels moyennant un paiement annuel. Ces services,
appelés parfois prestataires de services de certification, sont gérés par des
entreprises privées telles que les sociétés CertiNomis ou CertPlus en
France ;
• des services privés installés en général pour le besoin d’une entreprise.
Par exemple, Lotus Domino fournit une fonction permettant de distribuer
des certificats aux clients accédant aux serveurs de ce type. Des éditeurs
de logiciels tels que Entrust, Baltimore, Netscape ou IBM fournissent des
progiciels permettant de mettre en œuvre des autorités de certification
pour l’usage interne d’une entreprise ;
• des services publics installés au niveau d’un pays ou d’une région. Ils
permettent de distribuer des certificats aux personnes afin de
communiquer avec eux de façon sécurisée ;

• des services offerts par les banques ou les organismes de cartes de crédit pour
distribuer des certificats SET en vue du paiement sécurisé sur Internet (voir
l’article Paiement sécurisé sur Internet avec le protocole SET [H 3 578]).
• D’autres types de services peuvent voir le jour en fonction du type de
certification recherché. Une entreprise ou une administration peut considérer
qu’un service de certification privé assure un meilleur contrôle des certificats
distribués qu’un service généralisé, mais le coût d’exploitation d’un service
privé peut être bien plus élevé.
• 3.3 Processus de certification
• La figure 3 illustre le protocole utilisé pour distribuer un certificat à un
utilisateur muni d’un navigateur Internet ; il pourra dès lors, en présentant ce
certificat, utiliser une application sur un serveur faisant confiance à l’autorité
de certification (en fait, l’application pourra effectuer des contrôles
supplémentaires concernant le nom ou l’organisation du détenteur du
certificat). Les échanges comportent les étapes suivantes.
• 1. L’utilisateur affiche, à l’aide de son navigateur (browser), un formulaire
d’enregistrement que lui envoie l’application d’enregistrement.

• Le navigateur va d’abord calculer une biclé (couple clé publique et clé
privée). Ensuite, l’utilisateur va remplir le formulaire qu’il soumettra,
accompagné de la clé publique à faire certifier, au serveur de certification.
Ce dernier met la demande en file d’attente.
•Figure 3 - Processus de demande d’un
certificat
•

2. Une personne faisant partie de l’autorité d’enregistrement (celle-ci peut être
gérée par une entreprise ou un consortium contrôlant l’autorité de
certification) passe en revue la file d’attente qu’elle est chargée d’approuver.
Pour chaque demande, cette personne effectue une validation basée sur un
certain nombre d’informations dont celles envoyées séparément par le
demandeur (carte d’identité, justification de domicile, etc.). Cela peut aller
jusqu’à appeler le demandeur par téléphone. En revanche, cette étape peut se
dérouler automatiquement si le contenu du formulaire est suffisamment précis
pour identifier de façon sûre son émetteur. (Il peut contenir, par exemple, un
mot de passe distribué au préalable par l’autorité.)
3. L’autorité d’enregistrement approuve la demande de certificat.
• 4. La fonction de gestion des certificats du serveur de certification va générer le
certificat demandé et le signer avec sa clé privée. Ensuite, elle notifiera au
demandeur que son certificat est prêt.
• 5. À intervalles réguliers, le demandeur consulte sa messagerie personnelle
(« e-mail ») pour s’enquérir de l’approbation de son certificat. Dans le cas
positif, il pourra charger le certificat sur son poste de travail et dès lors, l’accès
à l’application pour laquelle il avait effectué sa demande de certificat sera
permis.

• 3.4 Annulation des certificats
• Chaque fois qu’un utilisateur reçoit un certificat d’un tiers, il doit non
seulement vérifier que ce certificat est bien valide (notamment qu’il est signé
par une autorité compétente et reconnue), mais aussi que ce certificat
n’appartient pas à une liste noire (il n’est en effet pas possible de retirer
physiquement un certificat, à la manière d’un retrait de permis de conduire).
L’utilisateur doit pour cela consulter un annuaire, éventuellement distant,
prévu à cet effet. Afin de ne pas faire de demande réitérée à l’autorité de
certification, l’utilisateur peut maintenir sa propre liste de certificats annulés.
• Plusieurs raisons peuvent amener une autorité à annuler des certificats :
• il est supposé que la clé privée du détenteur du certificat a été révélée ou
subtilisée de façon frauduleuse ;
• l’utilisateur a perdu le rôle attaché à la possession de son certificat ;
• la clé privée de l’autorité de certification a été compromise ou subtilisée.
• Afin de pouvoir traiter tous ces cas, il faut mettre en place un mécanisme
d’annulation des certificats. La solution choisie consiste notamment, pour
chaque autorité de certification, à maintenir une liste des certificats annulés,
mais dont la période de validité n’a pas encore expiré.

• Ces listes sont parfois appelées « listes noires » ou bien CRL (Certificate
Revocation List).
• Une autre solution pourrait consister à retirer le certificat d’un annuaire
global contenant tous les certificats. Cette solution n’est toutefois pas
souhaitable car un certificat annulé peut encore servir à vérifier des
signatures de messages créés antérieurement à l’annulation du certificat.
•Figure 4 - Domaine de certification
hiérarchique

• 3.5 Hiérarchies de certification
• Dans la vie courante, comme dans le cas de distribution de certificats
physiques, il est commun de posséder plusieurs types de « certificats » : une
carte d’identité, un passeport, un permis de conduire, une carte de Sécurité
sociale, etc.
• De la même façon, du point de vue électronique, nous serons amenés à
posséder des certificats provenant de diverses autorités, pour des usages
différents : certificat SET pour chaque carte bancaire, certificats SSL pour
accéder aux services de notre banque, certificat EDI, etc. Il faudra, bien sûr, des
autorités de certification différentes pour toutes ces utilisations.
• Même pour un usage donné, il peut être nécessaire de mettre en œuvre
plusieurs autorités de certification. En effet, il est illusoire de vouloir gérer
l’ensemble des utilisateurs potentiels, surtout au niveau mondial, par un
serveur de certification unique. Par conséquent, une autorité centralisée (un
consortium bancaire par exemple) pourra déléguer ses pouvoirs de certification
à des serveurs intermédiaires qui, eux-mêmes, les céderont à d’autres autorités
jusqu’à un serveur de certification terminal chargé de délivrer les certificats aux
particuliers. Ainsi se crée, comme dans la figure 4, une hiérarchie de
certification dans laquelle chaque niveau accrédite un niveau inférieur.

• Le point central est le serveur racine qui doit distribuer sa clé publique à tous.
Cette racine est le point de convergence de toutes les vérifications de
certificats.
• On retrouve cette situation dans le cas du paiement sécurisé utilisant le
protocole SET [H 3 578] : outre la racine, deux niveaux de certification sont
représentés respectivement par les marques de cartes bancaires et par les
banques émettrices de cartes.
• Lors d’un échange avec un tiers, membre d’une hiérarchie de certification, un
utilisateur devra envoyer non seulement son certificat, mais aussi tous les
certificats de la chaîne jusqu’au certificat racine, comme indiqué
précédemment. La vérification d’un certificat va donc consister à contrôler
tous les certificats, en partant du certificat d’une feuille de l’arbre, jusqu’au
certificat racine. Cela consiste par exemple, sur la figure 4, si David veut
vérifier le certificat d’Alice, à contrôler que ce certificat est bien signé par
l’autorité de certification CA-3, que le certificat de l’autorité de certification
CA-3 est bien signé par la clé publique de la racine CA-X. Il faut enfin vérifier la
validité du certificat racine lui-même ainsi que sa clé publique. Normalement,
ce certificat racine a été introduit dans un fichier de certificats, au préalable,
par l’utilisateur (après vérification) ou par une entité en laquelle il a confiance.

• Notons qu’il n’est toutefois pas nécessaire que tous les individus qui veulent
s’authentifier mutuellement appartiennent à une même hiérarchie. Ils
peuvent aussi dépendre de deux domaines de certification indépendants.
Afin que ces individus puissent réaliser quand même leur authentification
réciproque, il faudra alors que leurs autorités de certification respectives (au
niveau qu’il convient) se certifient mutuellement : on parle alors de
certification croisée comme l’illustre la figure 5. Les flèches montrent que
chaque autorité possède un certificat garanti par une signature de l’autre
autorité. Par exemple, Alice pourra vérifier un certificat présenté par Robert
appartenant à un autre domaine hiérarchique en remontant la chaîne de
certification : certificat de Robert, certificat de CA-4, certificat de CA-3. Alice
aura confiance dans le certificat de Robert parce qu’elle a confiance dans le
certificat de CA-3.
• La certification croisée est intéressante car elle peut être mise en œuvre
facilement, puisqu’il suffit d’un accord entre deux autorités de certification.
Toutefois, lorsque le nombre d’autorités de certification devient élevé, le
nombre de certifications croisées à réaliser croît quadratiquement : N × (N −
1). Enfin, la certification croisée suppose que les niveaux de sécurité attachés
à chaque hiérarchie (on parle de politique de certification) sont équivalents.

• La hiérarchie de certification est plus difficile à organiser qu’une certification
croisée car il faut, au préalable, créer une autorité racine reconnue par tous.
En revanche, chaque autorité de certification n’a besoin d’être certifiée que
par une seule autorité supérieure ; elle aura aussi à certifier un nombre limité
d’autorités de niveau inférieur.
• 3.6 Éléments de l’infrastructure de gestion de clés
• Nous rappelons sur la figure 6 les éléments principaux d’une infrastructure de
gestion de clés, en montrant leur articulation :
• l’autorité de certification est chargée de signer les certificats, à la demande
de l’autorité d’enregistrement, et de publier les certificats dans un annuaire ;
• l’autorité d’enregistrement contrôle les demandes de certificats et les
accorde ou non suivant une politique de certification précisée par
l’organisme qui la gère. L’autorité d’enregistrement peut annuler des
certificats qu’elle a créés ;
• le demandeur est la personne désirant faire certifier ses données d’identité
et sa clé publique auprès de l’autorité d’enregistrement ;

• l’annuaire est une base de données servant à contenir notamment les
certificats générés par l’autorité de certification ainsi que des listes
d’annulation ;
• le vérificateur de certificats est une fonction chargée de valider un
certificat qui lui est présenté, en vérifiant notamment la signature de
l’autorité émettrice et l’appartenance possible du certificat à une liste
noire.
Figure 5 - Domaines de certification en réseau

•Figure 6 - Infrastructure de gestion
de clés

• 3.7 Standardisation
• Aujourd’hui, presque tous les fournisseurs d’infrastructures à gestion de
clés utilisent un format normalisé, X.509, pour les certificats. Toutefois,
encore récemment, il n’existait pas de norme décrivant les structures de
données à l’intérieur des certificats, le format des listes noires, le contenu
d’une politique de certification, la façon de demander un certificat, etc.
• Le groupe PKIX de l’Internet Engineering Task Force (IETF) propose un
modèle de spécifications répondant notamment à ces besoins et qui tend
aujourd’hui à s’imposer comme standard de fait X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol – OCSP. Il existe
aujourd’hui de nombreux RFC (Request for Comment) sur PKIX, terme
désignant des spécifications publiées par l’IETF.

• 4. Utilisation des certificats
• 4.1 Protocoles et formats utilisant les certificats
4.1.1 Authentification dans les transactions électroniques par
SSL/TLS
4.1.2 Courrier électronique
4.1.3 EDI et XML
4.1.4 Paiement sécurisé avec SET
4.1.5 Réseaux privés virtuels
4.2 Utilisation pratique des certificats
4.2.1 Commerce d’entreprise à entreprise
4.2.2 Carte professionnelle de santé
4.2.3 Paiement de la TVA et déclaration de revenus
4.2.4 Notaires
4.2.5 Appels d’offres
4.2.6 Industrie pharmaceutique

• Les certificats ont de multiples usages aujourd’hui. Ils apparaissent à la fois
dans l’utilisation de protocoles informatiques et surtout de façon pratique
dans des applications à destination du grand public. Nous décrivons ici ces
deux types d’utilisation qui ressortent de deux emplois élémentaires des
certificats :
• signature d’un document ;
• chiffrement de la clé symétrique servant à occulter le contenu d’un
message.
• 4.1 Protocoles et formats utilisant les certificats
• 4.1.1 Authentification dans les transactions
électroniques par SSL/TLS
• L’authentification est sans doute le premier usage des certificats. Les
partenaires qui veulent s’authentifier mutuellement s’envoient leurs
certificats respectifs accompagnés d’une preuve qu’ils en sont bien les
possesseurs. Cette preuve consiste en un message (un jeton) signé par la
clé privée associée à la clé publique contenue dans le certificat.

• Il faut évidemment prendre quelques précautions pour éviter que ce
message d’authentification puisse être rejoué par quelqu’un d’autre.
•Figure 7 - Schéma simplifié d’un établissement de
session SSL

•
• L’authentification par certificats est mise en œuvre notamment par un
protocole de sécurisation des échanges sur Internet appelé Secure Sockets Layer
(SSL) ou plus récemment standardisé sous le nom Transport Layer Security (TLS)
par l’IETF. Ce protocole a été développé par Netscape pour assurer initialement
la sécurité des échanges, par exemple, entre un serveur Web et un client muni
d’un navigateur.
• SSL permet de chiffrer les communications entre un client et un serveur et
d’authentifier le serveur (version 2 du protocole). Il peut aussi, de façon
facultative, authentifier le client (version 3). Bien que ce protocole ait été
développé pour les communications HTTP entre un navigateur Web et un
serveur Web, il peut aussi être utilisé pour les transferts de fichiers FTP.
• Il n’est pas dans l’intention de ce document de décrire le protocole en détail (on
se référera plutôt à [7]). Nous allons montrer toutefois comment les certificats
sont utilisés pour l’authentification mutuelle des clients et des serveurs. La
figure 7 fournit un schéma simplifié des échanges.
• Les connexions HTTP, dont chacune permet un échange entre client et serveur,
font partie d’une même session SSL dont la durée est indéterminée. À l’intérieur
d’une même session SSL, ne sont réalisés qu’un seul échange de clé passe-
partout et qu’une seule authentification, cela afin d’alléger le démarrage de la
connexion. Chaque connexion utilise une clé de chiffrement différente déduite
du passe-partout échangé au cours de l’établissement de session.
• Nous ne nous intéressons qu’au principe d’authentification se produisant au
démarrage d’une session SSL.

• Le serveur s’authentifie par l’envoi de son certificat au client. D’une part, ce
dernier vérifie sa validité par consultation du certificat de l’autorité qui a signé
le certificat du serveur. D’autre part, le client envoie au serveur le passe-
partout de la session, chiffré par la clé publique de ce dernier, afin de
s’assurer de l’identité du serveur. Seul le possesseur de la clé privée, donc le
bon serveur, peut déchiffrer le passe-partout.
• Le client s’authentifie en envoyant au serveur à la fois son certificat et un
message (jeton) signé avec sa clé privée. Le serveur peut ainsi vérifier que le
certificat a bien été envoyé par le vrai client, en contrôlant la signature qu’il va
recevoir. (À noter que le contenu du message signé n’est connu que du
serveur et du client.) Il est courant d’entendre dire, pour simplifier, que l’on
présente son certificat ; en réalité, cela ne suffit pas, il faut aussi prouver que
l’on est bien le possesseur de ce certificat : c’est l’objet du message signé
accompagnant le certificat.
• Nous voyons ici l’importance de la certification pour garantir l’authentification
des parties en présence, comprenant une vérification poussée du certificat
(signature de l’émetteur, listes noires, dates de validité, etc.).
• Ce processus d’authentification par certificat est généralisé dans la
messagerie Lotus Notes depuis 1989.

• 4.1.2 Courrier électronique
• En plus du besoin de chiffrer les informations échangées par courrier, le
besoin de non répudiation des messages est tout aussi important. L’utilisation
de certificats va permettre à la fois de signer ces messages et d’en chiffrer le
contenu. La signature et le chiffrement des courriers électroniques sont
disponibles sur les fonctions de courrier attachées aux navigateurs Web les
plus connus, tels que ceux de Netscape ou de Microsoft. C’est aussi une
fonction du serveur de messagerie Lotus Domino (appelé couramment Notes).
• Lorsqu’une personne désire envoyer un message, elle le prépare de façon
habituelle puis indique qu’elle désire le signer et/ou le chiffrer. Le chiffrement
du message exige que l’on connaisse la clé publique du destinataire. La
fonction courrier envoie ensuite au destinataire ce message accompagné de
sa signature et du certificat de l’émetteur.
• La personne recevant ce message est prévenue par sa fonction courrier que le
message reçu a été signé et/ou chiffré. Elle peut alors d’abord déchiffrer le
message, afficher le contenu du certificat associé au message et vérifier,
comme nous l’avons vu précédemment, que c’est bien la personne indiquée
dans le champ émetteur qui l’a envoyé.

• Le protocole de messagerie utilisé dans l’envoi de courrier signé et chiffré
s’appelle S/MIME (Secure Multi-purpose Internet Mail Extensions) (voir
l’article Sécurité des e-mails : PGP et S/MIME [H 5 330]).
• 4.1.3 EDI et XML
• Electronic Data Interchange est une norme fréquemment utilisée par les
entreprises pour échanger entre elles des informations structurées :
commandes, factures, paiements, etc. Nous voyons tout de suite
l’importance d’associer une signature à ces messages, cela permettant au
destinataire de posséder la preuve, par exemple, qu’une commande a bien
été passée par un client d’une entreprise, preuve que ce dernier ne peut
réfuter. La façon de signer un message EDI est en cours de normalisation.
• Le format XML (eXtensible Markup Language) est un format concurrent de
l’EDI dans son usage de structuration des messages échangés sur les
réseaux, notamment pour la communication « Business to Business » (BtoB,
commerce d’entreprise à entreprise). Des formats de signature XML
incluant les certificats ont déjà été proposés.

• 4.1.4 Paiement sécurisé avec SET
• Très tôt est apparu le besoin de sécuriser les paiements sur Internet. Les
grandes marques de cartes de crédit (Visa et MasterCard) ont développé
avec des éditeurs de logiciels tels qu’IBM, un protocole de paiement appelé
SET (Secure Electronic Transaction). Une version officielle de ce protocole a
été publiée en juin 1997 Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework. Il est opérationnel dans de
nombreux pays.
• SET permet de réaliser un paiement entre trois acteurs : le porteur de carte
de crédit, le commerçant et la banque acquéreur [H 3 578]. La sécurité des
échanges repose, en plus du chiffrement des messages échangés, sur les
signatures de ces messages par les acteurs permettant une authentification
mutuelle de ceux-ci. Chaque acteur doit donc posséder, en préalable à tout
paiement, un certificat délivré par :
• la banque émettrice de la carte pour le porteur (ou acheteur) ;
• la banque acquéreur pour le commerçant ;
• la ou les marques de cartes bancaires pour les banques acquéreur et
émettrice.

• Tous ces certificats sont les feuilles d’un arbre hiérarchique remontant vers une
racine commune gérée par le consortium SETCo. La vérification d’un certificat
se fait en remontant pas à pas jusqu’au sommet de la hiérarchie dont la racine
est supposée connue de tous et vérifiable.
• Rappelons qu’un certificat SET, bien qu’étant conforme à la recommandation
X.509, ne certifie pas un individu mais une carte de crédit. Le sujet du certificat
SET n’est pas une personne mais un numéro de carte. C’est pourquoi ces types
de certificats ne peuvent être utilisés que pour le paiement SET (c’est aussi une
conséquence des politiques de certification des banques du consortium SETCo).
• 4.1.5 Réseaux privés virtuels
• Le réseau Internet est devenu très populaire et bon marché aujourd’hui. Cela a
conduit de nombreuses entreprises à mettre en œuvre des réseaux privés
virtuels (Virtual Private Network : VPN) en s’appuyant sur Internet.
• Le réseau privé virtuel est une extension du réseau interne d’une entreprise se
servant du réseau Internet pour relier ses succursales éloignées ou simplement
ses employés entre eux, tout en conservant le même niveau de sécurité que s’il
s’agissait d’un unique réseau privé.

• La figure 8 montre un schéma de réseau privé virtuel reliant deux
succursales disposant de leur propre réseau interne, ainsi qu’un
collaborateur mobile. Les deux réseaux accèdent à l’Internet à travers un
équipement VPN (souvent un pare-feu). On obtient un réseau unique et
sécurisé en procédant de la façon suivante :
• les équipements VPN vont chercher à établir une communication entre
eux ;
• pour que les équipements soient sûrs de communiquer avec le bon
partenaire, ils vont devoir s’authentifier mutuellement ;
• l’authentification se fait par échange et vérification de certificats et de
signatures ;
• une fois les partenaires mutuellement authentifiés, les données
échangées entre les équipements VPN sont chiffrées.

•Figure 8 - Exemple de réseau VPN

• Cet exemple illustre encore le cas d’un certificat délivré non pas à une personne
mais à un élément informatique, en l’occurrence un serveur pare-feu.
• 4.2 Utilisation pratique des certificats
• Le paragraphe 4.1 a montré des applications pratiques des certificats par simple
emploi de protocoles : ce sont le courrier électronique et le paiement par
Internet. Nous allons maintenant décrire brièvement quelques autres
applications de ces certificats.
•
• 4.2.1 Commerce d’entreprise à entreprise
• Le BtoB est l’équivalent du commerce électronique destiné aux particuliers
(BtoC). En dehors de la question du paiement, se pose pour les entreprises le
besoin d’obtenir l’assurance que les entreprises avec lesquelles elles échangent
des informations, elles vendent ou bien elles effectuent des appels d’offres,
existent bien et sont solides financièrement.
• Ce type d’assurance est offert notamment par un consortium bancaire comme
celui d’Identrus.

• Le consortium a créé une infrastructure de gestion de clés hiérarchique,
dont il est la racine, en distribuant des certificats aux autorités de
certification gérées par les banques, ces dernières distribuant des
certificats aux entreprises. Ainsi est établi un domaine de confiance dans
lequel les transactions échangées entre entreprises accréditées par des
banques du consortium (après vérification de la solidité et de la solvabilité
de l’entreprise) sont signées avec des certificats (en fait par les clés
privées). Un service supplémentaire des banques peut consister à
cautionner les transactions, la banque ayant connaissance de la santé
financière des entreprises.
• 4.2.2 Carte professionnelle de santé
• La gestion des dossiers médicaux requiert un excellent niveau de sécurité.
Pourtant, une plus grande efficacité dans cette gestion conduit à
s’appuyer de plus en plus sur l’informatique. Il est donc nécessaire de
renforcer la sécurité d’accès et d’échange de ces informations sur les
réseaux et systèmes informatiques.

• C’est dans ce but qu’ont été créées une infrastructure de gestion de clés ainsi
que la carte professionnelle de santé (CPS) – à ne pas confondre avec la carte
Vitale –, reconnue par l’État et les organismes de Sécurité sociale. Cette
infrastructure délivre des certificats stockés sur des cartes à puce aux
différents acteurs du domaine de la santé :
• les professionnels de santé (médecins, chirurgiens, etc.) ;
• les directeurs d’établissement ;
• les personnels des établissements (infirmières, etc.).
• Chaque type de carte permet des opérations de types différents sur les
dossiers médicaux.
• Des certificats sont délivrés aussi aux serveurs informatiques afin d’assurer la
sécurité des échanges, par le protocole SSL, avec les utilisateurs.
• 4.2.3 Paiement de la TVA et déclaration de revenus
• Dans le cadre de l’amélioration de l’efficacité des administrations, la direction
générale des Impôts (DGI) a demandé aux entreprises d’automatiser le
processus de déclaration et de paiement de la taxe à la valeur ajoutée (TVA).

• Cette exigence concerne initialement les entreprises ayant un chiffre
d’affaires annuel supérieur à 15 millions d’euros et payant la TVA
mensuellement. Cela est facultatif pour les autres entreprises. Cette
procédure concerne aujourd’hui 14 000 entreprises sur un total de
3 millions.
• La télédéclaration permet à la fois de réduire le papier utilisé grâce à la
dématérialisation (jusque-là, la déclaration s’effectuait sur un formulaire
écrit) et d’accélérer le processus par enchaînement automatique du
paiement. Le schéma de la figure 9 illustre la procédure automatisée :

•Figure 9 - Schéma du télépaiement
de TVA
•

• En réalité, le schéma de la figure 9 montre trois processus exécutés dans
des moments différents :
• 1. la demande de certificat. Les principales banques en relation avec les
entreprises ont mis en œuvre, ou plutôt ont fait mettre en œuvre, une
autorité de certification par des prestataires de services de certification.
Chaque entreprise déclarante doit s’adresser à sa banque pour demander
un certificat. La banque joue le rôle d’autorité d’enregistrement et
demande, après vérifications, à l’autorité de certification de délivrer un
certificat à l’entreprise. Le certificat obtenu, souvent chargé dans une
carte à puce 5, est valable pour une ou deux années et va permettre
d’exécuter le second processus ;
• 2. la déclaration de la TVA. La personne de l’entreprise chargée de la
déclaration de la TVA, munie de son certificat (et donc de la biclé
associée), va pouvoir se connecter avec le navigateur Internet de son PC
au serveur de la DGI (à noter que cette connexion, afin d’en maintenir la
sécurité, utilise le protocole SSL). Une fois connecté, le déclarant remplit
le formulaire de TVA en ligne.

• Lorsqu’il est rempli et prêt à être soumis au serveur de la DGI, un agent
(petit programme) associé au navigateur signe la déclaration à l’aide de la
clé associée au certificat (dans ce but, le programme va demander que la
carte à puce soit introduite dans un lecteur attaché au PC et que l’utilisateur
compose son code confidentiel) ;
• 3. le paiement. Une fois la déclaration faite, la DGI peut déclencher
automatiquement le prélèvement du montant correspondant par exécution
d’un ordre auprès de la Banque de France. Cet ordre est relayé par le
réseau bancaire SIT jusqu’à la banque de l’entreprise. Cette dernière peut
alors exécuter le retrait sur le compte de l’entreprise et avertir cette
dernière de l’opération.
• Ce que nous venons de décrire pour les entreprises a son équivalent pour
les particuliers : la déclaration électronique de revenus. La procédure en
est un peu plus simple. La personne désirant déclarer ses revenus par
Internet doit se connecter au site de la DGI. Elle devra d’abord demander et
charger un certificat ; pour cela, elle s’authentifie en fournissant la somme
versée à l’IRPP l’année précédente ; ensuite elle remplira, en ligne, sa
déclaration qu’elle signera avant de la soumettre au serveur de la DGI.

• 4.2.4 Notaires
• Les notaires, de par leur fonction d’officier public, sont amenés à rédiger
ou enregistrer des actes dits « authentiques » (ventes de biens,
testaments, contrats, etc.), leur conférant ainsi une véracité d’un niveau
bien supérieur à celui des actes établis entre seulement deux parties. Le
notaire joue alors le rôle de tiers garant de l’authenticité de l’acte.
L’authentification, au sens premier du terme et non pas au sens
informatique, consiste à créer cet acte dans des conditions définies par la
loi.
• La Chambre nationale des notaires a mis en œuvre une infrastructure
informatique permettant de remplacer ou de compléter la signature
manuscrite par une signature électronique. Pour cela, une infrastructure
de gestion de clés a été créée pour l’ensemble des chambres régionales
des notaires permettant de distribuer à ces derniers, dans d’excellentes
conditions de sécurité, des cartes à puce (dénommées « REAL ») contenant
les certificats et les biclés associées.
• Dès maintenant, cette infrastructure et ces cartes à puce sont utilisées
pour signer des actes authentiques.

• 4.2.5 Appels d’offres
• Suite à la loi sur la signature électronique et aux décrets relatifs à cette loi,
le décret 2002-692 du 30 avril 2002, relatif à la dématérialisation des
procédures de passation des marchés publics, autorise les administrations à
recevoir les réponses à leurs appels d’offres sous forme électronique et
munies d’une signature électronique.
• Nous voyons tout l’intérêt de cette disposition : réduction du papier,
rapidité des échanges, économie de courrier et sécurité de l’appel d’offres
car les envois peuvent être chiffrés jusqu’à la date de clôture de l’appel
d’offres.
• 4.2.6 Industrie pharmaceutique
• Créer et mettre sur le marché un nouveau médicament est une longue et
coûteuse entreprise. Cela inclut la recherche, les tests, l’obtention de
l’agrément dans les différents pays et la mise sur le marché.
• La documentation permettant de proposer le médicament à l’agrément des
autorités concernées est énorme.

• Dans un but de réduction du papier, l’administration américaine chargée de
l’agrément des médicaments et de l’alimentation (FDA – Food and Drug
Administration) demande que cette documentation soit envoyée sous forme
électronique et soit signée électroniquement par l’émetteur, en l’occurrence la
société pharmaceutique. La création de cette signature exige bien sûr la
possession d’un certificat.
• 5. Sécurité et support des certificats
• L’utilisateur désirant accéder à des serveurs sur un réseau ouvert, signer des
documents ou des courriers doit disposer d’un certificat et de la clé privée
associée à ce certificat. Si le certificat peut être distribué à tous, la clé privée doit
être bien protégée de tout accès par un tiers.
• Souvent, certificats et clés privées sont stockés sur le poste de travail (PC) dans un
fichier chiffré dont l’accès est protégé par un mot de passe. Cela assure la plupart
du temps un bon niveau de sécurité. Toutefois, à partir du moment où le mot de
passe a été composé par l’utilisateur pour déverrouiller le fichier, la clé privée
apparaît en clair en mémoire réelle et est donc susceptible d’être révélée
(sachant aussi que le mot de passe peut être intercepté par « écoute » des
frappes au clavier).

• C’est pourquoi il existe plusieurs types de dispositifs matériels fournissant une
protection bien supérieure de la clé privée de l’utilisateur : ce sont notamment
les cartes à puce et les clés connectées par port USB. Ces dispositifs offrent des
capacités et des niveaux de sécurité croissants avec des prix correspondants (de
l’ordre de 10 € à 30 €) :
• le dispositif peut permettre de contenir uniquement la clé privée et la clé
publique (en fait le certificat en entier). La biclé est générée sur le PC et ensuite
chargée dans le dispositif matériel ;
• dans le niveau suivant, la signature est effectuée à l’intérieur du dispositif ;
• dans le niveau supérieur, la biclé elle-même est générée à l’intérieur du
dispositif matériel. On est alors certain que cette clé n’a jamais pu être
interceptée.
• Nous voyons que ces dispositifs apportent à la fois la portabilité du certificat et
de la biclé en même temps qu’ils améliorent grandement la sécurité. Tant que ce
dispositif n’est pas branché sur le PC, il n’est pas possible de signer. En outre,
une fois branché, il faut une action de l’utilisateur, en l’occurrence la
composition d’un code confidentiel, pour déverrouiller la clé privée et exécuter
une signature, à la manière de ce que chacun fait avec sa carte bancaire. C’est la
preuve que l’on est bien possesseur du dispositif.

• À noter que les dispositifs ne sont pas équivalents du point de vue de la
sécurité :
• avec la clé branchée sur le port USB, ou le lecteur de carte inclus dans le PC,
la saisie du code confidentiel est faite sur le clavier de l’ordinateur et la
création du condensé du message à signer est effectuée sur l’ordinateur ;
• en revanche, avec une carte à puce, il est courant d’attacher un lecteur de
carte à puce au poste de travail, soit en le connectant au port série, soit en
l’incluant dans le clavier. Le dispositif le plus sécurisé consiste en un lecteur
de carte séparé, connecté au port série ou port USB, permettant d’afficher le
texte à signer et possédant un clavier propre.
• Il est certain que, tôt ou tard, un lecteur de carte à puce fera partie
intégrante du PC au même titre qu’un lecteur de CD-ROM. Des compléments
aux navigateurs Web (programmes agents ou plugins) ont été développés,
par exemple par les fabricants de PC ou de matériels de sécurité, pour
permettre à ceux-ci d’accéder au certificat de la carte et demander à la carte
de signer. La clé USB est une solution économique mais qui n’offre pas le
même niveau de sécurité que le lecteur séparé du PC.

• 6. Conclusion
• La certification des utilisateurs est une technique devenue de plus en plus
indispensable en informatique, notamment du fait de l’expansion d’Internet.
Il est donc important pour les entreprises et les organisations de s’appuyer
sur une infrastructure de gestion de clés, soit qu’elles les gèrent elles-
mêmes, soit qu’elles en chargent des prestataires de services de
certification.
• Des prestataires de services de certification ainsi que des éditeurs de
progiciels d’infrastructures de gestion de clés existent aujourd’hui. La
standardisation autour du standard PKIX de l’IETF devrait faciliter
l’interopérabilité des différentes installations de ces infrastructures.
• La généralisation des cartes à puce comme moyen d’authentification et de
paiement va à la fois augmenter le niveau de sécurité de l’authentification et
nécessiter de mettre en œuvre de telles infrastructures.
• Il restait un dernier obstacle à l’expansion de la certification électronique : la
reconnaissance de la signature numérique comme équivalent juridique de la
signature manuscrite.

• Si une signature numérique peut être facilement reconnue dans le cadre
d’un accord commercial entre entreprises, il restait en Europe, et en
France notamment, à établir la législation permettant de la généraliser à
l’échange de documents entre des individus et les administrations ou les
entreprises. C’est chose faite avec la directive européenne 1999/93/CE et
avec la loi française du 13 mars 2000 sur la signature électronique. En
France, les décrets d’application du 30 mars 2001 et du 18 avril 2002
décrivent la mise en œuvre pratique de cette loi.

• Annexe
• 1 Réglementation
2 Organismes

• 1 Réglementation
• Directive 1999/93/CE du Parlement européen et du Conseil, du
13 décembre 1999, sur un cadre communautaire pour les signatures
électroniques (JO L. 13 du 19 janvier 2000, p. 12 à 20).
• Loi no
2000-230 du 13 mars 2000 portant adaptation du droit de la preuve
aux technologies de l'information et relative à la signature électronique
(JO no
62 du 14 mars 2000).
• Décret no
2001-272 du 30 mars 2001 pris pour l'application de l'article
1316-4 du code civil et relatif à la signature électronique (JO no
77 du 31
mars 2001).
• Décret no
2002-535 du 18 avril 2002 relatif à l'évaluation et à la
certification de la sécurité offerte par les produits et les systèmes des
technologies de l'information (JORF no
92 du 19 avril 2002, page 6944).
• Loi no
2004-575 du 21 juin 2004 pour la confiance dans l'économie
numérique (JORF no
143 du 22 juin 2004, page 11168).

• Décret no
2002-692 du 30 avril 2002 pris en application du 1o
et du 2o
de
l'article 56 du code des marchés publics et relatif à la dématérialisation
des procédures de passation des marchés publics (JORF no
103 du 3 mai
2002, page 8064).
2 Organismes
• Internet Engineering Task Force http://www.ietf.org
• Virtual Private Network Consortium (VPNC) http://www.vpnc.org
• Association nationale pour la promotion de la signature électronique
http://www.ialta.org
• Ministère de l'Économie, des Finances et de l'Emploi
http://www.minefe.gouv.fr

certification electronique en cryptographie.ppt

Contenu connexe

Similaire à certification electronique en cryptographie.ppt

Dernier

certification electronique en cryptographie.ppt