VT2015 Factoring RSA - Revision history

Sebastien.Toussaint at 07:00, 12 October 2015

2015-10-12T07:00:23Z

← Older revision		Revision as of 07:00, 12 October 2015
Line 10:		Line 10:

	== Abstract ==		== Abstract ==

			The significant growth of transactions on the Internet in the early-mid 90s and early 2000s raised awareness among researchers to find and develop data security techniques on the internet. The September 21, 2000, the end RSA encryption patent previously held by the Massachusetts Institute of Technology (MIT), was a breakthrough in securing confidential data on the internet. This encryption system is the safest today. An article mad by Florian Weimer published Sept. 2, 2015 said it is possible to retrieve RSA private keys, especially if they were implemented using the Chinese remainder theorem. RSA encryption with forward secrecy TLS protocols are safe. But the implementation of these protocols can be badly performed and therefore be vulnerable to Lenstra attacks. To prevent this problem it is necessary to verify the implementation of these algorithms and ensure that it is not vulnerable to hardware problems.

	== Résumé ==		== Résumé ==

			La croissance importante des transactions effectuées sur internet dans le début-milieu des années 90 et début des années 2000 a sensibilisé les chercheurs à trouver et développer des techniques de sécurisation des données sur internet. Le 21 septembre 2000, la fin du brevet de chiffrement RSA détenu jusqu’alors par le Massachusetts Institute of Technology (MIT), fut une grande avancée dans la sécurisation des données confidentielles sur internet. Ce système de chiffrement est le plus sûr aujourd’hui. Un article de Florian Weimer paru le 2 septembre 2015 dit qu’il est possible de récupérer des clés privées de RSA, spécialement si elles ont été implémentées été implémenté à l’aide du théorème des restes chinois. Le chiffrement RSA avec la confidentialité persistante de TLS sont des protocoles sûrs. Mais l’implémentation de ces protocoles peut être mal effectuée et donc être vulnérable aux attaques de Lenstra. Pour prévenir ce problème il faut bien vérifier l’implémentation de ces algorithmes et faire en sorte qu’il ne soit pas vulnérable aux problèmes matériels.

	= Synthèse =		= Synthèse =

Sebastien.Toussaint at 08:16, 9 October 2015

2015-10-09T08:16:11Z

← Older revision		Revision as of 08:16, 9 October 2015
Line 8:		Line 8:
	== Mots Clés ==		== Mots Clés ==
	RSA, théorème des restes chinois, TLS, Perfect foward secrecy, confidentialité persitante, handshake, diffie-hellman.		RSA, théorème des restes chinois, TLS, Perfect foward secrecy, confidentialité persitante, handshake, diffie-hellman.

			== Abstract ==

			== Résumé ==

	= Synthèse =		= Synthèse =

Sebastien.Toussaint at 06:57, 9 October 2015

2015-10-09T06:57:59Z

← Older revision		Revision as of 06:57, 9 October 2015
Line 77:		Line 77:

	Cette fuite est visible pour le client qui réalise la poignée de mains TLS ou un observateur passif qui intercepte le trafic réseau" écrit Florian Weimer		Cette fuite est visible pour le client qui réalise la poignée de mains TLS ou un observateur passif qui intercepte le trafic réseau" écrit Florian Weimer

			Florian Weimer explique que "dans les cas de fuites de clés que nous avons observé, l'attaquant à distance ne peut pas organiser une fuite de clés à la demande étant donné qu'il n'est pas en mesure de manipuler le serveur du réseau d'une manière qui augmenterait la probabilité d'une fuite de réseau dans une poignées de main TLS. L'individu malintentionné peut uniquement intercepter un maximum de poignées de main, probablement en initialisant une multitude de poignées".

			=== A ne pas faire ===
			"La désactivation de la confidentialité persistante permettrait aux observateurs passifs qui auraient voler des clés, de déchiffrer les sessions TLS à venir dans le trafic réseau intercepté, sans devoir rediriger la connexion du client. Autrement, la désactivation de la confidentialité persistante ne contribue qu'à la détérioration de la situation. (la désactivation de la confidentialité persistance et le remplacement du certificat du serveur, quant à eux, fonctionnent)" écrit Florian Weimer.

Sebastien.Toussaint: /* Conclusion */

2015-10-09T06:54:48Z

Conclusion

← Older revision		Revision as of 06:54, 9 October 2015
Line 82:		Line 82:

	Pour résumer, le chiffrement RSA avec la confidentialité persistante de TLS sont des protocoles sûrs. Mais l’implémentation de ces protocoles peut être mal effectuée et donc être vulnérable aux attaques de Lenstra. Pour prévenir ce problème il faut bien vérifier l’implémentation de ces algorithmes et faire en sorte qu’il ne soit pas vulnérable aux problèmes matériels.		Pour résumer, le chiffrement RSA avec la confidentialité persistante de TLS sont des protocoles sûrs. Mais l’implémentation de ces protocoles peut être mal effectuée et donc être vulnérable aux attaques de Lenstra. Pour prévenir ce problème il faut bien vérifier l’implémentation de ces algorithmes et faire en sorte qu’il ne soit pas vulnérable aux problèmes matériels.

	Concernant les logiciels qui utilisent ces protocoles, ils ont été prévenus et ont mieux protégés leurs implémentations. Si vous voulez savoir si votre système est bien implémenté il est conseillé de contacter votre fournisseur d'outil d'outils de chiffrement pour en être certain.		Concernant les logiciels qui utilisent ces protocoles, ils ont été prévenus et ont mieux protégés leurs implémentations. Si vous voulez savoir si votre système est bien implémenté il est conseillé de contacter votre fournisseur d'outil d'outils de chiffrement pour en être certain.

Sebastien.Toussaint: /* Conclusion */

2015-10-09T06:53:49Z

Conclusion

← Older revision		Revision as of 06:53, 9 October 2015
Line 81:		Line 81:
	= Conclusion =		= Conclusion =

	Pour résumer, le chiffrement RSA avec la confidentialité persistante de TLS sont des protocoles sûrs. Mais l’implémentation de ces protocoles peut être mal effectuée et donc être vulnérable aux attaques de Lenstra. Pour prévenir ce problème il faut bien vérifier l’implémentation de ces algorithmes et faire en sorte qu’il ne soit pas vulnérable aux problèmes matériels.		Pour résumer, le chiffrement RSA avec la confidentialité persistante de TLS sont des protocoles sûrs. Mais l’implémentation de ces protocoles peut être mal effectuée et donc être vulnérable aux attaques de Lenstra. Pour prévenir ce problème il faut bien vérifier l’implémentation de ces algorithmes et faire en sorte qu’il ne soit pas vulnérable aux problèmes matériels.
			Concernant les logiciels qui utilisent ces protocoles, ils ont été prévenus et ont mieux protégés leurs implémentations. Si vous voulez savoir si votre système est bien implémenté il est conseillé de contacter votre fournisseur d'outil d'outils de chiffrement pour en être certain.

	= Notes et références =		= Notes et références =

Sebastien.Toussaint: /* Notes et références */

2015-10-09T06:46:43Z

Notes et références

← Older revision		Revision as of 06:46, 9 October 2015
Line 88:		Line 88:
	- http://blog.terraverdeservices.com/rsa-key-factoring-vulnerability-using-perfect-forward-secrecy		- http://blog.terraverdeservices.com/rsa-key-factoring-vulnerability-using-perfect-forward-secrecy
	- https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2015/september/factoring-rsa-keys-with-tls-perfect-forward-secrecy/		- https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2015/september/factoring-rsa-keys-with-tls-perfect-forward-secrecy/
			- https://simple.wikipedia.org/wiki/Diffie-Hellman_key_exchange
			- http://bibmath.net/crypto/index.php?action=affiche&quoi=complements/resteschinois

Sebastien.Toussaint: /* Notes et références */

2015-10-09T06:44:53Z

Notes et références

← Older revision		Revision as of 06:44, 9 October 2015
Line 85:		Line 85:
	= Notes et références =		= Notes et références =
	- https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/		- https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/

	- http://villemin.gerard.free.fr/Crypto/RSA.htm		- http://villemin.gerard.free.fr/Crypto/RSA.htm

	- http://blog.terraverdeservices.com/rsa-key-factoring-vulnerability-using-perfect-forward-secrecy		- http://blog.terraverdeservices.com/rsa-key-factoring-vulnerability-using-perfect-forward-secrecy

	- https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2015/september/factoring-rsa-keys-with-tls-perfect-forward-secrecy/		- https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2015/september/factoring-rsa-keys-with-tls-perfect-forward-secrecy/

Sebastien.Toussaint: /* Notes et références */

2015-10-09T06:44:20Z

Notes et références

← Older revision		Revision as of 06:44, 9 October 2015
Line 84:		Line 84:

	= Notes et références =		= Notes et références =
	- https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/		- https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/

	- http://villemin.gerard.free.fr/Crypto/RSA.htm		- http://villemin.gerard.free.fr/Crypto/RSA.htm

	- http://blog.terraverdeservices.com/rsa-key-factoring-vulnerability-using-perfect-forward-secrecy		- http://blog.terraverdeservices.com/rsa-key-factoring-vulnerability-using-perfect-forward-secrecy

	- https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2015/september/factoring-rsa-keys-with-tls-perfect-forward-secrecy/		- https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2015/september/factoring-rsa-keys-with-tls-perfect-forward-secrecy/

Sebastien.Toussaint at 06:43, 9 October 2015

2015-10-09T06:43:44Z

← Older revision		Revision as of 06:43, 9 October 2015
Line 84:		Line 84:

	= Notes et références =		= Notes et références =
			- https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/
	TO DO WHEN I HAVE INTERNET BECAUSE I'M USING MY PHONE RIGHT NOW AND THAT'S NOT GOOD AT ALL

			- http://villemin.gerard.free.fr/Crypto/RSA.htm

			- http://blog.terraverdeservices.com/rsa-key-factoring-vulnerability-using-perfect-forward-secrecy

			- https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2015/september/factoring-rsa-keys-with-tls-perfect-forward-secrecy/

Sebastien.Toussaint at 06:31, 9 October 2015

2015-10-09T06:31:04Z

← Older revision		Revision as of 06:31, 9 October 2015
Line 16:		Line 16:
	Le chiffrement RSA est un système de cryptographie asymétrique. Cela signifie qu’il y existe deux clés dans notre système. Une clé privée connue par une seule entité. Elle va lui permettre de déchiffrer les messages qui lui ont été envoyés. Une clé publique connue de tout le monde et qui va chiffrer le message que l’on souhaite envoyer. Ces clés sont produites par une seule entité.		Le chiffrement RSA est un système de cryptographie asymétrique. Cela signifie qu’il y existe deux clés dans notre système. Une clé privée connue par une seule entité. Elle va lui permettre de déchiffrer les messages qui lui ont été envoyés. Une clé publique connue de tout le monde et qui va chiffrer le message que l’on souhaite envoyer. Ces clés sont produites par une seule entité.

	[[File:rsa.png\|center\|thumb\|~~500px~~]]		[[File:rsa.png\|center\|thumb\|700px]]

	L’image ci-dessus représente une communication RSA entre deux utilisateurs, Alice et Bob. Les éléments en vert sur l’image représentent les informations en clair dans le canal de communication de ce protocole, donc tout le monde y a accès. Les éléments en rouge représentent les informations privées de chaque utilisateur. Donc du côté d’Alice ces informations permettent de créer sa clé privée. Tout d’abord Alice choisit deux nombres premiers distincts p et q puis elle fait leur produit afin d’obtenir le nombre n, ensuite l’indicateur de Euler ou fonction Phi de n f = (p-1) (q-1). Puis on calcul e premier avec f donc e = 5 et on calcule d, inverse de e modulo f. Donc pour chiffrer les messages nous avons y = x^e mod n. Et pour déchiffrer les messages nous avons z = y^d mod n.		L’image ci-dessus représente une communication RSA entre deux utilisateurs, Alice et Bob. Les éléments en vert sur l’image représentent les informations en clair dans le canal de communication de ce protocole, donc tout le monde y a accès. Les éléments en rouge représentent les informations privées de chaque utilisateur. Donc du côté d’Alice ces informations permettent de créer sa clé privée. Tout d’abord Alice choisit deux nombres premiers distincts p et q puis elle fait leur produit afin d’obtenir le nombre n, ensuite l’indicateur de Euler ou fonction Phi de n f = (p-1) (q-1). Puis on calcul e premier avec f donc e = 5 et on calcule d, inverse de e modulo f. Donc pour chiffrer les messages nous avons y = x^e mod n. Et pour déchiffrer les messages nous avons z = y^d mod n.
Line 23:		Line 23:
	Théorème : Prenons m1, ..., m n des entiers supérieurs à 2 deux à deux premiers entre eux, et a1,...,an des entiers. Le système d'équations :		Théorème : Prenons m1, ..., m n des entiers supérieurs à 2 deux à deux premiers entre eux, et a1,...,an des entiers. Le système d'équations :

	[[File:~~Example~~.~~jpg~~]]		[[File:trc.png\|center\|thumb\|500px]]

	admet une unique solution modulo M=m1×⋯×mn qui est donnée par la formule :		admet une unique solution modulo M=m1×⋯×mn qui est donnée par la formule :
Line 48:		Line 48:
	Diffie-Hellman est une méthode par laquelle deux personnes nommées conventionnellement Alice et Bob peuvent se mettre d'accord sur un nombre (qu'ils peuvent utiliser comme clé pour chiffrer la conversation suivante) sans qu'une troisième personne appelée Ève puisse découvrir le nombre, même en ayant écouté tous leurs échanges.		Diffie-Hellman est une méthode par laquelle deux personnes nommées conventionnellement Alice et Bob peuvent se mettre d'accord sur un nombre (qu'ils peuvent utiliser comme clé pour chiffrer la conversation suivante) sans qu'une troisième personne appelée Ève puisse découvrir le nombre, même en ayant écouté tous leurs échanges.

	[[File:~~Example~~.~~jpg~~]]		[[File:d-f.png\|center\|thumb\|500px]]


Line 72:		Line 72:
	Et là nous savons que q divise w_p et que q divise aussi n. Alors que p ne divise plus Y^e – x. Il nous reste plus qu’à faire le PGCD de n et Y^e – x pour trouver q.		Et là nous savons que q divise w_p et que q divise aussi n. Alors que p ne divise plus Y^e – x. Il nous reste plus qu’à faire le PGCD de n et Y^e – x pour trouver q.

	[[File:~~Example~~.~~jpg~~]]		[[File:tls.png\|center\|thumb\|700px]]

	D’un point de vue réseau il s’agit d’une trame en plus que fournit le serveur au client durant le handshake TLS. Dans cette trame il y a la clé publique du serveur. Cette trame ne dit pas quel algorithme a été utilisé pour faire l’échange de clé; et ceci peut conduire à une longue série d’attaque. Selon le rapport de Florian Weimer il existe un seul moyen de prévenir cette erreur, il faut vérifier que la signature ait été bien faite.		D’un point de vue réseau il s’agit d’une trame en plus que fournit le serveur au client durant le handshake TLS. Dans cette trame il y a la clé publique du serveur. Cette trame ne dit pas quel algorithme a été utilisé pour faire l’échange de clé; et ceci peut conduire à une longue série d’attaque. Selon le rapport de Florian Weimer il existe un seul moyen de prévenir cette erreur, il faut vérifier que la signature ait été bien faite.