Brevet FR2852415A1 — publié le 20040917

SUPPORT DE TYPE CLE, DE CONTROLE DE L'ACCES A DES DONNEES ET/OU A UN LOGICIEL ET PROCEDE CORRESPONDANT La présente invention concerne un support de type clé comprenant une mémoire à lecture/écriture et des moyens de sécurisation de l'accès à des données et/ou à un logiciel, propre à être connecté à un dispositif lecteur. Elle concerne également un procédé de contrôle de l'accès à des données et/ou de l'utilisation d'un logiciel associé à un support du type clé. Elle trouve une application particulièrement importante bien que non exclusive dans le domaine de la protection contre la copie de logiciels utilisés sur des micro-ordinateurs. On connaît déjà des méthodes de protection de logiciels utilisés sur un ordinateur, qui consistent à marquer l'ordinateur au moyen d'un dispositif électronique complémentaire appelé clé. Le programme ou logiciel, au cours de son exécution, vérifie la présence de cette clé constituée par un circuit électronique qui renvoie des codes lorsqu'il est sollicité. Ce circuit peut se loger directement dans l'un des connecteurs d'extension de l'ordinateur, ou plus simplement se brancher sur l'une des prises ou ports externes, par exemple celui de l'imprimante sans pour autant perturber le fonctionnement de cette dernière. On peut ainsi copier le logiciel à volonté. Ce système qui a été encore amélioré en rendant les clés directement programmables grâce à une mémoire rémanente à lecture/écriture est de loin le plus efficace. Il présente cependant un certain nombre d'inconvénients. En effet, les données et/ou les logiciels qui sont actuellement accessibles de façon sécurisée par clé sur un ordinateur ne sont jamais totalement inaccessibles pour un pirate astucieux, qui peut réussir à détourner les codes utilisés et/ou à les simuler. La présente invention vise à fournir une clé et un procédé de sécurisation de l'accès à des données et/ou à un logiciel répondant mieux que ceux antérieurement connus aux exigences de la pratique, notamment en ce qu'elle permet de palier les inconvénients ci-dessus mentionnés, et en ce qu'elle permet par des procédures d'installation simplifiées de ne plus se préoccuper du dispositif sur lequel fonctionnera l'application. Avec l'invention, le programmeur va donc autoriser ou non l'accès aux données sécurisées ou le fonctionnement du logiciel protégé de façon optimisée, ce qui présente un résultat technique particulièrement avantageux, à une époque où le piratage de données ou de logiciels est malheureusement en recrudescence. Dans ce but, l'invention propose notamment un support de type clé comprenant une mémoire à lecture/écriture et des moyens de sécurisation de l'accès à des données et/ou à un logiciel propre à être connecté à un dispositif lecteur, caractérisé en ce que la mémoire comprend au moins un fichier spécifique agencé pour stocker au moins partiellement lesdites données et/ou ledit logiciel à sécuriser. En stockant les données à sécuriser et/ou le logiciel dont l'utilisation doit être contrôlée à l'intérieur même de la clé, ce qui paraît surprenant, on augmente ainsi la sécurité, le pirate ne pouvant y avoir accès qu'en pénétrant dans la clé elle-même, ce qui est quasiment impossible du fait de l'existence des moyens de sécurisation eux-mêmes également présents dans la clé. Dans des modes de réalisation avantageux, on a de plus recours à l'une et/ou à l'autre des dispositions suivantes : - les moyens de sécurisation comportent des moyens d'identification de l'utilisateur agencé pour bloquer l'usage de la totalité des autres fichiers stockés dans la clé en cas de mauvaise identification ; - les moyens agencés pour bloquer l'usage de la totalité des autres fichiers permettent l'effaçage desdits fichiers ; - les moyens de sécurisation comportent au moins un groupe de plusieurs fichiers agencés pour contrôler le niveau de sécurisation des données sécurisées stockées dans le fichier spécifique attaché audit groupe dans la mémoire dudit support ; - le groupe de plusieurs fichiers comprend un fichier mot de passe en lecture , un fichier mot de passe en écriture , et un fichier compteur de tentative d'accès ; - le compteur de tentative d'accès est agencé pour bloquer l'accès au fichier correspondant au bout de n tentatives infructueuses de mot de passe en lecture et/ou en écriture ; - l'accès au fichier dans le mode concerné est définitivement impossible après trois tentatives infructueuses. L'invention concerne également un procédé de contrôle de l'accès à des données et/ou de l'utilisation d'un logiciel associé à un support du type clé, caractérisé en ce que on stocke au moins partiellement lesdites données et/ou le logiciel dans au moins un fichier spécifique de données de la clé elle même. Dans un mode de réalisation avantageux, on identifie l'utilisateur et on bloque l'usage de la totalité des autres fichiers stockés dans la clé en cas de mauvaise identification. Avantageusement on sécurise l'accès audit fichier spécifique de données en stockant des informations de sécurisation dans au moins un groupe de plusieurs fichiers agencés pour contrôler le niveau de sécurisation desdites données sécurisées stockées dans ledit fichier. Dans un autre mode de réalisation, on sécurise l'accès aux données par un mot de passe en lecture et un mot de passe en écriture , que l'on compare avec des mots introduits dans un fichier dit compteur de tentatives . Avantageusement, on bloque l'accès au fichier correspondant au bout de n tentatives infructueuses de mot de passe en lecture et/ou en écriture. L'invention sera mieux comprise à la lecture de la description des modes de réalisation donnés ci-après à titre d'exemple non limitatifs, et en faisant également référence à différents tableaux. La description se réfère aux dessins qui l'accompagnent, dans lesquels : La figure 1 est une vue en perspective, schématique, d'un micro-ordinateur équipé d'une clé selon l'invention branché sur un port USB. La figure 2 est une vue en perspective de la clé de la figure 1 dont le boîtier de protection a été enlevé. La figure 3 est un schéma bloc général d'une clé électronique selon un mode de réalisation de l'invention. La figure 4 est un schéma donnant la structure cartographique de groupes de fichiers de sécurisation et de fichiers de données correspondants utilisés dans un mode de réalisation de l'invention. La figure 1 montre un micro-ordinateur 1 comportant un boîtier 2 et un écran 3. Le boîtier est muni d'un port USB 4. Selon le mode de réalisation de l'invention plus particulièrement décrit ici, le micro-ordinateur 1 comprend une clé 5, enfichée sur le port USB 4. En référence à la figure 2, la clé 5 comprend un circuit 6 muni d'un microcontrôleur 7, par exemple un PIC 16C765 fabriqué par la société américaine MICROCHIP. Un tel microcontrôleur 7 convient par exemple, avec une légère adaptation, au protocole IEEE 1284 utilisé dans le mode de réalisation de l'invention plus particulièrement décrit ici. Le circuit 6 comprend également une EEPROM 8 par exemple de 32 kilo Octets qui va permettre le stockage des fichiers de sécurisation et de données et une fiche 9 de connection avec le port USB. Plus précisément, en référence à la figure 3, il est représenté un schéma bloc d'un circuit 10 selon un autre mode de réalisation de l'invention. Il comprend un boîtier 11 (trait interrompu), un microcontrôleur 12, un circuit 13 dit latch qui permet le fonctionnement de la clé en mode transparent du type connu en langue anglo saxonne sous la dénomination Daisy chaining , une EEPROM 14 compatible I2C par exemple de 32 kilo octets, deux diodes schottky 15 permettant l'alimentation du circuit par au moins un signal 16 sélection ou init venant du PC hôte (non représenté), un ensemble de composant 17 permettant la génération de l'horloge par exemple d'une fréquence de 6Mhz, deux connecteurs DB25, dont l'un est destiné à être relié côté hôte et l'autre d'un côté dit pass through , autorisant le passage au travers de la clé de façon transparente, trois capacités de filtrage 19, et un ensemble 20 de cinq contacts (représentés par un trait mixte) permettant la programmation in situ de la clé lors de sa production. Dans le mode de réalisation plus particulièrement décrit ici, il est prévu de fonctionner en mode dit Daisy Chain et protocole EPP sans adresses. La clé est toujours configurée en mode esclave, c'est-àdire qu'elle reçoit toutes ses commandes par l'interface physique. Elle reçoit par ailleurs les commandes de lecture ou d'écriture sur le bus 21 considéré avec l'échange protocolaire ad hoc. On va maintenant décrire plus précisément le microcontrôleur 12. Il contient le programme de la clé et en particulier une zone spécifique pour l'identification au démarrage IDM ). Cette zone IDM a par exemple une taille de 42 octets et commande les fichiers listés dans le tableau 1 ci-après. L'abréviation MdP signifie Mot de Passe , E étant pour Ecriture et L pour Lecture . On note qu'il est ici prévu des mots de passe Constructeur, Distributeur et Editeur. Structure de l'IDM P/S/U xxx (2 octets) Date de fabrication (2 octets) N de version (2 octets) Build (2 octets) Code pays (2 octets) Distributeur (1 octet) N de série de fab (5 octets) N série éditeur (4 octets) Val défaut cptrs de tentative (1 octet) MdPE Constructeur (3 octets) MdPL Constructeur (3 octets) MdPE Distributeur (3 octets) MdPL Distributeur (3 octets) MdPE Editeur (3 octets) MdPL Editeur (3 octets) Compt Tentatives Constructeur (1 octet) Compt Tentatives E/L distrib. (1 octet) Compt Tentatives E/L éditeur (1 octet) Tableau 1 Le microcontrôleur contient également une mémoire RAM qui permet de stocker les variables et une mémoire tampon buffer permettant le bon fonctionnement du système. La place disponible est par exemple de 200 Octets. De façon connue, l'organisation (mapping) de la mémoire RAM est générée après compilation du programme écrit pour l'application. La mémoire à lecture/écriture 14, dite mémoire externe, est quant-à-elle composée d'un circuit EEPROM du type 24LCxx. Le nombre xx est celui qui donne la taille de la mémoire selon les caractéristiques souhaitées. Elle est compatible I2C. La cartographie de la mémoire EEPROM 12 est également précisée en référence à la figure 4. Il est prévu de gérer cette mémoire comme un mini disque par exemple structuré de la manière suivante : Dans la taille totale de la mémoire, on découpe n zones de 64 octets ou cluster 64. Plus précisément, la mémoire 12 est structurée en n fichiers 200,201, 202,203,..., 20i ..., 20n de 128 octets chacun, soit à chaque fois deux cluster~64 minimum : 200', 200" ;... 20i' , 20i'' ; le premier fichier 200 (secteur de BOOT) étant non effaçable. Le secteur de BOOT 200 de xx octets comprend de façon plus précise une zone BOOT système 200' de x octets, à l'adresse 0x000 variable suivant la taille mémoire. Il comprend également une zone protégée 200''de x octets, qui contient la recopie de l'IDM inscrite dans le microcontrôleur (cf.tableau 1), avec trois niveaux de protection suivant le type d'accès(Constructeurs, Distributeurs, Editeurs ). Le secteur de BOOT sera détaillé ci-après : Chaque fichier 201,202, etc, est, quant-à-lui constitué de deux clusters de 64 octets ou plus (un cluster pour l'en tête et un cluster pour le corps). La gestion de ces fichiers est par exemple réalisée de façon connue par des routines contenues dans le programme noyau système stocké dans le microcontrôleur de la clé. Le corps 201'',... 20i'', est strictement réservé aux données cryptées et protégées en écriture et/ou lecture selon l'invention. L'en-tête 201', 20i', est, quant-à-elle, par exemple, conforme au tableau 2 ci-après, les colonnes Con, Dis et Edi signifiant Constructeur, Distributeur, et Editeur. Variable NO NO Con Dis Edi Adr N Fichier Numéro du fichier Unique dans 1 1 # # # 0x00 la clé NomFichier Nom du fichier Unique dans la 8 9 # # # 0x01 clé ExtFichier Extension du fichier 3 12 # # # 0x09 TalFichier Taille du fichier Nombre de 1 13 # # # OxOC cluster de 64 Octets DCrFichier Date de création du fichier 2 15 # # # 0x0D DLmFichier Date Limite d'utilisation du 2 17 # # # OxOF fichier NbUsNet Nombre d'utilisateurs Réseau 2 19 # # # 0x11 CmtUses Compteur d'utilisation du fichier 2 21 # # # 0x13 PWWrite Mot de passe en Ecriture du 3 24 0x15 fichier PWRead Mot de passe en Lecture du 3 27 0x18 fichier SSII Code SSII 1 28 # # # 0x1B 1 29 # # # 0x1 C 0x1D CmtAcFic Compteur Tentative d'accès 1 0x1 E erronés RegEtat Régistre d' Etat 1 32 0x1 F KeyWrite Clé de cryptage en Ecriture 16 48 KeyRead Clé de Cryptage en Lecture 16 64 Tableau 2 Le secteur de BOOT 200 est réservé au système de gestion du microcontrôleur, et a une taille variable suivant la taille mémoire EEPROM implantée en production. Il contient dans la zone de BOOT 200', les registres suivants : La taille de la mémoire (registre 21), Le nombre de fichiers maxi (registre 22), Le nombre de fichiers créés (registre 23), Le nom et l'adresse de début des fichiers créés ( table 24 des fichiers ) Le secteur de BOOT 200 comprend également la zone protégée 200" dite IDM étendue. Cette zone, par exemple de 37 octets dans le mode de réalisation plus particulièrement décrit ici, contient les registres suivants : Une zone 25 correspondant à la recopie de l'IDM du microcontrôleur (cf.tableau 1) Une zone 26 d'accès Constructeur, Une zone 27 d'accès Distributeur, Une zone 28 d'accès Editeur, Le registre code PIN 29, Le code PIN 30. On remarquera que si on garde la même configuration que celle du microcontrôleur il est alors prévu deux fonctions IDM, une pour le microcontrôleur et une autre pour l'EEPROM de façon à connaître les deux numéros de série, un IDM microcontrôleur étant quoi qu'il en soit nécessaire au cas où l'EEPROM serait détruite du fait d'une erreur. Les informations données par l'IDM en clair sont les suivantes, sauf pour le Numéro de client lorsqu'il n'est pas initialisé. # P/S/U # Date de Fabrication # N de version # Build # Code Pays # Distributeur # Numéro de client. # Numéro de Série de fabrication. On a précisé ci-après le contenu et/ou le fonctionnement de certains des registres mentionnés, à titre d'exemples non limitatifs. Registre code PIN 29 Dans l'octet Flag du registre, on peut par exemple adopter les conventions suivantes : Si le Bit7 est à 1 le code PIN est demandé une seule fois, sauf si on demande un reset général. Les Bits 4-6 représentent le nombre de saisies erronées du code PIN, soit de 1 à 7 tentatives. Les Bits 0-2 sont initialisés à la même valeur que les Bits 4-6 et représentent le nombre maximum de tentatives d'accès avec un code erroné. A Chaque saisie erronée ce nombre est décrémenté. Quand il arrive à 0 l'accès ne peut se faire que par une fonction spécifique Constructeur. Si toutefois le code PIN est saisi à nouveau correctement, les Bits 0-2 reprennent la valeur des Bits 4-6. Par défaut l'octet entier est à 00 (0000 0000) Le code PIN sert dans le cas où l'utilisateur souhaite avoir un accès confidentiel aux données et/ou au logiciel uniquement. Ce n'est donc pas une protection supplémentaire coté Editeur. Code PIN 30 Dans le mode de réalisation plus particulièrement décrit ici, le code PIN comprend deux octets, soit quatre quartés. Chaque quarté représente un chiffre allant de 0 à 9. Le code PIN est donc représenté sur quatre chiffres de 0000 à 9999. Le Constructeur peut le lire et le modifier, le Distributeur n'a, quant à lui, aucun droit et l'Editeur peut, par contre, le lire et le modifier, à condition de rentrer l'ancien code PIN. Le Code PIN est unique pour toute la clé. L'utilisation du logiciel protégé peut demander plusieurs fois la confirmation du code PIN. ( cas du réseau) sans pour autant affecter la clé. Mot de Passe Constructeur Le mot de passe Constructeur est initialisé par ce dernier et ne figure que dans le microcontrôleur, jamais dans l'EEPROM. Toutes les fonctions Constructeur utilisent ce mot de passe. Si le mot de Passe est à 0 ou FFFF, aucune fonction Constructeur ne doit être prise en compte, le compteur de tentatives d'accès étant alors actionné systématiquement. Mot de Passe Distributeur Le mot de passe Distributeur est initialisé par le constructeur et, ici encore, ne doit figurer que dans le microcontrôleur et jamais dans l'EEPROM. Toutes les fonctions Distributeur doivent utiliser ce mot de passe. Si le mot de Passe Distributeur est à 0 ou FFFF, aucune fonction Distributeur ne doit être prise en compte, le compteur de tentatives d'accès étant alors actionné systématiquement. Mot de Passe Editeur Lorsque le mot de passe Editeur est initialisé par le Constructeur, soit une valeur différente de 0000 ou FFFF) ce dernier ne doit figurer que dans le microcontrôleur et jamais dans l'EEPROM. Par contre, si ce mot est égal à 0000 ou FFFF, l'Editeur doit alors utiliser une clé Maître pour initialiser le Mot de Passe Editeur dans l'EEPROM. Toutes les fonctions Editeur pour la gestion générale doivent utiliser ce mot de passe. Tous les compteurs de tentative d'accès se trouvent par ailleurs dans l'EEPROM. On a représenté un mode de réalisation de la zone protégée 200" de l'EEPROM dans le tableau n 3. Zone protégée de l'eeprom P/S/U xxx (2 octets) Date de fabrication (2 octets) N de version (2 octets) Build (2 octets) Code pays (2 octets) Distributeur (1 octet) N de série de fab (5 octets) N série éditeur (4 octets) Val défaut cptrs de tentative (1 octet) MdPE Constructeur (3 octets) MdPL Constructeur (3 octets) MdPE Distributeur (3 octets) MdPL Distributeur (3 octets) MdPE Editeur (3 octets) MdPL Editeur (3 octets) Compt Tentatives Constructeur (1 octet) Compt Tentatives E/L distrib. (1 octet) Compt Tentatives E/L éditeur (1 octet) Reg Compteur code pin (1 octet) Code pin (2 octets) Tableau 3 On va maintenant décrire un mode de réalisation du programme qui permet de mettre en #uvre le contrôle d'accès à des données et/ou à un logiciel selon l'invention. L'ensemble du logiciel est par exemple écrit en langage C avec un compilateur du type HITHECH software. Certaines routines, pour des questions de vitesse, sont avantageusement écrites en assembleur. Le noyau système Les fichiers sources qui le constituent sont les suivants : Le module mainpara.c Il a pour fonction d'initialiser le système. # Fonction init~pic~16c765() ; Le module système.c Ce fichier source comprend les fonctions suivantes : # Fonction Traite~Cde(); # Fonction Init~Idm(); # Fonction Ecrit~BOOT(int,unsigned char); # Fonction BOOT~Buff~64(unsigned char ); # Fonction Gest~Tent(); # Fonction Idm(); # Fonction Idm~Teste(); # Envoi~Err (char); # Fonction Ctrl~CodePin(int); # Fonction Modif~CodePin(int,char*); # Fonction DelogO; # Fonction Lecture~Idm(); Le fichier entête système .h Ce fichier en tête définit les différents paramètres des fonctions système. Le module gestmem.c # Fonction Raz~Buff~64 (unsigned char,unsigned char); # Fonction Raz~Buff~Sys(unsigned char,unsigned char); # Fonction Copie~Mem(unsigned char,unsigned char* ,const unsigned char* ); # Fonction Tfs~Rameeprom(int,unsigned char); # Fonction Tfs~Eepromram(int,unsigned char*); # Fonction int Buff~Adr~Mem(const unsigned char *); # Fonction Adr~Mem~Buff(unsigned char *); # Fonction Buff~Cmp(unsigned char ,const unsigned char *,const unsigned char * ); # Fonction Comp~00~FF(unsigned char ,unsigned char,unsigned char *); Le module decrypt.c # Fonction char De Cryptage(); Fonction char Calc~Crc(unsigned char,unsigned char *); Le fichier entête gestmem.h Ce fichier entête définit les différentes adresses de la mémoire EEPROM . Le module i2c.c # Fonction unsigned char i2c~Lit~Octet(void); # Fonction i2c~Ecrit~Octet(char); # Fonction i2c~Pas~Ack(void); # Fonction i2c~Ack(void); # Fonction i2c~Depart(void); # Fonction i2c~Arret(void); # Fonction i2c~Env~Adr~Ecrit(unsigned chartint ); # Fonction i2c~Env~Adr~Lect(unsigned char,int,unsigned char ); # Fonction i2c~Lit~Chaine(unsigned char, unsigned char*); # Fonction i2c~Ecrit~Chaine(unsigned char, const unsigned char* ) ; #Fonction i2c Lit Chaine Sys(unsigned char, unsigned char*); # Fonction i2c~Ecrit~Chaine~Sys(unsigned char,const unsigned char*); # Fonction i2c~Remplis(char, char ); L'interface au busLPT Le module daisy2.c # Fonction mode~daisy~assigne(); # Fonction mode daisy-select(); Le module mode~epp.c # Fonction Dde~Ecriture(unsigned char,unsigned char*); # Fonction Dde~Lecture(); # Fonction Mode~Epp(); L'interface de commandes Cette interface de commandes permet le dialogue entre les différents clients de la clé (Constructeurs, Distributeurs, Editeurs, Clients). Le module cdeedit.c # Fonction Ident~Edit~E~L(unsigned chartint ); # Fonction Ident~Codepin(); # Fonction Modif~Idm~EEPROM (int,unsigned char , # unsigned char *, # unsigned char *); # Fonction Cde~Ecrit~Edit~0(); # Fonction Cde~Lect~Edit~BO(); Le module cdefich.c # Fonction Crea~Fich(); # Fonction Del~Fich(); # Fonction Recherche~Fich(char,int); # Fonction Cde~Lect~Fich~0(); # Fonction Test~Regfich(unsigned char*); # Fonction Ecriture~Fichier(); # Fonction Lecture~Fichier(); # Fonction Infos~Dir(); # Fonction Modif~BOOT() ; # Fonction Ident~fichier~E(); # Fonction Ident~fichier~L(); # Fonction Ecrit~Crea~Fich(); # Fonction Ecrit~Del~Fich(); Le module cdessii.c # Fonction Cde~Lect~Ssii~0(); Il est ensuite prévu divers code erreur, correspondant aux paramètres suivants : - Constructeur non valide - IDM distributeur non valide - IDM éditeur non valide - clé grillée en lecture Constructeur, en lecture Distributeur, en lecture Editeur, en écriture Constructeur, en écriture Distributeur et en écriture Editeur. Ces codes sont renvoyés lorsqu'un login est fait et que le compteur de tentative correspondant est plein. - fichier grillé en lecture Ce code est renvoyé lorsque le registre d'état du fichier concerné indique que le compteur de tentative en lecture est plein - fichier grillé en écriture Ce code est renvoyé lorsque le registre d'état du fichier concerné indique que le compteur de tentative en écriture est plein. - Mot de passe en lecture non valide Ce code est renvoyé lorsque le mot de passe en écriture d'un fichier est erroné. - Mot de passe en écriture non valide Ce code est renvoyé lorsque le mot de passe en lecture d'un fichier est erroné. - fichier inexistant Ce code est renvoyé lorsque le fichier n'est pas mentionné dans la table des fichiers du secteur de BOOT système. D'autres codes sont prévus pour préciser diverses erreurs en fonction de critères classiques, à la portée de l'homme du métier. On va maintenant examiner de façon plus précise le fonctionnement et l'organisation du support selon le mode de réalisation de l'invention plus particulièrement décrit ici. Le support selon l'invention, où sont stockés les données, peut être externe et connecté à un port parallèle, un port série ou un port USB ou encore un lecteur de carte a puces. Il peut aussi être formé par un disque intégré dans l'ordinateur ou plus généralement le lecteur. Quel que soit le support, les API sont les mêmes, aucune différence n'étant faite entre une clé USB ou une autre. Les fonctions à utiliser pour contrôler les supports sont décrites ci-après. Pour accéder à un support il faut tout d'abord s'identifier. L'identification consiste à donner au support les informations dont il a besoin pour laisser par la suite effectuer les opérations sur les fichiers. Cette authentification est faite par des mots de passe, des clés de cryptage et la vérification du protocole. Comme on l'a vu, le support contient # Un Numéro de série unique de fabrication : écrit par le producteur du support ou constructeur. # Un Numéro de série unique par éditeur : écrit par le producteur du support ou l'éditeur lui même qui souhaite se protéger. # Un mot de passe en lecture : créé par le producteur du support et en fonction de chacun de ses clients. Il permet l'accès en lecture uniquement dans le support. # Un mot de passe en écriture : créé par le producteur du support et en fonction de chacun de ses clients. Il permet l'accès en lecture et écriture dans le support. # Une zone réservée pour la clé de cryptage : créée par le producteur du support, elle est fonction de chacun de ses clients. Elle permet le premier accès au support. Par la suite cette clé de cryptage change a chaque fois le contenu de manière aléatoire. # Un code PIN : écrit par l' éditeur. Ce code permet d'identifier l'utilisateur qui l'introduit pour accéder dans le support. # Un double compteur de tentative d'accès. ce compteur indique si une tentative d'accès a été effectuée avec des mots de passe non conformes. Il existe un compteur pour la lecture et un autre pour l'écriture. Au bout de trois tentatives infructueuses les compteurs bloquent le support. # Un compteur de code pin erroné : ce compteur indique si une tentative d'accès a été réalisée avec un code non conforme. Au bout de trois tentatives infructueuses les compteurs bloquent le système. # Nombre de fichiers créés : cette entité est gérée par le système lui-même. # Nombre de fichiers lisibles . géré par le système lui-même. # Taille de la mémoire gérée par le producteur suivant la taille mémoire disponible. # Taille d'un cluster gérée par le producteur suivant la taille mémoire disponible. # Identification et type du support : gérée par le producteur suivant le type du support. # Date de fabrication gérée par le producteur suivant la date de fabrication. # Identification du pays gérée par le producteur suivant pour quel pays le produit est destiné. # Identification du distributeur : gérée par le producteur. # Le registre d'état géré par le producteur, puis complété ou modifié par l'éditeur suivant ses besoins. Une fois cette première étape franchie il est alors possible d'accéder aux fichiers. Les opérations possibles portent sur deux entités : le support ou un fichier dans le support. La notion de fichier doit être ici examinée sous deux aspects différents. Un fichier est un conteneur pour des données spécifiques, mais c'est aussi un représentant d'une application (logiciel). De ce fait, la gestion des applications se fait donc sur la base des fichiers. A chaque fichier sont associées des informations qui permettent de contrôler le niveau de protection. Ces informations très semblables à celles nécessaires pour accéder au support lui-même, sont, par fichier, dans le mode de réalisation plus particulièrement décrit ici, les suivantes : - Un espace réservé pour le nom du fichier et son suffixe il est défini lors de la création du fichier et permet l'identification et l'accès à ce dernier. - Un numéro de fichier : il est unique sur un support pour un fichier donné. L'accès par ce numéro favorise la vitesse de recherche du fichier sur des supports dont le traitement est lent. - Une taille du fichier Elle renseigne le système d'exploitation sur la taille réelle du fichier. - Un mot de passe en lecture : il est défini lors de la création du fichier et permet l'accès au fichier en lecture uniquement. - Un mot de passe en écriture : il est défini lors de la création du fichier et permet l'accès au fichier en lecture et écriture. - Un double compteur de tentatives d'accès : ces deux compteurs renseignent sur les tentatives d'accès faites avec des mots de passe non conformes, à savoir un compteur pour la lecture et un autre pour l'écriture. Après trois tentatives infructueuses les compteurs bloquent le système pour l'accès au fichier. - Une date limite d'utilisation : cette date définie lors de la création du fichier ou par la suite à l'aide d'une fonction prévue pour cet usage, permet de bloquer l'utilisation du fichier lorsqu'elle est dépassée. Ce contrôle de date automatique est transparent pour le programmeur, la date étant donnée par le système externe ou par un système intégré au support. - Un compteur maximum d'utilisations : Ce nombre maximum d'utilisations défini lors de la création du fichier ou par la suite à l'aide d'une fonction prévue pour cet usage, permet de bloquer l'utilisation du fichier lorsque ce nombre est atteint. Ce contrôle de nombre maximum d'utilisations est automatique et transparent pour le programmeur. Le compteur est ajusté à chaque "login" sur le fichier. Ce fonctionnement est optionnel et il est toujours possible de débloquer le fichier par une fonction de modification de ce compteur, comme pour la date limite d'utilisation d'ailleurs. Un compteur maximum d'utilisateurs en réseau : Ce nombre maximum d'utilisateurs réseau défini par la suite à l'aide d'une fonction prévue pour cet usage, permet de bloquer l'utilisation du fichier lorsque ce nombre est atteint. Il s'agit du nombre de connexions simultanées sur le fichier en fonction du type de login . (Nécessite la version réseau) . - Une Version : Zone de huit caractères. Le contenu de ce champ est défini par le programmeur, mais cela permet, si c'est souhaité de n'autoriser le "login" sur le fichier que si la version est supérieure ou égale à celle demandée lors du "login" Une zone de "build". Cette zone de huit caractères est un complément de la Version. On pourra utiliser la Version seule ou la Version et le "Build", ou aucun des deux. Un ensemble de 64 options. Ce sont des indicateurs, qui permettent de n'ouvrir le fichier que si l'indicateur est positionné sur l'option demandée. - Deux compteurs 32 bits que le programmeur peut utiliser comme il le souhaite à travers des fonctions d'initialisation, de lecture et d'incrémentation ou décrémentation. Une zone réservée ascii. Cette zone sert à stocker une chaine en ascii. Elle a plusieurs fonctions dont celle d'identification d'un client ou du propriétaire. Le fichier n'est ouvert que si la zone est celle qui est demandée par l'utilisateur . - Une zone reservée pour accéder à un serveur. Cette zone contient l'adresse ou le nom d'un serveur pour une connection automatique. - Un registre d'état. Ce dernier donne des renseignements sur la nature du fichier et les protections qui y sont demandées. Toutes ces zones peuvent être utilisées séparément ou selon de nombreuses combinaisons et permettent un contrôle très complet de l'accès à un fichier. Selon le mode de réalisation de l'invention plus particulièrement décrit ici, ces accès sont contrôlés par des mots de passe qui sont différents en lecture et en écriture. Il ne sera possible de lire dans le support que si le mot de passe en lecture est le bon. Après trois tentatives, le support sera grillé en lecture. De la même façon, il ne sera possible d'écrire dans le support que si le bon mot de passe en écriture est fourni. Ici encore, après trois tentatives infructueuses, la clé est grillée en Ecriture. Dans un mode de réalisation, il est impossible de dé-griller un support. En plus des mots de passe au niveau du support , il est également possible, et comme on l'a vu, d'activer un contrôle par code pin. L'accès ne pourra alors se faire qu'après contrôle du code pin. Trois tentatives maximum sont ici encore autorisées sous peine de griller le support. Comme les mots de passe en lecture et écriture sont les même pour tous les supports d'un Editeur , le code pin permet de personnaliser le niveau d'accès de niveau clé par le code pin. Ainsi le programmeur va-t-il pouvoir définir un code pin différent par support. Comme on l'a compris, en plus du mécanisme de mots de passe à présenter pour accéder au support, il existe pour chaque fichier un jeu de mots de passe différents laissé à la responsabilité du programmeur. Ainsi, on peut définir un mot de passe en lecture et un mot de passe en écriture (identique ou différent) pour chacun des fichiers créés dans le support. Ici encore, et par exemple au-delà de trois tentatives de présentation des mots de passe, le fichier sera grillé en lecture ou/et en écriture. Il n'est prévu dans cet exemple, aucun moyen de dé-griller un fichier, la seule solution consistant à en recréer un autre. On va maintenant décrire à titre d'exemple non limitatif, dans le langage C choisi, les fonctions de gestions générale au niveau de la clé, les fonctions de navigation dans la liste de clés, les fonctions d'exploration du contenu d'une clé, les fonctions de création et suppression de fichiers, les fonctions de niveau application, et les fonctions niveau fichiers. Les fonctions de gestion générale au niveau des clés : openKey~: Cette fonction est nécessaire avant toute autre opération sur une clé. Elle ne permet pas l'accès à une clé, mais réserve les ressources nécessaires à la suite des opérations sur la clé ou sur les fichiers de la clé. closeKey . Cette fonction permet de libérer les ressources allouées par la fonction openKey. attachToFirstKey . Cette fonction permet de rechercher une clé physique particulière, soit la première clé trouvée, soit une clé précise. L'identification des clés se fait toujours sur son numéro de série dont l'unicité est garantie par le processus de fabrication. Cette fonction permet donc de faire un test de présence de clé. getSerialNumberKey : Cette fonction permet de lire le numéro de série de la clé : Elle ne fait aucun accès dans la clé. Le numéro de série renvoyé est celui passé lors de l'appel de la fonction openKey le cas échéant ou celui trouvé lors de l'exécution de la fonction attachToFirstKey. setPinKey . Cette fonction permet d'activer ou désactiver le contrôle du code pin pour l'accès dans la clé. Le code pin est une valeur numérique comprise entre 1 et 9999. testPinKey . Cette fonction permet de tester le code pin, s'il à été activé, pour autoriser l'accès dans la clé. Les fonctions de navigation dans la liste des clés : Ces fonctions ne sont accessibles que si la fonction openKey a déjà été appelée. Elles utilisent les caractéristiques (mot de passes et codes) données lors de l'appel à openKey. firstKey . Cette fonction permet de demander le calcul de toutes les clés trouvées sur le poste local, et elle renvoie le numéro de la première clé (numéro 1) s'il y en a. nextKey . cette fonction permet de demander le numéro de la clé suivante s'il y en a. serialKey : Cette fonction permet de lire le numéro de série d'une clé à une position donnée dans la liste trouvée par findKey. Les fonctions d'exploration du contenu d'une clé Ces fonctions permettent essentiellement de lire la liste des fichiers contenus dans une clé. findFirstKey : Permet d'établir la liste des fichiers visibles dans une clé et de renvoyer le numéro du premier élément findNextKey . Cette fonction permet de lire le fichier suivant dans la liste des fichiers établie par findFirstKey fNameKeyKey . cette fonction renvoie le nom du fichier à une position donnée. Les fonctions de création et suppression de fichiers : createFileKey : Cette fonction permet de créer un fichier dans la clé. La taille du fichier est définie de manière définitive lors de la création du fichier deleteFileKey : Cette fonction permet de supprimer un fichier dans la clé. formatFileKey : Cette fonction permet de supprimer tous les fichiers de la clé. Cela permet de la remettre dans l'état initial. Les fonctions de niveau application : Ces fonctions sont appelées fonctions de niveau application , car on considère qu'un fichier est lié à une application. En général, le programmeur fait un "login" de niveau application, ce qui permet de vérifier les caractéristiques de la clé, et celles d'un fichier particulier dans la clé. De nombreux paramètres permettent de faire des login plus ou moins sophistiqués. mLoginKey : Cette fonction permet de faire un "login" clé. Sur un fichier précis. Elle vérifie la présence du fichier dans la clé, et fait le contrôle des limites (seulement en version commerciale), de nombre d'utilisateurs maximum, de la date de validité, et du nombre d'accès maximum autorisés. En règle générale, il faut associer un fichier par application. Le fichier pourra contenir ou non des données spécifiques à cette application. mLoginKey est la fonction générique, et elle est déclinée en fonctions de suffixe S , V, 0, VB pour respectivement : - Signature : Vérification que les 8 premiers octets du contenu d'un fichier correspondent à une signature passée lors du "login" - Version : Vérification que le fichier est d'une version au moins égale à celle passée lors du "login" - Option . Vérification qu'une option dont le numéro est passé lors du "login", est bien positionnée - Version + Build : Vérification de la version et du Build de valeur au moins égale à celle passée lors de l'appel de la fonction de "login" Les suffixes SO, SV, SVB, SVO, SVBO, VO, VB et VBO correspondent à des combinaisons différentes de cette fonction. LogoutKey . Cette fonction permet de libérer la connexion avec la clé établie par la fonction mLoginKey, et de libérer les ressources associées. Si cette fonction n'est pas appelée, elle le sera automatiquement lors de l'appel de la fonction closeKey. Pour une clé connue par la fonction openKey, il est possible de faire autant de "login" application que l'on souhaite (avec succès ou échec selon le type de "login" demandé). Pour chacun de ces "login", les ressources allouées sont mémorisées au niveau du handle de la clé. Il est possible de parcourir cette liste de "login" par des fonctions prévues à cet effet. Ces fonctions sont utiles en particulier dans une application de gestion du suivi des "login" de clé. Les fonctions niveau fichier : Les fonctions portant sur les fichiers sont divisées en deux groupes : Celles qui ne nécessitent pas de "login" sur le fichier et celles qui nécessitent un "login" sur la clé. getEndDateKey : Cette fonction permet de lire la date limite d'utilisation définie pour un fichier. Les dates sont toutes codées sous forme de chaîne de caractères au format universel YYYYMMDD avec YYYY l' année sur 4 digits, MM le mois sur 2 digits et DD le jour sur 2 digits. setEndDateKey : Cette fonction permet de modifier la date limite d'utilisation du fichier. getNbMaxUseKey : Cette fonction permet de lire le nombre maximum d'utilisation d'un fichier. setNbMaxUseKey : Cette fonction permet de modifier le nombre maximum d'utilisation d'un fichier. getFOptKey : Cette fonction permet de lire l'état de l'indicateur de l'une des 64 options associées à un fichier. setFOptKey : Cette fonction permet d'activer ou désactiver l'une des 64 options associées à un fichier. getVersionKey : Cette fonction permet de lire la chaîne de version associée à un fichier. setVersionKey : Cette fonction permet de modifier la chaîne de version associée à un fichier. setNetUsersKey : Cette fonction permet de définir le nombre d'utilisateurs simultanés qui accèdent à un fichier (Version réseau : consulter la documentation correspondante). getNetUsersKey : Cette fonction permet de lire le nombre d'utilisateurs simultanés qui accèdent à un fichier (Version réseau : consulter la documentation correspondante). lockFileKey : Cette fonction permet de bloquer un fichier en écriture : Une fois exécutée, il ne sera plus possible d'écrire dans un fichier, ni même de modifier les zones associées au fichier (version, build, option, date limite, etc....). Cette opération est irréversible. Une fois qu'un "login" application est fait, le fichier concerné est considéré ouvert, et il est alors possible d'y écrire ou lire des informations selon certaine condition d'accès (droits en écriture par exemple) . writeKey . Cette fonction permet d'écrire un buffer dans un fichier de la clé. readKey : Cette fonction permet de lire le contenu d'un fichier d'une clé. getCounterKey : Cette fonction permet de lire la valeur de l'un des deux compteurs 32 bits associé à un fichier. setCounterKey : Cette fonction permet d'initialiser la valeur de l'un des deux compteurs de 32 bits associés à un fichier. incCounterKey : Cette fonction permet d'incrémenter (ou décrémenter) la valeur de l'un des deux compteurs de 32 bits associés à un fichier. Comme il va de soi et comme il résulte également de ce qui précède, la présente invention n'est pas limitée aux modes de réalisation plus particulièrement décrits. Elle en embrasse au contraire toutes les variantes et notamment celles où une partie seulement des données à sécuriser sont stockées dans la clé, le reste étant présentes dans l'ordinateur et/ou le lecteur, qui peut par exemple être un ordinateur, un lecteur de DVD, une station de jeux vidéo ou un décodeur de signaux cryptés pour télévision par satellite. REVENDICATIONS 1. Support (5,10) de type clé comprenant une mémoire à lecture/écriture (8,14) et des moyens (12 ; 200,201, ..., 20i) de sécurisation de l' accès à des données et/ou à un logiciel, propre à être connecté à un dispositif (2) lecteur, caractérisé en ce que la mémoire (14) comprend au moins un fichier spécifique (201'', 202'',..., 20i'', ..., 20n'') agencé pour stocker au moins partiellement lesdites données et/ou ledit logiciel à sécuriser. 2. Support selon la revendication 1, caractérisé en ce que les moyens de sécurisation comportent des moyens d'identification de l'utilisateur agencés pour bloquer l'usage de la totalité des autres fichiers stockés dans la clé en cas de mauvaise identification. 3. Support selon la revendication 2, caractérisé en ce que les moyens agencés pour bloquer l'usage de la totalité des autres fichiers permettent l'effaçage desdits fichiers. 4. Support selon l'une quelconque des revendications précédentes, caractérisé en ce que les moyens de sécurisation comportent au moins un groupe (201', 202', ..., 20i' , ..., 20n') de plusieurs fichiers agencés pour contrôler le niveau de sécurisation des données sécurisées stockées dans le fichier spécifique (201'', 202'', ..., 20i' ' , ..., 20n' ' ) attaché audit groupe dans la mémoire (14) dudit support (10). 5. Support selon la revendication 4, caractérisé en ce que le groupe de plusieurs fichiers comprend un fichier mot de passe en lecture , un fichier mot de passe en écriture , et un fichier compteur de tentative d'accès . 6. Support selon la revendication 5, caractérisé en ce que le compteur de tentative d'accès est agencé pour bloquer l'accès au fichier correspondant au bout de n tentatives infructueuses de mot de passe en lecture et/ou en écriture. 7. Support selon la revendication 6, caractérisé en ce que l'accès au fichier dans le mode concerné est définitivement impossible après trois tentatives infructueuses. 8. Support selon l'une quelconque des revendications 4 à 7, caractérisé en ce que le groupe de plusieurs fichiers comporte de plus un fichier date limite d'utilisation et/ou un fichier compteur maximum d'utilisation . 9. Support selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est formé par un circuit (5) enfichable sur un port USB. 10. Support selon la revendication 9, caractérisé en ce que ledit circuit comporte un microprocesseur(12), une EEPROM (14), une horloge (17), et des moyens (18), de connexion permettant la programmation et le stockage des données et /ou du logiciel. 11. Support selon l'une quelconque des revendications 1 à 8, caractérisé en ce que il est formé par un CDRom. 12. Procédé de contrôle de l'accès à des données et/ou de l'utilisation d'un logiciel associé à un support (5, 10) du type clé, caractérisé en ce que on stocke au moins partiellement lesdites données et/ou le programme dans au moins un fichier spécifique, (201'', 202'', ..., 20i' ' , ..., 20n'') de données de la clé elle même. 13. Procédé selon la revendication 12, caractérisé en ce que on identifie l'utilisateur de la clé et on bloque l'usage de la totalité des autres fichiers stockés dans la clé en cas de mauvaise identification. 14. Procédé selon l'une quelconque des revendications 12 et 13, caractérisé en ce que on sécurise l'accès audit fichier spécifique de données en stockant des informations de sécurisation dans au moins un groupe (201' , 202', ..., 20i',..., 20n' ) de plusieurs fichiers agencés pour contrôler le niveau de sécurisation desdites données sécurisées stockées dans ledit fichier. 15. Procédé selon l'une quelconque des revendications 12 et 14, caractérisé en ce que on sécurise l'accès aux données par un mot de passe lecture et un mot de passe écriture que l'on compare avec un mot introduit dans un fichier dit compteur de tentatives . 16. Procédé selon la revendication 15, caractérisé en ce que on bloque l'accès au fichier correspondant au bout de n tentatives infructueuses de mot de passe en lecture et/ou en écriture.