Authentification Web à l'aide de certificats PKI

Je comprends assez bien l'ICP d'un point de vue conceptuel - c'est-à-dire les clés privées / clés publiques - les mathématiques derrière elles, l'utilisation du hachage et du cryptage pour signer un certificat, la signature numérique des transactions ou des documents, etc. J'ai également travaillé sur des projets où openssl Les bibliothèques C ont été utilisées avec des certificats pour sécuriser la communication et l'authentification. Je connais également très bien les outils de ligne de commande openssl.

Cependant, j'ai très peu d'expérience avec les projets basés sur le PKI sur le Web et j'essaie donc de concevoir et de coder un projet personnel pour mieux comprendre cela.

Les exigences

Ceci est le site Web d'une banque. Tous les utilisateurs d'Internet Banking sont autorisés à utiliser n'importe quel certificat délivré par quelques autorités de certification connues (verisign, Thawte, entrust, etc.). La Banque n'est pas responsable de l'obtention des certificats pour l'utilisateur. Ces certificats seront utilisés pour l'authentification sur le site Web des banques. Les plates-formes / OS, etc. ne sont toujours pas fixes.

Conception

Je me demandais quelle était la meilleure façon de faire l'authentification.

1. J'ai vu qu'Apache a un moyen d'activer le SSL bidirectionnel - dans ce cas, je pense que la navigation vers le site Web demanderait automatiquement un certificat à l'utilisateur. Mais je ne sais pas si cela suffit, car il semble que tout ce qu'il vérifie est de savoir si un certificat est signé par une autorité de certification de confiance et peut également être s'il tombe dans une liste blanche de lignes d'objet des certificats, etc. Mais cela ne suffit pas pour un dossier bancaire, car vous devez pouvoir associer un identifiant utilisateur à un certificat.

2. IIS semble avoir un moyen par lequel je peux avoir un certificat stocké pour chaque utilisateur dans Active Directory. C'est ce que j'ai compris en lisant quelques articles MSDN. Vous activez SSL bidirectionnel dans IIS, puis lorsque l'utilisateur essaie de naviguer sur le site Web, IIS enverra une demande au navigateur avec une liste des autorités de certification approuvées et le navigateur permettra à l'utilisateur de choisir un certificat approprié dans son magasin de certificats et de l'envoyer. au backend. Je suppose que IIS fera 2 choses

   • Assurez-vous que l'utilisateur dispose de la clé privée correspondant au certificat (par sous les négociations de couverture)
   • Sur la base du mappage de certificats d'utilisateurs AD, IIS signalera le nom d'utilisateur à l'application.

3. Faites l'authenticité en appelant des fonctions de chiffrement plutôt en fonction du serveur Web pour le faire.

   • Afficher un écran utilisateur où il télécharge un certificat et l'application s'assure que l'utilisateur possède la clé privée correspondant au certificat (en demandant au frontal de signer une chaîne à l'aide du certificat).
   • L'application possède une base de données dont certaines données sont stockées, ce qui permet à chaque utilisateur d'être mappé à son ID utilisateur. Cela peut être
   • le certificat entier correspondant à chaque ID utilisateur
   • le numéro de série CA et cert correspondant à chaque ID utilisateur.

Je me demandais quelle est la méthode couramment utilisée? Quelles sont les meilleures pratiques? Si je devais choisir le n ° 3, quelles sont les meilleures façons de procéder?

Quelque chose qui peut également fonctionner facilement avec les applications de smartphone sera un bonus supplémentaire.

Mise à jour

Permettez-moi de clarifier ma déclaration "coder moi-même la partie d'authentification" parce que certaines des réponses semblent indiquer qu'elle a été mal comprise - mon mal de ne pas être clair.

Cela ne signifie pas que j'écris moi-même des trucs cryptographiques. Cela signifie simplement que j'appellerai en fait des routines de chiffrement explicitement au lieu de dépendre d'IIS ou de tout autre serveur Web de le faire implicitement.

Bien que je veuille vraiment répondre question par question, je pense que je vais aborder ce sujet par sujet:

Autorisation / authentification

D'accord, tout d'abord. Pour votre exemple, vous avez besoin des deux:

• Authentification - preuve que l'utilisateur est ce qu'il prétend être. Vous avez choisi PKI, avec la preuve implicite de la clé privée comme authentification.
• Autorisation - connexion de l'utilisateur à ce qu'il est autorisé à faire. Il s'agit du point de connexion entre la connexion et l'accès aux comptes autorisés. Le mappage du certificat au compte et aux capacités d'accès au compte est l'autorisation.

Autorisation, vous avez le problème de déterminer le processus par lequel vous connectez le DN sujet de votre utilisateur à son compte bancaire. Étant donné la gravité de la transaction, vous voulez certainement avoir un processus solide pour cela, et il n'y a pas de bonne voie ici. Il faudrait consulter la banque, et probablement les avocats, pour savoir comment procéder conformément à la politique.

SSL, authentification client / serveur, preuve de clé privée

Le protocole SSL inclut toujours l'authentification du serveur, avec un paramètre facultatif supplémentaire pour l'autorisation côté client. Vous avez raison avec le n ° 1 dans la mesure où Apache propose un paramètre qui ajoute l'authentification client par PKI, et vous pouvez le provisionner avec une liste d'autorités de certification de confiance. Lors de la configuration d'une session SSL qui nécessite une authentification client via PKI - vous obtiendrez une preuve de clé privée.

L'option # 1 ou l'option # 2 fournira cela - Apache et IIS peuvent être configurés de cette façon. En ce qui concerne les meilleures pratiques, je prendrais l'une ou l'autre de vos propres solutions. # 3 se rapproche dangereusement de la règle "n'écrivez pas votre propre crypto". En supposant que vous pouvez lier votre transaction à la présence d'une session SSL authentifiée, il n'y a aucune raison de lancer la vôtre.

Aussi - dans l'option # 1 ou l'option # 2, il existe un moyen de mettre la main sur l'ensemble du certificat, et à partir de là, sur n'importe quelle partie du certificat. Généralement, le DN du sujet et / ou le numéro de série du certificat sont utilisés pour déterminer l'identité de l'utilisateur à des fins d'autorisation.

En termes d '"usage courant" - tous les principaux serveurs Web sont assez courants. IIS, Apache, Tomcat et bien d'autres peuvent être configurés avec SSL d'authentification client. La décision à partir de là est largement basée sur la mise en œuvre globale. Les principaux serveurs Web ont tous eu des moyens d'accéder au certificat fourni dans la session SSL, ce dont vous avez besoin pour une vérification plus détaillée.

Modules complémentaires de vérification de certificats

Au minimum, vous devrez:

• configurer une session SSL
• extraire le certificat (la plupart des serveurs Web vérifieront la signature du certificat et la preuve de la clé privée)
• vérifier la date de validité du certificat (pas donné avec un serveur Web)
• effectuer la vérification d'autorisation pour les comptes auxquels ce certificat peut accéder

Compte tenu des enjeux bancaires élevés, vous pouvez également vérifier l'état de révocation du certificat - si la clé privée de l'utilisateur est perdue ou volée, son certificat doit être révoqué.

IIS peut avoir les crochets pour une vérification OCSP ou CRL - il a tendance à être un type de système plus complet (tenant la main!), Mais je ne me souviens pas du haut de ma tête. Je ne me souviens pas non plus si cela va vous forcer à utiliser des produits Microsoft pour cela. Pour Apache, vous devrez presque certainement coder ou ajouter une vérification OCSP / CRL. Je crois qu'il a des crochets lors de l'établissement de la session SSL - généralement cette vérification est effectuée une fois lorsque la session SSL est configurée.

Autorisation

Sur # 1 vs # 2 - vous avez raison, IIS a des fonctionnalités intégrées qui lieront le certificat fourni dans la session SSL à un référentiel AD. C'est l'un des cas où Microsoft fait un effort supplémentaire pour faciliter l'achat et l'utilisation de plus de ses produits. :) Il existe des nuances sur la façon dont IIS se lie à AD qui dépassent le cadre de cette question et au-delà de mes souvenirs immédiats. J'ai fait des trucs assez fous avec IIS et AD, et ma pensée générale est que pendant que vous faites quelque chose d'aussi simple que d'extraire le nom d'utilisateur basé sur le certificat d'un référentiel AD - vous êtes probablement bien. C'est lorsque vous rencontrez des problèmes plus complexes de stockage de données, de recherches AD étranges et de choses particulièrement folles (mais légitimes) avec PKI, vous '

Avec IIS, même toujours - vous aurez besoin d'ajouter quelque chose à votre structure AD, ou ailleurs, en liant le nom d'utilisateur au compte bancaire. Généralement, dans le secteur bancaire, un utilisateur possède plusieurs comptes. Et 2 utilisateurs peuvent avoir un compte conjoint, il s'agit donc d'une relation plusieurs à plusieurs.

Pour # 1 - oui, vous devez écrire votre propre recherche. Vous devez coder: - une base de données ou une hiérarchie LDAP reliant le certificat à l'utilisateur et l'utilisateur aux comptes bancaires de l'utilisateur. La partie unique garantie d'un certificat est le numéro de série + le DN de l'émetteur. Souvent, le DN du sujet fonctionne, mais ce n'est pas garanti dans tous les systèmes PKI.

C'est généralement ainsi que les développeurs utilisant PKI pour l'authentification haut de gamme avec Apache le font. Ayant travaillé dans un certain nombre de ces systèmes, je n'ai pas encore rencontré de cas de réutilisation des autorisations facile, donc je ne le vois jamais vraiment comme un énorme inconvénient - je vais devoir avoir quelque chose de spécialisé de toute façon, car les rôles / privilèges sont jamais facile.

Cela ressemble à un mélange de # 1 et # 3 - mon conseil fort serait - utilisez les capacités natives de n'importe quelle application / serveur Web que vous utilisez pour générer la session SSL. Cela permettra au navigateur de configurer le serveur avec la requête de certificat de manière standard À partir de là, avec Apache, vous devrez utiliser votre propre système d'autorisation. IIS fournira à Microsoft une idée de la façon dont cela devrait fonctionner pour vous.

Gotchas connus

Faites un tas de tests de navigateur. D'année en année, de navigateur en navigateur, je trouve des pièges avec la gestion des sessions SSL. Le chaînage correct de la session SSL à la série de demandes de pages Web et le contrôle de la déconnexion sont les principaux sujets de préoccupation. Et cela a beaucoup à voir avec le serveur et le logiciel de navigation. SSL est suffisamment stable pour que lorsqu'il fonctionne, il fonctionne généralement, bien qu'il puisse y avoir des problèmes IE contre tout le monde.

En particulier, la dernière fois que j'ai fait cela, la question du codage forcé et du temps de session était un gros problème.

Téléphones intelligents

Bien. La chance. est à peu près tout ce que je peux dire. Je ne suis pas du tout un développeur d'applications mobiles, mais mon impression jusqu'à présent est que dans un téléphone intelligent moyen, la gestion des certificats PKI est inférieure ou inexistante.

J'aimerais tellement qu'on me prouve le contraire.

Les certificats personnels fonctionnent bien pour le renouvellement périodique des certificats (qui a un processus assez solide derrière lui) et peuvent être implémentés comme une authentification "sans mot de passe" que les clients aiment

mais là où ça échoue c'est

• Le coût par certificat
• compatibilité avec les navigateurs modernes
• les utilisateurs finaux extraient des certificats et stockent des clés privées de manière non sécurisée

sachez que les certificats personnels modernes avec signature sha-2 ne fonctionnent pas avec Safari sur iPad et de nombreux navigateurs modernes. En effet, les certificats personnels n'ont jamais vraiment décollé comme le pensaient les organisations d'autorité de certification. L'émission de 30 000 certificats (ce que nous faisons) coûte environ le même par certificat que certains types de jetons matériels.

Votre stratégie pour permettre aux clients de trouver leurs propres certificats n'est pas vraiment valable. Il est difficile de trouver des fournisseurs de certificats personnels de nos jours et ils sont assez chers - vous devez vous assurer que l'analyse de rentabilisation fonctionne, sinon les clients n'achèteront tout simplement pas.

D'accord, il se passe beaucoup de choses ici. Tout d'abord, l'authentification du certificat client est inutile si elle n'est pas prise en charge sur le point de terminaison. Nous avons donc un excellent article d'Intrepidus couvrant les bases de l'authentification client pour les applications de smartphone .

Ensuite, laissez-moi vous suggérer fortement de ne pas coder votre propre routine d'authentification. Il y a beaucoup de grandes bibliothèques approuvées qui gèrent cela. Vous vous épargnerez des bogues de fonctionnalité et de sécurité en exécutant avec une bibliothèque mature pour l'authentification. L'utilisation d'une bibliothèque mature approuvée pour cela serait certainement la meilleure pratique.

La meilleure pratique suivante consiste à utiliser un répertoire pour gérer votre client: le mappage de certificats. Vous examinerez donc AD ou LDAP. Comme vous l'avez mentionné, Windows et IIS rendent cela assez transparent pour vous. IIS.net a un bon aperçu de la configuration du mappage de certificats sous IIS .

Si vous roulez avec Apache, ce n'est pas aussi facile à sortir de la boîte. Il semble que mod_authz_ldap effectue le mappage des certificats client, mais je n'ai pas personnellement travaillé avec.

Cela nous amène à la logistique de la mise en œuvre de quelque chose comme ça. Vous ne signez pas les certificats des utilisateurs, vous avez donc besoin d'un processus à toute épreuve pour qu'un utilisateur soumette son certificat et que votre application le publie dans l'annuaire. Je voudrais voir deux facteurs pour cela, avec un mot de passe authentifié et un message texte ou appelez un numéro de confiance. J'enverrais un e-mail à l'utilisateur pour lui faire savoir qu'un certificat a été ajouté à son compte. Je laisserais un utilisateur supprimer le mappage de certificat utilisateur via sa page de gestion de compte dans l'application.

J'examinerais ce que Google et Facebook font pour définir des cookies pour les appareils de confiance afin d'éviter deux facteurs. J'aurais de nouveaux appareils avec deux facteurs d'authentification avant d'autoriser uniquement l'authentification par certificat.

Je penserais également à la façon de gérer les certificats utilisateur révoqués. Cela signifie vérifier une liste de révocation de certificats externe (CRL). Que faire si un certificat client n'a pas de point de distribution CRL défini? Vérifiez-vous la liste de révocation de certificats chaque fois que l'utilisateur se connecte, ou sur une base planifiée dans le cadre d'un travail, car il n'y aura probablement qu'une poignée de listes de révocation de certificats en cours d'utilisation?

Vraiment, cela se résume à: comment puis-je savoir que je peux faire confiance que les certificats des utilisateurs n'ont pas été compromis, et comment puis-je faire confiance pour pouvoir mapper le certificat X à l'utilisateur Y.