Au lieu d'utiliser le classique "login"et mot de passe, certains sites Internet utilisent un certificat numérique pour authentifier leurs utilisateurs. Avec un tel système, l'utilisateur utilise une clé qui lui a été préalablement été envoyée par la société en charge du site Internet.
Pour de nombreuses personnes, ce type d'authentification c'est le "nec plus ultra" et elles sont très fières d'en parler. Quand je leur explique que ce n'est pas la panacée et leur en explique les raisons, les dents commencent à grincer.
Vous avez déclaré vos impôts en ligne ?
Si la la réponse est positive, alors vous avez déjà utilisé ce système permettant d'authentifier de façon extrêmement fiable la personne qui déclare. Il faut avouer que la mise en place initiale n'est pas toujours très simple mais a le mérite de fonctionner.
Pour fonctionner, ce fameux sésame s'appuie sur des principes dit de "cryptographie asymétrique", on parle aussi de "chiffrement asymétrique" bien que ce terme soit un peu réducteur.
Cryptographie asymétrique
Ce système, s'appuie sur des mécanismes de chiffrement dans lequel sont utilisées des clés ayant des propriétés spéciales entre-elles. Un tel jeu de clés est constitué de 2 clés associées : l'une est privée, l'autre est publique. En simplifiant à peine, ce que peut faire l'une, l'autre peut le défaire. Un jeu de clé (clé privée + clef publique) est aussi connu sous le nom de biclef.
Clé publique et clé privée.
Un message chiffré avec la clé publique ne pourra être déchiffré qu'avec la clé privée correspondante. Simple non ?
Pour la signature, c'est l'inverse : Pour signer numériquement un message, on utilise la clé privée en guise de "tampon". Pour vérifier l'authenticité du "tampon" on utilise la clé publique correspondante.
Nous reviendrons sur cela prochainement.
Authentification d'un site web via certificat
Quand l'on se connecte à site web sécurisé (compte bancaires, page de paiement d'un site de "e-commerce", le site web est authentifié par le biais de la clé publique qui nous est envoyée lors de l'établissement de la connexion. Avant d'utiliser cette clé, on vérifie si c'est bien celle du site auquel l'on est en train de se connecter : Ça c'est le rôle du certificat.
Dans ce cas de figure, le site Internet démontre qu'il possède bien la clé privée correspondant à celle présente dans le certificat via un principe de signature numérique. Le navigateur envoie un message au site web, celui le signe avec sa clé privé et renvoie le résultat. Le navigateur vérifie la signature avec la clé publique contenue dans le certificat.
Si tout est OK, alors la connexion chiffrée est établie.
Authentification d'un utilisateur via certificat
Si vous avez suivi mes explications ci-dessus, et bien c'est la même chose mais à l'envers !
Le site web envoie un message au navigateur, celui-ci le signe avec la clé privée et renvoie le résultat au site web. Ensuite, le site web vérifie la signature avec la clé publique correspondante.
Si tout est OK, alors l'utilisateur a le droit de se connecter.
Mais c'est blindé cette histoire ? bof... enfin ça dépend !
A première vue, cela semble super sécurisé cette histoire.... Il suffit d'y rajouter des gros mots comme RSA 2048 bits, SSL, TLS et autres trucs que les managers comprennent que dale (enfin 90%) et vous emballez qui vous voulez.... circulez, c'est sécurisé !
Et bien non.... Quelle est la faille me direz-vous ? Et bien elle réside dans le stockage de la clé privée sur le PC de l'utilisateur.
PKCS#12
Afin de stocker en local sur une machine un conteneur spécial est utilisé : la clé privée et sa clé publique correspondante sont écrites dans une archive au PKCS#12. Autrement dit, vous allez retrouver un fichier pour chaque jeu de clés.
Ces clés sont chiffrées via un algorithme comme 3DES (Triple DES). Pour accéder aux clés (et donc les utiliser) il faut montrer patte blanche... en donnant un mot de passe !
Qui connait le mot de passe peut donc utiliser les clés, et même dans certains cas les extraire.
Méthodes pour voler les clés
Il existe trois grandes méthodes pour voler des clés stockées dans une archive PKCS#12.
Attaque #1: Récupération du fichier PKCS#12
L'attaquant fait une copie du fichier PKCS#12 et l'envoie sur le serveur de son choix. Ensuite, il a tout le temps qu'il faut pour deviner le mot de passe via essai successifs. Simple, efficace et très rapide et très discret.
Attaque #2: Bruteforce en local sur le poste
C'est une variante de la méthode précédente dans laquelle l'attaquant va tenter sa chance directement sur la machine. Cela va surement générer une charge CPU plus élevée que d'habitude. Si cela est fait sans trop surcharger la machine, alors peu de chances qu'un utilisateur lambda se rendre compte de quelque chose.
Attaque #2: Sniffing du mot de passe via keylogger
Cette méthode est la plus évoluée. Une fois le fichier PKCS#12 envoyé sur un serveur de son choix, l'attaquant va capturer toutes les données saisies au niveau du navigateur et va les envoyer elles aussi vers son serveur. Il lui suffira de "forcer" (ou d'attendre que) l'utilisateur se connecte au site web concerné.
Conséquences d'un vol de clés privées
Une fois dérobées, ces clés privées peuvent être utilisées de différentes manières. Nous ne retiendrons que les deux les plus évidentes.
Usurpation d'identité
C'est le classique : Avec la clé privée, l'attaquant est en mesure de se connecter aux sites web et de faire ce qu'il souhaite... simple et efficace.
Signature de code malicieux
Dans le cas ou les clés dérobées sont des clés utilisées pour signer numériquement du code (afin d'en certifier la provenance et l'intégrité), l'attaquant pourra signer ses programmes malicieux et ainsi passer au travers de mécanismes de protection présumés forts. C'est un tel détournement qui a été utilisé par le ver Stuxnet qui ciblait les systèmes de contrôle industriel.
Les malwares évolués
Il y a quelques jours de cela, Symantec a mis à nu le cheval de Troie "Infostealer.Nimkey" utilisant ce type de technique (collecte des fichiers PKCS#12 et capture des saisies via sniffing).
Trois recommandations
Conseil #1 : Utilisez des mots de passe "forts" pour protéger vos fichiers PCKS#12. Si vous êtes en mal d'idée pour gérer vos mots de passe, je vous conseille cet article "2 recettes simples pour gérer ses mots de passe".
Conseil #2 : Stocker vos fichiers PKCS#12 dans des clés cryptographiques matérielles : Avec celles-ci, il n'est plus possible de récupérer/copier le fichier et à la 3ième tentative infructueuse de mot de passe elles se verrouillent.
Conseil #3 : N'utilisez pas de certificats clients : Faites de l'OTP (One-Time Password). Suivez les traces du géant Google ("Google se lance dans l'authentification forte") en mettant en place un système basé sur OATH.
Pour de nombreuses personnes, ce type d'authentification c'est le "nec plus ultra" et elles sont très fières d'en parler. Quand je leur explique que ce n'est pas la panacée et leur en explique les raisons, les dents commencent à grincer.
Vous avez déclaré vos impôts en ligne ?
Si la la réponse est positive, alors vous avez déjà utilisé ce système permettant d'authentifier de façon extrêmement fiable la personne qui déclare. Il faut avouer que la mise en place initiale n'est pas toujours très simple mais a le mérite de fonctionner.
Pour fonctionner, ce fameux sésame s'appuie sur des principes dit de "cryptographie asymétrique", on parle aussi de "chiffrement asymétrique" bien que ce terme soit un peu réducteur.
Cryptographie asymétrique
Ce système, s'appuie sur des mécanismes de chiffrement dans lequel sont utilisées des clés ayant des propriétés spéciales entre-elles. Un tel jeu de clés est constitué de 2 clés associées : l'une est privée, l'autre est publique. En simplifiant à peine, ce que peut faire l'une, l'autre peut le défaire. Un jeu de clé (clé privée + clef publique) est aussi connu sous le nom de biclef.
Clé publique et clé privée.
Un message chiffré avec la clé publique ne pourra être déchiffré qu'avec la clé privée correspondante. Simple non ?
Pour la signature, c'est l'inverse : Pour signer numériquement un message, on utilise la clé privée en guise de "tampon". Pour vérifier l'authenticité du "tampon" on utilise la clé publique correspondante.
Nous reviendrons sur cela prochainement.
Authentification d'un site web via certificat
Quand l'on se connecte à site web sécurisé (compte bancaires, page de paiement d'un site de "e-commerce", le site web est authentifié par le biais de la clé publique qui nous est envoyée lors de l'établissement de la connexion. Avant d'utiliser cette clé, on vérifie si c'est bien celle du site auquel l'on est en train de se connecter : Ça c'est le rôle du certificat.
Dans ce cas de figure, le site Internet démontre qu'il possède bien la clé privée correspondant à celle présente dans le certificat via un principe de signature numérique. Le navigateur envoie un message au site web, celui le signe avec sa clé privé et renvoie le résultat. Le navigateur vérifie la signature avec la clé publique contenue dans le certificat.
Si tout est OK, alors la connexion chiffrée est établie.
Authentification d'un utilisateur via certificat
Si vous avez suivi mes explications ci-dessus, et bien c'est la même chose mais à l'envers !
Le site web envoie un message au navigateur, celui-ci le signe avec la clé privée et renvoie le résultat au site web. Ensuite, le site web vérifie la signature avec la clé publique correspondante.
Si tout est OK, alors l'utilisateur a le droit de se connecter.
Mais c'est blindé cette histoire ? bof... enfin ça dépend !
A première vue, cela semble super sécurisé cette histoire.... Il suffit d'y rajouter des gros mots comme RSA 2048 bits, SSL, TLS et autres trucs que les managers comprennent que dale (enfin 90%) et vous emballez qui vous voulez.... circulez, c'est sécurisé !
Et bien non.... Quelle est la faille me direz-vous ? Et bien elle réside dans le stockage de la clé privée sur le PC de l'utilisateur.
PKCS#12
Afin de stocker en local sur une machine un conteneur spécial est utilisé : la clé privée et sa clé publique correspondante sont écrites dans une archive au PKCS#12. Autrement dit, vous allez retrouver un fichier pour chaque jeu de clés.
Ces clés sont chiffrées via un algorithme comme 3DES (Triple DES). Pour accéder aux clés (et donc les utiliser) il faut montrer patte blanche... en donnant un mot de passe !
Qui connait le mot de passe peut donc utiliser les clés, et même dans certains cas les extraire.
Méthodes pour voler les clés
Il existe trois grandes méthodes pour voler des clés stockées dans une archive PKCS#12.
Attaque #1: Récupération du fichier PKCS#12
L'attaquant fait une copie du fichier PKCS#12 et l'envoie sur le serveur de son choix. Ensuite, il a tout le temps qu'il faut pour deviner le mot de passe via essai successifs. Simple, efficace et très rapide et très discret.
Attaque #2: Bruteforce en local sur le poste
C'est une variante de la méthode précédente dans laquelle l'attaquant va tenter sa chance directement sur la machine. Cela va surement générer une charge CPU plus élevée que d'habitude. Si cela est fait sans trop surcharger la machine, alors peu de chances qu'un utilisateur lambda se rendre compte de quelque chose.
Attaque #2: Sniffing du mot de passe via keylogger
Cette méthode est la plus évoluée. Une fois le fichier PKCS#12 envoyé sur un serveur de son choix, l'attaquant va capturer toutes les données saisies au niveau du navigateur et va les envoyer elles aussi vers son serveur. Il lui suffira de "forcer" (ou d'attendre que) l'utilisateur se connecte au site web concerné.
Conséquences d'un vol de clés privées
Une fois dérobées, ces clés privées peuvent être utilisées de différentes manières. Nous ne retiendrons que les deux les plus évidentes.
Usurpation d'identité
C'est le classique : Avec la clé privée, l'attaquant est en mesure de se connecter aux sites web et de faire ce qu'il souhaite... simple et efficace.
Signature de code malicieux
Dans le cas ou les clés dérobées sont des clés utilisées pour signer numériquement du code (afin d'en certifier la provenance et l'intégrité), l'attaquant pourra signer ses programmes malicieux et ainsi passer au travers de mécanismes de protection présumés forts. C'est un tel détournement qui a été utilisé par le ver Stuxnet qui ciblait les systèmes de contrôle industriel.
Les malwares évolués
Il y a quelques jours de cela, Symantec a mis à nu le cheval de Troie "Infostealer.Nimkey" utilisant ce type de technique (collecte des fichiers PKCS#12 et capture des saisies via sniffing).
Trois recommandations
Conseil #1 : Utilisez des mots de passe "forts" pour protéger vos fichiers PCKS#12. Si vous êtes en mal d'idée pour gérer vos mots de passe, je vous conseille cet article "2 recettes simples pour gérer ses mots de passe".
Conseil #2 : Stocker vos fichiers PKCS#12 dans des clés cryptographiques matérielles : Avec celles-ci, il n'est plus possible de récupérer/copier le fichier et à la 3ième tentative infructueuse de mot de passe elles se verrouillent.
Conseil #3 : N'utilisez pas de certificats clients : Faites de l'OTP (One-Time Password). Suivez les traces du géant Google ("Google se lance dans l'authentification forte") en mettant en place un système basé sur OATH.
Au sein de la direction sécurité du Groupe Orange, je suis en charge de la veille sécurité et de la sensibilisation à la sécurité. Franchise, optimisme et bonne-humeur sont mes moteurs quotidiens