FR2862827A1 - Procede de gestion de donnees de securite - Google Patents

Abstract

Afin de rendre le passage par un serveur d'authentification unique incontournable on enregistre dans un annuaire des données de sécurité, permettant le déverrouillage d'applications ou de données, en chiffrant ces données de sécurité. La clé utilisée pour chiffrer ces données est elle aussi enregistrée dans l'annuaire. Cette clé est enregistrée en étant chiffrée d'une part par une clé ne dépendant que du serveur d'authentification, d'autre part par une clé ne dépendant que de l'utilisateur. Pour déverrouiller une application, il faut donc avoir ces deux dernière clés. Cela revient à obliger l'utilisateur à passer par le serveur pour déverrouiller une application.

Description

Procédé de gestion de données de sécurité

La présente invention a pour objet un procédé de gestion de données de sécurité. Le domaine de l'invention est celui de la gestion informatique des données de sécurité. Le domaine de l'invention est aussi celui de l'authentification unique aussi connu sous le nom de SSO pour Single Sign On.

Un but de l'invention est l'harmonisation des mécanismes de contrôle d'accès à plusieurs ressources possédant par ailleurs chacune leur propre 10 mécanisme de contrôle d'accès.

Un but de l'invention est de permettre la mise en place d'une solution SSO, c'est à dire d'authentification unique.

Un autre but de l'invention est de rendre le recours à l'authentification unique incontournable.

Un autre but de l'invention est de permettre l'application d'une politique d'accès à des ressources, cette politique devenant incontournable.

Dans l'état de la technique on connaît des applications SSO qui permettent à un utilisateur de ne s'authentifier qu'une fois et d'accéder après à toutes les ressources applicatives de l'entreprise. Cependant les mécanismes SSO de l'état de la technique ne permettent pas de gérer une politique d'accès à ces ressources. Une politique d'accès est, par exemple, la possibilité de n'accéder à une ressource qu'en fonction d'une plage horaire, d'un identifiant utilisateur, d'un point d'accès... . En effet les applications SSO de l'état de la technique ne sont au final que des commodités proposées aux utilisateurs. Une telle commodité consiste, en particulier, à rendre accessible de manière transparente tous les mots de passe d'un utilisateur via la saisie d'un seul mot de passe. Dans les faits, une application SSO automatise la saisie des mots de passe une fois qu'un utilisateur s'est authentifié auprès d'elle. En cas de défaillance apparente de l'application de SSO, il demeure toujours possible pour l'utilisateur de rechercher lui-même le mot de passe dont il a besoin et de le saisir manuellement pour lancer l'application qu'il souhaite utiliser.

Cette possibilité rend vaine toute tentative de centraliser, et surtout de rendre incontournable, l'application d'une politique d'accès aux ressources.

Dans l'invention on résout ces problèmes en mettant en oeuvre des moyens d'enregistrement des mots de passe, et plus généralement de données dîtes de sécurité, qui impose à un utilisateur souhaitant y accéder d'avoir recours à un serveur d'authentification. Ces moyens d'enregistrement sont d'autre part tels, qu'il est impossible au serveur d'accéder aux données de sécurités enregistrées sans au moins une intervention de l'utilisateur concerné par ces données. Dans l'invention, une donnée de sécurité est chiffrée par une clé Kssoperso dépendant de l'utilisateur. Une donnée de sécurité est aussi appelée un secret. Cette clé Kssoperso est enregistrée dans un annuaire. Cette clé Kssoperso est doublement chiffrée. D'une part Kssoperso est chiffrée par une clé Kserveuru gérée par le serveur d'authentification. D'autre part le résultat de ce chiffrement est chiffré par une clé Kupub dépendant de l'utilisateur. Ainsi l'utilisateur n'a jamais connaissance de Kssoperso, donc ne peut jamais accéder directement à la donnée de sécurité. Ainsi encore, le serveur d'authentification en peut pas avoir accès à Kssoperso sans une intervention de l'utilisateur qui est le seul à connaître Kupriv permettant de déchiffrer une donnée chiffrée avec Kupub.

L'invention fournit donc un mécanisme de contrôle d'accès supplémentaire rendant tous les autres mécanismes de contrôle d'accès tranparent.

Dans la mesure où le serveur est incontournable, il lui est donc facile d'appliquer une politique d'accès qui elle aussi devient incontournable.

Dans la mesure ou l'intervention de l'utilisateur est nécessaire, même une personne prenant le contrôle du serveur d'authentification ne pourrait pas accéder aux ressources de l'entreprise.

L'invention a donc pour objet un procédé de gestion de données de sécurité caractérisé en ce qu'on structure un annuaire de telle manière que: - des données de sécurité d'un utilisateur sont enregistrées chiffrées dans l'annuaire, chaque donnée de sécurité étant chiffrée grâce à une clé Kssoperso dépendant d'un utilisateur, - la clé Kssoperso est enregistrée chiffrée dans l'annuaire, la clé Kssoperso étant chiffrée par une clé Kserveuru dépendant de l'utilisateur, le résultat de ce chiffrement étant lui-même chiffré par un procédé de chiffrement asymétrique utilisant une clé publique Kupub dépendant elle aussi de l'utilisateur, - la clé Kserveuru dépendant de l'utilisateur est enregistrée chiffrée dans l'annuaire en étant chiffrée par un procédé utilisant une clé Kserveursecret, - la clé Kserveursecret est connue des seuls serveurs habilités à fournir une donnée de sécurité à l'utilisateur.

Avantageusement l'invention est aussi caractérisée en ce que: - un utilisateur obtient une paire de clé (Kupriv, Kupub) asymétriques en en fournissant une donnée de sécurité à terminal client connecté au serveur d'authentification, - le client s'authentifie auprès d'un serveur d'authentification unique en fonction d'information fournie par l'utilisateur, - le client émet une requête, vers le serveur d'authentification, pour obtenir une donnée de sécurité, - le serveur d'authentification consulte l'annuaire en fonction de la requête du client et obtient une clé Kssoperso chiffrée, - le serveur d'authentification transmet la clé Kssoperso chiffrée obtenue au client, - le client utilise Kupriv pour déchiffrer la clé Kssoperso chiffrée transmise, et transmet le résultat du déchiffrement, Kint, au serveur d'authentification, - le serveur d'authentification consulte l'annuaire en fonction de la requête du client pour obtenir une clé Kserveuru chiffrée, - le serveur d'authentification utilise la clé Kserveursecret pour déchiffrer Kserveuru - le serveur d'authentification utilise Kserveuru pour obtenir Kssoperso à partir de Kint, - le serveur d'authentification consulte l'annuaire en fonction de la requête du client pour obtenir une donnée de sécurité chiffrée, - le serveur d'authentification utilise Kssoperso pour déchiffrer la donnée de sécurité, - le serveur d'authentification transmet au client la donnée de sécurité déchiffrée.

Avantageusement l'invention est aussi caractérisée en ce que: - une donnée de sécurité est enregistrée dans l'annuaire en étant chiffrée par une clé Kssopersorec dépendant de l'utilisateur, - la clé Kssopersorec est enregistrée dans l'annuaire, la clé Kssopersorec étant chiffrée par la clé Kserveuru, le résultat de ce chiffrement étant lui-même chiffré par un procédé de chiffrement asymétrique utilisant une clé publique Krecpub dépendant d'un deuxième utilisateur habilité à effectuer une récupération de données de sécurité chiffrées avec la clé Kssopersorec, - une clé Krecpriv, de la biclé (Krecpriv, Krecpub) est enregistrée dans l'annuaire en étant chiffrée par la clé Kserveursecret, puis par une clé Kurec d'un utilisateur de récupération.

Avantageusement l'invention est aussi caractérisée en ce qu'une 10 donnée de sécurité enregistrée et chiffrée avec la clé Kssopersorec ne l'est pas avec la clé Kssoperso.

Avantageusement l'invention est aussi caractérisée en ce que le serveur d'authentification répond à une requête du terminal client en fonction d'une politique enregistrée dans l'annuaire.

Avantageusement l'invention est aussi caractérisée en ce que la donnée de sécurité transmise par le serveur d'authentification au client est chiffrée en utilisant la clé Kupub.

Avantageusement l'invention est aussi caractérisée en ce que la donnée de sécurité transmise par le serveur d'authentification au client est 20 transmise (315) via un canal sécurisé.

L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles ci sont présentées à titre indicatif et nullement limitatif de l'invention. Les figures montrent: Figure 1: une illustration d'un contexte matériel de mise en oeuvre du procédé selon l'invention.

Figure 2: une illustration d'une structure d'un annuaire utilisé pour le mise en oeuvre du procédé selon l'invention.

Figure 3: une illustration d'étapes du procédé selon l'invention.

La figure 1 montre, de manière schématique, un réseau d'entreprise.

En particulier la figure 1 montre un serveur 101 d'annuaire comportant une base de données aussi appelé ici un annuaire, dans lequel sont enregistrées des données de sécurité à un format compatible avec l'invention. La figure 1 montre aussi un serveur 102 SSO chargé de l'authentification unique, un serveur 103 dit applicatif, et une station 104 de travail ou terminal 104. Les éléments 101 à 104 sont interconnectés via un réseau 105 et sont donc en mesure de communiquer les uns avec les autres. Ces éléments sont donc en mesure d'échanger des messages. De manière implicite, chaque message comporte au moins une adresse de destinataire, et une adresse d'origine.

A la station 104 sont aussi connectées des périphériques d'entrées sorties comme un écran 107, un clavier 108, une souris 109, un lecteur 110 de carte à puce, et I ou un lecteur biométrique. La liste n'est pas exhaustive.

Dans ce document on prête des actions à un des appareils, serveur, station ou autre. Dans la pratique ces actions, pour un appareil donné, sont réalisées par un microprocesseur de cet appareil, ledit microprocesseur étant commandé par des codes instruction enregistrés dans une mémoire de l'appareil.

Dans la pratique le serveur d'annuaire met en oeuvre un service d'annuaire, que l'on peut aussi appeler une application d'annuaire. Il s'agit en fait d'une base de données que l'on peut interroger selon un langage particulier. Dans un mode de réalisation préféré, il s'agit du protocole LDAP (Light Weight Directory Access Protocol, pour protocole léger d'accès à un répertoire). Dans la pratique il pourrait s'agir d'un autre langage comme SQL (Structured Query Language, pour langage de requête structuré) par exemple. Ce service peut très bien être exécuté par une autre machine du réseau de l'entreprise, comme, par exemple, le serveur 102, ou le serveur 103.

Le serveur 103 est un serveur permettant la mise en oeuvre d'applications, ou le partage de données, propre au fonctionnement de l'entreprise. Ces applications, ou ces données, ne sont accessibles que si l'on dispose des droits adéquats. Ces droits sont matérialisés par une paire identifiant l mot de passe, ou simplement par un mot de passe.

Le serveur 103 comporte donc une mémoire de stockage de masse sur laquelle sont enregistrés une basse de données et / ou des applications.

La figure 2 montre un annuaire 201 selon l'invention. L'annuaire 201 comporte plusieurs enregistrements tel que l'enregistrement 202. L'enregistrement 202 est identifié par un champ 203 identifiant utilisateur. Ce champ 203 permet d'associer un enregistrement de l'annuaire 201 à un utilisateur du réseau de l'entreprise. Dans la pratique, l'annuaire 201 comporte autant d'enregistrements que d'utilisateurs référencés dans l'annuaire.

L'enregistrement 202 comporte d'autre part plusieurs tables, dont une table 204 des clés, une table 205 de données de sécurité, et une table 206 de politiques.

La table 205 comporte au moins 3 colonnes. Une première colonne 205a comporte des données de sécurité chiffrées par des clés de type Ksso. Une clé de type Ksso est une clé utilisée par un algorithme symétrique pour réaliser un chiffrement ou un déchiffrement. Une clé de type Ksso est utilisée pour chiffrer, et déchiffrer des données de sécurité. Chaque ligne de la table 205 correspond à une donnée de sécurité, par exemple un mot de passe permettant d'accéder à une application et ou à des données. Une donnée de sécurité peut aussi être un numéro de compte en banque, une donnée permettant le déverrouillage d'applications ou de données, un certificat de type X509 et sa clé privée, et plus généralement toute donnée qu'un utilisateur ne souhaite pas voir divulguer. Chaque utilisateur a sa clé, ou ses clés, Ksso personnelles. Ainsi La figure 2 montre que la table 205 comporte une ligne pour une donnée de sécurité Dl chiffrée par une clé Kssoperso, une ligne pour une donnée de sécurité D2 chiffrée par la clé Kssoperso, et une ligne pour une donnée D3 chiffrée par une clé Kssopersorec.

On note ici qu'une même donnée de sécurité, ou des données de sécurité différentes, peuvent être chiffrées, pour un même utilisateur, avec plusieurs clés de type Ksso. Comme il sera discuté ultérieurement, les clés de type Ksso sont enregistrées chiffrées. II est tout à fait possible qu'un utilisateur égare les moyens lui permettant de déchiffrer les clés de type Ksso, et donc d'accéder à ses données de sécurité. Dans ce cas il existe une clé de type Ksso récupérable, ici Kssopersorec, qui une fois récupérée permet à son tour à l'utilisateur de récupérer les données de sécurité qui ont été chiffrées avec Kssopersorec. Le choix des données de sécurité chiffrées avec une clé de type Ksso récupérable est laissé à l'utilisateur. C'est donc l'utilisateur qui choisit de prendre le risque de se retrouver sans moyen d'accéder à ses données de sécurité. Une clé de type Ksso est dite récupérable car elle est aussi enregistré chiffré avec des moyens autres que ceux de l'utilisateur titulaire de la clé de type Ksso.

Dans une variante préféré une donnée de sécurité n'est chiffré qu'avec une seule clé de type Ksso. Ainsi une donnée de sécurité est soit 35 récupérable, soit elle ne l'est pas.

Une deuxième colonne 205b de la table 205 permet d'associer à chaque donnée de sécurité de la table 205 une ou plusieurs applications dont l'utilisation est liée à la donnée de sécurité. Plus généralement cette deuxième colonne permet d'accéder à une donnée de sécurité via un identifiant de cette donnée de sécurité. Dans une variante cette deuxième colonne n'existe pas, et les données de sécurité sont accédées par un index étant un numéro de ligne.

Une troisième colonne 205c de la table 205 permet d'associer à chaque donnée de sécurité de la table 205 au moins une ligne de la table 204. Cette colonne permet en fait d'associer une donnée de sécurité à une clé de type Ksso.

La table 204 comporte au moins 2 colonnes. Une colonne 204a permettant d'enregistrer des clés chiffrées, et une colonne 204b permettant d'enregistrer un identifiant de clé. Comme pour la table 205, la deuxième colonne est facultative.

Dans la table 204, chaque ligne correspond à une clé, cette clé étant enregistrée chiffrée. Dans ce document, la notation k(x) signifie que la donnée x a été chiffrée avec un algorithme de chiffrement en utilisant k comme clé. La figure 2 montre que la clé Kssoperso est enregistrée dans la table 204 en étant chiffrée comme suit: Kupub(Kserveuru(Kssoperso)).

Où Kupub est une clé publique d'une biclé associée à l'utilisateur identifié par le champ 203. Une biclé est utilisée avec un algorithme de chiffrement asymétrique. Lorsque que ce n'est pas précisé, on considère que l'algorithme de chiffrement utilisé est symétrique.

Où Kserveuru est une clé associée à l'utilisateur identifié par le champ 203, cette association étant réalisée par le serveur 102 d'authentification.

La clé Kssopersorec est aussi enregistrée dans la table 204 en étant chiffrée comme suit: Kupub(Kserveuru(Kssopersorec)), Krecl pub(Kserveuru(Kssopersorec)).

Où Krec1 pub est la clé publique d'une biclé associée à un groupe d'utilisateurs récupérateurs habilités à récupérer les clés de type Ksso.

La clé Kserveuru est enregistrée dans la table 204 en étant chiffrée par une clé Kserveursecret. La clé Kserveursecret est enregistrée dans une mémoire 106 du serveur 102 d'authentification. Le serveur 102 est le seul à avoir accès à la clé Kserveursecret.

L'enregistrement 202 comporte aussi une table 206 permettant l'enregistrement de politiques d'accès aux données de sécurité. Une politique est une règle autorisant ou refusant l'accès à une donnée en fonctions de critères. Ces critères sont, par exemple, une plage horaire, un point d'origine de la requête (adresse IP ou autre), une application... la liste n'est pas exhaustive.

L'annuaire 201 comporte aussi un enregistrement 207 dit racine.

L'enregistrement est identifié dans l'annuaire 201 par un champ 208. L'enregistrement 207 comporte au moins une table 209 pour enregistrer les clés privés de récupération. Ainsi la clé Krec1 priv est chiffré par la clé Kserveursecret, le résultat de ce chiffrement étant lui même chiffré par au moins une clé Kurec propre à un utilisateur récupérateur. Dans la pratique il y a autant de clé Kurec que d'utilisateurs récupérateurs. Dans la pratique encore, la clé Kurec est une donnée de sécurité de l'utilisateur récupérateur. Dans une variante Kurec est la clé publique d'une biclé (Kupub, Kupriv) associée à un groupe d'utilisateur récupérateur. Le résultat du chiffrement par une clé Kurec est associé à un identifiant IdU utilisateur permettant de retrouver un tel chiffrement dans la table 207. Via la table 207 il est donc possible d'accéder à la clé Krecl priv permettant d'effectuer une récupération de clé Kssoperso. Cependant cette récupération ne saurait s'effectuer sans l'intermédiaire du serveur 102 d'authentification, car le recours à la clé Kserveursecret est nécessaire pour accéder à Krecl priv.

Dans cette description lorsque l'on dit qu'un serveur consulte l'annuaire 201, cela signifie que ce serveur émet une requête de consultation vers le serveur hébergeant l'annuaire 201, c'est à dire le serveur 101 dans notre exemple. Cette requête comporte au moins un identifiant d'utilisateur, et un identifiant de table. Cette requête comporte aussi un identifiant de ligne dans la table comportant l'information que le serveur consultant souhaite obtenir. La réponse à une requête de consultation est un message comportant l'information identifiée par la requête de consultation.

La figure 3 montre des étapes 301 d'obtention d'une biclé, et 302 d'authentification préliminaire. Au cours de ces étapes un utilisateur utilise la station 104 pour s'authentifier auprès du serveur 102 d'authentification. Cette authentification peut se faire par n'importe quels moyens d'authentification connus. Cette authentification se fait par exemple à travers la saisie par l'utilisateur d'un identifiant et d'un mot de passe qui sont transmis au serveur 102. Le mot de passe est une donnée de sécurité connue de l'utilisateur. On verra par la suite que c'est la seule donnée de sécurité directement accessible à l'utilisateur. Le serveur 102 vérifie alors la pertinence de cet identifiant et de ce mot de passe. S'ils sont corrects alors le serveur 102 accède à l'annuaire hébergé par le serveur 101. Grâce à l'identifiant utilisateur le serveur 102 peut demander au serveur 101 de lui transmettre la biclé (Kupriv, Kupub) enregistré dans la table 204 de l'enregistrement 202 correspondant à l'utilisateur. Cette biclé est enregistrée, dans notre exemple, en étant chiffré par un algorithme utilisant comme clé le mot de passe fournit par l'utilisateur. Dans une variante, cette biclé peut être chiffrée avec une clé connu du seul utilisateur. Le serveur 102 transmet alors cette biclé à la station 104 via laquelle s'est connecté l'utilisateur.

La saisie d'un mot de passe peut être substituée par un test mettant en oeuvre une donnée de biométrie.

Dans une autre variante les étapes 301 et 302 sont réalisées en utilisant une carte 111 à puce insérée dans le lecteur 110. La puce de la carte 111 comporte alors les moyens d'authentification, ainsi que la biclé (Kupriv, Kupub) qui n'est alors plus enregistrée dans l'annuaire 201.

A la fin des étapes 301 et 302, la station 104, et donc l'utilisateur utilisant cette station, est donc authentifiée par le serveur 102, et est en possession de la biclé (Kupriv, Kupub). Dans la mesure ou la station 104 est connectée et authentifiée par le serveur 102, la station 104 devient un client 104 du serveur 102.

Des étapes 301 et 302 on passe à une étape 303 d'émission d'une requête 350 d'obtention d'une donnée de sécurité par le client 104 vers le serveur 102. Dans la pratique l'utilisateur du client 104 ne se rend même pas compte qu'une telle requête est émise. Tout le travail est fait par le client 104 de manière transparente pour l'utilisateur. C'est cependant une action de l'utilisateur qui déclenche l'émission de cette requête. L'utilisateur peut en effet souhaiter, depuis le client 104, lancer une application ou accéder à des données, par exemple sur le serveur 103, ou le client 104 lui-même. Le lancement de cette application, ou l'accès à ces données est probablement protégé. Si c'est le cas une application cliente, exécutée par le client 104, le détecte est envoie la requête d'obtention de la donnée de sécurité permettant d'obtenir les droit permettant le lancement de l'application ou l'accès aux données. Cette application cliente est appelée un agent et prend en charge toutes les communications avec le serveur 102. Cette interception est propre au mécanisme de SSO, son traitement ultérieur est propre à l'invention.

La requête d'obtention d'une donnée de sécurité comporte au moins un identifiant 351 de l'utilisateur, et un identifiant 352 de l'application ou de la donnée à laquelle l'utilisateur cherche à accéder. Dans notre exemple on considère un identifiant d'application. La requête 350 d'obtention une fois produite est émise par le client 104 vers le serveur 102.

De l'étape 303 on passe à une étape 304 de consultation de l'annuaire par le serveur 102. Dans l'étape 304 le serveur 102 produit une requête 353 de consultation comportant au moins l'identifiant 351 de l'utilisateur, l'identifiant 352 de l'application, et un code 354 instruction précisant que le serveur 102 souhaite obtenir une clé de type Ksso.

De l'étape 304 on passe à une étape 305 de traitement de la requête 353 par le serveur 101. Dans l'étape 305, le serveur 101 utilise les données de la requête 353 pour parcourir l'annuaire 201 à la recherche de l'enregistrement 202 dont le champ 203 correspond au champ 351. Puis dans l'enregistrement 202 le serveur 101 parcourt la table 205, via la colonne 205b, ce qui lui permet de déterminer un identifiant de clé pour déterminer dans la table 204 la clé, c'est à dire la ligne, qui a été demandée via la requête 353.

Dans des variantes de l'invention, il est possible que les données de l'enregistrement 202 soient structurées autrement, et ou que la requête 353 comporte une information permettant d'accéder directement à la ligne souhaitée de la table 204.

Une fois la ligne de la table 204 déterminée, le serveur 305 produit un message 355 de réponse à la requête 353. Ce message 355 comporte au moins le contenu de la colonne 204a pour la ligne déterminée. Le message 355 comporte donc une clé 356 de type Ksso chiffrée comme précédemment décrit.

Le message 355 une fois produit est envoyé vers le serveur 102, et on passe à une étape 306 dans laquelle le serveur 102 transmet la clé 356 au client 104 via un message 357.

De l'étape 306 on passe à une étape 307 dans laquelle le client 104 utilise la clé Kupriv de la biclé (Kupriv, Kupub) obtenue à l'étape 301 pour déchiffrer la clé 356. Le résultat de ce déchiffrement produit Kint, qui est une clé intermédiaire avec Kint = Kserveuru(Kssoperso).

De l'étape 307 on passe à une étape 308 dans laquelle le client 104 produit et émet vers le serveur 102 un message 358 comportant la clé 359 Kint intermédiaire.

De l'étape 308 on passe à une étape 309 dans laquelle le serveur reçoit et sauvegarde la clé 359 Kint et consulte l'annuaire 201 pour obtenir la clé Kserveuru. Pour ce faire le serveur 102 produit une requête 360 de consultation comportant au moins l'identifiant 351 utilisateur et un code 361 instruction indiquant qu'il souhaite obtenir la clé Kserveuru de l'utilisateur. Une fois produite la requête 360 est émise vers le serveur 101. On note que le serveur 102 possède toutes les informations utiles pour la production de la requête 360 depuis l'étape 304.

De l'étape 309 on passe à une étape 310 dans laquelle le serveur 101 reçoit et traite la requête 360. Ce traitement consiste à déterminer un enregistrement dans l'annuaire 201, puis à parcourir la table 204 à la recherche de la ligne correspondant à la clé Kserveuru. Le bon enregistrement est trouvé grâce à l'identifiant 351, la bonne ligne est trouvée grâce au code 361. Le serveur 101 produit alors un message 362 comportant au moins dans un champ 363 le contenu de la colonne 204a pour la ligne désignée par le code 361. Dans les faits le champ 363 comporte: Kserveursecret(Kserveuru).

Une fois produit, le message 362 est émis vers le serveur 102, et on passe à une étape 311 de déchiffrement du champ 363 par le serveur 102.

Dans l'étape 311 le serveur 102 utilise sa connaissance de la clé Kserveursecret, qu'il est le seul à détenir, pour déchiffrer le contenu du champ 363 et ainsi obtenir Kserveuru.

De l'étape 311, on passe à une étape 312 dans laquelle le serveur 102 utilise Kserveuru pour déchiffrer Kint et ainsi obtenir Kssoperso.

De l'étape 312 on passe à une étape 313 de consultation de l'annuaire 201 par le serveur 102. Pour ce faire le serveur 102 produit une requête 364 de consultation comportant au moins l'identifiant 351 utilisateur, l'identifiant 352 de l'application et un code 365 instruction indiquant qu'il souhaite obtenir une donnée de sécurité. Une fois produite la requête 364 est émise vers le serveur 101. On note que le serveur 102 possède toutes les informations utiles pour la production de la requête 365 depuis l'étape 304.

De l'étape 313 on passe à une étape 314 dans laquelle le serveur reçoit et traite la requête 364. Ce traitement consiste à déterminer un enregistrement dans l'annuaire 201, puis à parcourir la table 205 à la recherche de la ligne correspondant à la donnée de sécurité requise. Le bon enregistrement est trouvé grâce à l'identifiant 351, la bonne ligne est trouvée grâce à l'identifiant 352. Le serveur 101 produit alors un message 365 comportant au moins dans un champ 366 le contenu de la colonne 205a pour la ligne désignée par l'identifiant 352. Dans les faits le champ 366 comporte: Kssoperso(DS).

De l'étape 314 on passe à une étape 315 dans laquelle le serveur 102 utilise la clé Kssoperso, connue depuis l'étape 312, pour déchiffrer le contenu du champ 366 et ainsi obtenir la donnée de sécurité DS. Cette donnée de sécurité une fois produite est envoyée au client 104 qui la réceptionne dans une étape 316.

Dans l'étape 316 le client 104 utilise la donnée de sécurité reçue à l'étape précédente pour déverrouiller l'application dont l'utilisateur du client 14 souhaite le lancement.

Dans une variante préférée, lorsque la donnée DS est transmise au client 104, elle l'est en utilisant un canal sécurisé mis en place grâce à l'utilisation d'un protocole de communication sécurisé de type SSL (Secure Socket Layer, pour socket sécurisé).

Dans une autre variante, lorsque la donnée DS est transmise au client 104, elle est chiffrée en utilisant la clé Kupub. Ainsi, seul le client 104 connaissant Kupriv peut accéder à la donnée de sécurité. Dans cettevariante, la clé Kupub est transmise au serveur 102 lors de l'étape d'authentification par exemple.

Dans une variante préférée de l'invention, les étapes de consultation 35 de l'annuaire sont condensées en une seule étape, l'étape 304, dans laquelle le serveur 102 produit et émet une requête de consultation lui permettant d'obtenir dans une seule réponse l'ensemble des informations dont il a besoin pour mener à terme la production de la donnée de sécurité DS. Ces données sont: - Kupub(Kserveuru(Kssoperso)), Kserveursecret(Kserveuru), et - Kssoperso(DS) On a ici décrit le procédé pour un utilisateur et une application. Ce procédé est strictement identique pour une autre application et / ou un autre utilisateur, les données extraites de l'annuaire 201 variant en fonction d'un identifiant de l'utilisateur et d'un identifiant d'une application.

Dans ce procédé il est impossible d'obtenir une clé Kssoperso si on ne possède pas Kupriv ET Kserveuru. Dans la pratique seul l'utilisateur possède Kupriv, et seul le serveur 102 est capable d'obtenir Kserveuru. Le passage par le serveur 102 est donc incontournable.

Pour la description de la table 204, on a vu que celle ci comporte des lignes dont le contenu est chiffré avec une clé asymétrique Krecl pub. Dans la pratique ces lignes peuvent être consultées par un propriétaire de la biclé (Krecl priv, Krecl pub) afin d'effectuer une récupération des clé de type Ksso perso récupérable de l'utilisateur. Les clés de type Krecl priv servent en effet à chiffrer des clés de type Ksso récupérable. L'accès aux données de sécurité chiffrées avec une clé de type Ksso récupérable se fait selon le même schéma que celui décrit pour la figure 3. Pour obtenir une donnée de sécurité via une clé Ksso récupérable il faut obligatoirement passer par le serveur 102 car ces clés sont aussi chiffrées avec Kserveuru. Ainsi lors d'une récupération, l'utilisateur récupérateur récupère en fait la clé de type Ksso récupérable chiffrée par Kserveuru.

Le fait que le serveur 102 d'authentification soit incontournable pour une récupération est encore renforcé par le fait que la clé Krec1 priv n'est accessible que via un processus permettant la mise en oeuvre de la clé Kserveursecret, et seul le serveur 102 d'authentification a accès à cette clé. II est donc impossible d'effectuer une récupération de clés sans passer par le serveur 102.

Lors d'une récupération, l'utilisateur entre en possession d'une nouvelle biclé (Kupriv2, Kupub2), le récupérateur lui fournit les clés Kssoperso, chiffrées par la clé Kserveuru, qui peuvent être récupérées (et donc les moyens d'accéder aux données de sécurité qui peuvent être récupérées), le serveur 102 recrée alors des lignes dans la table 204 correspondant à la nouvelle clé publique Kupub2 de l'utilisateur. Les anciennes lignes correspondant à la clé publique Kupub sont effacées.

Dans la pratique il peut y avoir plusieurs groupes récupérateurs correspondant alors à autant de lignes dans la table 204. Chaque groupe récupérateur est caractérisé par une biclé récupérateur qui lui est propre.

Dans une variante de l'invention le déverrouillage d'une application ou d'une donnée est lié à l'application d'une politique. Une telle politique est liée à un identifiant utilisateur, et ou à une application, et ou à une localisation, cette liste n'étant pas exhaustive. Une telle politique peut donc être mise en oeuvre par le serveur 102 à partir du moment ou il dispose de ces informations. Dans la mesure ou le serveur 102 est incontournable pour l'obtention d'une donnée de sécurité, et dans la mesure ou une donnée de sécurité est nécessaire pour le déverrouillage d'une application ou d'une donnée, alors une politique mise en oeuvre par le serveur 102 devient incontournable. En effet si le serveur 102 ne distribue pas de données de sécurité, il devient impossible de déverrouiller une application ou une donnée. Cela est bien le but poursuivi par la mise en oeuvre d'une politique de sécurité.

Dans l'invention le serveur 102 est en connaissance des informations utiles à la mise en oeuvre d'une politique d'accès dès la fin de l'étape 303 lorsque le message 350 a été émis. En effet ce message comporte un identifiant d'utilisateur, un identifiant d'application, et une adresse origine pour répondre à ce message. Dans la variante avec application d'une politique de sécurité, on passe donc de l'étape 303 à une étape 317 d'application d'une politique. Dans l'étape 317, le serveur 102 consulte l'annuaire 201 de manière à obtenir une description de la politique applicable à l'utilisateur identifié par le champ 351 pour l'application 352. Cette description est enregistrée dans la table 206 de l'enregistrement 202. Si aucune politique n'est spécifiquement enregistrée pour l'utilisateur et l'application spécifiée dans le message 350, alors le serveur 102 se rabat sur une politique par défaut enregistrée dans une mémoire du serveur 102.

De manière connue une politique est un ensemble de règles que l'on confronte à un ensemble de données (ici: identifiant utilisateur, identifiant d'application, origine de la demande) pour produire une sortie binaire à savoir: accès autorisé ou accès refusé. L'application de telles règles est déjà connue de la plupart des systèmes d'exploitation, et logiciels serveurs. Avec l'invention, l'application de ces règles devient incontournable, même dans un environnement informatique hétérogène. Par hétérogène il faut comprendre multi-utilisateurs, et multi-applicatif, et / ou multi systèmes d'exploitations.

Dans l'étape 317, si l'application des règles conduit à accès autorisé, alors on passe à l'étape 304. Sinon on passe à une étape 318 dans laquelle le serveur 102 signifie au client 104 l'impossibilité d'accès.

Claims (1)

16 REVENDICATIONS

1 - Procédé de gestion de données de sécurité caractérisé en ce qu'on structure un annuaire (201) de telle manière que: - des données de sécurité d'un utilisateur sont enregistrées chiffrées dans l'annuaire, chaque donnée de sécurité étant chiffrée grâce à une clé Kssoperso dépendant d'un utilisateur, - la clé Kssoperso est enregistrée chiffrée dans l'annuaire, la clé Kssoperso étant chiffrée par une clé Kserveuru dépendant de l'utilisateur, le résultat de ce chiffrement étant lui-même chiffré par un procédé de chiffrement asymétrique utilisant une clé publique Kupub dépendant elle aussi de l'utilisateur, - la clé Kserveuru dépendant de l'utilisateur est enregistrée chiffrée dans l'annuaire en étant chiffrée par un procédé utilisant une clé Kserveursecret, - la clé Kserveursecret est connue des seuls serveurs habilités à fournir une donnée de sécurité à l'utilisateur.

2 - Procédé d'authentification unique selon la revendication 1 caractérisé en ce que: - un utilisateur obtient (301) une paire de clé (Kupriv, Kupub) asymétriques en fournissant une donnée de sécurité à un terminal client connecté au serveur d'authentification, - le client s'authentifie (302) auprès d'un serveur d'authentification unique en fonction d'information fournie par l'utilisateur, - le client émet (303) une requête, vers le serveur d'authentification, pour obtenir une donnée de sécurité, - le serveur (304) d'authentification consulte l'annuaire en fonction de la requête du client et obtient une clé Kssoperso chiffrée, - le serveur d'authentification transmet (306) la clé Kssoperso chiffrée obtenue au client, - le client utilise (307-308) Kupriv pour déchiffrer la clé Kssoperso chiffrée transmise, et transmet le résultat du déchiffrement, Kint, au serveur d'authentification, - le serveur d'authentification consulte (309) l'annuaire en fonction de la requête du client pour obtenir une clé Kserveuru chiffrée, - le serveur d'authentification utilise (311) la clé Kserveursecret pour déchiffrer Kserveuru - le serveur d'authentification utilise (312) Kserveuru pour obtenir Kssoperso à partir de Kint, - le serveur d'authentification consulte (313) l'annuaire en fonction de la requête du client pour obtenir une donnée de sécurité chiffrée, - le serveur d'authentification utilise (315) Kssoperso pour déchiffrer la donnée de sécurité, - le serveur d'authentification transmet (315) au client la donnée de 10 sécurité déchiffrée.

3 - Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que: - une donnée de sécurité est enregistrée dans l'annuaire en étant chiffrée par une clé Kssopersorec dépendant de l'utilisateur, - la clé Kssopersorec est enregistrée dans l'annuaire, la clé Kssopersorec étant chiffrée par la clé Kserveuru, le résultat de ce chiffrement étant lui-même chiffré par un procédé de chiffrement asymétrique utilisant une clé publique Krecpub dépendant d'un deuxième utilisateur habilité a effectuer une récupération de données de sécurité chiffrées avec la clé Kssopersorec, - une clé Krecpriv, de la biclé (Krecpriv, Krecpub) est enregistrée dans l'annuaire en étant chiffrée par la clé Kserveursecret, puis par une clé Kurec d'un utilisateur de récupération.

4 - Procédé selon la revendications 3, caractérisé en ce que une 25 donnée de sécurité enregistrée et chiffrée avec la clé Kssopersorec ne l'est pas avec la clé Kssoperso.

- Procédé selon l'une des revendications 1 à 4, caractérisé en ce que le serveur d'authentification répond (317) à une requête du terminal client en fonction d'une politique (206) enregistrée dans l'annuaire.

6 - Procédé selon l'une des revendications 1 à 5, caractérisé en ce que la donnée de sécurité transmise par le serveur d'authentification au client est chiffrée (315) en utilisant la clé Kupub.

7 - Procédé selon l'une des revendication 1 à 6, caractérisé en ce que la donnée de sécurité transmise par le serveur d'authentification au client est transmise (315) via un canal sécurisé.