Avantages des certificats clients pour l'authentification client?
Je ne suis pas un expert en sécurité, veuillez donc simplement demander dans un commentaire si je n'ai pas suffisamment clarifié ma question pour y répondre.
Le scénario
Nous avons un serveur exécutant les services WCF et un certain nombre de clients se connectant. Ces clients sont en fait des PC Linux que nous construisons. Nous devons établir des communications sécurisées entre notre serveur et nos clients (encore une fois, nous les construisons et les déployons sur les sites des clients).
Client faisant confiance au serveur
Nous allons implémenter cela en permettant au client d'établir une connexion de confiance avec le serveur via la mise en œuvre des communications SSL.
Serveur faisant confiance au client
Nous avons maintenant la tâche d'authentifier le client. De toute évidence, cela se fait en conservant une sorte d'informations d'identification sur le client. Une fois que le client est connecté, il peut envoyer les informations d'identification au serveur et le serveur peut les valider.
Une option pour ces informations d'identification est de stocker une sorte de Guid ou autre identifiant/mot de passe généré par l'application basée sur WCF. Lors de la réception des informations d'identification, le service WCF effectue une recherche dans la base de données et vérifie qu'elles sont correctes.
Une autre option consiste à utiliser les services de certificats pour créer des certificats clients qui sont copiés sur le PC client avant d'être envoyés. Après avoir établi la connexion sécurisée, le client envoie le certificat au serveur qui authentifie le certificat avec les services de certificats.
Les questions
Quels sont les avantages de l'utilisation d'un certificat pour authentifier le client par rapport à un nom d'utilisateur/guid? Quels sont ses inconvénients?
Veuillez considérer:
- Sécurité
- Complexité de la mise en œuvre
- Complexité de la programmation Intégration avec l'application. Cela inclut le flux de travail de création du jeton d'authentification, l'association des métadonnées appropriées (autorisation/association), la gestion de l'authentification, comme la désactivation de l'accès, etc.
Le déploiement de certificats clients pourrait convenir ici. Les avantages de l'utilisation d'un certificat sur un nom d'utilisateur sont assez simples. Tout le monde peut saisir un nom d'utilisateur à partir de n'importe quel appareil client. Si vous utilisez une combinaison de nom d'utilisateur avec GUID, la "sécurité" ou l'assurance que le client se connecte à partir d'un appareil client connu/autorisé dépend de la force et de l'unicité du GUID. S'il existe un moyen de cloner ou d'usurper le GUID (les adresses mac peuvent être usurpées assez facilement), le niveau d'assurance diminuerait.
Les certificats clients peuvent être déployés sur les clients, avec ou sans vérification de validité (en dehors de la date de validité, cn, ski/aki, empreinte digitale, etc.). Les mécanismes de vérification de validité à la demande tels que ocsp nécessiteraient la vérification de l'application serveur avec un serveur ocsp chaque fois que le client se connecte/tente d'authentifier. Mais à partir de la description, je n'ai pas lu que la vérification de la validité est aussi importante que la possibilité de lier le certificat à l'appareil client.
Un détail important des certificats clients (certificats en général) est qu'ils peuvent être exportés et que la plupart des implémentations ne bloquent pas la portabilité du certificat. Peu importe si ou comment les certificats client seront stockés, sans mesures appropriées, le certificat peut être facilement copié d'un appareil à l'autre. Certaines implémentations stockent le certificat sur le système de fichiers (les fichiers qui se terminent par .cer, .der, .key, .crt indiquent généralement que les certificats sont stockés dans le système de fichiers). Des implémentations plus strictes (dépendant de l'application) peuvent stocker les certificats et les clés dans un magasin de clés (c.-à-d. Java magasin de clés). Le magasin de clés peut ajouter une protection supplémentaire, comme s'assurer que la clé privée n'est pas exportable. Cependant, le l'assurance que la clé n'a pas été exportée est aussi solide que le magasin de clés lui-même. Les magasins de clés matérielles (c.-à-d. cartes à puce, usb hsm, ironkey, etc.) offrent une assurance beaucoup plus forte que la clé privée n'est pas exportable que les magasins de clés de logiciel.
BTW, le point ci-dessus affecte également les clés du serveur. La plupart des implémentations stockent la clé privée dans un magasin de clés logicielles et sont généralement marquées comme exportables. De plus, la clé privée n'est généralement pas protégée par un mot de passe, donc toute personne ayant accès au serveur peut repartir avec la clé privée. Si un certificat peut être copié, il n'offre pas de non-répudiation.
Pour répondre à votre question, s'il existe un bon moyen d'exploiter une sorte d'ID matériel (GUID, numéro de série, certificat stocké dans HSM, etc.), cela fournira probablement plus d'assurance que l'utilisation d'un ID basé sur logiciel (certificats client inclus) . L'utilisation de certificats client avec une protection par mot de passe activée pour l'accès à la clé privée fournit une validation un peu plus forte, car non seulement un client doit avoir accès à la clé privée, mais également au mot de passe pour l'utiliser.
Si vous décidez d'utiliser des certificats clients, vous devrez alors créer ou utiliser une infrastructure PKI existante. Des fournisseurs comme Codomo, Entrust, Symantec (anciennement vrsn, thawte et geotrust), Godaddy et bien d'autres proposent des infrastructures publiques et privées à utiliser. Cependant, le coût de mise en œuvre d'un certificat client basé sur logiciel sera probablement plus élevé que l'utilisation d'un identifiant matériel basé sur logiciel ou peut-être même d'un identifiant unique basé sur matériel.
Si quoi que ce soit, déterminez le niveau d'assurance que vous souhaitez avoir et décidez si le logiciel, le logiciel + le mot de passe ou le matériel est suffisant.
Avec l'authentification par certificat client, le secret (la clé privée) ne quitte jamais le client et ne va pas au serveur. Que vous fassiez confiance au serveur ou non (vous devriez tout de même le vérifier de toute façon), votre clé privée ne sera pas divulguée. C'est un avantage par rapport à l'authentification traditionnelle basée sur un formulaire ou HTTP Basic.
Vous pouvez même utiliser des jetons/cartes à puce cryptographiques matériels conçus de telle manière que la clé privée ne quitte jamais le jeton (les signatures impliquées dans la négociation TLS se produisent à bord).
Si vous utilisez des certificats clients dans le contexte d'une infrastructure à clé publique (le plus probable), vous pouvez également profiter des avantages offerts par l'ICP. Ceci est surtout utile pour les grandes structures, mais vous pouvez:
Reconnaissez l'identité des utilisateurs que vous n'aviez jamais enregistrés auparavant.
C'est à cela que servent les autorités de certification. Si vous faites confiance à l'autorité de certification, vous faites confiance au certificat qu'elle émet. Si des utilisateurs inconnus se connectent sans compte préexistant à votre système et s'ils présentent des certificats auxquels vous faites confiance, vous serez en mesure de reconnaître leur identité, comme l'atteste l'autorité de certification. Vous voudrez peut-être ou non obtenir plus de détails de l'utilisateur, mais l'identité principale aura été affirmée auprès de l'AC et y aura laissé une trace administrative.
La même identité affirmée par le certificat peut être utilisée sur plusieurs sites Web indépendants (à condition qu'ils fassent confiance à la même autorité de certification), éventuellement utilisée comme une forme d'authentification unique.
Un certificat compromis peut être révoqué directement par l'AC.
Via l'autorité de certification, vous dissociez le problème de la preuve de l'identité de l'utilisateur de la fourniture du service lui-même. D'autres méthodes comme OpenID atteignent également cet objectif, mais ne fournissent guère le même niveau d'assurance que ce que les autorités de certification peuvent faire (à condition que les autorités de certification fassent leur travail correctement). Le niveau d'assurance variera en fonction de la qualité de l'AC.
Un avantage avec cela est que vous pouvez réémettre un nouveau certificat pour le même utilisateur avec des clés différentes (si le certificat précédent a expiré ou si la clé privée a été compromise) et conserver le même identifiant (Objet) sur tous les systèmes qui approuvent cette CALIFORNIE.
(Vous pouvez également utiliser des certificats clients en dehors du contexte d'une PKI, mais vous devez définir vos propres règles de confiance, ce qui peut être assez fastidieux.)
Les certificats clients peuvent également être utilisés indépendamment du protocole exécuté au-dessus de SSL/TLS. Vous pouvez même les utiliser pour S/MIME par exemple, le cas échéant.
Un autre avantage est que, comme l'authentification ne se produit pas au niveau HTTP, elle est effectivement sans état, si des choses comme le style architectural REST vous importent).
Certains services Web peuvent également l'utiliser pour la sécurité au niveau des messages, laissant ainsi éventuellement une piste d'audit pour la non-répudiation de certains messages si nécessaire.
Le principal inconvénient est que vous devrez éduquer vos utilisateurs aux concepts de base de la cryptographie à clé publique. Ceci est particulièrement important si vous n'utilisez pas de jetons matériels (mais conservez simplement les certificats et la clé privée dans le logiciel de l'utilisateur).
Contrairement aux mots de passe, les utilisateurs ne se souviendront pas de la clé privée/cert. Ils devront utiliser une machine sur laquelle le certificat a été installé (ou là où il y a un lecteur de carte approprié pour les solutions matérielles). Pour couper les coins, certains peuvent être tentés de ne pas prendre soin de leurs clés privées aussi soigneusement qu'ils le devraient (ils sont normalement protégés par mot de passe eux-mêmes).
En expliquant, la notion de "certificat" peut prêter à confusion. Même les experts raccourcissent parfois les peines. Si vous dites "utilisez votre certificat pour vous connecter", ce que vous voulez dire en réalité, c'est "utilisez la clé privée et votre certificat pour vous connecter": la clé privée est impliquée dans cette expression. En revanche, si quelqu'un vous dit "envoyez-moi votre certificat", vous ne devriez pas utiliser votre clé privée. Si vous recherchez de la documentation, vous trouverez un certain nombre de références aux fichiers PKCS # 12 (
.p12ou.pfx) et les fichiers de certificats PEM (.pemou.crt, généralement). En règle générale, le premier contient la clé privée tandis que le second ne le fait pas (bien qu'il puisse également le faire). Toutes ces notions dérouteront les utilisateurs à moins qu'ils ne sachent ce qu'ils font.Les interfaces utilisateur du navigateur pour les certificats clients sont généralement assez médiocres. Du point de vue de l'interface utilisateur, il est assez difficile de se déconnecter d'un site Web sur lequel vous vous êtes authentifié avec un certificat client par exemple (comme HTTP Basic). (Cela rend la protection CSRF encore plus importante.) Si vos clients sont des "machines" et non des utilisateurs via un navigateur, ce n'est pas vraiment un problème.
En termes d'infrastructure, si vous n'êtes pas disposé à utiliser les services d'une autorité de certification commerciale pour vos certificats clients, vous devrez déployer votre propre autorité de certification. Notez que l'autorité de certification utilisée pour authentifier les clients peut être indépendante de l'autorité de certification utilisée pour authentifier le serveur. Vous pouvez exécuter un site Web avec un certificat émis par une autorité de certification bien connue, mais lui faire confiance pour les certificats clients de votre propre autorité de certification. Il existe différents outils pour la gestion des CA, y compris ceux open source . Certains peuvent même générer une clé dans le navigateur, de sorte que la clé privée est prête dans le navigateur (l'inconvénient est que l'utilisateur doit réutiliser le même navigateur pour importer le certificat une fois qu'il est émis).
La configuration des serveurs nécessite une certaine compréhension de ce que les certificats (certificats CA, certificat de serveur), mais ce n'est pas vraiment si compliqué. La plupart des serveurs prennent en charge cette méthode d'une manière ou d'une autre.
Les certificats clients vous fournissent uniquement une authentification. Vous devrez peut-être encore obtenir d'autres attributs (par exemple à partir de LDAP ou d'une base de données par rapport aux sujets des certificats). Vous aurez certainement besoin d'avoir une logique d'autorisation en plus de cela, comme ce serait le cas pour tout autre système d'authentification. Il est typique de mapper un DN de sujet à un identifiant local dans votre système.
(Il existe des utilisations plus avancées où vous pouvez déléguer l'authentification à l'aide de certificats proxy ou transmettre des jetons d'autorisation via des certificats d'attribut, mais ceux-ci sont plus inhabituels et ne sont pas acceptés par toutes les piles de logiciels.)