Brevet FR2767208A1 — publié le 19990212

A La présente invention concerne un système et un procédé qui permettent d'implémenter des services centra- lisés pour mémoriser d'une manière sécurisée des données secrètes vitales, telles que des mots de passe, des clés cryptographiques, ainsi que des codes personnels ou fi- nanciers sensibles. De plus en plus, les transactions financières et autres transactions sensibles s'effectuent via des or- dinateurs personnels. Ceci rend d'autant plus indispensa- ble une mémorisation sécurisée des données. Des techni- ques de cryptographie modernes sont souvent utilisées afin de protéger de telles données à l'encontre d'un ac- cès non-autorisé. Les nouveaux procédés de sécurité, cependant, rendent nécessaires la mémorisation et la protection des données secrètes " vitales ", comme les clés cryptogra- phiques privées, les numéros de carte de crédit, ainsi que d'autres petits éléments de données secrètes. A l'heure actuelle, cette responsabilité incombe aux pro- grammes d'application individuels ou aux utilisateurs d'ordinateurs personnels, eux-mêmes. Bien qu'il soit pos- sible de trouver des programmes qui permettent aux utili- sateurs de crypter et de mémoriser les données, de tels programmes ne peuvent être utilisés d'une manière typique par d'autres programmes d'application. Actuellement, cha- que programme d'application doit imaginer un procédé fia- ble et sûr pour mémoriser de telles données. A titre d'exemple des problèmes associés à l'état courant de la technique, on va s'attacher aux questions impliquées dans l'exploitation des technologies des cartes à mémoire " intelligentes " (" smart cards "). Une telle carte à mémoire est particulièrement bien adap- tée, lorsque utilisée comme réceptacle, pour des données secrètes vitales telles que celles décrites ci-dessus. De plus, de telles cartes à mémoire peuvent être utilisées pour authentifier des utilisateurs en demandant à chaque utilisateur d'insérer sa carte à mémoire personnelle dans un réceptacle associé à l'ordinateur personnel de l'uti- lisateur. Des cartes à mémoire intraficables ont été jus- tement conçues à cet effet. Des problèmes se posent, en l'absence de normes agréées, quant à l'utilisation de tels dispositifs. Bien qu'il serait possible, pour un développeur, de prévoir des moyens qui permettraient de travailler avec un nombre limité de cartes à mémoire, il lui serait difficile, voire impossible, d'anticiper toutes les différentes va- riantes susceptibles, le cas échéant, d'être utilisées. De ce fait, il est impossible d'implémenter la technolo- gie de la carte à mémoire dans des applications diverses différentes. Bien que certains supports de mémorisation, tels que les disques durs magnétiques, ne représentent pas les mêmes défis que les cartes à mémoire, de nombreux développeurs de logiciels n'ont simplement pas les bases ni les connaissances requises pour implémenter d'une ma- nière sûre les techniques cryptographiques modernes. Même s'ils les avaient, il serait inefficace que chaque déve- loppeur entreprenne la tâche complexe de développer un procédé pour mémoriser des données secrètes vitales. En outre, les solutions résultantes risqueraient de ne pas être compatibles. Il serait bien plus préférable d'adop- ter un schéma commun pour mémoriser de telles données, et éviter d'avoir à implémenter une nouvelle solution pour chaque programme d'application différent. L'invention décrite ci-après permet l'implémen- tation de services de mémorisation protégée centralisés qui peuvent être appelés par des programmes d'application afin de mémoriser des données secrètes vitales. Un mode de réalisation de la présente invention est implémenté sous la forme d'un serveur et d'interfaces associées qui peuvent être invoqués par des programmes d'application afin de mémoriser et de récupérer de petits éléments de données. Le procédé général, ainsi que l'architecture générale, comprennent un serveur de mémorisation et une pluralité de fournisseurs de mémorisation et de fournis- seurs d'authentification installables. Chaque fournisseur de mémorisation est adapté pour mémoriser d'une manière sécurisée des données en utilisant un type spécifique de supports, comme des supports magnétiques ou des cartes à mémoire. Les détails inhérents au support de mémorisation sont dissimulés aux programmes d'application appelants. Les fournisseurs d'authentification sont utilisés pour authentifier les utilisateurs par différents procédés, comme en demandant des mots de passe, en lisant des car- tes à mémoire, en balayant la rétine, ou d'autres maniè- res que l'on pourra imaginer dans le futur. A nouveau, les détails de l'authentification sont généralement dis- simulés aux programmes d'application appelants. Les programmes d'application interagissent avec le serveur de mémorisation via des interfaces bien défi- nies. Un élément de données peut être mémorisé via un simple appel au serveur de mémorisation, et peut être ré- cupéré ultérieurement via un appel similaire. Le cryp- tage, le décryptage, les contrôles d'intégrité des élé- ments, et l'authentification de l'utilisateur sont tous effectués par le serveur de mémorisation et ses fournis- seurs associés. De ce fait, les programmes d'application peuvent bénéficier de caractéristiques de sûreté avan- cées, sans rendre plus complexes les programmes d'appli- cation, eux-mêmes. Lors de la mémorisation d'un élément de données en utilisant les services de mémorisation protégée, un programme d'application peut spécifier des règles qui dé- terminent quand autoriser l'accès à l'élément de données. L'accès est généralement limité à l'utilisateur de l'or- dinateur qui a créé l'élément de données. L'accès peut être limité d'une manière similaire à des programmes d'application spécifiés ou à certaines classes de pro- grammes d'application. Le serveur de mémorisation authen- tifie les programmes d'application demandeurs avant de leur retourner les données. Un fournisseur d'authentification par défaut authentifie les utilisateurs sur la base de leur con- nexion à l'ordinateur ou au réseau. D'autres fournisseurs d'authentification peuvent aussi être installés. Un fournisseur de mémorisation par défaut per- met la mémorisation d'éléments de données sur des sup- ports magnétiques, tels qu'un disque dur ou une dis- quette. Les éléments de données sont cryptés avant d'être mémorisés. Le cryptage utilise une clé qui est obtenue à partir de l'authentification de l'utilisateur. D'une ma- nière spécifique, la clé est obtenue à partir du mot de passe de l'utilisateur, entré lors de sa connexion à l'ordinateur ou au réseau. De plus, un programme d'appli- cation, voire l'utilisateur, peut spécifier que certains éléments nécessitent l'entrée d'un mot de passe addition- nel à chaque fois qu'est demandé un accès aux données. Le fournisseur de mémorisation par défaut im- plémente un schéma de cryptage à clé multi-niveau afin de minimiser le volume de cryptage à réeffectuer lorsque l'utilisateur change de mot de passe. Chaque élément de données est crypté en utilisant une clé d'élément qui est générée d'une manière aléatoire par le système. La clé d'élément est à son tour cryptée en utilisant une clé maîtresse qui est elle-même cryptée (comme on le décrira ci-après) avec une clé obtenue à partir du mot de passe fourni par l'utilisateur (tel que le mot de passe utilisé lors de la connexion de l'utilisateur). On va maintenant décrire la présente invention, à titre d'exemple uniquement, en se reportant aux dessins annexés sur lesquels: - la figure i est un schéma fonctionnel d'un exemple de système informatique qui est adapté pour être utilisé dans l'implémentation de la présente invention, la figure 2 est un organigramme d'un système de mémorisation protégée et d'un programme d'application appelant selon la présente invention, et - la figure 3 est un organigramme montrant com- ment les éléments de données sont cryptés et authentifiés selon la présente invention. On va maintenant décrire en détail la présente invention. On va décrire d'une manière sommaire ce qu'est la cryptographie. D'une manière sommaire, la cryptographie est le traitement que l'on utilise pour crypter ou brouiller des messages de manière à ce que les messages puissent être mémorisés et transmis en toute sécurité. La cryptographie peut être utilisée pour effectuer des communications sû- res, même lorsque le support de transmission (par exem- ple, l'Internet) n'est pas digne de confiance. Les utili- sateurs d'ordinateurs utilisent aussi la cryptographie pour crypter les fichiers sensibles, de manière à ce qu'un intrus ne puisse les comprendre. La cryptographie peut être utilisée pour garantir l'intégrité des données, ainsi que pour préserver la discrétion. Il est aussi pos- sible de vérifier l'origine d'éléments de données en uti- lisant la cryptographie, via l'utilisation de signatures numériques. Lorsqu'on utilise des procédés cryptographi- ques, seules les clés cryptographiques doivent demeurer secrètes. Les algorithmes, les tailles des clés, et les formats des fichiers peuvent être divulgués, sans compro- mettre la sécurité. En utilisant un cryptage de données, un élément de données peut être brouillé de manière à apparaître comme un charabia aléatoire et il est très difficile de le retransformer en données originelles sans une clé se- crête. Ce message peut consister en du texte ASCII, en un fichier de base de données, ou autres données. Une fois qu'un élément de données a été crypté, celui-ci peut être mémorisé sur un support non-sécurisé ou transmis via un réseau nonsécurisé, et demeurer en- core secret. Ultérieurement, le message peut être ramené par décryptage sous sa forme originelle. Lorsqu'un élément de données est crypté, une clé de cryptage est utilisée. Celle-ci est comparable à la clé que l'on utilise pour fermer un cadenas. Pour dé- crypter le message, une clé de décryptage doit être uti- lisée. Les clés de cryptage et de décryptage sont sou- vent, mais pas toujours, la même clé. Il existe deux classes principales d'algorith- mes de cryptage: les algorithmes symétriques et les al- gorithmes à clé publique (aussi connus comme algorithmes asymétriques). Les systèmes qui utilisent les algorithmes symétriques sont parfois appelés conventionnels. Les algorithmes symétriques constituent le type d'algorithme de cryptage le plus commun. Ceux-ci sont ap- pelés symétriques du fait que la même clé est utilisée à la fois pour le cryptage et le décryptage. Contrairement aux clés utilisées avec les algorithmes à clé publique, les clés symétriques sont fréquemment changées. Par comparaison avec les algorithmes à clé pu- blique, les algorithmes symétriques sont très rapides et, de ce fait, sont préférés lors du cryptage de gros volu- mes de données. Comme algorithmes symétriques les plus communs, on mentionnera les algorithmes RC2, RC4, et la "Data Encryption Standard" (DES) ou Norme de chiffrement Américaine. Les algorithmes (asymétriques) à clé publique utilisent deux clés différentes: la clé publique et la clé privée. La clé privée est réservée au propriétaire de la paire de clés, et la clé publique peut être distribuée à quiconque la demande (souvent par l'intermédiaire d'un certificat). Si une clé est utilisée pour crypter un mes- sage, alors l'autre clé est nécessaire pour décrypter le message. Les algorithmes à clé publique sont très lents - de l'ordre de 1000 fois plus lents que les algo- rithmes symétriques. En conséquence, ceux-ci ne sont uti- lisés d'une manière typique que pour crypter des clés de session. Ceux-ci sont aussi utilisés pour signer numéri- quement des messages. L'un des algorithmes à clé publique les plus communs est l'algorithme de chiffrement à clé publique RSA. Des signatures numériques peuvent être utili- sées pour distribuer un élément de données non-crypté, tout en permettant aux destinataires de vérifier que le message provient de l'émetteur patenté et qu'il n'a pas été trafiqué. Signer un message n'altère pas le message, mais génère simplement une chaîne de signatures numéri- ques qui peut être entrelacée avec le message ou trans- mise séparément. Les signatures numériques sont générées en uti- lisant des algorithmes de signature à clé publique: une clé privée est utilisée pour générer la signature, et la clé publique correspondante est utilisée pour valider la signature. Une authentification implique le traitement qui consiste à vérifier l'identité d'une personne ou d'une entité. Des certificats sont une manière classique d'ob- tenir l'authentification. Un certificat est un ensemble de données qui identifie complètement une entité, et est délivré par une Autorité de Certification uniquement après que l'Autorité a vérifié que l'entité est bien qui elle affirme être. L'ensemble de données contient la clé cryptographique publique de l'entité. Lorsque l'expédi- teur d'un message signe des données avec sa clé privée (et envoie une copie de son certificat avec le message), le destinataire du message peut utiliser la clé publique de l'expéditeur (récupérée à partir du certificat) afin de vérifier que l'expéditeur est bien celui qu'il affirme être. Des certificats peuvent aussi être utilisés pour vérifier que les données (y compris les programmes d'ap- plication) ont été attestées par une source digne de con- fiance. Sur un réseau, il existe souvent une applica- tion digne de confiance qui tourne sur un ordinateur sé- curisé, qui est connue comme l'Autorité de Certification. Cette application connaît la clé publique de chaque uti- lisateur. Les Autorités de Certification délivrent des messages connus sous le nom de certificats, qui contien- nent chacun la clé publique de l'un de ses utilisa- teurs-clients. Chaque certificat est signé avec la clé privée de l'Autorité de Certification. L'invention décrite ci-après utilise des tech- niques telles que les techniques de cryptage numérique, de signature et d'authentification bien connues, décrites ci-dessus. Pour de plus amples informations concernant ces techniques, on se reportera au document de Schneier, Bruce; intitulé "Applied Cryptography Second Edition: Protocols, Algorithms and Source Code in C"; John Wiley & Sons, 1996. La description qui va suivre suppose une certaine familiarité avec ces questions. On va maintenant décrire un exemple de contexte d'exploitation. La figure 1, ainsi que la discussion qui va suivre, ont pour but de fournir une brève description gé- nérale d'un contexte informatique adapté, dans lequel peut être implémentée la présente invention. Bien que ce- la ne soit pas nécessaire, la présente invention sera dé- crite dans le contexte général d'instructions exécutables par ordinateur, comme des modules de programme, exécutées par un ordinateur personnel. D'une manière générale, des modules de programme comprennent des routines, des pro- grammes, des objets, des composants, des structures de données, etc. qui exécutent des tâches particulières ou implémentent des types particuliers de données abstrai- tes. De plus, l'homme du métier appréciera que la pré- sente invention peut être implémentée en utilisant d'au- tres configurations de système informatique, y compris des dispositifs portatifs, des systèmes multiprocesseurs, des systèmes électroniques à base de microprocesseur ou programmables destinés au consommateur, des ordinateurs personnels communiquants, des mini-ordinateurs, des ordi- nateurs centraux, et analogues. La présente invention peut aussi être implémentée dans des contextes informati- ques répartis, dans lesquels les tâches sont exécutées par des dispositifs de traitement éloignés qui sont re- liés entre eux via un réseau de communication. Dans un contexte informatique réparti, les modules de programme peuvent être placés à la fois dans des dispositifs de mé- morisation locaux et éloignés. En se reportant à la figure 1, un exemple de système destiné à implémenter la présente invention com- porte un dispositif informatique universel qui se pré- sente sous la forme d'un ordinateur personnel 20 conven- tionnel, incluant une unité de traitement 21, une mé- moire-système 22, et un bus-système 23 qui relie les divers composants du système, y compris la mé- moire-système, à l'unité de traitement 21. Le bus-système 23 peut avoir n'importe quel type de structure et peut être un bus de mémoire ou une unité de commande de mé- moire, un bus périphérique, et un bus local utilisant n'importe quelle architecture de bus parmi une variété d'architectures. La mémoire- système inclut une mémoire morte (ROM) 24 et une mémoire vive (RAM) 25. Un système de gestion de base des entrées/sorties 26 (BIOS), conte- nant les routines de base qui aident à transférer les in- formations entre les éléments de l'ordinateur personnel , tel que pendant le démarrage, est mémorisé dans la ROM 24. L'ordinateur personnel 20 comporte en outre une mémoire à disque dur 27 destinée à permettre une lecture à partir d'un disque dur et une écriture sur un disque dur, non-représentée, une mémoire à disque magnétique 28 destinée à permettre une lecture à partir d'un disque ma- gnétique amovible 29 ou une écriture sur celui-ci, et une mémoire à disque optique 30 destinée à permettre une lec- ture à partir d'un disque optique amovible 31 ou une écriture sur celui-ci, tel qu'un CD ROM ou autres sup- ports optiques. La mémoire à disque dur 27, la mémoire à disque magnétique 28 et la mémoire à disque optique 30 sont reliées au bus-système 23 via une interface de mé- moire à disque dur 32, une interface de mémoire à disque magnétique 33 et une interface de mémoire optique 34, respectivement. Les mémoires et leurs supports lisibles par ordinateur associés assurent la mémorisation non-volatile des instructions lisibles par l'ordinateur, des structures de données, des modules de programme, ain- si que d'autres données, pour l'ordinateur personnel 20. Bien que le contexte décrit ici à titre d'exemple utilise un disque dur, un disque magnétique amovible 29 et un disque optique amovible 31, il doit être apprécié de l'homme du métier que d'autres types de supports lisibles par ordinateur, capables de mémoriser des données aux- quelles peut accéder un ordinateur, tels que des casset- tes magnétiques, des cartes-mémoires flash, des disques vidéonumériques, des cartouches de Bernoulli, des mémoi- res vives (RAM), des mémoires mortes (ROM), et analogues, peuvent aussi être utilisés dans le contexte d'exploita- tion décrit à titre d'exemple. Un certain nombre de modules de programme peu- vent être mémorisés sur le disque dur, le disque magnéti- que 29, le disque optique 31, la ROM 24 ou la RAM 25, y compris un système d'exploitation 35, un ou plusieurs programmes d'application 36, d'autres modules de pro- gramme 37 et des données de programme 38. Un utilisateur l1 peut entrer des instructions et des informations sur l'ordinateur personnel 20 via des dispositifs d'entrée, tels qu'un clavier 40 et un dispositif de pointage 42. D'autres dispositifs d'entrée (non-représentés) peuvent comprendre un microphone, une manette de jeu, un clavier de jeu, une antenne-satellite, un scanner, ou analogues. Ces dispositifs d'entrée, ainsi que d'autres, sont sou- vent reliés à l'unité de traitement 21 via une interface à port série 46 qui est reliée au bus-système, mais peu- vent être reliés par d'autres interfaces, comme par un port parallèle, un port de jeu, ou un bus série universel (USB). Un moniteur 47 ou autre type de dispositif d'affi- chage est aussi relié au bus-système 23 via une inter- face, telle qu'un adaptateur vidéo 48. En plus du moni- teur, les ordinateurs personnels comportent d'une manière typique d'autres dispositifs de sortie périphériques (non-représentés), tels que des haut-parleurs et des im- primantes. L'ordinateur personnel 20 peut être utilisé dans un contexte d'intégration à un réseau en utilisant des connexions logiques vers un ou plusieurs ordinateurs éloignés, tels qu'un ordinateur éloigné 49. L'ordinateur éloigné 49 peut être un autre ordinateur personnel, un serveur, un routeur, un ordinateur communiquant, un dis- positif pair ou autre noeud de réseau commun, et comporte d'une manière typique une grande partie, voire la totali- té des éléments décrits ci-dessus en référence à l'ordi- nateur personnel 20, bien que seul un dispositif de mémo- risation 50 ait été illustré sur la figure 1. Les con- nexions logiques représentées sur la figure 1 incluent un réseau local (LAN) 51 et un réseau étendu (WAN) 52. De tels contextes d'intégration à un réseau sont communs dans les bureaux, les réseaux informatiques d'entreprise, les intranets, et l'Internet. Lorsque utilisé dans un contexte d'intégration à un réseau local, l'ordinateur personnel 20 est relié au réseau local 51 via une interfaceréseau ou adaptateur 53. Lorsque utilisé dans un réseau étendu, l'ordinateur personnel 20 comporte d'une manière typique un modem 54, ou d'autres moyens, pour établir des communications via le réseau étendu 52, tel que l'Internet. Le modem 54, qui peut être interne ou externe, est relié au bus-système 23 via l'interface à port série 46. Dans un contexte d'inté- gration à un réseau, les modules de programme décrits en référence à l'ordinateur personnel 20, ou des parties de * ceux-ci, peuvent être mémorisés dans le dispositif de mé- morisation éloigné. On notera que les connexions au ré- seau qui ont été représentées ne sont données qu'à titre d'exemple et que d'autres moyens peuvent être utilisés pour établir un lien de communication entre les ordina- teurs. L'ordinateur illustré utilise un système d'ex- ploitation similaire aux systèmes d'exploitation de la famille Windows, commercialisés par Microsoft Corpora- tion. La fonctionnalité décrite ci-dessous est implémen- tée en utilisant des techniques de programmation stan- dards, y compris en utilisant les interfaces OLE et COM, décrites dans le document "Inside OLE 2"; Brockschmidt, Kraig; Microsoft Press, 1994. Des systèmes d'exploitation Windows plus ré- cents utilisent ce que l'on appelle l'API Win32: un en- semble bien défini d'interfaces qui permettent aux pro- grammes d'application d'utiliser la fonctionnalité four- nie par les systèmes d'exploitation Windows. L'API Win32 est décrite dans de nombreux documents, parmi lesquels "Windows 95 Win32 Programming API Bible"; Simon, Ri- chard; Waite Group Press, 1996. Une certaine familiarité avec ce type de programmation est supposée dans la des- cription qui va suivre. On va maintenant décrire la fonctionnalité et l'architecture globales. La figure 2 représente les composants architec- turaux d'un système de mémorisation protégée selon la présente invention qui est destiné à mémoriser des élé- ments de données et à les protéger à l'encontre d'un ac- cès non-autorisé. Le système de mémorisation protégée permet à des programmes d'application de mémoriser d'une manière sécurisée des éléments de données qui doivent rester confidentiels et ne doivent pas être trafiqués. De tels éléments de données peuvent comprendre des clés cryptographiques, des mots de passe, des informations fi- nancières, des profils de confiance, etc. Le système de mémorisation est conçu pour conserver de petits éléments de données secrètes vitales au niveau d'un site de mémo- risation central et commun; si un grand nombre de don- nées doivent être protégées, un code d'amorçage secret (tel qu'une clé de cryptage) peut être mémorisé dans le système de mémorisation, plutôt que les données el- les-mêmes. Ceci permet aux éléments de données d'être dé- placés, lorsque approprié, vers de petits dispositifs ma- tériels sécurisés, tels que des cartes à mémoire, et d'éviter aussi un temps système ("overhead") inutile, né- cessaire sinon pour sécuriser un grand nombre d'éléments de données. Le système de mémorisation protégée est exécuté par un ordinateur, tel que celui décrit ci-dessus en ré- férence à la figure 1. Des programmes d'application, tels qu'un programme d'application 102 représenté sur la fi- gure 2, sont aussi exécutés par l'ordinateur. Le système de mémorisation 100 comporte un com- posant 104 formant serveur de mémorisation, appelé aussi dispatcheur. D'une manière générale, le serveur de mémo- risation, via l'interface Pstore 110, reçoit des éléments de données en provenance de programmes d'application, mé- morise d'une manière sécurisée les éléments de données, et retourne ces éléments de données en réponse aux deman- des émanant des programmes d'application. Le serveur de mémorisation exécute aussi des procédures d'authentifica- tion et de vérification eu égard aux programmes d'appli- cation demandeurs, comme on l'expliquera avec plus de dé- tails par la suite. Au serveur de mémorisation sont associés une pluralité de fournisseurs de mémorisation 106 installa- bles et une pluralité de fournisseurs d'authentification 108 installables. Les fournisseurs de mémorisation spéci- fiés sont appelés par le serveur de mémorisation pour mé- moriser et récupérer d'une manière sécurisée des éléments de données. Un ou plusieurs fournisseurs d'authentifica- tion sont appelés par le serveur de mémorisation afin d'identifier et/ou d'authentifier les personnes utilisant les ordinateurs. Un fournisseur de mémorisation par défaut est implémenté au sein du système de mémorisation. Le four- nisseur de mémorisation par défaut crypte les éléments de données, puis les mémorise sur un disque dur ou une dis- quette. Le cryptage est basé sur une ou plusieurs clés qui sont obtenues à partir de l'authentification de l'utilisateur de l'ordinateur. Le fournisseur de mémori- sation par défaut vérifie aussi l'intégralité des élé- ments de données lorsqu'il les récupère et les décrypte. Un fournisseur d'authentification par défaut est aussi implémenté au sein du système de mémorisation. Le fournisseur d'authentification par défaut est appelé par le serveur de mémorisation afin d'identifier les uti- lisateurs d'ordinateurs sur la base de procédures de con- nexion au système d'exploitation précédemment suivies. D'une manière spécifique, le fournisseur d'authentifica- tion par défaut identifie la personne qui utilise l'ordi- nateur sur la base de l'identification faite lors de la connexion et du mot de passe fourni par l'utilisateur lorsqu'il s'est connecté au système d'exploitation de l'ordinateur ou au système d'exploitation du réseau. Bien que des fournisseurs de mémorisation et d'authentification par défaut soient implémentés, des fournisseurs additionnels pourront être installés dans le futur afin de bénéficier des nouvelles technologies de mémorisation et d'authentification. Par exemple, un four- nisseur de mémorisation sur carte à mémoire pourra être installé afin de permettre de mémoriser des éléments de données de noyau sur une carte à mémoire. Un fournisseur d'authentification de carte à mémoire pourra être utilisé d'une manière similaire afin d'authentifier les utilisa- teurs en leur demandant d'insérer leur carte à mémoire dans un lecteur de carte à mémoire. Quel que soit le cas, la carte à mémoire pourra utiliser des techniques crypto- graphiques à clé publique. Des interfaces COM bien définies sont utilisées entre le serveur de mémorisation et les divers fournis- seurs, ce qui permet à de nouveaux fournisseurs d'être facilement installés et enregistrés avec le serveur de mémorisation. Les programmes d'application peuvent en- voyer des appels identiques vers le serveur de mémorisa- tion 102, sans se soucier des fournisseurs utilisés. De ce fait, des programmes d'application peuvent être écrits, afin de bénéficier des technologies futures, en interagissant simplement avec le serveur de mémorisation 102, et sans avoir à se soucier des détails inhérents à ces technologies futures. Afin d'accroître la sécurité, le système de mé- morisation protégée est implémenté dans un espace d'adressage qui diffère de celui des programmes d'appli- cation appelants. Les communications de part et d'autre de la frontière entre traitements ou espaces d'adressage s'effectuent en utilisant des appels RPC. De tels appels peuvent se faire lorsqu'on utilise les systèmes d'exploi- tation Windows, ainsi que d'autres systèmes d'exploita- tion. La fonctionnalité et le formatage des appels RPC sont décrits dans le document intitulé "Microsoft Win32 Software Development Kit". Bien que les programmes d'application puissent faire directement des appels RPC, une telle complexité est évitée en fournissant une bibliothèque de liens dyna- miques (DLL) qui peut être exécutée dans les espaces d'adressage des programmes d'application. Cette biblio- thèque, appelée Interface Pstore 110 sur la figure 2, im- plémente une pluralité d'interfaces et de procédés asso- ciés qui peuvent être appelés par les programmes d'appli- cation afin d'exploiter l'intégralité de la fonctionnali- té du système de mémorisation protégée. Les interfaces comprennent des procédés pour créer et lire des éléments de données, ainsi que d'autres fonctions utiles. Les in- terfaces et les procédés du mode de réalisation décrit sont implémentés en utilisant les interfaces COM ('Compo- nent Objet Model') du système d'exploitation Windows. On va maintenant décrire comment se gère l'ac- cès à des données protégées. Le système de mémorisation protégée décrit ici dispose d'une très grande aptitude à gérer l'accès aux données. Le système de mémorisation offre deux niveaux de protection des données: une protection au niveau appli- cation et une protection au niveau utilisateur. Au niveau application, le serveur de mémorisation retourne les élé- ments de données demandés uniquement aux programmes d'ap- plication demandeurs autorisés. En outre, le serveur de mémorisation authentifie les programmes d'application de- mandeurs avant de retourner les éléments de données indi- viduels. L'authentification du programme d'application fait référence à un traitement qui consiste à déterminer si un programme d'application a été trafiqué, ou à un au- tre traitement qui consiste à vérifier la fiabilité d'un programme par l'utilisation de signatures numériques cryptographiques à clé publique/privée ou autres moyens. Microsoft Authenticode est un mécanisme disponible pour vérifier, par l'utilisation de signatures numériques, qu'un programme d'application a été publié par une per- sonne, un groupe ou une organisation spécifié, et qu'il est par conséquent fiable. La fonctionnalité Authenticode est commercialisée auprès du public par Microsoft Corpo- ration et fait partie de son kit de développement logi- ciel Win32 ("Win32 Software Development Kit"). Dans le mode de réalisation décrit ici, les éléments de données sont organisés d'une manière hiérar- chique en spécifiant des types et des sous-types de la manière suivante: Type - Sous-Type - Elément de Données Il existe des types et des soustypes qui sont prédéfinis, et il est possible aux programmes d'applica- tion de créer de nouveaux types et sous-types. Des ni- veaux de protection différents peuvent être établis pour des éléments de données tombant sous certains types et sous-types. D'une manière spécifique, un ensemble de rè- gles d'accès est spécifié pour chaque sous-type. Un en- semble de règles d'accès contient des règles associées à différents types ou sous-types d'éléments de données. L'accès à un élément de données d'un sous-type particu- lier est accordé si une seule règle quelconque de l'en- semble de règles correspondant est satisfaite. Chaque rè- gle d'accès comprend un mode et une ou plusieurs clauses d'accès; toutes les clauses d'accès doivent être satis- faites avant que la règle ne soit considérée comme satis- faite. Le mode indique le type d'accès autorisé si toutes les clauses contenues dans une règle sont satisfaites. Actuellement, deux modes d'accès sont définis: accès en lecture et écriture. Il existe actuellement trois types de clauses d'accès: Authenticode, Contrôle Binaire, et Descripteur de Sécurité. Authenticode vérifie que le programme d'ap- plication demandant l'accès aux données protégées est fiable et peut déterminer, le cas échéant, si la source, et par conséquent, l'application de la source, est digne de confiance. Le Contrôle Binaire garantit qu'un pro- gramme n'a pas été trafiqué depuis son installation. La clause Descripteur de Sécurité assure l'accès sur la base de listes de contrôle d'accès (ACL) sous Windows NT. Authenticode est un produit et service bien do- cumenté, commercialisé par Microsoft Corporation. Si la clause Authenticode a été spécifiée lors de la création d'un sous-type, un contrôle est effectué pour déterminer si l'application dont émane la demande a été signée ou non, et si elle a été signée, par qui l'a-t-elle été. La clause peut spécifier une racine particulière, un certi- ficateur, un éditeur (signataire), un nom de programme particulier, ou une combinaison particulière quelconque de ce qui précède. Aucun accès ne sera accordé à moins que les critères spécifiés ne soient satisfaits. Si aucun critère n'est spécifié, la vérification équivaut à per- mettre à n'importe quelle application ou module vérifié par Authenticode d'accéder aux données. Un contrôle via Authenticode vérifie aussi l'image binaire du module ins- pecté. Le Contrôle Binaire est implémenté en formant l'identifiant (connu sous le nom de "hash") d'une image binaire d'un programme d'application lors de l'initiali- sation. Lorsque le programme d'application demande des données à un instant ultérieur, le système de mémorisa- tion forme à nouveau l'identifiant ("hash") de l'image de la mémoire et le compare à l'identifiant originel. Les deux identifiants doivent coïncider avant que le système de mémorisation protégé n'autorise le programme d'appli- cation à accéder aux données demandées. Ainsi, si l'ap- plication a changé depuis qu'elle a été installée et, par conséquent, risque d'avoir été trafiquée, les données resteront protégées et l'accès aux données sera refusé à l'application. La clause Descripteur de Sécurité est destinée à ne permettre l'accès qu'à des utilisateurs ou des grou- pes spécifiés, et est implémentée sur les plates-formes Windows NT. Cette clause obtient les informations néces- saires concernant les utilisateurs et les groupes à par- tir des ACL contenus dans le descripteur de sécurité de Windows NT. Au niveau utilisateur, le serveur de mémorisa- tion permet d'accéder à des éléments de données indivi- duels en fonction de la personne qui utiliser couramment l'ordinateur; par défaut, seul l'utilisateur responsable de la création de l'élément de données est admis à y ac- céder. Cependant, un utilisateur peut modifier ce compor- tement par défaut en spécifiant des options appropriées lors de la création et de la sauvegarde des éléments de données, ou l'utilisateur peut modifier ultérieurement les droits d'accès aux données. Les utilisateurs et les programmes d'applica- tion peuvent spécifier des styles de sécurité, qui spéci- fient qu'un degré et/ou qu'un type de confirmation ou d'authentification est nécessaire pour accéder à un élé- ment de données particulier; par exemple, si un mot de passe est nécessaire. Le présent mode de réalisation, avec le fournisseur d'authentification par défaut, sup- porte les styles d'accès suivants: * Accès silencieux: aucune interac- tion-utilisateur requise. L'authentification est basée sur une procédure d'authentifica- tion du système d'exploitation de l'ordina- teur ou du réseau suivie précédemment. Dans la majeure partie des cas, ce type d'authen- tification repose sur la capacité de l'utili- sateur à entrer le mot de passe correct lors d'une procédure de connexion précédente, et aucune autre interaction n'est requise lors- que les données protégées font l'objet d'un accès dans la réalité. * Mot de passe de connexion: une boîte de dia- logue est présentée, priant l'utilisateur de bien vouloir entrer le mot de passe utilisé précédemment pour se connecter à l'ordinateur ou au réseau. * Mot de passe défini par l'utilisateur: l'utilisateur spécifie un mot de passe lors- qu'un élément est initialement mémorisé, et doit entrer le mot de passe avant de pouvoir accéder à nouveau aux données. De tels mots de passe peuvent différer pour des éléments de données différents, ou des groupes d'élé- ments de données peuvent être mémorisés sous le même mot de passe. * OK/annulation: lorsqu'une application tente d'accéder aux données, une boîte de dialogue apparaît. L'utilisateur répond à la boîte de dialogue en cliquant sur un bouton OK ou 're- fuser', autorisant ou refusant ainsi à un programme d'application demandeur l'accès aux données. Comme évident d'après les différents types de styles d'accès, l'accès à des éléments dans une mémorisa- tion protégée peut nécessiter une interaction avec l'uti- lisateur. Cette interaction est implémentée par l'utili- sation d'une boîte de dialogue d'alerte de l'utilisateur. D'une manière typique, l'utilisateur se verra prié d'in- troduire un mot de passe en réponse à une boîte de dialo- gue d'alerte de l'utilisateur. Cependant, des fournis- seurs d'authentification différents peuvent nécessiter des types de réponse qui diffèrent (comme l'insertion physique d'un jeton matériel ou des procédures d'authen- tification biométriques). Pour empêcher que des programmes de piratage ne présentent des boites de dialogue d'alerte de l'utilisa- teur qui soient similaires, et empêcher ainsi l'accès à des données secrètes, les boîtes de dialogue d'alerte de l'utilisateur peuvent être personnalisées par l'utilisa- teur. D'une manière spécifique, un utilisateur peut spé- cifier un arrière-plan ou un filigrane numérique particu- lier à utiliser dans la boîte de dialogue d'alerte de l'utilisateur. En variante, un tel filigrane peut être généré d'une manière aléatoire pour l'utilisateur. L'uti- lisateur se familiarisera avec le filigrane sélectionné, et reconnaîtra ainsi les boîtes de dialogue non-autorisées, générées par des applications utilisées à des fins de piratage. On va maintenant décrire comment s'effectuent le cryptage, le décryptage et l'authentification de don- nées. Des fournisseurs de mémorisation différents peuvent protéger de différentes manières les données mé- morisées. Cependant, un certain type de cryptographie se- ra habituellement utilisé. Le fournisseur de mémorisation par défaut décrit ici utilise un schéma de cryptage basé sur un mot de passe, dans lequel les éléments de données sont cryptés sur la base d'un mot de passe fourni par l'utilisateur, ou d'un autre code lié à l'authentifica- tion de l'utilisateur, avant de mémoriser les éléments de données. Lors de la récupération des éléments de données, le décryptage s'effectue sur la base du même mot de passe ou code. * Lorsqu'un élément de données est protégé par le style de sécurité "mot de passe défini par l'utilisateur" mentionné ci-dessus, l'utilisateur introduit d'une ma- nière explicite un mot de passe pour chaque élément de données lors d'une étape d'authentification qui est invo- quée avant de permettre d'accéder à un élément de données individuel. Dans le cas d'un "accès silencieux", cepen- dant, le cryptage et le décryptage s'effectuent sur la base d'un mot de passe ou d'un autre code qui est fourni par la personne qui utilise l'ordinateur lors d'une pro- cédure précédente d'authentification du système d'exploi- tation de l'ordinateur ou du réseau ou d'une procédure de connexion à celui-ci. D'une manière typique, le nom de connexion de l'utilisateur et un mot de passe sont utili- sés pour former ou obtenir une clé qui est utilisée pour le cryptage et le décryptage des éléments de données. Dans le mode de réalisation décrit, une techni- que à clé multi-niveau est utilisée pour crypter les élé- ments de données sur la base de codes ou de mots de passe fournis par l'utilisateur. Cette technique est illustrée sur la figure 3. Dans cette implémentation, le cryptage et le décryptage utilisent une ou plusieurs clés qui sont obtenues à partir des mots de passe ou codes de connexion fournis. Comme mentionné, le mot de passe ou le code peut être récupéré à partir d'une étape d'authentification précédente, ou le système de mémorisation peut inviter la personne qui utilise l'ordinateur à introduire un mot de passe. Généralement, une clé d'élément est générée d'une manière aléatoire pour chaque élément de données. L'élément de données est crypté avec sa clé d'élément correspondante. Une clé d'authentification d'élément est aussi générée d'une manière aléatoire pour chaque élément et est utilisée pour générer un code d'identification d'élément. Les codes d'identification d'élément sont uti- lisés pendant le décryptage afin de vérifier que les élé- ments de données sont correctement décryptés. La clé d'élément et la clé d'authentification d'élément sont alors cryptées en utilisant une clé maî- tresse. La clé maîtresse est un nombre qui est généré d'une manière aléatoire. Une clé d'authentification maî- tresse est aussi générée et est utilisée pour calculer un code d'authentification de clé de manière à ce que le dé- cryptage correct de la clé d'élément et de la clé d'au- thentification d'élément puisse être vérifié ultérieure- ment. Enfin, la clé maîtresse et la clé d'authentifica- tion maîtresse sont cryptées en utilisant un mot de passe qui est obtenu à partir de l'authentification ou l'iden- tification de l'utilisateur. En se reportant maintenant aux étapes spécifi- ques de la figure 3, un élément de données individuel qui est à crypter et à mémoriser est indiqué par la référence numérique 130. Une étape ou opération 131 est mise en oeuvre pour crypter l'élément de données 130 en utilisant une clé d'élément 132. D'une manière spécifique, une clé cryptographique 132 est utilisée pour effectuer un cryp- tage DES sur l'élément de données 130. La clé d'élément 132 est générée sous la forme d'un nombre aléatoire par le fournisseur de mémorisation par défaut. Le fournisseur de mémorisation exécute aussi une étape 133 qui consiste à générer un code d'authenti- fication d'élément pour l'élément de données 130 indivi- duel. Le code d'authentification d'élément est généré en utilisant un MAC (code d'authentification de message) en association avec une clé d'authentification d'élément 134 générée d'une manière aléatoire. Les MAC sont décrits dans le document de Schneier mentionné précédemment. Une autre étape 140 est effectuée pour crypter la clé d'élément 132 et la clé d'authentification d'élé- ment 134 avec une clé maîtresse 141, à nouveau en utili- sant le cryptage DES mentionné ci-dessus. La clé maî- tresse est un nombre aléatoire. Une étape 142 consiste à générer un code d'authentification de clé pour la combi- naison constituée de la clé d'élément et de la clé d'au- thentification d'élément. Le code d'authentification de clé est généré avec un MAC en association avec une clé d'authentification maîtresse 143 générée aléatoirement. Une étape 145 est exécutée pour crypter la clé maîtresse et la clé d'authentification maîtresse avec une clé-utilisateur 146. Il s'agit à nouveau d'un cryptage DES. La clé-utilisateur est obtenue à partir du mot de passe ou du code fourni par l'utilisateur, indiqué par la référence numérique 147 sur la figure 3. Pour générer la clé-utilisateur, le mot de passe 147 fourni par l'uti- lisateur est attaché à un nombre aléatoire appelé sel 148, et est haché lors d'une étape 149 en utilisant une fonction de hachage SHA-1. De ceci résulte un nombre qui est utilisé comme clé-utilisateur. Une fois ces étapes implémentées, le serveur de mémorisation mémorise l'élément de données individuel crypté, le code d'authentification d'élément, la clé d'élément cryptée, la clé d'authentification d'élément cryptée, le code d'authentification de clé, la clé maî- tresse cryptée et la clé d'authentification maîtresse cryptée, à récupérer ultérieurement lorsque le demande un programme d'application autorisé. La récupération s'effectue suivant l'opération inverse. Les éléments cryptés sont extraits de la mémori- sation. Le fournisseur de mémorisation déduit la clé- utilisateur du mot de passe fourni par l'utilisateur et utilise la clé-utilisateur pour décrypter la clé maî- tresse et la clé d'authentification maîtresse. La clé d'authentification maîtresse est utilisée en association avec le MAC spécifié pour vérifier que la clé maîtresse a été correctement décryptée. La clé maîtresse est alors utilisée pour décrypter une clé d'élément appropriée et la clé d'authentification d'élément correspondante. La clé d'authentification d'élément est utilisée en associa- tion avec le MAC pour vérifier que la clé d'élément a été correctement décryptée. La clé d'élément est alors utili- sée pour décrypter l'élément de données réel. Ce traitement permet que tous les éléments de données de l'utilisateur soient gérés en utilisant une clé maîtresse unique qui est à son tour cryptée en fonc- tion du mot de passe de l'utilisateur. L'avantage de ce schéma est que les éléments de données n'ont pas à être recryptés lorsque l'utilisateur change de mot de passe. A la place, seule la clé maîtresse doit être à nouveau cryptée. On va maintenant décrire comment s'effectue la vérification de l'intégrité du système de mémorisation. Le serveur de mémorisation, les fournisseurs de mémorisation et les fournisseurs d'authentification uti- lisent un mécanisme de verrouillage de la sécurité afin d'empêcher les violations de la sécurité qui pourraient résulter d'un traficage des composants du système. Ce mé- canisme utilise des techniques cryptographiques. Une première motivation du mécanisme de ver- rouillage de la sécurité est d'empêcher le chargement de fournisseurs non-autorisés par le serveur de mémorisa- tion. Il est particulièrement important d'empêcher qu'un module non-autorisé ne puisse se dissimuler sous l'appa- rence d'un fournisseur autorisé, du fait qu'un tel module non-autorisé pourrait alors dérober des données secrètes au sein du système. Une autre motivation est d'empêcher que le serveur de mémorisation ne puisse lui-même être trafiqué. Lorsque le serveur et les fournisseurs sont ex- pédiés, ceux-ci sont signés numériquement avec la clé privée d'une paire de clés cryptographiques publi- que/privée - la clé privée possède une clé publique cor- respondante. La clé publique est alors codée matérielle- ment dans les divers modules du serveur et des fournis- seurs. Le serveur et les fournisseurs sont configurés de manière à vérifier leur signature en utilisant la clé cryptographique publique à chaque fois qu'un composant individuel est chargé et est exécuté. Lorsque le serveur est chargé, celui-ci contrôle tout d'abord sa propre in- tégrité en contrôlant sa propre signature numérique avec la clé publique. Le serveur contrôle ensuite les signatu- res numériques des autres composants du noyau lorsque ceux-ci sont chargés. A chaque fois qu'un composant est chargé, il contrôle la signature numérique du serveur. Si le contrôle de l'intégrité se traduit par un échec, aucun des composants ne fonctionnera. On va maintenant décrire comment s'effectue l'authentification de programmes d'application deman- deurs. Comme décrit ci-dessus, l'accès à des éléments de données peut être limité sur la base des programmes d'application qui tentent d'accéder aux éléments de don- nées. Pour que cette caractéristique soit fiable, le sys- tème de mémorisation doit vérifier que les programmes d'application sont bien ceux qu'ils prétendent être, et qu'ils n'ont pas été trafiqués. Ce traitement s'appelle une authentification de programme. Une première option est d'authentifier les programmes sur la base d'un con- trôle binaire. Une telle authentification est effectuée par deux modules de serveur de mémorisation: le module d'identification et le module d'exécution. Le module d'identification est responsable de l'interrogation du client qui appelle le serveur de mémo- risation. Pour identifier un traitement associé à une de- mande, les étapes suivantes sont mises en oeuvre: 1. Le programme d'application du client s'iden- tifie auprès du serveur, en présentant deux éléments d'information: un Identificateur de traitement ("process ID"), et un pointeur de tâche ("thread handle"). L'Identificateur de traitement" est obtenu en utilisant l'ap- pel-système GetCurrentProcessId(); le poin- teur de tâche est obtenu en utilisant les appels-système GetCurrentThread() et Dupli- cateHandle(). 2. Le serveur de mémorisation ouvre un pointeur au client, en utilisant l'Identificateur de traitement dans un appel à l'appel-système OpenProcess(). Le serveur de mémorisation sauvegarde ce pointeur en vue d'une utilisa- tion ultérieure. 3. Le client formule des demandes d'accès à des éléments de données. 4. Le serveur de mémorisation utilise le poin- teur de traitement obtenu ci-dessus pour analyser l'espace des adresses-mémoire asso- cié au traitement-client. Le serveur utilise aussi ce pointeur pour demander au système d'exploitation sous-jacent quels sont les modules exécutables (fichiers.exe,.dll, etc.) présents dans l'opération associée, en plus de déterminer les adresses de charge- ment des modules; le procédé exact utilisé pour interroger le système d'exploitation varie selon le système d'exploitation. 5. Le serveur a maintenant une liste complète de modules associée au client, et l'utilise pour analyser la pile d'appels associée au pointeur de tâche obtenu ci-dessus. L'ap- pel-système StackWalk() est utilisé pour dé- terminer la chaîne d'appels associée au client. Le module d'exécution utilise les résultats fournis par le module d'identification pour effectuer les contrôles suivants: 1. Vérifier que l'image chargée dans le traite- ment-client n'a pas été trafiquée sur le disque. Ceci s'effectue en mémorisant une représentation cryptographique du ou des fi- chiers auxquels est accordé l'accès. Cette représentation cryptographique est mémorisée en même temps que les données. On peut uti- liser deux représentations cryptographiques du fichier: a Le fichier entier est lu et est ensuite soumis au hachage cryptographique SHA-1. La valeur de sortie de l'identifiant ("hash") est mémorisée en même temps que les données. Lorsqu'un accès subséquent aux données est demandé, l'identifiant est recalculé pour le fichier mémorisé sur le disque, puis est comparé à celui mémorisé en même temps que les données. Si le résultat de la comparaison s'avère correct, on passe au contrôle 2, ci-dessous. * Le fichier est soumis à une validation sur la base d'un certificat à clé publi- que. Des appels à Microsoft Authenticode sont alors utilisés pour vérifier que l'image n'a pas été trafiquée. Authenti- code gère le hachage de l'image du dis- que d'une manière interne. Cette repré- sentation cryptographique du fichier est plus souple, du fait qu'elle supporte aussi une validation vis-à-vis de divers champs contenus dans le certificat joint au fichier spécifique. Après la fin de la vérification par Authenticode, le système analyse le contenu du certifi- cat, afin de s'assurer qu'il coïncide avec le contenu mémorisé en même temps que les données faisant l'objet d'un ac- cès. 2. Vérifier que l'image sur disque coïncide avec celle chargée dans le traite- ment-client. * Le module à contrôler est appliqué "map- pé" sur l'espace d'adressage du serveur, en utilisant les appels-système de l'API CreateFileMapping() et MapViewOfFile(). * Des corrections par réallocation sont appliquées à l'image mappée si néces- saire - uniquement si l'image n'a pas été chargée à l'adresse préférée dans l'espace d'adressage du client. * Le système exécute une boucle sur l'en- tête de l'image, en recherchant les sec- tions validées en lecture seule, telles que les sections de code, les ressour- ces, et les données validées en lecture seule. Pour chaque section, il met à jour un identifiant ("hash") cryptogra- phique sur la base de la fonction SHA-1. * Le pointeur de traitement ("process han- dle") délivré en sortie par le module d'identification est maintenant utilisé pour lire l'espace des adresses- mémoire dans lequel est chargé le module. Ceci s'effectue en utilisant l'appel-système ReadProcessMemory(). Chaque section de la mémoire est lue comme souligné à l'étape précédente, en mettant à jour un identifiant ("hash") cryptographique à mesure que s'effectue le traitement. * Le système compare les deux identifiants résultant des étapes immédiatement pré- cédentes. Si ceux-ci coïncident, l'image en mémoire n'a pas été trafiquée. On va maintenant évoquer les fonctions de l'in- terface application. Comme décrit ci-dessus, les interfaces sont ex- posées à des programmes d'application, ce qui fait que les programmes d'application peuvent bénéficier de carac- téristiques de mémorisation protégée sans avoir à implé- menter de schémas de cryptage sophistiqués ni avoir à faire des appels RPC. En conclusion, la présente invention aboutit à une architecture polyvalente et efficace qui présente un certains nombres d'avantages par rapport à la technique antérieure. Un avantage important est que des programmes d'application différents peuvent utiliser un seul serveur fourni pour mémoriser des données de noyau secrètes dans une zone de mémorisation centrale. Ceci favorise la com- patibilité entre les applications et évite un temps-système ("overhead") important aux applications. L'interface-utilisateur est une zone qui bénéficie de la compatibilité assurée par le système de mémorisation dé- crit ci-dessus, du fait que des invitations-utilisateur sont générées par le système, plutôt que par les program- mes d'application individuels. La mémorisation uniforme des éléments de données leur permet aussi d'être gérés par un programme de gestion unique qui est indépendant des programmes d'application, eux-mêmes. Un autre avantage important de la présente in- vention est que les détails sous-jacents, inhérents à la sécurisation des éléments de données, sont dissimulés aux programmes d'application appelants. Par conséquent, les développeurs de programmes n'ont pas à implémenter de me- sures de sécurité sophistiquées; de telles mesures peu- vent être implémentées par de simples appels au système de mémorisation décrit ici. Un avantage supplémentaire est que les nouvelles technologies, telles que les cartes à mémoire, pourront être utilisées par les programmes d'application, sans avoir à reprogrammer d'une manière extensive. La présente invention protège les secrets à l'encontre des piratages orientés utilisateur et orientés logiciel, y compris à l'encontre des agressions par des virus. D'une manière significative, le contrôle des accès est géré séparément des programmes d'application qui gé- nèrent et accèdent aux éléments de données. Du fait que les applications n'ont pas directement accès aux données de cryptage ou à d'autres données de commande, un accès à une donnée n'implique pas un accès à une autre donnée. De plus, le système de mémorisation, lui-même, ne contient pas les informations nécessaires pour décrypter les élé- ments de données mémorisés. Au contraire, l'utilisateur doit être présent et doit fournir un mot de passe correct pour permettre le décryptage des données. Un autre avantage important de la présente in- vention est que les utilisateurs ne se voient pas con- traints d'entrer d'une manière explicite des mots de passe lorsqu'un accès à des données est requis. Au con- traire, l'authentification de l'utilisateur est effectuée une fois, lorsque l'utilisateur se connecte à l'ordina- teur ou au réseau. Cette information de connexion est utilisée pour l'authentification de l'utilisateur et pour obtenir des clés servant au cryptage et au décryptage des données. Bien que la présente invention ait été décrite dans un langage spécifique aux caractéristiques structu- relles et/ou aux étapes méthodologiques, il doit être compris que la présente invention n'est pas nécessaire- ment limitée aux caractéristiques ou aux étapes spécifi- ques décrites. Au contraire, les caractéristiques et les étapes spécifiques ne sont décrites qu'à titre d'exemple d'implémentation de l'invention revendiquée. REVENDICATIONS 1. Système pour mémoriser des éléments de don- nées et les protéger à l'encontre d'un accès non-autorisé, caractérisé en ce qu'il comporte: un serveur de mémorisation (104) qui reçoit des éléments de données (130) en provenance de programmes d'application (102) et retourne de tels éléments de don- nées en réponse à des demandes émanant de programmes d'application, un ou plusieurs fournisseurs de mémorisation (106) qui sont appelés par le serveur de mémorisation (104) et qui mémorisent et récupèrent d'une manière sécu- risée les éléments de données, un ou plusieurs fournisseurs d'authentification (108) qui sont appelés par le serveur de mémorisation (104) afin d'identifier des utilisateurs d'ordinateurs courants. 2. Système selon la revendication 1, caractéri- sé en ce que le serveur de mémorisation (104) est confi- guré pour appeler des fournisseurs de mémorisation ins- tallables. 3. Système selon la revendication 1, caractéri- sé en ce que le serveur de mémorisation (104) est confi- guré pour appeler des fournisseurs d'authentification installables. 4. Système selon la revendication 1, caractéri- sé en ce que le serveur de mémorisation (104) s'exécute dans un espace d'adressage qui diffère de celui des pro- grammes d'application (102). 5. Système selon la revendication 1, caractéri- sé en ce que le serveur de mémorisation (104) s'exécute dans un espace d'adressage qui diffère de celui des pro- grammes d'application (102) et est appelé via des appels RPC. 6. Système selon la revendication 1, caractéri- sé en ce que ledit ou lesdits fournisseurs d'authentifi- cation (108) comprennent un fournisseur d'authentifica- tion qui identifie les identificateurs sur la base d'une authentification précédente du réseau. 7. Système selon la revendication 1, caractéri- sé en ce que ledit ou lesdits fournisseurs de mémorisa- tion (106) comprennent un fournisseur de mémorisation qui crypte les éléments de données avant de les mémoriser et décrypte les éléments de données avant de les récupérer. 8. Système selon la revendication 1, caractéri- sé en ce que ledit ou lesdits fournisseurs de mémorisa- tion (106) comprennent un fournisseur de mémorisation qui vérifie l'intégrité des éléments de données lorsqu'il les récupère. 9. Système selon la revendication 1, caractéri- sé en ce que ledit ou lesdits fournisseurs de mémorisa- tion (106) comprennent un fournisseur de mémorisation qui crypte et décrypte les éléments de données en utilisant une ou plusieurs clés qui sont obtenues à partir de l'au- thentification de l'utilisateur courant de l'ordinateur. 10. Système selon la revendication 1, caracté- risé en ce que ledit ou lesdits fournisseurs de mémorisa- tion (106) comprennent un fournisseur de mémorisation qui crypte et décrypte les éléments de données en utilisant une ou plusieurs clés qui sont obtenues à partir d'un code fourni par l'utilisateur, et en ce que le serveur de mémorisation (104) invite l'utilisateur courant de l'or- dinateur à entrer le code à fournir par l'utilisateur. 11. Système selon la revendication 1, caracté- risé en ce que ledit ou lesdits fournisseurs de mémorisa- tion (106) comprennent un fournisseur de mémorisation qui crypte et décrypte les éléments de données en utilisant une ou plusieurs clés qui sont obtenues à partir d'un code de connexion au réseau fourni par l'utilisateur cou- rant de l'ordinateur. 12. Système selon la revendication 1, caracté- risé en ce que ledit ou lesdits fournisseurs de mémorisa- tion (106) comprennent un fournisseur de mémorisation qui mémorise et récupère d'une manière sécurisée les éléments de données en utilisant une ou plusieurs clés qui sont obtenues à partir d'un code fourni par l'utilisateur. 13. Système selon la revendication 1, caracté- risé en ce que ledit ou lesdits fournisseurs de mémorisa- tion (106) comprennent un fournisseur de mémorisation qui mémorise et récupère d'une manière sécurisée les éléments de données en utilisant une ou plusieurs clés qui sont obtenues à partir d'un code de connexion au réseau fourni par l'utilisateur courant de l'ordinateur. 14. Système selon la revendication 1, caracté- risé en ce que ledit ou lesdits fournisseurs de mémorisa- tion (106) comprennent un fournisseur de mémorisation qui mémorise les éléments de données en suivant les étapes consistant à: crypter les éléments de données (130) indivi- duels avec des clés d'élément (132), crypter les clés d'élément (132) avec une clé maîtresse (141), crypter la clé maîtresse (141) avec une clé-utilisateur (146) qui est obtenue à partir d'un code fourni par l'utilisateur, mémoriser les éléments de données individuels cryptés, les clés d'élément cryptées, et la clé maîtresse cryptée. 15. Système selon la revendication 1, caracté- risé en ce que ledit ou lesdits fournisseurs de mémorisa- tion (106) comprennent un fournisseur de mémorisation qui mémorise les éléments de données en suivant les étapes consistant à: crypter les éléments de données (130) indivi- duels avec des clés d'élément (132), générer des codes d'authentification d'élément, pour les éléments de données (130) individuels, en utili- sant des clés d'authentification d'élément (134), crypter les clés d'élément (132) et les clés d'authentification d'élément (134) avec une clé maîtresse (141), générer des codes d'authentification de clé, pour les clés d'élément (132) et les clés d'authentifica- tion d'élément (134), en utilisant une clé d'authentifi- cation maîtresse (143), crypter la clé maîtresse (141) et la clé d'au- thentification maîtresse (143) avec une clé-utilisateur (146) qui est obtenue à partir d'un code fourni par l'utilisateur, mémoriser les éléments de données individuels cryptés, les codes d'authentification d'élément, les clés d'élément cryptées, les clés d'authentification d'élément cryptées, les codes d'authentification de clé, la clé maîtresse cryptée, la clé d'authentification maîtresse cryptée. 16. Système selon la revendication 1, caracté- risé en ce que ledit ou lesdits fournisseurs de mémorisa- tion (106) comprennent un fournisseur de mémorisation qui récupère les éléments de données en suivant les étapes consistant à: récupérer des éléments de données individuels cryptés, les clés d'élément cryptées correspondant aux éléments de données individuels cryptés, et une clé maî- tresse cryptée, décrypter la clé maîtresse cryptée avec une cléutilisateur (146) qui est obtenue à partir d'un code fourni par l'utilisateur, décrypter les clés d'élément cryptées avec la clé maîtresse décryptée, décrypter des éléments de données individuels cryptés avec les clés d'élément décryptées correspondan- tes. 17. Système selon la revendication 1, caracté- risé en ce que le serveur de mémorisation (104) permet d'accéder à des éléments de données (130) individuels en fonction de l'utilisateur courant de l'ordinateur. 18. Système selon la revendication 1, caracté- risé en ce que le serveur de mémorisation (104) ne re- tourne des éléments de données demandés qu'à des program- mes d'application demandeurs autorisés. 19. Système selon la revendication 1, caracté- risé en ce que le serveur de mémorisation (104) ne re- tourne des éléments de données demandés qu'à des program- mes d'application demandeurs autorisés, et en ce que le serveur de mémorisation (104) authentifie les programmes d'application demandeurs avant de leur retourner des élé- ments de données individuels. 20. Système selon la revendication 1, caracté- risé en ce que le serveur de mémorisation (104) ne re- tourne des éléments de données demandés qu'à des program- mes d'application demandeurs autorisés, et en ce que le serveur de mémorisation (104) authentifie le programme d'application demandeur en utilisant la cryptographie à clé publique avant de retourner des éléments de données individuels. 21. Système selon la revendication 1, caracté- risé en ce que le serveur de mémorisation (104) répond aux demandes émanant de programmes d'application en pré- sentant des dialogues-utilisateur permettant à l'utilisa- teur courant de l'ordinateur de spécifier les mots de passe à utiliser par le fournisseur de mémorisation (106) pour mémoriser et récupérer d'une manière sécurisée des éléments de données. 22. Système selon la revendication 1, caracté- risé en ce que le serveur de mémorisation (104), les fournisseurs de mémorisation (106) et les fournisseurs d'authentification (108) sont signés individuellement par une clé cryptographique privée qui correspond à une clé cryptographique publique, le serveur de mémorisation (104), les fournisseurs de mémorisation (106) et les fournisseurs d'authentification (108) étant configurés de manière à vérifier les signatures des uns et des autres en utilisant la clé cryptographique publique. 23. Système pour mémoriser des éléments de don- nées et les protéger à l'encontre d'un accès non-autorisé, caractérisé en ce qu'il comporte: un serveur de mémorisation (104) qui reçoit des éléments de données (130) en provenance de programmes d'application (102), et retourne de tels éléments de don- nées en réponse à des demandes émanant de programmes d'application (102), le serveur de mémorisation (104) s'exécutant dans un espace d'adressage qui diffère de ce- lui des programmes d'application (102) et étant appelé via des appels RPC, un fournisseur de mémorisation (106) qui est appelé par le serveur de mémorisation (104) afin de mémo- riser et récupérer d'une manière sécurisée les éléments de données, le fournisseur de mémorisation (106) cryptant les éléments de données avant de les mémoriser en utili- sant une ou plusieurs clés qui sont obtenues à partir de l'authentification de l'utilisateur courant de l'ordina- teur, le fournisseur de mémorisation (106) vérifiant l'intégrité des éléments de données lorsqu'il les récu- père, un fournisseur d'authentification (108) qui est appelé par le serveur de mémorisation (104) afin d'iden- tifier les utilisateurs d'ordinateurs courants, le four- nisseur d'authentification identifiant les utilisateurs sur la base d'une procédure de connexion au système d'ex- ploitation suivie précédemment. 24. Système selon la revendication 23, caracté- risé en ce que ladite ou lesdites clés sont obtenues à partir d'un code de connexion au système d'exploitation fourni par l'utilisateur courant de l'ordinateur. 25. Système selon la revendication 24, caracté- risé en ce que ladite ou lesdites clés sont obtenues à partir d'un code fourni par l'utilisateur. 26. Système selon la revendication 23, caracté- risé en ce que le fournisseur de mémorisation (106) mémo- rise les éléments de données en suivant les étapes con- sistant à: crypter les éléments de données (130) indivi- duels avec des clés d'élément (132), crypter les clés d'élément (132) avec une clé maîtresse (141), crypter la clé maîtresse (141) avec une clé-utilisateur (146) qui est obtenue à partir d'un code fourni par l'utilisateur, mémoriser les éléments de données individuels cryptés, les clés d'élément cryptées, et la clé maîtresse cryptée. 27. Système selon la revendication 23, caracté- risé en ce que le fournisseur de mémorisation (106) mémo- rise les éléments de données en suivant les étapes con- sistant à: crypter les éléments de données (130) indivi- duels avec des clés d'élément (132), générer des codes d'authentification d'élément, pour les éléments de données (130) individuels, en utili- sant des clés d'authentification d'élément (134), crypter les clés d'élément (132) et les clés d'authentification d'élément (134) avec une clé maîtresse (141), générer des codes d'authentification de clé, pour les clés d'élément (132) et les clés d'authentifica- tion d'élément (134), en utilisant une clé d'authentifi- cation maîtresse (143), crypter la clé maîtresse (141) et la clé d'au- thentification maîtresse (143) avec une clé-utilisateur (146) qui est obtenue à partir d'un code fourni par l'utilisateur, mémoriser les éléments de données individuels cryptés, les codes d'authentification d'élément, les clés d'élément cryptées, les clés d'authentification d'élément cryptées, les codes d'authentification de clé, la clé maîtresse cryptée, et la clé d'authentification maîtresse cryptée. 28. Système selon la revendication 23, caracté- risé en ce que le fournisseur de mémorisation (106) récu- père des éléments de données en suivant les étapes con- sistant à: récupérer des éléments de données individuels cryptés, les clés d'élément cryptées correspondant aux éléments de données individuels cryptés, et une clé maî- tresse cryptée, décrypter la clé maîtresse cryptée avec une cléutilisateur (146) qui est obtenue à partir d'un code fourni par l'utilisateur, décrypter les clés d'élément cryptées avec la clé maîtresse (141) décryptée, décrypter les éléments de données individuels cryptés avec les clés d'élément (132) décryptées corres- pondantes. 29. Système selon la revendication 23, caracté- risé en ce que le serveur de mémorisation (104) ne re- tourne des éléments de données demandés qu'à des program- mes d'application demandeurs autorisés. 30. Système selon la revendication 23, caracté- risé en ce que le serveur de mémorisation (104) ne re- tourne des éléments de données demandés qu'à des program- mes d'application demandeurs autorisés, et en ce que le serveur de mémorisation (104) authentifie les programmes d'application demandeurs avant de leur retourner des élé- ments de données individuels. 31. Système selon la revendication 23, caracté- risé en ce que le serveur de mémorisation (104) ne re- tourne des éléments de données demandés qu'à des program- mes d'application demandeurs autorisés, et en ce que le serveur de mémorisation (104) authentifie les programmes d'application demandeurs en utilisant la cryptographie à clé publique avant de retourner des éléments de données individuels. 32. Système selon la revendication 23, caracté- risé en ce que le serveur de mémorisation (104) répond aux demandes émanant de programmes d'application en pré- sentant des dialogues-utilisateur permettant à l'utilisa- teur courant de l'ordinateur de spécifier les mots de passe à utiliser par le fournisseur de mémorisation pour mémoriser et récupérer d'une manière sécurisée des élé- ments de données. 33. Système selon la revendication 23, caracté- risé en ce que le serveur de mémorisation (104) et le fournisseur de mémorisation (106) sont signés individuel- lement par une clé cryptographique privée qui correspond à une clé cryptographique publique, le serveur de mémori- sation (104) et le fournisseur de mémorisation (106) étant configurés de manière à vérifier leur signature en utilisant la clé cryptographique publique. 34. Procédé pour mémoriser des données secrètes associées à des utilisateurs et à des applications et les protéger à l'encontre d'un accès non-autorisé, caractéri- sé en ce qu'il comporte les étapes consistant à: authentifier un utilisateur d'ordinateur cou- rant sur la base d'une authentification de connexion an- térieure effectuée par un système d'exploitation, recevoir des éléments de données (130) indivi- duels en provenance de programmes d'application (102), crypter les éléments de données (130) en utili- sant une ou plusieurs clés qui sont obtenues à partir de ladite authentification de connexion antérieure de l'uti- lisateur d'ordinateur courant, mémoriser les éléments de données cryptés. 35. Procédé selon la revendication 34, caracté- risé en ce que l'étape de mémorisation consiste à mémori- ser les éléments de données cryptés de programmes d'ap- plication différents dans une zone de mémorisation com- mune. 36. Procédé selon la revendication 34, caracté- risé en ce qu'il comporte en outre une étape consistant à obtenir ladite ou lesdites clés sur la base d'un mot de passe de connexion à l'ordinateur. 37. Procédé selon la revendication 34, caracté- risé en ce que l'étape de cryptage consiste à: crypter les éléments de données (130) indivi- duels avec des clés d'élément (132), crypter les clés d'élément (132) avec une clé maitresse (141), crypter la clé maîtresse (141) avec une clé-utilisateur (146) qui est obtenue à partir de ladite authentification précédente de l'utilisateur courant de l'ordinateur, le procédé comportant en outre une étape con- sistant à mémoriser les clés d'élément cryptées et la clé maîtresse cryptée. 38. Procédé selon la revendication 34, caracté- risé en ce qu'il comporte en outre les étapes supplémen- taires consistant à: récupérer des éléments de données individuels cryptés, les clés d'élément cryptées correspondant aux éléments de données individuels cryptés, et une clé maî- tresse cryptée, décrypter la clé maîtresse cryptée avec une cléutilisateur (146) qui est obtenue à partir de ladite authentification précédente de l'utilisateur courant de l'ordinateur, décrypter les clés d'élément (132) cryptées avec la clé maîtresse (141) décryptée, décrypter les éléments de données (130) indivi- duels cryptés avec les clés d'élément (132) décryptées correspondantes. 39. Procédé selon la revendication 34, caracté- risé en ce qu'il comporte une étape supplémentaire con- sistant à autoriser l'accès à des éléments de données in- dividuels en fonction de l'utilisateur courant de l'ordi- nateur. 40. Procédé selon la revendication 34, caracté- risé en ce qu'il comporte une étape supplémentaire con- sistant à ne retourner des éléments de données demandés qu'à des programmes d'application demandeurs autorisés. 41. Procédé selon la revendication 34, caracté- risé en ce qu'il comporte les étapes additionnelles con- sistant à: ne retourner des éléments de données qu'à des programmes d'application demandeurs autorisés, authentifier les programmes d'application de- mandeurs avant de retourner des éléments de données indi- viduels. 42. Procédé selon la revendication 34, caracté- risé en ce qu'il comporte une étape supplémentaire con- sistant à présenter des dialogues-utilisateur en réponse à des demandes émanant de programmes d'application con- cernant des éléments de données, les dialo- gues-utilisateur permettant à l'utilisateur courant de l'ordinateur de spécifier des mots de passe à utiliser par le fournisseur de mémorisation (106) pour décrypter *les éléments de données. 43. Procédé pour mémoriser des données secrètes associées à des utilisateurs et à des applications et les protéger à l'encontre d'un accès non-autorisé, caractéri- sé en ce qu'il comporte les étapes consistant à: recevoir des éléments de données (130) indivi- duels en provenance de programmes d'application (102), crypter les éléments de données (130) indivi- duels avec des clés d'élément (132), crypter les clés d'élément (132) avec une clé maîtresse (141), crypter la clé maîtresse (141) avec une clé-utilisateur (146), mémoriser les éléments de données cryptés, les clés d'élément cryptées, et la clé maîtresse cryptee. 44. Procédé selon la revendication 43, caracté- risé en ce qu'il comporte en outre les étapes supplémen- taires consistant à: générer des codes d'authentification d'élément, pour les éléments de données (130) individuels, en utili- sant des clés d'authentification d'élément (134), crypter les clés d'authentification d'élément (134) avec la clé maîtresse (141), générer des codes d'authentification de clé, pour les clés d'élément (132) et les clés d'authentifica- tion d'élément (134), en utilisant la clé d'authentifica- tion maîtresse (143), crypter la clé d'authentification maîtresse (143) avec la clé-utilisateur (146), mémoriser les codes d'authentification d'élé- ment, les clés d'élément cryptées, les clés d'authentifi- cation d'élément cryptées, les codes d'authentification de clé, et la clé d'authentification maîtresse cryptée. 45. Procédé selon la revendication 43, caracté- risé en ce qu'il comporte en outre les étapes supplémen- taires consistant à: récupérer des éléments de données (130) indivi- duels cryptés, les clés d'élément (132) cryptées corres- pondant aux éléments de données (130) individuels cryptés récupérés, et la clé maîtresse (141) cryptée, décrypter la clé maîtresse (141) cryptée avec la clé-utilisateur (146), décrypter les clés d'élément (132) cryptées avec la clé maîtresse (141) décryptée, décrypter les éléments de données (130) indivi- duels cryptés avec les clés d'élément (132) décryptées correspondantes. 46. Procédé selon la revendication 43, caracté- risé en ce qu'il comporte en outre une étape consistant à obtenir la clé-utilisateur (146) à partir d'une étape d'authentification de l'utilisateur. 47. Procédé selon la revendication 43, caracté- risé en ce qu'il comporte en outre une étape consistant à obtenir la cléutilisateur (146) à partir d'un code de connexion à l'ordinateur. 48. Procédé selon la revendication 43, caracté- risé en ce qu'il comporte en outre une étape consistant à obtenir la clé-utilisateur (146) à partir d'une authenti- fication antérieure de l'utilisateur courant de l'ordina- teur. 49. Procédé selon la revendication 43, caracté- risé en ce qu'il comporte en outre une étape consistant à obtenir la clé-utilisateur (146) à partir d'une authenti- fication de l'utilisateur courant de l'ordinateur par le réseau. 50. Procédé pour mémoriser des données secrètes associées à des utilisateurs et à des applications et les protéger à l'encontre d'un accès non-autorisé, caractéri- sé en ce qu'il comporte les étapes consistant à: recevoir des éléments de données (130) indivi- duels en provenance de programmes d'application (102), crypter les éléments de données (130) en utili- sant une ou plusieurs clés qui sont obtenues à partir de un ou plusieurs mots de passe fournis par l'utilisateur, mémoriser les éléments de données (130) cryp- tés, récupérer et décrypter les éléments de données (130) cryptés mémorisés en réponse à des demandes émanant de programmes d'application. 51. Procédé selon la revendication 50, caracté- risé en ce qu'il comporte une étape supplémentaire con- sistant à présenter des dialogues-utilisateur en réponse à des demandes émanant de programmes d'application con- cernant des éléments de données, les dialo- gues-utilisateur permettant à l'utilisateur courant de l'ordinateur de spécifier les mots de passe à fournir par l'utilisateur. 52. Procédé selon la revendication 34, caracté- risé en ce qu'il comporte l'étape supplémentaire consis- tant à: permettre à un utilisateur de spécifier un type d'authentification d'utilisateur qui sera effectué avant d'effectuer les étapes de récupération et de décryptage. 53. Procédé selon la revendication 50, caracté- risé en ce qu'il comporte en outre une étape consistant à obtenir un mot de passe par défaut de l'utilisateur du- rant une procédure de connexion à l'ordinateur. 54. Procédé selon la revendication 50, caracté- risé en ce qu'il comporte en outre une étape consistant à obtenir un mot de passe par défaut de l'utilisateur du- rant une procédure de connexion à l'ordinateur, le mot de passe par défaut de l'utilisateur comprenant un mot de passe de connexion à l'ordinateur. 55. Procédé selon la revendication 50, caracté- risé en ce qu'il comporte les étapes supplémentaires con- sistant à: obtenir un mot de passe par défaut de l'utili- sateur durant une procédure de connexion au réseau, obtenir des mots de passe supplémentaires de l'utilisateur en présentant des dialoguesutilisateur qui permettent à l'utilisateur courant de l'ordinateur de spécifier de tels mots de passe supplémentaires. 56. Procédé selon la revendication 50, caracté- risé en ce qu'il comporte une étape supplémentaire con- sistant à présenter des dialogues-utilisateur en réponse à des demandes émanant de programmes d'application (102) concernant des éléments de données (130), les dialo- gues-utilisateur permettant à l'utilisateur courant de l'ordinateur de spécifier les mots de passe à utiliser par le fournisseur de mémorisation (106) pour décrypter les éléments de données (130). 57. Procédé selon la revendication 50, caracté- risé en ce qu'il comporte une étape supplémentaire con- sistant à autoriser l'accès à des éléments de données (130) individuels en fonction de l'utilisateur courant de l'ordinateur. 58. Procédé selon la revendication 50, caracté- risé en ce qu'il comporte une étape supplémentaire con- sistant à ne retourner des éléments de données (130) de- mandés qu'à des programmes d'application (102) demandeurs autorisés. 59. Procédé selon la revendication 50, l'étape de cryptage comprenant le cryptage des éléments de don- nées (130) individuels avec des clés d'élément (132), ca- ractérisé en ce qu'il comporte les étapes supplémentaires consistant à: recevoir des éléments de données (130) indivi- duels en provenance de programmes d'application (102), crypter les clés d'élément (132) avec une clé maîtresse (141), crypter la clé maîtresse (141) avec une clé-utilisateur (146) qui est obtenue à partir dudit ou desdits mots de passe fournis par l'utilisateur. 60. Procédé pour mémoriser des données secrètes associées à des utilisateurs et à des applications et les protéger à l'encontre d'un accès non-autorisé, caractéri- sé en ce qu'il comporte les étapes consistant à: recevoir des éléments de données (130) indivi- duels en provenance de programmes d'application (102), crypter les éléments de données (130) en utili- sant une ou plusieurs clés qui sont obtenues à partir d'un ou plusieurs mots de passe fournis par l'utilisa- teur, mémoriser les éléments de données (130) cryp- tés, récupérer et décrypter les éléments de données (130) cryptés mémorisés en réponse à des demandes émanant de programmes d'application (102), autoriser l'accès à des éléments de données (130) individuels en fonction de l'utilisateur courant de l'ordinateur, ne retourner des éléments de données demandés qu'à des programmes d'application demandeurs autorisés. 61. Procédé selon la revendication 60, caracté- risé en ce qu'un programme d'application exécute une étape consistant à spécifier les programmes d'application qui sont autorisés à accéder aux éléments de données res- pectifs. 62. Procédé selon la revendication 60, caracté- risé en ce qu'un programme d'application exécute une étape consistant à spécifier les utilisateurs d'ordina- teurs qui sont autorisés à accéder à des éléments de don- nées respectifs. 63. Procédé selon la revendication 60, caracté- risé en ce qu'il comporte en outre une étape consistant à authentifier les programmes d'application demandeurs au- torisés en utilisant la cryptographie à clé publique avant de retourner des éléments de données individuels. 64. Procédé selon la revendication 60, caracté- risé en ce que l'étape de mémorisation consiste à mémori- ser les éléments de données cryptés en provenance de pro- grammes d'application différents dans une zone de mémori- sation commune. 65. Procédé pour mémoriser des données secrètes associées à des utilisateurs et à des applications et les protéger à l'encontre d'un accès non-autorisé, caractéri- sé en ce qu'il comporte les étapes consistant à: recevoir des éléments de données (130) indivi- duels en provenance de programmes d'application (102) différents, crypter les éléments de données (130), mémoriser les éléments de données (130) cryp- tés, en provenance des différents programmes d'applica- tion (102), dans une zone de mémorisation commune. 66. Procédé selon la revendication 65, caracté- risé en ce qu'il comporte une étape supplémentaire con- sistant à autoriser l'accès à des éléments de données in- dividuels en fonction de l'utilisateur courant de l'ordi- nateur. 67. Procédé selon la revendication 65, caracté- risé en ce qu'il comporte une étape supplémentaire con- sistant à ne retourner des éléments de données demandés qu'à des programmes d'application demandeurs autorisés. 68. Procédé selon la revendication 65, caracté- risé en ce qu'il comporte les étapes supplémentaires con- sistant à: ne retourner des éléments de données demandés qu'à des programmes d'application demandeurs autorisés, authentifier les programmes d'application de- mandeurs avant de retourner des éléments de données indi- viduels. 69. Procédé selon la revendication 65, caracté- risé en ce qu'il comporte une étape supplémentaire con- sistant à présenter des dialogues-utilisateur en réponse à des demandes émanant de programmes d'application con- cernant des éléments de données, les dialo- gues-utilisateur permettant à l'utilisateur courant de l'ordinateur de spécifier les mots de passe à utiliser par le fournisseur de mémorisation (106) pour décrypter les éléments de données (130). 70. Procédé selon la revendication 65, caracté- risé en ce que l'étape de cryptage est basée sur une ou plusieurs clés qui sont obtenues à partir de l'authenti- fication de l'utilisateur courant de l'ordinateur. 71. Procédé selon la revendication 65, caracté- risé en ce que l'étape de cryptage est basée sur une ou plusieurs clés qui sont obtenues à partir d'un code four- ni par l'utilisateur. 72. Procédé selon la revendication 65, ca- ractérisé en ce que l'étape de cryptage est basée sur une ou plusieurs clés qui sont obtenues à partir d'un code de connexion à l'ordinateur fourni par l'utilisateur courant de l'ordinateur.