WO2004032329A2

WO2004032329A2 - Software and method for authenticating same

Info

Publication number: WO2004032329A2
Application number: PCT/FR2003/050074
Authority: WO
Inventors: Jean-Claude Sarfati; Alain Lecaer
Original assignee: Canal + Technologies
Priority date: 2002-10-04
Filing date: 2003-10-02
Publication date: 2004-04-15
Also published as: WO2004032329A3; FR2845494A1; FR2845494B1; AU2003288371A1; AU2003288371A8

Abstract

The invention concerns a method for authenticating a software, comprising the following steps: verifying during the running of the software the conformity of an authentication result obtained by means of at least one computational algorithm and a previously stored result; launching a defence procedure in case of non-conformity, wherein the authentication algorithms are executed by several elementary computing functions and at least one verification function embedded in the entire software, during normal execution of the functions of said software.

Description

SOFTWARE AND METHOD FOR AUTHENTICATING SAME

DESCRIPTION

TECHNICAL FIELD The present invention relates to software and an authentication method thereof, in particular in the field of digital television decoders.

STATE OF THE PRIOR ART In the devices of the known art, an integrity test of an on-board software is generally carried out by calculating, using an external tool, a reference signature representative of this software and in inserting it into this one. During the software initialization phase, the software calculates its own signature and compares this signature with the reference signature. If these signatures are different, the software runs software specific to a defense procedure, otherwise it continues normally. This succession of steps is illustrated in FIG. 1.

In the case of authentication of such software, we want to ensure the origin of it. A known solution consists in taking the principle of the integrity test and combining it with an asymmetric cryptographic algorithm: the reference signature is encrypted with a private key and the result is integrated, in the form of a certificate, into the software. During the control phase, the reference signature is decrypted with an integrated public key to the software before being compared to the reference signature.

Such embedded software can therefore be attacked by pirates ("hackers") trying to modify the functionality of said software to their advantage. An authentication makes it possible to detect any unauthorized modification of the software, that is to say without an associated certificate.

Authentication relies entirely on software parts. Hackers can carry out attacks with varying degrees of ease. They can try to change the public key, reverse the signature equality test, short-circuit the entire verification ... A first document of known art, referenced [1] at the end of the description, describes a software self-checking mechanism designed to improve the resistance of this software against manipulation. This mechanism consists of a set of pieces of software, or "testers", which redundantly test the possible existence of changes in executable software during its execution, and which highlight such modifications. Each "tester" tests a small piece of contiguous software, and compares a calculated value to a known correct value. Each "tester" is tested by several others. The decommissioning of one or more of these "testers" by modifying them is thus detected by the unmodified "testers". A second document of known art, referenced [2] at the end of the description, describes the protection of software against modifications illegitimate from its users. Protection and resistance to manipulation of the software are achieved by using a network of security units, or "guards", dispersed in a program, which work together. Each of these units is a piece of software capable of performing certain safety-related actions during the execution of the program. The units can be programmed to perform any calculation, for example the calculation of a checksum of another piece of software during its execution, to verify its integrity. These security units can work together and implement a sophisticated protection scheme that allows them to resist attacks better than an isolated unit. Thus, if a program comprises several pieces of software whose integrity is to be protected, several units carrying out such verifications can be used to protect these different pieces.

But it seems that the hackers carry out, on the software by composing "flash" of which they recovered the image, rather analyzes of reverse engineering (or "reverse engineering") "static", that is to say by simple software review, only. "dynamic" analyzes, that is to say by taking an interest directly in the software being executed.

There are, in fact, many investigative tools, for example on computer terminals of the PC ("Personal Computers") type, which allow numerous amateur hackers to carry out static analyzes, while to carry out dynamic analyzes it is necessary to possess, master and implement specific tools. Such dynamic analyzes are therefore much more difficult to carry out, and are therefore only available to a few specialists.

In static analyzes, given that, in their usual implementations, the pieces of software linked to authentication are very localized in software in "flash" material, it is relatively easy to find and modify them without have to follow their executions.

The object of the invention is to overcome such drawbacks.

PRESENTATION OF THE INVENTION The present invention relates to a method for authenticating software, which comprises the following steps:

- verification during the course of the software of the concordance of a calculation result obtained using at least one authentication algorithm and a previously stored result,

launching of a defense procedure if there is no agreement, characterized in that the authentication algorithms are executed by several elementary calculation functions and at least one verification function disseminated throughout the software, during normal execution of the functions of this software. Advantageously, these steps are implemented during the software initialization phase. In an alternative embodiment, this method comprises preliminary steps of:

- calculation of the software signature by a main algorithm, - comparison of the concordance of this signature with a reference certificate,

- launch of a defense procedure if there is no match.

In this variant, the verification functions are of two types:

- the first verification functions which verify, directly or indirectly, the concordance between the signature calculated by the main algorithm and the reference certificate; - second verification functions which verify, directly or indirectly, that the result obtained with the calculation functions disseminated in the software corresponds to the expected value.

The invention also relates to software which comprises several calculation functions, and at least one verification function, scattered throughout it.

The elementary calculation functions used in the method of the invention are not necessarily the same from one execution to another. The execution of the software may, in fact, depend on external parameters or stimuli. Verification functions can be performed at any time during the life of the software. Also, so that a hacker can invalidate the authentication test of the invention, all the functions of verification, which are scattered throughout the software. Certain branches of the software normally not explored during standard operation can be called upon upon receipt of particular stimuli, allowing the execution of verification functions never called before. This makes it even more difficult to invalidate authentication by hackers.

BRIEF DESCRIPTION OF THE DRAWINGS - Figure 1 illustrates an integrity test of known art.

- Figure 2 illustrates the process of the invention.

- Figure 3 illustrates a variant of the method of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

The method of the invention consists in executing authentication algorithms by calculation and verification functions scattered throughout the software to be authenticated. Unlike the methods of the known art, authentication is not performed according to an iterative or linear process, but during the execution of said software. Knowing that a software consists of a set of functions called in sequence, in the invention is inserted into certain functions of this software elementary functions of signature calculation and elementary functions of verification. We then ensure that these insertions do not not interfere with the normal operation of this software, which is within the reach of those skilled in the art.

In a usual implementation, the signature calculation and verification algorithms are located in one or more places of the software, and are executed once during the course of the software, generally during the initialization phase of the latter.

In the implementation of the invention, the signature calculation is distributed geographically throughout the software, and is executed during the normal execution of the software functions, advantageously during the initialization phase which is a phase of compulsory passage of this software. Such an initialization phase is thus illustrated in FIG. 2 with: x: representing a calculation function, o: representing a verification function,

In this figure are illustrated different possible paths (here three in number: paths 10, 11 and 12) between the start (point 0) and the end (point F) of this initialization. The passage by one or the other of these paths depends on the state in which the software finds itself at the start of initialization: first initialization, choices made beforehand ...

As shown in FIG. 2, certain calculation and verification functions are not called during any of these paths.

In order not to penalize the performance of the software, in terms of execution speed and size, it is not possible to integrate a basic calculation or verification function in. software function. We therefore choose a number of such calculation or verification functions disseminated in the software in order to be able to carry out the calculation necessary to obtain a signature in a reasonable time according to the chosen calculation algorithm.

In the method of the invention, it is ensured that the calculation functions have indeed completed their calculation before the verification functions are implemented.

We therefore verify experimentally from what point, depending on the different possibilities for running the software, the verification functions can be made active.

In an alternative embodiment of the method of the invention, the authentication method of the known art is combined with the above method, that is to say that: on the one hand, the all of the software with the method of the known art, - on the other hand, the integrity of this software is verified with the method of the invention, by verifying the signature obtained by disseminated verification functions.

Thus, as illustrated in FIG. 3, if zones A, B and D of a memory made of flash material, for example, contain the software to be authenticated.

Computation functions F _c and verification functions F _v are scattered in these areas.

Zone B contains the main software integrity verification algorithm, in accordance with to the process of known art. Zone C contains a certificate which serves as a reference for authentication.

According to the method of known art, the main algorithm contained in zone B calculates the signature of the software on zones A, B and D, excluding the certificate contained in zone C. The calculated signature is memorized, using a code obfuscation technique. We then verify, by using for example verification functions, the concordance of this signature with said reference certificate. If there is no match, a defense procedure can then be launched. After this calculation which relates to the whole of the software, the calculation functions F _c disseminated in the software are executed during the execution of the software, according to the method of the invention. This calculation relates both to the main algorithm contained in zone B and to the possible defense functions which are also found in this zone B. In this variant, the verification functions can therefore be of two types:

- first verification functions which verify, directly or indirectly, the agreement between the signature calculated by the main algorithm and the expected value,

- second verification functions which verify directly or indirectly that the result obtained with the calculation functions F _c disseminated in the software corresponds to the expected value. In both cases, if the signatures do not match, a defense procedure can then be launched.

In a preferred embodiment of the invention, the HASH calculation algorithm called SHAl is used. The latter operates as follows:

1.Fill of file SHA.l is used to calculate a digest of file ("file digest") for a file which is provided as input. The file should be treated as a bit string. The length of the file is made up of the number of bits in the file (an empty file has a length of 0). If the number of bits in a file is a multiple of 8, for compacting the file can be represented in hexadecimal. The purpose of file filling is to make the total length of the filled file multiple of 512. SHA.l processes blocks of 512 bits sequentially when it performs the file digest. This summary can be carried out in the following manner. As a summary, a "1" followed by m "0" followed by a 64-bit integer is appended to the end of the file to produce a filled file of length 512 * n. The 64-bit integer is the length of the original file. The filled file is then treated by SHA.l as n blocks of 512 bits.

If a file has a length (denoted 1) such as: 1 <2 Λ 64, before it has entered SHA.l, the file is filled on the right as follows. at. "1" is attached. For example, if the original file is '01010000', it is completed with '010100001', b. the "0" are completed.

The number of "0" depends on the original file length. The last 64 bits of the last block of 512 bits are reserved for the length 1 of the original file,

For example, if we assume that the original file is the bit string: 01100001 01100010 01100011 01100100

01100101

After step (a) this gives

01100001 01100010 01100011 01100100 01100101 1 Since 1 = 40, the number of bits above is 41 and 417 "0" are joined, so the total is now 448.

This gives (in hexadecimal):

61626364 65800000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c. We get the 2-word representation of

1, the number of bits in the original file. If 1 <2 Λ 32 then the word is made up of "0". These two words are attached to the completed file.

For example, assume that the original file is like in (b). Then 1 = 40 (we note that

1 is calculated before any filling). The representation two words of 40 is (in hexadecimal):

00000000 00000028. Consequently the completed file

(in hexadecimal):

61626364 65800000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000028 The completed file contains 16 * n words for a few n> 0. The completed file is viewed as a sequence of n blocks M (l), M (2), first characters (or bits) of file.

2. Functions and constants used.

A sequence of ^" logical f (0), f (l) f (79) functions is used in SHA.l Each f (t), with

O≤ t <79 operates on three 32-bit words B, C, D and produces a 32-bit word as output, f (t, B, C, D) is defined as follows for words B, C, D f (t; B, C, D) = (B AND C) OR ((NOT B) AND D) (0 t <19) f (t; B, C, D) = B XOR C XOR D (20 ≤ t <= 39) f (t; B, C, D) = (B AND C) OR

(B AND D) OR (C AND D) (40 <t ≤ 59) f (t, B, C, D) = B XOR C XOR D (60 <t <79). A sequence of constant words K (0),

K (l), ... K (79) is used in SHA.l. In hexadecimal they are given by:

K (t) = 5A827999 (0 ≤ t <19)

K (t) - 6ED9EBA1 (20 ≤ t ≤ 39) K (t) = 8F1BBCDC (40 ≤ t <59)

K (t) = CA62C1D6) (60 ≤ t ≤ 79). 3. Calculation of the file digest

The file digest is calculated using the completed file as described above. This calculation is described using two buffers, each comprising five 32-bit words, and a sequence of 80 32-bit words. The words of the first buffers of 5 words are called A, B, C, D, E. The words of the second 5-word buffers are called HO, Hl, H2, H3 and H4. the words in the 80-word sequence are called {0), W (1) .... W (79). A single TEMP word buffer is also used.

To generate the file digest, blocks of 16 words M (l), M (2) ... (n) are processed in order. The processing of each M (i) comprises 80 steps.

Before the processing of any block, the Hs are initialized as follows (in hexadecimal):

H0 = 67452301

Hl ≈ EFCDAB89 H2 = 98BADCFE

H3 = 10325476

H4 = C3D2E1F0

Now M (l), (2),, M (n) are processed. To treat M (i) we carry out: a. Division of M (i) into 16 words (0),

W (l), ..W (15), where 11 (0) is the leftmost word. b. For t ≈ 16 to 79 (t) “S ^Λ l (W (t-3) XOR W (t-8) XOR (t-14) XOR W (t-16)). vs. A = HO, B = H1, C = H2, D = H3, E = H4. d. For t = 0 to 79

TEMP = S ^Λ 5 (A) + f (t; B, C, D) + E + W (t) + K (t) E = D; D = C; C = S Λ 30 (B): B = A; A = TEMP e. HO = HO + A, Hl = Hl + B, H2 = H2 + C? H3 ≈H3 + D, H4 = H4 + E. After processing M (n), the file digest is the 160-bit string represented by the 5 words:

H0 Hl H2 H3 H4.

According to the invention, the algorithm described above is broken down into N calculation functions which are disseminated intermittently with portions of the software. N calculation functions are necessary to obtain a single digest of file, that is to say a calculation result according to the invention.

REFERENCES

[1 ^]

"Dynamic Self-Checking Techniques for Improved Tamper Résistance" by Bill Horne, Lesley Matheson, Casey Sheehan and Robert E. Tarjan (presented during the ACM ("orkshop") DRM ("Digital Rights Management") seminar ( "Association for Computing Machinery") in 2001)

[2]

"Protecting Software Code by Guards" by Hoi Chang and Mikhail D. Attallah (presented in the framework of the DRM ("Workshop") DRM ("Digital Rights Management") seminar of the ACM ("Association for Computing Machinery") in 2001)

Claims

1. Method for authenticating software, which comprises the following steps: - verification during the course of the software of the concordance of n calculation result obtained using at least one authentication algorithm and d '' a result previously saved,

- launch of a defense procedure if there is no agreement, characterized in that the authentication algorithms are executed by several elementary calculation functions and at least one verification function disseminated throughout the software, during normal execution of the functions of this software.

2. Method according to claim 1, in which these steps are implemented during the software initialization phase.

3. Method according to claim 1, comprising preliminary steps of:

- calculation of the software signature by a main algorithm,

- comparison of the consistency of this signature with a reference certificate,

- launch of a defense procedure if there is no match.

4. Method according to claim 3, in which the verification functions are of two types:

- the first verification functions which verify, directly or indirectly, the agreement between the signature calculated by the main algorithm and the reference certificate;

- second verification functions which verify directly or indirectly that the result obtained with the calculation functions disseminated in the software corresponds to the expected value.

5. Software, characterized in that it comprises several calculation functions, and at least one verification function, scattered throughout it.