Activités de recherche sur la configuration automatique - Revision history

Ltoutain at 07:06, 7 March 2011

2011-03-07T07:06:25Z

Ltoutain: /* Rappel sur les certificats */

2010-03-21T14:02:24Z

‎Rappel sur les certificats

Ltoutain: /* Rappel sur les certificats */

2010-03-21T13:56:41Z

‎Rappel sur les certificats

Ltoutain: /* Rappel sur les certificats */

2010-03-21T13:52:36Z

‎Rappel sur les certificats

Ltoutain: /* Rappel sur les certificats */

2010-03-21T13:33:11Z

‎Rappel sur les certificats

Ltoutain: /* SEND */

2010-03-20T03:45:27Z

‎SEND

Ltoutain at 03:26, 20 March 2010

2010-03-20T03:26:02Z

Ltoutain: New page: =SEND= =SAVI=

2009-09-26T06:00:01Z

New page: =SEND= =SAVI=

New page

=SEND=

=SAVI=

← Older revision		Revision as of 07:06, 7 March 2011
Line 1:		Line 1:
		+	{{Suivi\|Bonnes pratiques de la configuration automatique\|Bonnes pratiques de la configuration automatique\|Questionnaire sur la configuration automatique\|Questionnaire sur la configuration automatique}}
		+
		+
	La configuration automatique presente un certain nombre d'avantage, mais peut également conduire à une paralysie du réseau, si un équipement non autorisé répond aux Sollicitations de Routeurs (RS) émis par les équipements d'un lien. Ils vont soit créer une adresse qui n'est pas routage et si ils l'utilisent ne recevront jamais de réponse, soit prendre ce faux routeur comme routeur par défaut. Cette configuration résulte le plus souvent d'une erreur de configuration que d'une attaque. Elle n'est pas complètement nouvelle; en IPv4 le fait d'installer un faux serveur DHCP retournant des valeurs inexacte peut conduire au même résultat. Néanmoins, plusieurs techniques sont en cours de standardisation à l'IETF pour augmenter la sécurité sur le réseau. Le groupe SEND (SEcure Neighbor Discovery) a développer une solution cryptographique à base de certificats pour authentifier les deux équipements (celui qui fait la demande et le routeur qui y répond). Le groupe SAVI (Source Address Validation Improvement) travaille au niveau des équipements d'interconnexion (commutateurs) pour autoriser ou non certaines adresses.		La configuration automatique presente un certain nombre d'avantage, mais peut également conduire à une paralysie du réseau, si un équipement non autorisé répond aux Sollicitations de Routeurs (RS) émis par les équipements d'un lien. Ils vont soit créer une adresse qui n'est pas routage et si ils l'utilisent ne recevront jamais de réponse, soit prendre ce faux routeur comme routeur par défaut. Cette configuration résulte le plus souvent d'une erreur de configuration que d'une attaque. Elle n'est pas complètement nouvelle; en IPv4 le fait d'installer un faux serveur DHCP retournant des valeurs inexacte peut conduire au même résultat. Néanmoins, plusieurs techniques sont en cours de standardisation à l'IETF pour augmenter la sécurité sur le réseau. Le groupe SEND (SEcure Neighbor Discovery) a développer une solution cryptographique à base de certificats pour authentifier les deux équipements (celui qui fait la demande et le routeur qui y répond). Le groupe SAVI (Source Address Validation Improvement) travaille au niveau des équipements d'interconnexion (commutateurs) pour autoriser ou non certaines adresses.

Line 16:		Line 19:

	=SAVI=		=SAVI=
		+
		+	{{Suivi\|Bonnes pratiques de la configuration automatique\|Bonnes pratiques de la configuration automatique\|Questionnaire sur la configuration automatique\|Questionnaire sur la configuration automatique}}

@@ Line 9: / Line 9: @@
 En cryptographie, on différencie les clés symétriques qui sont connues des deux extrémités et qui servent aussi bien à chiffrer qu'à déchiffrer l'information, et les clés asymétriques, l'une des clés sert à coder l'information et l'autre à la décoder. Un équipement peut décider de garder la première secrète et de divulger la seconde. Ainsi tous les équipements la connaissant seront capable de déchiffrer le message, mais seul l'émetteur à la possibilité d'envoyer de tel message, car il est pratiquement impossible de découvrir la clé privée à partir de la clé publique. Il faut aussi que les possesseurs de la clé publique aient la garantie que celle-ci provient bien de l'émetteur, sinon une attaque Man in the Middle peut se produire. Un attaquant se faisant passer pour la source, utilise la clé publique de la source pour déchiffrer les messages et les rechiffre en utilisant ses propres clés. Pour éviter ce genre d'attaques, les autorités de certification (CA: Certification Authority) ont été définies.
-Elles possèdent des clés publiques connues du tous (par exemple préconfigurées dans les navigateurs). Quand une machine ou un site produit une clé publique, celle-ci va être signée par l'autorité de certification en utilisant sa clé privée (en fait, la signature consiste a faire à hash des données contenant la clé publique à authentifier puis à chiffrer le résultat). Une machine qui souhaite vérifier une clé publique, va effectuer la même opération. Elle va calculer le hash suivant le même algorithme et déchiffrer la signature en utilisant la clé publique de l'autorité de certification. Si les deux résultats coincident, la clé publique est authentifié par la CA. La chaîne de certification peut être plus complexe et hiérarchique et les certificats permettent de valider d'autres certificats.
+Elles possèdent des clés publiques connues du tous (par exemple préconfigurées dans les navigateurs). Quand une machine ou un site produit une clé publique, celle-ci va être signée par l'autorité de certification en utilisant sa clé privée (en fait, la signature consiste a faire à hash des données contenant la clé publique à authentifier puis à chiffrer le résultat). Une machine qui souhaite vérifier une clé publique, va effectuer la même opération. Elle va calculer le hash suivant le même algorithme et déchiffrer la signature en utilisant la clé publique de l'autorité de certification. Si les deux résultats coincident, la clé publique est authentifié par la CA. La chaîne de certification peut être plus complexe et hiérarchique et les certificats permettent de valider d'autres certificats.  La racine s'auto-signe c'est-à-dire utilise sa propre clé privée pour authentifier sa clé publique.
 A noter que contrairement à la création d'un certificat qui demande une communication avec le CA, la vérification d'un certificat peut se faire hors-ligne puisque la clé publique du CA est déjà préconfigurée dans l'équipement. De plus, le transport d'un certificat peut se faire de manière ouverte (sans chiffrement) puisque la signature protège contre tout risque de modification des données.

@@ Line 13: / Line 13: @@
 A noter que contrairement à la création d'un certificat qui demande une communication avec le CA, la vérification d'un certificat peut se faire hors-ligne puisque la clé publique du CA est déjà préconfigurée dans l'équipement. De plus, le transport d'un certificat peut se faire de manière ouverte (sans chiffrement) puisque la signature protège contre tout risque de modification des données.
-La norme X.509 définit le format des certificats
+La norme X.509 définit le format des certificats, le RFC 3280 décrit le profile adapté à l'Internet.
 =SAVI=

@@ Line 9: / Line 9: @@
 En cryptographie, on différencie les clés symétriques qui sont connues des deux extrémités et qui servent aussi bien à chiffrer qu'à déchiffrer l'information, et les clés asymétriques, l'une des clés sert à coder l'information et l'autre à la décoder. Un équipement peut décider de garder la première secrète et de divulger la seconde. Ainsi tous les équipements la connaissant seront capable de déchiffrer le message, mais seul l'émetteur à la possibilité d'envoyer de tel message, car il est pratiquement impossible de découvrir la clé privée à partir de la clé publique. Il faut aussi que les possesseurs de la clé publique aient la garantie que celle-ci provient bien de l'émetteur, sinon une attaque Man in the Middle peut se produire. Un attaquant se faisant passer pour la source, utilise la clé publique de la source pour déchiffrer les messages et les rechiffre en utilisant ses propres clés. Pour éviter ce genre d'attaques, les autorités de certification (CA: Certification Authority) ont été définies.
-Elles possèdent des clés publiques connues du tous (par exemple préconfigurées dans les navigateurs). Quand une machine ou un site produit une clé publique, celle-ci va être signée par l'autorité de certification en utilisant sa clé privée (en fait, la signature consiste a faire à hash des données contenant la clé publique à authentifier puis à chiffrer le résultat). Une machine qui souhaite vérifier une clé publique, va effectuer la même opération. Elle va calculer le hash suivant le même algorithme et déchiffrer la signature en utilisant la clé publique de l'autorité de certification. Si les deux résultats coincident, la clé publique est authentifié par la CA.
+Elles possèdent des clés publiques connues du tous (par exemple préconfigurées dans les navigateurs). Quand une machine ou un site produit une clé publique, celle-ci va être signée par l'autorité de certification en utilisant sa clé privée (en fait, la signature consiste a faire à hash des données contenant la clé publique à authentifier puis à chiffrer le résultat). Une machine qui souhaite vérifier une clé publique, va effectuer la même opération. Elle va calculer le hash suivant le même algorithme et déchiffrer la signature en utilisant la clé publique de l'autorité de certification. Si les deux résultats coincident, la clé publique est authentifié par la CA. La chaîne de certification peut être plus complexe et hiérarchique et les certificats permettent de valider d'autres certificats.
 =SAVI=

@@ Line 7: / Line 7: @@
 ==Rappel sur les certificats==
-En cryptographie, on différencie les clés symétriques qui sont connues des deux extrémités et qui servent aussi bien à chiffrer qu'à déchiffrer l'information, et les clés asymétriques, l'une des clés sert à coder l'information et l'autre à la décoder. Un équipement peut décider de garder la première secrète et de divulger la seconde. Ainsi tous les équipements la connaissant seront capable de déchiffrer le message, mais seul l'émetteur à la possibilité d'envoyer de tel message, car il est pratiquement impossible de découvrir la clé privée à partir de la clé publique.
+En cryptographie, on différencie les clés symétriques qui sont connues des deux extrémités et qui servent aussi bien à chiffrer qu'à déchiffrer l'information, et les clés asymétriques, l'une des clés sert à coder l'information et l'autre à la décoder. Un équipement peut décider de garder la première secrète et de divulger la seconde. Ainsi tous les équipements la connaissant seront capable de déchiffrer le message, mais seul l'émetteur à la possibilité d'envoyer de tel message, car il est pratiquement impossible de découvrir la clé privée à partir de la clé publique. Il faut aussi que les possesseurs de la clé publique aient la garantie que celle-ci provient bien de l'émetteur, sinon une attaque Man in the Middle peut se produire. Un attaquant se faisant passer pour la source, utilise la clé publique de la source pour déchiffrer les messages et les rechiffre en utilisant ses propres clés. Pour éviter ce genre d'attaques, les autorités de certification (CA: Certification Authority) ont été définies.
-Les certificats sont basés sur cette propriété. Un certificat peut être vu comme le chiffrement de la clé publique par la clé privée. De cette manière, un récepteur peut vérifier la véracité de la clé qu'il reçoit.
+Elles possèdent des clés publiques connues du tous (par exemple préconfigurées dans les navigateurs). Quand une machine ou un site produit une clé publique, celle-ci va être signée par l'autorité de certification en utilisant sa clé privée (en fait, la signature consiste a faire à hash des données contenant la clé publique à authentifier puis à chiffrer le résultat). Une machine qui souhaite vérifier une clé publique, va effectuer la même opération. Elle va calculer le hash suivant le même algorithme et déchiffrer la signature en utilisant la clé publique de l'autorité de certification. Si les deux résultats coincident, la clé publique est authentifié par la CA.
 =SAVI=

← Older revision		Revision as of 03:45, 20 March 2010
Line 2:		Line 2:

	=SEND=		=SEND=
		+
		+	Le protocole IPsec ne peut pas servir directement pour authentifier les communications avec un équipement qui est en train d'acquérir son adresse car il a besoin dans un premier temps de pouvoir récupérer les clés qui vont servir à l'échange. A moins de les préconfigurer, il faut un adresse IP pour cette acquisition. Le protocole SEND résout cet oxymore en se basant sur des certificats.
		+
		+	==Rappel sur les certificats==
		+
		+	En cryptographie, on différencie les clés symétriques qui sont connues des deux extrémités et qui servent aussi bien à chiffrer qu'à déchiffrer l'information, et les clés asymétriques, l'une des clés sert à coder l'information et l'autre à la décoder. Un équipement peut décider de garder la première secrète et de divulger la seconde. Ainsi tous les équipements la connaissant seront capable de déchiffrer le message, mais seul l'émetteur à la possibilité d'envoyer de tel message, car il est pratiquement impossible de découvrir la clé privée à partir de la clé publique.
		+
		+	Les certificats sont basés sur cette propriété. Un certificat peut être vu comme le chiffrement de la clé publique par la clé privée. De cette manière, un récepteur peut vérifier la véracité de la clé qu'il reçoit.

	=SAVI=		=SAVI=

← Older revision		Revision as of 03:26, 20 March 2010
Line 1:		Line 1:
		+	La configuration automatique presente un certain nombre d'avantage, mais peut également conduire à une paralysie du réseau, si un équipement non autorisé répond aux Sollicitations de Routeurs (RS) émis par les équipements d'un lien. Ils vont soit créer une adresse qui n'est pas routage et si ils l'utilisent ne recevront jamais de réponse, soit prendre ce faux routeur comme routeur par défaut. Cette configuration résulte le plus souvent d'une erreur de configuration que d'une attaque. Elle n'est pas complètement nouvelle; en IPv4 le fait d'installer un faux serveur DHCP retournant des valeurs inexacte peut conduire au même résultat. Néanmoins, plusieurs techniques sont en cours de standardisation à l'IETF pour augmenter la sécurité sur le réseau. Le groupe SEND (SEcure Neighbor Discovery) a développer une solution cryptographique à base de certificats pour authentifier les deux équipements (celui qui fait la demande et le routeur qui y répond). Le groupe SAVI (Source Address Validation Improvement) travaille au niveau des équipements d'interconnexion (commutateurs) pour autoriser ou non certaines adresses.
		+
	=SEND=		=SEND=

	=SAVI=		=SAVI=