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 »


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


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


?

- 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


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


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


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


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



Token

“défi-

réponse”

NON (pas adapté)

OUI Le serveur RAS doit supporter ce



OUI Le serveur VPN doit supporter ce



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.

auth forte application

Documents