FR2845494A1

FR2845494A1 - Logiciel et procede d'authentification de celui-ci

Info

Publication number: FR2845494A1
Application number: FR0212326A
Authority: FR
Inventors: Jean Claude Sarfati; Alain Lecaer
Original assignee: Canal Plus Technologies SA
Current assignee: KCA Licensing SA
Priority date: 2002-10-04
Filing date: 2002-10-04
Publication date: 2004-04-09
Anticipated expiration: 2022-10-04
Also published as: WO2004032329A2; WO2004032329A3; AU2003288371A1; AU2003288371A8; FR2845494B1

Abstract

La présente invention concerne un procédé d'authentification d'un logiciel, qui comprend les étapes suivantes :- utilisation de plusieurs fonctions élémentaires de calcul et d'au moins une fonction de vérification disséminées dans l'ensemble dudit logiciel,- vérification au cours du déroulement du logiciel, à l'aide d'une fonction de vérification, de la concordance d'un résultat de calcul obtenu à l'aide desdites fonctions élémentaires de calcul et d'un résultat mémorisé au préalable,- lancement d'une procédure de défense s'il n'y a pas concordance,- exécution dudit logiciel entrecoupée par l'exécution desdites fonctions élémentaires de calcul disséminées, l'exécution d'une pluralité de fonctions élémentaires de calcul disséminées étant nécessaire à l'obtention d'un seul résultat de calcul.

Description

LOGICIEL ET PROCEDE D'AUTHENTIFICATION DE CELUI-CI

DESCRIPTION

DOMAINE TECHNIQUE

La présente invention concerne un logiciel et un procédé d'authentification de celui-ci, notamment dans le domaine des décodeurs en télévision numérique.

ETAT DE LA TECHNIQUE ANTERIEURE

Dans les dispositifs de l'art connu, un test d'intégrité d'un logiciel embarqué est généralement réalisé en calculant, à l'aide d'un outil externe, une signature de référence représentative de ce logiciel et en insérant celle-ci dans celui-ci. 15 Pendant la phase d'initialisation du logiciel, celui-ci calcule sa propre signature et compare cette signature avec la signature de référence. Si ces signatures sont différentes le logiciel exécute un logiciel spécifique à une procédure de défense, sinon il continue 20 normalement. Cette succession d'étapes est illustrée

sur la figure 1.

Dans le cas d'une authentification d'un tel logiciel, on souhaite s'assurer de la provenance de celui-ci. Une solution connue consiste à reprendre le 25 principe du test d'intégrité et à le combiner avec un algorithme cryptographique asymétrique: la signature de référence est chiffrée avec une clé privée et le résultat est intégré, sous forme d'un certificat, au logiciel. Pendant la phase de contrôle, la signature de 30 référence est déchiffrée avec une clé publique intégrée

SP 21976 DB

au logiciel avant d'être comparée à la signature de référence. Un tel logiciel embarqué peut donc faire l'objet d'attaques de la part de pirates ("hackers") 5 essayant de modifier les fonctionnalités dudit logiciel à leur profit. Une authentification permet de détecter une éventuelle modification non autorisée du logiciel,

c'est-à-dire sans certificat associé.

L'authentification repose entièrement sur 10 des parties de logiciel. Les pirates peuvent effectuer des attaques avec plus ou moins de facilité. Ils peuvent essayer de changer la clé publique, inverser le test d'égalité des signatures, court-circuiter

l'ensemble de la vérification...

Un premier document de l'art connu,

référencé [1] en fin de description, décrit un mécanisme d'autovérification de logiciel réalisé pour améliorer la résistance de ce logiciel à l'encontre des manipulations. Ce mécanisme consiste en un ensemble de 20 morceaux de logiciels, ou "testeurs", qui testent de

manière redondante l'existence éventuelle de changements dans un logiciel exécutable pendant son exécution, et qui mettent en évidence de telles modifications. Chaque "testeur" teste une petite partie 25 de logiciel contiguÙ, et compare une valeur calculée à une valeur correcte connue. Chaque "testeur" est testé par plusieurs autres. La mise hors service d'un ou plusieurs de ces "testeurs" en les modifiant, est ainsi

détectée par les "testeurs" non modifiés.

Un second document de l'art connu,

référencé [2] en fin de description, décriu la

SP 21976 DB

protection d'un logiciel contre des modifications illégitimes de la part de ses utilisateurs. La protection et la résistance aux manipulations du logiciel sont réalisées en utilisant un réseau d'unités 5 de sécurité, ou "guards", disséminées dans un programme, qui travaillent ensemble. Chacune de ces unités est un morceau de logiciel apte à réaliser certaines actions relatives à la sécurité, pendant l'exécution du programme. Les unités peuvent être 10 programmées pour effectuer n'importe quel calcul, par exemple le calcul d'une somme de contrôle (ou "checksum" en langue anglaise) d'un autre morceau de logiciel pendant son exécution, pour vérifier son intégrité. Ces unités de sécurité peuvent travailler 15 ensemble et mettre en oeuvre un schéma de protection sophistiqué qui permette de mieux résister aux attaques qu'une unité isolée. Ainsi, si un programme comporte plusieurs morceaux de logiciel dont on veut protéger l'intégrité, plusieurs unités réalisant de telles 20 vérifications peuvent être utilisées pour protéger ces

différents morceaux.

Mais il semble que les pirates effectuent, sur le logiciel en composant "flash" dont ils ont récupéré l'image, plutôt des analyses d'ingénierie 25 inverse (ou "reverse engineering") "statique", c'est-àdire par simple examen du logiciel, que des analyses "dynamiques", c'est-à-dire en s'intéressant directement

au logiciel en cours d'exécution.

Il existe, en effet, de nombreux outils 30 d'investigation, par exemple sur des terminaux informatiques de type PC ("Personal Computers"), qui

SP 21976 DB

permettent à de nombreux pirates amateurs d'effectuer des analyses statiques, alors que pour effectuer des analyses dynamiques il est nécessaire de détenir, maîtriser et mettre en oeuvre des outils spécifiques. De 5 telles analyses dynamiques sont donc nettement plus délicates à réaliser, et ne sont donc à la portée que

de quelques spécialistes.

Dans des analyses statiques, étant donné que, dans leurs mises en oeuvre habituelles, les 10 morceaux de logiciels liés à l'authentification sont très localisés dans le logiciel en matériau "flash", il est relativement facile de les retrouver et de les

modifier sans avoir à suivre leurs exécutions.

L'invention a pour objet de pallier de tels 15 inconvénients.

EXPOS DE L'INVENTION

La présente invention concerne un procédé d'authentification d'un logiciel, qui comprend les étapes suivantes: - utilisation de plusieurs fonctions élémentaires de calcul et d'au moins une fonction de vérification disséminées dans l'ensemble dudit logiciel, - vérification au cours du déroulement du logiciel, à l'aide d'une fonction de vérification, de la 25 concordance d'un résultat de calcul obtenu à l'aide desdites fonctions élémentaires de calcul et d'un résultat- mémorisé au préalable, - lancement d'une procédure de défense s'il n'y a pas concordance, caractérisé en ce que

SP 21976 DB

- l'exécution dudit logiciel est entrecoupée par l'exécution desdites fonctions élémentaires de calcul disséminées, l'exécution d'une pluralité de fonctions élémentaires de calcul disséminées étant nécessaire à l'obtention d'un seul résultat de calcul. Avantageusement, ces étapes sont mises en

oeuvre pendant la phase d'initialisation du logiciel.

Dans une variante de réalisation, ce procédé comprend des étapes préalables de: - calcul de la signature du logiciel par un algorithme principal, - comparaison de la concordance de cette signature à un certificat de référence,

- lancement d'une procédure de défense s'il n'y a pas 15 concordance.

Dans cette variante, les fonctions de vérification sont de deux types des premières fonctions de vérification qui vérifient de façon directe ou indirecte, la concordance entre 20 la signature calculée par l'algorithme principal et le certificat de référence; - des secondes fonctions de vérification qui vérifient,

de façon directe ou indirecte, que le résultat obtenu avec les fonctions de calcul disséminées dans le 25 logiciel correspond à la valeur attendue.

L'invention concerne également un logiciel qui comprend plusieurs fonctions de calcul, et au moins une fonction de vérification, disséminées dans

l'ensemble de celui-ci.

SP 21976 DB

Les fonctions de calcul élémentaires mises

à contribution dans le procédé de l'invention ne sont pas nécessairement les mêmes d'une exécution à l'autre.

L'exécution du logiciel peut, en effet, dépendre de 5 paramètres ou de stimuli externes. Les fonctions de

vérification peuvent être exécutées à tout moment au long de la vie du logiciel. Aussi, pour qu'un pirate puisse invalider le test d'authentification de l'invention, il faut supprimer toutes les fonctions de 10 vérification, qui sont disséminées dans le logiciel.

Certaines branches du logiciel normalement non explorées lors d'un fonctionnement standard peuvent être mises à contribution sur réception de stimuli particuliers, permettant l'exécution de fonctions de 15 vérification jamais appelées auparavant. Ceci rend encore plus difficile l'invalidation de

l'authentification par des pirates.

BREVE DESCRIPTION DES DESSINS

- La figure 1 illustre un test d'intégrité 20 de l'art connu.

- La figure 2 illustre le procédé de l'invention. - La figure 3 illustre une variante du

procédé de l'invention.

DESCRIPTION D TAILL E DE MODES DE R ALISATION

Le procédé de l'invention consiste à faire exécuter des algorithmes d'authentification par des fonctions de calcul et de vérification disséminées dans 30 l'ensemble du logiciel à authentifier. Contrairement

SP 21976 DB

-7 aux procédés de l'art connu, l'authentification n'est pas exécutée selon un processus itératif ou linéaire,

mais au cours de l'exécution dudit logiciel.

En sachant qu'un logiciel est constitué 5 d'un ensemble de fonctions appelées en séquence, dans l'invention on insère dans certaines fonctions de ce logiciel des fonctions élémentaires de calcul de signature et des fonctions élémentaires de vérification. On s'assure alors que ces insertions ne 10 perturbent pas le fonctionnement normal de ce logiciel,

ce qui est à la portée de l'homme de métier.

Dans une mise en oeuvre habituelle, les algorithmes de calcul de signature et de vérification sont localisés en un ou plusieurs endroits du logiciel, 15 et sont exécutés une fois au cours du déroulement du logiciel, généralement pendant la phase

d'initialisation de celui-ci.

Dans la mise en oeuvre de l'invention, le calcul de signature est réparti géographiquement dans 20 l'ensemble du logiciel, et est exécuté au fil de l'exécution normale des fonctions du logiciel, avantageusement pendant la phase d'initialisation qui

est une phase de passage obligé de ce logiciel.

Une telle phase d'initialisation est ainsi 25 illustrée sur la figure 2 avec: x: représentant une fonction de calcul, o: représentant une fonction de vérification, Sur cette figure sont illustrés différents chemins possibles (ici au nombre de trois: chemins 10, 30 11 et 12) entre le début (point O) et la fin (point F) de cette initialisation. Le passage par l'un ou l'autre

SP 21976 DB

de ces chemins dépend de l'état dans lequel se trouve le logiciel en début d'initialisation: première initialisation, choix effectués préalablement Comme cela apparaît sur la figure 2, 5 certaines fonctions de calcul et de vérification ne

sont appelées pendant aucun de ces chemins.

Pour ne pas pénaliser les performances du logiciel, en termes de vitesse d'exécution et de taille, il n'est pas possible d'intégrer une fonction 10 élémentaire de calcul ou de vérification dans chaque fonction du logiciel. On choisit donc un nombre de telles fonctions de calcul ou de vérification disséminées dans le logiciel pour pouvoir mener à bien le calcul nécessaire à l'obtention d'une signature dans 15 un temps raisonnable selon l'algorithme de calcul retenu. Dans le procédé de l'invention, on s'assure

que les fonctions de calcul ont bien terminé leur calcul avant que les fonctions de vérification 20 n'entrent en oeuvre.

On vérifie donc expérimentalement à partir de quel moment, en fonction des différentes possibilités de déroulement du logiciel, les fonctions de vérification peuvent être rendues actives. 25 Dans une variante de réalisation du procédé de l'invention, on combine le procédé d'authentification de l'art connu, et le procédé cidessus, c'est-à-dire que: - d'une part, on vérifie la totalité du logiciel avec le procédé de l'art connu,

SP 21976 DB

- d'autre part, on vérifie l'intégrité de ce logiciel avec le procédé de l'invention, en vérifiant la signature obtenue par des fonctions disséminées de vérification. Ainsi, comme illustré sur la figure 3, si

les zones A, B et D d'une mémoire en matériau flash, par exemple, contiennent le logiciel à authentifier.

Des fonctions de calcul F, et des fonctions de

vérification Fv sont disséminées dans ces zones.

La zone B contient l'algorithme principal de vérification d'intégrité du logiciel, conformément au procédé de l'art connu. La zone C contient un certificat qui sert de référence pour l'authentification. Selon le procédé de l'art connu,

l'algorithme principal contenu dans la zone B calcule la signature du logiciel sur les zones A, B et D, en excluant le certificat contenu dans la zone C. La signature calculée est mémorisée, en utilisant une 20 technique d'obfuscation de code.

On vérifie alors, en utilisant par exemple

des fonctions de vérification, la concordance de cette signature avec ledit certificat de référence. S'il n'y a pas concordance, une procédure de défense peut alors 25 être lancée.

Après ce calcul qui a porté sur l'ensemble du logiciel, les fonctions de calcul F, disséminées dans le logiciel sont exécutées au fil de l'exécution du logiciel, selon, le procédé de l'invention. Ce 30 calcul porte, à la fois, sur l'algorithme principal

SP 21976 DB

contenu dans la zone B et sur les éventuelles fonctions de défense qui se trouvent également dans cette zone B. Dans cette variante, les fonctions de vérification peuvent donc être de deux types: - des premières fonctions de vérification qui vérifient de façon directe ou indirecte la concordance entre la signature calculée par l'algorithme principal et la valeur attendue, - des secondes fonctions de vérification qui vérifient 10 de façon directe ou indirecte que le résultat obtenu avec les fonctions de calcul F0 disséminées dans le

logiciel correspond à la valeur attendue.

Dans les deux cas, s'il n'y a pas

concordance des signatures, une procédure de défense 15 peut alors être lancée.

Dans un mode de réalisation préféré de l'invention on utilise l'algorithme de calcul HASH nommé SHAl. Ce dernier opère de la manière suivante 20 l.Remplissage de fichier SHA.1 est utilisé pour calculer un condensé de fichier ("file digest")pour un fichier qui est fourni comme entrée. Le fichier devrait être considéré 25 comme une chaîne de bits. La longueur du fichier est constituée par le nombre de bits dans le fichier (un fichier vide a une longueur 0). Si le nombre de bits dans un fichier est un multiple de 8, pour compactage on peut représenter le fichier en hexadécimal. Le but 30 d'un remplissage de fichier est de rendre la longueur totale du fichier rempli multiple de 512. SHA.1 traite

SP 21976 DB

1l séquentiellement des blocs de 512 bits lorsqu'il réalise le condensé de fichier. Ce condensé peut-être réalisé de la façon suivante. Comme un résumé, un "1" suivi par m "0" suivis par un entier de 64 bits sont 5 joints à la fin du fichier pour produire un fichier rempli d'une longueur 512* n. L'entier de 64 bits est la longueur du fichier original. Le fichier rempli est

alors traité par SHA.1 comme n blocs de 512 bits.

Si un fichier a une longueur (notée 1) 10 telle que: 1 2 A 64, avant qu'il ne soit entré dans SHA.1, le fichier est rempli sur la droite de la

manière suivante.

a. "1" est joint.

Par exemple, si le fichier original est 15 '01010000', il est complété à '010100001',

b. les "0" sont complétés.

Le nombre de "0" dépend de la longueur originale de fichier. Les derniers 64 bits du dernier bloc de 512 bits sont réservés pour la longueur 1 du 20 fichier original, Par exemple, si on suppose que le fichier original est la chaîne de bits:

01100001 01100010 01100011 01100100

Après l'étape (a) cela donne

01100001 01100010 01100011 01100100

01100101 1

Puisque 1 = 40, le nombre de bits ci-dessus

est 41 et 417 "0" sont joints, ce qui fait que le total 30 est maintenant 448.

SP 21976 DB

Cela donne (en hexadécimal):

61626364 65800000 00000000 00000000 00000000 00000000 00000000 00000000 5 00000000 00000000 00000000 00000000

00000000 00000000

c. On obtient la représentation 2-mots de

1, le nombre de bits dans le fichier original. Si 1 < 2 A 32 alors le mot est composé de "0". On joint ces deux 10 mots au fichier complété.

Par exemple, on suppose que le fichier original est comme dans (b). Alors 1 = 40 (on note que 1 est calculé avant tout remplissage). La représentation deux mots de 40 est (en hexadécimal): 15 00000000 00000028. En conséquence le fichier complété (en hexadécimal):

61626364 65800000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 20 00000000 00000000 00000000 00000028

Le fichier complété contient 16 * n mots pour quelques n > 0. Le fichier complété est regardé comme une séquence de n blocs M(1), M(2), premiers caractères (ou bits) du fichier. 25

2. Fonctions et constantes utilisées.

Une séquence de fonctions logiques f (0), f(l)...... f(79) est utilisée dans SHA.1 Chaque f(t), avec 0s t s79 fonctionne sur trois mots de 32 bits B,C,D et 30 produit un mot de 32 bits comme sortie. f(t,B,C,D) est défini comme suit pour des mots B,C,D

SP 21976 DB

f(t; B,C,D)=(B AND (0 t - 19)

C) OR ((NOT B) AND D)

K(1),...K(79) sont donnés f(t; B,C,D)= B XOR C XOR D (20 t s =39) f(t; B,C,D)=(B AND C) OR (B AND D) OR (C AND D) (40 s t s 59) f(t,B,C,D) = B XOR C XOR D (60s t s79). Une séquence de mots constants K(0), est utilisée dans SHA.1. En hexadécimal ils par: K(t) = 5A827999 (0 s t s 19) K(t) = 6ED9EBA1 (20 s t s 39) K(t) = 8F1BBCDC (40 s t s 59)

K(t) = CA62C1D6) (60 s t s 79).

3. Calcul du condensé de fichier Le condensé de fichier est calculé en utilisant le fichier rempli comme décrit ci-dessus. Ce calcul est décrit en utilisant deux buffers, chacun comprenant cinq mots de 32 bits, et une séquence de 80 20 mots de 32 bits. Les mots des premier buffers de 5 mots

sont appelés A,B,C,D,E. Les mots des seconds buffers de 5 mots sont appelés H0, HI, H2, H3 et H4. les mots de la séquence de 80 mots sont appelés W(0), W(1)....W(79).

Un buffer de mot seul TEMP est aussi utilisé.

Pour générer le condensé de fichier, des blocs de 16 mots M(l),M(2)...M(n) sont traités dans l'ordre. Le traitement de chaque M(i) comprend 80 étapes.

Avant le traitement de tout bloc, les H 30 sont initialisés comme suit (en hexadécimal): -

SP 21976 DB

10 H0 = 67452301 Hi = EFCDAB89 H2 = 98BADCFE H3 = 10325476 H4 = C3D2ElF0 Maintenant M(1), M(2),, M(n) sont traités. Pour traiter M(i) on réalise:

a. Division de M (i) en 16 mots W(0), W(1),..W(15), o W(0) est le mot le plus à gauche.

b. Pour t = 16 à 79 W(t) = SAl(W(t-3) XOR W (t-8) XOR (t-14)

XOR W(t-16)).

c. A =HO,B = H1,C=H2,D=H3,E=H4.

d. Pour t= 0 à 79 TEMP = SA5(A)+f(t;B,C,D) + E + W(t) + K(t)

E = D; D = C; C = S A 30 (B): B =A; A =

TEMP e. H0 = H0 + A, Hi = HI +B,H2 = H2 + C?H3

=H3 + D, H4 = H4 + E.

Après traitement de M(n), le condensé de fichier est la chaîne de 160 bits représentée par les 5 mots:

H0 Hi H2 H3 H4.

Selon l'invention, l'algorithme décrit cidessus est décomposé en N fonctions de calculs qui sont disséminées par intermittence avec des portions du logiciel. N fonctions de calcul sont nécessaires pour obtenir un seul condensé de fichier, c'est à dire un 30 résultat de calcul selon l'invention.

SP 21976 DB

REFERENCES

[1] "Dynamic Self-Checking Techniques for Improved Tamper Resistance" de Bill Horne, Lesley Matheson, Casey 5 Sheehan et Robert E. Tarjan (présenté dans le cadre du séminaire ("Workshop") DRM ("Digital Rights Management") de l'ACM ("Association for Computing Machinery") en 2001)

[2]

"Protecting Software Code by Guards" de Hoi Chang et Mikhail D. Attallah "(présenté dans le cadre du séminaire ("Workshop") DRM ("Digital Rights Management") de l'ACM ("Association for Computing 15 Machinery") en 2001)

SP 21976 DB

Claims

REVENDICATIONS

1. Procédé d'authentification d'un logiciel, qui comprend les étapes suivantes: - utilisation de plusieurs fonctions élémentaires de calcul et d'au moins une fonction de vérification disséminées dans l'ensemble dudit logiciel, - vérification au cours du déroulement du logiciel, à l'aide d'une fonction de vérification, de la 10 concordance d'un résultat de calcul obtenu à l'aide desdites fonctions élémentaires de calcul et d'un résultat mémorisé au préalable, - lancement d'une procédure de défense s'il n'y a pas concordance, caractérisé en ce que - l'exécution dudit logiciel est entrecoupée par

l'exécution desdites fonctions élémentaires de calcul disséminées, l'exécution d'une pluralité de fonctions élémentaires disséminées étant nécessaire 20 à l'obtention d'un seul résultat de calcul.

2. Procédé selon la revendication 1, dans lequel ces étapes sont mises en oeuvre pendant la phase d'initialisation du logiciel. 25

3. Procédé selon la revendication 1, comprenant des étapes préalables de - calcul de la signature du logiciel par un algorithme principal, - comparaison de la concordance de cette signature à un certificat de référence,

SP 21976 DB

- lancement d'une procédure de défense s'il n'y a pas concordance.

4. Procédé selon la revendication 3, dans 5 lequel les fonctions de vérification sont de deux types: - des premières fonctions de vérification qui vérifient de façon directe ou indirecte la concordance entre la signature calculée par 10 l'algorithme principal et le certificat de référence; - des secondes fonctions de vérification qui vérifient

de façon directe ou indirecte que le résultat obtenu avec les fonctions de calcul disséminées dans le 15 logiciel correspond à la valeur attendue.

SP 21976 DB