CA2319773A1

CA2319773A1 - Simultaneous protection for several types of software of several software designers

Info

Publication number: CA2319773A1
Application number: CA002319773A
Authority: CA
Inventors: Chiun-Qiang Lee
Original assignee: Individual
Current assignee: Individual
Priority date: 1998-01-29
Filing date: 1999-01-29
Publication date: 1999-08-05
Also published as: EP1049969A1; FR2774187B1; AU2168599A; FR2774187A1; WO1999039256A1; CN1295682A

Abstract

The invention concerns the protection of several types of software against unauthorised use, consisting in an apparatus (licence card reader LCR) for simultaneously protecting several types of software of several software designers and comprising at least one communication peripheral (network, I/S port), a microcontroller programmable only once which integrates on the same silicon chip two parts separated by an interface. The integrated circuit is logically and physically protected against all attempts of unauthorised intrusion. The invention also concerns a portable apparatus of relatively small size with respect to the chip card connected for its use with the LCR apparatus, comprising at least a detachable recording module with high storage capacity, a microcontroller made secure against all attempts at unauthorised intrusion into its internal circuits. Thus the invention provides protection for several types of software independently of their editors with a single apparatus.

Description

Protection simultanée de plusieurs logiciels de plusieurs concepteurs de logiciels.
La présente invention concerne la protection de logiciels contre leurs utilisations non autorisées.
L'industrie du logiciel est sans doute le secteur où les produits sont le plus facilement copiés.
Or les médias d'enregistrement d'information qui sont en générale des supports optiques, magnétiques sont de plus en plus puissants en capacités de stockages. De plus, le temps mis pour effectuer une copie de ces médias est rapide. De plus, Ie prix pour posséder un appareil puissant de stockage d'information (disques dures, graveurs de CDROM) a été complètement démocratisé de sorte que les nouvelles versions de logiciels mises en vente sont très rapidement confrontées à des problèmes de copies illicites. De plus, il existe des pays où la copie illicite est pratiquée de manière industrielle et impunément à l'aide de CDROM. Si une telle pratique devait se généraliser, c'est tout le monde informatique qui s'écroule. Les programmes sont développés par les concepteurs de logiciels, appelés aussi développeurs. Les licences d'utilisation de leurs logiciels sont ensuite vendues aux clients. Les sociétés concepteurs de logiciels gagnent des profits généralement à
1 S travers la vente directe de leurs produits logiciel et / ou la vente de licences.
L'utilisation illicite de logiciels est définie par rapport à une autorisation d'utilisation de ces logiciels. Cette autorisation se traduit donc par le fait que le concepteur de logiciel accepte de donner une licence d'utilisation qui autorise vis à vis de la loi, l'utilisation de ses produits, au terme d'une entente commerciale.
Le prix de vente des logiciels est calculé avec le nombre d'utilisateurs susceptibles de les acheter. Ainsi les profits dégagés par une société de conception de logiciels dépendent assez de la manière dont leurs clients comptent utiliser ces logiciels une fois achetée.
Dans la mesure où après l'achat l'utilisateur est libre de dupliquer le contenu du média contenant ces logiciels, la survie des concepteurs de logiciels dépend assez de l'honnêteté de leurs clients.
Ainsi, pour les logiciels utilisés en réseau, cette licence obtenu autorise en général, l'utilisation du logiciel donné que sur un seul poste d'ordinateur. Pour être utilisé sur plusieurs postes, un nombre de licences correspondant au nombre de postes d'ordinateurs prévus pour l'utilisation de ces logiciels sur son réseau, doit être acheté. Bien entendu pour un ordinateur personnel, ce nombre est égal à 1. Par rapport aux concepteurs, rien ne peut leur garantir qu'effectivement leurs clients respectent bien les conditions liées aux contrats de vente des licences, car en l'absence de méthode et/ou moyen, rien n'empêche l'utilisation du logiciel sur un nombre de poste supérieur au nombre de licences achetées.
De plus, pour les logiciels utilisés sur un ordinateur isolé (ordinateur personnel) ou en réseau, si aucun moyen n'a été prise par le concepteur de logiciels, rien n'empêche à
ce qu'un utilisateur pirate face des copies de ces logiciels sur un média informatique pour les installer sur un nombre d'ordinateurs, de manière illimitée et de les utiliser impunément. Il se crée alors des marchés noirs de ventes de logiciels « piratés ». Ce marché non contrôlé peut causer de grand dommage dans l'industrie du logiciel.
. 9~~ r~~i~i~'1_.~<r~~~~'," ~~,~~~.'~ 26) ~=~é~1;~4 '~~ ,ï:;'~.. ,>.,~...- Simultaneous protection of several software from several designers software.
The present invention relates to the protection of software against their uses no allowed.
The software industry is arguably the industry where products are most easily copied.
The information recording media, which are generally media optical, magnets are more and more powerful in storage capacities. Moreover, the time taken for making a copy of these media is quick. In addition, the price for owning a powerful device of information storage (hard disks, CDROM burners) has been completely democratized from so the new versions of software that go on sale are very quickly faced with problems with illegal copying. In addition, there are countries where copying unlawful is practiced in a manner industrial and with impunity using CDROM. If such a practice were to occur to generalize is everyone who is falling apart. The programs are developed by the designers of software, also called developers. The licenses to use their software are then sold to customers. Software companies earn profits generally at 1 S through the direct sale of their software products and / or the sale of licenses.
Illegal use of software is defined in relation to authorization of use of these software. This authorization therefore results in the fact that the designer of software accepts give a user license which authorizes vis-à-vis the law, the use of its products, at the end a commercial agreement.
The software sale price is calculated with the number of users likely to buy. So the profits made by a software design company depend enough on the how their customers plan to use the software once purchased.
To the extent that after purchase the user is free to duplicate the content of the media containing these software, the survival of software designers depend enough on the honesty of their clients.
Thus, for software used on the network, this license obtained authorizes in general use given software only on one computer station. To be used on several stations, one number of licenses corresponding to the number of computer stations provided for the use of such software on its network, must be purchased. Of course for a personal computer that number is equal to 1. Compared to designers, nothing can guarantee them that indeed their customers respect the conditions linked to license sales contracts, because in the absence of a method and / or medium, nothing prevents the use of the software on a number of stations greater than number of licenses purchased.
In addition, for software used on an isolated computer (computer personal) or networked, if no means have been taken by the software designer, nothing prevents what a user pirate faces copies of this software on computer media for them install on a number unlimited computers and use them with impunity. It is created so black markets sales of “pirated” software. This uncontrolled market can cause great shame in the software industry.
. 9 ~~ r ~~ i ~ i ~ '1_. ~ <R ~~~~', "~~, ~~~. '~ 26) ~ = ~ é ~ 1; ~ 4 '~~, ï:;' ~ ..,>., ~ ...-

-2-Les concepteurs qui désirent contrôler ce phénomène de copies et/ou d'utilisations illicites de leurs logiciels, achètent un appareil électronique permettant de protéger d'une certaine manière ces logiciels. Mais cette solution n'est envisageable que pour certains logiciels.
De plus, ces concepteurs sont dépendants du fournisseur de ces moyens de protections de logiciels. Les concepteurs de logiciels à petit budget n'ont pas les moyens de protéger leurs produits numériques compte tenu du prix trop élevé des méthodes de protections par rapport aux prix de vente de leurs logiciels.
De plus, l'utilisation de ces appareils électroniques nécessite de la part du concepteur de logiciels, un achat de ces appareils avant la vente réel de ses logiciels.
Cette situation oblige la constitution d'un stock qui peut représenter un désavantage par rapport à ses concurrents qui auraient choisi de ne pas utiliser de moyens de protections de logiciels.
Pour répondre à tous ces problèmes d'utilisation de logiciels, différentes solutions ont été
apportées jusqu'ici. Une solution de protection de logiciels en réseaux ou en monopostes (ordinateurs personnels) est proposée dans le brevet U.S. Pat. No. 5,553,139.
Cependant il ne permet pas de protéger des logiciels par un même système d'appareil provenant de plusieurs concepteurs différents de logiciels.
D'autres méthodes sont utilisées pour un ordinateur donné par l'intermédiaire de systèmes électroniques connectés directement sur un port E/S de l'ordinateur hôte. Un tel système est proposé dans le brevet U.S. Pat. No. 5,343,524. Cette invention repose sur l'utilisation d'un circuit électronique basé sur un microcontrôleur sécurisé, qui ne peut être reproduit.
La protection de logiciels par rapport à cette invention concerne le fait que les logiciels protégés puissent vérifier par l'intermédiaire de clés, la présence de cet appareil et interagir avec cet appareil. Cependant les appareils selon cette invention présentent le désavantage de ne protéger que des logiciels de grandes productions en raison de son coût, et d'autre part de ne pouvoir protéger que les logiciels d'un même concepteur. Un exemple de produit similaire est distribué par la société Rainbow.
D'autre part, des méthodes de protection entièrement logiciel sont aussi employées. Ces protections consistent bien souvent à demander un code d'accès à
l'utilisateur. Ce code est ensuite vérifié à l'aide d'un calcul très compliqué. Cependant, il n'empêche pas certains utilisateurs de trouver le type de calcul qui est utilisé de sorte que les logiciels protégés de cette manière n'offrent aucune fiabilité par rapport à la protection de logiciels.
Des systèmes plus puissants sont utilisés à travers l'utilisation de coprocesseur pouvant calculer une partie des codes d'un logiciel donné et protégé selon cette méthode. Généralement, ces logiciels ne peuvent être utilisés directement dans l'état actuel où ils ont été livrés à l'utilisateur, car une partie est codée à l'aide de clés de cryptage stockées de manière sécurisée en accès, dans une mémoire de type ROM du coprocesseur. Ce principe implique le fait qu'un utilisateur ayant obtenu une licence d'utilisation d'un logiciel protégé selon cette méthode soit attaché à l'ordinateur hôte sur lequel le logiciel a été installé. De plus, la possibilité de protéger plusieurs logiciels de plusieurs sociétés de concepteur est difficile à mettre en oeuvre. Ainsi, un coprocesseur ayant des -2-Designers who wish to control this phenomenon of copies and / or unlawful use of their software, buy an electronic device to protect somehow these software. But this solution is only possible for certain software.
In addition, these designers are dependent on the supplier of these means of protection software. The low-budget software developers cannot afford to protect their digital products given the too high price of protection methods compared to sale price of their software.
In addition, the use of these electronic devices requires from the designer software, a purchase of these devices before the actual sale of its software.
This situation forces the constitution of a stock which can represent a disadvantage compared to its competitors who would have chosen not to use software protections.
To address all of these software usage issues, different solutions were brought so far. A software or network protection solution monopostes (personal computers) is proposed in the US Pat patent. No. 5,553,139.
However it does not not allow software to be protected by the same device system coming from to several different software designers.
Other methods are used for a given computer through of systems connected directly to an I / O port on the host computer. A
such system is proposed in US Pat. No. 5,343,524. This invention is based on the use of a circuit electronic based on a secure microcontroller, which cannot be reproduced.
The protection of software with respect to this invention relates to the fact that software protected can verify by through keys, the presence of this device and interact with that apparatus. However the devices according to this invention have the disadvantage of only protecting software large productions because of its cost, and on the other hand not being able protect that software from the same designer. An example of a similar product is distributed by Rainbow company.
On the other hand, fully software protection methods are also employed. These protections very often consist in requesting an access code to the user. This code is then checked using a very complicated calculation. However, it does not prevent some users of find the type of calculation that is used so that protected software in this way do offer no reliability compared to software protection.
More powerful systems are used through the use of coprocessor that can calculate some of the codes of a given and protected software according to this method. Generally, these software cannot be used directly as it stands have been delivered to the user, because part of it is encrypted using encryption keys stored so secure in access, in a coprocessor ROM type memory. This principle implies that a user having obtained a license to use software protected by this method either attached to the computer host on which the software was installed. In addition, the possibility of protect multiple software from multiple designer companies is difficult to implement. So a coprocessor with

-3~
caractéristiques similaires est proposé par le brevet U.S. Pat. No. 4,817,140.
:Je coprocesseur relative à ce brevet est lancé à condition que l'utilisateur dispose d'une clé
pour justifier son achat de licences d'utilisation. Un tel système présente un autre désavantage : son utilisation dédiée à la protection de logiciels d'un seul concepteur, peut rendre la présence d'un coprocesseur génant notamment quand d'autres concepteurs décide de fournir un moyen de protections de logiciels similaire. Dans certains cas, l'ajout de nouveau appareil peut être impossible. Par ailleurs, un tel coprocesseur représente un investissement possible qu'avec des logiciels dont le prix est très haut (coûteux) par rapport au prix de ce coprocesseur déjà onéreux. De plus, l'utilisateur est lié à
l'ordinateur sur lequel est installé le coprocesseur.
La plupart des systèmes utilisés pour la protection de logiciels sont dédiés à
une catégorie précise de logiciels. L'image de ces systèmes vis à vis de l'utilisateur peut être gênant dans la mesure où ils sont assimilés à une sorte de police électronique de surveillance et non de protections. De plus, ces systèmes sont contraignants dans la mesure où
l'utilisation de logiciels protégés par ces systèmes est liée à l'ordinateur hôte sur lequel est installé
le logiciel. De plus l'écriture d'un logiciel protégé est très dépendante de l'architecture du moyen de protections, ce qui peut rendre le développement du logiciel compliqué. De plus, comme dans le cas des « dongles », l'utilisateur est lié dans l'utilisation des logiciels aux moyens qui servent à la protections de logiciels. Ainsi, à titre d'exemple, si un dongle est perdu, cette perte entraîne très souvent la perte du droit d'utilisation du logiciel attaché au dongle perdu. D'autre part, les systèmes de protection de logiciels ne tiennent pas compte du fait qu'un logiciel attaché à son système électronique de protection peut être volé. Dans ce cas de vol, et d'utilisation illicite par rapport au voleur, il n'y a pas moyen d'empêcher l'utilisation du logiciel volé. De plus, l'utilisateur devra obtenir une nouvelle licence par un nouvel achat.
De plus, certains logiciels protégés sont caractérisés par leur utilisation limitée dans le temps.
Un tel système est présenté par le brevet U.S. Pat. No. 4,868,736. Ce brevet à
le désavantage de ne pouvoir réaliser que cette fonctionnalité.
Ainsi, la présente invention permet de remédier à tous les inconvénients qui viennent d' être cités.
La présente invention concerne la protection de logiciel contre le non respect des conditions d'utilisations des logiciels fixés par son concepteur. Elle concerne l'utilisation d'un seul appareil pour protéger plusieurs logiciels indépendamment des systèmes informatiques et du concepteur de ces logiciels. II est basé sur l'utilisation de deux appareils électroniques qui ne peuvent pas être dupliqués sans autorisations. Cette protection contre la duplication des appareils selon la présente invention est réalisée grâce à une méthode d'authentification intégrée dans ces appareils.
Le premier appareil est un lecteur électronique du second. Il est noté LCL
pour lecteur de cartes de licences. Ce lecteur assure la quasi-totalité des fonctionnalités de protections de logiciels selon la présente invention. -3 ~
Similar characteristics are proposed by the US Pat. No. 4,817,140.
: I coprocessor relating to this patent is launched on condition that the user has a key to justify his purchase of user licenses. Another disadvantage of such a system is its use dedicated to software protection from a single designer, can make the presence of a annoying coprocessor especially when other designers decide to provide a means of protection software similar. In some cases, adding a new device may be impossible. Furthermore, such coprocessor represents a possible investment only with software including the price is very high (expensive) compared to the price of this already expensive coprocessor. Moreover, the user is linked to the computer on which the coprocessor is installed.
Most systems used for software protection are dedicated to a category accurate software. The image of these systems towards the user can be troublesome in the to the extent that they are likened to some kind of electronic police of surveillance and not of protections. In addition, these systems are restrictive insofar as the use of software protected by these systems is linked to the host computer on which is installed The software. Moreover writing protected software is very dependent on the architecture of the means of protections, which can make software development complicated. In addition, as in the case "dongles", the user is bound in the use of the software to the means which serve to the protections of software. So, for example, if a dongle is lost, that loss very often results in loss the right to use the software attached to the lost dongle. On the other hand, protection systems of software does not take into account the fact that software attached to its electronic system protection can be stolen. In this case of theft, and illicit use by relation to the thief there is no way to prevent the use of stolen software. In addition, the user will have to get a new license with a new purchase.
In addition, certain protected software is characterized by its use limited in time.
Such a system is presented by the US Pat patent. No. 4,868,736. This patent to the disadvantage of not be able to realize that this functionality.
Thus, the present invention overcomes all the drawbacks which have just been cited.
The present invention relates to software protection against non-compliance conditions of uses of the software fixed by its designer. It relates to using only one device to protect multiple software independently of computer systems and from the designer of these software. It is based on the use of two electronic devices who cannot be duplicated without authorization. This protection against duplication of devices according to this invention is realized thanks to an authentication method integrated in these devices.
The first device is an electronic reader of the second. It is noted LCL
for reader license cards. This reader provides almost all of the functionality of software protections according to the present invention.

-4-Le second appareil est une carte électronique, notée CL (carte de licences).
Chaque utilisateur qui désire exécuter des logiciels protégés selon la présente invention, doit posséder une carte CL
sur lequel les autorisations d'utilisations de logiciels protégés selon la présente invention, sont stockées.
Ainsi, la présente invention sépare sur trois niveaux la protection de logiciels. Dans un premier temps, la présente invention concerne une méthode permettant la séparation du logiciel protégé (media d'enregistrement) du moyen qui réalise la protection de ce logiciel (le lecteur LCL).
Dans un deuxième temps, le lecteur LCL est distribué de manière indépendante par rapport à la distribution des logiciels protégés selon la présente invention. Ainsi, le même lecteur LCL, peut être utilisé pour permettre la protection de plusieurs logiciels indépendamment des concepteurs et du nombre de logiciels. L'utilisation de logiciels protégés selon la présente invention, n'est possible que si l'utilisateur dispose de la carte CL qui est distribuée indépendamment du lecteur LCL.
Selon la présente invention, la carte CL est un appareil portatif de petite taille par rapport à
une carte à puces. Elle possède un dispositif amovible d'enregistrement de grande capacité. Elle permet de stocker des données de manière sécurisée contre des lectures et/ou modifications non autorisées. Elle est essentiellement utilisée comme un dispositif d'accès permettant l'utilisation des logiciels protégés selon la présente invention. Les conditions d'utilisation d'un logiciel sont fixées par les concepteurs de logiciels. Un utilisateur ne peut exécuter un logiciel qu'à condition de posséder une autorisation qui lui a été fournie sur sa carte CL lors d'une opération d'achat. La carte CL permet de stocker sur un média d'enregistrement amovible un grand nombre d'autorisations d'utilisations de logiciels protégés. Ainsi, la carte CL penmet à
l'utilisateur de transporter les autorisations d'utilisation de logiciels et de pouvoir utiliser les logiciels correspondants sur tout ordinateur lorsque l'utilisation de ces logiciels dont il a le droit est possible par rapport à la présence ou non de ces logiciels protégés sur cet ordinateur.
La présente invention concerne par rapport à l'usage de cette carte CL un moyen de lutter contre les pertes ou le vol de cette carte CL. En cas de pertes ou de vols, la carte peut être rendue inutilisable par l'organisme qui gère (administre) les appareils selon la présente invention. Une partie importante des licences d'utilisations de ces logiciels peut être récupérer en cas de perte.
Ainsi, l'utilisateur ne coure pas le risque de perdre ses droits d'utilisation d'un logiciel lors de pertes de carte CL, ce qui peut être le cas avec les appareils de protection de logiciels dans l'état actuel de l' art.
La présente invention concerne des méthodes de protection de logiciels indépendamment des systèmes informatiques. La présente invention permet la protection de logiciels utilisés en réseau et/ou sur un ordinateur personnel. Le lecteur LCL possède une grande capacité
de modularité par rapport aux différents périphériques qui peuvent être ajouté sur son système électronique interne.
Ainsi, il très facile de connecter le lecteur LCL sur tout environnement informatique. Ainsi, la protection de logiciels selon la présente invention, est réalisable avec le même lecteur LCL dans _5~
des systèmes informatiques très hétérogènes où de nombreux systèmes différents cohabitent. Le fonctionnement des lecteurs LCL est indépendant de ces systèmes informatiques.
Par conséquent, les lecteurs LCL permettent la protection des logiciels indépendamment des systèmes informatiques prévus pour exécuter ces logiciels.
La présente invention permet le développement de logiciels protégés indépendamment des caractéristiques techniques des appareils selon la présente invention. Le développement des logiciels protégés selon la présente invention, est indépendant du fonctionnement interne du LCL.
La réalisation d'un logiciel protégé selon la présente invention est rendue possible en faisant exécuter une partie des fonctions qui composent ce logiciel par les ressources interne du LCL.
L'écriture de ces fonctions est complètement transparente dans la mesure où le concepteur de logiciel n'est pas tenu de respecter l'architecture électronique du LCL. Le bon fonctionnement de ces fonctions peut même être testé à l'extérieur du lecteur LCL, de sorte que le travail de protections de logiciels pour le concepteur s'arrête à l'écriture de ces fonctions. Ces fonctions sont essentiellement des fonctions de calculs de petite taille par rapport à la taille d'un logiciel standard et dont l'exécution est très rapide. Ainsi, plusieurs logiciels protégés différents peuvent être utilisés dans le cadre d'un réseau avec le même lecteur LCL. De plus, plusieurs logiciels protégés selon la présente invention peuvent donc être utilisés sur un ordinateur personnel avec un seul lecteur LCL.
Le fonctionnement du lecteur LCL utilisé avec un ordinateur personnel par rapport à une utilisation dans un environnement réseau ne diffère qu'au niveau des périphériques de communication utilisés dans chaque cas.
Selon la présente invention, le lecteur LCL réalise la protection de logiciel en effectuant des mesures sur l'utilisation de tous les logiciels en cours d'exécution. Le lecteur LCL est selon la présente invention, capable de connaître le nombre de licences utilisées sur un ordinateur et/ou sur tout le réseau auquel il est connecté. Il est capable de connaître la durée d'utilisation d'un logiciel donné par un utilisateur donné. Selon la présente invention, il est capable de cannaître toutes les informations d'utilisation concernant un logiciel donnée par rapport au temps.
Ces moyens de mesure propre au lecteur LCL permettent au lecteur LCL d'arbitrer l'utilisation des logiciels protégés selon la présente invention. Cet arbitrage est effectué par rapport aux conditions d'utilisation de chaque logiciel protégé selon la présente invention. Ces conditions sont fixées par le concepteur de ces logiciels.
Ainsi, selon la présente invention, la carte CL sert à stocker des autorisations d'utilisations de logiciels et le profil de l'utilisateur par rapport à son utilisation des logiciels protégés selon la présente invention. Le lecteur LCL est chargé de vérifier si le profil de l'utilisateur par rapports à
ses droits d'utilisations des logiciels, correspond bien aux conditions d'utilisation fixées par le concepteur de ces logiciels. Ces conditions peuvent être selon la réalisation de la présente invention, des conditions d'utilisations limitées dans le temps, des conditions d'ouverture simultanée d'un nombre de sessions d'exécution limitées par le nombre de licences d'utilisation possédées par le propriétaire de la carte CL.

Ainsi, un seul lecteur LCL peut arbitrer sur un ou plusieurs ordinateurs l'utilisation de un ou plusieurs logiciels différents protégés selon la présente invention. Les règles d'arbitrages peuvent être spécifiques à chaque version de logiciels, ce qui permet la protection de plusieurs logiciels par un seul appareil selon des critères spécifiques à l'utilisation de chaque logiciel protégé.
La présente invention permet une distribution des logiciels protégés indépendamment des moyens de protection de sorte que le développeur de logiciels peut ne pas constituer de stocks d'appareils permettant la protection. Ainsi, la protection de logiciels selon la présente invention est intéressante pour les petites et les grandes distributions de logiciels :
l'usage d'un seul appareil pour la protection de plusieurs logiciels indépendamment des concepteurs ne peut que diminuer le coût d'utilisation du système de protection de logiciels selon la présente invention. De plus, la présente invention permet une grande souplesse par rapport à l'administration des logiciels protégés. La vente des autorisations d'utilisation d'un logiciel données peut être centralisée ou décentralisée.
De plus, selon la présente invention, la création de logiciel protégé peut être effectuer de plusieurs manière. Les autorisations pour créer un logiciel protégé selon la présente invention, peuvent être centralisées ou décentralisé (situation décrite dans le cas de développement de logiciels de démonstrations ou de logiciels dont l'utilisation est limitée).
De plus, les appareils selon la présente invention peuvent effectuer des communications avec des systèmes distants. L'administration de ces appareils est effectuée par un système distant qui est selon la réalisation de la présente invention, un serveur noté aSVR. Ce serveur fixe les conditions d'utilisations des appareils selon la présente invention. Il arbitre de manière générale l'utilisation des appareils selon la présente invention.
De plus, les autorisations d'utilisation de logiciels contenue dans une carte CL peuvent être soit déplacées dans le lecteur LCL, soit dans une autre carte CL. Dans le cas où le déplacement aurait lieu vers un lecteur LCL, l'accès aux logiciels protégés peut être réalisé sans la présence d'une carte CL. Dans le cas de déplacements vers une autre carte CL, cela permet des distributions de licences d'utilisations de logiciels par des revendeurs. La présente invention permet ou non la centralisation des ventes des autorisations de logiciels.
De plus, selon la présente invention, le lecteur de cartes LCL possède un ou des dispositifs) qui permet un rajout de périphériques rapidement et facilement. Selon des modes particuliers de réalisation, le lecteur LCL dispose d'un récepteur radio pour recevoir des informations de manière sécurisée ou non grâce à un dispositif d'émission géré par ledit serveur aSVR.
Ce récepteur est essentiellement utilisé pour des opérations d'achat d'autorisations d'utilisation de logiciels hors ligne, des opérations de mise à jour. Il permet aussi de gérer la sécurité
d'utilisation des appareils selon la présente invention.
La présente invention permet par ses moyens et ses méthodes des achats soit par des connexions informatiques, soit par un système d'accueil humain. Les achats peuvent donc être effectués en ligne ou hors ligne. Ces achats consiste en l'acquisition des autorisations d'utilisations _7_ de logiciels protégés selon la présente invention. La présente concerne l'emploi d'un récepteur radio numérique permettant en particulier la réception de ces autorisations d'utilisations.
Pour réaliser la protection de plusieurs logiciels indépendamment de leurs concepteurs, la présente invention concerne l'utilisation au sein du lecteur LCL, d'un microcontrôleur sécurisé
contre les lectures et/ou les modifications non autorisées de sa mémoire interne et contre des attaques de virus informatiques qui peuvent être rencontrés dans la mesure où
ce microcontrôleur exécute des programmes dont il ignore la fiabilité, l'utilisation du lecteur comme moyen de protection de logiciels est libre en dehors des accords commerciaux éventuels.
Ainsi, cette propriété permet à ce que l'usage du lecteur LCL et de la carte CL sont complètement libre.
Pour permettre à l'utilisateur de transporter des autorisations d'utilisations de logiciels protégés, la carte CL est de petite taille. II est basé sur un microcontrôleur permettant de sécuriser l'accès aux informations qui défroissent les droits d'utilisations d'un logiciel donné. Il peut stocker un très grand nombre d'autorisation d'utilisations de logiciels protégés selon la présente invention.
Les informations sont stockées sur un média d'enregistrement de fortes capacités. Elles sont 1 S protégées contre toutes modifications et lectures non autorisées. De plus, le système interne de son microcontrôleur est aussi protégé contre tout contrôle physique et logique.
De plus, la présente invention concerne un système de protection de logiciel évolutif dans la mesure où il est possible de mettre à jour l'ensemble des systèmes informatiques contenus dans les microcontrôleurs cités précédemment. Compte tenu de leur capacité de sécuriser le stockage de données et l'exécution de programmes, compte tenu aussi de la possibilité de mettre facilement à
jour les systèmes informatiques des appareils selon la présente invention, la présente invention permet à des appareils de protection de logiciels d'être utilisée dans d'autres secteurs d'applications.
Les dessins annexés illustrent l'invention La figure 1 illustre l'ensemble des variantes de connexion mise en jeux dans la présente invention, et refléte le fonctionnement général de l'invention. Elle permet de comprendre les différents contextes d'utilisations des appareils selon la présente invention.
La figure 2 illustre les différentes couches de logiciels nécessaires pour que un LCL donné
puissent se connecter vers un système distant.
La figure 3 illustre le schéma synoptique de l'architecture du microcontrôleur utilisé dans l'appareil LCL.
La figure 4 reflète les associations possibles entre deux LCL concurrents sur le même réseau, pour permettre le partage des opérations liées à la protection de logiciels par la présente invention.
La figure 5 illustre le schéma synoptique des différents éléments composant la carte électronique CL, notamment l'architecture du microcontrôleur associé à une carte CL.
La figure 6 représente une vue de face du boîtier de la carte CL.
La figure 7 représente une vue en perspective du boîtier CL avec la carte CompactFlash sortie de son support.

_g_ La figure 8 illustre les jeux de connecteurs mâles femelles entre LCL et CL.
La figure 9 illustre le fait que les appareils selon la présente invention possèdent des durées d'utilisation par rapport au calendrier.
La figure 10 illustre les étapes d'une procédure d'authentification empêchant des appareils pirates de fonctionner avec les appareils (lecteurs LCL et cartes CL) certifiés.
La figure 11 illustre les étapes d'une opération d'achat de licences d'utilisation de logiciels protégés selon la présente invention.
La figure 12 illustre un arbre logique, simplifié et utilisé par le système d'exploitation du microcontrôleur 100 pour effectuer la protection de logiciel.
En référence à la figure 1, selon la réalisation de la présente invention, l'ensemble du systëme qui exploite le lecteur électronique, peut avoir une gestion centralisée par l'intermédiaire d'un serveur aSVR qui possède une base de données 12 relatives aux appareils selon la présente invention. L'ensemble des éléments compris dans l'encadré 10 est géré par un organisme donné.
Cet organisme est le distributeur des appareils relatifs à la présente invention. Le serveur aSVR
peut communiquer avec des systèmes informatiques distants utilisant un lecteur LCL. Selon des variantes de la réalisation de la présente invention, un lecteur LCL peut posséder un moyen pour se connecter soit directement sur un réseau 40, soit siu~ un port E/S d'un ordinateur personnel (contexte représenté par l'encadré 30) ou posséder un radiorécepteur numérique 22 (contexte représenté par l'encadré 20).
Selon la réalisation de la présente invention, la figure 2 illustre les différentes couches traversées par LCL pour atteindre un système distant. Les communications entre le système distant et LCL sont gérées par deux programmes tournant sur un ordinateur 50. La connexion 54 entre l'ordinateur et un lecteur LCL peut en fonction du type d'utilisation être une connexion réseau dans le cas de l'encadré 40 ou une connexion directe sur un port E/S de l'ordinateur 50 dans les contextes 30 et 20. Le port retenu pour la réalisation de la présente invention, dans les contextes 30 et 20, est un port USB (Universal Serial Bus) pour des raisons de rapidité, en supposant que les ordinateurs utilisés possèdent un tel port de communication. La description de la présente invention a retenu pour le contexte d'utilisation 40, le cas d'un réseau Ethernet avec le protocole TCP/IP.
Ainsi, dans ce contexte le lecteur LCL possédera un périphérique réseau adéquat. Le programme PGM 52 permet de communiquer de manière interactive avec un lecteur LCL donné.
Ces conununications se font grâce au programme driver DRV 51. En référence à la figure 2, ce driver 51 réalise toutes les fonctions de communications entre un lecteur LCL et un ordinateur 50 connecté à ce lecteur. Les différentes fonctionnalités de ces deux programmes propres à la gestion des appareils selon la présente invention, seront définie par la suite. Le programme PGM permet d'assurer au lecteur LCL une communication avec un système distant. Pour réaliser cette communication, PGM utilise les ressources de communications 53 de l'ordinateur hôte 50. Le programme DRV assure quant à lui la communication locale entre le lecteur LCL
et le programme PGM. Dans le cas 30, il peut s'agir du modem 31 permettant une connexion vers le réseau Internet WO 9913925b PCT/FR99/00182 auquel est attaché lc; serveur aSVR. Selon la réalisation de la présente invention, pour le cas 40, la ressource de communication 53 est celle de 1"ordinateur 50 par rapport aux ressources du réseau local, permettant un accès vers un système distant via le réseau Internet.
L'utilisation dc;s lecteurs LCL est sous soumise par une condition d'identification lors de sa -4-The second device is an electronic card, marked CL (license card).
Each user who wishes to run protected software according to the present invention, must have a CL card on which the authorizations to use software protected according to the present invention are stored.
Thus, the present invention separates on three levels the protection of software. In one firstly, the present invention relates to a method allowing the software separation protected (recording media) of the means which achieves the protection of this software (the LCL reader).
Secondly, the LCL reader is distributed independently compared to the distribution of protected software according to the present invention. So the same LCL reader, can be used to protect multiple software regardless of the designers and the number of software. Use of software protected under this invention is possible only if the user has the CL card which is distributed regardless of reader LCL.
According to the present invention, the CL card is a portable device of small size compared to a smart card. It has a removable device for recording big capacity. She allows data to be stored securely against readings and / or changes no allowed. It is mainly used as an access device allowing the use of protected software according to the present invention. Conditions of use of software are fixed by software designers. User cannot run software that provided have an authorization provided to him on his CL card during a purchase transaction. The map CL allows to store a large number on removable recording media permissions protected software uses. Thus, the CL card allows the user to carry the authorizations to use software and to be able to use software correspondents on everything computer when the use of this software for which it is entitled is possible compared to the whether or not this protected software is present on this computer.
The present invention relates to the use of this CL card a way to fight against loss or theft of this CL card. In the event of loss or theft, the card can be returned unusable by the body that manages (administers) the devices according to the present invention. A
important part of the licenses to use this software can be recover in case of loss.
Thus, the user does not run the risk of losing his rights of use software during CL card losses, which can be the case with protective devices software in the state current art.
The present invention relates to software protection methods regardless of Informatic Systems. The present invention allows the protection of network software and / or on a personal computer. LCL reader has a large capacity modularity by different devices that can be added to his system internal electronics.
This makes it very easy to connect the LCL reader to any environment computer science. So the software protection according to the present invention is achievable with the same LCL reader in _5 ~
very heterogeneous IT systems where many different systems coexist. The operation of LCL readers is independent of these computer systems.
Therefore, LCL readers allow software protection regardless of systems computer systems intended to run this software.
The present invention allows the development of protected software regardless of technical characteristics of the apparatuses according to the present invention. The development of protected software according to the present invention, is independent of internal functioning of LCL.
The production of protected software according to the present invention is made possible by doing perform some of the functions that make up this software by resources internal LCL.
The writing of these functions is completely transparent since the designer software is not required to respect the LCL electronic architecture. The smooth operation of these functions can even be tested outside of the LCL reader, so that the work of software protections for the designer stops writing these functions. These functions are basically small computational functions compared to the standard software size and whose execution is very fast. Several protected software different can be used as part of a network with the same LCL reader. In addition, several software protected according to the present invention can therefore be used on a personal computer with a single LCL reader.
The operation of the LCL reader used with a personal computer by in relation to use in a network environment only differs at the peripheral level communication used in each case.
According to the present invention, the LCL reader performs software protection by performing measures on the use of all software running. The LCL reader is according to the present invention, capable of knowing the number of licenses used on a computer and / or on the entire network to which it is connected. He is able to know the duration use of software given by a given user. According to the present invention, it is capable of cannaitre every usage information for software given over time.
These means of measurement specific to the LCL reader allows the LCL reader to arbitrate the use of software protected according to the present invention. This arbitration is carried out against at the conditions of use of each protected software according to the present invention. These conditions are set by the designer of this software.
Thus, according to the present invention, the CL card is used to store permissions to use software and the user's profile in relation to their use of software protected according to the present invention. The LCL reader is responsible for checking whether the profile of the user in relation to his rights to use the software, corresponds well to the conditions of use fixed by the designer of this software. These conditions can be according to the realization of this invention, time-limited conditions of use, opening conditions simultaneous of a number of execution sessions limited by the number of user licenses owned by the owner of the CL card.

Thus, a single LCL reader can arbitrate on one or more computers the use of one or several different software protected according to the present invention. The arbitration rules can be specific to each version of software, which allows the protection of several software by a single device according to criteria specific to the use of each protected software.
The present invention allows distribution of protected software regardless of means of protection so the software developer may not build up stocks protection devices. So software protection according to the present invention is interesting for small and large software distributions:
use of a single device for the protection of several software regardless of the designers may only decrease the cost of using the software protection system according to this invention. In addition, the present invention allows great flexibility with respect to administration softwares protected. The sale of authorizations to use given software may be centralized or decentralized.
In addition, according to the present invention, the creation of protected software can be perform of several ways. The permissions to create protected software according to the present invention, can be centralized or decentralized (situation described in the case of development of demo software or software whose use is limited).
In addition, the apparatuses according to the present invention can perform communications with remote systems. The administration of these devices is carried out by a remote system which is according to the embodiment of the present invention, a server noted aSVR. This server sets conditions of uses of the apparatuses according to the present invention. He arbitrates from generally use devices according to the present invention.
In addition, the authorizations to use software contained in a card CL can be either moved to the LCL reader or to another CL card. In the case where moving would take place to an LCL reader, access to protected software can be realized without the presence a CL card. In the case of travel to another CL card, this allows distributions software licenses by resellers. The current invention allows or not the centralized sales of software authorizations.
In addition, according to the present invention, the LCL card reader has one or more devices) which allows adding devices quickly and easily. According to particular modes of realization, the LCL reader has a radio receiver to receive information so secured or not thanks to a transmission device managed by said aSVR server.
This receiver is mainly used for authorization purchase operations of software usage outside line, update operations. It also allows you to manage security device usage according to the present invention.
The present invention allows by its means and methods of purchasing either by computer connections, either through a human reception system. Purchases can therefore be performed online or offline. These purchases consist of the acquisition of usage authorizations _7_ protected software according to the present invention. This concerns the use of a receiver digital radio allowing in particular the reception of these authorizations of uses.
To protect multiple software regardless of their designers, the The present invention relates to the use within the LCL reader, of a secure microcontroller against unauthorized readings and / or modifications of its memory internal and against computer virus attacks that may be encountered to the extent that this microcontroller runs programs of which it is unaware of the reliability, the use of the reader as a means of software protection is free outside of possible commercial agreements.
So this property allows that the use of the LCL reader and the CL card are completely free.
To allow the user to carry usage authorizations software protected, the CL card is small. It is based on a microcontroller to secure access to information that clears the rights of use of a given software. It can store a very large number of authorizations to use protected software according to the present invention.
Information is stored on strong recording media capabilities. They are 1 S protected against all unauthorized modifications and readings. Moreover, the internal sound system microcontroller is also protected against any physical and logical control.
In addition, the present invention relates to a software protection system.
evolving in the since it is possible to update all systems information contained in microcontrollers mentioned above. Given their ability to secure storing data and program execution, also taking into account the possibility of easily put on update the computer systems of the apparatuses according to the present invention, the present invention allows software protection devices to be used in other sectors of applications.
The accompanying drawings illustrate the invention Figure 1 illustrates all of the connection variants used in the current invention, and reflects the general operation of the invention. She allows to understand the different contexts of use of the devices according to the present invention.
Figure 2 illustrates the different layers of software necessary for a given LCL
can connect to a remote system.
FIG. 3 illustrates the block diagram of the architecture of the microcontroller used in the LCL device.
Figure 4 reflects the possible associations between two competing LCLs on the same network, to allow the sharing of software protection operations by the present invention.
FIG. 5 illustrates the block diagram of the various elements making up the menu CL electronics, in particular the architecture of the microcontroller associated with a CL card.
FIG. 6 represents a front view of the housing of the CL card.
Figure 7 shows a perspective view of the CL housing with the card CompactFlash output of its support.

_g_ FIG. 8 illustrates the sets of female male connectors between LCL and CL.
FIG. 9 illustrates the fact that the apparatuses according to the present invention have durations of use compared to the calendar.
Figure 10 illustrates the steps of an authentication procedure preventing machines hackers to work with devices (LCL readers and CL cards) certified.
Figure 11 illustrates the steps in a license purchase process software usage protected according to the present invention.
Figure 12 illustrates a simplified logic tree used by the system operating the microcontroller 100 to perform software protection.
With reference to FIG. 1, according to the embodiment of the present invention, the whole system which operates the electronic reader, can have centralized management by through a aSVR server which has a database 12 relating to the devices according to the current invention. All of the elements included in Box 10 are managed by a donated organism.
This organization is the distributor of the devices relating to this invention. The aSVR server can communicate with remote computer systems using a reader LCL. According to variants of the embodiment of the present invention, an LCL reader can have a way to connect either directly to a network 40, or siu ~ an I / O port of a personal computer (context represented by box 30) or have a digital radio receiver 22 (context represented by box 20).
According to the embodiment of the present invention, FIG. 2 illustrates the different layers crossed by LCL to reach a remote system. Communications between the remote system and LCL are managed by two programs running on a computer 50. The connection 54 between the computer and an LCL reader can, depending on the type of use, be a network connection in the case of box 40 or a direct connection to an I / O port of computer 50 within contexts 30 and 20. The port chosen for the realization of this invention, in contexts 30 and 20, is a USB (Universal Serial Bus) port for reasons of speed, in assuming that computers used have such a communication port. The description of the present invention retained for the context of use 40, the case of an Ethernet network with the TCP / IP protocol.
In this context, the LCL reader will have a network device adequate. The program PGM 52 allows interactive communication with a given LCL reader.
These communications are made using the DRV 51 driver program. With reference to the figure 2, this driver 51 performs all communication functions between an LCL reader and a computer 50 connected to this player. The different functionalities of these two programs management specific devices according to the present invention will be defined below. The PGM program allows to ensure the LCL reader communication with a remote system. For realize this communication, PGM uses the communications resources 53 of the computer host 50. The DRV program provides local communication between the LCL reader and the program PGM. In case 30, it can be modem 31 allowing a connection to the Internet WO 9913925b PCT / FR99 / 00182 to which is attached lc; aSVR server. According to the realization of this invention, for case 40, the communication resource 53 is that of 1 "computer 50 with respect to network resources local, allowing access to a remote system via the Internet.
The use of LCL readers is subject to a condition identification when

5 mise en marche, et par une condition de la connexion effective de la carte CL sur un support du lecteur LCL. Ces deux conditions seront décrites par la suite.
Le contexte 20 correspondant à des situations où le lecteur LCL est connecté
sur un ordinateur ne possédant pas de; moyens de communication avec un système distant. Ce fonctionnement sera décrit par la suite.
10 Selon la présente invention, la protection de logiciel est rendue possible en faisant exécuter une petite partie des fonctions d'un logiciel donné, par ledit lecteur électronique, noté LCL. Ladite carte électronique, noté CL, possède les autorisations d'utilisation du logiciel. Compte tenu de sa capacité de stockage;, la carte CL peut stocker 'une grande quantité
d'autorisations d'utilisation. De cette manière, la présente invention permet par le moyen d'un seul dispositif électronique, la 15 protection de plusie»rs logiciels simultanément et indépendamment de leurs concepteurs.
Selon la réalisation de la présente invention, le lecteur LCL et la carte CL
sont respectivement associés à deux numéros de série uniques. L'ensemble des informations permettant le fonctionnement du lecteur LCL et de la carte CL pour réaliser la protection de logiciels, est géré
par le serveur aSVR. à l'aide de sa base de données 12 qui doit être protégée contre des accës non 20 autorisés par rapport à la sécurité du système mise en place pour la protection de logiciels.
L'organisme en que;~tion qui gère aSVR attribue respectivement à une carte CL
donné et un lecteur LCL donné, les numéros de séries ID.c et ID.d, et les clés secrètes de codages kT.c et kT.d. Les numéros ID.c et ID.~i sont uniques. Ces deux numéros et ces deux clés secrètes sont stockés dans de la mémoire non volatile qui se trouve dans le système électronique de CL et de LCL. Des 25 précisions seront données ultérieurement. Les couples (ID.c, kT.c) et (ID.d, kT.d) sont stockés par ailleurs dans la base de données 12 accessible uniquement par aSVR pour des raisons de sécurités évidentes. Les clés lcT.c et kT.d sont connues uniquement par aSVR, en dehors des appareils LCL
et CL.
De plus, selon la réalisation de la présente invention, les numéros ID.c et ID.d sont publics, 30 mais non modifiables. Cela signifie qu'ils sont stockés dans la mémoire protégée du système électronique intégra dans chaque appareil relatif à la présente invention, et qu ils sont communiqués par ailleurs à leur utilisateur sous une forme claire. Selon la réalisation de la présente invention, ils sont marqués sur le boîtier de CL et de LCL. De plus, la présente invention ne concerne la forme du boîtier utilisé pour le lecteur LCL.
35 Selon la réalïsation de la présente invention, la méthode de cryptage adoptée avec les clés secrètes de codage lcT.d et kT.c, concerne le cryptage DES (data encryption standard) développé
par la société IBM. Ces deux clés ont une taille de 128 bits suffisante contre des craquages de codes. Selon des modes particuliers de réalisation, on pourra choisir d'autre type de cryptage et de WO 99/39255 start-up, and by a condition of the effective connection of the card CL on a support of LCL reader. These two conditions will be described later.
Context 20 corresponding to situations where the LCL reader is connected on a computer not having; means of communication with a remote system. This operation will described later.
According to the present invention, software protection is made possible by having executed a small part of the functions of a given software, by said reader electronic, noted LCL. Said electronic card, marked CL, has the authorizations to use the software. Given its storage capacity; the CL card can store a large amount usage authorizations. Of this way the present invention allows by means of a single device electronic, the 15 protection of several software simultaneously and independently of their designers.
According to the embodiment of the present invention, the LCL reader and the CL card are respectively associated with two unique serial numbers. All information allowing the operation of the LCL reader and the CL card to protect the software, is managed by the aSVR server. using its database 12 which must be protected against unauthorized access 20 authorized in relation to the security of the system put in place for software protection.
The organization in which ~ ~ which manages aSVR allocates respectively to a CL card given and a reader LCL given, ID.c and ID.d serial numbers, and secret coding keys kT.c and kT.d. The ID.c and ID numbers. ~ i are unique. These two numbers and these two secret keys are stored in non-volatile memory found in the electronic system of CL and LCL. Of 25 details will be given later. The couples (ID.c, kT.c) and (ID.d, kT.d) are stored by elsewhere in the database 12 accessible only by aSVR for security reasons obvious. The keys lcT.c and kT.d are known only by aSVR, outside LCL devices and CL.
In addition, according to the embodiment of the present invention, the numbers ID.c and ID.d are public, 30 but cannot be modified. This means that they are stored in memory protected from the system integrated electronics in each device relating to the present invention, and they are communicated to their user in a clear form. According to realization of this invention, they are marked on the CL and LCL housing. In addition, the present invention does concerns the shape of the case used for the LCL reader.
According to the embodiment of the present invention, the encryption method adopted with keys coding secrets lcT.d and kT.c, concerns DES encryption (data encryption standard) developed by the company IBM. These two keys have a size of 128 bits sufficient against crackles of codes. According to particular embodiments, it will be possible to choose other type of encryption and WO 99/3925

6 PCT/FR99/00182 taille de clés de codage.
Selon la présente invention, les appareils LCL et CL sont paramétrables dans une certaine mesure par l'intermédiaire d'un programme informatique, noté PGM, adapté pour chaque type d'ordinateur et de systèmes d'exploitation informatique. PGM permet à un utilisateur de démarrer des procédures relatives à des opérations nécessitant une intervention de l'utilisation. Ces procédures sont décrites par la suite. PGM est distribué par ledit organisme qui gère aSVR. A
l'installation de PGM sur un ordinateur hôte, une opération de localisation d'un lecteur LCL est effectuée. Si un lecteur LCL est connecté directement sur un port de communication de l'ordinateur hôte, un driver logiciel DRV de communication à travers ce port est installé
afin de permettre à un programme de cet ordinateur d'envoyer des données vers LCL et d'en recevoir de LCL en suivant le schéma de la figure 2, sans tenir compte des caractéristiques techniques de la communication entre cet ordinateur et le lecteur LCL connecté. Le driver DRV permet une utilisation transparente du lecteur LCL.
Dans le cas où des logiciels protégés seraient utilisés en réseau (il s'agit du contexte 40), un programme driver DRV adéquat sera installé sur chaque ordinateur du réseau, pour permettre la communication entre ces ordinateurs et le LCL connecté sur ce réseau local. Le driver DRV permet une utilisation transparente de LCL pour chaque ordinateur du réseau qui peuvent avoir des systèmes informatiques différents entre eux.
A son installation sur le réseau Ethernet, le lecteur LCL reçoit une adresse IP par rapport au protocole TCP/IP, qui permet au driver installé sur les ordinateurs du réseau de le localiser.
De plus, chaque driver DRV permet à chaque ordinateur hôte où sont utilisés des logiciels protégés par la présente invention, de communiquer avec le lecteur LCL. La réalisation de la présente invention permet aussi à ce que plusieurs programme PGM puissent établir des communications avec un lecteur LCL donné connecté sur le réseau considéré.
Dans son utilisation réseau 40, le lecteur LCL en cas d'utilisation intensive, peut partager avec d'autre lecteur LCL, sa fonction de protection de logiciels comme on le voit sur la figure 4 où une répartition des ordinateurs utilisant deux lecteurs LCL est illustrée. La répartition des lecteurs LCL présents sur le réseau avec les ordinateurs est, selon la réalisation de la présente invention, réalisée par l'administrateur réseau. Ce dernier effectue la répartition des ordinateurs du réseau par rapport aux lecteurs LCL présents sur le réseau, au moment de l'installation de DRV sur chaque ordinateur de ce réseau. Il indique à DRV l'adresse IP du lecteur LCL à utiliser.
Après l'installation de PGM sur un ordinateur hôte, les utilisateurs de cet ordinateur peuvent alors effectuer sur un lecteur LCL donné, connecté avec une carte CL donnée les différentes opérations suivantes : achat en ligne de licences d'utilisation de logiciels protégés par ia présente invention, déplacement d'un certain nombre de licences d'utilisation de logiciels d'une carte CL
vers une autre carte CL, des opérations de récupération de licences perdues avec la perte d'une carte CL, la mise à jour des programmes contenus dans les mémoires électroniques du lecteur LCL
ou de la carte CL.

Ainsi, la réalisation de la présente invention considère un logiciel donné, noté LD. Les descriptions suivantes sont valables pour tout autre logiciel. Son concepteur (fabricant) le protège selon la présente invention, contre des utilisations illégales en séparant l'ensemble des fonctions composant son logiciel en deux parties. La première partie concerne les procédures dont il désire laisser l'exécution à un ordinateur hôte. La deuxième partie concerne les fonctions qui devront être exécutées par les ressources de calculs de LCL. Ces fonctions doivent être rapide à exécuter. Leur taille est de l'ordre du 100 kilooctets.
De cette deuxième partie dudit logiciel LD, il en extrait une liste de fonctions {Fo, F~,...,F;, ...F"}. Ces fonctions sont nécessaires pour le fonctionnement du logiciel LD.
Pour effectuer cette extraction, il doit respecter une règle primordiale : ces fonctions ne doivent pas faire appel à des ressources caractéristiques des ordinateurs prévus pour l'exécution de LD.
Cette condition est assez facile à respecter. Par exemple, ladite liste de fonctions peut être uniquement des fonctions de calculs purs.
Selon la réalisation de la présente invention, l'écriture de ces fonctions et le test de leur bon fonctionnement peuvent être réalisés indépendamment de la présence du lecteur LCL. Le moyen retenu pour la réalisation de la présente invention, concerne la machine virtuelle JAVA. Ainsi, ces fonctions sont écrites en JAVA. Ces fonctions sont donc compilées en « byte code » du langage universel JAVA et stockées dans un fichier, noté LF.
Par ailleurs, selon la réalisation de la présente invention, la protection du logiciel LD
commence alors par l'exécution du programme PGM sur un ordinateur contenant LF. Selon la réalisation de la présente invention, PGM demande alors au concepteur de LD le système d'exploitation (WINDOWS NT, DOS, L11~TIX,...) et le type d'ordinateur (MACINTOSH, SPARC, PC,...) qui exécuteront LD. Après ces réponses, PGM lance une procédure de connexion du lecteur LCL disponible vers le serveur aSVR. La communication entre LCL et aSVR se fait selon la figure 2. Le numéro de série du lecteur LCL est donné en premier au serveur aSVR.
Durant cette procédure de création d'un logiciel protégé par la présente invention, LCL
demande à aSVR en communication sécurisée un numéro de série S# à associer au logiciel à
protéger LD et une clé de codages kX.S#.
Selon la réalisation de la présente invention, S# est définit sur 128 bits, et Ia clé kX.S# est définie par rapport au cryptage DES avec une taille de 128 bits.
Selon la réalisation de la présénte invention, pour effectuer ladite communication sécurisée avec aSVR, LCL commence par envoyer à aSVR son numéro ID.d sous une forme non codée. Par association avec la clé correspondante, aSVR trouve dans sa base de données 12, la clé kT.d à
associer à ID.d.
Ainsi, aSVR retourne à LCL, S# et kX.S# sous une forme codée avec la clé kT.d.
Le lecteur LCL récupère la forme claire de S# et kX.S# en décodant avec la clé kT.d qui se trouve dans sa mémoire interne 111, par rapport à l'algorithme de cryptage DES.
Selon la présente invention, la clé kX.S# est connue par aSVR seul, car après utilisation, kX.S# sera effacé de la mémoire sécurisée DRAM 109 de LCL. De plus, S# esv communiqué à
PGM qui l'inscrit dans un fichier binaire contenant les conditions limites d'utilisation du logiciel.
Selon la réalisation de la présente invention, ce fichier peut avoir le format suivant : S# du logiciel associé (128 bits), licences permanentes (8 bits), durée d'utilisation (24 bits), (utilisation expire fin (16 bits), nombre d'exécutions (32 bits). Ce (chier fait donc une taille de 26 octets. {Fo, F;,...,F;, ...F"} subissent ensuite des opérations de cryptage. La fonction Fo est traitée à part. Il s'agit selon la réalisation de la présente invention, de la procédure dite d'initialisation permettant d'une part de compter le nombre de licences utilisées sur le réseau dans le contexte réseau 40, et d'autre part de mesurer des caractéristiques d'utilisation du logiciel LD par rapport au temps. C'est une fonction qui est exécutée durant l'exécution du logiciel LD par un utilisateur, et de façon répétitive. Fo est en particulier la première fonction qui sera exécutée par LCL lors de l'ouverture d'une session d'exécutions du logiciel LD.
Fo est codée avec une clé différente de kX.S#. Pour cela le logiciel PGM
génère une clé du même type notée kEL.S# par rapport au cryptage DES. La clé kEL.S# est connue uniquement par le concepteur de LD. Selon la réalisation de la présente invention, kEL.S# est une clé de 128bits. Il est de la responsabilité du concepteur de conserver en sécurité cette clé
kEL.S#. A cette fonction codée, il joint une autre information codée aussi par la clé kEL.S#. Il s'agit du fichier contenant les conditions limites d'utilisation du logiciel LD. Ces informations codées constituent alors un fichier nommé eFo selon la réalisation de la présente invention.
De plus, selon la réalisation de la présente invention, les autres fonctions sont ensuite codées par la clé kX.S#. Pour cette étape, PGM envoie ensuite F,,...,F;, ...F" vers LCL par l'intermédiaire de DRV. Les ressources de calculs de LCL codent alors ces fonctions successivement avec la clé
kX.S#. A la fin des opérations de codage, LCL retourne {eF,,....,eF"}
correspondant respectivement aux formes codées de {F,,..., F"}.
Selon la réalisation de la présente invention, PGM procède ensuite à
l'assemblage du logiciel.
Pour un système d'exploitation donnée, PGM crée un fichier bibliothèque de fonctions qui seront exécutée durant l'exécution du logiciel LD sur l'ordinateur d'un utilisateur donné. Les différentes fonctions de la bibliothèque permettent de charger un élément de {eFo, ....,eF"} avec les paramètres nécessaires à l'exécution de la fonction correspondante, vers le lecteur LCL
lors de l'utilisation de LD. eFO, ....,eFn seront respectivement chargées par les fonctions FFo,....,FF" créées par PGM.
Ces fonctions sont créées par rapport au type de systèmes d'exploitations et le type d'ordinateurs associés qui exécuteront LD. PGM rassemble ainsi {FFO,...,FFn} et {eFO,...,eFn} avec le reste du logiciel LD ainsi protégé, et numéroté S#. Le tout est ensuite mis sur média d'enregistrement, par exemple un CDROM. Le logiciel est ainsi protégé et prêt à être diffusé
librement, car il ne pourra pas être utilisé dans l'état actuel. Ainsi, la distribution du média d'enregistrement peut être effectuée de manière complètement libre.
Ainsi, la protection de logiciel selon la présente invention, est basée sur l'utilisation des ressources de calculs du lecteur LCL.

Selon la présente invention, le lecteur LCL est un lecteur électronique construit autour d'un microcontrôleur 100 sécurisé physiquement et logiquement afin de prévenir contre les tentatives de pirates pour des contrôles électroniques non autorisés. Compte tenu du fait que ce microcontrôleur 100 est amené à exécuter des programmes d'origine inconnue, la présente invention concerne un moyen d'empêcher des attaques informatiques du microcontrôleur 100 par l'intermédiaire de virus informatiques. Cette mesure est prise pour empêcher un virus de lire des informations confidentielles liées aux fonctionnements du lecteur LCL. Ainsi la présente invention permet de sécuriser à la fois le stockage d'information et à la fois l'exécution de tout programme extérieur aux programmes initialement chargés dans le microcontrôleur 100.
Selon la réalisation de la présente invention, l'architecture retenue du microcontrôleur est construite autour d'un système basé sur un jeu de deux processeurs utilisés en maître esclave. En référence à la figure 3, le microcontrôleur 100 intègre sur la même pastille de silicium deux parties principales 130 et 120. Les méthodes d'intégration ASIC (Application Specific Integrated Circuit) sont employées pour réaliser ces pastilles de silicium. La partie 130 comporte un processeur CPU1 qui est le processeur maître. Il est relié par un bus interne 101 à un module de mémoires FLASH
111, un module de mémoires DRAM 109, un générateur de nombre aléatoire 1I2, un port E/S
RS232 151, un port USB 152, un contrôleur de cartes à puces (SmartCard) 153, un contrôleur PCMCIA 154, un contrôleur clavier et écran LCD 155, un contrôleur 113 du processeur esclave CPU2 qui se trouve dans la partie 120, une interface 106, une interface Bus externe 105, une horloge temps réel programmable interne 104, un système de microfusible interne 102 qui permet de sortir le bus interne 101 à l'extérieur du microcontrôleur 100. La partie 120 du microcontrôleur 100 comporte un watchdog 108. Le CPU2 est relié par le bus interne 114 à un module de mémoires DRAM 110, un contrôleur DMA 107, et une interface 106. L'esclave CPU2 est commandé par l'intermédiaire du contrôleur 113 et de l'interface 106. Ces deux derniers systèmes électroniques (113 et 106) sont contrôlés uniquement par le processeur maître CPU1. Ainsi, une telle architecture permet l'exécution des programmes d'origine inconnue sans pour autant endommager l'intégrité
des informations contenues dans le microcontrôleur 100.
Selon des modes particuliers de réalisation, Ie microcontrôleur 100 peut ne pas intégrer sur la même pastille de silicium tout ou partie des éléments suivants : Port E/S
RS232 151, port USB 152, contrôleur de cartes à puces 153, contrôleur PCMCIA 154, contrôleur clavier et écran LCD 155.
Selon des modes particuliers de réalisation non illustrés, et afin d'accélérer la vitesse de traitement d' informations, le microcontrôleur 100 peut comporter sur la même pastille de silicium un coprocesseur de cryptage adapté par rapport à la technique de cryptage DES.
Bien entendu ce coprocesseur de cryptage sera intégré dans la partie 130 relié sur le bus interne 101.
Selon la présente invention, l'horloge temps réel interne 104 est alimentée par une pile électrique 103 externe par rapport au microcontrôleur 100. Son fonctionnement est autonome. Cette horloge est intégrée sur ladite pastille de silicium afin d'empêcher des tentatives de contrôles électroniques faussant l'heure et la date qu'il fournit au CPU1. Compte tenu de la faible consommation électrique de cette horloge, la pile électrique permet de fournir en continue le courant nécessaire au fonctionnement de cette horloge pendant toute la durée d'utilisation du microcontrôleur 100 comme organe central du lecteur LCL. Eventuellement, une procédure de mise à l'heure de l'horloge 104 pourra être effectuée par le serveur aSVR.
L'horloge 104 permet de mesurer le temps d'utilisation des logiciels protégés et d'effectuer des opérations dépendant de la date et de l'heure.
Le bus interne 101 est sorti vers l'extérieur du microcontrôleur 100, par l'intermédiaire du système de microfusibles 102. Selon une variante non illustrée, le système de microfusibles est évité en employant de la mémoire OTP EPROM interne. Cette variante permet les mêmes niveaux de sécurité que l'utilisation du système de microfusibles 102.
Le système de microfusibles 102 permet de réaliser un système de microcontrôleur programmable une seule fois. Les données nécessaires pour mettre en service les lecteurs LCL
(clés de codages secrètes, numéros de série, identifiants, dates, heures), et le système d'exploitation du microcontrôleur 100 regroupant des programmes permettant aux lecteurs LCL
de réaliser directement etlou indirectement toutes les fonctionnalités relatives à la présente invention, sont programmés en usine dans la zone mémoire de mémoire non volatile (mémoire Flash 111). Le système d'exploitation est exécuté dans la mémoire DRAM 109.
La réalisation de la présente invention utilise de la mémoire FLASH comme support de stockage permanente pour le microcontrôleur 100. Le choix d'une telle mémoire FLASH peut permettre une mise à jour très facile du système d'exploitation initialement programmé en usine.
Selon la réalisation de la présente invention, les heures et les dates sont données, sauf mention contraire, par rapport au méridien origine des fuseaux horaires GMT (Greenwich Mean Time).
Ainsi lors de la mise à l'heure durant la programmation du microcontrôleur 100 en usine, cette référence est prise pour l'horloge interne 104 du microcontrôleur 100 des lecteurs LCL.
Après programmation, le système de microfusibles est détruit ce qui empêche définitivement une nouvelle programmation du microcontrôleur 100, il n'y a plus alors d'accès directs à l'intérieur du microcontrôleur 100, car tous les contrôleurs et interfaces sont totalement sous le contrôle du processeur maître CPU1 (selon la construction du rnicrocontrôleur 100). Le système d'exploitation du microcontrôleur 100 ainsi programmé est automatiquement chargé par le processeur maître CPU1 à chaque démarrage d'un lecteur LCL.
Ainsi l'intégralité des informations gui sont stockées dans la mémoire interne du microcontrôleur 100 sont sécurisées contre toutes tentatives de contrôle électronique externe au microcontrôleur 100. Compte tenu des propriétés physiques d'une pastille de silicium, de sa taille et de son boîtier, il offre dans l'état actuel de l'art une très bonne protection physique et logique contre toutes tentatives d'intrusions non autorisées dans les circuits internes du microcontrôleur 100. Selon des modes particuliers de réalisation, des techniques de protection supplémentaires peuvent toutefois être ajoutées autour du microcontrôleur 100. Une des techniques possibles concerne l'utilisation d'un dispositif électrique externe de protection de circuits intégrés, présenté

dans le brevet de la société IBM en 1990 (U.S. Patent 5,117,457).
Le système électronique esclave 120 sert à exécuter des programmes venant de l'extérieur du microcontrôleur, c'est à dire n'appartenant pas au système d'exploitation qui a été chargé dans la mémoire FLASH 111 lors de la programmation du microcontrôleur 100. Il permet d'exécuter des programmes à l'abri des attaques de virus informatiques éventuels. La sécurité
est complète par rapport à ces attaques grâce à une protection physique caractérisée par une séparation logique d'une même pastille de silicium en deux parties 120 et 130 dont i'un 120 est esclave de l'autre 130.
Selon la réalisation de la présente invention, la zone mémoire DRAM 109 est strictement réservée à l'exécution du système d'exploitation du microcontrôleur 100 qui à
été chargé en usine, lors de la procédure de prograxnlnation du microcontrôleur 100. Il sert aussi de mémoire tampon pour transférer les programmes et/ou données venant de l'extérieur du microcontrôleur vers la mémoire DRAM 110 via l'interface 106 contrôlée uniquement par le processeur maître CPU1. Les programmes venant de l'extérieur sont exécuter à partir de la mémoire DRAM
110, par le processeur esclave CPU2 contrôlé par le processeur maître CPU1 via le contrôleur 113.
Selon la réalisation de la présente invention, par rapport l'utilisations des lecteurs LCL avec différents types d'ordinateur et de systèmes d'exploitations, et compte tenu de l'écriture des fonctions Fo précédemment décrites, le CPU2 est un processeur Java (PicoJava) de la société Sun Microsystems. Cette caractéristique rend le développement des fonctions {Fo, F1,...,F;, ...F"}
indépendant des ressources de calculs de l'ordinateur qui exécute un logiciel protégé selon la présente invention, et des ressources internes du LCL. De plus, le concepteur de logiciels protégés par la présente invention, peut tester le fonctionnement des fonctions {Fo, F,,...,F;, ...F"}
indépendamment du lecteur LCL avec un programme simulant une machine virtuelle JAVA.
Selon la réalisation de la présente invention, CPU1 est un processeur du type 80386SX. Il peut donc utiliser directement via son bus interne 101 une grande quantité de mémoires internes edou externes. Sa capacité de calculs permet d'envisager une forte capacité de traitements d'informations en multitâche.
Selon des modes particuliers de réalisation, le microcontrôleur peut ne pas utiliser de processeurs JAVA, mais un processeur du type 80386SX dont le système d'exploitation serait la machine virtuelle JAVA de la société Sun Microsystems que le CPUl chargerait à
chaque nouvelle exécution de programmes dans la DRAM 110 afin d'éviter d'éventuelles attaques de virus informatiques.
De plus, selon la réalisation de la présente invention, la totalité des informations éventuelles de la mémoire DRAM 110 est effacée par CPU1 avant chaque nouveau chargement de programmes qui doivent être exécutés par CPU2. CPU1 met en pause CPU2 par l'intermédiaire du contrôleur de CPU2 113, et efface, par exemple par une désactivation momentanée des circuits qui composent le module de mémoires DRAM 110, le contenu de cette mémoire DR.AM 110 grâce à
l'interface 106.
Ensuite, CPU1 charge les paramètres d'exécution et le nouveau programme à
exécuter dans la DRAM 110 directement grâce au contrôleur DMA 107. Ce chargement direct permet de ne pas utiliser CPU2 et de permettre au CPU1 de contrôler complètement la DRAM 110.
Ainsi, après chargement du programme, CPU1 donne alors la main à CPU2 par l'intermédiaire du contrôleur de CPU2 113. CPU2 exécute alors le nouveau programme. Ainsi compte tenu de toutes ces mesures, si ce programme est un virus informatique volontairement inscrit dans une des fonctions de type F;, il ne pourra toutefois porter aucunes atteintes au fonctionnement du microcontrôleur 100, ni recopier vers l'extérieur des données non effacées concernants les anciennes fonctions qui ont été
exécutées par CPU2 dans la mémoire DRAM 110. De plus, CPU1 conserve le contrôle des accès aux données contenues sa partie 130. Cette procédure de chargement de programme et/ou de données dans la DRAM 110, est répétée pour chaque programme qui doit être exécuté par le processeur esclave CPU2.
Selon la réalisation de la présente invention, l'architecture présentée par la figure 3, permet d'empêcher un programme n'appartenant pas au système d'exploitation du microcontrôleur 100 d'effectuer des lectures et/ou modification dans la mémoire interne du systëme 130 intégré dans le rr~icrocontrôleur 100. Il permet aussi d'empêcher ces programmes de contrôler les interfaces et/ou contrôleurs du microcontrôleur 100, et donc d'empêcher des pirates de lire le contenu des mémoires sécurisées physiquement et logiquement du système 130, intégrées dans le microcontrôleur 100.
De plus, selon la présente invention, l'interface bus externe 105 permet au microcontrôleur 100 de contrôler des périphériques externes reliés au bus externe 114. Ce bus permet d'ajouter au LCL des périphériques d'enregistrement comme par exemple un média d'enregistrement du type Flash Disk (mémoire FLASH utilisé un disque standard), un périphérique de communication réseau.
L'architecture du microcontrôleur 100 pern~et une grande modularité de fonctionnement.
Selon la réalisation de la présente invention, on connecte sur ce bus 114 un périphérique d'accès réseau Ethernet pour une communication en protocole TPC/IP. Selon le type de communication utilisé entre un lecteur LCL et un ordinateur donné, on pourra connecter sur ce bus un périphérique adéquat à cette communication. Ainsi, on peut ajouter un périphérique radio récepteur 22, pour utiliser un lecteur LCL dans le contexte 20 de la figure 1. L'usage de ce récepteur sera défini par la suite.
Selon la réalisation de la présente invention, compte tenu du contrôleur PCMCIA 154 intégré
dans le microcontrôleur 100, les périphériques utilisés peuvent être aussi des cartes PCMCIA
utilisée par le microcontrôleur 100 pour toutes opérations relatives à la présente invention. Ces cartes PCMCIA peuvent être des cartes Ethernet PCMCIA, des cartes FLASH
PCMCIA, un disque dur PCMCIA, une carte module de réceptions numériques hertziennes PCMCIA. Ces différentes cartes ne sont pas illustrées. L'usage du contrôleur PCMCIA permet d'ajouter à
un lecteur LCL
donné des périphériques plus facilement par rapport au bus externe 114. Le port USB 150 sert à
une connexion à grande vitesse de transmission et de réceptions entre un ordinateur, et un lecteur LCL donné. Il s'agit des contextes 30 et 20.

_ 17-Le port d'E/S 151 permet selon la réalisation de la présente invention, de communiquer avec une carte CL.
En référence à la figure 5, la carte électronique CL 60 ést construite autour d'un microcontrôleur 400 intégrant sur une même pastille de silicium un processeur CPU 405 relié par un bus interne 406 à un module de mémoires Flash 401, un module de mémoires OTP EPROM
407, un module de mémoires DRAM 404, un Port Série E/S RS232 403, un contrôleur de CompactFlash 402 de la société SanDisk.
Selon une variante non illustrée, le microcontrôleur intègre sur une même surface de pastille de silicium un coprocesseur de cryptage DES pour permettre au CPU d'effectuer des opérations de cryptage plus rapidement.
Selon la réalisation de la présente invention, les accès en lecture dans le module de mémoires OTPEPROM directement de l'extérieur du microcontrôleur 400 sont supprimés, afin de laisser tous les accès aux circuits internes du microcontrôleur 400 sous le contrôle unique du processeur CPU
405. La présente invention ne requiert pas l'utilisation d'une grande puissance de calcul au niveau du processeur CPU 405 intégré dans le microcontrôleur 400.
Ce microcontrôleur 400 comporte un moyen de sécuriser la lecture et/ou la modification illicite des informations qui sont contenues dans sa mémoire interne. Une méthode de sécurisation des accès en mémoires est proposée dans le brevet U.S. Pat. 5,293,424 daté du 8 mars 1994.
Selon la présente invention, la mémoire OTP EPROM interne 407 sert à stocker des clés de cryptage, des numéros de série d'identification, des dates, le système d'exploitation du microcontrôleur 400 réalisant directement et/ou indirectement des fonctions relatives à son utilisation selon la présente invention.
Selon la réalisation de la présente invention, la mémoire FLASH interne 401 sert à stocker de manière permanente des données supplémentaires après la sortie d'usine de la carte CL. Elle sert aussi à stocker des programmes supplémentaires qui permettent au microcontrôleur 400 de réaliser directement edou indirectement des fonctions supplémentaires relatives à son utilisation selon la présente invention après la sortie d'usine de la carte CL.
Selon la réalisation de la présente invention, et de manière générale, la carte CL est alimentée électriquement par LCL lorsqu'elle est connectée à LCL. Cette liaison électrique n'est pas illustrée.
Selon la présente invention, le microcontrôleur 400 est protégé contre toute modification des informations qu'il contient. II s'agit d'un microcontrôleur similaire à ceux des cartes à puces. Il est relié à un connecteur femelle 63 qui permet de communiquer par contact avec un lecteur LCL
donné.
Selon la présente invention, la carte CL est un appareil portatif de petite taille possédant une unité de stockage amovible de forte capacité.
Selon la réalisation de la présente invention, le microcontrôleur 400 est relié à la sortie de son contrôleur de CompactFlash à un support de connexion 64 pour modules de mémoires de type CompactFlash.

Selon des modes particuliers de réalisation, le contrôleur de CompactFlash peut ne pas être intégré sur la même pastille de silicium que le microcontrôleur 400. Il peut aussi utiliser un autre média d'enregistrement telle que des modules DiskOnChip de la société M-Systems ou tout autre système propriétaire et amovible de mémoires non volatiles.
Dans l'état actuel de l'art, des microcontrôleurs possédant les caractéristiques du microcontrôleur 400 sont très nombreux. Selon la réalisation de la présente invention, un microcontrôleur 32 bits RISC présentant les caractéristiques du microcontrôleur 400 à été intégré
sur une même pastille de silicium avec le contrôleur de carte CompactFlash.
Cette intégration utilise les technologies d'intégrations ASIC (Application Speciflc Integrated Circuit).
Ainsi, l'intégralité des informations qui sont stockées dans la mémoire interne du microcontrôleur 400 est sécurisée contre toutes tentatives de contrôles électroniques externes.
Selon la présente invention, la carte CL est un appareil portatif de petite taille. Il permet de transporter les informations concernant l'utilisation de logiciels protégés, indépendamment du lecteur électronique LCL. Elle est utilisée comme une clé d'accès à
l'utilisation de logiciels protégés selon la présente invention. Sa portabilité permet à un utilisateur d'utiliser les logiciels dont il a acheté les droits d'utilisation (licences) sur tout ordinateur qui posséderait ces logiciels.
Selon la réalisation de la présente invention, le format géométrique de CL est compris entre celui de la carte CompactFlash est celui d'une carte PCMCIA..
En référence à la figure 6, un trou 62 a été placé dans un coin du boîtier 60 représentant CL.
Ainsi, la carte CL peut être attachée à un porte-clés mécanique. Selon la réalisation de la présente invention, le numéro de série ID.c non illustré d'une carte CL donnée est imprimé sur le boîtier 60 de CL.
De plus, selon la présente invention, en référence à la figure 7, le module de mémoires CompactFlash 61 est détachable du boîtier 60 via le système de support de connexion 64 pour carte CompactFlash.
En référence à la figure 8 et selon la réalisation de la présente invention, la carte CL se connecte par contact avec un lecteur LCL via un jeu de deux connecteurs mâle femelle. Une carte CL possède un connecteur femelle 63 qu'il connecte sur le connecteur 210 mâle correspondant du lecteur LCL. Ces jeux de connecteurs permettent une communication série RS232 entre LCL et CL
par contact. De plus, il permet d'apporter de l'énergie électrique aux circuits électroniques de la carte CL. Selon la réalisation de la présente invention, le lecteur LCI. est alimenté sur secteur.
Selon des modes particuliers de réalisation non illustrés, CL peut avoir sa propre alimentation électrique pour permettre un fonctionnement autonome. Selon ces modes particuliers de réalisation, on peut intégrer dans CL un module de communication hertzienne ou infrarouge pour permettre des communications sans contacts avec LCL. Un exemple d'un tel dispositif est apporté par Hough dans U.S. Pat. No. 5,412,253. Bien sûre, le lecteur LCL possède dans ces conditions les ports de communications adéquats.
Selon la réalisation de la présente invention, toutes les clés de codages écrites en usine lors de la programmation des appareils de type LCL et CL sont des clés de 128 bits définics par rapport à
l'algorithme DES. Ainsi, compte tenu de la présente description de l'invention, un module de mémoires OTP EPROM de 256 kilooctets, un module de mémoires Flash de 64 kilooctets, un module de mémoire DRAM de 512 kilooctets ont été intégré avec le CPU 405 (processeur RISC), le Port Série E/S RS232 403 et le contrôleur de carte CompactFlash sur une même pastille de silicium. Bien entendu, d'autres tailles plus grandes de mémoires peuvent être utilisées en fonction des disponibilités des macros d'intégration ASIC et de leur coût. Ces quantités sont données par rapport à la présente réalisation.
Par ailleurs, selon la réalisation de la présente invention, la taille retenue pour le module de mémoire Flash 111, est de 1 mégaoctets. La taille retenue pour le module de mémoire DRAM 109, est de 2 mégaoctets. La taille retenue pour le module de mémoire DRAM 110 est de 1 mégaoctet.
Ces quantités sont données par rapport à la présente réalisation.
L'ensemble des programmes relatifs aux fonctionnalités du lecteur LCL
constitue le système d'exploitation interne du microcontrôleur 100. Ce système d'exploitation est enregistré dans la mémoire Flash 111 du microcontrôleur 100 lors de sa programmation en usine.
L'ensemble des programmes relatifs aux fonctionnalités de la carte CL
constitue le système d'exploitation interne du microcontrôleur 400. Ce système d'exploitation est enregistré dans la mémoire OTP EPROM 407 du microcontrôleur 400 lors de sa programmation en usine.
Selon la présente invention, les communications entre LCL et CL sont sécurisées. La présente invention concerne l'utilisation d'une méthode d'authentification permettant à
un groupe d'appareils quelconques de se reconnaître à l'aide de cette méthode. Cette authentification permet que seuls les appareils relatifs à la présente invention, certifiés par l'organisme qui gère le serveur aSVR, puissent fonctionner ensemble. Cette méthode selon la présente invention, permet d'empêcher que des appareils non reconnus par l'organisme qui gëre les appareils relatifs à la présente invention, ne puissent fonctionner avec ceux reconnus. Cette méthode empêche ainsi des appareils pirates d'effectuer des lectures de données dans les mémoires électroniques sécurisées des appareils relatifs à la présente invention.
La présente invention concerne des appareils qui ne peuvent être utilisés que pendant une durée déterminer dans le temps. Pour la réalisation, les appareils LCL et CL
sont tous caractérisés par une date DB de mise en service et une date DE qui indique que l'utilisation de ces appareils relatifs à la présente invention, expire fin DE. DB et DE constitue une information publique non modifiable.
Ainsi, selon la réalisation de la présente invention, la date DB du lecteur LCL, notée DB.d, est écrite lors de la programmation en usine du microcontrôleur 100, dans une zone libre de la mémoire Flash 111. De plus, la date DE d'un lecteur LCL, notée DE.d, est écrite lors de la programmation en usine du microcontrôleur 100, dans une zone libre de la mémoire Flash 111.
De plus, selon la réalisation de la présente invention, la date DB de CL, notée DB.c, est écrite lors de la programmation en usine du microcontrôleur 400, dans une zone libre de la mémoire Flash 401. De plus, la date DE d'une carte CL, notée DE.c, est écrite lors de la programmation en usine du microcontrôleur 400, dans une zone libre de la mémoire OTPEPROM 407.
Ainsi, selon la réalisation de la présente invention, l'organisme qui gère aSVR génère pour chaque semaine du calendrier international qui commence le lundi et qui se termine fin dimanche une clé kLi. La clé kLl est la première clé qui a été générée pour la première semaine où les premiers appareils relatifs à la présente invention, ont été mise en service.
La clé kLi indique la clé
de la semaine i par rapport à cette première semaine. Toutes ces clés sont entièrement créées et gardées secrètement par l'organisme qui gère le serveur aSVR afin de garantir la sécurité
d'utilisation des appareils relatifs à la présente invention.
Selon la réalisation de la présente invention, pour une carte CL considérée, lors de la procédure de programmation de son microcontrôleur 400, la clé secrète de codage kLj est écrite dans une zone libre de la mémoire OTPEPROM 407. Cette clé secrète kLj correspond à la semaine j par rapport à la première semaine où les premiers appareils relatifs à la présente invention, ont été
mise en service. La clé kLj a été choisie de telle sorte que la semaine j contient la date DB de la mise en service de cette carte CL. Cette clé secrète ne sera jamais révélée à
l'utilisateur. Par ailleurs, elle est connue uniquement par l'organisme qui gère le servçur aSVR.
De plus, selon la réalisation de la présente invention, pour un lecteur LCL
considéré, lors de la procédure de programmation de son microcontrôleur 100, la liste de clés secrètes de codage {kL;+],kL;+2~~-i+3~ ~ ~ ~ ~~+mi correspondant à toutes les clés associées aux semaines comprises entre la date DB.d diminuée de 1460 jours et la date DE.d, sont stockées dans la mémoire Flash 111 du microcontrôleur 100. Bien entendu, leurs adresses mémoires suivent une convention adoptée pour permettre de les retrouver dans la mémoire 111. Ces clés secrètes sont par ailleurs connues uniquement par l'organisme qui gère le serveur aSVR. Toutes ces clés secrètes qui viennent d'être citées, sont générées par rapport à l'algorithme de cryptage DES. Chacune de ces clés secrètes a une taille de 128 bits.
Selon la réalisation de la présente invention, la durée qui sépare une date de mise en service DB et une date de fin d'utilisation DE des appareils relatifs à la présente invention, est de 1461 jours (4 ans). Ainsi {kL;+;,ld.;+z~l~.a+3,...,kL;+",} n'occupe pas plus de 7 000 octets (approximation volontairement excessive) dans la mémoire Flash du microcontrôleur 100 d'un LCL donnée. La figure 4 permet de comprendre le choix du nombre de clés dans la liste {kL;+;,kL;+z,~.a+3,...,kL;+m}.
Ce nombre est du à l'existence des appareils les plus anciens, encore en service à la date DB.d de mise en service du LCL considéré. Compte tenu de la capacité des mémoires Flash intégrées au sein d'un microcontrôleur 100, la totalité des clés {kL;+t~~..i+2W-i+3~~~~~l~i+mi peut donc être stockée avec le système d'exploitation microcontrôleur 100.
Ainsi, la réalisation de ladite procédure d'authentification est basée sur l'utilisation judicieuse de toutes ces clés. Le nombre de clés employées permet à ce que si une clé
venait à être cassée, le fonctionnement lié à l'authentification par rapport à cette clé, ne mette pas en échec l'ensemble du système relatif à la présente invention.

WO 99!39256 PCT/FR99/00182 En référence à la figure 10, pour l'utilisation de LCL, dans un premier temps, un lecteur LCL
ne peut fonctionner que si la date courante indiquée par l'horloge temps réel interne 104 du microcontrôleur 100 de LCL est comprise entre les dates DB.d et DE.d du même LCL. Autrement la suite ne peut aboutir 551. Cette condition est illustrée sur la figure 10 par l'élément 501 $ Dans un deuxième temps, en référence à l'étape 502, pour mettre en fonctionnement un lecteur LCL, l'utilisateur doit effectuer une opération d'identification détaillée par la suite.
Dans un troisième temps, pour mettre en fonctionnement une carte CL, l'utilisateur doit connecter d'abord sa carte CL (étape 503) sur le support de type mâle de connexion 210 possédé
par le lecteur LCL, pour permettre une communication par contact entre le lecteur LCL et la carte CL. Le support de type mâle 210 du lecteur LCL est relié au port E/S RS232 151 du microcontrôleur 100. La carte CL possède donc un connecteur femelle 63 relié
au port E/S RS232 403 de son microcontrôleur 400. L'utilisateur doit effectuer ensuite une opération d'identification décrite par la suite.
Selon la réalisation de la présente invention, dans un quatrième temps 504, le microcontrôleur 400 de la carte CL envoie sous une forme non codée sa date de mise en service DB.c au microcontrôleur du LCL via ladite liaison RS232. Si un pirate modifier la valeur DB.c transmise, la suite de la présenie description ne pourra aboutir avec succès.
De l'autre côté et après réception de DB.c, dans un cinquième temps 505, le processeur CPU1 du microcontrôleur 100 de LCL effectue une correspondance entre DB.c et une clé secrète notée kLj.d éléments de la liste {kL;+t,~.i+2,~..i+3,~~~W-i+mi de telle sorte que la semaine j associée à
kLj.d selon la présente invention contienne DB.c.
Dans un sixième temps 506, le processeur CPU1 génère une clé kCS de 128 bits par rapport au cryptage DES, à l'aide de son générateur de nombres aléatoires 112. kCS est conservées secrètement dans la mémoire interne DRAM 109 du microcontrôleur 100.
Selon la présente invention, kCS est codée ensuite par kLj.d puis envoyée sous sa forme codée, notée ekCS, vers ie microcontrôleur de CL.
Dans un septième temps 507, à réception de ekCS, la carte CL tente de décoder ekCS avec sa clé secrète kLj. Selon la présente invention, si le décodage réussit, ladite procédure d'authentification a réussi. Le microcontrôleur de CL utilisera alors la clé
kCS pour envoyée des informations codées vers LCL, et pour décodée des informations venant par la suite de LCL. Le microcontrôleur 400 de la carte CL stocke dans sa mémoire interne sécurisée DRAM 404 cette clé
secrète kCS.
Ainsi, selon la réalisation de la présente invention, dans un huitième temps 508, le microcontrôleur de CL envoie ensuite la date d'expiration DE.c associée à CL
sous une forme codée par la clé kCS vers le microcontrôleur du lecteur LCL.
A réception, dans un neuvième temps 509, CPU1 vérifie si DE.c n'est pas dépassé par rapport à la date courante donnée par l'horloge interne du microcontrôleur 100 de LCL.
Si cette date est dépassée, LCL refusera de poursuivre la communication avec la carte CL 552.
Sinon, une communication sécurisée entre LCL et CL peut avoir lieu 559.
Ainsi, chaque session de communication entre LCL et CL qui commence par leur connexion par contact et qui se termine lorsque l'une des conditions suivantes est remplie : CL est déconnecté
de LCL, la date courante indiquée par l'horloge 104 a dépassé la date DE.c, la date courante indiquée par l'horloge 104 a dépassé la date DE.d. La déconnexion de la carte CL du lecteur LCL
est marquée par l'absence de charge à la sortie de l'alimentation électrique utilisée pour alimenter les circuits électroniques de la carte CL.
De plus, selon la présente invention, toutes les communications entre le lecteur LCL et la carte CL sont sécurisées par l'utilisation d'une méthode de cryptage symétrique utilisant une clé secrète, notée kCS.
Selon la réalisation de la présente invention, l'utilisateur qui désire faire fonctionner un appareil relatif à la présente invention, doit saisir sur le clavier de son lecteur LCL contrôlé par le microcontrôleur 100 par l'intermédiaire du contrôleur de claviers et écrans LCD 155, un code PIN.
Au moment de sa saisie, les chiffres tapés seront inscrits sur l'écran LCD non illustré et contrôlé
par le contrôleur 155. Ce code lui a été fourni lors de la première acquisition (l'achat) de l'appareil en question. Le code PIN est un code numérique de 5 chiffres associé à chaque appareil. II doit être conservé secrètement par le propriétaire de l'appareil correspondant.
L'utilisation d'un tel code est similaire à celui utilisé avec des méthodes d'identification présente dans le monde des cartes à
puces (SmartCard) dans l'état actuel de l'art. Les étapes qui permettent de vérifier la saisie correcte du code PIN associé à chaque appareil selon la présente invention, sont évidente et ne sont pas détaillée dans la présente description de l'invention. Il faut toutefois ajouter que le code PIN d'une carte CL est saisi sur le clavier du LCL, puis transmis sous sa forme non codée, vers le microcontrôleur 400 de la carte CL, via la liaison série RS232 présente entre une carte CL donnée et un lecteur LCL donnée. Il est donc sous-entendu, sauf mention contraire, dans un fonctionnent correct d'un appareil relatif à la présente invention, que la saisie du code PIN a été menée avec succès.
La présente invention concerne l'utilisation d'une carte CL comme média d'enregistrement portatif, sécurisé contenant des fichiers d'autorisation d'utilisation de tous les logiciels protégés selon la présente invention, et acquis légalement par l'utilisateur et séparément de l'acquisition du logiciel (le média d'enregistrement). Ces fichiers ont été enregistrés dans la carte CL en suivant une procédure d'acquisition de logiciels décrite par la suite.
Selon la réalisation de la présente invention, un fichier d'autorisations d'utilisation d'un logiciel donné ayant le numéro de série S#, noté Fich.S#, est défini comme un fichier binaire dont les bits de données sont ordonnés de la façon suivante : S# du logiciel (128 bits), B7.c (128 bits), nombre de licences (L#.S# : 16 bits), dernière utilisation (DR.S# : Jour 5 bits, mois 4 bits, année 12 bits, heure 5 bits, minutes 6 bits, secondes 6 bits), première utilisation (DP.S# : date et heure 38 büs), durée d'utilisation courant (DU.S# en minutes : 24 bits), nombre d'exécutions du logiciel (28 bits), données diverses (Misc :1024 bits), clé kEL.S (128 bits), clé kX.S#
(128 bits). Le total est de WO 99/39256 PC'T/FR99/00182 i 680 bits, soit un fichier de 210 octets.

Selon la réalisation de la présente invention, une carte de type CompactFlash 61 distribuée par la société SanDisk d'une capacité de stockage de 4 mégaoctets est insérée comme indiqué sur la figure 7 sur un support de connexion 64 adapté et présent sur la carte CL, pour permettre la connexion de cette carte CompactFlash vers le contrôleur de cartes CompactFlash 402 du microcontrôleur 400. Les cartes CompactFlash sont compatibles avec le standard ATA des cartes PCMCIA dans l'état actuel de l'art. Ces modules de mémoires CompactFlash sont utilisés comme des disques de stockage d'informations. Les instructions nécessaires concernant l'écriture du driver qui permet au microcontrôleur 400 d'utiliser le module CompactFlash de 4 mégaoctets sont donnée par le standard ATA. Ce driver non illustré, permet selon la réalisation de la présente invention, au microcontrôleur d'effectuer les opérations suivantes sur la carte CompactFlash : lectures de fichiers, modifications de fichiers, créations de fichiers.
Ainsi, selon la réalisation de la présente invention, la carte CL permet de stocker plus de 10000 fichiers d'autorisations d'utilisation de logiciels protégés selon la présente invention. Ce nombre est largement suffisant pour tous les logiciels protégés par la présente invention, qu'un utilisateur peut acquérir légalement. Toutefois, l'utilisateur pourra changer de cartes CompactFlash pour une plus grande capacité de stockage. Compte tenu de la norme ATA, ce changement ne nécessite ni de mise à jour des programmes système du microcontrôleur 400, ni de changement du boîtier 60 et du support pour carte CompactFlash 64.
Selon la présente invention, les informations stockées sur la carte CL, concernant les autorisations d'utilisation de logiciels protégés selon la présente invention, ne dépendent pas du média d'enregistrement mais de l'entité carte électronique CL. Ainsi, un utilisateur d'une carte CL
pourra utiliser plusieurs cartes CompactFlash pour stocker des fichiers de type Fich.S#. Les données qui sont stockées sur une première carte CompactFlash associée à une carte CL donnée peuvent être transférées vers une deuxième carte CompactFlash. Cette opération est effectuée à
l'aide du programme PGM précédemment cité.
Selon la présente invention, les fichiers d'autorisations Fich.S# sont stockés sous une forme codée, notées eFich.S#, avec une clé secrète kS.c de 128 bits par rapport à la technique de cryptage DES, dans la carte CompactFlash utilisée comme un disque de stockage. La clé
secrète kS.c a été
inscrite dans la mémoire OTPEPROM 407 lors de la programmation en usine du microcontrôleur 400.
Ainsi, eFich.S# ne pourra être utilisé que par la carte CL qui i'a créé, car la clé secrète kS.c est différente pour chaque carte CL mise en service.
De plus, la présente invention concerne une méthode qui permet de séparer l'acquisition du média d'enregistrement contenant un ou des logiciels) protégés) par la présente invention, du droit d'utilisation de ce ou ces logiciel(s).
Selon la réalisation de la présente invention, les médias d'enregistrement de logiciels protégés selon la présente invention, sont librement distribués. Cependant, un logiciel protégé selon la présente invention, ne peut être exécuté uniquement qu'après une opération d'acquisition légale d'un fichier Fich.S# d'autorisation d'utilisation de ce logiciel numéroté S#.
Ainsi, en référence à la figure 2, lorsqu'un utilisateur désire obtenir une ou des licences d'utilisation, il doit connecter tout d'abord son lecteur LCL avec le serveur aSVR, à l'aide du programme PGM. Selon la réalisation de la présente invention, cette connexion est établie via le réseau Internet.
Pour commencer à acquérir une autorisation (une ou des licence(s)) d'utilisations d'un logiciel numéroté S# et protégés selon la présente invention, l'utilisateur commence par connecter sa carte CL sur ledit lecteur LCL donné. L'utilisateur doit maintenir sa carte CL
connectée au moins jusqu'à la fin de la présente procédure d'achat en ligne (avec connexion). On suppose que l'utilisateur veut acquérir NL nombre(s) de licences d'utilisation de ce logiciel numéroté S#. Il saisit ensuite le code PIN de sa carte CL sur le clavier dudit lecteur LCL.
L'opération d'authentification précédemment citée doit aboutir avec succès pour continuer.
Ainsi, en référence à la figure 11, selon la réalisation de la présente invention, au début de la connexion avec aSVR, ledit lecteur LCL communique à aSVR son numéro ID.d (étape 601}. Dans ce contexte de communication, aSVR est le système distant représenté sur la figure 2. Bien sûre, les opérations commerciales qui sous-entend que aSVR accepte une communication avec ledit lecteur LCL sont sous-entendues. Le programme PGM envoie ensuite vers aSVR le numéro de série S#
dudit logiciel, saisie par l'utilisateur (acheteur), et le nombre NL. Ces deux informations sont envoyées sous une forme codée par la clé secrète kT.d du lecteur LCL de l'utilisateur.
De plus, la réalisation de la présente invention considère que le concepteur dudit logiciel au numéro de série S# dispose lui aussi d'un serveur noté dSVR, non illustré et relié par le réseau Internet à aSVR. Le serveur dSVR est connecté de son côté avec le lecteur LCL
dudit concepteur.
Bien entendu, cela suppose que le système d'exploitation d'un lecteur LCL soit programmé de telle sorte qu'il puisse répondre à certaine requête relative à la présente procédure d'achat du serveur dSVR. Ainsi (étape 602), dSVR communique ensuite à aSVR le numéro ID.d de son lecteur LCL
qui a servi à créer le logiciel S# protégé selon la présente invention. La communication entre dSVR
et le lecteur LCL se passe comme sur la figure 2 où l'ordinateur 50 est représenté ici par le serveur dSVR.
Pour permettre une communication sur deux niveaux, le lecteur LCL de l'utilisateur communique à aSVR (étape 603) sous une forme codée une clé publique, notée kP.
La clé kP est codée avec la clé secrète kT.d du LCL de l'utilisateur. kP est une clé
publique, relative à la technique de cryptage RSA (Rivest, Shamir et Adleman). La clé kP est créée avec sa clé privée kV
pour l'occasion (dynamiquement) et effacée à la fin de cette procédure d'acquisition de licences.
La forme codée par ladite clé kT.d de kP est notée ekP.kT. De plus, il faut noter que aSVR ne connaît pas la valeur de la clé privée kV associée à kP. Le codage systématique des informations lors de la communication évite d'éventuelles modifications des données échangées lors de leur transfert.
A réception, aSVR décode ekP.kT à l'aide des informations qu'il possède concenlant le lecteur LCL de l'utilisateur. Selon la réalisation de la présente invention, aSVR est seul en dehors de ce lecteur LCL, à connaître la correspondance du numéro )D.d avec la clé
kT.d par rapport à un lecteur LCL donné. La clé kP est ensuite codée avec la clé secrète kT.d relative au lecteur LCL du concepteur du logiciel S# protégé selon la présente invention. La nouvelle forme codée de kP est notée ekP.kT2. Ensuite, aSVR communique ekP.kT2 604 au lecteur LCL du concepteur via le serveur dSVR. De cette manière, l'utilisation des techniques de protection de logiciels selon la présente invention, crée une dépendance entre le concepteur de logiciels protégés selon la présente invention, et l'organisme qui gère aSVR. Ainsi, Le concepteur de logiciel n'a pas à constituer des stocks autre qu'un stock de médias d'enregistrement contenant le logiciel protégé selon la présente invention.
A réception, le lecteur LCL dudit concepteur décode ekP.kT2 avec sa clé kT.d.
Avec la clé
public kP, LCL relatif au concepteur code ensuite kEL.S# généré lors de la procédure de création du logiciel S# protégé selon la présente invention avec la clé kP. La forme codée de kEL.S# par kP
est notée ekEL. Selon des variantes non illustrées, après avoir décodé
ekP.kT2, ledit peut communiquer kP au serveur dSVR afin de lui laisser le codage de la clé kEL.S#
par la clé kP. Mais ces variantes ne changent en rien quant au principe fondamentale de la présente invention.
Selon ia réalisation de la présente invention, dSVR reçoit ensuite de aSVR la valeur de NL.
NL permet au concepteur de logiciels protégés selon la présente invention, d'effectuer une comptabilité avec l'organisme qui gère aSVR. Selon une variante de la présente procédure d'acquisition d'autorisation d'utilisations, dSVR envoie après réception de la clé kP, une clé public kPUB relatif au cryptage RSA vers le LCL de l'utilisateur (acheteur) via aSVR.
Cette variante permet au programme PGM connecté avec le lecteur LCL de l'utilisateur, de retourner à dSVR par l'intermédiaire de aSVR, la valeur codée avec kPUB de NL. Cette variante permet à ce que dSVR
ne se fie pas à la bonne sincérité de aSVR. Ainsi, cette variante permet à
dSVR de contrôler exactement le nombre de licences vendues.
Selon la réalisation de la présente invention, dSVR envoie ensuite (étape 605) ekEL à aSVR.
Ce serveur aSVR envoie ensuite (étape 606) kX.S# sous une forme codée avec la clé kT.d (celui du lecteur LCL de l'utilisateur) vers le lecteur LCL de l'utilisateur. La clé
kX.S# est une clé créée et stockée par aSVR lors de la procédure de protection précédemment décrite du logiciel LD
numéroté S#. Le serveur aSVR envoie ensuite vers le lecteur LCL de l'utilisateur, eKEL. A
réception, le lecteur LCL de l'utilisateur décode eKEL par kV. Il obtient donc kEL.S#. Ce lecteur LCL décode aussi la forme codée de kX.S# par sa clé kT.d.
Selon la réalisation de la présente invention, ledit lecteur LCL envoie ensuite à ladite carte CL, sous une forme codée avec la clé kCS obtenue lors de la procédure d'authentification précédemment décrite, les données suivantes : S#, NL qui correspond au nombre de licences demandées par l'utilisateur à aSVR, kX.S#, kEL.S#, la date et l'heure courantes indiquées par l'horloge 104.
Ainsi, le microcontrôleur 400 de la carte CL décode les différentes données reçues avec kCS.

Le microcontrôleur 400 procëde alors à la procédure (étape 607) de mise à jour qui suit. Le microcontrôleur 400 vérifie si un fichier codé eFich.S# d'autorisation d'utilisation existe déjà pour le logiciel en question numéroté S#. Dans ce cas, il procède à sa modification en augmentant la valeur du champ L#.S# dans le fichier Fich.S# correspondant, de la valeur de NL. Dans le cas où
l'utilisateur aurait acquis une autorisation dépendante du temps, bien entendu des mises à jour sur les champs correspondants sont effectuées dans le fichier Fich.S#. Pour la compréhension de la présente invention, certain point évident sont sous-entendu.
S'il n'existe pas de fichier Fich.S# correspondant, un nouveau fichier Fich.S#
est créé. Ainsi, selon la réalisation de la présente invention, le microcontrôleur 400 de la carte CL crée le fichier Fich.S# en remplissant les champs suivants du nouveau fichier : S#, L#.S#, ID.c numéro de série de la carte CL en question, kEL.S#, kX.S#. Les valeurs de DR.S# et de DP.S# sont initialisées par la valeur de l'heure et de la date courante. Les champs DU.S# et « nombre d'exécutions du logiciel »
prennent évidemment la valeur nulle. Le champ Misc sert à stocker des valeurs liées à des besoins éventuels de définir des champs d'informations supplémentaires. Misc est initialement à zéro.
L#.S# prend la valeur de NL.
Selon des modes particuliers de réalisation non décrites, un utilisateur peut directement se connecter sur le serveur dSVR pour acheter des licences lorsque aSVR a communiqué la valeur de kX.S# d'un logiciel numéroté S# protégé selon la présente invention. Cette variante permet de décentraliser la vente des licences.
Compte tenu du format des fichiers Fich.S# et de sa forme codée eFich.S#, seul une carte CL
donnée et numérotée ID.c peut utiliser les fichiers Fich.S# correspondant à
ID.c Selon la réalisation de la présente invention, on considère un logiciel, noté
LD, ayant subi une procédure de protection selon la présente invention. Bien entendu, les explications qui suivent sont valables pour tout iogiciel protégé selon ia présente invention. Pour permettre une explication, on considère son utilisation dans le cas où l'ordinateur hôte est connecté à un lecteur LCL via un réseau de type Ethernet, en TCP/IP. C'est le cas du contexte 40. Le driver DRV
précédemment citée permet de communiquer avec LCL par rapport au protocole TCP/IP. Selon la réalisation de la présente invention, la couche TCP/IP est sous-entendu dans les propositions de communication entre le programme driver DRV et le lecteur LCL considéré.
Selon des modes particuliers de réalisation non décrite, mais illustrée par la figure 4, plusieurs LCL peuvent être présents sur le réseau. Cependant, ces organisations ne change pas les caractéristiques de la présente invention.
Selon la réalisation de la présente invention, à l'obtention d'une ou plusieurs autorisations) d'utilisation du logiciel LD (licences d'utilisation), LD peut alors être exécuté.
Ainsi, au lancement du logiciel LD sur un ordinateur hôte, la fonction FFo est exécutée en premier. De manière générale, selon la réalisation de la présente invention, toutes les fonctions FF;
effectuent toutes une procédure commune : le chargement de eF; vers LCL.
__~ _ ~

Selon la réalisation de la présente invention, lorsque le logiciel LD appehe une fonction donnée FF;, il lui transmet par passage de paramètres en utilisant par exemple la pile du système de l'ordinateur hôte, des informations paramètres, notées PARAM, utilisées directement et/ou indirectement lors de l'exécution éventuelle de la fonction F; correspondant à
FF;. Ensuite, FF;
charge en mémoire le contenu du fichier eF; décrit précédemment. Puis, FF;
appelle (au sens d'un appel de programmes informatiques) le driver DRV afin de lui communiquer les informations PARAM et l'adresse mémoire où se trouve eF;. Ces informations sont ensuite envoyées vers LCL à
travers le réseau considéré. Des paramètres supplémentaires peuvent être rajoutés par une fonction FF; dans les paramètres PARAM. Ainsi, PARAM contient notamment des informations relatives à
l'heure courante dans l'ordinateur qui exécute ladite fonction FF;. II
contient aussi un identifiant unique représentant cet ordinateur hôte (par exemple l'adresse IP de cet ordinateur sur le réseau qui est fournie par Ie système d'exploitation de cet ordinateur) et le numéro de série S# du logiciel correspondant à ladite fonction FF;. Bien entendu, dans le cas d'un lecteur directement connecté sur un ordinateur (c'est le contexte 30 et 20), il n'y a pas de problèmes d'identifiants uniques. Ainsi, on note l'identifiant unique de l'ordinateur IDIP. Cette variable est utilisé par le microcontrôleur 100 du lecteur LCL pour gérer l'utilisation des logiciels en fonctions des postes d'ordinateurs. Bien entendu, le choix d'une adresse IP pour les valeurs possibles de la variable IDIP ne concerne que la présente réalisation. Dans d'autres modes de réalisation, IDIP pourra être définie autrement.
Ainsi, selon la réalisation de la présente invention, lorsque le microcontrôleur 100 du lecteur LCL aura terminé le traitement des informations reçues et en particulier l'exécution de la fonction F; correspondante, les résultats obtenus sont alors transportés à nouveau vers ledit ordinateur hôte à
travers le réseau considéré. A réception, DRV retourne les résultats à FF; qui les retourne au logiciel LD. Si la carte CL qui est connecté sur le lecteur LCL ne possède pas de licences d'utilisation pour le logiciel LD, alors LCL ne retournera pas de résultats mais un message indiquant à FF; de fermer l'exécution du logiciel LD. Une fermeture d'exécution peut être donnée à
FF; dans d'autre situation décrite par la suite. Ainsi, l'exécution des fonctions F; par le lecteur LCL
crée une dépendance physique du logiciel LD avec LCL.
Ainsi, selon la réalisation de la présente invention, au début du lancement du logiciel LD, la fonction FFo associé à LD est exécutée. Durant l'exécution de FFo associé
audit logiciel LD aucune autre fonction de type FF; associée à LD ne doit être exécutée. Des informations supplémentaires seront données par la suite. FFo envoie eFo, l'heure courant indiquée par l'ordinateur qui exécute FFo, les paramètres d'exécution PAR.AM de la fonction Fo, la valeur S#
associée au logiciel LD.
A l'arnvée des résultats calculés par le microcontrôleur 100 de LCL, FFo considère deux types de résultats. Le premier type concerne les résultats liés à l'exécution de Fo (Fo doit être une fonction compliquée de telle sorte que le logiciel LD en dépend énormément) dans le microcontrôleur 100.
Dans la mesure où ces résultats ne sont des messages d'erreurs, ces résultats sont retournés au logiciel LD pour continuer l'exécution de LD. Le deuxième type concerne une heure Htop par _28_ rapport à l'horloge dudit ordinateur exécutant le logiciel LD. Cette indication de temps correspond au prochain moment où FFo devra être impérativement Lancé par le logiciel LD.
De plus, l'ordre dans laquelle les autres fonctions FF; sont appelées, n'est pas prévisible, car il dépend de l'utilisation de LD.
Selon la réalisation de Ia présente invention, l'exécution de FFa est volontairement Longue, de l'ordre de 1 seconde.
De plus, à l'heure Htop, si FFo n'est pas exécutée, alors LCL considére que La session d'exécution associée audit logiciel LD qui doit lancer FFo est fermée. Cette condition permet à
LCL de diminuer son compteur de licences utilisées sur le réseau par rapport à
LD.
Bien sfire, le dépassement du nombre de licences ne concerne pas les logiciels qui sont utilisé
avec un ordinateur isolé et connecté directement par un port E/S à un LCL
adapté à ce port.
De plus, lors de l'exécution des autres fonctions FF; pour i différent de 0 par le logiciel LD, FF; vérifie d'abord si la fonction FFo associée à LD n'est pas en cours d'exécution. En L'absence d'une exécution en cours de FFo, FF; pour i différent de 0, envoie eF;, S#, les paramètres d'exécution de F; vers LCL via DRV. Lorsque le lecteur LCL a terminé le traitement de eF;
accompagné de ses paramètres, les résultats sont retournés à FF;. FF; retourne alors ces résultats au logiciel LD. Si un message d'erreur est reçu, l'exécution du logiciel LD
s'arrête. Contrairement à
des systèmes de protection de logiciels qui utilisent des vérifications de codes, les logiciels protégés selon la présente invention, possèdent une protection incontournable par rapports à la difficulté de pouvoir trouver une fonction équivalente aux fonctions de F;
utilisées.
Selon la réalisation de La présente invention, compte tenu du processeur CPUl, le système d'exploitation du microcontrôleur 100 est un système multitâche afin de pouvoir traiter plusieurs utilisation de logiciels protégés selon la présente invention en même temps.
La réalisation de ce système d'exploitation se réfère à des standards de systèmes multitâches existant concernant les processeurs 80386 de la société Intel. De plus, la sécurité du système de protection de logiciels selon La présente invention, repose en particulier sur l'exécution d'un seul programme principal à la fois par le processeur CPU2.
Selon la réalisation de la présente invention, à la réception complète d'un paquet d'informations, CPU1 les charge dans la mémoire DRAM 109. Dans le cas de données (correspondantes à un logiciel donné numéroté S#) du type eF; et des paramètres associés à eF;, la liste de test suivant est réalisée : i est égale à 0 701, eF; correspond à un logiciel numéroté S# qui a déjà exécuté une fois FFo avec succès 702, l'heure indiquée par l'horloge 104 est égale à l'heure Htop (valeur précédemment définie correspondant au logiciel numéroté S# qui a dans cette condition déjà exécuté une fois FFo avec succès) exprimée par rapport à
l'heure de l'horloge 104 avec une erreur de plus ou moins deux secondes (test 703 ou 705), le nombre (noté NL.S#) courant de licences utilisées (correspondant au logiciel numéroté S#) augmenté de 1 est strictement supérieur à la valeur L#.S# du fichier Fich.S# (correspondant au logiciel numéroté S#) fourni par la carte CL (test 704). Les éléments de cette liste de tests sont notés respectivement testl, test2, testa, _._ _.__ _. T_.

WO 99I39Z56 !'CT/FR99/00182 test4. Le chiffre associé à ces tests indique l'ordre de ces tests dans les conditions de leurs réalisations. En référence à la figure 12, le test testl 701 correspond au début de l'arbre d'analyse qui est effectué donc en considérant un logiciel donné numéroté S#, et un identifiant unique IDIP
qui est le numéro adresse IP de chaque ordinateur sur le réseau considéré. Ce numéro permet ainsi d'associer chaque session d'exécution de logiciels par rapport à un ordinateur donné dudit réseau.
Selon des variantes de cette réalisation, d'autre identifiant unique peuvent être associé directement à une session d'exécution d'un logiciel donné par l'emploi d'un identifiant de processus combiné
avec l'adresse réseau de l'ordinateur où se trouve ce processus. Ainsi, la présente réalisation considère l'identifiant unique associé à une adresse IP comme un exemple de moyen possible pour identifier un ordinateur sur ledit réseau. Ainsi, au début de l'arbre d'analyse de la figure 12, les informations S# et IP (IDIP) sont supposées fournies par la fonction FF; avec le driver DRV. Ces deux informations sont envoyées vers ledit lecteur LCL dans le paquet d'informations PARAM
précédemment décrit.
Selon la réalisation de la présente invention, par rapport au test test4 704, si le résultat est une valeur fausse au sens booléen, alors la nouvelle valeur de NL.S# 709 est celle de l'ancienne augmentée de 1, à condition que le test test2 702 soit faux et que le testl 701 soit vrai.
Par rapport à une valeur vraie du test testa 703, et à condition d'une valeur vraie des tests testl 701 et test2 702, CPU1 effectue un lecteur de l'heure courante sur l'horloge interne 104, pour calculer la nouvelle valeur de Htop exprimée par rapport à l'heure de l'horloge associée à
l'ordinateur exécutant le logiciel S# dans les conditions de ces tests et le contexte de ces conditions.
La nouvelle valeur de Htop est à égale l'ancienne augmentée de 5 minutes (par exemple), selon la réalisation de la présente invention. Cette valeur de 5 minutes est ajustée de telle sorte que deux ou plusieurs logiciels ayant le même numéro S# et tournant sur des ordinateurs différents, ne puissent pas exécuter la fonction FFo correspondante en même temps (il faut tenir compte de ladite erreur de plus ou moins deux secondes). Cette valeur de S minutes peut donc être remplacée, par tout autre valeur en fonction de la phrase précédente. A la fin du test testa, une exécution 706 de la fonction Fo a lieu.
Par rapport à une valeur fausse du test testa 703, et à condition d'une valeur vraie des tests testl 701 et test2 702, un message d'erreur 70? est alors retourné à la session d'exécution du logiciel correspondant à l'exécution de la fonction FFo dans les conditions de ces tests et le contexte de ces conditions. De plus, CPU1 diminue de 1 point le compteur NL.S#
associé aux logiciels au numéro de série S#. Le système d'exploitation du microcontrôleur 100 dans le cadre de la protection de plusieurs logiciels en même temps, gère une liste d'objets référencés par les différents identifiants IDIP correspondant à tous les ordinateurs du réseau qui exécutent un logiciel protégé selon la présente invention. Cette liste d'objets est établie à partir des informations de PARAM. Les champs de chacun de ces objets servent à enregistrer les numéros de série S# des logiciels numérotés S# qui sont exécutés sur l'ordinateur dont l'identifiant IDIP correspond à ladite référence IDIP de ces objets. Cette liste d'objet permet la gestion de l'utilisation des logiciels . T __.

protégés en fonction des ordinateurs. Lorsque NL.S# est diminué de 1 point par rapport un ordinateur identifié par IDIP et qui exécute le logiciel numéroté S# qui a provoqué cette diminution, le champ de l'objet IDIP correspondant qui contient la valeur de S# est effacé. Cette gestion permet à ce que une nouvelle exécution d'un logiciel numéroté S#
puisse avoir lieu. Il faut aussi noter que la valeur de NL.S# est le total desdits objets possédant un champ identique à la valeur de S# dans la notation de NL.S#. Ainsi, en contrepartie lorsqu'une augmentation de 1 point de la valeur de NL.S# a lieu, un nouveau champ dans i'objet IDIP de ladite liste d'objets est créé.
L'objet IDIP correspond à l'ordinateur numéroté mIP qui exécute la fonction FF; du logiciel S#.
Ledit nouveau champ prend alors la valeur de S#.
Par rapport à une valeur vraie du test test4 704 et d'une valeur fausse du test test2 702 et d'une valeur vraie du test testl 701, un message d'erreur 708 est alors retourné à
la session d'exécution du logiciel correspondant à l'exécution de la fonction FFo dans les conditions de ces tests et le contexte de ces conditions.
Par rapport à une valeur vraie du test testa 705, et à condition d'une valeur fausse du test testl 701, CPU1 diminue de 1 point le compteur NL.S# associé aux logiciels numérotés S#. Ladite liste d'objets IDIP est actualisée en conséquence. Un message d'erreur 710 est alors retourné à la session d'exécution du logiciel correspondant à l'exécution de la fonction FFo dans les conditions de ces tests et le contexte de ces conditions.
En référence à la figure 12, pour une valeur vraie du produit (testl 701 et test2 702 et testa 703) dans l'ordre de leur réalisation, pour une valeur fausse du produit (testl 701 et test2 702 et test4 704) dans l'ordre de leur réalisation, et pour une valeur fausse du produit (testl 701 et testa 705) dans l'ordre de leur réalisation, le résultat conduit à un traitement de eF; par CPU1.
Bien entendu, l'ensemble de ces tests est défini par rapport à la réalisation de la présente invention pour permettre les fonctionnalités de protection de plusieurs logiciels en même temps par un seul lecteur LCL. L'arbre d'analyse de la figure 12 est simplifié au maximum par soucis de clarté de compréhension. Selon des modes particuliers de réalisation, les conditions des tests et le contexte de ces tests peuvent varier.
En cas d'utilisation intensive, une file d'attente est créée pour faire exécuter une à une les fonctions F; par le processeur CPU2. Afin de diminuer le temps d'attente, une condition de durée autorisée pour l'exécution d'une fonction F; donnée peut être fixée, par exemple 1/100 de secondes valeur définie par rapport à la vitesse de calcul du processeur CPU2. Cette condition de durée devra être respectée par le développeur de logiciels protégés selon la présente invention.
Selon la réalisation de la présente invention, les informations d'utilisation d'un logiciel donné
numéroté S# sont fournies par la carte CL. Ainsi, lorsqu'il est nécessaire par rapport à l'arbre d'analyse, notamment à l'étape 704, le microcontrôleur 100 effectue une requête auprès de la carte CL. Ainsi, CPU1 effectue dans l'objectif d'exécuter F;, une requête à propos du logiciel numéroté
S#, auprès de la carte CL connecté dans le contexte de cette requête. Dans les conditions de succès de la procédure d'authentification précédemment définie entre LCL et CL, et dans les conditions de la possessions du fichiers Fich.S# associé au logiciel numéroté S# du contexte de cette requête, le microcontrôleur 400 de la carte CL retourne au LCL sous une forme codée par la clé kCS, le fichier Fich.S#. Le microcontrôleur 100 met alors à jour les champs suivants : DR.S#
(dernière utilisation) remplacée par la date courante, DU.S# recalculé, Nombre d'exécution du logiciel. DR.S# est mise à jour par rapport à la date et l'heure de la première exécution de la fonction FFo par rapport au dernier lancement d'une exécution du logiciel S# associé à cette fonction.
DU.S# est recalculée avec la valeur dynamique de Htop et l'heure courante indiquée par l'horloge 104 au moment où
l'exécution d'une fonction FF; correspondante a lieu. Le champ « Nombre d'exécution du logiciel »
est calculé par rapport à la dernière exécution du logiciel associé au contexte de ce calcul. Il est donc augmenté d'un point à chaque nouvelle exécution. L'ensemble de ces tests est optimisé en fonction du flux des requêtes des différentes fonctions FF; exécutées par les logiciels correspondants sur les différents ordinateurs connectés sur le réseau avec le lecteur LCL considéré
dans le contexte de ces mises à jour d'informations.
Selon la réalisation de la présente invention, les valeurs de L#.S#, kEL.S# et kX.S# (d'autres champs du fichier concernés peuvent être retenus par CPU1 selon les besoins) sont mémorisées dans la DRAM 109. Fich.S# modifié est ensuite retourné à CL sous une forme codée par kCS. Afin d'empêcher des actes de piraterie, si la carte CL est enlevée pendant que le lecteur LCL utilise la carte CL pour effectuer des opérations concernant la présente invention, le lecteur LCL met fin à
toutes les sessions d'exécution de logiciels protégés selon la présente invention, en leur retournant un message d'erreur. Selon des modes particuliers de réalisation, les appareils selon la présente invention, peuvent ne pas retourner ainsi un message d'en:eurs, dans la mesure où des fichiers Fich.S# peuvent être stockés en permanence dans le lecteur LCL de la même manière que celle employée avec la carte CL.
Ainsi, selon la réalisation de la présente invention, la valeur L#.S# empêche de dépasser le nombre de licences d'utilisations d'un logiciel protégé selon la présente invention.
Selon la réalisation de la présente invention, pour le cas i=0, la clé kEL.S#
fournie par le fichier Fich.S# est utilisée pour décoder eFo. CPU1 obtient ainsi ledit fichier de conditions d'utilisation du logiciel associé à ce eFo. CPU1 compare la valeur de ces différentes informations par rapport au fichier Fich.S# associé. A titre explicatif, si l'utilisation est fixée par rapport à une date d'expiration, ledit fichier de conditions d'utilisation renseigne cette valeur limite par son champ correspondant. Selon des modes particuliers de réalisation, ledit fichier de conditions d'utilisation peut ne pas comporter tout ou partie des champs suivants :
licences permanentes, durée d'utilisation, l'utilisation expire fin, nombres d'exécutions.
Selon la réalisation de la présente invention, après le succès de la comparaison des données fournies par le fichier Fich.S# avec le fichier de conditions (limites) d'utilisation décodée par la clé
kEL.S# et associée à eFo, et toujours pour i=0, CPU1 récupère aussi avec la clé kEL.S# les « byte code » JAVA (code d'instruction JAVA) de la fonction Fo.
_ _- _ _._ T__ Selon la réalisation de la présente invention, pour i différent de 0, les données codées eF; sont décodées à l'aide de la clé IcX.S# renseignée par le Fich.S# correspondant.
CPU1 récupère alors les « byte code » JAVA (code d'instruction correspondant à la machine virtuelle JAVA) de la fonction F;.
S Ces codes d'instruction sont chargés alors par l'intermédiaire de l'interface 106 directement dans la DRAM 110 grâce au contrôleur DMA 107. Par l'intermédiaire du contrôleur du CPU2, CPUl donne la main au CPU2 (processeur PicoJava) pour l'exécution de F; dont les paramètres d'exécution ont été chargés au préalable. Le watchdog 108 surveille au bon fonctionnement du CPU2. A la fin de l'exécution de F; par CPU2, les résultats sont récupérés par CPU1 et retournés vers l'ordinateur qui a envoyé les données eF;.
Dans les contextes d'utilisation 30 et 20, un lecteur LCL peut être utilisé
avec un ordinateur personnel grâce à une connexion directe entre leur port E/S USB respectif.
Pour ces deux contextes la protection de logiciels par le lecteur LCL est une version simplifiée des fonctionnalités en réseau. Par conséquent, la présente description n'apportera pas de renseignements supplémentaires.
Selon des modes particuliers de réalisation, le champ « durée d'utilisation »
du fichier de conditions d'utilisation peut être utilisé pour caractériser l'utilisation de logiciels de démonstrations. Ainsi, le fichier de conditions d'utilisations fixe en particulier des conditions d'utilisation limite. Le fichier d'autorisation d'utilisations renseigne la «
quantité » d'utilisation en cours. Les deux fichiers combinés permettent selon la réalisation de la présente invention, de protéger un logiciel contre le non respect de ses conditions d'utilisations.
De plus, le format du fichier de conditions d'utilisation est surtout intéressant pour développer des applications de démonstrations dont l'utilisation est limitée. Dans ce contexte, une procédure de protection particulière peut être utilisée pour que la création de logiciels protégés selon la présente invention, puisse être effectué sans passer par l'intermédiaire du serveur aSVR, Cette fonctionnalité est intéressante pour permettre notamment de décentraliser la protection de logiciels selon la présente invention. De plus, pour lancer une telle procédure de protection, le choix sera effectué à l'aide du programme PGM.
Par rapport à la procédure de protection de logiciels précédemment décrite, les fonctions F;
sont maintenant codées avec une clé secrète kLi de ladite liste {lcL;+1~~+2~1~-i+3~~~~~~+m}~ qui correspond à la semaine courante pendant laquelle cette procédure spéciale de protection de logiciels est lancée. L'usage de ces clés est intéressant uniquement pour les logiciels dont l'utilisation est limitée dans le temps à cause de la définition de ces clés kLi. Bien sfire, le lecteur LCL qui effectuera cette procédure ne communiquera pas la valeur de kLi par rapport à sa définition. Pour être distribué, le logiciel ainsi protégé devra être accompagné des indications sur la semaine pendant laquelle cette procédure particulière de protection a été
effectuée. Ainsi, lorsqu'un utilisateur désire exécuter un logiciel protégé de cette manière (par la clé
kLi), il n'aura pas besoins de contacter le serveur aSVR, car toutes les informations s'y trouvent sur le média d'enregistrement. Cependant l'utilisation du logiciel reste dépendante d'un lecteur LCL compte tenu du cryptage. Ainsi, l'utilisateur pourra disposer immédiatement du logiciel, mais ne pourra pas dépasser les conditions d'utilisations fixées dans le fichier de conditions d'utilisation. La réalisation de la présente invention empêche une réutilisation d'un logiciel dont l'utilisation est limitée dans le temps. Des explications seront données par la suite.
$ De plus, la présente invention concerne une méthode rendant l'utilisation des appareils selon la présente invention, transparente du point de vue informatique par l'intermédiaire d'un programme noté PGM qui a déjà été abordé. Le programme PGM est développé de telie sorte qu'il puisse permettre à un utilisateur des appareils selon la présente d'effectuer des opérations nécessitant une interactivité avec ces appareils. Son utilisation est généralement sous-entendue dans la présente description. Il a aussi pour rôle de permettre à un LCL donné de se connecter à un système informatique distant en utilisant les ressources de communication de l'ordinateur hôte et du système informatique de cet ordinateur.
Le programme PGM est utilisé en parallèle avec un programme driver DRV. Ce driver DRV
constitue une couche de communication entre PGM et un lecteur LCL donné. Il assure la transparence de l'utilisation du lecteur LCL. L'adjonction de ces deux éléments dans un ordinateur donné est illustré sur la figure 2. Ces deux programmes remplissent toutes les fonctionnalités décrites précédemment et par la suite. Une convention est adoptée sur les procédures d'interrogation d'un LCL donné afin de permettre à ce lecteur LCL de reconnaître et d'exécuter des commandes qui sont intégrés au système d'exploitation de son microcontrôleur 100. Ces commandes sont définies lors de la construction des lecteurs LCL.
En retour, selon la présente invention, PGM peut aussi interpréter les informations provenant des commandes envoyées par LCL. Ces commandes sont essentiellement, selon la réalisation de la présente invention, des instructions pour permettre à un LCL d'accéder à un système distant.
Ainsi, selon la convention adoptée pour communiquer avec un lecteur LCL donné, des commandes sont définies par rapport à la possibilité pour les lecteurs LCL, de se connecter à aSVR
par l'intermédiaire des ressources disponibles de communication réseau pour permettre par exemple une mise à jour du système informatique interne des appareils selon la présente invention ou encore la mise à l'heure de l'horloge interne 104 en cas de dysfonctionnement (la püe 103 est épuisée).
Selon le contexte d'utilisation 20 indiqué sur la figure 1, un récepteur hertzien numérique 22 est connecté sur le bus externe 114 du microcontrôleur 100, pour permettre à
un lecteur LCL donné
de recevoir des informations directement de l'organisme qui gère le serveur aSVR. Bien entendu, ce récepteur sera intégré dans le boîtier retenu pour l'utilisation du lecteur LCL. II est ainsi possible d'envoyer des informations à tous les lecteurs LCL en service de manière générale et/ou spécifique.
De plus, la faible consommation de ce type de récepteur par rapport à un fonctionnement avec des piles électriques, permet de les laisser en fonctionnement permanent, même si le lecteur LCL est éteint. Selon une variante d'utilisation d'alimentation électrique, des piles rechargeables peuvent être employées avec le radiorécepteur 22 indépendamment de l'alimentation électrique du LCL
_ __ __...____.~ ._ (fournit éventueliement par le réseau électrique local). Bien entendu, le récepteu: dispose de sa propre mémoire pour permettre de conserver les données reçues de l'émetteur 13 lorsque le lecteur LCL est éteint. Ainsi, le serveur aSVR peut envoyer des informations comme par exemple la mise à jour du système d'exploitation du lecteur LCL et/ou de la carte CL par l'intermédiaire d'un émetteur 13.
Selon une variante du fonctionnement des lecteurs LCL, une condition de durée peut être ajouter en plus des informations concernant les dates de mise en service et de fin d'utilisation (DB.d et DE.D). Cette condition est relative à l'utilisation de LCL avec le radiorécepteur 22. Ainsi, un lecteur LCL qui n'aurait reçu aucunes informations provenant de l'émetteur 20, refusera de fonctionner au moment de sa mise en marche par un utilisateur. Une procédure de connexion sur aSVR par l'intermédiaire du programme PGM devra être effectuée afin de récupérer les informations que ce lecteur LCL aurait pu manquer pour cause de mauvaise réception radio. Cette récupération se fait bien sûre par l'intermédiaire de la clé kT.d pour sécuriser la communication entre aSVF~ et le lecteur LCL en question.
De plus, afin d'envoyer de l'émetteur 13 des informations de manière sécurisée, les clés secrètes kLi précédemment décrites sont utilisées pour coder ces informations à envoyer par radio aux lecteurs LCL. On note ces informations MR. De plus, kLi est choisie de telle sorte qu'elle correspond avec la semaine où les informations partent de l'émetteur 13. On note eMR la forme codée de MR par kLi. En choisissant d'émettre les informations MR à partir du lundi qui suit la semaine (commençant un lundi et se terminant fin dimanche) où ces informations MR ont été
définies, les mêmes informations sont envoyées en répétition suivant un intervalle donné durant toute la semaine. Ceci permet de s'assurer qu'elles ont bien été reçues, et d'éviter trop de connexion de LCL vers aSVR.
Cette variante de la présente invention présente beaucoup d'avantage, car elle permet dans un premier temps de retourner les fichiers Fich.S# de manière sécurisée vers le lecteur LCL
correspondant à l'acheteur du logiciel associé à Fich.S#. Bien entendu, l'émetteur 13 peut envoyer de manière spécifique des informations vers un récepteur radio 22 donné. Cette variante permet un achat sans connexion informatique, mais par l'utilisateur directement au téléphone avec un accueil humain. Cette variante permet une complète séparation de la distribution du média d'enregistrement contenant un logiciel donné, de la vente des licences d'utilisation de ce logiciel donné.
Dans un deuxième temps, cette variante permet d'envoyer des informations concernant la perte d'un appareil. Compte tenu des capacités de stockage des modules de «
Disque Flash », un circuit DiskOnChip non illustré de la société Msystems est connecté avec un contrôleur éventuel sur le bus externe 114 du microcontrôleur 100 pour permettre au microcontrôleur 100 de disposer d'un disque de stockage. Un DiskOnChip de 12 mégaoctets est choisit selon la réalisation de la présente variante de l'invention. Selon d'autres variantes, une carte Disque Flash PCMCIA peut être employée à la place du DiskOnChip. Ainsi, à réception des informations eMR, le microcontrôleur 100 décode eMR à l'aide de la clé kLi de la semaine courante.
Ainsi, pour désactiver un appareil CL et/ou LCL donnés par rapport à leur utilisation, une information correspondant à son numéro de série peut être jointe. Ce numéro de série est alors sauvegardé sur le circuit DiskOnChip dans un fichier noté ANNUL qui sert à
stocker tous les numéros de séries des appareils selon la présente invention, qui ne doivent plus être utilisés. Selon des modes particuliers de réalisation, par rapport à la sécurité nécessaire contre des modifications, ledit numéro peut ne pas être codé lors de son émission de l'émetteur 13.
Selon la présente invention, un procédé informatique d'authentification et de signature par LCL est effectué sur le fichier ANNUL. La signature électronique et les informations de l'authentification sont stockées dans la mémoire interne 111 du microcontrôleur 100. Ainsi, le microcontrôleur 100 à chaque démarrage vérifie si le fichier ANNUL n'a pas été
remplacé par un autre fichier au même format ou modifié par une opération non autorisée.
Ce fichier ANNUL est alors utilisé lors de la procédure d'authentification entre une carte CL
donnée et un lecteur LCL donnée par rapport à la procédure précédemment décrite. Si CL présente un )D.c qui est référencé dans le fichier ANNUL, LCL rejette aiors la carte CL
en question. De plus, au démarrage de LCL et/ou à réception d'une information MR, le microcontrôleur 100 du LCL, vérifie si son propre ID.d n'est pas référencé dans le contenu de MR
et/ou ANNUL. Si le cas se présente, le microcontrôleur 100 se met hors service en détruisant le contenu de sa mémoire interne.
Ainsi, compte tenu de la réalisation de la présente variante, un appareil CL
ou LCL peut être mis hors service dans un maximum de 1 semaine.
De plus, selon la réalisation de la présente invention, les appareils ont une utilisation d'au maximum 4 ans. Cette durée peut tout à fait se ramener à 2 ans. Dans le contexte de cette durée, en considérant une possibilité de pertes des appareils selon la présente invention, avec un volume de 1 million de pertes d'appareils en 2 deux ans (les pertes volontaires seraient empêchées par le prix d'achat d'un nouvel appareil en cas de perte). Ce volume peut sembler exagérer. Compte tenu des capacités des méthodes de compressions (un faux de 50%), et compte tenu de la taille de 128 bits d'un numéro de série ID, il faudrait donc environ et sans compression 1 S
mégaoctets, 8 mégaoctets avec compression d'espace de stockage de données. Sur une durée d'utilisation de deux ans des appareils selon la présente invention, la capacité de la DiskOnChip selon la présente variante suffit.
Pour le cas de durée d'utilisation plus longue, des capacités de stockage plus grandes peuvent être prises compte tenu de la capacité des modules DiskOnChip dans l'état actuel de l'art.
De plus, ledit radiorécepteur numérique, compte tenu de sa capacité de recevoir des informations qui le concerne uniquement, lors de l'achat d'une licence de logiciel, l'utilisateur peut recevoir par radio le fichier Fich.S# (décrite précédemment) correspondant à
son achat de licences du logiciel numéroté S#. Cette fonctionnalité peut avoir un grand impact au niveau commercial (l'achat de logiciel peut être effectué partout sur la planète sans connexion). Bien sûre, Fich.S# est __._ ..~__._._ ___ . _ __ envoyé sous forme codée avec la clé kLi de la semaine courante. Selon d~;s variations de réalisations, on peut utiliser une clé de type kT.d pour les opérations d'achat.
La possibilité de faire rejeter l'utilisation d'un appareil selon la présente invention par le reste des appareils selon la présente invention, permet de donner aux utilisateurs la possibilité de récupérer une partie du contenu de leur carte CL perdue.
Ainsi, en tenant compte du format de fichier Fich.S#, la taille de ce fichier peut êtxe ramenée à
66 octets dans un ftchier nommé rFich.S#, en conservant uniquement les champs suivants : S# du logiciel, m.c, L#.S#, kEL.S#, kX.S#. En considérant uniquement les logiciels dont l'utilisateur possède une licence d'utilisation permanente, rFich.S# suffit pour définir l'utilisation de ces logiciels protégés selon la présente invention. Ainsi avec un module de mémoire de 64 kilooctets, on peut stocker au moins 990 licences de logiciels différents dont l'utilisation peut être définie par rFich.S#. Selon cette nouvelle variante, l'organisme qui gère aSVR, fournit lors de l'achat d'une carte CL une carte à puces (SmartCard) notée SC, et pouvant sécuriser des données en lecture et en modification. SC n'est pas illustrée. SC camporte un microcontrôleur intégrant sur une seule pastille de silicium, un processeur, un module mémoire Flash de 64 kilooctets, de la mémoire DRAM et OTPEPROM. Les accès en mémoire sont contrôlés par le processeur du microcontrôleur de SC. Cette carte est une carte à puces sécurisée. Cette carte à puces est utilisée à chaque fois que l'utilisateur acquière légalement une nouvelle licence pour une ou des utilisations) permanente{s) d'un logiciel donné protégé selon la présente invention. Lors de cette acquisition, cette carte est insérée dans le lecteur de cartes à puces qui communique avec le microcontrôleur 100 du lecteur LCL par le moyen du contrôleur de cartes à puces 153. Le fichier rFich.S# sera alors copié dans le module de mémoires Flash de 64 kilooctets du microcontrôleur de la carte à
puces. Bien entendu, la carte à puces SC possède en interne une clé secrète kLi de la même manière que la carte CL. Cette clé est utilisée lors d'une procédure d'identification similaire à celle qui a lieu entre le lecteur LCL
et la carte CL. Des modifications du contenu de la carte SC ne peuvent être effectuées uniquement par un lecteur LCL connecté à une carte CL associée. Ainsi, pour cette variante de la réalisation de l'invention, rFich.S# est stocké sous une forme codée, notée erFich.S#, par la clé kS.c de la carte CL. De plus, compte tenu des propriétés de sécurité des cartes à puces (SmartCard), erFich.S# et ainsi protégé contre la modification ou la lecture non autorisée. De toutes manière cette information est protégé. De plus, par l'emploi de la clé kS pour codée rFich.S#, cette carte ne peut être utilisée qu'avec la carte CL d'où les fichiers rFich.S# proviennent. Bien sûre, si l'utilisateur a acheté des licences d'un logiciel S# en plus par rapport à celles qu'il a déjà dans sa carte CL, LCL copie alors erFich.S# et l'envoie vers la carte CL correspondant. Les champs de rFich.S#
sont mis à jour par rapport au nombre de licences nouvellement acquises. Le nouveau fichier erFich.S# obtenu remplace ensuite l'ancien dans la mémoire interne du microcontrôleur de la carte SC.
Ainsi en cas de perte, la sauvegarde effectuée sur la carte à puces SC peut être récupérer en deux étapes : achat d'une nouvelle carte CL, connexion vers le serveur aSVR
par l'intermédiaire du programme PGM.

Lors de la connexion sur le serveur, l'utilisateur communique par l'interniédiaire de son programme PGM, le numéro de série ID.c de son ancienne carte CL (lD.c est une donnée publique non modifiable : il est affiché en clair sur le boîtier 60 de chaque CL).
Ensuite, l'utilisateur communique le numéro de série de sa nouvelle carte CL. En échange, aSVR
retourne une donnée qui est la forme codée de la clé secrète kS de la carte CL perdu. Cette clé
est codée par la clé kT.d du lecteur LCL sur lequel la nouvelle carte CL est connectée. L'acquisition de la clé kS de la carte CL perdue permet de récupérer ainsi le contenu des fichiers rFich.S#.
Selon la variante de l'invention utilisant le radiorécepteur, le numéro ID.c de la carte CL
perdue peut être communiqué oralement par téléphone. LCL reçoit alors par l'intermédiaire de son radiorécepteur numérique et sous une forme codée par la clé kLi de la semaine courante, la clé kS
de la carte CL perdue et correspondant audit numéro ID.c de la carte perdue.
L'acquisition de la clé
kS de la carte CL perdue permet de récupérer ainsi le contenu des fichiers rFich.S#.
De l'autre coté, aSVR lance une procédure pour désactiver l'utilisation de la carte perdue en envoyant selon la variante de l'invention précédemment décrite, le numéro ID.c de la carte perdue à tous les lecteurs LCL.
Selon une autre variante de l'invention, le stockage des fichiers Fich.S# peut être effectué par le lecteur LCL en suivant les conditions de sécurités similaires au fonctionnement d'une carte CL
au niveau du stockage de ces fichiers. Les fichiers Fich.S# seront alors stockés sur média d'enregistrement externe prévu pour ce stockage. On peut utiliser par exemple une DiskOnChip.
Les fichiers stockés sur ce support sont protégés par la clé kS.d du lecteur LCL correspond. Dans cette variante, la clé kS.d est une clé secrète inscrite dans la mémoire interne 111 lors de la programmation en usine du microcontrôleur 100. Ainsi lorsqu'une ou des licences) de logiciels sont déplacés vers le lecteur LCL, l'accès aux logiciels protégés selon la présente invention, et associés à ce lecteur LCL peut être réalisée indépendamment de la présence d'une carte CL. Ceci permet une utilisation par toutes les personnes pouvant accéder à l'ordinateur sur lequel ledit lecteur LCL est connecté. Bien entendu, lors d'un déplacement de licences de logiciels d'une carte CL, les informations seront mises à jour dans la carte à puces SC en obligeant la connexion de la carte à puces SC correspondant à cette carte CL sur le lecteur adapté du lecteur LCL. Par exemple lorsque deux licences d'un logiciel numéroté S# sont déplacée de la carte CL
vers un lecteur LCL, le contenu du fichier eFich.S# de la carte CL et le contenu du fichier erFich.S# de la cartes à puces SC seront modifiés en conséquence afin d'écrire un fichier d'utilisations de logiciels au niveau du lecteur LCL. Dans cette nouvelle fonctionnalité du lecteur LCL, une carte à
puces du même type que SC devra être associée à chaque lecteur LCL pour permettre une sauvegarde des fïchiers Fich.S# relatifs à des licences d'utilisations permanentes de logiciels.
Ainsi, cette carte à puces devra être insérée immédiatement après les déplacements des licences d'utilisations de la carte CL
vers le lecteur LCL pour valider le transfert. Compte tenu du fait que les autorisations d'uülisations de logiciels copiées dans le lecteur LCL peuvent être transférer par une opération inverse à celle qui vient d'être décrite vers une nouvelle carte CL, il est donc possible de déplacer une autorisation d'utilisation d'un logiciel protégé selon la présente invention d'une carte CL
vers une autre carte CL. Les cartes à puces SC respectives de ces deux cartes CL seront bien entendu mises à jour automatiquement.
De plus, par rapport à ladite possibilité de changer de carte CompactFlash sur une carte CL, et S par rapport à des autorisations d'utilisation de logiciels relativement à
une utilisation limitée, un fichier eTPS est présent sur chaque carte CompactFlash qui est utilisée par une carte CL donnée et numérotée ID.c. Ce fichier devra impérativement être présent sur toutes les cartes CompactFlash utilisées par ladite carte CL. Autrement, la carte CL ne fonctionne pas. De plus, eTPS est la forme codée du fichier TPS qui contient en première ligne le numéro ID.c, puis tous les numéros de série de logiciels S# acquis selon la présente invention, par l'utilisateur de cette carte CL. Ainsi, un utilisateur ne pourra contourner les limites d'utilisations d'un logiciel d'utilisation limitée par rapport par exemple au temps ou au nombre d'exécutions, en changeant de carte CompactFlash.
Cette restriction s'applique selon la réalisation de la présente invention, par exemple sur les logiciels gratuits.
Ainsi selon des variantes évidentes de réalisation qui ne seront pas décrits (cette description n'apporte rien à la compréhension et à la réalisation de la présente invention), par rapport à sa capacité de protection d'informations contre toutes modifications, la carte CL
peut servir au stockage d'informations public non modifiable tel que l'identité d'une personne. Ces informations pourront être consultées par l'intermédiaire de l'interface utilisateur représentée par le programme PGM. La carte CL peut, en effet compte tenu de sa grande capacité de stockage permettre de stocker des programmes et/ou des compteurs relatifs à une valeur donnée, de manière sécurisée contre des modifications et/ou lectures non autorisées selon un critère donné.
De l'autre côté, LCL
offre un moyen sécurisé pour permettre l'exécution de ces programmes supplémentaires et/ou le traitement de ces compteurs relatifs à une valeur donnée. Le microcontrôleur 100 est physiquement protégé contre des programmes dits virus informatiques. On peut ainsi envisager de définir Ie champ Misc des fichiers Fich.S# par des codes de programmes exécutables par le processeur CPU2 du microcontrôleur 100 ou par des compteurs de fidélité représentant le nombre de licences de logiciels achetés par l'utilisateur à un concepteur de logiciels donnés, afin de permettre des opérations commerciales correspondantes. Les codes de programmes éventuellement ajoutés dans le champ Misc peuvent permettre de modifier le comportement desdites fonctions F; lors de leur exécution par le lecteur LCL, afin de rendre quasiment impossible le piratage du logiciel correspond en essayant de remonter à la fonction F; par une surveillance des entrées et sorties de données au niveau des appels des fonctions FF;. II est à rappeler que seule la forme codée eF; des fonctions F; sont accessibles par l'utilisateur.
Selon la présente invention, l'emploi d'un circuit intégré (le microcontrôleur 100) physiquement et logiquement protégé contre des attaques de virus informatiques et contre les lectures et/ou des modifications de données contenues dans le circuit, permet un très haut niveau de sécurité de protection de logiciels. Compte tenu des périphériques de communications que peut .._ _____- 7_ _ WO 99/3925b PCT/FR99/00182 utiliser un tel circuit, les appareils selon la présente invention, n'apparaisse plus comme un appareil prohibitif de surveillance, mais un véritable outil participant activement à
l'utilisation des logiciels notamment par le fait que la présente invention permet de récupérer en sécurité des licences perdues. En effet, la présente invention permet de rendre un outil de protection de logiciels, S d'aspect souvent décoratif en raison du temps où il est effectivement utilisé, en un outil que l'utilisateur peut utiliser dans sa vie quotidienne par sa capacité de sécuriser le stockage de données et l'exécution de programmes. Ainsi la présente invention est un nouvel outil de protection de logiciel qui permet d'une part la distribution des logiciels indépendamment de la vente de leur droit d'utilisation, et d'autre part un développement libre des logiciels protégés selon la présente invention. Selon la présente invention, cette séparation a une grande conséquence sur le coût nécessaire pour protéger un logiciel. En effet, l'utilisation d'un seul appareil selon la présente invention, pour la protection de plusieurs logiciels indépendamment des concepteurs de logiciels, permet de distribuer le coût d'un appareil selon la présente invention sur tous les concepteurs de logiciels, de sorte que le prix d'un seul appweil selon la présente invention, devienne faible et abordable pour l'utilisateur.
De plus, ladite séparation permet selon la présente invention, la vente de moyens de protections de logiciels indépendamment des logiciels qui utilisent ces moyens ptiur la protection.
La puissance de la présente invention au niveau des sécurités utilisées, permet compte tenu de sa vente séparée du produit logiciel, une exploitation commerciale liée à
d'autres opérations. Ces opérations peuvent être des opérations qui consiste à présenter des informations confidentielles que l'utilisateur ne peut modifier ou falsifier. Elle peut servir donc à un outil permettant des accès à un système donné. Ainsi, la présente invention est un moyen de protection de logiciels qui permet des fonctionnalités parallèles à son utilisation. Ces fonctionnalités auront pour conséquence la baisse du coût des appareils selon la présente invention et la baisse du coût de protection d'un logiciel donné. La protection de logiciel selon la présente invention, devient par conséquent un système intéressant pour les petites et les grandes productions de logiciels. Les appareils selon la présente invention sont susceptibles d'une industrialisation par rapport au monde de l'industrie des logiciels et de leur protection.
Bien entendu, l'invention n'est pas limitée aux modes de réalisation qui viemlent d'être décrits et représentés. On pourra y apporter de nombreuses modifications de détail sans sortir pour cela du cadre de l'invention. 6 PCT / FR99 / 00182 encoding key size.
According to the present invention, the LCL and CL devices can be configured in a certain measurement via a computer program, noted PGM, suitable for each type computer and computer operating systems. PGM allows a user to start procedures relating to operations requiring intervention by use. These procedures are described below. PGM is distributed by said organization who manages aSVR. AT
installing PGM on a host computer, a localization operation of an LCL reader is performed. If an LCL reader is connected directly to a computer communication host, a DRV software driver for communication through this port is installed in order to allow a program on this computer to send and receive data to LCL
LCL by following the diagram of Figure 2, without taking into account the technical characteristics of Communication between this computer and the connected LCL player. The DRV driver allows transparent use of the LCL reader.
In the case where protected software is used on the network (this is from context 40), a appropriate DRV driver program will be installed on each computer on the network, to allow the communication between these computers and the LCL connected on this local network. The DRV driver allows transparent use of LCL for each computer on the network which may have different computer systems between them.
When installed on the Ethernet network, the LCL reader receives an address IP versus TCP / IP protocol, which allows the driver installed on network computers to locate it.
In addition, each DRV driver allows each host computer where are used softwares protected by the present invention, to communicate with the LCL reader. The realization of the present invention also allows that several PGM programs can establish communications with a given LCL reader connected to the network in question.
In its use network 40, the LCL reader in case of intensive use, can share with other LCL reader, sa software protection function as seen in Figure 4 where a distribution of computers using two LCL readers is illustrated. The distribution of LCL readers on the network with computers is, according to the realization of this invention made by network administrator. The latter distributes the computers of the network compared to LCL readers present on the network, when DRV was installed on each computer's this network. It tells DRV the IP address of the LCL reader to use.
After installing PGM on a host computer, users of this computer can then perform on a given LCL reader, connected with a given CL card the different following operations: online purchase of software licenses protected by i present invention, relocation of a number of licenses to use CL card software to another CL card, lost license recovery operations with the loss of a CL card, updating the programs contained in the memories LCL reader electronics or the CL card.

Thus, the realization of the present invention considers a given software, noted LD. The The following descriptions are valid for all other software. Its designer (manufacturer) protects it according to the present invention, against illegal uses by separating all functions composing its software in two parts. The first part concerns procedures he desires leave the execution to a host computer. The second part concerns functions that should be run by LCL compute resources. These functions must be quick to execute. Their size is around 100 kilobytes.
From this second part of said LD software, he extracts a list of functions {Fo, F ~, ..., F ;, ... F "}. These functions are necessary for the operation of the LD software.
To perform this extraction, it must respect a fundamental rule: these functions must not not use resources characteristic of computers intended for the execution of LD.
This condition is enough easy to stick to. For example, said list of functions can be only functions of pure calculations.
According to the embodiment of the present invention, the writing of these functions and their good test operation can be performed regardless of the presence of the reader LCL. The way retained for the realization of the present invention, relates to the machine JAVA virtual. So these functions are written in JAVA. These functions are therefore compiled in “byte language code universal JAVA and stored in a file, noted LF.
Furthermore, according to the embodiment of the present invention, the protection of the LD software then begins by running the PGM program on a computer containing LF. According to realization of the present invention, PGM then asks the designer of LD the system operating system (WINDOWS NT, DOS, L11 ~ TIX, ...) and the type of computer (MACINTOSH, SPARC, PC, ...) which will execute LD. After these answers, PGM launches a procedure of reader connection LCL available to the aSVR server. Communication between LCL and aSVR is done according to the figure 2. The serial number of the LCL reader is given first to the aSVR server.
During this procedure for creating software protected by the present invention, LCL
ask aSVR in secure communication an S # serial number to associate with the software protect LD and a key to kX.S # encodings.
According to the embodiment of the present invention, S # is defined on 128 bits, and The key kX.S # is defined with respect to DES encryption with a size of 128 bits.
According to the embodiment of the present invention, to perform said secure communication with aSVR, LCL starts by sending aSVR its ID.d number in a non-form coded. Through association with the corresponding key, aSVR found in its database 12, the key kT.d to associate with ID.d.
Thus, aSVR returns to LCL, S # and kX.S # in a form coded with the key kT.d.
The reader LCL retrieves the clear form of S # and kX.S # by decoding with the key kT.d which is in his internal memory 111, compared to the DES encryption algorithm.
According to the present invention, the key kX.S # is known by aSVR alone, because after use, kX.S # will be deleted from the DRAM 109 secure memory of LCL. In addition, S # esv communicated to PGM which registers it in a binary file containing the boundary conditions software usage.
According to the embodiment of the present invention, this file can have the format next: S # of software associated (128 bits), permanent licenses (8 bits), duration of use (24 bits), (use expires end (16 bits), number of executions (32 bits). This (shit is therefore a size of 26 bytes. {Fo, F;, ..., F ;, ... F "} then undergo encryption operations. The Fo function is treated separately. According to carrying out the present invention, the so-called initialization procedure allowing on the one hand to count the number of licenses used on the network in the network context 40, and on the other hand measure usage characteristics of LD software compared to time. It is a function which is executed during the execution of the LD software by a user, and repetitively. Fo is in particular the first function which will be executed by LCL when opening of a session LD software executions.
Fo is coded with a different key from kX.S #. For this the PGM software generates a key of same type noted kEL.S # compared to DES encryption. The kEL.S # key is known only by the designer of LD. According to the embodiment of the present invention, kEL.S # is a 128-bit key. he is the responsibility of the designer to keep this key safe kEL.S #. To this function coded, it attaches other information coded also by the key kEL.S #. It's about of the file containing the conditions for using the LD software. This coded information then constitute a file named eFo according to the embodiment of the present invention.
In addition, according to the embodiment of the present invention, the other functions are then coded by the key kX.S #. For this step, PGM then sends F ,, ..., F ;, ... F "to LCL through of DRV. LCL computing resources then code these functions successively with the key kX.S #. At the end of the coding operations, LCL returns {eF ,, ...., eF "}
corresponding respectively to the coded forms of {F ,, ..., F "}.
According to the embodiment of the present invention, PGM then proceeds to software assembly.
For a given operating system, PGM creates a library file of functions that will be executed during the execution of the LD software on a user's computer given. The different library functions allow you to load an element from {eFo, ...., eF "} with parameters necessary to execute the corresponding function, to the LCL reader when using LD. eFO, ...., eFn will be respectively loaded by the functions FFo, ...., FF "created by PGM.
These functions are created in relation to the type of operating systems and the type of computers partners who will execute LD. PGM thus brings together {FFO, ..., FFn} and {eFO, ..., eFn} with the rest of the LD software thus protected, and numbered S #. Everything is then put on media registration, by example a CDROM. The software is thus protected and ready to be distributed freely, because he cannot not be used in the current state. So the distribution of the media recording can be completely free.
Thus, the software protection according to the present invention is based on the use of LCL reader calculation resources.

According to the present invention, the LCL reader is an electronic reader built around a microcontroller 100 physically and logically secure to prevent against attempts to hackers for unauthorized electronic checks. Given that that this microcontroller 100 is required to run programs of unknown origin, this invention relates to a means of preventing computer attacks of the microcontroller 100 by virus intermediary IT. This is done to prevent a virus from reading information confidential linked to the operations of the LCL reader. So this invention allows secure both the storage of information and the execution of everything outdoor program to the programs initially loaded into the microcontroller 100.
According to the embodiment of the present invention, the architecture chosen for the microcontroller is built around a system based on a set of two processors used in master slave. In reference to FIG. 3, the microcontroller 100 integrates on the same pad silicon two parts main 130 and 120. Integration methods ASIC (Application Specific Integrated Circuit) are used to make these silicon wafers. Part 130 includes a CPU1 processor which is the master processor. It is connected by an internal bus 101 to a module of FLASH memories 111, a DRAM memory module 109, a 1I2 random number generator, a doors RS232 151, a USB port 152, a smart card controller 153, a controller PCMCIA 154, a keyboard and LCD screen controller 155, a controller 113 of the slave processor CPU2 which is in part 120, an interface 106, a Bus interface external 105, a internal programmable real-time clock 104, a microfuse system internal 102 which allows to take out the internal bus 101 outside the microcontroller 100. The part 120 of the microcontroller 100 includes a watchdog 108. The CPU2 is connected by the internal bus 114 to a memory module DRAM 110, a DMA controller 107, and an interface 106. The slave CPU2 is ordered by through controller 113 and interface 106. The latter two electronic systems (113 and 106) are controlled only by the master processor CPU1. So, such architecture allows the execution of programs of unknown origin without damage integrity information contained in the microcontroller 100.
According to particular embodiments, the microcontroller 100 may not not integrate on the same silicon wafer all or part of the following: I / O port RS232 151, USB port 152, smart card controller 153, PCMCIA controller 154, keyboard controller and LCD screen 155.
According to particular embodiments not illustrated, and in order to accelerate processing speed information, the microcontroller 100 can comprise on the same chip of silicon one encryption coprocessor adapted to the DES encryption technique.
Of course this encryption coprocessor will be integrated into part 130 connected to the bus internal 101.
According to the present invention, the internal real time clock 104 is supplied by a pile electric 103 external with respect to the microcontroller 100. Its operation is autonomous. This clock is integrated on said silicon wafer in order to prevent control attempts distorting the time and date it provides to CPU1. Considering from the weak power consumption of this clock, the electric battery provides continuously on current required to operate this clock for the entire duration of use of microcontroller 100 as the central organ of the LCL reader. Optionally, a procedure setting the time of the clock 104 may be carried out by the aSVR server.
The clock 104 allows measure the time spent using protected software and perform operations dependent on the date and time.
The internal bus 101 is taken out of the microcontroller 100, by through the microfuse system 102. According to a variant not illustrated, the microfuse is avoided by using internal OTP EPROM memory. This variant allows same levels safety than using the microfuse system 102.
The microfuse system 102 makes it possible to produce a system of microcontroller programmable only once. The data necessary to put into service LCL readers (secret coding keys, serial numbers, identifiers, dates, times), and the operating system microcontroller 100 grouping programs allowing LCL readers to realise directly and / or indirectly all the functions relating to present invention are factory programmed in the non-volatile memory memory area (memory Flash 111). The operating system is executed in DRAM 109.
The embodiment of the present invention uses FLASH memory as support of permanent storage for the microcontroller 100. The choice of such a memory FLASH can allow a very easy update of the operating system initially factory programmed.
According to the embodiment of the present invention, the times and the dates are data, unless stated otherwise, compared to the origin meridian of GMT time zones (Greenwich Mean Time).
So when setting the time during the programming of the microcontroller 100 in the factory, this reference is taken for the internal clock 104 of the microcontroller 100 of the LCL readers.
After programming, the microfuse system is destroyed which prevents definitely a new programming of the microcontroller 100, there is then no more access direct inside of the microcontroller 100, because all the controllers and interfaces are completely under the control of master processor CPU1 (depending on the construction of the microcontroller 100). The operating system of the microcontroller 100 thus programmed is automatically loaded by the master processor CPU1 each time an LCL reader is started.
Thus all the information which is stored in the internal memory of microcontroller 100 are secured against all attempts at control electronic external to microcontroller 100. Given the physical properties of a pellet of silicon, its size and its housing, it offers in the current state of the art a very good physical and logical protection against all unauthorized intrusion attempts into circuits internal of the microcontroller 100. According to particular embodiments, protection techniques additional can however be added around the microcontroller 100. One of the possible techniques concerns the use of an external electrical protection device integrated circuits, presented in the patent of the company IBM in 1990 (US Patent 5,117,457).
The slave electronic system 120 is used to execute programs coming from outside of microcontroller, i.e. not belonging to the operating system which was loaded in the FLASH memory 111 when programming the microcontroller 100. It allows to execute programs safe from possible computer virus attacks. Security is completed by report to these attacks through physical protection characterized by a logical separation of the same silicon wafer in two parts 120 and 130 of which one 120 is slave of the other 130.
According to the embodiment of the present invention, the DRAM memory area 109 is strictly reserved for the execution of the operating system of the microcontroller 100 which been loaded at the factory, during the prograxnlnation procedure of the microcontroller 100. It is also used buffer to transfer programs and / or data from outside the microcontroller to the DRAM memory 110 via interface 106 controlled only by the processor master CPU1. The programs from outside are executed from DRAM memory 110, by the slave processor CPU2 controlled by the master processor CPU1 via the controller 113.
According to the embodiment of the present invention, compared to the uses of LCL readers with different types of computers and operating systems, and given of writing Fo functions previously described, the CPU2 is a Java processor (PicoJava) from Sun Microsystems. This characteristic makes the development of the functions {Fo, F1, ..., F ;, ... F "}
independent of computational resources of the computer running software protected according to the present invention, and internal resources of LCL. In addition, the designer protected software by the present invention, can test the operation of the functions {Fo, F ,, ..., F ;, ... F "}
independently of the LCL reader with a program simulating a virtual machine JAVA.
According to the embodiment of the present invention, CPU1 is a processor of the type 80386SX. he can so use directly via its internal bus 101 a large amount of edou internal memories external. Its calculation capacity allows us to envisage a high capacity for treatments multitasking information.
According to particular embodiments, the microcontroller may not use of JAVA processors, but an 80386SX type processor including the system operating would be the JAVA virtual machine from Sun Microsystems that the CPUl would load at every news execution of programs in DRAM 110 in order to avoid possible attacks virus IT.
In addition, according to the embodiment of the present invention, all of the any information of the DRAM memory 110 is erased by CPU1 before each new loading of programs which must be executed by CPU2. CPU1 pauses CPU2 via of the controller CPU2 113, and clears, for example by temporarily disabling the circuits that make up the DRAM 110 memory module, the content of this DR.AM 110 memory thanks to interface 106.
Then CPU1 loads the execution parameters and the new program to run in the DRAM 110 directly thanks to the DMA 107 controller. This direct loading allows to not use CPU2 and allow CPU1 to fully control DRAM 110.
So after loading of the program, CPU1 then gives the hand to CPU2 via of the controller CPU2 113. CPU2 then executes the new program. So given all of these measures, if this program is a computer virus voluntarily registered in one of the type F functions;
however, it cannot affect the functioning of the microcontroller 100, ni copy out of the data not erased concerning the old data functions that have been executed by CPU2 in DRAM memory 110. In addition, CPU1 keeps the access control to the data contained in its part 130. This procedure for loading program and / or data in DRAM 110, is repeated for each program which must be executed by the slave processor CPU2.
According to the embodiment of the present invention, the architecture presented by the Figure 3, allows prevent a program that does not belong to the operating system of the microcontroller 100 to perform readings and / or modification in the internal memory of the system 130 integrated in the rr ~ icrocontroller 100. It also makes it possible to prevent these programs from controlling interfaces and / or microcontroller 100 controllers, and therefore prevent hackers from reading the content of memories physically and logically secured from system 130, integrated into the microcontroller 100.
In addition, according to the present invention, the external bus interface 105 allows the microcontroller 100 to control external devices connected to external bus 114. This bus add to LCL of recording devices such as media type record Flash Disk (FLASH memory used a standard disk), a peripheral communication network.
The architecture of the microcontroller 100 pern ~ and a great modularity of operation.
According to the embodiment of the present invention, on this bus 114 is connected a access device Ethernet network for communication in TPC / IP protocol. Depending on the type of communication used between an LCL reader and a given computer, we can connect to this bus a device adequate for this communication. So we can add a radio device receiver 22, for use an LCL reader in the context 20 of figure 1. The use of this receiver will be defined by the after.
According to the embodiment of the present invention, taking into account the controller Integrated PCMCIA 154 in the microcontroller 100, the peripherals used can also be PCMCIA cards used by the microcontroller 100 for all operations relating to the present invention. These PCMCIA cards can be PCMCIA Ethernet cards, FLASH cards PCMCIA, a disk PCMCIA hard drive, a PCMCIA wireless digital reception module card. These different cards are not illustrated. The use of the PCMCIA controller makes it possible to add to an LCL reader given devices more easily compared to external bus 114. The USB 150 port used for a high speed transmission and reception connection between a computer, and a player LCL given. These are contexts 30 and 20.

_ 17-The I / O port 151 allows, according to the embodiment of the present invention, to communicate with a CL card.
Referring to Figure 5, the CL 60 electronic card is built around of a microcontroller 400 integrating a processor on the same silicon wafer CPU 405 connected by an internal bus 406 to a Flash memory module 401, a memory module OTP EPROM
407, a DRAM memory module 404, a RS232 403 I / O serial port, a controller CompactFlash 402 from SanDisk.
According to a variant not illustrated, the microcontroller integrates on the same pad surface silicon a DES encryption coprocessor to allow the CPU to perform operations encryption faster.
According to the embodiment of the present invention, the read accesses in the memory module OTPEPROM directly from outside the microcontroller 400 are deleted, in order to leave all access to internal circuits of microcontroller 400 under single control CPU processor 405. The present invention does not require the use of a large computing power at the level of the processor CPU 405 integrated in the microcontroller 400.
This microcontroller 400 includes a means of securing the reading and / or the modification illicit information that is contained in its internal memory. A
security method access to memories is proposed in the US Pat. 5,293,424 dated March 8, 1994.
According to the present invention, the internal OTP EPROM memory 407 is used to store keys to encryption, identification serial numbers, dates, system operating the microcontroller 400 performing functions directly and / or indirectly relating to his use according to the present invention.
According to the embodiment of the present invention, the internal FLASH memory 401 used to store permanently additional data after leaving the factory CL card. She serves also to store additional programs that allow the microcontroller 400 to realize directly or indirectly additional functions relating to its use according to present invention after leaving the CL card factory.
According to the embodiment of the present invention, and in general, the CL card is powered electrically by LCL when connected to LCL. This connection electric is not illustrated.
According to the present invention, the microcontroller 400 is protected against any modification of information it contains. It is a microcontroller similar to those smart cards. It is connected to a female connector 63 which makes it possible to communicate by contact with a LCL reader given.
According to the present invention, the CL card is a portable device of small size with a high capacity removable storage unit.
According to the embodiment of the present invention, the microcontroller 400 is connected to the sound output CompactFlash controller to a 64 connection support for modules type memories CompactFlash.

According to particular embodiments, the CompactFlash controller may not be integrated on the same silicon wafer as the microcontroller 400. It can also use another recording media such as DiskOnChip modules from the company M-Systems or any other proprietary and removable system of non-volatile memories.
In the current state of the art, microcontrollers having the characteristics of microcontroller 400 are very numerous. According to the realization of this invention, a 32-bit RISC microcontroller with the characteristics of microcontroller 400 has been integrated on the same silicon wafer with the CompactFlash card controller.
This integration uses ASIC (Application Speciflc Integrated) integration technologies Circuit).
So all of the information that is stored in memory internal of microcontroller 400 is secured against all attempts at checks external electronics.
According to the present invention, the CL card is a portable device of small cut. It allows to transport information concerning the use of protected software, regardless of LCL electronic reader. It is used as an access key to the use of software protected according to the present invention. Its portability allows a user to use software whose use rights (licenses) it has purchased on any computer that would own this software.
According to the embodiment of the present invention, the geometric format of CL is between that of the CompactFlash card is that of a PCMCIA card.
Referring to Figure 6, a hole 62 has been placed in a corner of the housing 60 representing CL.
Thus, the CL card can be attached to a mechanical keychain. According to realization of this invention, the serial number ID.c not illustrated of a given CL card is printed on case 60 from CL.
In addition, according to the present invention, with reference to Figure 7, the module memories CompactFlash 61 is detachable from housing 60 via the support system connection 64 for card CompactFlash.
With reference to FIG. 8 and according to the embodiment of the present invention, the CL card is connects by contact with an LCL reader via a set of two male connectors female. A map CL has a female connector 63 which it connects to the male connector 210 correspondent of LCL reader. These connector sets allow RS232 serial communication between LCL and CL
by contact. In addition, it provides electrical energy to electronic circuits of the CL card. According to the embodiment of the present invention, the LCI reader. East powered by mains.
According to particular embodiments not illustrated, CL can have its own food electric to allow autonomous operation. According to these modes private individuals, you can integrate in CL a radio or infrared communication module to allow contactless communications with LCL. An example of such a device is brought by Hough in US Pat. No. 5,412,253. Of course, the LCL reader has in these conditions the ports of adequate communications.
According to the embodiment of the present invention, all the coding keys written in the factory when programming of LCL and CL type devices are 128-bit keys definite compared to the DES algorithm. Thus, given this description of the invention, a module of 256 kilobyte OTP EPROM memories, a 64 Flash memory module kilobytes, one 512 kilobyte DRAM memory module has been integrated with the CPU 405 (RISC processor), the RS232 403 I / O serial port and the CompactFlash card controller on a same tablet silicon. Of course, other larger memory sizes can be used according availability of ASIC integration macros and their cost. These quantities are given by in relation to this achievement.
Furthermore, according to the embodiment of the present invention, the size retained for the module Flash memory 111 is 1 megabytes. The size chosen for the DRAM memory 109, is 2 megabytes. The size used for the DRAM 110 memory module is 1 megabyte.
These quantities are given relative to the present embodiment.
All the programs relating to the functionalities of the LCL reader constitutes the system internal operating system of microcontroller 100. This operating system is recorded in the Flash memory 111 of microcontroller 100 when programmed in the factory.
All the programs relating to the functionality of the CL card constitutes the system internal operating system of microcontroller 400. This operating system is recorded in the OTP EPROM 407 memory of microcontroller 400 when programmed in factory.
According to the present invention, communications between LCL and CL are secure. The current The invention relates to the use of an authentication method allowing a group of any device to recognize themselves using this method. This authentication allows that only the devices relating to the present invention, certified by the organization that manages the server aSVR, can work together. This method according to the present invention, allows prevent devices which are not recognized by the body which manages them devices related to present invention, can not work with those recognized. This method thus prevents hacked devices to read data from memories secure electronic apparatus relating to the present invention.
The present invention relates to apparatus which can only be used during a duration to be determined over time. For the realization, LCL and CL devices are all characterized by a date of commissioning DB and a date DE which indicates that the use of these devices relating to the present invention, expires end OF. DB and DE constitutes a public information no editable.
Thus, according to the embodiment of the present invention, the date DB of the reader LCL, denoted DB.d, is written during the factory programming of the microcontroller 100, in a zone free from Flash memory 111. In addition, the date DE of an LCL reader, noted DE.d, is written during the factory programming of microcontroller 100, in a free area of the Flash memory 111.
In addition, according to the embodiment of the present invention, the date DB of CL, denoted DB.c, is written when programming the microcontroller 400 in the factory, in a free zone from memory Flash 401. In addition, the date DE of a CL card, noted DE.c, is written during programming in factory of microcontroller 400, in a free area of memory OTPEPROM 407.
Thus, according to the embodiment of the present invention, the organization which manages aSVR generates for each week of the international calendar which begins on Monday and which ends late sunday a kLi key. The kLl key is the first key that was generated for the first week when first devices relating to the present invention have been put into service.
The key kLi indicates the key of week i compared to this first week. All of these keys are fully created and kept secretly by the organization that manages the aSVR server in order to guarantee Security of use of the devices relating to the present invention.
According to the embodiment of the present invention, for a CL card considered, when programming procedure for its microcontroller 400, the secret key to kLj coding is written in a free area of the OTPEPROM 407 memory. This secret key kLj corresponds to the week j compared to the first week when the first devices relating to the present invention have been commissioning. The key kLj was chosen so that week d contains the date DB of the commissioning of this CL card. This secret key will never be revealed to the user. Through moreover, it is known only by the organization which manages the aSVR service.
In addition, according to the embodiment of the present invention, for an LCL reader considered, during the programming procedure for its microcontroller 100, the list of keys coding secrets {kL; +], kL; + 2 ~~ -i + 3 ~ ~ ~ ~ ~~ + mi corresponding to all the keys associated with weeks between the date DB.d reduced by 1460 days and the date DE.d, are stored in the Flash memory 111 of microcontroller 100. Of course, their memory addresses follow a convention adopted for allow them to be found in memory 111. These secret keys are by elsewhere known only by the organization that manages the aSVR server. All these secret keys who have just been cited, are generated in relation to the DES encryption algorithm. Each of these secret keys has a size of 128 bits.
According to the embodiment of the present invention, the duration which separates a date from commissioning DB and an end date DE of the devices relating to this invention, is from 1461 days (4 years). Thus {kL; + ;, ld.; + Z ~ l ~ .a + 3, ..., kL; + ",} occupies no more than 7 000 bytes (approximation voluntarily excessive) in the Flash memory of the microcontroller 100 of a LCL given. The figure 4 allows to understand the choice of the number of keys in the list {kL; + ;, kL; + z, ~ .a + 3, ..., kL; + m}.
This number is due to the existence of the oldest devices, still in service on date DB.d from commissioning of the LCL in question. Given the capacity of the memories Flash built into within a microcontroller 100, all of the keys {kL; + t ~~ ..i + 2W-i + 3 ~~~~~ l ~ i + mi can therefore be stored with the microcontroller operating system 100.
Thus, the realization of said authentication procedure is based on judicious use of all these keys. The number of keys used allows that if a key were to be broken, the operation linked to authentication with respect to this key, does not set in check the entire system relating to the present invention.

WO 99! 39256 PCT / FR99 / 00182 With reference to FIG. 10, for the use of LCL, firstly, an LCL reader can only work if the current date indicated by the real time clock internal 104 of LCL microcontroller 100 is between the dates DB.d and DE.d of the same LCL. Other the continuation cannot succeed 551. This condition is illustrated in FIG. 10 by element 501 $ Secondly, with reference to step 502, to highlight operation one LCL reader, user must perform an identification operation detailed later.
Thirdly, to put a CL card into operation, user must first connect its CL card (step 503) to the male type support of connection 210 owned by the LCL reader, to allow communication by contact between the LCL reader and card CL. The male type 210 support of the LCL reader is connected to the RS232 I / O port 151 of microcontroller 100. The CL card therefore has a female connector 63 connected to the RS232 I / O port 403 of its microcontroller 400. The user must then perform a identification operation described below.
According to the embodiment of the present invention, in a fourth step 504, the microcontroller 400 of the CL card sends in an unencrypted form its date of commissioning DB.c au LCL microcontroller via said RS232 link. If a hacker modify the DB.c value transmitted, the following this description cannot be successfully completed.
On the other side and after reception of DB.c, in a fifth step 505, the processor CPU1 of the LCL microcontroller 100 makes a correspondence between DB.c and a noted secret key kLj.d elements of the list {kL; + t, ~ .i + 2, ~ ..i + 3, ~~~ W-i + mi so that the week d associated with kLj.d according to the present invention contains DB.c.
In a sixth step 506, the processor CPU1 generates a 128-bit kCS key compared to DES encryption, using its random number generator 112. kCS is preserved secretly in the internal DRAM memory 109 of the microcontroller 100.
According to the present invention, kCS is then coded by kLj.d then sent under its shape coded, noted ekCS, towards the microcontroller of CL.
In a seventh step 507, on receipt of ekCS, the CL card attempts to decode ekCS with its secret key kLj. According to the present invention, if the decoding succeeds, said procedure authentication was successful. The CL microcontroller will then use the key kCS for sending coded information to LCL, and for decoded information coming through the sequel to LCL. The microcontroller 400 of the CL card stores in its secure internal memory DRAM 404 this key secret kCS.
Thus, according to the embodiment of the present invention, in an eighth step 508, the CL microcontroller then sends the expiration date DE.c associated with CL
in a form coded by the key kCS to the microcontroller of the LCL reader.
On reception, in a ninth step 509, CPU1 checks whether DE.c is not exceeded compared on the current date given by the internal clock of the LCL microcontroller 100.
If this date is exceeded, LCL will refuse to continue communication with the CL 552 card.
Otherwise, a secure communication between LCL and CL can take place 559.
Thus, each communication session between LCL and CL which begins with their connection by contact and which ends when one of the following conditions is filled: CL is disconnected of LCL, the current date indicated by the clock 104 has exceeded the date DE.c, the current date indicated by the clock 104 has passed the date DE.d. Disconnecting the card LCL reader CL
is marked by the absence of charge at the output of the power supply used to power the electronic circuits of the CL card.
In addition, according to the present invention, all communications between the LCL reader and card CL are secured by the use of a symmetric encryption method using a secret key, noted kCS.
According to the embodiment of the present invention, the user who wishes to make operate a device relating to the present invention, must enter on the keyboard its LCL reader controlled by the microcontroller 100 via the keyboard and screen controller LCD 155, a PIN code.
At the time of its entry, the numbers typed will be written on the LCD screen not illustrated and controlled by the controller 155. This code was supplied to him during the first acquisition (purchase) of the device in question. The PIN code is a 5-digit numeric code associated with each apparatus. He must be kept secretly by the owner of the corresponding device.
The use of such a code is similar to that used with identification methods present in the world of cards to chips (SmartCard) in the current state of the art. The steps to check the correct entry of the PIN code associated with each device according to the present invention, are obvious and are not detailed in the present description of the invention. However, add that the PIN code of a CL card is entered on the LCL keyboard, then transmitted in its non-form coded, towards microcontroller 400 of the CL card, via the RS232 serial link between a given CL card and a given LCL reader. It is therefore understood, unless otherwise stated, in a work correct of an apparatus relating to the present invention, that entering the code PIN was conducted with success.
The present invention relates to the use of a CL card as a medium recording portable, secure containing authorization files for use by all protected software according to the present invention, and acquired legally by the user and separately from the acquisition of software (the recording media). These files have been saved in the CL card following a software acquisition procedure described below.
According to the embodiment of the present invention, an authorization file of use of a given software with serial number S #, marked Fich.S #, is defined as binary file of which the data bits are ordered as follows: S # of the software (128 bits), B7.c (128 bits), number of licenses (L # .S #: 16 bits), last use (DR.S #: Day 5 bits, month 4 bits, year 12 bits, 5-bit hour, 6-bit minutes, 6-bit seconds), first use (DP.S #: date and time 38 büs), current usage time (DU.S # in minutes: 24 bits), number of software executions (28 bits), miscellaneous data (Misc: 1024 bits), kEL.S key (128 bits), kX.S # key (128 bits). The total is WO 99/39256 PC'T / FR99 / 00182 i 680 bits, a 210 byte file.

According to the embodiment of the present invention, a CompactFlash type card 61 distributed by the company SanDisk with a storage capacity of 4 megabytes is inserted as shown on the FIG. 7 on a suitable connection support 64 present on the CL card, to allow the connection of this CompactFlash card to the card controller CompactFlash 402 from 400 microcontroller. CompactFlash cards are compatible with the standard ATA cards PCMCIA in the current state of the art. These CompactFlash memory modules are used as information storage disks. The necessary instructions concerning the writing of the driver which allows the microcontroller 400 to use the CompactFlash module of 4 megabytes are given by the ATA standard. This driver not shown, allows depending on the realization of the present invention, at microcontroller to perform the following operations on the CompactFlash card : readings of files, file modifications, file creations.
Thus, according to the embodiment of the present invention, the CL card makes it possible to store more than 10,000 authorization files for the use of software protected according to the present invention. This number is more than enough for all software protected by present invention, that a user can legally acquire. However, the user can change CompactFlash cards for greater storage capacity. Given the ATA standard, this change does requires neither updating the microcontroller 400 system programs, nor change of case 60 and support for CompactFlash 64 card.
According to the present invention, the information stored on the card CL, about the authorizations to use protected software according to the present invention, do not depend on recording media but from the electronic card entity CL. So a CL card user can use several CompactFlash cards to store files type.Sheet #. The data that is stored on a first CompactFlash card associated with a CL card given can be transferred to a second CompactFlash card. This operation is performed at using the aforementioned PGM program.
According to the present invention, the Fich.S # authorization files are stored.
in a form coded, denoted eFich.S #, with a 128-bit kS.c secret key compared to the encryption technique DES, in the CompactFlash card used as a storage disk. The key secret kS.ca summer written in the OTPEPROM 407 memory during the factory programming of the microcontroller 400.
Thus, eFich.S # can only be used by the CL card that created it, because the secret key kS.c is different for each CL card put into service.
In addition, the present invention relates to a method for separating the acquisition of recording media containing software) protected by the present invention, from right to use this or these software (s).
According to the embodiment of the present invention, the recording media of protected software according to the present invention are freely distributed. However, software protected according to the present invention, can only be executed after an operation legal acquisition a file File.S # authorizing the use of this software numbered S #.
So, with reference to the figure 2, when a user wishes to obtain one or more licenses of use, it must connect everything first its LCL reader with the aSVR server, using the PGM program. According to the achievement of the present invention, this connection is established via the Internet.
To start acquiring an authorization (license (s)) of software uses numbered S # and protected according to the present invention, the user begins by connecting his card CL on said given LCL reader. The user must maintain his CL card connected at least until the end of this online purchase procedure (with connection). We suppose that the user wants to acquire NL number (s) of licenses to use this software numbered S #. he then enter the PIN code of their CL card on the keyboard of the LCL reader.
The operation authentication method mentioned above must be successfully completed in order to continue.
Thus, with reference to FIG. 11, according to the embodiment of the present invention, at the beginning of the connection with aSVR, said LCL reader communicates to aSVR its ID number.d (step 601}. In this communication context, aSVR is the remote system represented on the figure 2. Of course, the commercial transactions which implies that aSVR accepts a communication with said reader LCL are implied. The PGM program then sends the number to aSVR
S series of said software, entered by the user (buyer), and the NL number. These two information are sent in a form encoded by the secret key kT.d of the LCL reader of the user.
In addition, the embodiment of the present invention considers that the designer said software to S # serial number also has a server noted dSVR, not illustrated and connected by network Internet at aSVR. The dSVR server is connected on its side with the LCL reader said designer.
Of course, this assumes that the operating system of an LCL player is programmed such so that it can respond to certain requests relating to this server purchase procedure dSVR. Thus (step 602), dSVR then communicates to aSVR the number ID.d of its LCL reader which was used to create the protected S # software according to the present invention. The communication between dSVR
and the LCL reader goes as in figure 2 where the computer 50 is represented here by the server dSVR.
To allow communication on two levels, the LCL reader of the user communicates to aSVR (step 603) in coded form a public key, denoted kP.
The key kP is encoded with the secret key kT.d of the user's LCL. kP is a key public, relating to RSA encryption technique (Rivest, Shamir and Adleman). The kP key is created with his private key kV
for the occasion (dynamically) and deleted at the end of this procedure acquisition of licenses.
The form coded by said kT.d key of kP is denoted ekP.kT. In addition, it is necessary note that aSVR does not does not know the value of the private key kV associated with kP. Coding systematic information during communication avoids possible data modifications exchanged during their transfer.
On reception, aSVR decodes ekP.kT using the information it has concentrating the User LCL reader. According to the embodiment of the present invention, aSVR is alone outside of this LCL reader, to know the correspondence of the number) Dd with the key kT.d compared to a given LCL reader. The kP key is then coded with the secret key kT.d relating to the LCL reader of designer of the protected S # software according to the present invention. The new coded form of kP is noted ekP.kT2. ASVR then communicates ekP.kT2 604 to the LCL reader of the designer via the dSVR server. In this way, the use of protection techniques software according to the present invention, creates dependency between software designer protected according to this invention, and the organization that manages aSVR. Thus, the software designer has not to constitute stocks other than a stock of recording media containing the software protected according to this invention.
On receipt, the LCL reader of said designer decodes ekP.kT2 with its key kT.d.
With the key public kP, LCL relating to the designer then codes kEL.S # generated during the creation procedure S # software protected according to the present invention with the kP key. The form coded from kEL.S # by kP
is noted ekEL. According to variants not illustrated, after decoding ekP.kT2, said may communicate kP to the dSVR server in order to let it code the kEL.S # key with the kP key. But these variants do not change anything with regard to the fundamental principle of present invention.
According to the embodiment of the present invention, dSVR then receives from aSVR the value of NL.
NL allows the designer of protected software according to the present invention, to perform a accounting with the organization that manages aSVR. According to a variant of this procedure of acquisition of authorization of uses, dSVR sends after reception of the kP key, a public key kPUB relating to RSA encryption to the LCL of the user (buyer) via aSVR.
This variant allows the PGM program connected with the user's LCL reader to return to dSVR by via aSVR, the value coded with kPUB from NL. This variant allows dSVR
does not trust the good sincerity of aSVR. So this variant allows dSVR to control exactly the number of licenses sold.
According to the embodiment of the present invention, dSVR then sends (step 605) ekEL to aSVR.
This aSVR server then sends (step 606) kX.S # in a form coded with the kT.d key (that of user's LCL reader) to the user's LCL reader. The key kX.S # is a key created and stored by aSVR during the previously described protection procedure of the LD software numbered S #. The aSVR server then sends to the LCL reader of the user, eKEL. AT
reception, the user's LCL reader decodes eKEL by kV. So he gets kEL.S #. This reader LCL also decodes the coded form of kX.S # by its key kT.d.
According to the embodiment of the present invention, said LCL reader sends then to said CL card, in coded form with the kCS key obtained during the procedure authentication previously described, the following data: S #, NL which corresponds to the number of licenses requested by the user from aSVR, kX.S #, kEL.S #, date and time common indicated by the clock 104.
Thus, the microcontroller 400 of the CL card decodes the different data received with kCS.

The microcontroller 400 then proceeds to the update procedure (step 607) following. The microcontroller 400 checks whether an encoded file eFich.S # authorization of use already exists for the software in question numbered S #. In this case, it proceeds to its modification by increasing the value of the L # .S # field in the corresponding Fich.S # file, of the value of NL. In the case where the user would have acquired a time-dependent authorization, of course updates on the corresponding fields are carried out in the file Fich.S #. For the understanding of the present invention, certain obvious point are implied.
If there is no corresponding Fich.S # file, a new Fich.S # file is created. So, according to the embodiment of the present invention, the microcontroller 400 of the CL card creates the file Fich.S # by filling in the following fields of the new file: S #, L # .S #, ID.c serial number of the CL card in question, kEL.S #, kX.S #. The values of DR.S # and DP.S # are initialized by the value of the current time and date. The DU.S # and “number” fields software execution »
obviously take the value zero. The Misc field is used to store values linked to needs possible to define additional information fields. Misc is initially zero.
L # .S # takes the value of NL.
According to particular embodiments not described, a user can directly connect to the dSVR server to purchase licenses when aSVR has communicated the value of kX.S # of software numbered S # protected according to the present invention. This variant allows to decentralize the sale of licenses.
Given the format of the Fich.S # files and its coded form eFich.S #, only a CL card given and numbered ID.c can use the Fich.S # files corresponding to ID.c According to the embodiment of the present invention, we consider software, denoted LD, having undergone protection procedure according to the present invention. Of course, explanations that follow are valid for any software protected according to the present invention. For allow an explanation, we consider its use in case the host computer is connected to a LCL reader via a Ethernet type network, in TCP / IP. This is the case for context 40. The DRV driver previously cited allows communication with LCL in relation to the TCP / IP protocol. According to realization of the present invention, the TCP / IP layer is understood in the proposals of communication between the DRV driver program and the LCL reader in question.
According to particular embodiments not described, but illustrated by the figure 4, several LCL may be present on the network. However, these organizations do not don't change them features of the present invention.
According to the embodiment of the present invention, on obtaining one or multiple authorizations) use of LD software (user licenses), LD can then be executed.
Thus, when launching the LD software on a host computer, the FFo function is executed in first. In general, according to the embodiment of the present invention, all FF functions;
all perform a common procedure: loading eF; to LCL.
__ ~ _ ~

According to the embodiment of the present invention, when the LD software calls a function FF data; it transmits it by passing parameters using for example the system stack the host computer, parameter information, noted PARAM, used directly and / or indirectly during the possible execution of the function F; corresponding to FF ;. Then FF;
loads the content of the eF file into memory; previously described. Then, FF;
calls (in the sense of a call of computer programs) the DRV driver in order to communicate the information PARAM and the memory address where eF is located. This information is then sent to LCL at through the network considered. Additional parameters can be added by a function FF; in the PARAM parameters. PARAM therefore contains in particular information related to the current time in the computer executing said FF function ;. II
also contains an identifier unique representing this host computer (for example the IP address of this computer on the network which is provided by the operating system of this computer) and the S # series of software corresponding to said FF function ;. Of course, in the case of a reader directly connected to a computer (context 30 and 20), there are no problems unique identifiers. So, we note the unique identifier of the IDIP computer. This variable is used by the microcontroller 100 the LCL reader to manage the use of software according to workstations computers. Good of course, choosing an IP address for the possible values of the variable IDIP only concerns the present achievement. In other embodiments, IDIP may be otherwise defined.
Thus, according to the embodiment of the present invention, when the reader 100 microcontroller LCL will have finished processing the information received and in particular the execution of the function F; corresponding, the results obtained are then transported again to said host computer to through the network considered. Upon receipt, DRV returns the results to FF; who returns them to LD software. If the CL card that is connected to the LCL reader does not have of licenses of use for LD software, then LCL will not return results but a message telling FF; to close the execution of the LD software. A closing execution may be given to FF; in other situation described later. Thus, the execution of functions F; by LCL reader creates physical dependence on LD software with LCL.
Thus, according to the embodiment of the present invention, at the start of the launch of the LD software, the FFo function associated with LD is executed. During the execution of associated FFo LD software audit none other FF type function; associated with LD should not be executed. Of Additional Information will be given later. FFo sends eFo, the current time indicated by the computer running FFo, execution parameters PAR.AM of the function Fo, the value S #
associated with LD software.
On arrival of the results calculated by the microcontroller 100 of LCL, FFo consider two types of results. The first type concerns the results linked to the execution of Fo (Fo must be a function complicated so that LD software is very dependent on it) in the microcontroller 100.
Since these results are not error messages, these results returned to LD software to continue running LD. The second type concerns a hour Htop by _28_ report to the clock of said computer running LD software. This time indication matches at the next moment when FFo must be launched by the LD software.
In addition, the order in which the other FF functions; are called, is not predictable because it depends on the use of LD.
According to the embodiment of the present invention, the execution of FFa is voluntarily Long, from about 1 second.
In addition, at Htop time, if FFo is not executed, then LCL considers that La session of execution associated with said LD software which is to launch FFo is closed. This condition allows LCL to decrease its counter of licenses used on the network compared to LD.
Of course, exceeding the number of licenses does not concern software which are used with an isolated computer and connected directly by an I / O port to an LCL
suitable for this port.
In addition, when performing other FF functions; for i different from 0 by LD software, FF; first check if the FFo function associated with LD is not in progress of execution. Without an ongoing execution of FFo, FF; for i different from 0, send eF ;, S #, the settings execution of F; to LCL via DRV. When the LCL reader has finished treatment of eF;
accompanied by its parameters, the results are returned to FF ;. FF; return then these results at LD software. If an error message is received, running the LD software stop. Contrary to software protection systems that use checks from codes, software protected according to the present invention, have essential protection compared to the difficulty in being able to find a function equivalent to the functions of F;
used.
According to the embodiment of the present invention, taking into account the processor CPUl, the system operating system of microcontroller 100 is a multitasking system in order to ability to process multiple use of protected software according to the present invention at the same time.
The realization of this operating system refers to multitasking system standards existing regarding 80386 processors from Intel. In addition, the security of the software protection according to the present invention, is based in particular on the execution of a single main program at the times by processor CPU2.
According to the embodiment of the present invention, upon complete reception of a package of information, CPU1 loads them into the DRAM memory 109. In the case of data (corresponding to a given software numbered S #) of the eF type; and parameters associated with eF ;, the The following test list is carried out: i is equal to 0 701, eF; corresponds to a numbered software S # which has already successfully executed FFo once 702, the time indicated by the clock 104 is equal to the hour Htop (previously defined value corresponding to the software numbered S # which has in this condition already executed once FFo successfully) expressed in relation to clock time 104 with an error of more or less two seconds (test 703 or 705), the number (noted NL.S #) current of licenses used (corresponding to software numbered S #) increased by 1 is strictly greater than the value L # .S # of the file Fich.S # (corresponding to the software numbered S #) supplied by the CL card (test 704). The elements of this list of tests are noted respectively testl, test2, testa, _._ _.__ _. T_.

WO 99I39Z56! 'CT / FR99 / 00182 test4. The number associated with these tests indicates the order of these tests in the conditions of their achievements. With reference to FIG. 12, the test test 701 corresponds to the start of the analysis tree which is done therefore by considering a given software numbered S #, and a unique identifier IDIP
which is the IP address number of each computer on the network in question. This number so allows associate each software execution session with a computer given from said network.
According to variants of this embodiment, other unique identifier can be directly associated to a session of execution of a software given by the use of an identifier of combined process with the network address of the computer where this process is located. So the present achievement considers the unique identifier associated with an IP address as an example of possible means for identify a computer on said network. So at the start of the tree Figure 12 analysis, the S # and IP information (IDIP) are assumed to be provided by the FF function; with the DRV driver. These two pieces of information are sent to said LCL reader in the packet PARAM information previously described.
According to the embodiment of the present invention, compared to test test4 704, if the result is a false value in the boolean sense, then the new value of NL.S # 709 is that from the old increased by 1, provided that the test2 702 is false and that the testl 701 is true.
Relative to a true value of testa 703, and provided a value true testl tests 701 and test2 702, CPU1 reads the current time from the clock internal 104, for calculate the new value of Htop expressed with respect to the time of the clock associated with the computer running the S # software under the conditions of these tests and the context of these conditions.
The new value of Htop is equal to the old one increased by 5 minutes (by example), depending on the realization of the present invention. This value of 5 minutes is adjusted by so that two or several software having the same S # number and running on computers different, cannot not execute the corresponding FFo function at the same time (keep account of said error of more or less two seconds). This value of S minutes can therefore be replaced by any other value based on the previous sentence. At the end of the testa, a 706 execution of the function Fo takes place.
Compared to a false value of testa 703, and provided a value true tests testl 701 and test2 702, an error message 70? then returned to the execution session of software corresponding to the execution of the FFo function under the conditions of these tests and the context of these conditions. In addition, CPU1 decreases the NL.S # counter by 1 point associated with software with serial number S #. The microcontroller operating system 100 as part of protection of several software at the same time, manages a list of objects referenced by different IDIP identifiers corresponding to all computers on the network who run software protected according to the present invention. This list of objects is established from information from PARAM. The fields of each of these objects are used to record the numbers of S # series of S # numbered software which is executed on the computer whose identifier IDIP corresponds to said IDIP reference of these objects. This object list allows the management of the use of software . T __.

protected according to computers. When NL.S # is decreased by 1 point by report one computer identified by IDIP and which runs the software numbered S # which has caused this decrease, the corresponding IDIP object field that contains the value of S # is deleted. This management allows that a new execution of a software numbered S #
can take place. It is necessary also note that the value of NL.S # is the total of said objects having a field identical to the value of S # in NL.S # notation. So, in return when a 1 point increase of the value of NL.S # takes place, a new field in the IDIP object of said object list is created.
The IDIP object corresponds to the numbered computer mIP which performs the function FF; of S # software.
Said new field then takes the value of S #.
Compared to a true value of test test4 704 and a false value of test test2 702 and a true value of testl 701, an error message 708 is then returned to the execution session software corresponding to the execution of the FFo function under the conditions of these tests and the context of these conditions.
Relative to a true value of testa 705, and provided a value false testl testl 701, CPU1 decreases the NL.S # counter associated with numbered software by 1 point S #. Said list IDIP objects are updated accordingly. An error message 710 is then returned to the software execution session corresponding to the execution of the FFo function in the conditions of these tests and the context of these conditions.
Referring to Figure 12, for a true value of the product (testl 701 and test2 702 and testa 703) in the order of their realization, for a false value of the product (testl 701 and test2 702 and test4 704) in the order of their realization, and for a false value of product (testl 701 and testa 705) in the order of their realization, the result leads to a processing of eF; by CPU1.
Of course, all of these tests are defined in relation to carrying out of this invention to enable the protection functionality of several software at the same time by a single LCL reader. The analysis tree in Figure 12 is simplified at maximum for the sake of clarity of understanding. According to particular embodiments, the test conditions and the context of these tests may vary.
In case of intensive use, a queue is created to make run one at a time functions F; by the processor CPU2. In order to reduce the waiting time, a duration condition authorized for the execution of an F function; data can be set, by example 1/100 of seconds value defined in relation to the calculation speed of the processor CPU2. This duration condition shall be respected by the developer of software protected according to this invention.
According to the embodiment of the present invention, the usage information of a given software numbered S # are provided by the CL card. So when it is needed by relation to the tree analysis, in particular in step 704, the microcontroller 100 performs a request from the card CL. Thus, CPU1 performs in order to execute F ;, a request about numbered software S #, with the CL card connected in the context of this request. In the conditions for success the authentication procedure previously defined between LCL and CL, and under the conditions of Possession of the Fich.S # files associated with the numbered software S # of the context of this request, the microcontroller 400 of the CL card returns to the LCL in a form coded by the kCS key, the file File #. The microcontroller 100 then updates the following fields: DR.S #
(last use) replaced by the current date, DU.S # recalculated, Number of times the software. DR.S # is set up to date with the date and time of the first execution of the FFo function compared to last launch of an execution of the S # software associated with this function.
DU.S # is recalculated with the dynamic value of Htop and the current time indicated by the clock 104 by the time execution of an FF function; corresponding takes place. The "Number" field software execution »
is calculated with respect to the last execution of the software associated with the context of this calculation. It is therefore increased by one point for each new execution. All of these tests is optimized in function of the flow of requests from the various FF functions; executed by software correspondents on the different computers connected on the network with the LCL reader considered in the context of these information updates.
According to the embodiment of the present invention, the values of L # .S #, kEL.S # and kX.S # (others fields of the file concerned can be retained by CPU1 as needed) are memorized in DRAM 109. Modified Fich.S # is then returned to CL in a form coded by kCS. To to prevent acts of piracy, if the CL card is removed while the LCL reader uses the CL card to perform operations relating to the present invention, the LCL reader ends all software execution sessions protected under this invention, by returning them Error message. According to particular embodiments, the devices according to this invention, may not return a message from others, insofar as where files File.S # can be permanently stored in the LCL reader of the same way that that used with the CL card.
Thus, according to the embodiment of the present invention, the value L # .S # prevents to exceed the number of licenses to use protected software according to this invention.
According to the embodiment of the present invention, for the case i = 0, the key kEL.S #
provided by the Fich.S # file is used to decode eFo. CPU1 thus obtains said conditions file of use of the software associated with this eFo. CPU1 compares the value of these different information compared to the associated Fich.S # file. By way of explanation, if the use is fixed relative to a expiration date, said file of conditions of use informs this limit value by sound corresponding field. According to particular embodiments, said conditions file of use may not include all or part of the following fields:
permanent licenses, duration of use, use expires end, number of executions.
According to the embodiment of the present invention, after the success of the data comparison provided by the Fich.S # file with the conditions file (limits) of use decoded by the key kEL.S # and associated with eFo, and always for i = 0, CPU1 also recovers with the key kEL.S # les "byte code »JAVA (JAVA instruction code) of the Fo function.
_ _- _ _._ T__ According to the embodiment of the present invention, for i other than 0, the eF coded data; are decoded using the IcX.S # key filled in by the corresponding Fich.S #.
CPU1 then retrieves the JAVA byte code (instruction code corresponding to the virtual machine JAVA) of the function F ;.
S These instruction codes are then loaded via interface 106 directly in the DRAM 110 using the DMA 107 controller. Via the CPU2 controller, CPUl gives control to CPU2 (PicoJava processor) for the execution of F; whose the settings have been charged beforehand. The watchdog 108 monitors the right operation of CPU2. At the end of the execution of F; by CPU2, the results are retrieved by CPU1 and returned to the computer that sent the eF data ;.
In contexts of use 30 and 20, an LCL reader can be used with a computer personal thanks to a direct connection between their respective USB I / O port.
For these two contexts software protection by the LCL reader is a simplified version of features in network. Consequently, the present description will not bring any Additional Information.
According to particular embodiments, the “duration of use” field of the file terms of use can be used to characterize the use of software demonstrations. Thus, the file of conditions of use fixes in particular conditions of limited use. The file of authorization of uses informs the “
quantity »of use in Classes. The two files combined allow according to the realization of the present invention, of protect software against non-compliance with its conditions of use.
In addition, the format of the conditions of use file is mainly interesting to develop demonstration applications whose use is limited. In this context, a procedure of special protection can be used so that the creation of software protected according to the present invention, can be carried out without passing through the aSVR server, This functionality is interesting to allow in particular to decentralize the software protection according to the present invention. In addition, to initiate such a procedure protection, the choice will be performed using the PGM program.
Compared to the previously described software protection procedure, the F functions;
are now coded with a secret key kLi from said list {lcL; + 1 ~~ + 2 ~ 1 ~ -i + 3 ~~~~~~ + m} ~ which corresponds to the current week during which this special procedure of protection of software is launched. The use of these keys is interesting only for software including the use is limited in time because of the definition of these keys kLi. Of course, the reader LCL performing this procedure will not communicate the value of kLi by compared to his definition. To be distributed, the software thus protected must be accompanied by indications on the week during which this particular protection procedure was performed. So when user wishes to run software protected in this way (by the key kLi), it will not need to contact the aSVR server, because all the information is there on the media registration. However, the use of the software remains dependent on a LCL reader account required encryption. Thus, the user will have immediate access to the software but will not be able to exceed the conditions of use set in the conditions file of use. The realization of the present invention prevents re-use of software including use is limited in the time. Explanations will be given later.
In addition, the present invention relates to a method making the use devices according to the present invention, transparent from a computer point of view by through a program noted PGM which has already been discussed. The PGM program is developed from such that he can allow a user of the devices according to this to perform operations requiring interactivity with these devices. Its use is generally implied in this description. Its role is also to allow a given LCL to connect to a remote computer system using the communication resources of the host computer and of the computer system of this computer.
The PGM program is used in parallel with a DRV driver program. This DRV driver constitutes a communication layer between PGM and a given LCL reader. he ensures the transparency in the use of the LCL reader. The addition of these two items in a computer given is illustrated in figure 2. These two programs fulfill all the features described previously and later. A convention is adopted on procedures interrogation of a given LCL in order to allow this LCL reader to recognize and execute commands that are integrated into the operating system of its microcontroller These commands are defined when building LCL readers.
In return, according to the present invention, PGM can also interpret the information from orders sent by LCL. These commands are essentially, depending on the realization of the present invention, instructions for allowing an LCL to access a remote system.
Thus, according to the convention adopted to communicate with a given LCL reader, of commands are defined in relation to the possibility for LCL readers to connect to aSVR
through available network communication resources for allow by example an update of the internal computer system of the devices according to the present invention or setting the time of the internal clock 104 in the event of malfunction (püe 103 is sold out).
According to the context of use 20 indicated in FIG. 1, a receiver digital radio 22 is connected to the external bus 114 of the microcontroller 100, to allow a given LCL reader receive information directly from the organization that manages the server aSVR. Of course, this receiver will be integrated in the box selected for the use of the reader LCL. It is thus possible send information to all LCL readers in service so that general and / or specific.
In addition, the low consumption of this type of receiver compared to a operation with electric batteries, allows to leave them in permanent operation, even if the LCL reader is off. According to a variant of use of power supply, batteries rechargeable can be used with the radio receiver 22 independently of the power supply LCL
_ __ __...____. ~ ._ (possibly supplied by the local electrical network). Of course, the receiver: has its own memory to store the data received from the transmitter 13 when the reader LCL is off. So the aSVR server can send information like by example the setting the operating system of the LCL reader and / or the CL card by through a transmitter 13.
According to a variant of the operation of LCL readers, a duration condition may be add in addition information concerning the dates of commissioning and end of use (DB.d and DE.D). This condition relates to the use of LCL with the radio receiver 22. So, an LCL reader who would not have received any information from the transmitter 20, will refuse to operate when it is started by a user. A procedure connection on aSVR through the PGM program should be performed in order to recover them information that this LCL reader could have missed due to bad radio reception. This recovery is of course done using the kT.d key to secure communication between aSVF ~ and the LCL player in question.
In addition, in order to send information from the transmitter 13 so that secure, keys previously described kLi secrets are used to encode this information to send by radio to LCL readers. This information is noted MR. In addition, kLi is chosen from so that she corresponds to the week when the information leaves from the transmitter 13. We note eMR the form coded from MR by kLi. By choosing to send the MR information from the Monday following week (starting Monday and ending late Sunday) where this information MR were defined, the same information is sent in repetition following a interval given during the whole week. This ensures that they have been received, and avoid too much connection from LCL to aSVR.
This variant of the present invention has many advantages, because it allows in a first time to securely return the Fich.S # files to the LCL reader corresponding to the purchaser of the software associated with Fich.S #. Of course, transmitter 13 can send specifically information to a given radio receiver 22. This variant allows a purchase without computer connection, but by the user directly at telephone with a welcome human. This variant allows complete separation of the distribution of media of registration containing a given software, of the sale of licenses to use this software given.
In a second step, this variant makes it possible to send information about the loss of a device. Given the storage capacities of the modules of "
Flash disk ", a DiskOnChip circuit not illustrated from the company Msystems is connected with a possible controller on the external bus 114 of the microcontroller 100 to allow the microcontroller 100 to have a storage drive. A 12 megabyte DiskOnChip is chosen according to the realization of the present variant of the invention. According to other variants, a Disc card Flash PCMCIA can be used in place of DiskOnChip. So, upon receipt of the information eMR, the microcontroller 100 decodes eMR using the kLi key for the current week.
Thus, to deactivate a given CL and / or LCL device in relation to their use, a information corresponding to its serial number can be attached. This issue of series is then saved on the DiskOnChip circuit in a file marked ANNUL which is used to store all serial numbers of the devices according to the present invention, which should not no longer be used. According to particular embodiments, with respect to the necessary security against modifications, said number may not be coded when transmitted from transmitter 13.
According to the present invention, a computerized method of authentication and signature by LCL is performed on the ANNUL file. Electronic signature and information from authentication are stored in internal memory 111 of the microcontroller 100. So the microcontroller 100 at each start-up checks if the ANNUL file has not been replaced by a another file in the same format or modified by an unauthorized operation.
This ANNUL file is then used during the authentication procedure between a CL card given and a given LCL reader compared to the procedure previously described. If CL is present a) Dc which is referenced in the ANNUL file, LCL rejects the CL card in question. Of more, at the start of LCL and / or upon receipt of MR information, the 100 microcontroller LCL, checks if its own ID.d is not referenced in the content of MR
and / or CANCEL. If the case presents itself, the microcontroller 100 goes out of service by destroying the content of his memory internal.
Thus, taking into account the implementation of this variant, a CL device or LCL can be taken out of service within a maximum of 1 week.
In addition, according to the embodiment of the present invention, the devices have a use of at maximum 4 years. This duration can be reduced to 2 years. In the context of this duration, in considering a possibility of loss of devices according to this invention, with a volume of 1 million device losses in 2 two years (voluntary losses would be prevented by the price purchase of a new device in case of loss). This volume may seem overdo it. take in account the capabilities of compression methods (50% false), and taking into account the 128 bit size an ID serial number, so it would take approximately and without compression 1 S
megabytes, 8 megabytes with compression of data storage space. Over a period of use two years old devices according to the present invention, the capacity of the DiskOnChip according to the this variant suffices.
For longer service life, more storage capacity large can be taken into account the capacity of the DiskOnChip modules in the current state of art.
In addition, said digital radio receiver, given its capacity to receive information which concerns him only, when purchasing a license software the user can receive by radio the file File.S # (described above) corresponding to buying licenses of software numbered S #. This feature can have a big impact on commercial level (software can be purchased anywhere on the planet without connection). Of course, Fich.S # is __._ .. ~ __._._ ___. _ __ sent in coded form with the kLi key for the current week. According to d ~; s variations of realizations, we can use a kT.d type key for operations of purchase.
The possibility of rejecting the use of a device according to this invention by the rest devices according to the present invention, allows users to be given the possibility of recover part of the contents of their lost CL card.
So, taking into account the file format Fich.S #, the size of this file can be reduced to 66 bytes in a file named rFich.S #, keeping only the fields following: S # of software, mc, L # .S #, kEL.S #, kX.S #. Considering only software whose user has a permanent use license, rFich.S # is sufficient to define the use of these protected software according to the present invention. So with a module of 64 kilobytes memory, you can store at least 990 different software licenses including use can be defined by rFile.S #. According to this new variant, the organization which manages aSVR, provides when buying a CL card a chip card (SmartCard) denoted SC, which can secure data in read and modification. SC is not illustrated. SC has an integrated microcontroller on one silicon wafer, processor, 64-kilobyte Flash memory module, from memory DRAM and OTPEPROM. The memory accesses are controlled by the processor of the microcontroller from SC. This card is a secure chip card. This smart card is used whenever the user legally acquires a new license for one or more uses) permanent {s) protected software according to the present invention. During this acquisition, this card is inserted in the smart card reader which communicates with the reader 100 microcontroller LCL by means of the smart card controller 153. The file rFich.S # will be then copied to the 64-kilobyte Flash memory module of the microcontroller of the card fleas. Of course, the SC smart card internally has a secret key kLi in the same way as the CL card. This key is used during an identification procedure similar to that which has place between LCL reader and the CL card. Changes to the contents of the SC card cannot be performed only by an LCL reader connected to an associated CL card. So for this variant of the realization of the invention, rFich.S # is stored in coded form, denoted erFich.S #, by the kS.c key on the card CL. In addition, given the security properties of smart cards (SmartCard), erFich.S # and thus protected against unauthorized modification or reading. All way this information is protected. In addition, by using the key kS for coded rFich.S #, this card cannot be used than with the CL card where the rFich.S # files come from. Of course, if user bought S # software licenses in addition to those already in its possession CL card, LCL then copies erFich.S # and sends it to the corresponding CL card. The fields of rFich.S #
are updated by relative to the number of newly acquired licenses. The new file erFich.S # obtained then replaces the old one in the internal memory of the microcontroller of the SC card.
So in case of loss, the backup made on the SC smart card can be recover in two steps: purchase of a new CL card, connection to the aSVR server via PGM program.

When connecting to the server, the user communicates by the sound intermediary PGM program, the serial number ID.c of its old CL card (lD.c is a public data cannot be modified: it is displayed in plain text on box 60 of each CL).
Then the user give the serial number of their new CL card. In exchange, aSVR
returns a data which is the coded form of the secret key kS of the lost CL card. This key is coded by the key kT.d the LCL reader on which the new CL card is connected. The acquisition of kS card key CL lost allows you to recover the content of rFich.S # files.
According to the variant of the invention using the radio receiver, the number ID.c CL card lost can be communicated orally by phone. LCL then receives by through her digital radio receiver in a form coded by the kLi key of the week current, the kS key of the lost CL card and corresponding to said ID.c number of the lost card.
The acquisition of the key kS of the lost CL card allows to recover the contents of the files rFile.S #.
On the other hand, aSVR launches a procedure to deactivate the use of the card lost in sending according to the variant of the invention described above, the number ID.c of the lost card to all LCL readers.
According to another variant of the invention, the storage of Fich.S # files can be done by the LCL reader following security conditions similar to CL card operation storage of these files. The Fich.S # files will then be stored on media external recording planned for this storage. We can use for example a DiskOnChip.
The files stored on this medium are protected by the kS.d key of the player LCL matches. In this variant, the key kS.d is a secret key written in the memory internal 111 during the factory programming of the microcontroller 100. Thus when one or more software licenses are moved to the LCL reader, access to protected software according to the present invention, and associated with this LCL reader can be performed regardless of the presence a CL card. This allows use by anyone who can access the computer on which said LCL player is connected. Of course, when moving licenses from card software CL, the information will be updated in the SC smart card by forcing the connection of the SC chip card corresponding to this CL card on the appropriate reader of the LCL reader. for example when two licenses of software numbered S # are moved from the CL card to an LCL reader, the content of the eFich.S # file on the CL card and the content of the file erFich.S # of smart cards SC will be modified accordingly in order to write a file of uses of software at the LCL reader. In this new feature of the LCL reader, a card chips of the same type that SC must be associated with each LCL reader to allow a backup files Fich.S # relating to licenses for the permanent use of software.
So this smart card should be inserted immediately after moving the licenses uses of the CL card to the LCL reader to validate the transfer. In view of the fact that the user authorizations software copied to the LCL player can be transferred by a reverse operation to that which has just been described to a new CL card, it is therefore possible to move permission use of software protected according to the present invention with a CL card to another card CL. The respective SC chip cards of these two CL cards will be fine heard updates automatically.
In addition, compared to said possibility to change the CompactFlash card on a CL card, and S in relation to authorizations to use software in relation to limited use, a eTPS file is present on each CompactFlash card that is used by a given CL card and numbered ID.c. This file must be present on all CompactFlash cards used by said CL card. Otherwise, the CL card does not work. Of plus, eTPS is the form coded from the TPS file which contains the ID.c number on the first line, then all serial numbers of S # software acquired according to the present invention, by the user of this CL card. So a user will not be able to circumvent the limits of use of a software limited use by report for example to the time or the number of executions, by changing the card CompactFlash.
This restriction applies according to the embodiment of the present invention, for example on free software.
Thus according to obvious variant embodiments which will not be described (this description contributes nothing to the understanding and realization of this invention), in relation to its information protection capacity against any modifications, the CL card can be used for non-modifiable public information storage such as the identity of a person. These informations can be viewed through the user interface represented by the program PGM. The CL card can, in fact given its large storage capacity allows to store programs and / or counters relating to a given value, secure way against unauthorized modifications and / or readings according to a given criterion.
On the other side, LCL
provides a secure way to allow these programs to run and / or the processing of these counters relative to a given value. The microcontroller 100 is physically protected against so-called computer virus programs. We can thus consider defining Ie Misc field of Fich.S # files by program codes executable by the CPU2 processor microcontroller 100 or by loyalty counters representing the number of software purchased by the user from a given software designer, so to allow corresponding commercial operations. Program codes possibly added in the Misc field can be used to modify the behavior of said functions F; during their execution by the LCL reader, in order to make pirating almost impossible software corresponds while trying to go back to function F; by monitoring inputs and outputs of data at the level of calls to FF functions ;. It should be remembered that only the coded form eF; of functions F; are accessible by the user.
According to the present invention, the use of an integrated circuit (the microcontroller 100) physically and logically protected against computer virus attacks and against readings and / or modifications of data contained in the circuit, allows a very high level of software protection security. Given the peripherals of communications that can .._ _____- 7_ _ WO 99 / 3925b PCT / FR99 / 00182 use such a circuit, the devices according to the present invention, no longer appears as a device prohibitive surveillance, but a real tool actively participating in the use of software in particular by the fact that the present invention makes it possible to recover in license security lost. Indeed, the present invention makes it possible to make a tool for software protection, S often decorative in appearance due to the time it is actually used, into a tool that the user can use in his daily life by his ability to secure data storage and program execution. So the present invention is a new tool protective software that allows software distribution on the one hand independently of selling their right of use, and on the other hand a free development of protected software according to this invention. According to the present invention, this separation has a large cost consequence necessary to protect software. Indeed, the use of a single device according to this invention, for the protection of several software regardless of software designers, allows to distribute the cost of a device according to the present invention on all the designers of software, so that the price of a single appweil according to the present invention, become weak and affordable for the user.
In addition, said separation allows according to the present invention, the sale of means of software protections regardless of software using these means for protection.
The power of the present invention in terms of the security used, allows given its separate sale of the software product, a commercial operation related to other operations. These operations can be operations which involves presenting confidential information that the user cannot modify or falsify. It can therefore be used as a tool allowing access to a given system. Thus, the present invention is a means of protecting software that allows functionality parallel to its use. These features will consequence the decline of the cost of the devices according to the present invention and the drop in the cost of software protection given. The software protection according to the present invention becomes by therefore a system interesting for small and large software productions. The devices according to this invention are susceptible to industrialization compared to the world of software industry and their protection.
Of course, the invention is not limited to the embodiments which to be described and represented. We can make many modifications in detail without going outside for that part of the invention.

Claims

Claim

1. System for simultaneous protection of multiple software from different software developers against non-compliance with the terms of use fixed by these software designers, characterized in that it comprises in combination - a reader (LCL) comprising at least one communication peripheral (network, port I/O) creating an upper communication layer allowing the exchange of data with protected software, a one-time programmable microcontroller (100) who integrates on a single electronic entity two parts (130, 120) separated by an interface (106) - a portable device (CL) of the card type intended for the storage of a large number authorizations to use protected software comprising a module recording removable high storage capacity, and a secure microcontroller (400) against all unauthorized intrusions into its internal circuits.

2. System according to claim 1 characterized in that the part (130) of the microcontroller (100) comprises at least one non-volatile memory module (111), a module of memories volatiles (109), a serial I/O port (151), an internal real-time clock (104) and a processor master (CPU1).

3. System according to any one of the preceding claims characterized in that the part (120) of the microcontroller (100) includes at least one memory module volatile (110) and a slave processor (CPU2).

4. System according to any one of the preceding claims characterized in that the microcontroller (100) physically and logically secures on the one hand its memory space internal against unauthorized reading and/or modification, and on the other hand the execution of programs within the memory (110) with respect to the possibility for a given program, executed in this memory space to extract data from the microcontroller (100) present before running this program.

5. System according to any one of the preceding claims, characterized in that the microcontroller (400) comprises at least one OTPEPROM memory module (407) Where equivalent, a DRAM dynamic memory module (107) or equivalent, and a processor (CPU).

6. System according to any one of the preceding claims characterized in that the reader includes an over-the-air receiver to enable purchase operations out of line rights use of protected software, update of microcontrollers (100, 440), or administration of the reader (LCL) and the portable device (CL).

7. Systems according to any one of the preceding claims characterized in that the reader includes a communication device for connection and a central system remote to allow purchase operations of rights of use of protected software, updating update of microcontrollers (100, 400), or reader administration (LCL) and of the portable device (CL).

8. System according to any one of the preceding claims, characterized in that the microcontroller is secured against any physical and/or logical attack and remember at least one series of codes and digital keys, used to effect a transmission secure information for the transfer of a right to use protected software of the device portable (CL) to another reader (LCL) or other portable devices (CL).

9. System according to any one of the preceding claims, characterized in that he includes an external read-safe backup device and/or changes unauthorized.