diff options
Diffstat (limited to 'files/fr/introduction_à_la_cryptographie_à_clef_publique')
6 files changed, 600 insertions, 0 deletions
diff --git a/files/fr/introduction_à_la_cryptographie_à_clef_publique/certificats_et_authentification/index.html b/files/fr/introduction_à_la_cryptographie_à_clef_publique/certificats_et_authentification/index.html new file mode 100644 index 0000000000..0207687122 --- /dev/null +++ b/files/fr/introduction_à_la_cryptographie_à_clef_publique/certificats_et_authentification/index.html @@ -0,0 +1,395 @@ +--- +title: Certificats et authentification +slug: >- + Introduction_à_la_cryptographie_à_clef_publique/Certificats_et_authentification +tags: + - Sécurité +--- +<h3 id="Certificat_identifiant_une_personne_ou_une_entité">Certificat identifiant une personne ou une entité</h3> + +<p>Un <em>certificat</em> est un document électronique utilisé pour identifier un individu, un serveur, une entreprise ou toute autre entité et pour associer une clef publique à cette identité. Tout comme un permis de conduire, un passeport, ou tout autre moyen d'identification personnelle couramment utilisé, un certificat fournit généralement une preuve reconnue de l'identité de la personne. La cryptographie à clef publique utilise les certificats pour éviter les problèmes d'usurpation d'identité (voir <a href="#Probl.C3.A8mes_de_s.C3.A9curit.C3.A9_sur_Internet">Problèmes de sécurité sur Internet</a>).</p> + +<p>Pour obtenir un permis de conduire, il faut s'inscrire dans une agence gouvernementale, telle que le <em>Department of Motor Vehicles</em>, qui vérifie votre identité, votre capacité à conduire, votre adresse, et d'autres information avant de délivrer le permis. Pour obtenir une carte d'étudiant, il faut s'adresser à une université ou une école, qui contrôle certaines informations (comme le paiement des frais d'inscription) avant de délivrer la carte d'étudiant. Pour obtenir une carte de bibliothèque, il faut uniquement fournir votre nom et une attestation de logement à vos nom et adresse.</p> + +<p>Les certificats fonctionnent sur les mêmes principes que ces différents documents d'identité. Les autorités de certification (AC ou CA) sont des entités qui valident les identités et émettent les certificats. Elles peuvent être des tierces-parties indépendantes ou des organisations possédant leur propre serveur d'émission de certificats (tel que <em>Red Hat Certificate System</em>). Les méthodes utilisées pour valider une identité varient selon les politiques d'émission d'une AC donnée — tout comme les méthodes de validation des autres formulaires d'identification varient selon les organismes d'émission et leurs domaines d'application. En général, avant d'émettre un certificat, une AC doit utiliser ses procédures de vérification publiées pour un type de certificat afin de s'assurer que l'entité demandant le certificat est bien celle qu'elle prétend être.</p> + +<p>Le certificat émis par l'AC lie une clef publique particulière au nom de l'entité qu'il identifie (tel qu'un nom d'employé ou de serveur). Les certificats aident à prévenir l'utilisation de fausses clefs publiques pour l'usurpation d'identité. Seule la clef publique certifiée dans le certificat fonctionnera avec la clef privée correspondante possédée par l'entité identifiée par le certificat.</p> + +<p>En plus de la clef publique, un certificat contient toujours le nom de l'entité qu'il identifie, une date d'expiration, le nom de son AC émettrice, un numéro de série et d'éventuelles autres informations utiles. Plus important, un certificat contient toujours la signature numérique de l'AC émettrice. La signature numérique de l'AC émettrice permet au certificat de fonctionner comme une <em>lettre d'introduction</em> pour les utilisateurs qui connaissent l'AC et lui font confiance mais qui ne connaissent pas l'entité identifiée par le certificat.</p> + +<p>Pour plus d'informations concernant le rôle des autorités de certification (AC), voir « <a href="#Comment_les_certificats_d.27AC_sont_utilis.C3.A9s_pour_.C3.A9tablir_une_relation_de_confiance">Comment les certificats d'AC sont utilisés pour établir une relation de confiance</a> ».</p> + +<h3 id="L'authentification_confirme_une_identité">L'authentification confirme une identité</h3> + +<p>L'<em>authentification</em> est le processus de confirmation d'une identité. Dans le contexte d'interactions entre les réseaux, l'authentification comporte l'identification confiante d'une partie par une autre. L'authentification sur les réseaux peut avoir plusieurs formes. Les certificats sont un moyen d'authentification.</p> + +<p>Les interactions entre les réseaux se font généralement entre un client, tel que le navigateur d'un ordinateur personnel, et un serveur, tel que le matériel et le logiciel hébergeant un site Web. L'<em>authentification cliente</em> se réfère à l'identification confiante d'un client par un serveur (c'est-à-dire, l'identification de la personne supposée utiliser le logiciel client). <em>L'authentification serveur</em> se réfère à l'identification confiante d'un serveur par le client (c'est-à-dire, l'identification de l'organisation supposée être responsable du serveur à une adresse réseau particulière).</p> + +<p>Les authentifications cliente et serveur ne sont pas les seules formes d'authentification permises par les certificats. Par exemple, la signature numérique d'un courriel combinée au certificat identifiant l'expéditeur fournissent une forte preuve que la personne identifiée par le certificat a bien envoyé le message. De même, une signature numérique dans un formulaire HTML combinée à un certificat identifiant le signataire peut fournir une preuve, après coup, que la personne identifiée par le certificat est d'accord avec le contenu du formulaire. En plus de l'authentification, la signature numérique assure, dans les deux cas, un degré de non répudiation (c'est-à-dire que la signature numérique rend difficile la négation ultérieure par le signataire des informations présentes dans le message électronique ou le formulaire).</p> + +<p>L'authentification cliente est un élément essentiel de la sécurité réseau, sur les intranets ou les extranets. Les sections qui suivent présentes deux formes d'authentification cliente :</p> + +<ul> + <li><strong>Authentification basée sur un mot de passe</strong> : Presque tous les serveurs permettent l'authentification cliente à l'aide d'un nom, ou pseudonyme, et d'un mot de passe. Par exemple, un serveur pour demander à un utilisateur de fournir un nom et un mot de passe avant de donner des droits d'accès à certaines parties du serveur. Le serveur maintient une liste des noms et des mots de passe ; si un nom particulier est dans cette liste, et que l'utilisateur fournit le bon mot de passe, le serveur donne des droit d'accès.</li> + <li><strong>Authentification basée sur un certificat</strong> : L'authentification basée sur les certificats est une étape du protocole SSL. Le client signe numériquement des données générées aléatoirement et envoie à la fois ces données signées et le certificat sur le réseau. Le serveur utilise les techniques de cryptographie à clef publique pour valider la signature et confirmer la validité du certificat.</li> +</ul> + +<h4 id="L'authentification_par_mot_de_passe">L'authentification par mot de passe</h4> + +<p>La figure 4 montre les étapes basiques mise en œuvre dans l'authentification d'un client à l'aide d'un nom et d'un mot de passe. Cette figure suppose que :</p> + +<ul> + <li>L'utilisateur a déjà décidé de faire confiance au serveur, sans authentification ou sur la base d'une authentification de serveur via SSL.</li> + <li>L'utilisateur a demandé une ressource contrôlée par le serveur.</li> + <li>Le serveur demande une authentification client avant de donner les droits d'accès aux ressources demandées.</li> +</ul> + +<p><img alt="Figure 4. Utilisation d'un mot de passe pour authentifier un client auprès d'un serveur" class="internal" src="/@api/deki/files/1157/=01pswd.png"></p> + +<p>Voici les étapes décrites dans la figure 4 :</p> + +<ol> + <li>En réponse à une demande d'authentification de la part du serveur, le client affiche une boîte de dialogue demandant le nom de l'utilisateur et son mot de passe pour accéder à ce serveur. L'utilisateur doit fournir séparément un nom et un mot de passe pour chaque nouveau serveur qu'il désire utiliser pendant sa session de travail.</li> + <li>Le client envoie le nom et le mot de passe par le réseau, en clair ou par une connexion SSL chiffrée.</li> + <li>Le serveur vérifie le nom et le mot de passe dans sa base de données locale et, s'ils correspondent, il les accepte comme preuves authentifiant l'identité de l'utilisateur.</li> + <li>Le serveur détermine si l'utilisateur est autorisé à accéder aux ressources demandées, et si oui, autorise le client à y accéder.</li> +</ol> + +<p>Avec cet arrangement, l'utilisateur doit fournir un mot de passe pour chaque serveur, et l'administrateur doit conserver les noms et les mots de passe de chaque utilisateur, généralement sur des serveurs distincts.</p> + +<p>Une implémentation propre ne mémorise pas les mots de passe en texte simple. À la place, il concatène le mot de passe avec une valeur aléatoire propre à chaque utilisateur (également appelée « <em>salt</em> ») et mémorise la valeur hachée du résultat avec le « <em>salt</em> ». Ceci rend plus difficile des attaques de force brute.</p> + +<p>Comme expliqué dans la section suivante, un des avantages de l'authentification par certificat est qu'elle peut être utilisée pour remplacer les trois premières étapes décrites à la figure 4 avec un mécanisme qui permet à l'utilisateur de fournir un seul mot de passe (qui n'est pas transmis à travers le réseau) et permet à l'administrateur de centraliser le contrôle de l'authentification des utilisateurs.</p> + +<h4 id="L'authentification_par_certificat">L'authentification par certificat</h4> + +<p>La figure 5 décrit le fonctionnement d'une authentification client à l'aide des certificats et du protocole SSL. Pour authentifier un utilisateur auprès d'un serveur, Le client signe numériquement des données générées aléatoirement et envoie à la fois ces données signées et le certificat sur le réseau. Pour les besoins de cette discussion, la signature numérique associée aux données signées peut être considérée comme une preuve fournie par le client au serveur. Le serveur authentifie l'identité de l'utilisateur en se basant sur la force de cette preuve.</p> + +<p>Comme pour la figure 4, la figure 5 suppose que l'utilisateur a déjà décidé de faire confiance au serveur et qu'il a demandé une ressource, et que le serveur a demandé une authentification client lors du processus d'évaluation des droits à accéder à la ressource demandée.</p> + +<p><img alt="Figure 5. Utilisation d'une authentification par certificat d'un client auprès d'un serveur" class="internal" src="/@api/deki/files/1159/=02cert.png"></p> + +<p>Contrairement au processus décrit à la figure 4, celui de la figure 5 nécessite d'utiliser SSL. La figure 5 suppose également que le client possède un certificat valide qui peut être utilisé pour l'identifier auprès du serveur. L'authentification par certificat est généralement considérée comme préférable à l'authentification par mot de passe car elle est basée sur ce que l'utilisateur a (la clef privée) aussi bien que sur ce que l'utilisateur sait (le mot de passe qui protège cette clef privée). Cependant, il est important de remarquer que ces deux affirmations ne sont vraies que si aucune personne non autorisée n'a accès à l'ordinateur de l'utilisateur ou a son mot de passe, si le mot de passe de la base de données des clefs privées du logiciel client a été défini, et si le logiciel est paramétré pour demander le mot de passe à intervalles raisonnablement fréquents.</p> + +<p>Ni l'authentification par mot de passe, ni l'authentification par certificat ne répondent aux questions de sécurité soulevées par l'accès physique à l'ordinateur d'un individu ou à ses mots de passe. La cryptographie à clef publique peut uniquement vérifier qu'une clef privée utilisée pour signer des données, correspond à la clef publique présente dans un certificat. Il est de la responsabilité de l'utilisateur de protéger physiquement son ordinateur et de conserver secret le mot de passe de sa clef privée.</p> + +<p>Voici les étapes décrites dans la figure 5 :</p> + +<ol> + <li>Le logiciel client, tel que le navigateur, maintient une base de données des clefs privées correspondantes aux clefs publiques publiées avec tous les certificats émis pour ce client. Le client demande le mot de passe de cette base de données la première fois qu'il a besoin d'y accéder lors d'une session donnée — par exemple, la première fois que l'utilisateur essaie d'accéder à un serveur SSL qui requiert une authentification par certificat. Après avoir renseigné une première fois ce mot de passe, l'utilisateur n'en a plus besoin pour la durée de la session, même en accédant à d'autres serveurs SSL.</li> + <li>Le client débloque la base de données des clefs privées, récupère la clef privée du certificat de l'utilisateur et utilise cette clef privée pour signer numériquement des données générées aléatoirement dans ce but en se basant sur des entrées du client et du serveur. Ces données et la signature numérique constituent une « preuve » de la validité de la clef privée. La signature numérique peut uniquement être créée avec la clef privée et peut être validée par la clef publique associée aux données signées, ce qui est réservé à la session SSL.</li> + <li>Le client envoie le certificat de l'utilisateur et la <em>preuve</em> (les données générées aléatoirement signées numériquement) par le réseau.</li> + <li>Le serveur utilise le certificat et la <em>preuve</em> pour authentifier l'identité de l'utilisateur (pour plus de détails sur ce fonctionnement, voir « <a href="/fr/Introduction_à_SSL" title="fr/Introduction_à_SSL">Introduction à SSL</a> »).</li> + <li>À ce moment, le serveur peut éventuellement exécuter des tâches d'authentification supplémentaires, comme vérifier si le certificat présenté par le client est stocké dans l'entrée de l'utilisateur d'un annuaire LDAP. Le serveur continue alors à évaluer si l'utilisateur identifié est autorisé ou non à accéder à la ressource demandée. Ce processus d'évaluation peut employer une variété de mécanismes standards d'autorisation, en utilisant éventuellement des informations présentes dans un annuaire LDAP, des bases de données d'entreprises, etc. Si le résultat de l'évaluation est positif, le serveur autorise le client à accéder à la ressource demandée.</li> +</ol> + +<p>Comme on peut le voir en comparant les figures 4 et 5, les certificats remplacent la portion de l'authentification correspondant à l'interaction entre le client et le serveur. Plutôt que de demander à l'utilisateur d'envoyer des mots de passe par le réseau à longueur de journée, l'ouverture de session unique demande une seule fois à l'utilisateur de saisir son mot de passe de base de données de clefs privée, sans l'envoyer par le réseau. Pour la suite de la session, le client présente le certificat de l'utilisateur pour authentifier l'utilisateur auprès de chaque serveur auquel il se connecte. Les mécanismes d'autorisation existants basés sur l'authentification de l'identité du l'utilisateur ne sont pas concernés.</p> + +<h3 id="Comment_utiliser_les_certificats">Comment utiliser les certificats</h3> + +<ul> + <li><a href="#Types_de_certificats">Types de certificats</a></li> + <li><a href="#Le_protocole_SSL">Le protocole SSL</a></li> + <li><a href="#Messages_sign.C3.A9s_et_encrypt.C3.A9s">Messages signés et encryptés</a></li> + <li><a href="#Signature_de_formulaire">Signature de formulaire</a></li> + <li><a href="#Ouverture_unique_de_session">Ouverture unique de session</a></li> + <li><a href="#Signature_d.27objet">Signature d'objet</a></li> +</ul> + +<h4 id="Types_de_certificats">Types de certificats</h4> + +<p>Cinq types de certificats sont couramment utilisé avec les produits Red Hat :</p> + +<ul> + <li><strong>Certificats de client SSL</strong> : Utilisés pour identifier des client auprès de serveurs via SSL (authentification client). Généralement, l'identité du client est présumée être la même que celle d'un être humain, tel qu'un employé dans une entreprise. Voir <a href="#_L.27authentification_par_certificat"> L'authentification par certificat</a>, pour une description de la façon dont les certificats d'un client SSL sont utilisés pour l'authentification client. Les certificats d'un client SSL peuvent également être utilisés pour la signature de formulaires et comme composante d'une solution de l'ouverture de session unique.</li> +</ul> + +<dl> + <dt>Exemples </dt> + <dd>Une banque donne un certificat client SSL à l'un de ses usagers qui lui permet de s'identifier auprès du serveur de la banque et d'accéder à ses comptes. Une compagnie peut donner un certificat client SSL à l'un de ses nouveaux employés qui lui permet de s'identifier auprès du serveur de l'entreprise et d'obtenir accès aux ressources disponibles sur ce serveur.</dd> +</dl> + +<ul> + <li><strong>Certificats de serveur SSL</strong> : Utilisé pour identifier les serveurs auprès des client via SSL (authentification serveur). L'authentification serveur peut être utilisée avec ou sans authentification client. L'authentification serveur est obligatoire lors de l'établissement d'une connexion SSL chiffrée. Pour plus d'informations, voir <a href="#Le_protocole_SSL">Le protocole SSL</a>.</li> +</ul> + +<dl> + <dt>Exemple </dt> + <dd>Les sites internet de commerce électronique (communément appelé e-commerce) supportent habituellement l'authentification serveur par certificat, au minimum, pour établir une session SSL chiffrée et assure les clients qu'ils traitent avec un site identifié comme étant celui d'une entreprise donnée. La session SSL assure que les informations personnelles renseignées par le client et transmises par le réseau, telles que son numéro de carte de crédit, ne seront pas aisément interceptées.</dd> +</dl> + +<ul> + <li><strong>Certificats S/MIME</strong> : Utilisés pour signer et chiffrer les courriels. Comme pour les certificats client SSL, l'identité du client est généralement présumé être la même que celle d'un être humain, tel qu'un employé d'une entreprise. Un certificat unique peut être utilisé comme certificat S/MIME et comme certificat SSL (voir <a href="#Messages_sign.C3.A9s_et_chiffr.C3.A9s">Messages signés et chiffrés</a>). Les certificats S/MIME peuvent également être utilisés pour la signature de formulaires et comme composante d'une solution de l'ouverture de session unique.</li> +</ul> + +<dl> + <dt>Exemples </dt> + <dd>Une entreprise déploie des certificats combinés S/MIME et SSL dans l'unique but d'authentifier l'identité des employés, permettant ainsi la signature de messages et l'authentification de client SSL, mais pas le chiffrage des messages. Une autre entreprise émet des certificats S/MIME uniquement dans le but de signer et de chiffrer les messages de natures financière ou légale qu'elle envoie.</dd> +</dl> + +<ul> + <li><strong>Certificats de signature d'objet</strong> : Utilisés pour identifier les signataires de code Java, de scripts JavaScript, ou d'autres fichiers signés. Pour plus d'informations, voir <a href="#Signature_d.27objets">Signature d'objets</a>.</li> +</ul> + +<dl> + <dt>Exemple </dt> + <dd>Une entreprise de logiciel signe les logiciels qu'elle distribue par Internet pour fournir l'assurance à ses utilisateurs que le logiciel est un produit légitime. L'utilisation des certificats et des signatures numériques de cette façon peut également servir pour que les utilisateurs identifient et contrôlent l'accès à leurs ordinateurs des logiciels téléchargés.</dd> +</dl> + +<ul> + <li><strong>Certificats d'AC</strong> : Utilisés pour identifier les autorités de certification (AC). Les logiciels client et serveur utilisent les certificats d'AC pour déterminer quelles autres certifications peuvent être de confiance. Pour plus d'informations, voir <a href="#Utilisation_des_certificats_d.27AC_pour_.C3.A9tablir_la_confiance">Utilisation des certificats d'AC pour établir la confiance</a>.</li> +</ul> + +<dl> + <dt>Exemple </dt> + <dd>Les certificats d'AC stockés dans <em>Communicator</em> déterminent quels autres certificats peuvent être utilisés pour l'authentification. Un administrateur peut implémenter certains aspects de la politique de sécurité de son entreprise en contrôlant les certificats d'AC stockés dans les <em>Communicator</em> de chaque utilisateur.</dd> +</dl> + +<p>Les sections ci-dessous décrivent l'utilisation des certificats dans les produits Red Hat.</p> + +<h4 id="Le_protocole_SSL">Le protocole SSL</h4> + +<p>Le protocole <em>Secure Sockets Layer</em> (SSL) est un ensemble de règles gouvernant l'authentification serveur, l'authentification client et les communications encryptées entre des serveurs et des clients. SSL est largement utilisé sur Internet, particulièrement pour les interactions mettant en œuvre l'échange d'informations confidentielles telles que les numéros de cartes de crédit.</p> + +<p>SSL requiert un certificat SSL serveur, au minimum. Comme partie du processus de négociation, le serveur présente son certificat au client afin d'authentifier son identité. Le processus d'authentification utilise le chiffrement par clef privée et les signatures numériques pour confirmer que ce serveur est bien celui-ci qu'il prétend être. Une fois le serveur authentifié, le client et le serveur utilisent des techniques de chiffrement à clefs symétriques, ce qui est rapide, pour chiffrer toutes les informations qu'ils échangent pour le reste de la session et pour détecter toutes tentatives d'altération des données qui peuvent arriver.</p> + +<p>Les serveurs peuvent éventuellement être configurés pour demander l'authentification client aussi bien que l'authentification serveur. Dans ce cas, après le succès de l'authentification serveur, le client doit à son tour présenter son certificat au serveur afin d'authentifier son identité avant qu'une connexion SSL ne puisse s'établir.</p> + +<p>Pour une présentation de l'authentification client avec SSL et ses différences par rapport à authentification par mot de passe, voir « <a href="#L.27authentification_confirme_une_identit.C3.A9"> L'authentification confirme une identité</a> ». Pour des informations plus détaillées à propos de SSL, voir « <a href="/fr/Introduction_à_SSL" title="fr/Introduction_à_SSL">Introduction à SSL</a> ».</p> + +<h4 id="Messages_signés_et_encryptés">Messages signés et encryptés</h4> + +<p>Certains logiciels de courriers électroniques (y compris Messenger, qui fait parti de Communicator) supportent les messages chiffrés et numériquement signés suivant un protocole largement accepté connu sous le nom de <em>Secure Multipurpose Internet Mail Extension</em> (S/MIME). L'utilisation de S/MIME pour signer et chiffrer des messages requiert que l'expéditeur possède un certificat S/MIME.</p> + +<p>Un message électronique qui comprend une signature numérique fournit l'assurance qu'il a bien été envoyé par la personne dont le nom apparaît dans l'en-tête du message, authentifiant ainsi l'expéditeur. Si la signature numérique ne peut pas être validée pour le courrieleur à la fin de la réception, l'utilisateur est alerté.</p> + +<p>La signature numérique est unique au message qu'elle accompagne. Si le message reçu diffère de quelque manière que se soit du message qui a été envoyé - même par l'ajout ou la suppression d'une virgule - la signature numérique ne peut pas être validée. Par conséquent un message signé fournit aussi une certaine assurance que les données qu'il contient n'ont pas été altérées. Comme on l'a vu au début de ce document, cette sorte d'assurance est connue sous le nom de non répudiation. En d'autres termes, lorsqu'un message est signé, il est très difficile à l'expéditeur de nier l'avoir envoyé. Ceci est capital pour de nombreuses formes de communications commerciales. Pour plus d'informations à propose du mécanisme de signature numérique, voir « <a href="/fr/Introduction_à_la_cryptographie_à_clef_publique/Signatures_numériques" title="fr/Introduction_à_la_cryptographie_à_clef_publique/Signatures_numériques">Signatures numériques</a> ».</p> + +<p>S/MIME rend également possible le chiffrement symétrique (chiffrement à clefs publiques) des messages électroniques. C'est aussi important pour certains utilisateur professionnels. Cependant, l'utilisation du chiffrement pour les messages requiert une gestion soigneuse. Si le destinataire des messages chiffrés perd sa clef et qu'il n'a pas de sauvegarde de la clef, par exemple, les messages chiffrés ne pourront jamais être déchiffrés.</p> + +<h4 id="Signature_de_formulaire">Signature de formulaire</h4> + +<p>De nombreuses formes de e-commerce requièrent la possibilité de fournir une preuve persistante qu'une personne a autorisé une transaction. Bien que SSL fournisse une authentification cliente limitée à la durée de la connexion, il ne fournit pas d'authentification persistante pour les transactions pouvant intervenir pendant cette connexion SSL. S/MIME fournit une authentification persistante pour les messages électroniques, mais le e-commerce utilise souvent des formulaires dans des pages Web plutôt que l'échange de courriel.</p> + +<p>La technologie Red Hat connue sous le nom de <em>signature de formulaire</em> répond au besoin de l'authentification persistante des transactions financières. La signature de formulaire permet à un utilisateur d'associer une signature numérique avec les données Web générées comme résultat d'une transaction, telles qu'un ordre d'achat ou tout autre document financier. La clef privée associée avec soit le certificat SSL client, soit un certificat S/MIME peut être utilisée dans ce but.</p> + +<p>Lorsqu'un utilisateur clique sur le bouton « soumettre » d'un formulaire Web qui supporte la signature de formulaire, une boîte de dialogue affiche le texte exacte à signer. L'auteur du formulaire peut soit spécifier le certificat à utiliser soit sélectionner un certificat SSL ou S/MIME parmi ceux du client installés dans Communicator. Lorsque l'utilisateur clique sur « OK », le texte est signé et les deux (le texte et la signature numérique) sont envoyés au serveur. Le serveur peut alors utiliser un utilitaire Red Hat appelé <em>Signature Verification Tool</em> (Outil de Vérification de Signature) pour valider la signature numérique.</p> + +<p>Pour plus d'informations sur le support des signatures de formulaires dans les produits Red Hat, voir <em>Red Hat Form Signing</em>.</p> + +<h4 id="Ouverture_unique_de_session">Ouverture unique de session</h4> + +<p>Les utilisateurs doivent souvent retenir plusieurs mots de passe pour les différents services qu'ils utilisent. Par exemple, un utilisateur peut devoir saisir des mots de passe différents pour accéder au réseau, collecter ses messages, accéder à un répertoire, utiliser le service d'agenda de son entreprise et accéder à une grande variété de serveurs. La multiplication des mots de passe devient vite un casse-tête pour les utilisateurs comme pour les administrateurs. Les utilisateurs ayant des difficultés à retenir leurs mots de passe ont tendances à en choisir de faible force et à les écrire dans des endroits accessibles. Les administrateurs doivent maintenir une base de données séparée de mot de passe sur chaque serveur et traiter des problèmes potentiels de sécurité liés au fait que des mots de passe sont envoyés sur le réseau par habitude et fréquemment.</p> + +<p>La solution à ce problème requiert un moyen pour l'utilisateur d'ouvrir une session unique, en utilisant un mot de passe unique, et d'obtenir un accès authentifié à toutes les ressources du réseau que l'utilisateur est autorisé à employer - sans envoyer aucun autre mot de passe. Cette possibilité est connue comme <em>ouverture de session unique</em>.</p> + +<p>Both client SSL certificates and S/MIME certificates can play a significant role in a</p> + +<p>Les certificats clients SSL et S/MIME permettent tous deux d'implémenter une ouverture de session unique, voir "<a href="#_L.27authentification_par_certificat">L'authentification par certificat</a>" pour un exemple d'ouverture de session unique basée sur SSL.</p> + +<p>L'utilisateur se connecte à sa base de donnée locale de clé privée à l'aide d'un mot de passe. Puis utilise une clé privée pour signer ses messages et ainsi s'authentifier auprès de tous les serveurs nécessitant une authentification client SSL. Remarquez que dans ce processus le mot de passe n'est pas envoyé à travers le réseau. Cela simplifie l'accès du client au serveur d'une part et la gestion d'authentification côté serveur d'autre part. </p> + +<p>En plus de l'utilisation des certificats, une solution d'ouverture de session unique complète doit être capable d'interopérer avec les systèmes d'entreprise, tels que les systèmes d'exploitation sous-jacents qui s'appuient sur les mots de passe ou toutes autres formes d'authentification.</p> + +<h4 id="Signature_d'objet">Signature d'objet</h4> + +<p>Communicator supporte un ensemble d'outils et de technologies appelés <em>signature d'objet</em>. La signature d'objet utilise des techniques standard de cryptographie à clef publique pour permettre aux utilisateurs d'obtenir des informations fiables à propos du code qu'ils téléchargent de la même façon qu'ils peuvent obtenir des informations fiables à propos des logiciels <em>prêt-à-installer</em>.</p> + +<p>Plus important, la signature d'objet aide les utilisateurs et les administrateurs réseaux à prendre des décisions concernant les logiciels distribués par Internet ou intranet — par exemple, autoriser ou non les applets Java signés par une entité donnée à utiliser certaines fonctionnalités spécifiques d'un ordinateur.</p> + +<p>Les « objets » signés avec les technologies de signature d'objet peuvent être des applets ou tout autre code Java, scripts JavaScript, plugins, ou tout autre type de fichiers. La « signature » est une signature numérique. Les objets signés et leur signature sont généralement stockés dans une archive spéciale appelé archive <code>JAR</code>.</p> + +<p>Les développeurs de logiciels et toute personne désireuse de signer des fichiers à l'aide de cette technique doit tout d'abord obtenir un certificat de signature d'objet.</p> + +<h3 id="Contenu_d'un_certificat">Contenu d'un certificat</h3> + +<p>Le contenu des certificats supportés par Red Hat et de nombreuses autres éditeurs de logiciels sont organisés selon la spécification de certificat X.509 v3, qui a été recommandée par l'International Telecommunications Union (ITU), une organisation de standardisation internationale, depuis 1988.</p> + +<p>Les utilisateurs n'ont généralement pas besoin de connaître le contenu exact d'un certificat. Cependant les administrateurs système travaillant avec les certificats peuvent avoir besoin de se familiariser avec les informations qu'il contient.</p> + +<h4 id="Noms_distincts">Noms distincts</h4> + +<p>Un certificat X.509 v3 relie un nom distinct (<em>distinguished name</em> ou DN en anglais) à une clef publique. Un DN est une série de paires nom-valeur, telle que <code>uid=martin</code>, qui identifie de façon unique une entité (qui est le « sujet » du certificat).</p> + +<p>Par exemple, voici ce que donnerait le DN typique d'un employé de Red Hat, Inc.:</p> + +<pre>uid=martin,e=martin@<code>exemple.net</code>,cn=Jean Martin,o=Red Hat, Inc.,c=FR +</pre> + +<p>Les abréviation devant chaque signe égale « = » de cet exemple on les significations suivantes :</p> + +<ul> + <li><code>uid</code> : ID utilisateur</li> + <li><code>e</code> : adresse électronique</li> + <li><code>cn</code> : le nom courant de l'utilisateur</li> + <li><code>o</code> : organisation</li> + <li><code>c</code> : pays</li> +</ul> + +<p>Les DN peuvent inclure une grande variété d'autres paires nom-valeur. Elles sont utilisées pour identifier à la fois les sujets du certificat et les entrés dans les annuaires qui supportent LDAP (Lightweight Directory Access Protocol).</p> + +<p>Les règles régissant la construction des DN peuvent parfois être complexes et ne font pas parties de l'objectif de ce document. Pour de plus amples informations à propos des DN, voir <em><a class="external" href="http://www.ietf.org/rfc/rfc1485.txt">A String Representation of Distinguished Names (en)</a></em>.</p> + +<h4 id="Un_certificat_typique">Un certificat typique</h4> + +<p>Chaque certificat de type X.509 comprend deux sections :</p> + +<ul> + <li>La section <em>données</em> inclut les informations suivantes : + + <ul> + <li>Le numéro de version du standard X.509 supporté par le certificat.</li> + <li>Le numéro de série du certificat. Chaque certificat émis par une autorité de certification (AC) a un numéro de série unique parmi les certificats émis par cette AC.</li> + <li>Informations</li> + <li>Informations concernant la clef publique de l'utilisateur, comprenant l'algorithme utilisé et une représentation de la clef elle-même.</li> + <li>Le DN de l'AC émettrice du certificat.</li> + <li>La période de validité du certificat (par exemple, entre le 15 novembre 1999 à 13 h 00 et le 15 novembre 2000 à 13 h 00).</li> + <li>Le DN du sujet du certificat (par exemple, dans un certificat client SSL, le DN de l'utilisateur), également appelé le nom du sujet.</li> + <li>Des <em>extensions de certificat</em> optionnelles, pouvant fournir des données supplémentaires utilisées par le client ou le serveur. Par exemple, l'extension de certificat <em>type</em> indique le type auquel appartient le certificat : un certificat client SSL, un certificat serveur SSL, un certificat de signature de message, etc. Les extensions de certificat peuvent également être utilisées pour d'autres raisons.</li> + </ul> + </li> + <li>La section <em>signature</em> inclut les informations suivantes : + <ul> + <li>L'algorithme de cryptographie, ou chiffrement, utilisé par l'AC émettrice pour créer sa propre signature numérique. Pour plus d'informations à propos des chiffrements, voir "<a href="/fr/Introduction_à_SSL" title="fr/Introduction_à_SSL">Introduction à SSL</a>."</li> + <li>La signature numérique de l'AC, obtenue par le hachage de toutes les données contenues dans le certificat et chiffrée avec la clef privée de l'AC.</li> + </ul> + </li> +</ul> + +<p>Voici les sections de données et de signature d'un certificat dans un format lisible par un être humain :</p> + +<pre>Certificate: +Data: + Version: v3 (0x2) + Serial Number: 3 (0x3) + Signature Algorithm: PKCS #1 MD5 With RSA Encryption + Issuer: OU=Ace Certificate Authority, O=Ace Industry, C=US + Validity: + Not Before: Fri Oct 17 18:36:25 1997 + Not After: Sun Oct 17 18:36:25 1999 + Subject: CN=Jane Doe, OU=Finance, O=Ace Industry, C=US + Subject Public Key Info: + Algorithm: PKCS #1 RSA Encryption + Public Key: + Modulus: + 00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86: + ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22: + 43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00: + 98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9: + 73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e: + 9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0: + 7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54: + 91:f4:15 + Public Exponent: 65537 (0x10001) + Extensions: + Identifier: Certificate Type + Critical: no + Certified Usage: + SSL Client + Identifier: Authority Key Identifier + Critical: no + Key Identifier: + f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36: + 26:c9 + Signature: + Algorithm: PKCS #1 MD5 With RSA Encryption + Signature: + 6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06: + 30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb: + f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc: + 2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5: + b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5: + 4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8: + d:c4 +</pre> + +<p>Voici le même certificat affiché au format d'encodage 64 bytes interprété par un logiciel :</p> + +<pre> -----BEGIN CERTIFICATE----- + MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER + MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw + MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK + EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0 + dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG + 7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L + iQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZ + NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV + HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt + I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3 + UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84 + hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A== + -----END CERTIFICATE----- + +</pre> + +<h3 id="Utiliser_les_certificats_pour_établir_la_confiance">Utiliser les certificats pour établir la confiance</h3> + +<p>Les autorités de certification (AC) sont des entités qui valident l'identité et l'émission des certificats. Elles peuvent être des organismes indépendants ou des entreprises qui utilisent leur propre logiciel d'émission de certificats (tel que <em>Red Hat Certificate System</em>).</p> + +<p>Tout logiciel client ou serveur qui supporte les certificats maintient une liste des certificats d'AC de confiance. Ces certificats d'AC déterminent quels autres certificats le logiciel peut valider - en d'autres mots, dans quels émetteurs de certificats le logiciel peut avoir confiance. Dans le cas le plus simple, le logiciel ne peut valider que les certificats émis par une des AC pour lesquelles il possède le certificat. Il est également possible pour un certificat d'une AC de confiance de faire parti d'une chaîne de certificats d'AC, chacun émis par l'AC parente dans la hiérarchie de certificat.</p> + +<p>Les sections suivantes expliquent comment les hiérarchies et les chaînes de certificats déterminent les logiciels de confiance.</p> + +<ul> + <li><a href="#Hi.C3.A9rarchies_d.27AC">Hiérarchies d'AC</a></li> + <li><a href="#Cha.C3.AEnes_de_certificat">Chaînes de certificat</a></li> + <li><a href="#V.C3.A9rification_d.27une_cha.C3.AEne_de_certificat">Vérification d'une chaîne de certificat</a></li> +</ul> + +<h4 id="Hiérarchies_d'AC">Hiérarchies d'AC</h4> + +<p>Dans les grandes organisations, il peut être judicieux de déléguer la responsabilité de l'émission des certificats à plusieurs autorités de certification. Par exemple, le nombre de certificats requis peut être trop important à maintenir par une seule AC ; les différents services de l'organisation peuvent avoir différentes politiques d'attribution des certificats ; ou il peut être important pour l'AC d'être physiquement localisée dans la même zone géographique que les personnes auxquelles elle délivre les certificats.</p> + +<p>Il est possible de déléguer la responsabilité de l'émission de certificats à des AC subordonnées. Le standard X.509 inclus un modèle de paramétrage d'une hiérarchie d'AC telle celle montrée à la Figure 6.</p> + +<p><img alt="Figure 6. Exemple de hiérarchie d'AC" class="internal" src="/@api/deki/files/1166/=14HIER.gif"></p> + +<p>Dans ce modèle, l'AC racine est au sommet de la hiérarchie. Le certificat de l'AC racine est un « certificat auto-signé » : c'est-à-dire que le certificat est signé numériquement par la même entité — L'AC racine — que celle que le certificat identifie. Les AC directement subordonnées à l'AC racine on des certificats d'AC signés par l'AC racine. Les AC se trouvant sous les AC subordonnées dans la hiérarchie ont leurs certificats signés par les plus hautes AC subordonnées.</p> + +<p>Les organisations ont une grande flexibilité quant à l'établissement de leurs hiérarchies d'AC. La figure 6 ne montre qu'un exemple ; beaucoup d'autres hiérarchies sont possibles.</p> + +<h4 id="Chaînes_de_certificat">Chaînes de certificat</h4> + +<p>Les hiérarchie d'AC se reflètent dans les chaînes de certificats. Une <em>chaîne de certificats</em> est une série de certificats émis par des AC successives. La figure 7 montre une chaîne de certificats <strong>leading from a certificate that identifies some entity through two subordinate CA certificates to the CA certificate for the root CA (based on the CA hierarchy shown in Figure 6).</strong></p> + +<p><img alt="Figure 7. Exemple de chaîne de certificat" class="internal" src="/@api/deki/files/1167/=15chn.gif"></p> + +<p>Une chaîne de certificats trace le chemin des certificats d'une branche de la hiérarchie jusqu'à la racine. Dans une chaîne de certificats, on a donc :</p> + +<ul> + <li>chaque certificat est suivi par le certificat de son émetteur.</li> + <li>chaque certificat contient le nom (DN) de l'émetteur du certificat, qui est identique à celui du nom du sujet du certificat suivant dans la chaîne.</li> +</ul> + +<p>Dans la figure 7, Le certificat <em>Engineering CA</em> contient le DN de l'AC (qui est <em>USA CA</em>), qui a émis le certificat. Le DN de <em>USA CA</em> est également le nom du sujet du prochain certificat dans la chaîne.</p> + +<ul> + <li>Chaque certificat est signé avec la clef privée de son émetteur. La signature peut être vérifiée avec la clef publique du certificat de l'émetteur, qui est le prochain certificat dans la chaîne.</li> +</ul> + +<p>Dans la figure 7, la clef publique dans le certificat de <em>USA CA</em> peut être utilisée pour vérifier que la signature numérique de <em>USA CA</em> dans le certificat de <em>Engineering CA</em>.</p> + +<h4 id="Vérification_d'une_chaîne_de_certificat">Vérification d'une chaîne de certificat</h4> + +<p>La vérification de la chaîne de certificats est le processus permettant de s'assurer que la chaîne de certificats donnée est bien formée, proprement signée et sécurisée. Les logiciels Red Hat utilisent la procédure suivante pour former et vérifier une chaîne de certificats, en commençant par le certificat présenté pour l'authentification :</p> + +<ol> + <li>La période de validité du certificat est vérifiée par rapport à la date actuelle fournie par l'horloge système du vérificateur.</li> + <li>Le certificat de l'émetteur est localisé. La source peut être une base de certificats locale du vérificateur (du client ou du serveur) ou une chaîne de certificats fournit par le sujet (par exemple, par une connexion SSL).</li> + <li>La signature du certificat est vérifiée à l'aide de la clef publique du certificat de l'émetteur.</li> + <li>Si le certificat de l'émetteur est présent dans les certificats de confiance du vérificateur, la vérification s'arrête avec succès à cette étape. Autrement, le certificat de l'émetteur est vérifié pour être certain qu'il contient les indications appropriées concernant les AC subordonnées dans l'extension du type de certificat de Red Hat, et la chaîne de vérification recommence depuis l'étape 1, mais avec le nouveau certificat. La figure 8 présente un exemple de ce processus.</li> +</ol> + +<p><img alt="Figure 8. Vérification d'un chaîne de certificats complète, jusqu'à l'AC racine" class="internal" src="/@api/deki/files/1168/=16chver.gif"></p> + +<p>La figure 8 décrit ce qui se passe lorsque seule l'AC racine est incluse dans la base locale de certificats du vérificateur. Si un certificat d'une des AC intermédiaires présentes dans cette figure, telle que <em>Engineering CA</em>, est trouvé dans la base locale de certificats du vérificateur, la vérification s'arrête à ce certificat, comme décrit à la figure 9.</p> + +<p><img alt="Figure 9. Vérification d'une chaîne de certificats, jusqu'à une AC intermédiaire" class="internal" src="/@api/deki/files/1169/=19chver.gif"></p> + +<p>Des dates de validité expirées, une signature invalide ou l'absence d'un certificat pour l'AC émettrice à n'importe quelle étape de la chaîne de certificats provoquera un échec de l'authentification. Par exemple, la figure 10 montre l'échec d'une vérification si le certificat de l'AC racine ou celui d'une AC intermédiaire ne sont pas présent dans la base locale de certificats du vérificateur.</p> + +<p><img alt="Figure 10. Une chaîne de certificat qui ne peut pas être vérifiée" class="internal" src="/@api/deki/files/1170/=20chver.gif"></p> + +<p>Pour des informations générales sur le fonctionnement des signatures numériques, voir « <a href="/fr/Introduction_à_la_cryptographie_à_clef_publique/Signatures_numériques" title="fr/Introduction_à_la_cryptographie_à_clef_publique/Signatures_numériques">Signatures numériques</a> ». Pour une description plus détaillée sur le processus de vérification des signatures dans le contexte d'une authentification SSL client-serveur, voir « <a href="/fr/Introduction_à_SSL" title="fr/Introduction_à_SSL">Introduction à SSL</a> ».</p> + +<p>{{PreviousNext("Introduction à la cryptographie à clef publique:Signatures numériques", "Introduction à la cryptographie à clef publique:Gestion des certificats", "Gestion des certificats")}}</p> diff --git a/files/fr/introduction_à_la_cryptographie_à_clef_publique/chiffrement_et_déchiffrement/index.html b/files/fr/introduction_à_la_cryptographie_à_clef_publique/chiffrement_et_déchiffrement/index.html new file mode 100644 index 0000000000..6abf3ba1dc --- /dev/null +++ b/files/fr/introduction_à_la_cryptographie_à_clef_publique/chiffrement_et_déchiffrement/index.html @@ -0,0 +1,55 @@ +--- +title: Chiffrement et déchiffrement +slug: Introduction_à_la_cryptographie_à_clef_publique/Chiffrement_et_déchiffrement +tags: + - Sécurité +--- +<p>Le chiffrement est un processus de transformation des informations de façon à les rendre inintelligibles à toute personne autre que le destinataire. Le déchiffrement est le processus inverse du chiffrement, il sert à transformer les informations de façon à les rendre à nouveau intelligibles. Un algorithme de cryptographie, également appelé chiffre, est une fonction mathématique utilisée pour le chiffrement ou le déchiffrement. Dans la plupart des cas, deux fonctions complémentaires sont employées, l'une pour le chiffrement et la second pour le déchiffrement.</p> + +<p>Dans la cryptographie moderne, la possibilité de conserver des informations secrètes ne se fait pas à partir de l'algorithme de cryptographie, largement connu, mais avec un nombre appelé clef qui doit être utilisé avec l'algorithme de cryptographie afin de produire un résultat chiffré ou pour déchiffrer des informations précédemment chiffrées. Le déchiffrement avec la bonne clef est simple. Sans cette clef, il devient très difficile et dans certains cas impossible pour tous les besoins pratiques.</p> + +<p>Les sections suivantes introduisent à l'utilisation des clefs pour le chiffrement et le déchiffrement.</p> + +<ul> + <li><a href="#Chiffrement_par_clef_sym.C3.A9trique">Chiffrement par clef symétrique</a></li> + <li><a href="#Chiffrement_par_clef_publique">Chiffrement par clef publique</a></li> + <li><a href="#Longueur_de_clef_et_force_du_chiffrement">Longueur de clef et force du chiffrement</a></li> +</ul> + +<h3 id="Chiffrement_par_clef_sym.C3.A9trique" name="Chiffrement_par_clef_sym.C3.A9trique">Chiffrement par clef symétrique</h3> + +<p>Avec le chiffrement par clef symétrique, le chiffrement peut être calculé avec la clef de déchiffrement et vice versa. Avec la plupart des algorithme symétrique, la même clef est utilisée pour le chiffrement et le déchiffrement, comme indiqué sur la figure 1.</p> + +<p><img alt="Figure 1. Chiffrement par clef symétrique"></p> + +<p>L'implémentation d'un chiffrement par clef symétrique peut être hautement efficace, ainsi les utilisateurs ne subissent pas de longs délais d'attente lors du chiffrement ou du déchiffrement. Le chiffrement par clef symétrique fournit un haut degré d'authentification, car les informations chiffrées avec une clef symétrique ne peuvent pas être déchiffrées avec une clef symétrique différente. Ainsi, tant que la clef symétrique est gardée secrète par les deux correspondants qui l'utilise pour le chiffrement de leurs communications, chacun d'eux est assuré qu'il communique bien avec l'autre aussi longtemps que les messages déchiffrés ont un sens.</p> + +<p>Le chiffrement par clef symétrique est efficace tant que les deux parties en présence gardent la clef secrète. Si quelqu'un d'autre découvre la clef, cela met en cause la confidentialité et l'authenticité des informations échangées. Une personne possédant une clef symétrique non autorisée peut non seulement déchiffrer les messages envoyé avec cette clef, mais elle peut également chiffrer de nouveaux messages et les envoyer comme s'ils provenaient d'un des deux correspondants qui utilisait originellement la clef.</p> + +<p>Le chiffrement par clef symétrique joue un rôle important dans le protocole SSL, qui est largement utilisé pour l'authentification, la détection des altérations de données, et le chiffrement sur les réseaux TCP/IP. SSL utilise également les techniques de chiffrement par clef publique qui est décrit dans la section suivante.</p> + +<h3 id="Chiffrement_par_clef_publique" name="Chiffrement_par_clef_publique">Chiffrement par clef publique</h3> + +<p>Les implémentations du chiffrement à clef publique les plus communément utilisées sont fondées sur des algorithmes brevetés par<em>RSA Data Security</em>. Par conséquent, cette section décrit l'approche RSA du chiffrement à clef publique.</p> + +<p>Le chiffrement à clef publique (également appelé chiffrement asymétrique) utilise une paire de clefs, l'une publique et l'autre privée, associées à une entité qui a besoin d'authentifier son identité de façon électronique ou de chiffrer des données. La clef publique est publiée et la clef privée correspondante est conservée secrète par l'entité. Pour plus d'informations sur les moyens de publication des clefs publiques, voir « <a href="fr/Introduction_%c3%a0_la_cryptographie_%c3%a0_clef_publique/Certificats_et_authentification">Certificats et Authentification</a> ». Les données chiffrées avec la clef publique ne peuvent être déchiffrées qu'avec votre clef privée. <a href="#Figure2">Figure 2</a> montre une vue simplifiée du fonctionnement du chiffrement par clef publique.</p> + +<p><img alt="Figure 2. Chiffrement par clef publique"></p> + +<p>Dans le schéma de la Figure 2, vous distribuez librement une clef publique, et vous seul serez capable de lire les données chiffrées en utilisant cette clef. En général, pour envoyer des données chiffrées à quelqu'un, vous chiffrez les données avec la clef publique de cette personne, et le destinataire des données chiffrées les déchiffrera avec la clef privée correspondante.</p> + +<p>Comparée au chiffrement par clef symétrique, le chiffrement par clef publique requiert plus de calcul et il n'est donc pas toujours adapté pour de grandes quantités de données. Cependant, il est possible d'utiliser le chiffrement par clef publique pour envoyer une clef symétrique, qui peut alors être utilisée pour chiffrer des données supplémentaires. C'est cette approche qu'utilise le <a href="fr/Introduction_%c3%a0_SSL#Le_protocole_SSL">protocole SSL</a>.</p> + +<p>Comme cela peut arriver, l'opération inverse de celle décrite dans la figure 2 est également possible : les données chiffrées avec votre clef privée ne peuvent être déchiffrées qu'avec votre clef public. Cependant ce n'est pas le meilleur moyen de chiffrer des données sensibles, car cela signifie que n'importe qui possédant votre clef publique, qui par définition est publiée, pourra déchiffrer les données. Néanmoins, le chiffrement par clef publique est utile, parce qu'il signifie que vous pouvez utiliser votre clef privée pour signer des données avec votre signature numérique - une condition importante pour le commerce électronique ou tout autre application commerciale de la cryptographie. Les logiciels clients tels que Netscape Communicator peuvent alors utiliser votre clef publique pour confirmer que le message a été signé avec votre clef privée et qu'il n'a pas été altéré depuis sa signature. « <a href="fr/Introduction_%c3%a0_la_cryptographie_%c3%a0_clef_publique/Signatures_num%c3%a9riques">Signatures numériques</a> » et les sections suivantes décrivent le fonctionnement du processus de confirmation.</p> + +<h3 id="Longueur_de_clef_et_force_du_chiffrement" name="Longueur_de_clef_et_force_du_chiffrement">Longueur de clef et force du chiffrement</h3> + +<p>En général, la force d'un chiffrement est rapporté à la difficulté à casser la clef, qui dépend à la foi du chiffrement utilisé et de la longueur de la clef. Par exemple, la difficulté de découvrir la clef du chiffrement RSA le plus communément utilisé pour le chiffrement par clef publique dépend de la difficulté de factoriser de grands nombres, un problème mathématique bien connu.</p> + +<p>La force d'un chiffrement est souvent décrite en terme de taille des clefs utilisées pour l'encryptage : en général, les plus longues clefs fournissent les plus forts chiffrements. La longueur d'une clef se mesure en bits. Par exemple, des clefs de 128 bits utilisées avec un chiffrement par clef symétrique RC4 supportées par SSL fournissent significativement une meilleure protection cryptographique que des clefs de 40 bits associées au même chiffrement. En gros, un chiffrement RC4 128 bits est 3 x 10<sup>26</sup> fois plus fort qu'un chiffrement RC4 40 bits. Pour plus d'informations à propos de RC4 et des autres chiffrements utilisés avec SSL, voir « <a href="fr/Introduction_%c3%a0_SSL">Introduction à SSL</a> ».</p> + +<p>Les différent chiffrements peuvent requérir différentes longueurs de clef pour parvenir au même niveau de cryptage. Le chiffrement RSA utilisé pour le chiffrement par clef publique, par exemple, ne peut utiliser qu'un sous-ensemble de toutes les valeurs possibles pour une clef d'une longueur donnée, à cause de la nature du problème mathématique sur lequel il est basé. Les autres chiffrements, tels que ceux utilisés par le chiffrement à clef symétrique, peuvent utiliser toutes les valeurs possibles pour une clef de longueur donnée, plutôt qu'un sous-ensemble de ces valeurs. Ainsi, une clef de 128 bits associée à un chiffrement par clef symétrique fournira un meilleur cryptage des données qu'une clef de 128 bits associée à un chiffrement RSA par clef publique. Cette différence explique pourquoi les chiffrement par clef publique RSA doivent utiliser des clefs de 512 bits (voire plus) pour être considérés forts du point du vue cryptographique, alors que les chiffrements par clef symétrique peuvent parvenir au même niveau de protection avec une clef de 64 bits. Même ce haut niveau de chiffrement peut être vulnérable aux attaques extérieures dans un futur proche.</p> + +<p>Parce que la possibilité d'intercepter clandestinement des informations chiffrées et de pouvoir les déchiffrer est historiquement une importante activité militaire, le gouvernement étasunien a restreint l'exportation de logiciels de cryptographie, incluant la plupart des logiciels permettant l'utilisation de clefs de chiffrement de plus de 40 bits</p> + +<p>{{PreviousNext("Introduction à la cryptographie à clef publique:Les problèmes de sécurité sur Internet", "Introduction à la cryptographie à clef publique:Signatures numériques")}}</p> diff --git a/files/fr/introduction_à_la_cryptographie_à_clef_publique/gestion_des_certificats/index.html b/files/fr/introduction_à_la_cryptographie_à_clef_publique/gestion_des_certificats/index.html new file mode 100644 index 0000000000..cd835c6f24 --- /dev/null +++ b/files/fr/introduction_à_la_cryptographie_à_clef_publique/gestion_des_certificats/index.html @@ -0,0 +1,53 @@ +--- +title: Gestion des certificats +slug: Introduction_à_la_cryptographie_à_clef_publique/Gestion_des_certificats +tags: + - Sécurité +--- +<p>L'ensemble des standards et des services facilitant l'utilisation de la cryptographie à clef publique et des certificats X.509 v3 dans un environnement réseau est appelé <em>public key infrastructure</em> (PKI ou infrastructure à clef publique). La gestion de PKI est un sujet complexe qui dépasse le cadre de se document. Les sections qui suivent présentent quelques-uns des problèmes liés à la gestion de certificats qu'on retrouve dans les produits Red Hat.</p> + +<h3 id="Émission_de_certificats">Émission de certificats</h3> + +<p>Le processus d'émission d'un certificat dépend de l'autorité de certification qui l'a émis et du but dans lequel il l'a été. Les processus d'émission de formulaires non numériques varient de façons identiques. Par exemple, si vous désirez obtenir une carte d'identité générique (pas un permis de conduire) du Department of Motor Vehicles de l'état de California, les conditions sont claires : vous devez présenter un justificatif d'identité, tel qu'une facture à votre nom, et une carte d'étudiant. Si vous désirez un permis de conduire en bonne et due forme, vous devez en plus passer un test de conduite la première fois que vous le réclamez et un test sur le code de la route pour son renouvellement. Si vous voulez obtenir un permis de conduire commercial pour un 38-tonnes, les conditions sont plus exigeantes. Si vous vivez dans un autre état ou un autre pays, les conditions d'obtention de ces différents permis de conduire seront différentes.</p> + +<p>De même, les différentes autorités de certification ont différentes procédures d'émission des différents types de certificats. Dans certains cas, la seule condition pourra être votre adresse électronique. Dans d'autres cas, un nom d'utilisateur et un mot de passe vous seront demandés. À l'autre bout de l'échelle, pour les certificats identifiants des personnes pouvant prendre des décisions importantes, le processus d'émission pourra requérir des documents notariés, une enquête de fond et un entretien personnel.</p> + +<p>Selon les politiques de l'organisation, le processus d'émission des certificats peut soit être complètement transparent pour l'utilisateur, soit exiger une participation significative de l'utilisateur et des procédures complexes. En général, l'émission de certificats doit être flexible, ainsi les organisations peuvent les adapter à leurs besoins.</p> + +<p><a class="external" href="http://www.redhat.com/docs/manuals/cert-system/index.html">Red Hat Certificate System permet à une organisation de paramètrer sa propre autorité de certification et d'émission de certificats.</a></p> + +<p>L'émission de certificats est l'une des nombreuses tâches de gestion qui peuvent être déléguées à une autorité de certification indépendante.</p> + +<h3 id="Certificats_et_annuaire_LDAP">Certificats et annuaire LDAP</h3> + +<p>Le<em>Lightweight Directory Access Protocol</em> (LDAP) d'accès aux services d'annuaire propose une grande flexibilité pour la gestion des certificats d'une organisation. Les administrateurs systèmes peuvent stocker la plupart des informations requises par la gestion des certificats dans un annuaire compatible LDAP. Par exemple, une autorité de certification peut utiliser les informations contenues dans un annuaire pour préremplir un certificat avec les informations concernant un nouvel employé. L'autorité de certification peut niveler les informations de l'annuaire de nombreuses manières pour émettre les certificats un à un ou en groupe, en utilisant un éventail des différentes techniques d'identification en fonction de la politique de sécurité d'une organisation donnée. Les autres routines des tâches de gestion, telles que la gestion de clefs, le renouvellement ou la révocation de certificats, peuvent être partiellement ou pleinement automatisées à l'aide de l'annuaire.</p> + +<p>Les informations stockées dans l'annuaire peuvent également être utilisées en association avec les certificats pour contrôler l'accès aux différentes ressources disponibles sur un réseau en fonction des utilisateurs ou des groupes d'utilisateurs. L'émission de certificats et toutes les tâches de gestion des certificats font intégralement parties de la gestion des utilisateurs et des groupes d'utilisateurs.</p> + +<p>En général, les services d'annuaires performants sont une brique essentielle de toute stratégie de gestion des certificats. Red Hat<em>Directory Server</em> est pleinement intégré à Red Hat<em>Certificate System</em> afin de fournir une solution de gestion des certificats complète.</p> + +<h3 id="Gestion_des_clefs">Gestion des clefs</h3> + +<p>Avant d'émettre un certificat, la clef publique qu'il contient et la clef privée correspondante doivent être générées. Il est parfois plus utile d'émettre, pour une unique personne, un certificat et une paire de clefs pour les opérations de signature, et un second certificat et une paire de clefs pour les opérations de chiffrement. Séparer les certificats de signature et de chiffrement permet de conserver la clef de signature uniquement sur une machine local, assurant ainsi une non répudiation maximale, et de sauvegarder la clef privée de chiffrement dans un endroit centralisé où elle peut être récupérée au cas où l'utilisateur perdrait la clef originale ou quitterait l'entreprise.</p> + +<p>Les clefs peuvent être générées par un logiciel client ou générées de façon centralisée par l'autorité de certification puis distribuées aux utilisateurs via un annuaire LDAP. Il y a plusieurs options entrant dans le choix du type de génération des clefs, locale et centralisée. Par exemple, la génération locale des clefs assure une non répudiation maximale, mais elle peut induire une plus grande participation de l'utilisateur lors des étapes d'émission. La flexibilité des possibilités dans la gestion des clefs est essentielle pour la plupart des organisations.</p> + +<p><em>Le recouvrement de clef</em>, ou la capacité de récupérer une sauvegarde des clefs de chiffrement suivant des conditions bien définies, peut être un point important de la gestion des certificats (selon l'utilisation des certificats par l'organisation). Les schémas de recouvrement de clefs mettent habituellement en œuvre un mécanisme de type<em>m sur n</em> : par exemple,<em>m</em> dirigeants d'une organisation sur<em>n</em> doivent donner leur accord, chacun contribuant à l'aide d'un code (ou d'une clef) personnel et spécial, avant que la clef d'une personne en particulier puisse être récupérée. Ce type de mécanisme assure que plusieurs personnes autorisées doivent donner leur accord avant qu'une clef de chiffrement puisse être récupérée.</p> + +<h3 id="Renouvellement_et_révocation_de_certificats">Renouvellement et révocation de certificats</h3> + +<p>Comme un permis de conduire dans certains pays, un certificat spécifie une période de temps pendant laquelle il est valide. Les tentatives d'utilisation d'un certificat avant ou après la période de validité échoueront. Par conséquent, les mécanismes de gestion du renouvellement des certificats sont essentiels dans toute stratégie de gestion des certificats. Par exemple, un administrateur voudra être notifié automatiquement lorsqu'un certificat s'apprête à expirer, afin de compléter le processus de renouvellement approprié pendant le temps restant, sans gêner le détenteur du certificat. Le processus de renouvellement peut impliquer la réutilisation de la même paire de clefs publiques ou d'une nouvelle paire.</p> + +<p>Un permis de conduire peut être suspendu, même s'il n'est pas périmé - par exemple, suite à une décision de justice pour infraction grave au code de la route. De même, il est parfois nécessaire de révoquer un certificat avant sa date d'expiration - par exemple, si un employé quitte l'entreprise ou s'il est muté dans un autre service.</p> + +<p>La révocation des certificats peut être gérée de différentes manières. Pour certaines organisations, il peut être suffisant de paramétrer les serveurs afin que le processus d'authentification inclut la vérification de la présence du certificat présenté dans l'annuaire. Lorsqu'un administrateur révoque un certificat, le certificat peut être automatiquement supprimé de l'annuaire et ainsi toutes les tentatives d'authentification échoueront, même si le certificat reste valide dans tous les autres domaines. Une autre approche implique la publication d'une <em>Certificates Revocation List</em> (CRL ou liste de certificats révoquées) dans l'annuaire à intervalles réguliers et la vérification de cette liste lors du processus d'authentification. Pour d'autres organisation, il sera peut-être préférable de vérifier directement l'autorité de certification émettrice chaque fois qu'un certificat est présenté pour une authentification. Ce processus est parfois appelé vérification de l'état d'un certificat en temps réel.</p> + +<h3 id="Autorités_d'enregistrement">Autorités d'enregistrement</h3> + +<p>Les interactions entre les entités identifiées par des certificats (parfois appelées entités finales) et les autorités de certifications (AC, pour <em>Certificates Authority</em>) sont un élément essentiel de la gestion des certificats. Ces interactions incluent les opérations telles que l'enregistrement de la certification, le recouvrement, le renouvellement ou la révocation de certificats, et la sauvegarde et le recouvrement de clefs. En général, une AC (Autorité de certification) doit être en mesure d'authentifier les identités des entités finales avant de répondre à leurs requêtes. De plus, certaines requêtes doivent être approuvées par un administrateur autorisé ou un gestionnaire afin d'aboutir.</p> + +<p>Comme on l'a vu précédemment, les moyens mis en œuvre par les différentes AC pour vérifier une identité avant d'émettre un certificat sont très nombreux selon l'organisation et le domaine d'utilisation du certificat. Pour fournir une flexibilité opérationnelle maximale, les interactions avec les entités finales peuvent être séparées des autres fonctions d'une AC et gérées par un service séparé appelé une <em>Registration Authority</em> (RA, ou Autorité d'enregistrement).</p> + +<p>Une RA (autorité d'enregistrement) agît comme une application amont de l'AC, en recevant les requêtes des entités finales, en les authentifiant puis en les renvoyant vers l'AC. Après réception de la réponse de l'AC, la RA notifie les résultats à l'entité finale. Les RA peuvent être très utiles pour adapter une infrastructure à clef publique à différents départements, zones géographiques, ou d'autres unités opérationnelles ayant des politiques et des exigences d'authentification très différentes.</p> + +<p>{{Previous("Introduction à la cryptographie à clef publique:Certificats et authentification")}}</p> diff --git a/files/fr/introduction_à_la_cryptographie_à_clef_publique/index.html b/files/fr/introduction_à_la_cryptographie_à_clef_publique/index.html new file mode 100644 index 0000000000..ffa18e0573 --- /dev/null +++ b/files/fr/introduction_à_la_cryptographie_à_clef_publique/index.html @@ -0,0 +1,31 @@ +--- +title: Introduction à la cryptographie à clef publique +slug: Introduction_à_la_cryptographie_à_clef_publique +tags: + - Sécurité +translation_of: Archive/Security/Introduction_to_Public-Key_Cryptography +--- +<h3 id="Introduction" name="Introduction">Introduction</h3> + +<p>La cryptographie à clef publique ainsi que les standards et les techniques qui s'y rapportent sont à la base des dispositifs de sécurité de nombreux produits Red Hat. Cela comprend : la signature et le chiffrement de messages électroniques, la signature de formulaire, la signature d'objet, les ouvertures de session unique et le protocole SSL (Secure Sockets Layer). Ce document est une introduction aux concepts de base de la cryptographie à clef publique.</p> + +<ul> + <li><a href="fr/Introduction_%c3%a0_la_cryptographie_%c3%a0_clef_publique/Les_probl%c3%a8mes_de_s%c3%a9curit%c3%a9_sur_Internet">Les problèmes de sécurité sur Internet</a></li> + <li><a href="fr/Introduction_%c3%a0_la_cryptographie_%c3%a0_clef_publique/Chiffrement_et_d%c3%a9chiffrement">Chiffrement et déchiffrement</a></li> + <li><a href="fr/Introduction_%c3%a0_la_cryptographie_%c3%a0_clef_publique/Signatures_num%c3%a9riques">Signatures numériques</a></li> + <li><a href="fr/Introduction_%c3%a0_la_cryptographie_%c3%a0_clef_publique/Certificats_et_authentification">Certificats et authentification</a></li> + <li><a href="fr/Introduction_%c3%a0_la_cryptographie_%c3%a0_clef_publique/Gestion_des_certificats">Gestion des certificats</a></li> +</ul> + +<p>Pour une présentation de SSL, voir l'article « <a href="fr/Introduction_%c3%a0_SSL">Introduction à SSL</a> ».</p> + +<div class="originaldocinfo"> +<h3 id="Informations_sur_le_document_original" name="Informations_sur_le_document_original">Informations sur le document original</h3> + +<ul> + <li>Auteur(s) : Noms des auteurs</li> + <li>Autres contributeurs : Giacomo Magnini</li> + <li>Dernière mise à jour : 26 septembre 2005</li> + <li>Copyright : © 2001 Sun Microsystems, Inc. Used by permission. © 2005 Red Hat, Inc. Tous droits réservés.</li> +</ul> +</div> diff --git a/files/fr/introduction_à_la_cryptographie_à_clef_publique/les_problèmes_de_sécurité_sur_internet/index.html b/files/fr/introduction_à_la_cryptographie_à_clef_publique/les_problèmes_de_sécurité_sur_internet/index.html new file mode 100644 index 0000000000..9e79f1d777 --- /dev/null +++ b/files/fr/introduction_à_la_cryptographie_à_clef_publique/les_problèmes_de_sécurité_sur_internet/index.html @@ -0,0 +1,36 @@ +--- +title: Les problèmes de sécurité sur Internet +slug: >- + Introduction_à_la_cryptographie_à_clef_publique/Les_problèmes_de_sécurité_sur_Internet +tags: + - Sécurité +--- +<p>Toutes les communications Internet utilisent le<em>Transmission Control Protocol/Internet Protocol</em> (TCP/IP). TCP/IP permet d'envoyer des informations d'un ordinateur à un autre au travers d'une grande variété d'ordinateurs intermédiaires et de réseaux distincts avant qu'elles atteignent leur destination.</p> + +<p>La grande flexibilité de TCP/IP à conduit à son adoption mondiale en tant que protocole de base pour les communications Internet et Intranet. Dans le même temps, le fait que TCP/IP permettent aux informations de transiter par de nombreux ordinateurs intermédiaires rend possible à une tierce-partie d'interférer avec les communications des façons suivantes :</p> + +<ul> + <li><strong>Écoute clandestine</strong>. Les informations restent intactes, mais leur confidentialité est compromise. Par exemple, quelqu'un peut intercepter votre numéro de carte de crédit, enregistrer des conversations sensibles ou intercepter des informations classifiées.</li> + <li><strong>Altération de données</strong>. Les informations en transit sont modifiées ou remplacées puis envoyées au destinataire. Par exemple, quelqu'un peut altérer une commande de biens de consommation ou changer les données personnelles d'un internaute.</li> + <li><strong>Usurpation d'identité</strong>. Les informations sont transmises à une personne se faisant passer pour le destinataire. L'usurpation d'identité peut être de deux natures différentes : + <ul> + <li>Mystification (ou spoofing en anglais). Une personne peut prétendre être quelqu'un d'autre. Par exemple, une personne peut prétendre avoir l'adresse électronique <code><a class="link-mailto" href="mailto:jdoe@exemple.net" rel="freelink">jdoe@exemple.net</a></code>, ou un ordinateur peut s'identifier comme étant le domaine <code>www.exemple.net</code> alors qu'il ne l'est pas. Ce type d'usurpation est connu sous le nom de spoofing.</li> + <li>Fausse déclaration. Une personne ou une organisation peut se présenter faussement. Par exemple, le site <code>www.exemple.net</code> peut prétendre être un site de vente de meubles en lignes alors qu'il ne prend que les paiement par cartes de crédits mais qu'il n'envoie aucune marchandise.</li> + </ul> + </li> +</ul> + +<p>Normalement, les utilisateurs des nombreux ordinateurs coopérant ensemble à l'existence d'Internet, ou de toute autre réseau, ne surveillent pas et n'interfèrent pas avec le trafic réseau circulant continuellement par leurs machines. Cependant, de nombreuses données personnelles sensibles et les transactions commerciales sur Internet requièrent certaines précautions afin de minimiser les risques dus aux menaces listées ci-dessus. Heureusement, un ensemble de techniques et de standards bien rodés, connu sous le nom de cryptographie à clef publique, rend plus facile la mise en place de telles précautions.</p> + +<p>La cryptographie à clef publique facilite les tâches suivantes :</p> + +<ul> + <li>Le chiffrement et le déchiffrement permettent à deux entités communicantes de<em>déguiser</em> les informations qu'elles s'échangent. L'expéditeur chiffre, ou brouille, les informations avant de les envoyer. Le destinataire déchiffre, ou décode, ces informations après leur réception. Lors du transit, les informations cryptées sont inintelligibles aux tierces personnes.</li> + <li>La détection de l'altération permet au destinataire des informations de vérifier qu'elles n'ont pas été modifiées lors du transit. Toute tentative de modifier les données ou de leur substituer un faux message sera détecté.</li> + <li>L'authentification permet au destinataire des informations de déterminer leur origine, pour confirmer l'identité de l'expéditeur.</li> + <li>La non-répudiation empêche l'expéditeur des informations de prétendre par la suite de ne pas les avoir envoyées.</li> +</ul> + +<p>Les sections qui suivent introduisent les concepts de cryptographie à clef publique qui sont à la base de ces possibilités.</p> + +<p>{{PreviousNext("Introduction à la cryptographie à clef publique", "Introduction à la cryptographie à clef publique:Chiffrement et déchiffrement")}}</p> diff --git a/files/fr/introduction_à_la_cryptographie_à_clef_publique/signatures_numériques/index.html b/files/fr/introduction_à_la_cryptographie_à_clef_publique/signatures_numériques/index.html new file mode 100644 index 0000000000..360b6340a9 --- /dev/null +++ b/files/fr/introduction_à_la_cryptographie_à_clef_publique/signatures_numériques/index.html @@ -0,0 +1,30 @@ +--- +title: Signatures numériques +slug: Introduction_à_la_cryptographie_à_clef_publique/Signatures_numériques +tags: + - Sécurité +--- +<p>Le chiffrement et le déchiffrement permettent de limiter le problème des écoutes clandestines, un des trois problèmes de sécurité sur Internet mentionné dans une précédente section de ce document. Mais ils ne permettent pas, à eux seuls, de contrer les deux autres problèmes mentionnés dans « <a href="fr/Introduction_%c3%a0_la_cryptographie_%c3%a0_clef_publique/Les_probl%c3%a8mes_de_s%c3%a9curit%c3%a9_sur_Internet">Les problèmes de sécurité sur Internet</a> » : l'altération des données et l'usurpation d'identité.</p> + +<p>Cette section décrit comment la cryptographie à clef publique peut combattre l'altération des données. Les sections suivantes décriront les solutions permettant de résoudre les problèmes d'usurpation.</p> + +<p>La détection de l'altération des données et les techniques d'authentification qui s'y rapportent sont basées sur une fonction mathématique appelée empreinte numérique à sens unique (également appelée <strong>a message digest</strong>). Une empreinte numérique à sens unique est un nombre de longueur fixe ayant les caractéristiques suivantes :</p> + +<ul> + <li>La valeur de l'empreinte numérique est unique pour les données<em>hachées</em>. Tout changement dans les données, même la modification ou l'altération d'un seul et unique caractère, produit une valeur différentes.</li> + <li>Le contenu des données hachées ne peut pas, pour les applications pratiques, être déduit depuis l'empreinte numérique - c'est pour cela que cette fonction est à « sens unique ».</li> +</ul> + +<p>Comme évoqué dans « <a href="fr/Introduction_%c3%a0_la_cryptographie_%c3%a0_clef_publique/Chiffrement_et_d%c3%a9chiffrement#Chiffrement_par_clef_publique">Chiffrement par clef publique</a> », il est possible d'utiliser votre clef privée pour le chiffrement et votre clef publique pour le déchiffrement. Bien que ce ne soit pas souhaitable lorsque vous chiffrez des informations sensibles, c'est une partie cruciale de la signature numérique de données. Plutôt que de chiffrer les données elles-mêmes, le logiciel de signature crée une empreinte numérique à « sens unique », puis utilise votre clef privée pour chiffrer cette empreinte. L'empreinte chiffrée, tout comme les autres informations, tel que l'algorithme de hachage, est connu sous le nom de signature numérique.</p> + +<p>Figure 3 montre une vue simplifiée de l'utilisation d'un signature numérique pour valider l'intégrité de données signées.</p> + +<p><img alt="Figure 3. Utilisation d'une signature numérique pour valider l'intégrité de données"></p> + +<p>Figure 3 montre que deux éléments sont transférés au destinataire des données signées : les données originales et la signature numérique, qui est simplement une empreinte numérique (des données originales) qui a été chiffrée avec la clef privée du signataire. Pour valider l'intégrité des données, le logiciel récepteur doit d'abord utiliser la clef publique du signataire pour décrypter l'empreinte numérique. Il utilise alors le même algorithme de hachage qui a généré l'empreinte numérique pour générer une nouvelle empreinte à « sens unique » des mêmes données. Bien que se ne soit pas indiqué sur la figure 3, les informations concernant l'algorithme de hachage sont également envoyées avec la signature numérique. Finalement, le logiciel de réception compare la nouvelle empreinte avec l'originale. Si les deux correspondent, les données n'ont pas changées depuis leur signature. Dans le cas contraire, elles ont été altérées, ou la signature a été créée avec une clef privée ne correspondant pas à la clef publique présentée par la signataire.</p> + +<p>Si les deux empreintes correspondent, le destinataire peut être certain que la clef publique utilisée pour déchiffrer la signature numérique correspond à la clef privée utilisée pour la création cette signature. Cependant, la confirmation de l'identité du signataire requiert également un moyen de confirmer que la clef publique appartient bien à une personne en particulier ou à une autre entité. Pour plus d'informations sur la façon dont cela fonctionne, voir la section suivante, « <a href="fr/Introduction_%c3%a0_la_cryptographie_%c3%a0_clef_publique/Certificats_et_authentification">Certificats et authentification</a> ».</p> + +<p>L'importance d'une signature numérique est comparable à celle d'une signature manuelle. Une fois les données signées, il vous est difficile après coup de prétendre le contraire - en supposant que le clef privée n'a pas été compromise ou qu'elle n'est pas sous le contrôle de son propriétaire. Cette qualité de la signature numérique fournit un haut degré de non-répudiation - ainsi, il est difficile au signataire de nier avoir signé les données. Dans certains cas, une signature numérique peut être l'équivalent légal d'une signature manuelle.</p> + +<p>{{PreviousNext("Introduction à la cryptographie à clef publique:Chiffrement et déchiffrement", "Introduction à la cryptographie à clef publique:Certificats et authentification")}}</p> |