J'ai l'impression qu'il y a un flottement dans le texte entre le one time password et l'authentification forte. Je connais mal les one time password. Je connais mieux les PKI.
Voici mes deux euro-cents sur l'authentification forte et les tokens matériels:
Question: comment garantir de la crypto forte?
-> première sous question: que veut on protéger?
Réponse: 3 grandes familles existent: le chiffrement, la signature, et l'authentification.
Ces trois familles reposent sur le mécanisme de clé privée / clé publique. Ce concept de clé privée /publiques est celui qui nous intéresse ici. Associé aux clés publiques, un certificat qui ajoute des informations comme l'adresse mail du possesseur de la clé publique, des dates de validité, etc..
La clé privée est privée et ne doit être connue que du possesseur de la clé. Le certificat (et la clé publique associée) sont publics, (ie diffusables partout)
Cette crypto est communément appelée PKI, et la PKI correspond à une mise en oeuvre de ces mécanismes. De très nombreuses RFC définissent ce qu'il faut faire pour construire une PKI. Dans le logiciel libre openssl a tout ce qu'il faut pour batir une PKI.
En gros:
-on génére une autorité (un couple de clé et certificat).
-On génére des couples clés privés/publics pour chacun de nos utilisateurs.
-Les certificats sont signés par l'autorité (comprendre authentifiés par l'autorité)
Puis, toute personne qui souhaite utiliser notre PKI doit agréer l'autorité, en gros faire confiance a cette autorité, et par la, faire confiance aux certificats signés par celle ci.
Donc un user peut récuperer un certificat quelquepart, vérifier son authenticité, puis l'utiliser.
Ca, c'est pour la théorie. Je passe les mécanismes de révocation de certificats, de mécanisme permettant l'authent, la signature et le chiffrement.
Bref.
Venons en au point qui nous intéresse, les cartes à puce (ou token USB).
Un point crucial concernant ces PKI concerne la clé privée. Si elle est diffusée, forcément, elle ne sert à rien.
Et survient un paradoxe: comment être persuadé que la clé privée ne fuite jamais dans aucun cas alors qu'il faut l'utiliser?
La solution réside dans l'utilisation d'une carte à puce. Une carte à puce est un ordinateur complet, et donc, la clé privée ne sort jamais de la carte à puce. Toutes les opérations crypto sont réalisées par la carte à puce, depuis le tirage des clés, jusqu'aux opérations de chiffrement/déchiffrement. La clé privée est donc parfaitement protégée, et la carte à puce elle même peut protéger des brute force en détruisant la clé au bout de trois tentatives de code PIN.
C'est donc génial (du point de vue crypto). Mais.
Mais tout n'est pas si évident. Et entre autre vient le point noir de la communication entre un programme local au PC et la carte à puce. Une norme de communication existe et s'appelle la norme PKCS#11. Les constructeurs de carte à puce fournissent donc un middleware (un driver, quoi) permettant de présenter une interface PKCS#11 à un programme du PC. Et ces middleware existent uniquement sous windows. Certains middleware ont existé sous linux (je pense au clés token USB rainbow ikey1000) mais sous la forme de blobs binaires, attachés à une certaine version de noyau.
Bref:
la solution serait effectivement d'implémenter:
-premièrement d'une couche PKCS#11
-deuxièmement du pilote spécifique pour une carte particulière
-troisièmement une couche applicative (un add-on pour openssl ? )
[^] # Re: Comment nous aider
Posté par octane . En réponse à la dépêche OpenToken : un projet de token d'authentification matérielle ouvert. Évalué à 4.
Voici mes deux euro-cents sur l'authentification forte et les tokens matériels:
Question: comment garantir de la crypto forte?
-> première sous question: que veut on protéger?
Réponse: 3 grandes familles existent: le chiffrement, la signature, et l'authentification.
Ces trois familles reposent sur le mécanisme de clé privée / clé publique. Ce concept de clé privée /publiques est celui qui nous intéresse ici. Associé aux clés publiques, un certificat qui ajoute des informations comme l'adresse mail du possesseur de la clé publique, des dates de validité, etc..
La clé privée est privée et ne doit être connue que du possesseur de la clé. Le certificat (et la clé publique associée) sont publics, (ie diffusables partout)
Cette crypto est communément appelée PKI, et la PKI correspond à une mise en oeuvre de ces mécanismes. De très nombreuses RFC définissent ce qu'il faut faire pour construire une PKI. Dans le logiciel libre openssl a tout ce qu'il faut pour batir une PKI.
En gros:
-on génére une autorité (un couple de clé et certificat).
-On génére des couples clés privés/publics pour chacun de nos utilisateurs.
-Les certificats sont signés par l'autorité (comprendre authentifiés par l'autorité)
Puis, toute personne qui souhaite utiliser notre PKI doit agréer l'autorité, en gros faire confiance a cette autorité, et par la, faire confiance aux certificats signés par celle ci.
Donc un user peut récuperer un certificat quelquepart, vérifier son authenticité, puis l'utiliser.
Ca, c'est pour la théorie. Je passe les mécanismes de révocation de certificats, de mécanisme permettant l'authent, la signature et le chiffrement.
Bref.
Venons en au point qui nous intéresse, les cartes à puce (ou token USB).
Un point crucial concernant ces PKI concerne la clé privée. Si elle est diffusée, forcément, elle ne sert à rien.
Et survient un paradoxe: comment être persuadé que la clé privée ne fuite jamais dans aucun cas alors qu'il faut l'utiliser?
La solution réside dans l'utilisation d'une carte à puce. Une carte à puce est un ordinateur complet, et donc, la clé privée ne sort jamais de la carte à puce. Toutes les opérations crypto sont réalisées par la carte à puce, depuis le tirage des clés, jusqu'aux opérations de chiffrement/déchiffrement. La clé privée est donc parfaitement protégée, et la carte à puce elle même peut protéger des brute force en détruisant la clé au bout de trois tentatives de code PIN.
C'est donc génial (du point de vue crypto). Mais.
Mais tout n'est pas si évident. Et entre autre vient le point noir de la communication entre un programme local au PC et la carte à puce. Une norme de communication existe et s'appelle la norme PKCS#11. Les constructeurs de carte à puce fournissent donc un middleware (un driver, quoi) permettant de présenter une interface PKCS#11 à un programme du PC. Et ces middleware existent uniquement sous windows. Certains middleware ont existé sous linux (je pense au clés token USB rainbow ikey1000) mais sous la forme de blobs binaires, attachés à une certaine version de noyau.
Bref:
la solution serait effectivement d'implémenter:
-premièrement d'une couche PKCS#11
-deuxièmement du pilote spécifique pour une carte particulière
-troisièmement une couche applicative (un add-on pour openssl ? )