Brevet FR2867868A1 — publié le 20050923

1. Objet L'invention concerne un système de protection de logiciels et de données, basé sur une méthode de cryptage qui assure une grande 5 sécurité dans la protection. Les systèmes de protection standards sont facilement cassables, car quels que soient les systèmes de cession de licences utilisés (clefs, activation par Internet, ...), il y a toujours un test afin de vérifier si le logiciel possède une licence valable ou pas. lI est alors facile à un pirate informatique de faire sauter le test avec un simple correctif, plutôt que d'essayer de casser le système de licence lui même. L'invention solutionne ce problème et empêche les pirates informatiques d'accéder aux fonctionnalités, et cela même s'ils sont capable de casser le test de validité de la licence. Ce document décrit un système de protection générique et innovant, ainsi que des fonctionnalités spécifiques pour la gestion d'extension de fonctionnalités (logiciels modulaires) et la protection de contenu (contenu multimédia notamment). 1.1 Principe de l'invention. Le logiciel licencié est stocké dans une version cryptée sur l'unité de stockage de l'ordinateur (2). Pour démarrer le logiciel, un lanceur dédié (3), utilisant une fonction de cryptage D, est exécuté et décrypte de manière dynamique les fichiers binaires (1) en les chargeant directement dans la mémoire centrale (5) lorsque cela est nécessaire. Les versions en clair des fichiers binaires (34) ne sont jamais stockés sur l'unité de stockage (2). La figure 1 présente les relations entre les fichiers chiffrés (1) sur l'unité de stockage (2) et les données en clair dans un segment de la 30 mémoire (4) centrale de l'ordinateur (5). 1.2 La gestion des clefs La clef de décryptage (7) K n'est pas enregistré sur l'unité de stockage (2) de manière permanente, mais peut être retrouvée à partir de deux sous-clefs (10) qui sont relatives à un identifiant physique IDP 9. La sous-clef KP (10) est étroitement liée à IDP (7), donc dépendante de la machine. -- La sous-clef KE (8) est calculée par le fournisseur du 40 logiciel, en utilisant KP (10) et K (7) KE = g(K, Kp) Le module de chargement calcule K = f(Kp,KE) Le programme est conçu de manière à ce que: Les fonctionnalités logicielles ne puissent être débloquées qu'avec la clef appropriée sur le système approprié. Les fonctionnalités débloquées ne puissent pas être fonctionnelles une fois transférées sur un autre système de même type ou non. Aucune clef sensible ne soit stockée sur les unités de io stockage locales (2). Deux cas de gestion de clefs peuvent être distingués: (1) Le logiciel, ou fichiers binaires, installé initialement (1) est le même pour chaque machine. (2) Le logiciel, ou fichiers binaires, installé initialement (1) est spécifique à chaque machine. La décision entre les ces deux variantes dépendra des contraintes du système de production et de diffusion des logiciels. 2. Définitions Nous donnerons ici un certain nombre de définitions nécessaires à la compréhension du système décrit. Certaines sont d'ordre général et 5 certaines sont spécifiques au système. 2.1. Identifiant physique Dans la suite, nous considérerons qu'un système physique typiquement un ordinateur, est identifié par un numéro matériel unique, spécifique au système et qui ne peut pas être modifié. Nous appellerons un tel numéro identifiant physique (1). 2.2. Fonction de hachage Une fonction de hachage est une fonction non inversible qui génère un condensât (ou empreinte) de taille fixe à partir d'une donnée d'entrée de taille quelconque. Les propriétés mathématiques d'une telle fonction doivent assurer que: La probabilité que deux entrées différentes donnes le même condensât est extrêmement faible. Il est impossible de retrouver l'entrée à partir du condensât. Les fonctions de hachages sont typiquement utilisées pour vérifier l'intégrité de données. 2.3. Logiciel modulaire Un logiciel d'architecture modulaire est un logiciel présentant plusieurs fonctionnalités, typiquement implémentée dans des composants logiciels distincts, exécutables indépendamment les unes des autres. Sur un tel système, certaines fonctionnalités peuvent être totalement désactivées sans nuire au bon fonctionnement des autres. 2.4. Programme principal Dans une architecture modulaire, le programme principal (18) est le composant logiciel qui va gérer l'ensemble des fonctionnalités. C'est la partie centrale de l'architecture. Il est capable de configurer, de lancer et de stopper les différents modules fonctionnels (1). 4 2.5. Module Dans une architecture modulaire, un module (1) est une partie du système, fournissant un ou plusieurs services, et ne dépendant que du programme principal pour fonctionner. 2.6. Extension des fonctionnalités d'un logiciel Une extension logicielle est une modification d'un logiciel existant. Elle vise typiquement à augmenter ses performances ou à étendre ses 10 fonctionnalités, c'est à dire à ajouter ou activer de nouveaux modules. 2.7 Porte-clef Le porte-clef (16) est une structure virtuelle conçue spécifiquement 15 pour le système de protection. Il stocke toutes les informations nécessaires relatives aux licences. C'est grâce au porteclef virtuel que le système pourra vérifier si une licence est active ou non. 2.8. Lanceur Dans le cadre de notre système, nous appellerons lanceur le module (3), ou couche d'abstraction, logiciel qui se charge de déchiffrer à la volée les fichiers (1) et de les charger en mémoire (5) pour les lire ou les exécuter. 2.9. Acronymes AES: 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 Liste des figure Des modes d'exécution de l'invention seront décrits ci-après, à titre d'exemples non limitatifs avec références aux dessins annexés dans lesquels: La figure 1 est une représentation schématique des relations entre les fichiers chiffrés (1) sur l'unité de stockage (2) et les données en clair dans un segment de la mémoire (4) centrale de l'ordinateur (5). La figure 2 est une représentation schématique d'un fichier en 15 clair (34), crypté grâce à une clef K (7) et à un algorithme C (6) pour calculer le fichier crypté (1). La figure 3 représente de manière schématique le processus de génération d'une sous-clef de transmission (8) à partir d'une clef K (7) définie par un fournisseur de logiciel et de IDP (9), identifiant du client ou de la machine. La figure 4 représente de manière schématique la génération d'une clef K (7) à partir des éléments KE (8) et IDP2 (9), et illustre le 25 décryptage d'un fichier crypté (1) par K (7). La figure 5 représente de manière schématique l'utilisation des IDP (9) avec K (14) pour générer K' (7) et KE (8). La figure 6 représente de manière schématique l'utilisation des clefs et des identifiants lors d'une installation avec des fichiers spécifiques à chaque machine. La figure 7 représente de manière schématique les principes de 35 logiciel modulaire, et de gestion de licence à l'aide d'un porte-clef virtuel (16). La figure 8 une représentation schématisé d'un exemple de structure de porte-clef (16). Le champ IDENTIFIANT de la fonction permet de stocker des identifiants (19) des fonctionnalités/modules. Le champ LICENCE permet de stocker des marqueurs (20) de licence. SOUS-CLEF DE FONCTION est le champ permettant de 2867868 6 garder la valeur des sous- clefs (8) qui vont permettre de retrouver la clef de chiffrage des modules correspondants. Enfin, le champ CONDENSAT DE CLEF permet de stocker des empreintes (21) des clefs secrètes. Ces empreintes (21) permettront au programme principal de vérifier que la sous-clef est bien valide. La figure 9. représente de manière schématique le procédé d'installation pour un logiciel embarqué, cette installation étant totalement maîtrisée par le fournisseur. La figure 10. représente de manière schématique le fonctionnement d'un programme d'installation: on utilise pour générer des clefs de chiffrement une triple fonction (fonction h, voir sections 3.4.et4.2.): La figure 11. représente de manière schématique un exemple de structure d'un porte-clefs virtuel. La figure 12. représente de manière schématique la génération d'une sousclef (10) K'p à partir d'une adresse physique de l'interface réseau (9) (numéro NIC). Cette génération se fait par une simple répétition de motif. La figure 13. représente de manière schématique la génération 25 d'une sous-clef KE (8) à partir de K'F; (7) et K'p (10). Cette génération se fait par chiffrement AES. La figure 14. représente de manière schématique un système de récupération d'une clef de chiffrement K'F; (7) et le déchiffrage du 30 module correspondant. La figure 15. représente de manière schématique un système de vérification de la validité d'une sous-clef KE (8). La figure 16. représente de manière schématique le principe du boîtier de sécurisation (29) intercalé en aval d'un serveur (31). La figure 17. représente de manière schématique la production des CD (33) de série à partir d'un master (22). La figure 18. représente de manière schématique la génération de K'2 (7) et KE2 (8) à partir de IDP1 (9), IDP2 (9) et de K2 (14). 2867868 7 La figure 19. représente de manière schématique la génération de KE1 à partir d'un identifiant IDP2(9) et d'une clef K, (7) La figure 20. représente de manière schématique la méthode de génération des clefs K' (7) et KE (8) à partir d'un identifiant SIM (9) et d'une clef K (14). La figure 21 représente de manière schématique le système de lo protection de disque dur (41) mettant en oeuvre une carte d'interface (42) assurant les fonctionnalités de cryptage et de décryptage ainsi qu'un lecteur de cartes à puce (43) permettant l'authentification des utilisateurs. La figure 22 représente de manière schématique le procédé de génération des clefs de chiffrage K' (7) et de stockage KE (8) dans le cadre du système de protection de disque dur. La figure 23 représente de manière schématique le procédé de récupération de la clef de chiffrage K' (7) à partir de la clef de stockage KE (8) contenue dans la mémoire (44) et de la carte à puce correspondante (39), dans le cadre du système de protection de disque dur. La figure 24 représente de manière schématique la disposition physique de la mémoire (44) de stockage des KE (8),dans le cadre du système de protection de disque dur. La figure 25 représente de manière schématique le procédé de cryptage mis en oeuvre pour la protection d'un disque dur (41) contenant déjà des données, dans le cadre du système de protection de disque dur. La figure 26 représente de manière schématique le procédé de 35 décryptage mis en oeuvre pour la dé-protection d'un disque dur (41) protégé. La figure 27 représente de manière schématique le système de concentrateur mis en oeuvre pour utiliser plusieurs cartes d'interface (42) et plusieurs disques durs (41) avec un seul lecteur de cartes à puce (43), dans le cadre du système de protection de disque dur. 3. Description du système Comme expliqué précédemment, l'invention peut être implémentée avec une version de logiciel (fichiers binaire) (1) identique ou s personnalisée pour chaque utilisateur. Nous allons détailler les méthodes de gestion des clefs qui seront utilisées dans chacun des deux cas. Il sera aussi détaillé le système d'extension sécurisée de fonctionnalités. l0 3.1 Gestion des clefs avec des binaires identiques Cette méthode sera utilisé si les contraintes de production et de diffusion ne permettent pas une personnalisation des fichiers binaires 1 pour chaque copie du logiciel (typiquement, le cas de grandes diffusions de CD-ROM (33) ou de DVD-ROM (33)). 3.1.1 Chiffrage des binaires Les fichiers binaires (34) sont chiffrés par le fournisseur de logiciel en utilisant une clef de chiffrage K (7) qui ne sera pas transmise à l'utilisateur. Seule la version cryptée des fichiers binaires (1) sera fournie au client. La figure 2 montre le fichier en clair (34), crypté grâce à la clef K (7) et l'algorithme C (6) pour obtenir le fichier crypté (1). 3.1.2 Génération des clefs Chaque machine ou utilisateur possède un ou plusieurs identifiants (9) IDP. La clef de chiffrage/déchiffrage principale K (7) est définie par le fournisseur de logiciel. La clef de chiffrage K (7) est alors utilisée pour générer une sous-clef KE (8) dépendante de IDP (9) via une fonction g (35) (typiquement une fonction symétrique qui prendrait en entrée une dérivée de K (7) et de IDP (9)), qui sera transmise à l'utilisateur avec les fichiers binaires cryptés (1). La figure 3 montre le processus de génération de la sous-clef de transmission (8) à partir de la clef K (7) définie par le fournisseur de 35 logiciel et de IDP (9), identifiant du client ou de la machine. 3.1.3 Processus d'installation L'utilisateur exécute un logiciel d'installation qui copie les fichiers cryptés (1) sur l'unité de stockage locale (2) de sa machine. Le logiciel est alors installé, mais pas encore activé : l'utilisateur peut activer le logiciel en demandant sa sous-clef KE (8) au fournisseur de logiciel. 2867868 9 La clef physique KP (10) est générée en local grâce à IDP (9) et est alors combinée avec KE (8) pour retrouver K (7) via la fonction f (12). Grâce à K (7), les fichiers binaires (1) peuvent alors être décryptés en mémoire (5) lorsque cela sera nécessaire. Cette opération doit être totalement transparente pour l'utilisateur. La figure 4 montre comment la clef K (7) est retrouvée à partir de KE (8) et IDP2 (9), et illustre le décryptage du fichier crypté (1) par K (7). Avantage de l'invention: - Les versions non cryptés des fichiers (34) ne sont jamais envoyées ou stockées sur les unités de stockages locales (2) de l'utilisateur. La clef de chiffrage/déchiffrage (7) ne transite pas à travers le 15 réseau. La clef de chiffrage/déchiffrage (7) n'est jamais stockée dans l'unité de stockage locale (2). - L'utilisateur n'a besoin de connaître que KE (8). 3.2 Gestion de clef pour les machines avec des binaires personnalisés Cette méthode est une version améliorée de la précédente, mais ne peut être utilisée que dans le cas où les contraintes de productions et de diffusions permettent la personnalisation des fichiers binaires (34) pour chaque copie du logiciel (typiquement, pour les diffusions restreintes sur support physique (CD, DVD...) ou le téléchargement de logiciels avec un serveur d'installation à distance dédié (31)). 3.2.1 Génération des clefs Chaque machine ou utilisateur possède un ou plusieurs identifiants (9) IDP. Un IDP (9) sera combiné avec une clef constante (14) K, qui est choisie par le fournisseur et qui restera secrète à l'aide d'une fonction h (15) (typiquement une fonction de hachage, voir implémentation en 4.2) Une clef K' (7) sera alors générée à partir de IDP (9), de K (14) en appliquant h (15), et qui sera utilisée pour chiffrer les fichiers binaires (1). K' (7) est dépendante de la machine étant donné qu'elle prends en compte IDP (9), idéntifiant unique de la machine. Comme la clef de chiffrage (7) est spécifique à la machine, les fichiers chiffrés (1) sont spécifiques à la machine aussi. La clef de chiffrage K' (7) sera alors utilisée pour générer KE (8), une sous-clef de transmission (dépendante de IDP (9) puisque K' (7) est déjà dépendant de IDP (9)), grâce à une fonction g (35). KE (8) sera transmise à l'utilisateur en même temps que les fichiers binaires chiffrés (1). La figure 5 illustre l'utilisation des IDP (9) avec K (14) pour générer K' (7) et KE (8). 3.2.2 Processus d'installation Le processus d'installation doit être contrôlé du coté du fournisseur. Comme l'installation se fait à partir d'un serveur (31) du fournisseur, l'utilisateur n'a pas à connaître la clef K (14). Le point clef de ce processus d'installation est que l'utilisateur ne voit jamais la version en clair des fichiers binaires (34) puisque les fichiers sont cryptés pendant le processus d'installation à partir du Master CD (22) en usine lors de la copie, ou avant le transfert de fichier dans le cas d'une installation par réseau, avant d'être stocké, toujours de manière crypté, en local sur la machine utilisatrice. De plus, la clef qui sert à chiffrer est K' (7), et non K (14) : l'utilisateur n'aura jamais à connaître K (14). La figure 6 explicite comment sont utilisées les clefs et les 25 identifiants lors d'une installation avec des fichiers spécifiques à chaque machine. 3.2.3 Avantages de l'invention - Chaque copie de chaque fichier est cryptée spécifiquement pour chaque machine ou utilisateur. Les fichiers en clair (34) ne sont jamais stockés sur le système local. - La clef de déchiffrage K' (7) n'est jamais envoyée à travers le réseau. La clef K' (7) n'est jamais stockée localement sur la machine de l'utilisateur. La clef K (14) reste secrète et ne sera jamais transmise, stockée ou recalculée du coté du client. L'utilisateur ne connaît que la sous-clef KE (8). 3.2.4 Application possible de la protection. 2867868 11 Diffusion restreinte de logiciels ou de données sur support physique. Serveur d'installation de logiciels à distance (31) (réseau) - Diffusion de media à travers des réseaux publics 5 (typiquement Internet) ou privés. 3.3 Gestion de licences d'extensions sécurisée Cette section décrit les particularités du système pour la gestion des licences d'extensions des logiciels modulaires. Cet aspect est indépendant de la méthode de gestion des clefs de chiffrage. La gestion de licences d'extensions sécurisée peut être utilisée avec les deux systèmes de gestion de clefs (binaires identiques ou personnalisés). Note: La gestion de licence unique (pour des logiciels non modulaires) peut être considéré comme étant un cas particulier avec un module unique. Même si aujourd'hui les taux de transferts via les réseaux croissent, ils sont généralement encore trop bas pour permettre le transfert de grosses quantités de données avec un délai raisonnable. Ce problème est d'autant plus critique si les données à transférer doivent être cryptées: typiquement, pour le transfert de logiciel à licence privée, la confidentialité de la transaction doit être assurée afin d'éviter les copies pirates. La méthode de protection décrite dans la section 1. peut résoudre ce problème: un logiciel (ou une suite de logiciel) sera entièrement (tous les modules/fonctionnalités, même optionnels) stocké sur la machine de l'utilisateur, et ses fonctionnalités seront activées sur demande. Chaque module (34) est stocké dans une version cryptée (1) pour éviter le piratage. En plus du système d'extensions, cette section décrit la manière dont les modules sont activés et la manière dont les licences sont gérées. La solution consiste en plusieurs fonctionnalités qui vont permettre de gérer les licences accordées, l'activation et la configuration des différents modules/fonctionnalités. Plusieurs éléments distincts sont nécessaires au fonctionnement du système: - Une structure logique appelée porte-clef (16) Un programme principal (18) 2867868 12 Des fonctionnalités modulaires (34) et indépendantes, conçues pour fonctionner avec le programme principal (18). Note: Les fonctionnalités peuvent être des modules différents d'une même application ou des application différentes (dans le second cas le système d'exploitation sera considéré comme programme principal). 3.3.1 Installation La procédure d'installation installe toutes les fonctionnalités optionnelles même si elles ne sont pas licenciées. Toutes les fonctionnalités seront disponibles sur le système, mais elles seront verrouillées. Afin d'éviter le piratage, les fonctionnalités seront chiffrées avec une clef secrète (7), et seules les fonctionnalités licenciées seront décryptées dynamiquement lors de l'utilisation. La figure 7 illustre les principes de logiciel modulaire, et de gestion de licence à l'aide du porte-clef virtuel (16). 3.3.2 Le porte-clef Le porte-clef (16) est une structure logique qui stocke des informations sur les modules et les licences. Cette structure contient des champs remplis avec les identifiants (19) des fonctions, des marqueurs (20) des licences accordées, les sous-clefs des licences (8) des modules, ainsi que les empreintes (21) des clefs primaires de chiffrage. Pour chaque fonctionnalité, les empreintes (21) des clefs primaires de chiffrage sont données par défaut. Les sous-clefs (8) des licences ne sont stockées que lorsque les licences correspondantes sont accordées. Pour les licences non acquises, le champ correspondant sera mis à une valeur par défaut. Lorsqu'une licence sera accordée, la valeur de la sous-clef (8) remplacera la valeur par défaut, et le marqueur (20) de licence sera positionné à OUI. La figure 8 est un exemple de structure de porte-clef (16). Le champ IDENTIFIANT de la fonction permet de stocker les identifiants (19) de la fonctionnalité/module. Le champ LICENCE permet de stocker le marqueur (20) de licence. SOUS-CLEF DE FONCTION est le champ permettant de garder la valeur des sous-clefs (8) qui vont permettre de retrouver la clef de chiffrage des modules correspondants. Enfin, le champ 2867868 13 CONDENSAT DE CLEF permet de stocker l'empreinte (21) de la clef secrète. Cette empreinte (21) permettra au programme principal de vérifier que la sous-clef est bien valide. 3.3.3 Extensions Quand l'utilisateur veut étendre les fonctionnalités (1) de son système (cad ajouter des fonctionnalités), il a besoin de la sousclef (8) personnalisée pour débloquer les fonctions correspondantes. Puisque les fichiers binaires (1) sont déjà stockés sur le système, on a besoin de très peu de transferts de données. Les sous-clefs (8) sont générées par le fournisseur (à partir de la clef de chiffrage (7) et de l'identifiant unique (9) de l'utilisateur, et éventuellement les identifiants des modules), et transmises à l'utilisateur. L'utilisateur entre les sous-clefs (8) en spécifiant les fonctionnalités (1) qu'il veut débloquer. Une fois ces informations confirmées, le programme principal génère une clef de déchiffrage (7) pour chacune des sous-clefs (8). Une empreinte sera extraite de chacune de ces clefs (26), pour être comparée aux empreintes stockée (21) dans le porte-clef afin de vérifier la validité des clefs de déblocage (8). Une fois les clefs (7) validées, le porte-clef (16) sera mis à jour. Les marqueurs (20) correspondants aux fonctionnalités (1) seront mis à OUI. Les modules seront alors déchiffrés et démarrés. 3.3.4 Mise à jour (patchs) Quand le binaire (34) devra être mis à jour, les différences entre les anciens binaires et les nouveaux binaires seront envoyés, ou disponibles en téléchargement. Les données incluent les modifications à apporter aux versions cryptées des binaires des fonctionnalités à mettre à jour, ainsi que les informations pour la vérification de l'intégrité. 4. Implémentations Nous donnons ici des exemples concrets d'implémentations pour le système décrit précédemment. Nous traiterons des cas de mise en oeuvre du système global, ainsi que de l'implémentation des fonctions de base. 4.1 Identifiant physique Nous distinguerons deux principaux types d'identifiant physique (9): 10 Identifiant relatif à une machine (typiquement un ordinateur) : c'est le plus aisé à mettre en oeuvre car il ne nécessite pas de matériel propriétaire - Identifiant relatif à un utilisateur: ce système est plus flexible et doit permettre à un client d'utiliser un produit licencié sur 15 différentes machines mais pas simultanément. 4.1.1. Identifiant machine Un tel identifiant est un code unique non modifiable (numéros de série par exemple) implémenté sur un composant matériel. II doit être accessible par logiciel, en lecture seule, pour permettre la vérification automatique. Techniquement le type d'implémentation matérielle a une grande importance: pour une meilleure fiabilité, le système devra utiliser un identifiant réellement non modifiable de type ROM ou PROM, plutôt que EPROM, EEPROM ou flash. Quelques exemples d'identifiant machine (plate-forme PC) : - Adresse physique de la carte réseau ( NIC number ) - Numéro de série du disque dur Identifiant du microprocesseur 4.1.2. Identifiant utilisateur Ce type d'identifiant sera lié à un utilisateur et non à une machine. Pour une sécurité optimale, il pourra tout de même s'agir d'un code matériel, mais qui devra être portable pour permettre à l'utilisateur de s'identifier sur plusieurs systèmes distincts. Quelques exemples d'identifiant utilisateur: - Dongle propriétaire: par exemple PROM + interface (USB, COM, LPT...) Carte à puce ou carte magnétique Numéro de série du produit 4.2. Implémentation des fonctions 2867868 15 4.2.1. Fonctions de cryptage / décryptage Les fonctions de cryptage (6) C et de décryptage (13) D peuvent être implémentées au moyen de n'importe quel algorithme de chiffrement récent (et sûr). Dans la description générale du système, on utilise la même clef (7) pour le chiffrement et le déchiffrement, on sous-entend donc que l'algorithme est symétrique (de type DES, triple DES, AES ou RC4 par exemple). Cela ne constitue en aucune façon une contrainte du système, qui peut être implémenté avec un chiffrement asymétrique lo (type RSA par exemple), pour peu que l'on génère au départ une paire appropriée de clefs, K0 et KD. 4.2.2. Fonction de génération de clefs L'implémentation exacte de ces fonctions sera évidemment dépendant du choix des fonctions de cryptage / décryptage, car le format d'une clef dépend de l'algorithme utilisé. - La fonction i (11), utilisée pour générer KP (10), a pour seule 20 contrainte d'être surjective. Il pourra donc s'agir d'une simple opération de changement de taille (complétion / padding ou troncature) . - Les fonctions f (12), utilisée pour retrouver K (7), et g (35), utilisée pour générer KE (8), peuvent être très simplement implémentées au 25 moyen d'opérateurs XOR ( ou exclusif ) : ^ K est posé ^ Si KE = KP XOR K Alors K = KP XOR KE Une solution plus sure consiste à utiliser pour f et g un algorithme de chiffrement symétrique du type DES ou AES, avec KP (10) comme 30 clef: ^ K est posé ^ Si KE = DESKP (K) Alors K = DESKP (KE) (N'importe quel chiffreur / déchiffreur symétrique pourra être utilisé.) - La fonction h (15), utilisée pour générer K' (7), sera typiquement implémentée en deux étapes: une concaténation de K (14) et KP (10) avec possible adaptation de la taille finale par troncature ou complétion), puis un hachage (15) du résultat. La fonction de hachage (15) pourra être un algorithme standard 40 comme MD5, ou SHA-1 (ce dernier étant plus sur) : ^ K=SHA-1 (KKp) 4.3. Cas d'implémentation du système global Nous présentons ici quatre exemples détaillés d'utilisation du 5 système décrit précédemment. 4.3.1. Extension de fonctionnalités sur plate forme propriétaire lo Ce cas d'implémentation décrit un système propriétaire (23), plate-forme matérielle et logiciel embarqué par exemple, utilisant une architecture logicielle modulaire (voir section 3.3.) : le fournisseur livre le système (23) avec les fonctions de base activées, et un certain nombre p de fonctions avancées seront disponibles pour une activation ultérieure à l'aide de clefs spécifiques. A chacune des fonctionnalités optionnelles est associée une clef KF qui servira de base pour la génération des clefs personnalisées (10), en fonctions des machines et / ou des utilisateurs. La méthode de gestion des clefs utilisée ici est celle décrite en 20 section 3.2. Nous utiliserons ici une plate-forme matérielle de type PC, avec l'adresse physique de l'interface réseau (NIC number) comme identifiant physique (9) IDP1 et IDP2. La figure 9. illustre le procédé d'installation pour le logiciel 25 embarqué, cette installation étant totalement maîtrisée par le fournisseur. Le CD d'installation contient: ^ Les fichiers binaires du programme principal (18) en clair ^ Les fichiers binaires des fonctionnalités optionnelles en 30 clair (34) ^ Les clefs de bases associées aux p fonctionnalités optionnelles (14) KF1, KF2É É É É KFPÉ ^ Un logiciel d'installation dédié comprenant un générateur de clefs, un module de chiffrage (ici AES) et l'installation 35 proprement dite. Nous utiliseront ici pour le chiffrage l'algorithme AES, avec des clefs de 256 bits. Le programme d'installation est exécuté à partir du CD. Une fois lancé, il va recherché l'adresse physique de l'interface réseau (9) de la machine cible, et générer les clefs de cryptages personnalisées (10) . La figure 10. illustre le fonctionnement du programme d'installation: on utilise pour générer les clefs de chiffrement une triple fonction (fonction h, voir sections 3.4. et 4.2.) : concaténation de la clef de base KF (25) et de l'identifiant physique (NIC number) (9) Hachage par l'algorithme SHA-1 Complétion à 256 bits (l'empreinte générée par SHA-1 est de 160 bits, la complétion à 256 pourra se faire en répétant partiellement le motif) Pour chaque fonctionnalité optionnelle, une clef (7) sera donc générée (chacune de ces clefs sera spécifiques à la fonction et à la machine) et les fichiers binaires (34) correspondants seront cryptés et copiés sur le disque dur de la machine cible. Les fichiers binaires du programme principal (18) sont installés directement sans cryptage. Afin de gérer l'activation séparée des différents modules, un porte-clefs virtuel (16) (voir section 3.3.) est implémenté sur la machine cible. Il stocke pour chaque fonctionnalité activée une sous-clef (8) relative à la fonction et à la machine. II stocke également une empreinte (21) ( hash code ) de la clef de chiffrement pour chaque fonctionnalité (active ou non). Un flag (8) indique pour chaque fonctionnalité si elle est activée ou non. La figure 11. illustre la structure du porte-clefs virtuel. Chaque sous-clef (8) KE est générée de la manière suivante: - Une sous-clef (10) K'F de 32 octets (256 bits) est générée à partir des 6 octets du numéro NIC (9). La sous-clef KE (8) est alors générée par un cryptage AES de la clef KIF; (7) correspondante, avec KIF (10) comme clef de chiffrement. La figure 12. illustre la génération de la sous-clef (10) K'P à partir de l'adresse physique de l'interface réseau (9) (numéro NIC). Cette génération se fait par une simple répétition de motif. La figure 13. illustre la génération de la sous-clef KE (8) à partir de K'Fj (7) et K'P (10). Cette génération se fait par chiffrement AES. 2867868 18 Le système est livré avec toutes les fonctionnalités disponibles mais seules celles choisies par le client sont activées. Quand l'utilisateur exécute une fonction active, le lanceur utilise la sous-clef KE (8) stockée dans le porte-clef (16) pour retrouver la clef KF (7) correspondante (K'Fi = AESDecrypt(Kip)(K'Ej) ) et décrypte les fichiers binaires (1) en mémoire (5) pour les exécuter. Quand l'utilisateur souhaite activer une nouvelle fonctionnalité, le fournisseur lui envoie la sous-clef KE (8) correspondante (par téléphone, courrier, e-mail... etc.). Cette sous-clef (8) est saisie manuellement par l'utilisateur sur le système, qui va vérifier sa validité à l'aide de l'empreinte (21) stockée dans le porte-clef (16)(le logiciel vérifie que SHA1(AESDecrypt(Kip)(K'Ei)) = empreinte stockée). Si la sous-clef KE (8) est valide, elle est ajoutée au porte-clef (16) et le flag d'activation (20) de la fonction correspondante est affirmé. La transmission de la sous-clef KE (8) ne pose pas de problème et ne nécessite pas de sécurité particulière, car la sous-clef (8) est spécifique au système et ne pourra être exploitée par aucun autre utilisateur. Si un module (1) est déchiffré avec une clef incorrecte, il ne pourra naturellement pas être utilisé. La vérification de validité de KE (8) sert donc plus a prévenir les erreurs de saisies qu'à éviter le piratage. La figure 14. illustre le système de récupération de la clef de chiffrement K'Fi (7) et le déchiffrage du module correspondant. La figure 15. illustre le système de vérification de la validité de la sous-clef KE (8). 4.3.2. Serveur sécurisé d'installation de logiciel L'objet de cette implémentation est de fournir une forte protection contre le piratage, pour les logiciels téléchargeables sur le réseau (typiquement sur Internet) : le serveur sécurisé d'installation à distance (31) permet au fournisseur de fournir à chaque client une version cryptée spécifiquement selon la méthode décrite en section 3.2. Un boîtier dédié de type appliance (29) pourra être utilisé entre le serveur (31) et les clients (27) pour sécuriser les serveurs d'installation pré-existants. La figure 16. illustre le principe du boîtier de sécurisation (29) intercalé en aval du serveur (31). Une clef de base K (17) est associée à chaque logiciel téléchargeable. Quand un client demande l'installation d'un logiciel il reçoit un programme de téléchargement / installation dédié. Ce programme va télécharger les fichiers nécessaires et les installer sur le système client. Une fois lancé, il va récupérer le ou les identifiants spécifiques à la machine et / ou à l'utilisateur (9) (IDP1 et IDP2) et les envoyer à l'appliance (29) (transaction sécurisée, SSL par exemple) qui les utilise pour la génération de clefs: l'appliance calcule K' (7) à partir de K (14) et IDP, (9) (fonction h 15), puis génère la sous-clef de transmission KE (8) à partir de K' (7) et IDP2 (9) (fonction g 12) et la transmet à la machine cliente (27). Une requête (28) est alors envoyée a I 'appliance pour l'installation effective du logiciel. Le serveur va envoyer les fichiers en clair (34) à l'appliance (29) qui va les crypter dynamiquement (clef K' (7), algorithme AES) pour les transmettre à la machine cliente (27) ou le logiciel crypté est finalement installé. Quand le client utilise le logiciel, le lanceur utilise KE (8) et IDP2 (9) pour retrouver K' (7) dont il se sert pour déchiffrer à la volée les fichiers (1) nécessaires à l'exécution. La machine cliente ne stocke ni ne calcule jamais K (14) car les fichiers (1) sont décryptés avec K' (7). K' (7) est spécifique à IDp (9) et ne pourra donc pas être utilisé sur un autre système. De la même manière, KE (8) est spécifique à IDPi (9) et IDP2 (9). 4.3.3. Système hybride pour la diffusion de CDROM Nous prendrons comme exemple la diffusion de logiciel (pour PC par exemple) sur support CDROM (33) ou DVDROM (33). Le système décrit ci-après implémente une combinaison des deux méthodes de gestion de clefs (voir section 3.1. et 3. 2.). Chaque CD (33) est produit à partir d'un master (22). Sur le CD 35 master (22), tous les fichiers (1) sont cryptés avec une clef KI (7), à l'exception du programme d'installation qui est stocké en clair. La figure 17. illustre la production des CD (33) de série à partir du master (22). Certains fichiers indispensables (32) sont volontairement laissés absents du master. Ces fichiers seront fournis au client ultérieurement. Une copie du CDROM est ensuite achetée par un client qui va installer le logiciel sur son ordinateur. Le programme d'installation va installer les versions cryptées des fichiers (1) sur le disque dur cible et demander à l'utilisateur de saisir le numéro de série du produit (typiquement, indiqué sur l'emballage) et éventuellement ses coordonnées personnelles (cette information constitue IDP2 9). Le programme d'installation va alors récupérer automatiquement l'identifiant physique de l'ordinateur (9) (typiquement, l'adresse physique de l'interface réseau) qui constitue IDp1 (9). Ces deux identifiants sont alors envoyés au serveur (31) du fournisseur (typiquement, l'éditeur du logiciel) par transmission sécurisée (typiquement, SSL). Le serveur va alors calculer une clef personnalisée K'2 (7), à partir de IDpi (9) et de K2 (14) (clef secrète, qui ne quitte jamais le serveur). Les fichiers manquant (32) sur le CD sont alors cryptés avec K'2 (7) et envoyés au client. Le serveur (29) va alors générer les sous-clefs de transmission KE1 (8) et KE2 (8) (à partir de IDP2 (9), KI (14) et K2 (14)) et les transmettre au client. Ces transferts peuvent être fait par transaction sécurisée, mais en pratique la transmission sécurisées de IDpl (9) et IDP2 (9) est suffisante. La figure 18. illustre la génération de K'2 et KE2. La figure 19. illustre la génération de KE1. KE1 (7) et KE2 (7) et IDP2 (9) sont stockés sur la machine cliente (27). Lorsque le client utilise le logiciel, K, (7) et K'2 (7) sont recalculées dynamiquement: KI (7) est généré à partir de KE1 (8) et IDP2 (9). K'2 (7) est généré à partir de KE2 (8) et IDP2 (9). Les fichiers courants sont alors décryptés avec KI (7), et les fichiers spéciaux (ceux qui sont manquant sur le CD) sont décryptés avec K'2 (7). Aucun fichier n'est stocké en clair sur le disque dur (2) : ils sont tous décryptés dynamiquement en mémoire (5) pour être exécutés. Nous utilisons IDp1 (9) (ici identifiant machine) pour personnaliser la clef de chiffrage (7) et IDP2 (9) (ici identifiant utilisateur) pour personnaliser la clef de transmission (8). Cette méthode donne plus de souplesse au système: si l'identifiant machine vient à changer (remplacement de la carte réseau par exemple), le client pourra demander au fournisseur de re-générer les fichiers personnalisés et de les lui envoyer grâce à son identifiant client (qui lui n'a pas changé). K, (7) et K2 (7) doivent être différents pour assurer une sécurité accrue du système: même si un pirate réussit à retrouver KI (7), il ne pourra jamais récupérer K2 (7), car seul K'2 (7) est calculé en local. Comme K'2 (7) est en fait le résultat d'une fonction de hachage (15), on ne pourra jamais remonter à K2 (14). 4.3.4. Multimédia téléchargeable à la demande L'invention s'applique également à la protection des contenus multimédias téléchargeables, pour lecture sur ordinateurs personnels (PC, Mac...) ou sur lecteurs dédiés de type baladeur mp3. Quelles que soient les plate-forme(s) physiques différentes (PC, baladeurs MP3, platines de salon, autoradios...) sur lesquelles un utilisateur voudra lire un contenu multimédia, celles-ci doivent disposer d'un identifiant physique commun. Nous utiliserons ici une solution à base de carte SIM, portable et susceptible d'être reconnue sur tout type de plate-forme équipée du lecteur adéquat. Les fichiers multimédias (musique, films...) sont téléchargés via Internet. Lorsqu'un utilisateur demande un fichier (34), celui-ci est crypté spécifiquement en fonction de son identifiant SIM (9) (méthode décrite en section 3.2.) : le serveur calcule une clef unique K' (7) à partir de l'identifiant SIM (9) du client et d'une clef de base secrète K (14) relative au fichier demandé. Le fichier (34) est chiffré avec K' (7) et une sous-clef de transmission KE (8) est calculée (à partir de K' (7) et de l'identifiant SIM (9)) et ajoutée à l'entête du fichier crypté (1). Une empreinte (21) (code de hachage) de K' (7) est également ajoutée à l'entête (l'entête contient en fait les même informations qu'une ligne du porte-clef virtuel (16) décrit en section 3.3.) Si le client se connecte pour la première fois au serveur (31), son identifiant SIM (9) est transmis vers le serveur (31) par transaction sécurisée (typiquement, SSL) . La figure 20. illustre la méthode de génération des clefs K' et KE. Le fichier personnalisé (1) peut alors être envoyé au client (téléchargé, ou envoyé par courrier sur CD gravé en cas de grosse commande par exemple) . La clef de chiffrage K' (7) ne peut être retrouvée qu'à l'aide de l'identifiant SIM (9) du client: si le fichier (1) est intercepté par un pirate, il sera donc inutilisable. Lorsque l'utilisateur utilise le fichier (1), le système de lecture va utiliser l'identifiant SIM (9) et la sous-clef KE (8) contenue dans l'entête pour retrouver K' (7) et décrypter le contenu dynamiquement. Une vérification de K' (7) est effectuée préalablement au décryptage, grâce à l'empreinte (21) contenue dans l'entête du fichier. L'utilisation de la carte SIM (9) en tant qu'identifiant physique 5 permet la portabilité, et l'extension du système à tout type de lecteur multimédia (PC, baladeurs MP3, platines de salon, autoradios...). Comme indiqué précédemment, les fichiers personnalisés (1) ne seront exploitables que par l'utilisateur qui les aura commandés. Les fichiers eux-mêmes peuvent donc être envoyés sans protection supplémentaire. La seule nécessité est de protéger efficacement le transfert de l'identifiant SIM (9) lors de la première connexion d'un client. 4.3.5. Protection de données sur disque dur L'invention s'applique à la protection des données stockées sur mémoire de masse: sur disque dur en particulier. Nous décrivons ici un système capable de protéger les données contenues sur un disque dur (41) et également de restreindre l'accès à l'ordinateur sur lequel le disque (41) est installé, en chiffrant de façon matérielle (indépendamment du système d'exploitation) les partitions de données et / ou de système. En ce qui concerne la protection des données le système décrit ci-après pourra également s'appliquer aux graveurs de CDROM ou de DVDROM. La figure 21. présente le principe de fonctionnement d'un tel système: une carte d'interface dédiée (42) est placée entre le disque dur à protéger (41) et le contrôleur disque (36) de la carte mère (40). Cette carte (42) est reliée à un lecteur de cartes à puce (43) qui va servir à l'authentification de l'utilisateur. Lorsque l'utilisateur est authentifié, les commandes de lecture I écriture entre le disque (41) et le contrôleur (36) sont interceptées par la carte (42) qui va crypter les données vers le disque (41) et décrypter les données vers le contrôleur (36). Ce système permet d'assurer une grande sécurité dans la protection des données tout en s'affranchissant des contraintes liées au système d'exploitation. Ce système va exploiter la méthode de gestion de clefs personnalisées décrite en section 3.2. La carte de cryptage (42) est identifiée par un numéro matériel unique (46), non falsifiable et non accessible de l'extérieur. Une clef K unique (14) est obtenue en 2867868 23 combinant ce numéro avec le numéro de série (47) du disque dur à protéger (41). Une clef physique Kp (10) est d'autre part générée à partir des informations secrètes (48) contenues sur la carte à puce (39). Pour protéger le disque (41), une clef de chiffrage personnalisée K' (7) va être générée à partir de K (14) et de Kp (10) grâce à a fonction h (15). Une sous-clef de stockage KE (8) sera alors générée par la fonction g (35) à partir de K' et Kp. D'autres sous-clefs de stockage (8) pourront être générée pour une même clef de chiffrage (7), afin de permettre l'utilisation du système avec d'autres cartes à puce (pour autoriser plusieurs utilisateurs par exemple). Les données seront cryptées et décryptées avec K' (7), mais seules les sous-clefs de stockage KE (8) seront conservées sur le système. Pour chiffrer ou déchiffrer les données, la clef de chiffrage K' sera générée dynamiquement à partir d'une clef KE (8) et de la carte à puce (39) correspondante avec la fonction f (12). La figure 22. illustre le système de génération de clefs décrit ci-avant. La figure 23. illustre le procédé de génération dynamique de la clef K' (7) à partir d'une sous-clef KE (8) et de la carte à puce (39) 20 correspondante. Les sous-clefs de stockage KE (8) seront stockées dans une mémoire effaçable (44) de type EEPROM ou flash. Pour permettre à un utilisateur de transporter un disque et de l'utiliser sur un autre système, avec la carte a puce appropriée, cette mémoire (44) sera physiquement située entre le disque dur (41) et le connecteur (45) et sera transportée avec le disque dur. Dans le cas d'un disque monté en rack, cette mémoire (44) sera physiquement située dans le tiroir. En plus des sous-clefs de stockage KE (8) cette mémoire contiendra l' empreinte (21) de la clef de chiffrage K' (7) selon le principe de porte clef (16) décrit en section 3. 3.2. Cette empreinte permettra de vérifier la validité de la clef avant d'effectuer un chiffrage ou un déchiffrage. La figure 24 présente la disposition physique de la mémoire de stockage des KE. Le système sera capable de décoder la table des partitions du disque de manière à crypter indépendamment chaque partition. Dans le cas d'un système multi utilisateurs, chaque utilisateur dispose de sa propre carte à puce et un système de droits affectera indépendamment les droits de lecture et/ou écriture pour chaque couple partition utilisateur. 2867868 24 Le système peut être installé sur un disque vierge, ou sur un disque contenant déjà des informations. Dans le second cas, une procédure spéciale permettra de chiffrer automatiquement tout le contenu du disque (41). La figure 25 illustre ce principe. De la même manière, un disque déjà protégé pourra être dé-protégé . La figure 26 illustre ce principe. la Dans le cas ou plusieurs disques durs (1) doivent être protégé, un dispositif de type concentrateur (37) permettra d'utiliser plusieurs cartes d'interface avec un seul lecteur de cartes à puce (43). Chaque disque dur (41) est relié au contrôleur (36) via une carte d'interface différente (42). Chaque carte d'interface (42) est reliée au concentrateur (37) qui communique avec le lecteur (43). La figure 27 illustre un système utilisant plusieurs disques durs (41) et un concentrateur (37). ANNEXE 1. Table des symboles Cette table ne présente que les fonctions utilisées et les contraintes qui leur sont associées. Pour les implémentations, voir la section 4.). Symboles Description Pré requis pour l'implémentation C Fonction de chiffrage V x, DK(CK(x)) = x D Fonction de déchiffrage K Clef primaire de chiffrage/déchiffrage IDp Identifiant physique (relative à la i(lDp) = Kp machine ou au client) SI IDp, IDp2 ALORS i(lDp1) I(IDP2) Kp Clef relative à l'identifiant physique (directement lié à IDp) 1 Fonction générant Kp KE Clef fournie au client (relative à K SI KE = g(Kp,K) ALORS et à Kp) K = f(Kp, KE) (sous-clef de transmission) ^ K ne peut pas être retrouvé sauf si KE ET Kp sont connues G Fonction générant KE f Fonction de recomposition de K K' Clef de chiffrage/déchiffrage K' = h(K,Kp) personnalisée (relative à SI Km KP2ALORS l'identifiant physique) ^ P(h(K, Kp) _ h(K,Kp)) 0 (P: Probabilité) ^ K ne peut pas être retrouvée à partir de h, K' et de Kp h Fonction générant K' BFp Version en clair des fichiers - binaires BFc Version chiffrés des fichiers - binaires ECp Code binaire décrypté - 5. Revendications (1) Procédé de protection par cryptage de logiciels et de données, diffusés via un réseau ou un support de stockage, caractérisé par les étapes suivantes: - La génération d'une clef de chiffrage secrète K (7) destinée au cryptage des programmes ou données à protéger - Le cryptage des programmes ou logiciels à protéger au moyen d'un algorithme de chiffrage (6) et de la clef K (7) - Le stockage chez chaque utilisateur des versions cryptées des programmes ou données et de ces version uniquement - La génération d'une sous-clef KQ (10) relative à un utilisateur et/ou à un système - La génération, au moyen d'une fonction g (35), d'une sous-clef KE (8) dépendant de K (7) et Kp (10) - La récupération dynamique à chaque utilisation des programmes ou données, au moyen d'une fonction f (12), de la clef K (7) à partir des sous-clefs KE (8) et KP (10) - Le déchiffrage dynamique en mémoire, à chacune de leur utilisation, des programmes ou données protégées, au moyen d'un algorithme de déchiffrage (13) et de la clef K (7) (2) Procédé selon la revendication 1 caractérisé en ce qu'il consiste à : - Générer pour chaque utilisateur et/ou système une clef de chiffrage K' (7) personnalisée dépendant d'une clef secrète K (14) fixée et d'une sous- clef Kp (10) relative à l'utilisateur et/ou au système, cette génération s'effectuant au moyen d'une fonction non réversible Utiliser la clef K' (7) pour le chiffrage des programmes ou données à protéger avant de les fournir à l'utilisateur ou au système correspondant à la sous-clef Kp (3) Application d'un procédé selon l'une des revendications précédentes à la protection et à la gestion des droits d'utilisation de fonctionnalités logicielles cryptées (1) activables à la demande en envoyant à un utilisateur des sous-clefs KE (8) spécifiques à l'utilisateur et/ou à une machine. (4) Application d'un procédé selon l'une des revendications s précédentes à la protection de logiciels embarqués ou à la gestion de licences sur des systèmes ou plates-formes matérielles propriétaires (5) Application d'un procédé selon l'une des revendications 1 à l0 2 au téléchargement de contenus sécurisés (31) à partir d'une infrastructure serveur ou de boîtiers réseaux de sécurisation de contenus (29), vers une machine cliente (27), les logiciels ou données étant cryptés de façon personnalisée pour une machine et/ou un utilisateur (6) Application d'un procédé selon l'une des revendications précédentes à la diffusion de contenus multimédias, avec une identification d'un utilisateur ou d'une machine cliente par un système d'authentification. (7) Le procédé selon les revendications 1 et 2, caractérisé en ce qu'il consiste également à protéger le contenu de tout support de stockage de données (33) en omettant sur le support (33) un élément indispensable (32) , pour le transmettre ultérieurement, protégé et personnalisé selon le procédé revendiqué dans la revendication 2. (8) Procédé selon les revendications 1 et 2, caractérisé par le stockage des informations relatives aux clefs, nécessaires mais non sensibles, dans une entête spécifique aux fichiers protégés, à savoir: a. Le stockage de la sous-clef de transmission (8) spécifique à un utilisateur dans l'entête du fichier. b. Stockage du condensât (21) de la clef principale de chiffrement (7) dans l'entête du fichier. (9) Système de protection d'unités de stockage et en particulier de disque dur mettant en oeuvre les revendications 1 et 2, caractérisé en ce qu'il comporte: - Une carte d'interface entre le disque dur et son contrôleur, réalisant à la volée le cryptage et le décryptage des données. - Une mémoire programmable de type EEPROM ou flash contenant les sousclefs KE (8) et l'empreinte (21) de la clef de chiffrement K (7) - Un lecteur de carte à puce permettant l'authentification 5 sur le système d'un ou plusieurs utilisateur(s).