|
|
|
Sommaire Sécurité |
|
Questions - Réponses
: le jargon des espaces de confiance électroniques en 10 points |
Authentifier
les utilisateurs d'un portail d'entreprise, permettre la signature
électronique de contrats, ouvrir l'accès à une multitude de
ressources depuis un point d'entrée unique... Difficile pour
une entreprise d'échapper aujourd'hui à la problématique de
l'espace de confiance électronique. L'heure est donc venue de
se frotter au jargon de la sécurité. PKI, chiffrement à clé
publique, VPN, SSO... JDNet Solutions vous propose une visite
guidée. (02/10/2001) |
|
Pourquoi ne pas
se contenter d'un échange de login et de mot de passe
pour créer un espace de confiance électronique?
Simplement, parce qu'un
tel échange garantit seulement que la personne à
l'écran connaît le login et le mot de passe adéquats...
Autrement dit, la saisie d'un mot de passe ne garantit pas en
soi la confidentialité des échanges qui suivent
cette procédure et encore moins, par exemple, la non-répudiation
des actes électroniques. En fait, même l'authentification
d'une personne n'est que "moyennement" assurée
par l'échange d'un login et d'un mot de passe (qui a
pu lui-même être échangé et donc dérobé).
Bref, l'échange d'un login et d'un mot de passe s'apparente
à une procédure basique incapable de couvrir à
elle seule les principaux besoins en matière de sécurité
(identification, confidentialité des échanges,
non répudiation des actes électroniques, gestion
des habilitations, etc).
Quelle
différence entre l'authentification, l'identification
et l'habilitation ?
"Identifier"
consiste à associer une personne physique à son
identité numérique. L'authentifier revient à
vérifier l'identité de cette personne. Schématiquement
donc, en saisissant un login, je m'identifie, en ajoutant mon
mot de passe, je m'authentifie. Cette procédure achevée,
je reçois alors des habilitations qui m'autorisent ou
non à accéder à des ressources (applications,
données, etc).
Si
le couple login/mot de passe est peu sécurisant, quels
sont les autres dispositifs possibles ?
Il existe au
moins deux grands types de dispositifs beaucoup plus robustes
que le simple mot de passe.
Le premier dispositif contraint l'utilisateur à posséder
un objet qui contient ou génère une clef électronique.
Il peut s'agir d'une carte à puce (qui demande donc la
présence d'un lecteur sur le poste de travail), d'une
clef USB (du nom du connecteur que l'on trouve dorénavant
sur bon nombre de PC et de Mac) ou encore d'une calculette,
ce dernier moyen étant aussi connu sous le nom de "jeton
d'authentification" (token, en anglais). En fonction de
l'heure ou d'un code envoyé par le serveur, cette calculette
génère une clef qui ne sera utilisable qu'une
fois - inutile de la dérober donc. Associée à
un login, cette clef dynamique
permet au serveur d'authentifier l'utilisateur. Seule faiblesse
de ces dispositifs, ils peuvent eux-même être dérobés...
Voilà pourquoi les plus exigeants se tournent vers la
biométrie. En fonction d'une empreinte digitale, vocale
ou encore à partir de la reconnaissance de l'iris, un
mécanisme authentifie physiquement l'utilisateur.
Dans ces problématiques
d'authentification quel rôle joue la signature électronique
?
La signature électronique
représente réellement la pierre angulaire de l'infrastructure
d'un espace de confiance. A elle seule, la signature :
Authentifie l'utilisateur
Assure que le document n'a
pas été modifié
Garantit le caractère
non-répudiable des documents signés.
Si la signature électronique
apporte une telle polyvalence c'est notamment parce qu'elle
repose sur des procédés de chiffrement à
clef publique.
Quel
est le schéma de fonctionnement du chiffrement à
clef publique sur lequel repose la signature électronique
?
Le chiffrement à clef
publique est aussi connu sous le nom de chiffrement asymétrique,
par opposition au chiffrement symétrique. Dans ce dernier
cas, deux utilisateurs doivent s'entendre sur un mot de passe
(ou une clef) qui, soumis à des algorithmes, permet de
chiffrer et de déchiffrer les documents échangés.
La robustesse du procédé dépend donc directement
du niveau de secret qui entoure le "mot de passe".
Lequel doit donc être renouvellé régulièrement
et transmis de manière sécurisée...
Le
chiffrement à clef publique utilise pour sa part deux
clefs: l'une, dite "privée", ne quitte pas
l'utilisateur; l'autre, dite "publique", porte assez
bien son nom. Cette combinaison clefs publique/privée
permet plusieurs usages.
Primo, un document chiffré avec la clef publique d'un
utilisateur ne pourra être déchiffré que
par la clef privée correspondante - seul le destinataire
du document peut donc le lire, ce qui garantit la confidentialité
de l'échange.
Secundo, un utilisateur peut aussi "signer" un message
avec sa clef privée car seule la clef publique correspondante
permettra au destinataire de lire le message.
- Le bon fonctionnement de la clef publique confirme qu'elle
est bien associée à la clef privée utilisée
pour chiffrer le message, ce qui authentifie l'émetteur.
Ce
procédé est d'autant plus robuste si la clef privée
de l'utilisateur est stockée dans un dispositif d'authentification
comme une carte à puce.
Si la signature électronique repose sur des procédés
de chiffrement à clef publique, elle demande donc de
déployer des infrastructures à clef publique (PKI)
?
Si l'on entend
par PKI le fait de recourir à un ou plusieurs tiers qui
prennent en charge l'enregistrement des utilisateurs, la certification
des identités ou encore la gestion des clefs, alors le
raccourci est un peu hâtif. En effet, une entreprise peut
déployer sa propre infrastructure de gestion des certificats
(par exemple pour authentifier sur un périmètre
interne ses propres salariés) sans passer par un ou plusieurs
tiers. D'ailleurs, le fameux logiciel de chiffrement PGP, qui
met en oeuvre du chiffrement asymétrique, se passe d'intermédiaire.
Ces tiers, dits tiers de confiance, s'imposent en revanche pour
les projets de plus grande envergure et dont les intervenants
ne sont pas forcément connus à l'avance. Dans
ces cas de figure, ils prennent en charge la procédure
de certification des nouveaux entrants, préalable à
leur entrée dans l'espace de confiance électronique.
Quels types de tiers entrent en jeu
dans une PKI ?
On
distingue au moins trois types d'acteurs :
L'autorité d'enregistrement qui s'occupe de vérifier
l'identité de l'utilisateur.
L'autorité de certification qui, pour sa part, génère
le certificat numérique.
L'opérateur PKI qui gère à proprement parler
ces certificats (stockage dans des infrastructures sécurisées,
etc.)
Dans la pratique, les rôles ne sont pas forcément
aussi dissociés. Une même entité peut à
la fois faire office d'autorité de certification et d'opérateur
PKI.
Concrètement, les certificats
numériques sont-ils directement manipulés par
les utilisateurs ?
Pas toujours.
Les certificats numériques sont utilisés aussi
bien au niveau des applications directement visibles par l'utilisateur
qu'au niveau, plus enfoui, des couches réseau. Deux exemples.
- Pour signer électroniquement un contrat, un utilisateur
passera par une application d'où il appellera son certificat
pour l'appliquer sur le document.
- En revanche, pour travailler ensemble, deux collaborateurs
peuvent passer par un réseau privé virtuel (ou
Virtual Private Network, VPN). Ces VPN s'apparentent à
des "tunnels de chiffrement" qui, via Internet, véhiculent
des données de manière sécurisée.
Pour élaborer ces VPN, les entreprises utilisent notamment
des routeurs qui exploitent des technologies de chiffrement
asymétrique et des certificats numériques.
Autre exemple pour montrer que, sans le savoir, nous utilisons
déjà des technologies à clef publique:
SSL, le protocole massivement utilisé sur le Web pour
chiffrer des données confidentielles (typiquement des
coordonnées bancaires) représente une forme allégée
de PKI.
Dans ces projets de sécurisation
des espaces de confiance, l'on évoque souvent le SSO...
de quoi s'agit-il ?
Le SSO (Single
Sign On) consiste à donner accès à une
multitude de ressources à partir d'une seule et unique
procédure d'authentification. Sur un portail d'entreprise
par exemple, l'utilisateur s'authentifie une seule et unique
fois et l'architecture technique s'occupe ensuite de diffuser
la validité de cette authentification et les habilitations
associées aux applications concernées. A noter
que le SSO peut être pris en charge par des solutions
dédiées à cette tâche (signées
par exemple Netegrity ou encore RSA/Securant).
Pour
tous les sujets que nous venons d'aborder (les certificats,
les PKI, le SSO), existe-t-il des standards ?
On
en compte quelques-uns mais, en règle générale,
ces chantiers sont loin d'être achevés.
Pour les certificats, une norme existe connue sous le nom de
X.509. Elle en est aujourd'hui à sa troisième
version et représente un espoir de voir se normaliser
des infrastructures de certificats encore très largement
propriétaires.
Pour
les PKI, l'IETF,
l'un des grands organes de standardisation du Net, travaille
sur PKIX, qui vise à normaliser les procédures
(publication d'un certificat, horodatage d'un document signé...)
et leurs dessous techniques (méthodes de transports,
format des messages...). Un vaste chantier dont certains chapitres
sont tout juste esquissés.
Pour le SSO, l'éditeur de Netegrity a initié le
standard SAML
(pour Security Assertions Markup Language) aujourd'hui placé
sous la tutelle de l'Oasis,
un organisme de standardisation. SAML définit un vocabulaire
XML pour véhiculer les informations relatives à
l'authentification, et devrait être validé dans
l'année à venir.
|
|
|
|
|