Elaboration d’un modèle d’identité et fédération d’identité

Le One Time Password

Comme son nom l’indique, le One Time Password consiste à soumettre à l’utilisateur un mot de passe valable une seule fois, à un moment précis. Contrairement au cas précédent, l’utilisateur ne choisit donc pas le mot de passe, qui est en général une chaîne pseudo-aléatoire d’une longueur très variable selon les implémentations. En effet, Le fait que le mot de passe n’ait de validité qu’à un instant donné, sans droit à l’erreur, limite par nature toute attaque par force brute ou par dictionnaire.
Par conséquent, il n’est pas rare qu’un OTP soit une suite de quatre ou cinq caractères qui peuvent être uniquement des chiffres. En dehors d’être unique, un OTP se doit également d’être non prédictible : la connaissance d’OTP antérieurs ne doit pas permettre à un attaquant de déduire les OTP futurs. Dans cette section, nous décrivons les implémentations les plus courantes de l’OTP, et nous montrerons que, quelle que soit son incarnation, l’OTP n’est finalement qu’une déclinaison plus élaborée du modèle d’identité «identifiant / mot de passe» sur laquelle l’attaque par Phishing devient beaucoup moins efficace, mais qui reste sensible à une attaque de type MITM.

Transmission de l’OTP par courrier électronique et SMS

D’un contexte à l’autre, les déploiements d’un système d’authentification par OTP sont très variables. Le point commun entre les différentes versions existantes consiste à trouver un moyen de transmettre une donnée, de manière certaine, à l’utilisateur. Une première approche consiste à utiliser une donnée numérique propre à l’utilisateur, notamment son adresse mail ou son numéro de téléphone, comme moyen de lui transmettre des données – dans un cas par courrier électronique, dans l’autre cas par SMS. Par exemple, dans les systèmes bancaires, lors d’un paiement en ligne, l’utilisateur n’est, par défaut, pas authentifié auprès de sa banque. Celle-ci utilise alors en général l’adresse mail fournie par l’utilisateur, ou bien son numéro de téléphone, ou bien les deux à la fois, qui servent de point de contact avec ce dernier, et permettent de lui envoyer un mail et/ou un SMS contenant l’OTP.
Le cas de la transmission par mail se heurte, par ricochet, au problème de l’authentification au serveur de mail, protégé par le classique «identifiant / mot de passe». Celui de la transmission par SMS permet d’éviter cet écueil et bénéficie également, éventuellement, d’un chiffrement de type symétrique de type A5/x lors du transport jusqu’au téléphone de l’utilisateur – bien que les algorithmes A5/1 et A5/2, utilisés dans les réseaux GSM, soient depuis longtemps considérés comme cassés.

Les OTP non numériques

Une orientation différente de la conception de l’OTP conduit à établir préalablement le lien entre l’utilisateur et un élément physique qui sera générateur d’OTP. Cet élément physique peut être non numérique, c’est-à-dire sous forme papier, qui contient alors une liste d’OTP statiques. Lors d’une procédure d’authentification, il est demandé à l’utilisateur de saisir l’un de ces OTP, qui ne sera plus jamais demandé par la suite. Ce système est mis en pratique dans certaines banques, qui envoient une carte d’OTP statiques à l’utilisateur sur recommandé, c’est-à-dire sur la fois de son adresse postale. Ces OTP peuvent être demandés lors d’achats en ligne ou de virements bancaires.
Le principal défaut de ce système réside dans son format même. En effet, les OTP peuvent être visibles pour quiconque est proche de l’utilisateur, et la nécessité de posséder en permanence, sur soi, la carte d’OTP, en fait une cible facile pour un vol matériel. Ainsi, dans le cas des systèmes bancaires, il est très probable que cette carte sera conservée conjointement avec la carte de crédit – le vol de l’une impliquant le vol de l’autre avec une probabilité non négligeable. On peut considérer ce système comme une version statique et non numérique d’un système plus élaboré reposant sur un composant hardware ou, dans une version équivalente, sur un composant software dédié, installé sur un équipement mobile. Ce sont ces derniers qui vont à présent retenir notre attention.

La biométrie

La biométrie a pour objet d’authentifier un individu à partir d’une ou de plusieurs de ses caractéristiques physiques ou comportementales. Les modalités biométriques pouvant être mises en œuvre dans un protocole d’authentification sont multiples : analyse des empreintes digitales, de la géométrie de la main, scanner de la rétine ou de l’iris, analyse de la signature manuscrite, reconnaissance faciale, etc. L’identité d’une personne peut alors être vérifiée par comparaison de la modalité relevée avec un modèle figurant dans une base de données consultée par le serveur d’authentification. Deux politiques peuvent être mises en œuvre à cette fin :
La vérification d’une modalité nominative, c’est-à-dire sur un seul échantillon de la base (comparaison individuelle 1 : 1), extraite de la norme X9.84-2001 .
L’identification d’une modalité anonyme, testée sur tous les échantillons (comparaison collective 1 : N), à nouveau extraite de la norme X9.84-2001.
Dans les deux cas, si la concordance entre la modalité et l’échantillon est jugée suffisante, l’identité de l’utilisateur est considérée comme vérifiée. L’évaluation du degré de concordance est réalisée par une analyse mathématique qui définit un seuil d’acceptation au-dessus duquel l’identité est vérifiée. De nombreux organismes ont œuvré à la standardisation des données biométriques, parmi lesquels, outre l’ISO et l’IEC, nous pouvons citer le NIST, qui a mis en place le standard CBEFF (Common Biometric Exchange Formats Framework) définissant le format numérique d’échange de données biométriques . Par construction, l’authentification par la biométrie n’existe que dans un modèle symétrique. La différence essentielle avec la notion de mot de passe provient du caractère personnel, non secret, non modifiable et non imitable de la donnée. Le fait même que la biométrie s’appuie sur une caractéristique propre à l’individu rend le terme générique «authentification» impropre. En réalité, si un terme générique doit être employé, il s’agit d’identification : l’individu déclare qui il est par le moyen d’une de ses modalités biométriques, ce qui lui permet par ailleurs d’éviter d’avoir à mémoriser une information – ce qui reste l’un des principaux écueils de l’authentification par mot de passe. De plus, les caractéristiques fondant la biométrie garantissent une association naturelle entre l’information fournie (la modalité), et l’identité de l’utilisateur. De ce point de vue, dans un contexte administratif adapté (typiquement, authentification hautement sécurisée de personnel dans une infrastructure), et avec la garantie de disposer d’un lecteur biométrique de confiance, un protocole s’appuyant sur EAP-TTLS et utilisant la biométrie dans la seconde phase d’authentification, avait été proposé en tant que draft à l’IETF . Toutefois, malgré les attraits que la biométrie possède, de nombreuses limitations existent, et beaucoup d’attaques sont réalisables, ce qui amène à penser que la définition d’un modèle d’identité numérique reposant sur ce principe relève d’une gageure.

Le protocole TLS

Le protocole TLS, anciennement dénommé SSL, a été inventé par Netscape dans les années 1990. Il s’agit d’un protocole se situant entre la couche transport et la couche applicative visant à ajouter une couche sécuritaire protégeant les données applicatives. C’est du moins son utilisation la plus courante : le protocole TLS a en effet l’avantage de pouvoir sécuriser, par un canal chiffré, et sans souci d’interopérabilité, tout protocole de niveau applicatif (FTP[44], HTTP, SMTP, etc.), tout en nécessitant une connexion fiable au niveau du transport, par exemple le protocole TCP. Le fait que les protocoles de niveau applicatif permettent, par défaut, un échange de données en texte clair a très vite attiré l’attention sur les nombreux risques qu’un tel parti pris comporte. Etablir un protocole standardisé, interopérable, qui permette d’offrir, entre autres, confidentialité et intégrité des données, était donc loin d’être un luxe et explique en grande partie le succès de TLS.
Dans l’usage quotidien, les protocoles applicatifs les plus sollicités sont sans conteste HTTP et SMTP. Ainsi, dans le cas de HTTP tous les échanges réalisés avec un serveur Web transitent sans protection dans le réseau, laissant toute liberté à un attaquant ou un espion pour observer le contenu des requêtes et réponses. Cela comprend, bien entendu, les données sensibles telles que les mots de passe utilisateur ou les numéros de carte bancaire. Dans le cas de SMTP, non seulement l’identifiant et mot de passe du client sont transmis en clair à travers le réseau, mais les mails eux-mêmes peuvent être lus en entier par tout individu malveillant, et même éventuellement modifiés.
En réponse à ces défauts de conception, le protocole TLS propose d’établir, entre deux entités du réseau, les services de sécurité suivants :
Confidentialité des données par la mise en place d’un tunnel sécurisé entre client et serveur dans lequel les données sont chiffrées par un algorithme cryptographique symétrique tel que RC4 ou AES.
Intégrité des données par le calcul d’un MAC (Message Authentication Code) sur chaque fragment des données applicatives échangées. En général l’algorithme utilisé est un HMAC qui s’appuie sur des fonctions de hachage classiques telles que MD5 ou bien SHA-1.
Protection contre le rejeu par l’ajout d’un numéro de séquence pris en compte dans le calcul des MAC. Authentification à sens unique ou mutuelle par l’intermédiaire de certificats numériques X509. Ces derniers sont un maillon des infrastructures à clé publique (PKI) largement mobilisées dans le cadre du protocole TLS.

La carte à puce

L’histoire de la carte à puce remonte aux années 1970 où l’implication industrielle dans la microélectronique (Bull CP8, Schlumberger, etc.) a permis de concevoir les prémices d’un type de composant qui devait succéder aux cartes à bande magnétique, sur lesquels il était aisé de lire ou d’écrire des données. A l’heure actuelle, la carte à puce[68] peut être définie comme un type de micro-contrôleur sécurisé à bas prix mettant en place des contre-mesures visant à empêcher la modification de données stockées. Ces composants comportent un CPU, dont les architectures vont de 8 à 32 bits, quelques centaines de Ko de ROM qui contient le système d’exploitation du composant, de la RAM à hauteur d’environ 10 Ko, et une mémoire non volatile E²PROM dont la taille varie de 32 Ko à 1 Mo qui stocke la partie software (e.g. des Applets Javacard) ainsi que les clés cryptographiques. La carte à puce s’est aujourd’hui déployée à grande échelle (environ 7 milliards d’unité) dans de nombreux secteurs tels que la monétique (cartes EMV), la téléphonie mobile qui représente près de 75% du marché global de la carte à puce (cartes SIM, USIM), la médecine (cartes Vitale), le transport (cartes sans contact Navigo), etc. La puce des cartes à contacts ne peut fonctionner qu’à l’aide d’un CAD (Card Acceptance Device), usuellement un lecteur de cartes, qui lui délivre de l’énergie et une horloge, ainsi qu’un lien de communication avec un terminal. Elle est constituée de huit contacts à même de gérer ces différents éléments, selon le standard ISO 7816-2. La communication avec le terminal peut être un lien série ou bien une interface USB, avec un débit variant entre 9600 bits/s à quelques Mbits/s. Les paquets échangés entre la carte et le terminal s’appellent des APDUs (Application Protocol Data Units), d’une taille maximale de 256 octets, et dont la spécification détaillée est définie dans le standard ISO/IEC 7816.
La sécurité dans les cartes à puce est mise en place par un ensemble de contre-mesures physiques et logiques qui permettent d’empêcher, notamment, des attaques de type injection de fautes, consistant à introduire des erreurs volontaires dans l’exécution d’un programme afin d’en tirer des informations censées être secrètes, ou encore des attaques par canaux cachés (side channel attacks) qui visent à exploiter des données physiques ou temporelles produites par le composant (mesure de temps d’exécution, de consommation d’énergie pour un calcul donné par exemple) afin de déduire, par exemple, un secret cryptographique. Ces attaques sont connues pour fonctionner sur des environnements classiques tels que les ordinateurs, dont les composants hardware ne sont en général pas pourvus de telles contre-mesures. Pour cette raison, les attaques à base de malware ou de Trojan ont beaucoup plus de latitude pour nuire dans ces environnements que dans une carte à puce, où de nombreux verrous supplémentaires sont posés. Les cartes à puce fournissent ainsi un environnement de confiance, dans le sens défini par le Trusted Computing Group : «Trust is the expectation that a device will behave in a particular manner for a specific purpose» . Ce consortium, fondé en 2003, a notamment défini les spécifications d’un composant nommé TPM (Trusted Platform Module) prévu pour être attaché à la carte mère des terminaux afin d’exécuter des fonctionnalités telles que le relevé de mesures d’intégrité ou le stockage sécurisé d’informations. Néanmoins, contrairement aux cartes à puce, les TPM ne sont pas prévus pour stocker des données applications spécifiques.

Carte à puce et identité numérique

La carte à puce a permis de faire apparaître un modèle d’identité original par rapport à ceux qui ont été étudiés au cours du premier chapitre, et qui s’intéressaient avant tout à l’identité numérique au cœur du Web, et non aux réseaux accessibles via les terminaux mobiles. Or, ces modèles d’identités ont en commun le fait que l’utilisateur est pleinement détenteur et gestionnaire de son identité : c’est lui-même qui la crée et, en accord avec le modèle adopté, c’est lui-même qui sait comment fournir la preuve de son identité lorsque cela lui est demandé.
Mais des cartes à puce du type USIM, émises par des opérateurs mobiles de réseaux 3G, représentent un modèle où l’identité de l’utilisateur est gérée par une tierce partie. Dans ce paradigme, l’utilisateur accepte l’identité qui a été créée pour lui et sur laquelle il n’a aucune connaissance, notamment sur le secret incarné par une clé stockée dans la carte. La preuve de l’identité est réalisée sans l’intervention de l’utilisateur, qui n’a même pas connaissance de la procédure d’authentification.
L’orientation que nous avons prise, et qui nous amène sur un modèle d’identité reposant sur l’utilisation d’une carte à puce, nous permet assez naturellement de nous inscrire dans la convergence, puisque la carte à puce peut, par nature, se greffer aisément sur la plupart des terminaux modernes, i.e. des plateformes dites convergentes. Toutefois, pour être entièrement cohérents avec nos ambitions, il nous faut également prendre en considération le modèle dont nous venons de parler, et nous assurer que le modèle d’identité que nous élaborerons reste compatible à la fois avec un type de gestion centrée utilisateur, et avec un type de gestion déléguée à une tierce partie.

Les avantages sécuritaires de la carte EAP-TLS

Du point de vue de la sécurité, la différence essentielle entre les deux architectures est celle relative à la mise à contribution de l’environnement de confiance. Dans le cas des architectures classiques, le protocole TLS s’exécute par définition sur le poste client, et il existe dès lors une scission entre l’entité qui s’authentifie (i.e. le poste client, vulnérable) et l’élément sécurisé prouvant
l’identité (i.e. le composant contenant la clé privée et réalisant les calculs cryptographiques). Par conséquent, l’authentification mutuelle n’est pas parfaite. A cela s’ajoute le problème, du stockage du Master Secret d’une session TLS sur le poste client, alors qu’il s’agit d’une donnée capitale pour un attaquant. Par contraste, l’architecture que nous proposons réalise une authentification mutuelle complète entre la carte EAP-TLS de l’utilisateur et le serveur Web distant. Le poste client ne peut profiter de cette connexion sécurisée que s’il reçoit de la carte les clés temporaires successives et la ciphersuite associée, autrement dit si le lien entre le poste client et la carte EAP-TLS est établi, ce qui est précisément le rôle du code PIN utilisateur – qui assure au logiciel proxy que l’utilisateur du poste client est bien le possesseur de la carte EAP-TLS.
Par ailleurs, la réécriture complète du protocole TLS permet d’y ajouter des options ne s’opposant pas strictement au standard en vigueur, telles que la protection de l’identité du client mise en place par le chiffrement du certificat X509 de l’utilisateur . De la même manière, l’échange de clés par l’algorithme RSA implémente le plus souvent la norme PKCS#1 v1.5. Or, comme il a été démontré, cette norme présente des failles importantes permettant notamment à un attaquant de réaliser une opération impliquant la clé privée de la victime sans pour autant l’avoir récupérée. Il serait alors possible d’implémenter la norme PKCS#1 v2.1, la plus récente à ce jour, et qui est résistante à cette attaque. Cela n’a toutefois pas été réalisé, et ce pour deux raisons principales : avant tout, l’échange de clés par RSA tend à être délaissé au profit de l’utilisation de la cryptographie par courbes elliptiques (ECC), ce qui limite l’intérêt d’un tel ajout pour les perspectives futures. Par ailleurs, cette norme n’est pas préconisée par l’IETF à travers les dernières versions du protocole TLS, dans lesquelles la référence à la norme PKCS #1 v1.5 est explicite – ce qui limite les possibilités de déploiement de l’ajout en question. Il en va de même des calculs MD5-SHA-1 de la PRF, qui ont été officiellement remplacés par l’algorithme SHA-256 dans TLS v.1.2, version que peu de serveurs implémentent. Dans ces derniers exemples, le cas d’utilisation le plus adapté reste celui du M2M, où deux composants embarquant la même application peuvent communiquer avec des standards récents sans craindre de problèmes d’incompatibilité.

Table des matières

Partie I : L’identité numérique au cœur de l’Internet 
Chapitre 1 : L’identité numérique et les protocoles d’authentification
1.1 Introduction 
1.2 Les faiblesses du modèle « identifiant / mot de passe »
1.2.1 Contexte
1.2.2 Les contre-mesures simples limitant les attaques classiques
1.2.3 Le problème de la confiance
1.3 Le One Time Password 
1.3.1 Algorithmes de calcul des OTP
1.3.2 Transmission de l’OTP par courrier électronique et SMS
1.3.3 Les OTP non numériques
1.3.4 La génération d’OTP via jeton ou software dédié
1.3.5 La vulnérabilité des OTP face à des attaques de type MITM
1.4 La biométrie 
1.4.1 Principe
1.4.2 Limitations et faiblesses
1.5 Le protocole TLS 
1.5.1 Présentation générale
1.5.2 Détail d’une session TLS
1.5.3 L’identité et l’authentification dans TLS
1.5.4 Le protocole TLS-PSK
1.6 Conclusion 
Chapitre 2 : La fédération d’identité et le Single Sign On 
2.1 Introduction 
2.2 Fédération d’identité et SSO 
2.3 Les solutions pour la fédération d’identité 
2.3.1 Le protocole Infocard et Windows Cardspace
2.3.2 Le langage SAML
2.3.3 OpenID
2.3.4 Comparatif des différentes solutions .
2.4 Elaboration d’un modèle d’identité et fédération d’identité
2.5 Conclusion
Chapitre 3 : La carte à puce EAP-TLS 
3.1 Introduction 
3.2 La carte à puce 
3.2.1 Généralités sur la carte à puce
3.2.2 La technologie Javacard
3.2.3 Carte à puce et identité numérique
3.3 L’architecture de la carte EAP-TLS
3.3.1 Rappels sur le protocole EAP
3.3.2 Les contraintes du TLS embarqué
3.3.3 L’identité EAP-TLS
3.3.4 La gestion de l’EAP-TLS par la carte
3.3.5 Le logiciel proxy
3.4 Comparaison avec les architectures classiques 
3.4.1 Carte EAP-TLS et composants PKCS#15
3.4.2 Les avantages sécuritaires de la carte EAP-TLS
3.5 Déploiements de la carte EAP-TLS
3.6 Analyse de performances
3.6.1 Mesures sur Javacard GX4 et carte USIM
3.6.2 Mesures de connexions TCP parallèles
3.7 Transposition à un composant 8 bits ST23XXXX et comparaison de performances 
3.8 Conclusion
Partie II : Définition et gestion d’un modèle d’identité numérique fondé sur la carte EAP-TLS 
Chapitre 4 : Système de gestion de l’identité TLS
4.1 Introduction
4.2 La carte à identités TLS 
4.2.1 Cas d’une carte à une identité
4.2.2 Cas d’une carte à plusieurs identités
4.3 Le serveur d’identités 
4.3.1 Création d’un compte racine
4.3.2 Gestion des identités
4.3.3 Chargement des identités TLS dans la carte
4.3.4 Sécurisation des conteneurs d’identité
4.4 Le cycle de vie de la carte d’identités TLS
4.4.1 Création de la carte en usine
4.4.2 Gestion de la carte par l’utilisateur
4.4.3 Fin de vie de la carte
4.5 Analyse de la sécurité de l’architecture
4.5.1 Authentification
4.5.2 Enregistrement de l’utilisateur
4.5.3 Accès à des ressources protégées
4.5.4 Révocation
4.6 Implémentation du serveur d’identités
4.6.1 Technologies déployées
4.6.2 Performances mesurées
4.7 Conclusion 
Chapitre 5 : Intégration de la fédération d’identités et des réseaux mobiles
5.1 Introduction 
5.2 Intégration de la technologie OpenID 
5.2.1 Choix et implémentation de OpenID
5.2.2 Scénario d’authentification
5.2.3 Limitations
5.3 Adaptation aux terminaux mobiles 
5.3.1 Le système d’exploitation Android
5.3.2 Cas des téléphones RIM Blackberry
5.3.3 Architecture avec serveur OTA
5.4 Conclusion 
Partie III : Applications concrètes du modèle d’identité numérique fondé sur la carte EAP-TLS
Chapitre 6 : L’identité TLS pour l’authentification dans le Cloud Computing 
6.1 Introduction 
6.2 Une architecture d’authentification auprès d’un serveur RADIUS 
6.2.1 Contexte
6.2.2 Présentation de l’architecture
6.3 Une architecture pour la génération sécurisée de jetons SAML
6.4 Performances mesurées 
6.5 Conclusion 
Chapitre 7 : Une architecture pour le prépaiement sécurisé 
7.1 Introduction 
7.2 Les systèmes de paiement 
7.2.1 Généralités sur les transactions par carte bancaire
7.2.2 Les questions de sécurité
7.2.3 Le cas de la technologie EMV
7.3 Proposition d’un modèle pour le prépaiement 
7.3.1 Vue générale de l’architecture
7.3.2 Les jetons
7.3.3 Le terminal marchand
7.3.4 Le Front End
7.3.5 Le Back End
7.4 Scénario détaillé d’une transaction
7.4.1 Transmission des jetons clients vers le SAM
7.4.2 Connexion du SAM au serveur du Front End
7.5 Performances mesurées
7.6 Conclusion 
Chapitre 8 : Une architecture pour la distribution sécurisée de clés pour serrures RFID
8.1 Introduction 
8.2 La technologie NFC 
8.2.1 Généralités
8.2.2 Support de la technologie NFC par Android
8.3 Les cartes RFID à interface duale 
8.3.1 Le système d’exploitation JCOP
8.3.2 La carte Mifare Classic 1K
8.3.3 L’émulation Mifare
8.4 Proposition d’une architecture pour la distribution de clés 
8.4.1 Les éléments constitutifs de l’architecture
8.4.2 Scénario d’obtention d’une clé
8.4.3 Performances
8.5 Conclusion 
Conclusion générale
Annexe A : Les concepts de la sécurité 
Annexe B : Le standard ISO/IEC 7816 

Télécharger le rapport complet