427 lines
19 KiB
Markdown
427 lines
19 KiB
Markdown
---
|
|
title: Authentification par smartcard et PKI
|
|
documentclass: scrartcl
|
|
author:
|
|
- Luc Lauriou
|
|
- Yorick Barbanneau
|
|
fontsize: 13pt
|
|
mainfont: DejaVu Serif
|
|
geometry: [top=1.5cm, bottom=3cm, left=3cm, right=3cm]
|
|
header-includes:
|
|
- \definecolor{liens}{HTML}{de6a66}
|
|
urlcolor: liens
|
|
linkstyle: bold
|
|
...
|
|
|
|
## Introduction
|
|
|
|
Depuis toujours, l'authentification sur des systèmes informatiques est
|
|
principalement régie par l'utilisation du couple identifiant / mot de passe.
|
|
C'est pourtant un facteur d'identification peu fiable : utilisation du même mot
|
|
de passe pour plusieurs - voir tous les - services, mot de passe faible, progrès
|
|
technique rendant leur cassage plus efficace etc. Dans un communiqué de presse
|
|
du W3C et de l'Alliance FIDO, "les mots de passe volés, faibles ou par défaut
|
|
sont à l'origine de 81% des atteintes à la protection des données".
|
|
|
|
> Les mots de passe volés, faibles ou par défaut
|
|
> sont à l'origine de 81% des atteintes à la protection des données.
|
|
|
|
Il existe des solutions pour pallier ces faiblesses, avec notamment
|
|
l'introduction d'un ou plusieurs autres facteurs d'authentification (TOTP, SMS
|
|
etc.) ou les gestionnaires de mots de passe (keepass, LastPass, etc ...).
|
|
|
|
L'authentification par certificats semble être une alternative intéressante aux
|
|
traditionnels mots de passe. Nous allons dans ce mémoire parler de la norme
|
|
X.509, des infrastructures à clefs publiques, des smartcards et des attaques
|
|
connues.
|
|
|
|
## La norme X.509
|
|
|
|
La norme X.509 régie les formats pour les certificats à clés
|
|
publiques. Elle est définie par l'Union Internationale des Télécommunications et
|
|
établie comme suit :
|
|
|
|
- Le **format de certificat**
|
|
- La **liste de révocation** des certificats
|
|
- leurs **attributs**
|
|
- un **algorithme de validation de chemin des certificats**
|
|
|
|
Contrairement à OpenPGP qui repose sur une toile de confiance, X.509 repose sur
|
|
les autorités de certifications : un tiers de confiance délivre les certificats
|
|
et fournit les moyens de les vérifier.
|
|
|
|
Les certificats X.509 sont donc composé de deux éléments : une partie publique
|
|
et une partie privée. Ces certificats peuvent assurer plusieurs rôles.
|
|
|
|
En voici quelques uns :
|
|
|
|
### PKI - Infrastructure à clefs publiques
|
|
|
|
Une infrastructure à clefs publiques est un ensemble d'éléments, qu'ils soient
|
|
humains, matériels ou logiciels, destinés à gérer les clefs publiques des
|
|
utilisateurs d'un système.
|
|
|
|
Cette infrastructure est utilisée pour créer, gérer, distribuer et révoquer des
|
|
certificats.
|
|
|
|
#### La PKI elle va te crypter l'Internet du digital
|
|
|
|
Sur Internet, les différentes autorités de certifications assurent les rôles de
|
|
PKI : Elle fournissent l'infrastructure pour gérer les certificats permettant
|
|
le fonctionnement du chiffrement TLS.
|
|
|
|
## Une SmartCard?
|
|
|
|
Maintenant que nous avons parlé de la norme X.509, nous allons parler de notre
|
|
**startcard**. D'après Wikipédia ([source](l_sc-wiki)) :
|
|
|
|
> Une carte à puce est une carte en matière plastique, voire en papier ou en
|
|
> carton, de quelques centimètres de côté et moins d'un millimètre d'épaisseur,
|
|
> portant au moins un circuit intégré capable de contenir de l'information. Le
|
|
> circuit intégré (la puce) peut contenir un microprocesseur capable de traiter
|
|
> cette information, ou être limité à des circuits de mémoire non volatile et,
|
|
> éventuellement, un composant de sécurité (carte mémoire).
|
|
|
|
Vous utilisez tous les jours une SmartCard : votre carte SIM, votre carte
|
|
bancaire...
|
|
|
|
Les smartcards qui nous intéressent ici contiennent un espace de stockage, un
|
|
microprocesseur et un coprocesseur pour accélérer les opérations
|
|
cryptographiques.
|
|
|
|

|
|
|
|
Comme vous pouvez le voir, il n'y a pas de connexion directe entre les contacts
|
|
et la mémoire. Pour des raisons évidente de sécurité, tout passe par le système
|
|
d'exploitation de la carte. Il en existe une multitude (JavaCard Operating
|
|
System, MULTOS, OpenPGP Card, Gnuk etc.)
|
|
|
|
### Création, stockage et utilisation de certificats
|
|
|
|
Dans le cas qui nous intéresse, la carte à puce permet de stocker le certificat
|
|
et de l'utiliser. Lors de son utilisation, un code PIN sera demandé, le
|
|
certificat contenu pourra alors être utilisé pour s'authentifier, signer ou
|
|
chiffrer.
|
|
|
|
Certaines smartcards permettent la génération de certificats.
|
|
|
|
### Les "normes" PKCS
|
|
|
|
PKCS pour *Public Key Cryptographics Standard* est un ensemble de spécifications
|
|
portées au départ par la Société *RSA Security* afin d'implanter les techniques
|
|
liées à la cryptographie par clé publique. Par la suite, beaucoup de ces
|
|
spécifications sont devenues des standard par le biais de RFC écrites par le
|
|
groupe de travail PKIX[^n_pkix] de l'IETF.
|
|
|
|
Les plus utiles ici sont :
|
|
|
|
- **PKCS#7** : standard de syntaxe de message cryptographiques, normalisé par
|
|
les RFC 2315 et 5653.
|
|
- **PKCS#11** : API définissant une interface générique pour les périphériques
|
|
cryptographiques.
|
|
|
|
[^n_pkix]:Public Key Infrastructure X.509, groupe de travail de l'IETF dédié aux
|
|
infrastructures à clé publiques
|
|
|
|
### Le Web plus accessible aux authentifications par certificats
|
|
|
|
Aujourd'hui, l'un des principaux défauts de l'authentification par certificats,
|
|
c'est qu'elle n'est pas déployée largement : seul un petit nombre de services
|
|
l'utilisent.
|
|
|
|
Cependant, supporté par le constat que les mots de passe perdent en efficacité,
|
|
le standard WebAuthn - pour *Web Authentication* - a récemment été créé et
|
|
publiée par le W3C. Ce standard définit une API destinée aux navigateurs, aux
|
|
applications web et aux autres plateformes nécessitant une authentification
|
|
forte basée sur clés publiques.
|
|
|
|
Les grands du Web ont déjà mis en place le support de WebAuthn sur
|
|
leurs outils : Windows 10, Android, Google Chrome, Mozilla Firefox,
|
|
Microsoft Edge et Safari. L'apparition de ce standard va sans aucun doute
|
|
encourager une adoption plus large de ce type d'authentification.
|
|
|
|
## Attaque sur les smartcard
|
|
|
|
### Attaques par canal auxiliaire
|
|
|
|
Les attaques par canal auxiliaire regroupent les attaques qui tentent d'exploiter
|
|
des failles sur l'implémentation des procédures de sécurité plutôt que sur les
|
|
procédures elles-mêmes. Voici une liste de types d'attaques par canal
|
|
auxiliaire sur lesquels on va s'attarder car elles touchent les smartcards :
|
|
|
|
#### Attaque par sondage
|
|
|
|
Particulièrement invasive, elle consiste à détériorer suffisamment une puce pour
|
|
avoir un accès physique aux bus et y lire les bits qui y passent. Il est à noter
|
|
que cette attaque est très difficile à mettre en place car elle nécessite du
|
|
matériel de pointe (oscilloscope très précis,
|
|
chronométrage du passage des bits...), de la rigueur et de la précision sur la
|
|
détérioration de la puce, etc.
|
|
|
|
#### Analyse de consommation
|
|
|
|
En fonction des opérations résolues par un processeur, sa consommation en
|
|
énergie diffère. En étudiant les variations d'énergie utilisées par un lecteur de
|
|
cartes, il est possible de trouver des indices sur la clé privée, sur un
|
|
échantillon suffisant. Aujourd'hui, cette attaque peut être aisément
|
|
contrecarrée en apposant du bruit sur le circuit ou en le blindant.
|
|
|
|
#### Analyse d'émanations électromagnétiques
|
|
|
|
Semblable à l'Analyse de consommation, à ceci prêt qu'on ne s'attache pas, cette
|
|
fois ci à l'énergie consommée mais au rayonnement électromagnétique émis par un
|
|
appareil. A l'instar de la consommation en énergie, le rayonnement n'est pas
|
|
le même en fonction des opérations exécutées par le terminal. L'étude du
|
|
rayonnement thermique peut s'apparenter à une analyse d'émanations
|
|
électromagnétiques.
|
|
|
|
#### Attaque par faute
|
|
|
|
Le principe ici est de provoquer des erreurs pour que le système réagisse de
|
|
manière inhabituelle sur les opérations de chiffrement et laisse des indices
|
|
sur la clé de chiffrement.
|
|
|
|
#### Attaque temporelle
|
|
|
|
Le temps que met un algorithme à s'exécuter donne parfois des indices sur la
|
|
constitution d'une clé entrée en paramètre dans cet algorithme, comme le nombre
|
|
de bits à 1. A elle seule, cette attaque ne donne pas beaucoup d'informations,
|
|
mais elle peut être combinée avec d'autres attaques pour en augmenter son
|
|
efficacité.
|
|
|
|
### Attaques sur les PKI
|
|
|
|
Même si elle ne touchent pas directement les smartcards, Il est intéressant de
|
|
parler des attaques sur les infrastructures à clé publique.
|
|
|
|
#### Collision MD5
|
|
|
|
Le MD5 pour *Message Digest 5* est un algorithme de hachage cryptographique
|
|
permettant d'obtenir l'empreinte d'un fichier / d'une chaine de caractères. Elle
|
|
a été inventée par **Ronald Rivets** en 1991 pour succéder à MD4.
|
|
|
|
Il doit être considéré comme obsolète depuis 1996, année de découverte d'une
|
|
faille dans l'algorithme ouvrant la voie à des collisions. En 2004 une équipe de
|
|
chercheurs chinois menée par la mathématicienne Wang Xiaoyun [démontre la
|
|
faisabilité][l_md5_2005] d'une collision complète. Mais cette attaque n'est pas
|
|
encore suffisamment sophistiquée pour être utilisée sur un cas concret. Wang,
|
|
Lenstra et de Wegner feront la [démonstration de leur attaque][l_md5_2006] sur
|
|
deux certificats X.509 différents ayant la même signature MD5 en 2006.
|
|
|
|
[l_md5_2005]:https://eprint.iacr.org/2004/199.pdf
|
|
[l_md5_2006]:https://www.win.tue.nl/~bdeweger/CollidingCertificates/
|
|
|
|
##### Attaque par collision
|
|
|
|
Une attaque par collision est menée sur une fonction de hashage cryptographique
|
|
afin trouver **deux entrées différentes donnant lieux au même résultat**. Comme
|
|
la plupart des fonctions de signature électronique se font sur le *condensat*
|
|
d'un document plutôt que sur le document lui-même. Ainsi s'il est possible de
|
|
produire deux documents avec le même *condensat*[^n_hash], leurs signatures
|
|
seront strictement identiques. Il suffit alors d'envoyer à l'autorité de
|
|
certification le document légitime et **copier la signature obtenue sur le
|
|
document frauduleux**.
|
|
|
|
[^n_hash]:Le mot français pour *hash*
|
|
|
|
##### Attaque par collision avec préfixe choisi
|
|
|
|
Dans le cadre de certificats, les choses se compliquent un peu : c'est
|
|
**l'autorité de certification qui génère le certificat** en fonction des
|
|
informations contenues dans le CSR. L'attaquant doit alors manipuler les données
|
|
contenues dans le CSR qu'il envoie et y intégrer des blocs de collision pour
|
|
annuler les différences entre les hashes du certificat obtenu et celui forgé.
|
|
Il va jouer sur le préfixe du CSR, d'où le nom de l'attaque.
|
|
|
|
Ce type d'attaque n'est cependant pas aisé, l'attaquant devra anticiper
|
|
certaines informations qui seront intégrées dans le certificat produit par
|
|
l'autorité. Certaines pourront être influencées comme le champ CN, d'autres
|
|
récupérées sur d'autres certificats signés par la même autorité (le contenu des
|
|
champs *issuer* par exemple) et enfin d'autres devront être
|
|
"devinées" [^n_devinees] - numéro de série du certificat et date d'expiration -
|
|
|
|
[Une telle attaque a été démontrée][l_md5_2008] en décembre 2008 par une équipe
|
|
de chercheurs menée par Sotirov et Stevens. Ils ont ainsi pu obtenir un
|
|
certificat à même de signer n'importe quels autres certificats et reconnu par les
|
|
principaux navigateurs de l'époque.
|
|
|
|
Une technique similaire a été utilisée par le malware *Flame* découvert en 2012.
|
|
Il usurpait une signature de code Microsoft pour se propager au travers de
|
|
Windows Update.
|
|
|
|
[l_md5_2008]:https://www.win.tue.nl/hashclash/rogue-ca/
|
|
|
|
[^n_devinees]:Prédites serait plus adapté, dans l'attaque menée par Sotirov et
|
|
Stevens, l'équipe de chercheurs a réussi à prédire ces deux éléments en étudiant le
|
|
fonctionnement de l'autorité de certification utilisée.
|
|
|
|
### Attaque par oracle de padding
|
|
|
|
Ce type d'attaque a été mené avec succès sur différents périphériques
|
|
cryptographiques par une équipe de recherche internationale. Leurs travaux a
|
|
donné lieu à une publication en avril 2012.
|
|
|
|
Ils on ainsi pu extraire les clefs privées de la plupart des périphériques
|
|
disponibles sur le marché quels que soient leurs marques.
|
|
|
|
La première démonstration pratique de cette attaque a été faite par Daniel
|
|
Bleichenbacher alors chercheur en cryptographie chez *Bell Laboratories*
|
|
|
|
#### Comment fonctionne t-elle?
|
|
|
|
##### Le chiffrement par bloc
|
|
|
|
Avant de rentrer plus en détails dans le fonctionnement de l'attaque par oracle
|
|
de padding, il est nécessaire d'expliquer le fonctionnement du chiffrement par
|
|
bloc. Il existe une multitude de chiffrement par bloc, nous resterons sur le
|
|
mode CBC *Cipher Block Chaining*.
|
|
|
|

|
|
|
|
Pour éviter l'apparition de motifs dans le bloc chiffré qui pourrait faciliter
|
|
la création de "dictionnaire de code", le mode *CBC* utilise le précédent bloc
|
|
chiffré pour réaliser une opération booléenne avec le bloc actuel en clair avant
|
|
de le chiffrer. Pour le premier bloc à envoyer, *CBC* utilise un vecteur
|
|
d'initialisation.
|
|
|
|
Contrairement au chiffrement de flux, le chiffrement par bloc nécessite une
|
|
taille de donnée définie en entrée. Si les données sont trop importantes, il
|
|
faut les découper, si elle sont plus petites on utilisera alors la technique du
|
|
padding.
|
|
|
|
$$
|
|
cleartext[n] = decrypt(cblock[n]) \oplus cblock[n-1]
|
|
$$
|
|
|
|
##### Le padding
|
|
|
|

|
|
|
|
Dans notre exemple, notre bloc doit faire 128 bits mais les données ne
|
|
représente que 104 bits [1]. Nous allons donc rajouter trois octets avec pour
|
|
valeur hexadécimale `0x03` qui représente le nombre d'octets manquant [2].
|
|
|
|
##### L'attaque par oracle de padding
|
|
|
|
Une **oracle de padding** est un mechanisme prenant un bloc chiffré en entrée,
|
|
le déchiffre et avertit l'utilisateur si le padding est correct ou non.
|
|
|
|
Le chiffrement par bloc en mode *CBC* a un énorme défaut : l'intégrité des
|
|
messages n'est pas vérifiée. Du coup un attaquant peut modifier le résultat
|
|
de `cleartext[n]` en modifiant `cblock[n-1]`, ou tout simplement en le
|
|
forgeant à notre convenance.
|
|
|
|
Prenons `X` comme bloc de chiffrement forgé pour l'occasion, et `cblock[n]`
|
|
bloc de chiffrement à attaquer et `cleartexthack` le résultat du déchiffrement
|
|
de `cblock[n]` avec notre `X` en vecteur d'initialisation, nous pouvons écrire :
|
|
|
|
$$
|
|
cleartexthack = decrypt(cblock[n]) \oplus X
|
|
$$
|
|
|
|
Nous savons aussi que :
|
|
|
|
$$
|
|
cblock[n] = encrypt(cleartext[n] \oplus cblock[n-1])
|
|
$$
|
|
|
|
Donc on peut écrire :
|
|
|
|
$$
|
|
cleartexthack = decrypt(encrypt(cleartext[n] \oplus cblock[n-1])) \oplus X
|
|
$$
|
|
|
|
En simplifiant :
|
|
|
|
$$
|
|
cleartexthack = cleartext[n] \oplus cblock[n-1] \oplus X
|
|
$$
|
|
|
|
Que l'on peut aussi écrire
|
|
$$
|
|
cleartext[n] = cleartexthack \oplus cblock[n-1] \oplus X
|
|
$$
|
|
|
|
Cette équation se compose de deux éléments que nous avons en notre possession :
|
|
`X` notre bloc forgé et `cblock[n-1]` notre avant-dernier bloc, et deux
|
|
éléments inconnus : `cleartexthack` le résultat en clair de la manipulation de
|
|
notre attaque et `cleartext[n]` le résultat du déchiffrement de `cblock[n]`.
|
|
|
|
Il n'est plus question ici de chiffrement, mais de simples opérations
|
|
booléennes.
|
|
|
|
Comme nous avons accès à une **oracle de padding** nous n'avons qu'à tester
|
|
toutes les valeurs du dernier octet de `X` jusqu'à obtenir un padding correct
|
|
(`0x01`). Dans le cadre de notre block de 16 octets :
|
|
|
|
$$
|
|
cleartext[n][15] = 0x01 \oplus cblock[n-1][15] \oplus X[15]
|
|
$$
|
|
|
|
Il ne nous reste plus qu'une inconnue `cleartext[n][15]`, nous pouvons résoudre
|
|
l'équation.
|
|
|
|
Il suffit de procéder ainsi pour les 16 octets de notre bloc pour le déchiffrer
|
|
en entier et ainsi de suite...
|
|
|
|
##### Et son utilisation contre les smartcard
|
|
|
|
C'est bien entendu une version simplifiée de l'attaque par padding oracle, mais
|
|
elle permet de comprendre son fonctionnement. Elle fut au centre des travaux de
|
|
recherche menés par Romain Bardou, Riccardo Focardi, Yusuke Kawamoto, Lorenzo
|
|
Simionato, Graham Steel, et al. donnant lieu à une publication. Ces travaux
|
|
permirent, en 2012, **l'extraction des clés privées** de beaucoup de
|
|
périphériques de cryptographie (PKCS#11) de marques différentes. Les chercheurs
|
|
ont par ailleurs largement améliorer les algorithmes de Bleichenbacher pour
|
|
accélérer sensiblement les performances, surtout sur les appareils peu puissant
|
|
comme les smartcards.
|
|
|
|
## Conclusion
|
|
|
|
L'authentification par smartcards liée à une PKI est intéressante à bien des
|
|
égard, réservée jusque là au monde de l'entreprise de par la complexité de
|
|
l'infrastructure à déployer. Mais l'apparition de périphériques comme les
|
|
*Yubikey* et la nécessité de pallier aux problèmes des mots de passes pousse les
|
|
entreprises touchant le grand public à trouver des solutions; *WebAuth* en est
|
|
la preuve (mais sans la partie PKI).
|
|
|
|
Il est cependant utopique de penser que les smartcards résolvent tous les
|
|
problèmes, bien au contraire. Nous avons vu qu'il est possible d'attaquer
|
|
directement l'infrastructure de clés[^n_infra]. Mais il est est aussi possible
|
|
d'attaquer le périphérique lui même: n'oublions pas que celui-ci est complexe,
|
|
équipé de plusieurs processeurs et d'un système d'exploitation, agrandissant la
|
|
surface d'attaque[^n_yubikey].
|
|
|
|
N'oublions pas aussi qu'un périphérique se vole; et si la plupart des smartcards
|
|
sont résistante à l'ouverture par la force, une attaque ciblée couplée à de
|
|
l'ingénierie sociale bien menée pour retrouver le code PIN reste possible.
|
|
|
|
[^n_infra]:Google a publié le 23 février 2017 un article annonçant la première
|
|
collision sur du SHA1. [source](https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html)
|
|
|
|
[^n_yubikey]:La Yubikey 4, et d'autre périphériques cryptographiques sont
|
|
touchés par ROCAT, une faille touchant des librairies utilisées par des puces
|
|
de la marque Infineon Technologies AG et permettant de prédire la clé privée
|
|
grâce à la clé publique - CVE-2017-15361. [source](https://crocs.fi.muni.cz/public/papers/rsa_ccs17)
|
|
|
|
## Bibliographie
|
|
|
|
Stéphane Bortzmeyer *[RFC 5280: Internet X.509 Public Key Infrastructure
|
|
Certificate and Certificate Revocation List (CRL)
|
|
Profile](https://www.bortzmeyer.org/5280.html)*
|
|
|
|
Ivan Ristić *[BulletProof SSL and TLS](https://www.feistyduck.com/books/bulletproof-ssl-and-tls)*
|
|
|
|
Pixis *[Padding oracle](https://beta.hackndo.com/padding-oracle/)*
|
|
|
|
Romain Bardou, Riccardo Focardi, Yusuke Kawamoto, Lorenzo Simionato, Graham Steel, et al..
|
|
*Efficient Padding Oracle Attacks on Cryptographic Hardware.* [Research Report] RR-7944, 2012,
|
|
pp.19. <hal-00691958v2>
|
|
|
|
Marc Zaffagni *[CNETfrance.fr : Vers la fin des mots de passe ? WebAuthn est
|
|
désormais un standard du web](https://www.cnetfrance.fr/news/vers-la-fin-des-mots-de-passe-webauthn-est-desormais-un-standard-du-web-39881531.htm)*
|
|
|
|
W3C *[Web Authentication: An API for accessing Public Key Credentials](https://www.w3.org/TR/webauthn)*
|
|
|
|
Wikipedia *[Attaque de collisions](https://fr.wikipedia.org/wiki/Attaque_de_collisions)*,
|
|
*[Attaque par canal auxiliaire](https://fr.wikipedia.org/wiki/Attaque_par_canal_auxiliaire)*
|