FR2852415A1 - Key type storage medium for controlling access to data and/or software, has microcontroller connected with reading device to securitize access to data and software, and ROM with files to store data and software that are to be securitized - Google Patents

Abstract

The medium (10) has a microcontroller (12) connected with a reading device (2) for securitizing access to data and software. An electrically erasable programmable ROM (EEPROM) (14) comprises group of files arranged to store the data and software that are to be securitized. A pair of Schottky diodes powers a latch (13) upon receiving a selection signal from a host personal computer (PC). An independent claim is also included for a process for controlling the access to data and use of computer associated to a support key.

Description

<Desc / Clms Page number 1>

KEY TYPE MEDIUM, CONTROL OF ACCESS TO DATA AND / OR SOFTWARE, AND CORRESPONDING METHOD
The present invention relates to a key type support comprising a read / write memory and means for securing access to data and / or software, capable of being connected to a reader device.

 It also relates to a method of controlling access to data and / or the use of software associated with a key type support.

 It finds a particularly important application although not exclusive in the field of copy protection of software used on microcomputers.

 Methods of protecting software used on a computer, which consists of marking the computer by means of a complementary electronic device called a key, are already known.

 The program or software, during its execution, checks for the presence of this key constituted by an electronic circuit that returns codes when it is requested.

 This circuit can be housed directly in one of the expansion slots of the computer, or more simply connect to one of the external sockets or ports, for example that of the printer without disturbing the operation of this last.

 We can copy the software at will. This system, which has been further improved by making keys directly programmable through read / write non-volatile memory, is by far the most efficient.

<Desc / Clms Page number 2>

 However, it has a number of disadvantages.

 Indeed, the data and / or software that is currently accessible in a secure way by key on a computer are never completely inaccessible to a clever hacker, who can successfully hijack the used codes and / or simulate them.

 The present invention aims to provide a key and a method of securing access to data and / or software that better than those previously known to the requirements of the practice, in particular in that it makes it possible to overcome the disadvantages above-mentioned, and in that it allows by simplified installation procedures to no longer be concerned about the device on which the application will work.

 With the invention, the programmer will therefore allow or not access to secure data or the operation of the protected software in an optimized manner, which has a particularly advantageous technical result, at a time when piracy of data or software is unfortunately in recrudescence.

 For this purpose, the invention notably proposes a key-type support comprising a read / write memory and means for securing access to data and / or software adapted to be connected to a reader device, characterized in that the memory comprises at least one specific file arranged to at least partially store said data and / or said software to be secured.

<Desc / Clms Page number 3>

 By storing the data to be secured and / or the software whose use must be controlled inside the key itself, which seems surprising, it increases the security and the hacker can have access to it only by entering the key itself, which is almost impossible because of the existence of the security means themselves also present in the key.

 In advantageous embodiments, one and / or the other of the following provisions is also used: the security means comprise means of identification of the user arranged to block the use of the all other files stored in the key in case of misidentification; the means arranged to block the use of all the other files allow the erasure of said files; the security means comprise at least one group of several files arranged to control the level of security of the secure data stored in the specific file attached to said group in the memory of said medium; the group of several files includes a read password file, a write password file, and an access attempt counter file; - The access attempt counter is arranged to block access to the corresponding file after n unsuccessful attempts to password read and / or write;

<Desc / Clms Page number 4>

 - Access to the file in the mode concerned is definitively impossible after three unsuccessful attempts.

 The invention also relates to a method for controlling the access to data and / or the use of software associated with a key type support, characterized in that at least part of said data is stored and / or software in at least one specific data file of the key itself.

 In an advantageous embodiment, the user is identified and the use of all the other files stored in the key is blocked in the event of misidentification.

 Advantageously secures access to said specific file of data by storing security information in at least one group of several files arranged to control the level of security of said secure data stored in said file.

 In another embodiment, the access to the data is secured by a read password and a write password, which are compared with words entered in a file called the attempt counter.

 Advantageously, access to the corresponding file is blocked after n unsuccessful attempts of password reading and / or writing.

 The invention will be better understood on reading the description of the embodiments given hereinafter by way of nonlimiting example, and also referring to various tables.

<Desc / Clms Page number 5>

The description refers to the accompanying drawings, in which:
Figure 1 is a schematic perspective view of a microcomputer equipped with a key according to the invention connected to a USB port.

 Figure 2 is a perspective view of the key of Figure 1, the protective housing has been removed.

 Figure 3 is a block diagram of an electronic key according to one embodiment of the invention.

 Fig. 4 is a diagram showing the mapping structure of securing file groups and corresponding data files used in one embodiment of the invention.

 FIG. 1 shows a microcomputer 1 comprising a housing 2 and a screen 3.

 The case is equipped with a USB 4 port.

 According to the embodiment of the invention more particularly described here, the microcomputer 1 comprises a key 5, plugged into the USB port 4.

 With reference to FIG. 2, the key 5 comprises a circuit 6 provided with a microcontroller 7, for example a PIC 16C765 manufactured by the American company MICROCHIP.

 Such a microcontroller 7 is suitable, for example, with a slight adaptation, to the IEEE 1284 protocol used in the embodiment of the invention more particularly described here.

 The circuit 6 also includes an EEPROM 8 for example of 32 kilo octets which will allow the storage of the security and data files and a plug 9 connection with the USB port.

<Desc / Clms Page number 6>

 More specifically, with reference to FIG. 3, there is shown a block diagram of a circuit 10 according to another embodiment of the invention.

 It comprises a housing 11 (broken line), a microcontroller 12, a circuit 13 called latch which allows the operation of the key in transparent mode of the type known in the Anglo-Saxon language under the name Daisy chaining, an EEPROM 14 compatible I2C for example of 32 kilobytes, two schottky diodes 15 for supplying the circuit with at least one signal 16 select or init from the host PC (not shown), a set of component 17 for generating the clock for example a frequency of 6Mhz, two DB25 connectors, one of which is intended to be connected on the host side and the other of a so-called pass-through side, allowing the passage through the key in a transparent manner, three filtering capacitors 19, and one set 20 of five contacts (represented by a dash) allowing the in-situ programming of the key during its production.

 In the embodiment more particularly described here, it is intended to operate in so-called Daisy Chain mode and EPP protocol without addresses. The key is always configured in slave mode, that is, it receives all its commands through the physical interface.

 It also receives the read or write commands on the bus 21 considered with the ad hoc protocol exchange.

 We will now describe more precisely the microcontroller 12. It contains the program of the key and in particular a specific area for

<Desc / Clms Page number 7>

 IDM startup ID). This IDM zone has for example a size of 42 bytes and controls the files listed in Table 1 below.

The abbreviation MdP means Password, E being for Writing and L for Reading. We note that here are provided builder, distributor and publisher passwords.

<Tb>
<Tb>

<SEP> Structure of <SEP> IDM
<tb> P / S / U <SEP> xxx <SEP> (2 <SEP> bytes)
<tb> Date <SEP> of <SEP> manufacture <SEP> (2 <SEP> bytes)
<tb> N of <SEP> version <SEP> (2 <SEP> bytes)
<tb> Build <SEP> (2 <SEP> bytes)
<tb> Code <SEP> country <SEP> (2 <SEP> bytes)
<tb> Distributor <SEP> (1 <SEP> byte)
<tb> N of <SEP><SEP> series of <SEP> fab <SEP> (5 <SEP> bytes)
<tb> N series <SEP> editor <SEP> (4 <SEP> bytes)
<tb> Val <SEP> default <SEP> cptrs <SEP> of <SEP> attempt <SEP> (1 <SEP> byte)
<tb> MEP <SEP> Constructor <SEP> (3 <SEP> bytes)
<tb> MdPL <SEP> Constructor <SEP> (3 <SEP> Bytes)
<tb> MEP <SEP> Distributor <SEP> (3 <SEP> bytes)
<tb> MdPL <SEP> Distributor <SEP> (3 <SEP> Bytes)
<tb> MEP <SEP> Editor <SEP> (3 <SEP> bytes)
<tb> MdPL <SEP> Editor <SEP> (3 <SEP> Bytes)
<tb> Count <SEP> Attempts <SEP> Constructor <SEP> (1 <SEP> byte)
<tb> Count <SEP> Attempts <SEP> E / L <SEP> Distrib. <SEP> (1 <SEP> byte)
<tb> Count <SEP> Attempts <SEP> E / L <SEP> Editor <SEP> (1 <SEP> Byte)
<Tb>

Table 1 The microcontroller also contains a RAM memory that stores variables and a buffer buffer for the proper functioning of the system.

<Desc / Clms Page number 8>

The available space is for example 200 bytes. In a known manner, the organization (mapping) of the RAM memory is generated after compilation of the program written for the application.

 The read / write memory 14, called external memory, is composed of an EEPROM circuit of the 24LCxx type.

 The number xx is the one that gives the size of the memory according to the desired characteristics.

 It is I2C compatible.

 The mapping of the EEPROM memory 12 is also specified with reference to FIG. 4.

It is planned to manage this memory as a mini disk for example structured as follows:
In the total size of the memory, n zones of 64 bytes or cluster 64 are cut out.

More specifically, the memory 12 is structured in n files 200,201, 202,203, ..., 20i ..., 20n of 128 bytes each, ie each time two clusters ~ 64 minimum: 200 ', 200 "; ... 20i ', 20i' ', the first file 200 (BOOT sector) being non-erasable.

 The BOOT 200 sector of xx bytes more precisely comprises a system BOOT zone 200 'of x bytes, at address 0x000 variable according to the memory size.

 It also includes a protected area 200 '' x bytes, which contains the copy of the IDM registered in the microcontroller (see table 1), with three levels of protection depending on the type of access (Manufacturers, Distributors, Editors) .

 The BOOT sector will be detailed below:

<Desc / Clms Page number 9>

Each file 201,202, etc., is, for its part, made up of two clusters of 64 bytes or more (a cluster for the head and a cluster for the body). The management of these files is for example performed in known manner by routines contained in the system kernel program stored in the microcontroller of the key.

 The body 201 '', ... 20i '' is strictly reserved for the encrypted data protected in writing and / or reading according to the invention.

The header 201 ', 20i', is, for example, in accordance with Table 2 below, the columns Con, Dis and Edi meaning Manufacturer, Distributor, and Publisher.

<Tb>
<Tb>

Variable <SEP> NO <SE> NO <SEP> Con <SEP> Dis <SEP> Edi <SEP> Adr
<tb> N File <SEP> Number <SEP> of <SEP> file <SEP> Unique <SEP> in <SEP> 1 <SEP> 1 <SEP>#<SEP>#<SEP>#<SEP> 0x00
<tb> the <SEP> key <SEP>
<tb> FileName <SEP> Name <SEP> of <SEP> file <SEP> Unique <SEP> in <SEP><SEP> 8 <SEP> 9 <SEP>#<SEP>#<SEP>#<SEP> 0x01
<tb> key
<tb> ExtFile <SEP><SEP> Extension <SEP> File <SEP> 3 <SEP> 12 <SEP>#<SEP>#<SEP>#<SEP> 0x09
<tb> TalFile <SEP><SEP><SEP> Size <SEP> File <SEP> Number of <SEP> 1 <SEP> 13 <SEP>#<SEP>#<SEP>#<SEP> OxOC
<tb> cluster <SEP> of <SEP> 64 <SEP> Bytes
<tb> DCrFile <SEP> Date <SEP> of <SEP> Creation <SEP> of <SEP> File <SEP> 2 <SEP> 15 <SEP>#<SEP>#<SEP>#<SEP> 0x0D
<tb> DLmFile <SEP> Date <SEP><SEP> Limit <SEP> of <SEP> 2 <SEP> 17 <SEP>#<SEP>#<SEP>#<SEP> OxOF
<tb> file
<tb> NbUsNet <SEP> Number <SEP> of users <SEP> Network <SEP> 2 <SEP> 19 <SEP>#<SEP>#<SEP>#<SEP> 0x11
<tb> CmtUses <SEP> Counter <SEP> of use <SEP> of <SEP> file <SEP> 2 <SEP> 21 <SEP>#<SEP>#<SEP>#<SEP> 0x13
<tb> PWWrite <SEP> Word <SEP> of <SEP> pass <SEP> in <SEP> Write <SEP> of <SEP> 3 <SEP> 24 <SEP> 0x15
<tb> file
<tb> PWRead <SEP> Word <SEP> of <SEP> Pass <SEP> in <SEP> Read <SEP> of <SEP> 3 <SEP> 27 <SEP> 0x18
<tb> file
<tb> SSII <SEP> Code <SEP> SSII <SEP> 1 <SEP> 28 <SEP>#<SEP>#<SEP>#<SEP> 0x1B
<tb> 1 <SEP> 29 <SEP>#<SEP>#<SEP>#<SEP> 0x1 <SEP> C
<Tb>

<Desc / Clms Page number 10>

<Tb>
<tb> 0x1D
<tb> CmtAcFic <SEP> Counter <SEP> Attempt <SEP> Access <SEP> 1 <SEP> 0x1 <SEP> E
<tb> erroneous
<tb> RegEtat <SEP> Registers <SEP> of <SEP> Status <SEP> 1 <SEP> 32 <SEP> 0x1 <SEP> F
<tb> KeyWrite <SEP> Key <SEP> of <SEP> Encryption <SEP> in <SEP> Write <SEP> 16 <SEP> 48
<tb> KeyRead <SEP><SEP>Key><SEP> Encryption <SEP><SEP> Read <SEP> 16 <SEP> 64
<Tb>

Table 2
The sector of BOOT 200 is reserved for the management system of the microcontroller, and has a variable size according to the size EEPROM memory implanted in production.

It contains in the zone of BOOT 200 ', the following registers:
The size of the memory (register 21),
The maximum number of files (register 22),
The number of files created (register 23),
The name and start address of the created files (table 24 of the files)
The BOOT 200 sector also includes the protected area 200 "called extended IDM.

This zone, for example 37 bytes in the embodiment more particularly described here, contains the following registers:
A zone 25 corresponding to the copy of the IDM of the microcontroller (see table 1)
An access zone 26 Constructor,
A zone 27 of access Distributor,
An access zone 28 Editor,
The PIN code register 29,
PIN code 30.

 Note that if we keep the same configuration as that of the microcontroller it is

<Desc / Clms Page number 11>

 then provided two IDM functions, one for the microcontroller and another for the EEPROM to know the two serial numbers, a microcontroller IDM being anyway necessary in case the EEPROM would be destroyed due to a mistake.

 The information given by the clear IDM is as follows, except for the Client Number when it is not initialized.

 # P / S / U # Manufacturing Date # N Version # Build # Country Code # Distributor # Customer Number.

 # Manufacturing serial number.

 The contents and / or the operation of some of the mentioned registers have been specified below, by way of non-limiting examples.

PIN code register 29
In the Flag byte of the register, one can for example adopt the following conventions:
If the Bit7 is 1 the PIN code is requested once, unless a general reset is requested.

 Bits 4-6 represent the number of incorrect entries of the PIN code, ie from 1 to 7 attempts.

 Bits 0-2 are initialized to the same value as Bits 4-6 and represent the maximum number of access attempts with wrong code.

<Desc / Clms Page number 12>

 At each wrong entry this number is decremented.

When it reaches 0 access can only be done by a specific function Constructor.

 However, if the PIN code is entered correctly again, Bits 0-2 will return the value of Bits 4-6.

By default, the entire byte is at 00 (0000 0000)
The PIN code is used in case the user wishes to have confidential access to the data and / or the software only. This is not an additional protection listed Editor.

PIN code 30
In the embodiment more particularly described here, the PIN code comprises two bytes, ie four quartés. Each quarté represents a number ranging from 0 to 9. The PIN code is thus represented on four digits from 0000 to 9999. The Builder can read it and modify it, the Distributor has, meanwhile, no rights and the Publisher can, however, read it and modify it, provided you enter the old PIN.

 The PIN code is unique for the whole key.

 Using the protected software may require PIN confirmation several times. (network case) without affecting the key.

Builder password
The manufacturer password is initialized by the latter and appears only in the microcontroller, never in the EEPROM. All Builder functions use this password. If the password is 0 or FFFF, no manufacturer function should be taken into account, the

<Desc / Clms Page number 13>

 access attempts are then systematically activated.

Distributor Password
The Distributor password is initialized by the manufacturer and, here again, should only appear in the microcontroller and never in the EEPROM.

 All Distributor functions must use this password.

 If the Distributor Password is 0 or FFFF, then no Distributor function has to be taken into account, and the Access Attempt Counter is always activated.

Password Publisher
When the Editor password is initialized by the Builder, a value other than 0000 or FFFF), the latter must appear only in the microcontroller and never in the EEPROM.

 On the other hand, if this word is equal to 0000 or FFFF, the Editor must then use a Master key to initialize the Password Editor in the EEPROM.

 All Editor functions for general management must use this password.

 All access attempt counters are also in the EEPROM.

An embodiment of the protected area 200 "of the EEPROM is shown in Table 3.

<Tb>
<Tb>

<SEP> protected <SEP> zone of <SEP> the eeprom
<tb> P / S / U <SEP> xxx <SEP> (2 <SEP> bytes)
<tb> Date <SEP> of <SEP> manufacture <SEP> (2 <SEP> bytes)
<tb> N of <SEP> version <SEP> (2 <SEP> bytes)
<tb> Build <SEP> (2 <SEP> bytes)
<tb> Code <SEP> country <SEP> (2 <SEP> bytes)
<Tb>

<Desc / Clms Page number 14>

<Tb>
<tb> Distributor <SEP> (1 <SEP> byte)
<tb> N of <SEP><SEP> series of <SEP> fab <SEP> (5 <SEP> bytes)
<tb> N series <SEP> editor <SEP> (4 <SEP> bytes)
<tb> Val <SEP> default <SEP> cptrs <SEP> of <SEP> attempt <SEP> (1 <SEP> byte)
<tb> MEP <SEP> Constructor <SEP> (3 <SEP> bytes)
<tb> MdPL <SEP> Constructor <SEP> (3 <SEP> Bytes)
<tb> MEP <SEP> Distributor <SEP> (3 <SEP> bytes)
<tb> MdPL <SEP> Distributor <SEP> (3 <SEP> Bytes)
<tb> MEP <SEP> Editor <SEP> (3 <SEP> bytes)
<tb> MdPL <SEP> Editor <SEP> (3 <SEP> Bytes)
<tb> Count <SEP> Attempts <SEP> Constructor <SEP> (1 <SEP> byte)
<tb> Count <SEP> Attempts <SEP> E / L <SEP> Distrib. <SEP> (1 <SEP> byte)
<tb> Count <SEP> Attempts <SEP> E / L <SEP> Editor <SEP> (1 <SEP> Byte)
<tb> Reg <SEP> Counter <SEP> code <SEP> pin <SEP> (1 <SEP> byte)
<tb> Code <SEP> pin <SEP> (2 <SEP> bytes)
<Tb>

Table 3
We will now describe an embodiment of the program that makes it possible to implement access control to data and / or software according to the invention.

 The entire software is for example written in C language with a compiler of the type HITHECH software. Certain routines, for reasons of speed, are advantageously written in assembler.

The system kernel
The source files that constitute it are as follows: The mainpara.c module
Its function is to initialize the system.

# Function init ~ pic ~ 16c765 (); The system.c module
This source file includes the following functions:

<Desc / Clms Page number 15>

# Process Function ~ Cde (); # Function Init ~ Idm (); # Written Function ~ BOOT (int, unsigned char); # BOOT function ~ Buff ~ 64 (unsigned char); # Function Gest ~ Tent (); # Idm function (); # Idm function ~ Test (); # Send ~ Err (char); # Ctrl function ~ CodePin (int); # Modify function ~ CodePin (int, char *); # DelogO function; # Function Reading ~ Idm (); The system header file .h
This header file defines the various parameters of the system functions.

The module gestmem.c # Function Raz ~ Buff ~ 64 (unsigned char, unsigned char); # Raz ~ Buff ~ Sys function (unsigned char, unsigned char); # Copy function ~ Mem (unsigned char, unsigned char *, const unsigned char *); # Tfs function ~ Rameeprom (int, unsigned char); # Function Tfs ~ Eepromram (int, unsigned char *); # Buff Buffer Function ~ Adr ~ Mem (const unsigned char *); # Function Adr ~ Mem ~ Buff (unsigned char *); # Buff function Cmp (unsigned char, const unsigned char *, const unsigned char *); # Function Comp ~ 00 ~ FF (unsigned char, unsigned char, unsigned char *); The module decrypt.c # function char Encryption ();
Char function Calc ~ Crc (unsigned char, unsigned char *); The header file gestmem.h This header file defines the different addresses of the EEPROM memory.

<Desc / Clms Page number 16>

#Fonction i2c Lit Chaine Sys(unsigned char, unsigned char*); # Fonction i2c~Ecrit~Chaine~Sys(unsigned char,const unsigned char*); # Fonction i2c~Remplis(char, char ); L'interface au busLPT Le module daisy2.c # Fonction mode~daisy~assigne(); # Fonction mode daisy-select(); Le module mode~epp.c # Fonction Dde~Ecriture(unsigned char,unsigned char*); # Fonction Dde~Lecture(); # Fonction Mode~Epp(); L'interface de commandes
Cette interface de commandes permet le dialogue entre les différents clients de la clé (Constructeurs, Distributeurs, Editeurs, Clients). The module i2c.c # Function unsigned char i2c ~ Lit ~ Octet (void); # Function i2c ~ Written ~ Octet (char); # Function i2c ~ Not ~ Ack (void); # Function i2c ~ Ack (void); # Function i2c ~ Departure (void); # Function i2c ~ Stop (void); # Function i2c ~ Env ~ Adr ~ Written (unsigned chartint); # Function i2c ~ Env ~ Adr ~ Lect (unsigned char, int, unsigned char); # Function i2c ~ Lit ~ String (unsigned char, unsigned char *); # Function i2c ~ Written ~ String (unsigned char, const unsigned char *);

#Function i2c String Sys (unsigned char, unsigned char *); # Function i2c ~ Written ~ String ~ Sys (unsigned char, const unsigned char *); # Function i2c ~ Filled (tank, tank); The interface to the busLPT The module daisy2.c # Function mode ~ daisy ~ assign (); # Function mode daisy-select (); The mode module ~ epp.c # Function Dde ~ Write (unsigned char, unsigned char *); # Dde ~ Play function (); # Function Mode ~ Epp (); The command interface
This command interface allows dialogue between the different key clients (Manufacturers, Distributors, Editors, Customers).

The module cdeedit.c # Function Ident ~ Edit ~ E ~ L (unsigned chartint); # Ident function ~ Codepin (); # Modify function ~ Idm ~ EEPROM (int, unsigned char, # unsigned char *,

<Desc / Clms Page number 17>

# unsigned char *); # Function Cde ~ Written ~ Edit ~ 0 (); # Function Cde ~ Lect ~ Edit ~ BO (); The module cdefich.c # Function Crea ~ File (); # Function Del ~ File (); # Function Search ~ File (char, int); # Function Cde ~ Lect ~ Fich ~ 0 (); # Function Test ~ Regfich (unsigned char *); # Write function ~ File (); # Function Reading ~ File (); # Function Info ~ Dir (); # Modify Function ~ BOOT (); # Function Ident ~ file ~ E (); # Ident function ~ file ~ L (); # Written Function ~ Crea ~ File (); # Written Function ~ Del ~ File (); The module cdessii.c # Function Cde ~ Lect ~ Ssii ~ 0 ();
Various error codes are then provided, corresponding to the following parameters: - Invalid constructor - Invalid distributor IDM - Invalid publisher IDM - Wrenched read-only Writer, read
Distributor, Read Editor, Write
Constructor, Write Distributor and Write Editor.

These codes are returned when a login is done and the corresponding attempt counter is full.

<Desc / Clms Page number 18>

- read-to-read file This code is returned when the status register of the file concerned indicates that the read attempt counter is full - write-burn file This code is returned when the status register of the concerned file indicates that the counter write attempt is full.

- Invalid read password This code is returned when the write password of a file is wrong.

- Invalid write password This code is returned when the password for reading a file is wrong.

- no file This code is returned when the file is not mentioned in the system BOOT sector file table.

 Other codes are provided to specify various errors according to conventional criteria, within the scope of the skilled person.

 We will now examine more precisely the operation and organization of the support according to the embodiment of the invention more particularly described here.

 The medium according to the invention, where the data is stored, can be external and connected to a parallel port, a serial port or a USB port or a chip card reader. It can also be formed by a disk integrated in the computer or more generally the reader.

<Desc / Clms Page number 19>

 Whatever the medium, the APIs are the same, no difference being made between a USB key or another.

 The functions to be used to control media are described below.

 To access a support, you must first identify yourself. The identification consists of giving the support the information it needs to allow the file operations to be performed later. This authentication is done by passwords, encryption keys and protocol verification.

 As we have seen, the media contains # A unique serial number of manufacture: written by the producer of the medium or manufacturer.

 # A unique serial number per publisher: written by the support producer or the publisher who wants to protect themselves.

 # A read password: created by the support producer and according to each of its customers. It allows read access only in the medium.

 # A write password: created by the support producer and according to each of its clients. It allows read and write access to the media.

 # An area reserved for the encryption key: created by the support producer, it is a function of each of its clients. It allows the first access to the support. Over there

<Desc / Clms Page number 20>

 then this encryption key changes each time the content randomly.

 # A PIN code: written by the publisher. This code makes it possible to identify the user who introduces it to access the support.

 # A double access attempt counter. this counter indicates whether an access attempt was made with non-compliant passwords.

 There is one meter for reading and another for writing. After three unsuccessful attempts the counters block the support.

 # An incorrect pin code counter: This counter indicates whether an access attempt was made with an illegal code.

 After three unsuccessful attempts the counters block the system.

 # Number of files created: This entity is managed by the system itself.

 # Number of readable files. managed by the system itself.

 # Size of the memory managed by the producer according to the available memory size.

 # Size of a cluster managed by the producer according to the available memory size.

 # Identification and type of support: managed by the producer according to the type of support.

<Desc / Clms Page number 21>

 # Date of manufacture managed by the producer according to the date of manufacture.

 # Identification of the country managed by the next producer for which country the product is intended.

 # Distributor ID: Managed by the producer.

 # The state register managed by the producer, then completed or modified by the publisher according to his needs.

 Once this first step is reached it is then possible to access the files.

 The possible operations concern two entities: the support or a file in the support.

 The notion of file must be examined here under two different aspects.

 A file is a container for specific data, but it is also a representative of an application (software). As a result, application management is based on files.

 Each file is associated with information that makes it possible to control the level of protection.

 This information, very similar to that needed to access the medium itself, is, by file, in the embodiment more particularly described here, the following: a placeholder for the file name and its suffix is defined when creating the file and allowing identification and access to the latter.

 - A file number: it is unique on a support for a given file. Access by this

<Desc / Clms Page number 22>

 number promotes the search speed of the file on slow-processing media.

- A file size It informs the operating system about the actual size of the file.

- A password in read: it is defined during the creation of the file and allows the access to the file in reading only.

- A password in writing: it is defined during the creation of the file and allows the access to the file in reading and writing.

- A double access attempts counter: these two counters provide information on access attempts made with non-compliant passwords, namely a counter for reading and another for writing.

 After three unsuccessful attempts the counters block the system for accessing the file.

- An expiry date: this date defined during the creation of the file or subsequently using a function provided for this purpose, allows to block the use of the file when it is exceeded. This automatic date control is transparent to the programmer, the date being given by the external system or by a system integrated into the support.

- A maximum usage counter: This maximum number of uses defined when creating the file or subsequently to

<Desc / Clms Page number 23>

 using a function provided for this purpose, it is possible to block the use of the file when this number is reached. This control of maximum number of uses is automatic and transparent for the programmer. The counter is adjusted to each "login" on the file. This operation is optional and it is always possible to unblock the file by a modification function of this counter, as for the expiry date elsewhere.

 A maximum network user counter: This maximum number of network users defined subsequently using a function provided for this purpose, makes it possible to block the use of the file when this number is reached. This is the number of simultaneous connections on the file depending on the type of login. (Requires the network version).

- One Version: Area of eight characters. The content of this field is defined by the programmer, but it allows, if it is desired to authorize the "login" on the file only if the version is greater than or equal to that requested during the "login"
A zone of "build". This eight character field is a complement of the Version.

We can use the Version only or the
Version and the "Build", or neither.

 A set of 64 options. These are indicators, which make it possible to open the

<Desc / Clms Page number 24>

 file only if the indicator is positioned on the requested option.

 - Two 32-bit counters that the programmer can use as he wishes through the functions of initialization, reading and incrementation or decrementation.

 A reserved area ascii. This area is used to store an ascii chain. It has several functions including the identification of a customer or the owner. The file is only open if the zone is the one requested by the user.

 - A reserved area to access a server.

 This field contains the address or name of a server for an automatic connection.

 - A state register. The latter gives information on the nature of the file and the protections that are required.

 All of these areas can be used separately or in many combinations and allow a very complete control of access to a file.

 According to the embodiment of the invention more particularly described here, these accesses are controlled by passwords which are different in reading and writing. It will only be possible to read in the media if the password for reading is the correct one.

 After three attempts, the media will be burned for reading. In the same way, it will only be possible to write to the media if the correct write password is provided.

 Here again, after three unsuccessful attempts, the key is burned in Scripture.

<Desc / Clms Page number 25>

 In one embodiment, it is impossible to de-grill a support.

 In addition to the passwords at the support level, it is also possible, and as we have seen, to activate a control by pin code.

 Access can only be done after checking the pin code. Up to three attempts are still allowed, otherwise the rack will burn.

 Since the read and write passwords are the same for all media in a Publisher, the pin code is used to customize the key-level access level by the pin code.

 So the programmer will be able to define a different pin code by support.

 As we have understood, in addition to the mechanism of passwords to present to access the support, there exists for each file a set of different passwords left to the responsibility of the programmer.

Thus, it is possible to define a read password and a write password (identical or different) for each of the files created in the medium.

 Here again, and for example beyond three attempts to present the passwords, the file will be burned for reading and / or writing.

 In this example, there is no way to undo a file, the only solution is to recreate another file.

 We will now describe as a non-limiting example, in the chosen language C, the general management functions at the key level, the navigation functions in the key list, the functions of exploration of the contents of a key. , the functions of

<Desc / Clms Page number 26>

 file creation and deletion, application-level functions, and file-level functions.

The general management functions at the key level: openKey ~: This function is necessary before any other operation on a key. It does not allow access to a key, but reserves the necessary resources as a result of operations on the key or on the files of the key. closeKey. This function releases the resources allocated by the openKey function. attachToFirstKey. This function is used to search for a particular physical key, either the first key found or a specific key.

The identification of the keys is always done on its serial number whose uniqueness is guaranteed by the manufacturing process. This function makes it possible to perform a key presence test. getSerialNumberKey: This function reads the serial number of the key: It has no access in the key. The returned serial number is the one passed when calling the openKey function, if any, or the one found when running the attachToFirstKey function. setPinKey. This function allows you to enable or disable pin code control for access in the key. The pin code is a numeric value between 1 and 9999. testPinKey. This function is used to test the pin code, if enabled, to allow access in the key.

The navigation functions in the list of keys:

<Desc / Clms Page number 27>

 These functions are only accessible if the openKey function has already been called. They use the characteristics (password and codes) given when calling openKey. firstKey. This function makes it possible to request the calculation of all the keys found on the local workstation, and it returns the number of the first key (number 1) if there is one. nextKey. this function is used to request the next key number if there is one. serialKey: This function reads the serial number of a key at a given position in the list found by findKey.

The functions of exploration of the contents of a key These functions essentially make it possible to read the list of the files contained in a key. findFirstKey: Lets you list the visible files in a key and return the number of the first findNextKey element. This function reads the next file in the file list set by findFirstKey fNameKeyKey. this function returns the file name at a given position.

Functions for creating and deleting files: createFileKey: This function is used to create a file in the key. The file size is definitively set when creating the file deleteFileKey: This function allows you to delete a file in the key.

<Desc / Clms Page number 28>

 formatFileKey: This function deletes all files from the key. This restores it to its original state.

Application-level functions: These functions are called application-level functions because we consider that a file is linked to an application.

In general, the programmer makes an application-level "login", which makes it possible to check the characteristics of the key, and those of a particular file in the key. Many parameters allow to make more or less sophisticated login. mLoginKey: This function allows to make a key "login". On a specific file. It verifies the presence of the file in the key, and checks the limits (only in commercial version), the maximum number of users, the date of validity, and the maximum number of authorized accesses. As a general rule, you must associate one file per application. The file may or may not contain data specific to this application. mLoginKey is the generic function, and it is declined in functions of suffix S, V, 0, VB for respectively: - Signature: Verification that the first 8 bytes of the contents of a file correspond to a signature passed during the "login" - Version: Verification that the file is of a version at least equal to that passed during the "login"

<Desc / Clms Page number 29>

- Option. Verification that an option whose number is passed during the "login", is well positioned - Version + Build: Verification of the version and the Build of value at least equal to that passed during the call of the function of "login""
The suffixes SO, SV, SVB, SVO, SVBO, VO, VB and
VBOs correspond to different combinations of this function.

 LogoutKey. This function frees the connection with the key set by the mLoginKey function, and releases the associated resources. If this function is not called, it will be automatically called when the closeKey function is called.

For a key known by the openKey function, it is possible to make as many "login" application as you want (with success or failure depending on the type of "login" requested). For each of these "login", the allocated resources are stored at the handle of the key. It is possible to browse this list of "login" by functions provided for this purpose. These functions are useful in particular in an application for managing the tracking of key "login".

File Level Functions: The file functions are divided into two groups: Those that do not require

<Desc / Clms Page number 30>

 "login" on the file and those that require a "login" on the key. getEndDateKey: This function reads the expiry date defined for a file. The dates are all coded as universal character strings YYYYMMDD with YYYY the year on 4 digits, MM the month on 2 digits and DD the day on 2 digits. setEndDateKey: This function is used to change the file's expiration date. getNbMaxUseKey: This function reads the maximum number of times a file is used. setNbMaxUseKey: This function allows you to change the maximum number of uses of a file. getFOptKey: This function reads the indicator status of any of the 64 options associated with a file. setFOptKey: This function enables or disables one of the 64 options associated with a file. getVersionKey: This function reads the version string associated with a file. setVersionKey: This function is used to modify the version string associated with a file. setNetUsersKey: This function is used to define the number of simultaneous users who access a file (Network version: consult the corresponding documentation). getNetUsersKey: This function is used to read the number of simultaneous users who access a file (Network version: consult the corresponding documentation).

<Desc / Clms Page number 31>

 lockFileKey: This function makes it possible to block a file in writing: Once executed, it will not be possible anymore to write in a file, nor even to modify the zones associated with the file (version, build, option, deadline, etc .. ..). This operation is irreversible.

Once a "login" application is done, the file concerned is considered open, and it is then possible to write or read information according to certain access conditions (write rights for example). writeKey. This function makes it possible to write a buffer in a file of the key. readKey: This function reads the contents of a key file. getCounterKey: This function reads the value of one of the two 32-bit counters associated with a file. setCounterKey: This function initializes the value of one of the two 32-bit counters associated with a file. incCounterKey: This function increments (or decrements) the value of one of the two 32-bit counters associated with a file.

 As is obvious and as also follows from the above, the present invention is not limited to the embodiments more particularly described. On the contrary, it embraces all the variants and in particular those where only a part of the data to be secured is stored in the key, the rest being present in the computer and / or the reader, which may for example

<Desc / Clms Page number 32>

 be a computer, a DVD player, a video game station or an encrypted signal decoder for satellite television.

Claims (16)

A key type medium (5, 10) including a read / write memory (8, 14) and means (12, 200, 201, ..., 20i) for securing access to data and / or software, adapted to be connected to a device (2) reader, characterized in that the memory (14) comprises at least one specific file (201 '', 202 '', ..., 20i '', ... , 20n '') arranged to at least partially store said data and / or said software to be secured.  2. Support according to claim 1, characterized in that the securing means comprise user identification means arranged to block the use of all other files stored in the key in case of misidentification.  3. Support according to claim 2, characterized in that the means arranged to block the use of all other files allow the erasure of said files.  4. Support according to any one of the preceding claims, characterized in that the securing means comprise at least one group (201 ', 202', ..., 20i ', ..., 20n') of several arranged files. to control the security level of the secure data stored in the specific file (201 '', 202 '', ..., 20i '', ..., 20n '') attached to said group in the memory (14) of said medium (10).  5. Support according to claim 4, characterized in that the group of several files includes a file password reading, a word file. <Desc / Clms Page number 34>  write password, and an access attempt counter file.  6. Support according to claim 5, characterized in that the access attempt counter is arranged to block access to the corresponding file after n unsuccessful attempts to password read and / or write.  7. Support according to claim 6, characterized in that access to the file in the mode concerned is definitively impossible after three unsuccessful attempts.  8. Support according to any one of claims 4 to 7, characterized in that the group of several files further comprises a file expiration date of use and / or a maximum counter file of use.  9. Support according to any one of the preceding claims, characterized in that it is formed by a circuit (5) plug-in on a USB port.  10. Support according to claim 9, characterized in that said circuit comprises a microprocessor (12), an EEPROM (14), a clock (17), and means (18), connection for programming and storage of data and / or software.  11. Support according to any one of claims 1 to 8, characterized in that it is formed by a CDRom.  12. A method of controlling access to data and / or the use of software associated with a support (5, 10) of the key type, characterized in that at least part of said data is stored and / or <Desc / Clms Page number 35>  the program in at least one specific file, (201 '', 202 '', ..., 20i '', ..., 20n '') of data of the key itself.  13. The method as claimed in claim 12, wherein the user of the key is identified and the use of all the other files stored in the key is blocked in the event of misidentification.  14. Method according to any one of claims 12 and 13, characterized in that access to said specific file of data is secured by storing security information in at least one group (201 ', 202', ..., 20i ', ..., 20n') of several files arranged to control the level of security of said secure data stored in said file.  15. Method according to any one of claims 12 and 14, characterized in that secures access to the data by a read password and a write password that is compared with a word introduced in a file said attempt counter.  16. The method of claim 15, characterized in that one blocks access to the corresponding file after n unsuccessful attempts to password read and / or write.