Auth forte application
description
Transcript of Auth forte application
White Paper
Quelle solution d’authentification forte
pour quelle application ??
Version 2.0
SCRYPTO
- 2 -
SOMMAIRE
1. QU’APPELLE-T-ON AUTHENTIFICATION FORTE 3
2. PRINCIPALES TECHNIQUES D’AUTHENTIFICATION FORTE 4
2.1. LE TOKEN DE TECHNOLOGIE « SYNCHRO-TEMPS» 4 1.1.1. PRESENTATION 4
2.2. LE TOKEN DE TECHNOLOGIE « DEFI-REPONSE » 5
2.2. LE TOKEN DE TECHNOLOGIE « DEFI-REPONSE » 6
1.1.2. PRESENTATION 6
2.3. CERTIFICATS DIGITAUX SUR DISQUE 8 1.1.3. PRESENTATION 8
2.4. CARTE A PUCE A CRYPTO PROCESSEUR 10
2.5. SCHEMA DE L’AUTHENTIFICATION 10
2.6. CLE A PUCE A CRYPTO PROCESSEUR 11
1.1.4. PRESENTATION 11
1.1.5. SCHEMA DE L’AUTHENTIFICATION 12
2.7. BIOMETRIE 13 1.1.6. PRESENTATION 13
1.1.7. SCHEMA D’AUTHENTIFICATION 14
3. BESOINS 15
3.1. ACCES AU RESEAU D’ENTREPRISE 15
3.2. ACCES INTRANET-EXTRANET 16
3.3. EVOLUTIVITE - RESPECTS DES STANDARDS 17
3.4. SINGLE SIGN-ON (SSO)- MULTI-APPLICATIONS 19
4. CONCLUSIONS 20
- 3 -
1. Qu’appelle-t-on Authentification Forte L’authentification forte est une vérification rigoureuse (sinon parfaite, serait-on tenté de dire !)
de l’identité d’un individu, cette vérification s’effectuant au travers d’un processus s’appuyant
sur une ou plusieurs technologies.
A l’heure actuelle, on peut affirmer qu’aucune des technologies proposées par le marché
n’est parfaite. Le « vol d’identité » est toujours possible, car dans la plupart des cas la
menace et la contrainte font tomber toutes les barrières technologiques.
Par exemple, au Distributeur Automatique de Billets, un voleur « persuasif » peut demander
au porteur d’une carte bancaire tout l’argent qu’il souhaite (dans la limite de son plafond de
retrait !) ou simplement lui « emprunter » carte et code secret pour faire ses courses !
Néanmoins, si l’on occulte l’usage de la menace physique et que l’on se place dans un
environnement sécurisé (l’environnement professionnel ou le domicile) la technologie répond
dans la majorité des cas précis au problème de l’usurpation.
Cette usurpation serait, dans la plupart des applications, préjudiciable car un fraudeur serait
capable de :
- obtenir les droits afférents à cet utilisateur (accès à des ressources partagées,
accès à des ressources personnelles)
- signer des transactions au nom de cet utilisateur (passage d’ordres en bourse,
achat de biens en ligne, etc.)
Le challenge de l’authentification forte est donc de « rendre difficile la fraude pour un pirate
ou un voleur » en respectant, toutefois, les contraintes liées à l’environnement technique,
économique et organisationnel de l’application.
Ce document présente de manière synoptique les principales méthodes disponibles sur le
marché de la sécurité et essaie de répondre à la question que vous vous posez « quelle
solution d’authentification forte pour mon application ? ».
- 4 -
2. PRINCIPALES TECHNIQUES D’AUTHENTIFICATION FORTE 2.1. Le token de technologie « synchro-temps»
1.1.1. Présentation
Ce système se présente sous la forme la plus simple :
- petit afficheur d’une ligne
- pas de clavier
L’utilisateur ne transmet aucune information au token.
Des variantes existent :
Présence d’un clavier pour la saisie d’un code PIN permettant le déblocage de la fonction de
calcul du mot de passe.
Token de technologie « synchro-temps »
Fonctionnement - Système de génération de mot de passe à usage unique (OTP).
- Génération et affichage d’un nombre non prédictible toutes les 60 secondes (par
exemple).
- L’utilisateur saisit son identifiant et son mot de passe dans l’interface
d’authentification : le mot de passe est une combinaison du code PIN de l’utilisateur
et de l’OTP.
- Validation du mot de passe transmis par le système au serveur d’authentification
qui autorise ou refuse l’accès.
Points clé - Périphérique unique qui ne peut être cloné.
- Combiné avec un code PIN constitue une méthode d’authentification à 2
facteurs.
- Ne nécessite aucun périphérique spécifique ou logiciel spécifique sur le poste
client.
- Administration des utilisateurs dans une base propriétaire.
Faiblesses du système - Pas de single sign-on : l’utilisateur doit s’authentifier explicitement sur chaque
application protégée par cette technologie.
- Peut nécessiter une ré-authentification lors de sessions longues.
- Pas évolutif : pas de signature possible.
- Validité limitée : pas de remplacement de la pile possible .
- Erreur d’authentification liée aux erreurs humaines (lecture et report du mot de
passe).
- Méthode non standard.
- Désynchronisation possible du token.
Environnement cible - Connexion depuis n’importe quel PC : pas de besoin de lecteur ou de logiciel
spécifique.
Application cible - Accès RAS ou VPN d’entreprise.
- Intranet et extranet où les applications sont accessibles au travers du navigateur.
- 5 -
2.2.
?
?
STATION DE TRAVAIL
123456
SERVEUR D’AUTHENTIFICATION
UserID : DUPOND
Password :
OTP =
123456
Code
PIN
123456
Heure Token = Heure
**** =
Clé secrète
DUPOND
Base utilisateurs
?
- 6 -
Le token de technologie « défi-réponse »
1.1.2. Présentation
Ce token est une version évoluée du token de technologie « synchronisation sur le temps »
car il dispose d’une interface clavier permettant de saisir un code PIN, un défi,
éventuellement un numéro d’application.
Token de technologie « défi-réponse » Fonctionnement - L’utilisateur active le token en saisissant son code PIN.
- Un défi est affiché sur l’écran du token.
- L’utilisateur rentre le défi au clavier du token.
- Le token génère une réponse.
- L’utilisateur saisit son identifiant et son mot de passe dans l’interface
d’authentification : le mot de passe est la réponse générée par le token.
- Validation du mot de passe transmis par le système au serveur d’authentification
qui autorise ou refuse l’accès.
Points clé - Token + code PIN = méthode d’authentification à deux facteurs.
- Piles remplaçables.
- Système non basé sur le temps : pas de problème de dérive temps.
- Peut être utilisé dans certains cas comme outil de signature pour une quantité
réduite de données (montant d’une transaction par exemple).
Faiblesses du système - Ergonomie du système (clavier et écran de taille réduite).
- Procédure de login assez complexe.
- Méthode non standard.
Environnement cible - Sécurisation des accès distants pour les nomades et télé-travailleurs.
Application cible - Accès RAS et VPN d’entreprise.
Il existe une variante pour les token de technologie « défi-réponse » :
Certains fabricants proposent des lecteurs autonomes (type calculette) avec afficheur-clavier
dans lesquels on peut insérer une carte à puce.
Ce type de lecteur permet de s’affranchir du problème d’absence de lecteur connecté au
poste.
Par contre, la taille de la zone de saisie du mot de passe dans l’interface des procédures de
logon empêche la mise en œuvre de l’algorithme asymétrique RSA. La signature s’effectue,
en effet, sur des données de 512, 1024 ou 2048 bits.
On ne pourra utiliser qu’un algorithme symétrique pour lequel la taille des blocs chiffrés est
limité à 8 octets (DES ou 3-DES)
- 7 -
Base
utilisateurs
STATION DE TRAVAIL SERVEUR D’AUTHENTIFICATION
UserID : DUPOND
Password : 123456
123456
123456
DEFI
Clé secrète DUPOND
REPONSE =
123456
DEFI
DEFI PIN
?X = DEFI
Clé secrète DUPOND
- 8 -
2.3. Certificats digitaux sur disque
1.1.3. Présentation
En dehors de l’utilisation d’une carte à puce ou d’une clé à puce dans le cadre d’une PKI, le disque dur reste le moyen le plus répandu pour stocker le certificat, ainsi que la clé privée associée, de l’utilisateur.
Certificats digitaux sur disque Fonctionnement - idem carte ou clé à puce à la différence près que le certificat et la clé privée sont
stockée sur le disque dur du poste.
Points clé - pas de matériel ou logiciel spécifique.
- proposé par les principaux systèmes d’exploitation.
Faiblesses du système - Mobilité réduite : il est nécessaire d’exporter son certificat et sa clé privée sur
disquette.
- La sécurité repose sur un simple mot de passe qui protège la clé privée (fichier
PKCS#12).
- L’importation des données d’identification sur des postes autres que le sien diminue
la confiance que l’on peut accorder au certificat.
- La compromission de la clé privée n’est pas facilement détectable (pas d’objet
physique perdu, une simple copie suffit).
Environnement cible - Réseaux ne nécessitant qu’un niveau réduit de sécurité.
- Utilisateurs se connectant à un Intranet ou extranet toujours à partir du même
poste.
Application cible - E-commerce avec des transactions de faible montant.
- 9 -
X = DEFI
REPONSE
CERTIFICAT
REPONSE
DEFI
Clé privée DUPOND
REPONSE
DEFI
Clé publique
AC
?X = COMPRIME
SIGNATURE
DEFI
STATION DE TRAVAIL SERVEUR D’AUTHENTIFICATION
?
- 10 -
2.4. Carte à puce à crypto processeur
Présentation
Carte à puce à crypto processeur
Fonctionnement - La clé privée et le certificat de l’utilisateur sont stockés dans la carte.
- Au login l’utilisateur introduit sa carte dans le lecteur de carte.
- L’identifiant et le certificat sont lus dans la carte.
- Le serveur vérifie le certificat et contrôle sa non révocation.
- Le code PIN est saisi et vérifié par la carte : en cas de succès, la fonction de signature avec la
clé privée est débloquée.
- L‘authentification de l’utilisateur est effectuée dans une procédure de défi-réponse.
Points clé - Mobilité : l’utilisateur peut utiliser son certificat et sa clé privée sur d’autres postes que le sien.
- En cas de perte ou de vol de la carte le certificat est révoqué par l’administrateur.
- Clonage impossible : la clé privée ne peut être lue.
- L’identifiant de l’utilisateur est lu directement dans la carte.
- Méthode standard : utilisation certificat X.509 et algorithme asymétrique RSA.
- La carte est utilisée comme outil de verrouillage de la station : le retrait de la carte provoque le
verrouillage de la station.
- Le dialogue appli-carte étant direct toutes les opérations de signature et de
chiffrement/déchiffrement sont possibles.
- Offre les fonctions de single sign-on : plusieurs couples identifiant – mot de passe peuvent être
mémorisés dans la carte.
- Les solutions sont compatibles avec les nombreux lecteurs PC/SC.
- Compatibilité avec le standard Microsoft (CryptoAPI).
Faiblesses du système - Pas de login à partir de n’importe quel PC (nécessite un lecteur et un module logiciel client
spécifique).
- Difficilement déployable sur les extranets (réticence des utilisateurs à installer lecteur et logiciel
sur leur propre PC).
- Nécessite de déployer une PKI.
Environnement cible - L’installation et la configuration de tous les postes sont contrôlées par l’administrateur réseau :
homogénéité des logiciels (OS, module client, drivers) et des matériels (lecteurs, cartes)
Application cible - Applications de single sign-on.
- Logon sécurisé sur domaine Windows 2000 (LAN ou VPN).
- Authentification à toutes les applications au travers d’un portail Web.
- Authentification des utilisateurs en accès VPN : compatible clients VPN du marché (compatible
CryptoAPI).
- Application nécessitant confidentialité (chiffrement des données) et non répudiation (signature).
- Carte entreprise (multi-application).
2.5. Schéma de l’authentification
Voir schéma d’authentification clé à puce
- 11 -
2.6. Clé à puce à crypto processeur
1.1.4. Présentation
Carte et clé à puce ont le même niveau fonctionnel. Elles peuvent cohabiter dans une même
application d’authentification car elle utilisent les mêmes techniques basées sur une PKI.
La clé à puce autorise moins le multi-application car les applications de contrôle d’accès
physique, les applications de porte-monnaie électronique (distributeurs, automate de
rechargement, etc…) ne proposent pas à l’heure actuelle des interfaces USB.
Clé à puce à crypto processeur
Fonctionnement - La clé privée et le certificat de l’utilisateur sont stockés dans la clé.
- Au login l’utilisateur introduit sa clé dans le connecteur USB.
- L’identifiant et le certificat sont lus dans la clé.
- Le serveur vérifie le certificat et contrôle sa non révocation.
- Le code PIN est saisi et vérifié par la clé : en cas de succès, la fonction de signature avec la clé
privée est débloquée.
- L‘authentification de l’utilisateur est effectuée dans une procédure de défi-réponse.
Points clé - Mobilité : l’utilisateur peut utiliser son certificat et sa clé privée sur d’autres postes que le sien.
- En cas de perte ou de vol de la clé le certificat est révoqué par l’administrateur.
- Clonage impossible : la clé privée ne peut être lue.
- L’identifiant de l’utilisateur est lu directement dans la clé.
- Méthode standard : utilisation certificat X.509 et algorithme asymétrique RSA.
- La clé est utilisée comme outil de verrouillage de la station : le retrait de la clé du connecteur
USB provoque le verrouillage de la station .
- Le dialogue appli-clé étant direct toutes les opérations de signature et de
chiffrement/déchiffrement sont possibles
- Offre les fonctions de single sign-on : plusieurs couples identifiant – mot de passe peuvent être
mémorisés dans la clé.
- Pas besoin de lecteurs (pas d’installation de driver spécifique).
- Compatibilité avec standard Microsoft (CryptoAPI).
- Pratique : utilisation de la clé à puce comme porte-clé.
Faiblesses du système - Pas de login à partir de n’importe quel PC (nécessite un port USB).
- Difficilement déployable sur les extranets (réticence des utilisateurs à installer un logiciel sur
leur propre PC).
- Nécessite de déployer une PKI.
Environnement cible - L’installation et la configuration de tous les postes sont contrôlés par l’administrateur réseau :
homogénéité des logiciels (OS, module client, drivers) et des matériels (lecteurs, cartes).
Application cible - Applications de single sign-on.
- Logon sécurisé sur domaine Windows 2000 (LAN ou VPN).
- Authentification à toutes les applications au travers d’un portail Web.
- Authentification des utilisateurs en accès VPN : compatible clients VPN du marché (compatible
CryptoAPI).
- Application nécessitant confidentialité (chiffrement des données) et non répudiation (signature).
- 12 -
1.1.5. Schéma de l’authentification
Clé publique
AC
STATION DE TRAVAIL SERVEUR D’AUTHENTIFICATION
CERTIFICAT
SIGNATURE
?ACCREDITATIO
N
CRYPTO
Clé publique DUPOND
PIN
ACCREDITATION
CRYPTO
Clé privée
DUPOND
ACCREDITATION …
X = COMPRIME
CRYPTO
- 13 -
L’accréditation peut être : § Un TGT (Ticket Granting Ticket pour accéder au TGS) : dans l’authentification
Kerberos (Smart Card Logon de Windows 2000)
§ Plus généralement, un authentifiant pour le compte sur lequel l’utilisateur souhaite
se connecter
2.7. Biométrie
1.1.6. Présentation
Biométrie
Fonctionnement - L’utilisateur est authentifié à partir d’une donnée physique caractéristique telle que l’empreinte
digitale, l’empreinte vocale, la forme du visage, l’analyse de comportement (dynamique de
signature, vitesse de frappe au clavier), etc.
- Chaque type d’authentification nécessite un matériel spécifique (scanner, microphone, caméra,
tablette de digitalisation, etc.) et un logiciel spécifique (implémentation d’algorithme de
comparaison des données collectées avec un modèle).
Points clé - Les données biométriques sont propres à un utilisateur.
- Portabilité : les données biométriques font partie intégrante de l’utilisateur !
- Peut être utilisé comme moyen d’identification (recherche du modèle correspondant dans la
base des utilisateurs) : évite la saisie de l’identifiant.
- Pas de code PIN ou de Mot de Passe à retenir.
Faiblesses du système - Nécessité de matériel spécifique coûteux.
- Fiabilité : plusieurs lectures sont parfois nécessaires (qualité des périphériques).
- Risque d’erreur qu’il est nécessaire d’occulter (fixer un taux acceptable pour éviter rejets
répétitifs) : notion de TFR (Taux de Faux Rejets) et de TFA (Taux de Fausses Acceptations).
- Nécessite l’enregistrement de l’utilisateur (Une ou plusieurs mesures).
Environnement cible - Identification et authentification dans des environnements dépourvus de clavier-écran (sas
d’accès).
Application cible - Contrôle d’accès logique au réseau d’entreprise (bio-identification simple).
- En complément avec des solutions par carte ou clé à puce (méthode d’authentification à 3
facteurs) dans des applications très sensibles au sein d’institutions financières, dans un
périmètre militaire, ou dans des centres de recherche (bio-identification évoluée).
- 14 -
1.1.7. Schéma d’authentification
MODELE
Base des utilisateurs
STATION DE TRAVAIL SERVEUR D’AUTHENTIFICATION
UserID : DUPOND
Password : EMPREINTE
REDUITE
EMPREINTE REDUITE
EMPREINTE
REDUITE
? SCORE < SEUIL
- 15 -
3. Besoins
Les tableaux ci-après font état de l’adaptation de chaque technologie pour un besoin donné.
3.1. Accès au réseau d’entreprise
LAN RAS VPN
Token
“chrono
temps”
NON (pas adapté)
OUI Le serveur RA S doit supporter ce
type d’authentification ou nécessité
d’un serveur RADIUS
OUI Le serveur VPN doit supporter ce
type d’authentification ou nécessité
d’un serveur RADIUS
Token
“défi-
réponse”
NON (pas adapté)
OUI Le serveur RAS doit supporter ce
type d’authentification ou nécessité
d’un serveur RADIUS
OUI Le serveur VPN doit supporter ce
type d’authentification ou nécessité
d’un serveur RADIUS
Certificat
sur disque NON OUI
Si le client et serveur RAS supporte
le protocole EAP
OUI De nombreux éditeurs de clients
VPN propose la compatibilité avec
les standards (CryptoAPI de
Microsoft ou PKCS#11 de RSA)
Biométrie OUI Nécessite modification de la
procédure d’authentification de
l’OS
OUI Si le client et serveur RAS supporte
le protocole EAP
NON Dans IPSec utilisation d’un
« shared secret » (niveau de
sécurité faible) =>à combiner avec
certificat
Carte
et clé à puce OUI
Windows 2000 supporte le
smart card logon nativement
Nécessite modification de la
procédure d’authentification
pour les autres OS
OUI Si le client et serveur RAS supporte
le protocole EAP
Ou
Stockage userID-MdP du compte
RAS dans carte/clé
OUI De nombreux édteurs de clients
VPN propose la compatibilité avec
les standards (CryptoAPI de
Microsoft ou PKCS#11 de RSA).
Dans IPSec, IKE utilise les
certificats
- 16 -
3.2. Accès intranet-extranet
Poste banalisé Poste non banalisé
Token
“chrono
temps”
OUI
OUI
Token
“défi-
réponse”
OUI
OUI
Certificat
sur disque
NON Pas adapté, car nécessite l’importation du
certificat et de la clé privée
OUI
Nécessite mise en œuvre de SSL
Biométrie NON
OUI
Nécessite installation lecteur et logiciel spécifique
Carte
et clé à puce
OUI
OUI
Nécessite installation lecteur et logiciel spécifique
Nécessite mise en œuvre de SSL
La carte à puce peut être utilisée sur un poste banalisé avec le lecteur autonome (type calculette). Dans ce cas, l’utilisation du certificat de clé publique n’est pas possible. Il est obligatoire d’utiliser l’algorithme symétrique de la carte (si disponible).
- 17 -
3.3. Evolutivité - Respects des standards
Standards Chiffrement Signature Token
“chrono
temps”
NON
NON
NON
Token
“défi-
réponse”
NON
NON
OUI Fonctionnalité réduite (non
standard)
Certificat
sur disque
OUI CryptoAPI pour Microsoft (CSP
Microsoft)
Certificat X.509
OUI RAS : EAP-TLS + MPPE
VPN : IPSec (IKE)
Intranet-Extranet : SSL
Disque : EFS (W2000) ou propriétaire
OUI Messagerie sécurisé : S/MIME
Application propriétaire :
utilisation de CryptoAPI
Biométrie
NON
NON
NON
Carte
et clé à puce
OUI CryptoAPI pour Microsoft (CSP
spécifique fabricant carte/clé)
Certificat X.509
Intégration de plusieurs algo
standard (RSA, DES, AES, ECC)
OUI
RAS : EAP-TLS + MPPE
VPN : IPSec (IKE)
Intranet-Extranet : SSL
Disque : EFS (W2000) ou propriétaire
OUI Messagerie sécurisé : S/MIME
Appli propriétaire : utilisation
de CryptoAPI
Dans le cadre d’un environnement Microsoft Windows, l’intégration dans l’architecture de
sécurité CryptoAPI permet à des applications tierces, telles que le navigateur (IE) ou la
messagerie (Outlook), d’exploiter le certificat et la clé privée contenus dans le support (carte
ou clé).
Toutefois, les fonctions d’authentification EAP-TLS, le tunneling IPSec ne sont disponibles
que sur Windows 2000 et XP.
C’est le cas également du système de chiffrement EFS (Encryption File System) qui est
propre à Windows 2000 et XP, et qui s’appuie sur CryptoAPI.
Pour être compatible CryptoAPI, chaque éditeur de solution d’authentification basée sur la
carte à puce ou la clé à puce doit fournir un CSP (Cryptographic Service Provider) qui est
« pluggé » dans l’architecture de Microsoft.
- 18 -
Le déploiement important de Windows 2000 et Windows XP comme plate-forme pour les
stations de travail des utilisateurs constitue donc un critère de choix d’une solution
d’authentification forte.
En l’occurrence le choix d’une solution à base de carte à puce (ou clé à puce) à
cryptoprocesseur est garante de la pérennité de ses investissements.
- 19 -
3.4. Single Sign-On (SSO)- multi-applications
Le multi-application est apparenté à la carte d’entreprise offrant par exemple des fonctions de : - Contrôle d’accès physique (accès locaux, accès parking)
- Restauration d’entreprise
- Porte-monnaie électronique (distributeur café, friandise, etc.)
- Etc…
SSO Multi-applications Token
“chrono temps” NON
NON
Token
“défi-réponse” NON
NON
Certificat
Sur disque OUI
Si les applications sont compatibles PKI
NON
Biométrie NON
NON
Carte
et clé à puce OUI
Mémorisation des couples identifiant-MdP
OUI
La clé à puce n’est pas facilement utilisable en
l’absence de port USB sur les équipements
Pour le single sign-on, seules les technologies permettant la mémorisation de couples Identifiant – Mot de passe offriront des fonctionnalités de single sign-on simples.
- 20 -
4. Conclusions
Actuellement, les solution d’authentification forte basées sur la carte à puce ou sur la clé à
puce dotée d’un cryptoprocesseur constituent le meilleur compromis quelque soit le type
d’application à protéger. Les tableaux comparatifs sur les différents critères évoqués le
prouvent.
De plus, elles offrent de réelles perspectives d’évolutivité. Notamment, l’intégration des
techniques d’identification biométrique permet d’offrir un niveau de sécurité optimum
(solutions d’authentification à 3 facteurs).
La reconnaissance et l’adoption du standard X.509 pour les méthodes d’authentification et
de signature garantit la pérennité de ces solutions ainsi que l’interopérabilité avec de
nombreuses applications externes.