FR2867868A1 - Software and data protection method, involves dynamically dearchiving secret encryption key from sub-keys at each usage of programs/data, and dynamically decrypting protected programs or data by decryption algorithm and secret key - Google Patents

Abstract

The method involves generating a sub-key KP (10) relative to a user and/or a system, and generating a sub-key KE (8) depending on a secret encryption key K (7) and the sub-key KP (10). The secret encryption key is dynamically dearchived from the sub-keys at each usage of programs or data. The protected programs or data are dynamically decrypted in an electrically erasable programmable ROM by a decryption algorithm and the key K (7). Independent claims are also included for the following: (A) an application of a method to the protection and management of rights of the usage of encrypted software functionalities (B) a system for protecting storage units and in particular hard disk implementing a software and data protecting method.

Description

1. Object

  The invention relates to a software and data protection system based on an encryption method which provides a high security in the protection.

  The standard protection systems are easily broken, because whatever the license transfer systems used (keys, activation via the Internet, ...), there is always a test to check if the software has a valid license or not . It is then easy for a hacker to blow the test with a simple fix, rather than trying to break the licensing system itself.

  The invention solves this problem and prevents hackers from accessing the features, even if they are able to break the validity test of the license. This document describes a generic and innovative protection system, as well as specific functionalities for feature extension management (modular software) and content protection (multimedia content in particular).

1.1 Principle of the invention

  The licensed software is stored in an encrypted version on the storage unit of the computer (2). To start the software, a dedicated launcher (3), using a D encryption function, is dynamically executed and decrypts the binary files (1) by loading them directly into the main memory (5) when necessary. The plaintext versions of the binary files (34) are never stored on the storage unit (2).

  FIG. 1 shows the relationships between the encrypted files (1) on the storage unit (2) and the data in the clear in a segment of the central memory (4) of the computer (5).

  1.2 The management of the keys The decryption key (7) K is not permanently registered on the storage unit (2), but can be found from two sub-keys (10) which are relative to a IDP physical identifier 9.

  The subkey KP (10) is closely related to IDP (7), thus dependent on the machine.

  The subkey KE (8) is computed by the software provider, using KP (10) and K (7) KE = g (K, Kp). The load module calculates K = f (Kp, KE The program is designed so that: The software features can only be unlocked with the appropriate key on the appropriate system.

  Unlocked features can not be functional once transferred to another system of the same type or not.

  No sensitive key is stored on the local storage units (2).

  Two key management cases can be distinguished: (1) The software, or binary files, initially installed (1) is the same for each machine.

  (2) The software, or binary files, initially installed (1) is specific to each machine.

  The decision between these two variants will depend on the constraints of the software production and distribution system.

  2. Definitions We will give here a certain number of definitions necessary for the understanding of the described system. Some are general and some are system specific.

  2.1. Physical Identifier In the following, we will consider that a physical system typically a computer, is identified by a unique hardware number, specific to the system and which can not be modified. We will call such a physical identifier number (1).

  2.2. Hash function A hash function is a non-invertible function that generates a fixed-size condensate (or imprint) from any input data of any size. The mathematical properties of such a function must ensure that: The probability that two different inputs give the same condensate is extremely low.

  It is impossible to find the entry from the condensate.

  Hash functions are typically used to verify data integrity.

  2.3. Modular Software Modular architecture software is a software with several features, typically implemented in separate software components, executable independently of each other. On such a system, some features can be completely disabled without affecting the functioning of others.

  2.4. Main Program In a modular architecture, the main program (18) is the software component that will manage all the features. This is the central part of the architecture. It is able to configure, start and stop the various functional modules (1).

  4 2.5. Module In a modular architecture, a module (1) is a part of the system, providing one or more services, and depending only on the main program to function.

  2.6. Extending Software Features A software extension is a modification of an existing software. It typically aims to increase its performance or extend its functionality, ie to add or activate new modules.

  2.7 Keychain The keychain (16) is a virtual structure designed specifically for the protection system. It stores all the necessary information related to the licenses. It is thanks to the virtual porteclef that the system will be able to check if a license is active or not.

  2.8. Launcher As part of our system, we will call launcher module (3), or layer of abstraction, software that is responsible for decrypting the files on the fly (1) and load them in memory (5) to read them or execute them.

  2.9. AES Acronyms: Advanced Encryption Standard CDROM: Compact Disc ROM CPU: Central Processing Unit DES: Data Encryption Standard DVDROM: Digital Versatile Disc ROM EPROM: Erasable Programmable ROM EEPROM: Electrically Erasable Programmable ROM MD5: Message Digest 5 NIC: Network Interface Card PC: Personal Computer PROM: Programmable ROM ROM: Read Only Memory 4o SC: Smart Card SHA1: Secure Hash Algorithm 1 SIM: Subscriber Identity Module SS L: Secure Socket Layer TDES: Triple DES 2.10 List of Figures Modes of Execution of the Invention will be described below, by way of non-limiting examples with reference to the accompanying drawings in which: FIG. 1 is a schematic representation of the relationships between the encrypted files (1) on the storage unit (2) and the data in clear in a segment of the memory (4) central computer (5).

  FIG. 2 is a schematic representation of a plaintext file (34), encrypted by means of a key K (7) and an algorithm C (6) for calculating the encrypted file (1).

  FIG. 3 schematically represents the process of generating a transmission sub-key (8) from a key K (7) defined by a software provider and IDP (9), identifying the client or the machine.

  Figure 4 schematically shows the generation of a key K (7) from the KE (8) and IDP2 (9) elements, and illustrates the decryption of an encrypted file (1) by K (7).

  Figure 5 schematically shows the use of IDPs (9) with K (14) to generate K '(7) and KE (8).

  Figure 6 shows schematically the use of keys and identifiers during an installation with files specific to each machine.

  Figure 7 schematically illustrates the principles of modular software, and license management using a virtual keychain (16).

  Figure 8 is a schematic representation of an exemplary key holder structure (16). The IDENTIFIER field of the function makes it possible to store identifiers (19) of the functionalities / modules. The LICENSE field is used to store license markers (20). FUNCTION SUB-KEY is the field allowing to keep the value of the subkeys (8) which will make it possible to find the key of encryption of the corresponding modules. Finally, the field KEY CONDENSATE makes it possible to store fingerprints (21) of the secret keys. These fingerprints (21) will allow the main program to verify that the subkey is valid.

  Figure 9. schematically shows the installation method for embedded software, this installation is completely controlled by the supplier.

  Figure 10 shows schematically the operation of an installation program: a triple function is used to generate encryption keys (function h, see sections 3.4.et4.2.): Figure 11. represents schematic an example of structure of a virtual keychain.

  FIG. 12 schematically represents the generation of an sub-element (10) K'p from a physical address of the network interface (9) (NIC number). This generation is done by a simple pattern repetition.

  Fig. 13. schematically shows the generation of a ke key sub-key (8) from K'F; (7) and K'p (10). This generation is done by AES encryption.

  Figure 14. schematically shows a system for recovering an encryption key K'F; (7) and deciphering the corresponding module.

  Figure 15. schematically shows a system for checking the validity of a subkey KE (8).

  Figure 16. schematically shows the principle of the security box (29) inserted downstream of a server (31).

  Figure 17. schematically shows the production of series CDs (33) from a master (22).

  Figure 18. schematically shows the generation of K'2 (7) and KE2 (8) from IDP1 (9), IDP2 (9) and K2 (14).

  FIG. 19. schematically shows the generation of KE1 from an identifier IDP2 (9) and a key K, (7). FIG. 20 schematically represents the method of generating the keys K '. (7) and KE (8) from a SIM identifier (9) and a K key (14).

  FIG. 21 schematically shows the hard disk protection system (41) implementing an interface card (42) providing the encryption and decryption functions and a smart card reader (43) enabling user authentication.

  Figure 22 schematically shows the method of generating encryption keys K '(7) and storage KE (8) as part of the hard disk protection system.

  FIG. 23 schematically represents the method of recovering the encryption key K '(7) from the storage key KE (8) contained in the memory (44) and the corresponding smart card (39), as part of the hard disk protection system.

  Fig. 24 schematically shows the physical arrangement of the KE (8) storage memory (44) as part of the hard disk protection system.

  Figure 25 schematically shows the encryption method implemented for the protection of a hard disk (41) already containing data, as part of the hard disk protection system.

  Fig. 26 schematically shows the decryption method used for the de-protection of a protected hard disk (41).

  FIG. 27 schematically represents the concentrator system implemented to use several interface cards (42) and several hard disks (41) with a single chip card reader (43), as part of the protection system. hard drive.

3. Description of the system

  As explained above, the invention can be implemented with a software version (binary files) (1) identical or customized for each user. We will detail the key management methods that will be used in each case. It will also be detailed the system of secure extension of features.

  l0 3.1 Management of keys with identical binaries This method will be used if the production and distribution constraints do not allow a customization of binary files 1 for each copy of the software (typically, the case of large CD-ROMs (33) or DVD-ROM (33)).

  3.1.1 Bit Encryption Binary files (34) are encrypted by the software provider using a K (7) encryption key that will not be passed to the user. Only the encrypted version of the binary files (1) will be provided to the client.

  Figure 2 shows the plaintext file (34), encrypted with the key K (7) and the algorithm C (6) to obtain the encrypted file (1).

  3.1.2 Key Generation Each machine or user has one or more IDP IDs (9). The key encryption / decryption key K (7) is defined by the software provider.

  The encryption key K (7) is then used to generate a key KE (8) dependent on IDP (9) via a function g (35) (typically a symmetric function which would take as input a derivative of K (7) and IDP (9)), which will be transmitted to the user with the encrypted binary files (1).

  Fig. 3 shows the process of generating the transmission subkey (8) from key K (7) defined by the software provider and IDP (9), client or machine identifier.

  3.1.3 Installation process The user runs installation software that copies the encrypted files (1) to the local storage unit (2) of his machine. The software is then installed, but not yet activated: the user can activate the software by asking his KE (8) subkey for the software provider.

  The physical key KP (10) is generated locally by means of IDP (9) and is then combined with KE (8) to find K (7) via the function f (12). Thanks to K (7), the binary files (1) can then be decrypted in memory (5) when this is necessary. This operation must be completely transparent to the user.

  Figure 4 shows how the key K (7) is found from KE (8) and IDP2 (9), and illustrates the decryption of the encrypted file (1) by K (7).

  Advantage of the invention: The unencrypted versions of the files (34) are never sent or stored on the local storage units (2) of the user.

  The encryption / decryption key (7) does not pass through the network.

  The encryption / decryption key (7) is never stored in the local storage unit (2).

  - The user needs to know only KE (8).

  3.2 Key management for machines with custom binaries This method is an improved version of the previous one, but can only be used if the production and delivery constraints allow the customization of the binary files (34) for each copy software (typically, for restricted broadcasts on physical media (CD, DVD ...) or downloading software with a dedicated remote installation server (31)).

  3.2.1 Key Generation Each machine or user has one or more IDP IDs (9). An IDP (9) will be combined with a constant key (14) K, which is chosen by the provider and will remain secret using a function h (15) (typically a hash function, see implementation in 4.2) A key K '(7) will then be generated from IDP (9), K (14) by applying h (15), and which will be used to encrypt the binary files (1). K '(7) is machine dependent since it takes into account IDP (9), the unique identifier of the machine. Since the encryption key (7) is machine-specific, the encrypted files (1) are machine-specific as well.

  The encryption key K '(7) will then be used to generate KE (8), a transmission subkey (dependent on IDP (9) since K' (7) is already dependent on IDP (9)), thanks to a function g (35). KE (8) will be transmitted to the user at the same time as the encrypted bit files (1).

  Figure 5 illustrates the use of IDPs (9) with K (14) to generate K '(7) and KE (8).

  3.2.2 Installation process The installation process must be controlled on the supplier's side.

  Since the installation is done from a server (31) of the provider, the user does not have to know the key K (14). The key point of this installation process is that the user never sees the plaintext version of the binary files (34) since the files are encrypted during the installation process from the Master CD (22) at the factory during the copy, or before the file transfer in the case of a network installation, before being stored, always encrypted, locally on the user machine. Moreover, the key used to encrypt is K '(7), not K (14): the user will never have to know K (14).

  Figure 6 explains how keys and identifiers are used during installation with machine specific files.

  3.2.3 Advantages of the invention - Each copy of each file is encrypted specifically for each machine or user.

  Files in clear (34) are never stored on the local system.

  The decryption key K '(7) is never sent through the network.

  The key K '(7) is never stored locally on the user's machine.

  Key K (14) remains secret and will never be transmitted, stored or recalculated on the client's side.

  The user knows only the subkey KE (8).

  3.2.4 Possible application of protection.

  2867868 11 Restricted release of software or data on physical media.

  Remote Software Installation Server (31) (Network) - Broadcast media over public (typically Internet) or private networks.

  3.3 Secure Extension License Management This section describes the system features for managing modular software license extensions. This aspect is independent of the encryption key management method. Secure extension license management can be used with both key management systems (identical or custom binaries).

  Note: Single license management (for non-modular software) can be considered as a special case with a single module.

  Even though network transfer rates are growing today, they are generally still too low to allow the transfer of large amounts of data in a reasonable amount of time. This problem is even more critical if the data to be transferred must be encrypted: typically, for the transfer of software to private license, the confidentiality of the transaction must be ensured in order to avoid pirated copies.

  The protection method described in section 1. can solve this problem: a software (or a suite of software) will be fully (all modules / features, even optional) stored on the user's machine, and its features will be enabled on demand. Each module (34) is stored in an encrypted version (1) to prevent piracy.

  In addition to the extensions system, this section describes how modules are enabled and how licenses are handled. The solution consists of several functionalities that will make it possible to manage the licenses granted, the activation and the configuration of the various modules / functionalities.

  Several distinct elements are necessary for the operation of the system: - A logical structure called key-ring (16) A main program (18) 2867868 12 Modular (34) and independent functionalities, designed to work with the main program (18).

  Note: The features can be different modules of the same application or different applications (in the second case the operating system will be considered as the main program).

  3.3.1 Installation The installation procedure installs all the optional features even if they are not licensed. All features will be available on the system, but they will be locked. To avoid hacking, the features will be encrypted with a secret key (7), and only the licensed features will be decrypted dynamically during use.

  Figure 7 illustrates the principles of modular software, and license management using the virtual keychain (16).

  3.3.2 Keychain The keychain (16) is a logical structure that stores information about modules and licenses.

  This structure contains fields filled with the identifiers (19) of the functions, the markers (20) of the licenses granted, the sub-keys of the licenses (8) of the modules, as well as the fingerprints (21) of the primary encryption keys. For each feature, the fingerprints (21) of the primary encryption keys are given by default. Subscription keys (8) are only stored when the corresponding licenses are granted. For unvested licenses, the corresponding field will be set to a default value. When a license is granted, the value of subkey (8) will replace the default value, and the license marker (20) will be set to YES.

  Fig. 8 is an example of a key holder structure (16). The IDENTIFIER field of the function makes it possible to store the identifiers (19) of the functionality / module. The LICENSE field is used to store the license tag (20).

    SUB-KEY OF FUNCTION is the field allowing to keep the value of the sub-keys (8) which will allow to find the key of encryption of the corresponding modules. Finally, the field 2867868 13 KEY CONDENSATE makes it possible to store the imprint (21) of the secret key. This footprint (21) will allow the main program to verify that the subkey is valid.

  3.3.3 Extensions When the user wants to extend the functionalities (1) of his system (ie add functionalities), he needs the custom sub-element (8) to unblock the corresponding functions. Since binary files (1) are already stored on the system, very little data transfer is needed.

  The subkeys (8) are generated by the provider (from the encryption key (7) and the unique identifier (9) of the user, and possibly the identifiers of the modules), and transmitted to the user. The user enters the sub-keys (8) by specifying the functionalities (1) that he wants to unlock. Once this information is confirmed, the main program generates a decryption key (7) for each of the subkeys (8). An impression will be extracted from each of these keys (26), to be compared to stored fingerprints (21) in the key holder to verify the validity of the unlocking keys (8).

  Once the keys (7) validated, the key holder (16) will be updated. The markers (20) corresponding to the functionalities (1) will be set to YES. The modules will then be decrypted and started.

  3.3.4 Update (patches) When the binary (34) will have to be updated, the differences between the old binaries and the new binaries will be sent, or available for download. The data includes changes to the encrypted versions of the feature binaries to be updated, as well as the information for the integrity check.

  4. Implementations Here we give concrete examples of implementations for the system described above. We will deal with the cases of implementation of the global system, as well as the implementation of the basic functions.

  4.1 Physical identifier We will distinguish two main types of physical identifier (9): 10 Identifier relating to a machine (typically a computer): it is the easiest to implement because it does not require any proprietary hardware - Identifier relating to a user: this system is more flexible and must allow a customer to use a licensed product on 15 different machines but not simultaneously.

  4.1.1. Machine ID Such an identifier is a unique non-modifiable code (eg serial numbers) implemented on a hardware component. It must be accessible by software, read-only, to enable automatic verification.

  Technically the type of hardware implementation is of great importance: for better reliability, the system must use a truly unmodifiable identifier type ROM or PROM, rather than EPROM, EEPROM or flash.

  Some examples of machine identifier (PC platform): - Physical address of the network card (NIC number) - Serial number of the hard disk Identifier of the microprocessor 4.1.2. User ID This type of identifier will be linked to a user and not to a machine. For optimal security, it may still be a hardware code, but must be portable to allow the user to identify themselves on several separate systems.

  Some examples of user identifier: - Dongle owner: for example PROM + interface (USB, COM, LPT ...) Smart card or magnetic card Product serial number 4.2. Implementing Functions 2867868 15 4.2.1. Encryption / decryption functions Encryption (6) C and decryption (13) D functions can be implemented using any recent (and secure) encryption algorithm.

  In the general description of the system, we use the same key (7) for encryption and decryption, it implies that the algorithm is symmetrical (type DES, triple DES, AES or RC4 for example). This does not constitute in any way a constraint of the system, which can be implemented with asymmetric encryption lo (RSA type for example), provided that an appropriate pair of keys, K0 and KD, are initially generated.

  4.2.2. Key Generation Function The exact implementation of these functions will obviously depend on the choice of encryption / decryption functions, because the format of a key depends on the algorithm used.

  The function i (11), used to generate KP (10), has the sole constraint of being surjective. It can therefore be a simple change of size operation (completion / padding or truncation).

  The functions f (12), used to find K (7), and g (35), used to generate KE (8), can be very simply implemented by means of operators XOR (or exclusive): asked ^ If KE = KP XOR K Then K = KP XOR KE A safer solution is to use for f and g a symmetric encryption algorithm of the DES or AES type, with KP (10) as key: ^ K is set ^ If KE = DESKP (K) Then K = DESKP (KE) (Any symmetric encryptor / decryptor can be used.) - The function h (15), used to generate K '(7), will typically be implemented in two steps: a concatenation of K (14) and KP (10) with possible adaptation of the final size by truncation or completion), then a hashing (15) of the result.

  The hash function (15) may be a standard algorithm 40 such as MD5, or SHA-1 (the latter being more secure): KK = SHA-1 (KKp) 4.3. Global system implementation case We present here four detailed examples of the use of the system described above. 4.3.1. Extension of features on proprietary lo platform This case

  implementation describes a proprietary system (23), hardware platform and embedded software for example, using a modular software architecture (see section 3.3.): the supplier delivers the system (23) with the basic functions enabled, and a p number of advanced functions will be available for later activation using specific keys.

  Each of the optional functionalities is associated with a key KF which will serve as a basis for the generation of the personalized keys (10), in function of the machines and / or the users.

  The key management method used here is that described in section 3.2.

  We will use here a hardware platform of type PC, with the physical address of the network interface (NIC number) as physical identifier (9) IDP1 and IDP2.

  Figure 9. illustrates the installation method for the embedded software, this installation being totally controlled by the supplier.

  The installation CD contains: ^ Binary files of the main program (18) in plain text ^ The optional feature files in clear (34) ^ The basic keys associated with p optional features (14) KF1, KF2É É É É KFPÉ ^ A dedicated installation software comprising a key generator, an encryption module (here AES) and the installation 35 itself.

  We will use here for the encryption the algorithm AES, with keys of 256 bits. The installer is run from the CD. Once launched, it will search the physical address of the network interface (9) of the target machine, and generate the custom encryption keys (10).

  Figure 10. illustrates the operation of the installation program: a triple function is used to generate the encryption keys (function h, see sections 3.4 and 4.2): concatenation of the basic key KF (25) and the 'physical identifier (NIC number) (9) Hashing by SHA-1 256-bit completion (the SHA-1 generated fingerprint is 160 bits, the completion at 256 can be done by partially repeating the pattern) each optional feature, a key (7) will be generated (each of these keys will be specific to the function and the machine) and the corresponding binary files (34) will be encrypted and copied to the hard disk of the target machine. The binary files of the main program (18) are installed directly without encryption.

  In order to manage the separate activation of the different modules, a virtual key ring (16) (see section 3.3.) Is implemented on the target machine. It stores for each activated feature a subkey (8) relating to the function and the machine. It also stores a fingerprint (21) (hash code) of the encryption key for each feature (active or not). A flag (8) indicates for each functionality if it is activated or not.

  Figure 11. illustrates the structure of the virtual key ring.

  Each subkey (8) KE is generated as follows: A subkey (10) K'F of 32 bytes (256 bits) is generated from the 6 bytes of the NIC number (9).

  The subkey KE (8) is then generated by AES encryption of the key KIF; (7) corresponding, with KIF (10) as encryption key.

  Figure 12 illustrates the generation of the subkey (10) K'P from the physical address of the network interface (9) (NIC number). This generation is done by a simple pattern repetition.

  Figure 13 illustrates the generation of the key subkey KE (8) from K'Fj (7) and K'P (10). This generation is done by AES encryption.

  2867868 18 The system comes with all the features available but only those chosen by the customer are enabled. When the user executes an active function, the launcher uses the subkey KE (8) stored in the keychain (16) to find the corresponding key KF (7) (K'Fi = AESDecrypt (Kip) (K ') Ej)) and decrypts the binary files (1) in memory (5) to execute them.

  When the user wishes to activate a new feature, the provider sends him the corresponding KE (8) subkey (by phone, mail, e-mail ... etc.). This subkey (8) is entered manually by the user on the system, which will verify its validity using the imprint (21) stored in the key holder (16) (the software checks that SHA1 ( AESDecrypt (Kip) (K'Ei)) = stored fingerprint). If the subkey KE (8) is valid, it is added to the keychain (16) and the activation flag (20) of the corresponding function is asserted.

  The transmission of the subkey KE (8) poses no problem and does not require any particular security, because the subkey (8) is system-specific and can not be exploited by any other user.

  If a module (1) is decrypted with an incorrect key, it can not be used naturally. The validity check of KE (8) thus serves more to prevent seizure errors than to avoid hacking.

  Figure 14. illustrates the system of recovery of the encryption key K'Fi (7) and decryption of the corresponding module.

  Figure 15. illustrates the verification system of the validity of the subkey KE (8).

  4.3.2. Secure Software Installation Server The purpose of this implementation is to provide strong protection against hacking, for downloadable software on the network (typically over the Internet): the secure remote installation server (31) allows the provider provide each client with an encrypted version specifically according to the method described in section 3.2.

  A dedicated appliance-type box (29) may be used between the server (31) and the clients (27) to secure the pre-existing installation servers.

  Figure 16. illustrates the principle of the security box (29) inserted downstream of the server (31).

  A basic key K (17) is associated with each downloadable software. When a client requests the installation of a software it receives a dedicated download / installation program. This program will download the necessary files and install them on the client system. Once launched, it will retrieve the identifier (s) specific to the machine and / or the user (9) (IDP1 and IDP2) and send them to the appliance (29) (secure transaction, SSL for example) which uses for key generation: the appliance calculates K '(7) from K (14) and IDP, (9) (function h 15), then generates the transmission subkey KE (8) from K '(7) and IDP2 (9) (function g 12) and transmits it to the client machine (27). A request (28) is then sent to the appliance for the actual installation of the software. The server will send the plaintext files (34) to the appliance (29) which will encrypt them dynamically (K 'key (7), AES algorithm) to transmit them to the client machine (27) where the encrypted software is finally installed.

  When the client uses the software, the launcher uses KE (8) and IDP2 (9) to find K '(7) which he uses to decipher on the fly the files (1) necessary for execution. The client machine does not store or calculate K (14) because the files (1) are decrypted with K '(7). K '(7) is specific to IDp (9) and therefore can not be used on another system. In the same way, KE (8) is specific to IDPi (9) and IDP2 (9).

  4.3.3. Hybrid system for CDROM broadcasting We will take as an example the diffusion of software (for PC for example) on CDROM (33) or DVDROM (33) media. The system described below implements a combination of the two key management methods (see section 3.1 and 3. 2.).

  Each CD (33) is produced from a master (22). On the CD 35 master (22), all the files (1) are encrypted with a KI key (7), with the exception of the installer which is stored in clear.

  Figure 17. illustrates the production of serial CDs (33) from the master (22).

  Some indispensable files (32) are deliberately left absent from the master. These files will be provided to the client later.

  A copy of the CDROM is then purchased by a client who will install the software on his computer. The installer will install the encrypted versions of the files (1) on the target hard drive and ask the user to enter the serial number of the product (typically, indicated on the package) and possibly his personal details (this information constitutes IDP2 9). The installation program will then automatically recover the physical identifier of the computer (9) (typically the physical address of the network interface) which constitutes IDp1 (9). These two identifiers are then sent to the server (31) of the provider (typically, the software publisher) by secure transmission (typically, SSL). The server will then calculate a custom key K'2 (7), from IDpi (9) and K2 (14) (secret key, which never leaves the server). Missing files (32) on the CD are then encrypted with K'2 (7) and sent to the client. The server (29) will then generate the transmission subkeys KE1 (8) and KE2 (8) (from IDP2 (9), KI (14) and K2 (14)) and transmit them to the client. These transfers can be done by secure transaction, but in practice the secure transmission of IDpl (9) and IDP2 (9) is sufficient.

  Figure 18. illustrates the generation of K'2 and KE2. Figure 19. illustrates the generation of KE1.

  KE1 (7) and KE2 (7) and IDP2 (9) are stored on the client machine (27). When the client uses the software, K, (7) and K'2 (7) are dynamically recalculated: KI (7) is generated from KE1 (8) and IDP2 (9). K'2 (7) is generated from KE2 (8) and IDP2 (9). The current files are then decrypted with KI (7), and special files (those that are missing on the CD) are decrypted with K'2 (7). No file is stored in clear on the hard disk (2): they are all dynamically decrypted in memory (5) to be executed.

  We use IDp1 (9) (here machine identifier) to customize the encryption key (7) and IDP2 (9) (here user ID) to customize the transmission key (8). This method gives more flexibility to the system: if the machine identifier changes (replacement of the network card for example), the customer can ask the provider to re-generate the personalized files and send them to him through his client ID (which has not changed him).

  K, (7) and K2 (7) must be different to ensure an increased security of the system: even if a hacker succeeds in finding KI (7), he will never be able to recover K2 (7), because only K'2 (7) ) is calculated locally. Since K'2 (7) is in fact the result of a hash function (15), we can never go back to K2 (14).

  4.3.4. Multimedia downloadable on demand The invention also applies to the protection of downloadable multimedia content, for reading on personal computers (PC, Mac ...) or dedicated players type mp3 player.

  Whatever the different physical platforms (PC, MP3 players, turntables, car radios ...) on which a user will want to read a multimedia content, these must have a common physical identifier. We will use a SIM-based, portable solution that can be recognized on any type of platform equipped with the appropriate reader.

  Multimedia files (music, movies ...) are downloaded via the Internet. When a user requests a file (34), it is encrypted specifically according to its SIM identifier (9) (method described in section 3.2.): The server calculates a unique key K '(7) from l SIM identifier (9) of the client and a secret base key K (14) relating to the requested file. The file (34) is encrypted with K '(7) and a transmission subkey KE (8) is calculated (from K' (7) and the SIM identifier (9)) and added to the header of the encrypted file (1). A fingerprint (21) (hash code) of K '(7) is also added to the header (the header contains in fact the same information as a line of the virtual key-holder (16) described in section 3.3. ) If the client connects for the first time to the server (31), its SIM identifier (9) is transmitted to the server (31) by secure transaction (typically, SSL).

  Figure 20. illustrates the method of generating the keys K 'and KE.

  The custom file (1) can then be sent to the client (downloaded, or sent by mail on CD engraved in case of big order for example). The encryption key K '(7) can be found only with the help of the SIM identifier (9) of the client: if the file (1) is intercepted by a hacker, it will be unusable.

  When the user uses the file (1), the reading system will use the identifier SIM (9) and the subkey KE (8) contained in the header to find K '(7) and decrypt the content dynamically . A verification of K '(7) is performed prior to decryption, thanks to the imprint (21) contained in the header of the file.

  The use of the SIM card (9) as physical identifier 5 allows the portability, and extension of the system to any type of media player (PC, MP3 players, turntables, car radios ...).

  As indicated above, the custom files (1) will be usable only by the user who ordered them. The files themselves can be sent without additional protection. The only need is to effectively protect the transfer of the SIM identifier (9) during the first connection of a client.

  4.3.5. Data Protection on Hard Disk The invention applies to the protection of data stored on mass storage: on hard disk in particular.

  Here we describe a system that can protect the data contained on a hard drive (41) and also restrict access to the computer on which the drive (41) is installed, by encrypting hardware (regardless of the system). exploitation) the data and / or system partitions.

  With regard to data protection, the system described below may also be applicable to CDROM or DVDROM recorders.

  Figure 21. shows the principle of operation of such a system: a dedicated interface board (42) is placed between the hard disk to protect (41) and the disk controller (36) of the motherboard (40). This card (42) is connected to a smart card reader (43) which will be used to authenticate the user. When the user is authenticated, the read I write commands between the disk (41) and the controller (36) are intercepted by the card (42) which will encrypt the data to the disk (41) and decrypt the data to the disk. controller (36). This system makes it possible to ensure a high level of security in the data protection while freeing itself from the constraints related to the operating system.

  This system will exploit the custom key management method described in section 3.2. The encryption card (42) is identified by a unique hardware number (46), not falsifiable and not accessible from the outside. A single key K (14) is obtained by combining this number with the serial number (47) of the hard disk to be protected (41). A physical key Kp (10) is, on the other hand, generated from the secret information (48) contained on the smart card (39). To protect the disk (41), a custom encryption key K '(7) will be generated from K (14) and Kp (10) by means of a function h (15). A storage subkey KE (8) will then be generated by the function g (35) from K 'and Kp. Other storage subkeys (8) can be generated for the same encryption key (7), to allow the use of the system with other smart cards (to allow multiple users for example). The data will be encrypted and decrypted with K '(7), but only KE (8) storage subkeys will be kept on the system. To encrypt or decrypt the data, the encryption key K 'will be generated dynamically from a key KE (8) and the corresponding smart card (39) with the function f (12).

  Figure 22. illustrates the key generation system described above.

  Fig. 23. illustrates the method of dynamically generating the key K '(7) from a subkey KE (8) and the corresponding smart card (39).

  The storage subkeys KE (8) will be stored in an erasable memory (44) of the EEPROM or flash type. To allow a user to transport a disk and use it on another system, with the appropriate smart card, this memory (44) will be physically located between the hard disk (41) and the connector (45) and will be transported with the hard disk. In the case of a rack-mounted disk, this memory (44) will be physically located in the drawer. In addition to the storage subkeys KE (8) this memory will contain the fingerprint (21) of the encryption key K '(7) according to the key ring principle (16) described in section 3. 3.2. This fingerprint will verify the validity of the key before performing encryption or decryption.

  Figure 24 shows the physical layout of the KE storage memory.

  The system will be able to decode the partition table of the disk so that each partition is encrypted independently. In the case of a multi-user system, each user has his own smart card and a rights system will independently affect the read and / or write rights for each user partition pair.

  2867868 24 The system can be installed on a blank disc, or on a disc already containing information. In the second case, a special procedure will automatically encrypt the entire contents of the disc (41).

Figure 25 illustrates this principle.

  In the same way, an already protected disc can be de-protected.

  Figure 26 illustrates this principle. the

  In the case where a plurality of hard disks (1) are to be protected, a concentrator type device (37) will make it possible to use a plurality of interface cards with a single smart card reader (43). Each hard disk (41) is connected to the controller (36) via a different interface card (42). Each interface card (42) is connected to the concentrator (37) which communicates with the reader (43).

  Figure 27 illustrates a system using multiple hard disks (41) and a hub (37).

  APPENDIX 1. Symbol Table This table only shows the functions used and the constraints associated with them. For implementations, see section 4.).

  Symbols Description Prerequisites for

  implementation C Encryption function V x, DK (CK (x)) = x D Decryption function K Primary key for encryption / decryption IDp Physical identifier (relative to the i (lDp) = Kp machine or client) IF IDp , IDp2 THEN i (lDp1) I (IDP2) Kp Key relative to the physical identifier (directly linked to IDp) 1 Function generating Kp KE Key supplied to the client (relative to K SI KE = g (Kp, K) THEN and to Kp) K = f (Kp, KE) (transmission subkey) ^ K can not be found unless KE and Kp are known G Function generating KE f KK recompiling function 'Encryption / decryption key K' = h (K, Kp) custom (relative to SI Km KP2ALORS the physical identifier) ^ P (h (K, Kp) _ h (K, Kp)) 0 (P: Probability) ^ K can not be traced from of h, K 'and Kp h Function generating K' BFp Clear version of the files - BFc binaries Encrypted version of the files - ECp binaries Decrypted binary code -

Claims (1)

5. Claims   (1) A method of protection by encryption of software and data, broadcast via a network or a storage medium, characterized by the following steps: - The generation of a secret encryption key K (7) intended for the encryption of programs or data to be protected - The encryption of the programs or software to be protected by means of an encryption algorithm (6) and the K key (7) - The storage at each user of the encrypted versions of the programs or data and of these versions only - The generation of a subkey KQ (10) relating to a user and / or a system - The generation, by means of a function g (35), of a subkey KE (8) depending on K (7) and Kp (10) - The dynamic recovery with each use of the programs or data, by means of a function f (12), of the key K (7) from the subkeys KE (8) and KP (10) - The dynamic deciphering in memory, at each of their use, of the protected programs or data, at the The method of claim 1, characterized in that it consists of: generating, for each user and / or system, an encryption key K '(1), a key for decryption (13) and the key K (7); (7) dependent on a secret key K (14) fixed and a subkey Kp (10) relative to the user and / or the system, this generation being effected by means of a non-reversible function Use the key K '(7) for the encryption of the programs or data to be protected before providing them to the user or the system corresponding to the subkey Kp (3) Application of a method according to one of the preceding claims the protection and management of the rights of use of on-demand encrypted software functionalities (1) by sending KE (8) specific sub-keys to the user and / or a machine to a user.   (4) Application of a method according to one of the preceding claims to the protection of embedded software or the management of licenses on proprietary hardware systems or platforms. (5) Application of a method according to one of the preceding Claims 1 to 10, for downloading secure contents (31) from a server infrastructure or content security network boxes (29) to a client machine (27), the software or data being encrypted in a customized manner for a machine and / or a user (6) Application of a method according to one of the preceding claims to the broadcasting of multimedia contents, with an identification of a user or a client machine by an authentication system.   (7) The method according to claims 1 and 2, characterized in that it also consists in protecting the contents of any data storage medium (33) by omitting on the support (33) an indispensable element (32), for transmit it later, protected and personalized according to the method claimed in claim 2.   (8) A method according to claims 1 and 2, characterized by storing key information, necessary but not sensitive, in a header specific to the protected files, namely: a. The storage of the user-specific transmission subkey (8) in the header of the file.   b. Storage of the condensate (21) of the main encryption key (7) in the header of the file.   (9) System for protecting storage units and in particular hard disk drive implementing claims 1 and 2, characterized in that it comprises: an interface card between the hard disk and its controller, realizing the fly encryption and decryption of data.   A programmable memory of the EEPROM or flash type containing the KE (8) subkeys and the imprint (21) of the encryption key K (7); - a smart card reader allowing the authentication on the system of a or multiple users.