T 1216/08 (Authenticating a program image/ROVI) 13-01-2012

Reasons for the Decision

The Invention

1. The invention deals with the authen tication of software in a dynamic loading environment (description as pub lished, p. 1, lines 20-21). It is known to calculate an electronic signature for the image of a given pro gram (a "disk image", see p. 1, line 12) so that by authen ticating that signature later it can be deter mined whether the program image was changed. If the program image normally does not change a failure to authen ti cate the signature may be taken to indicate that the program image was tampered with and should, hence, be rejec ted as insecure. This approach fails however if the program image contains pointers which are legi ti mately modified du ring program loading and linking (p. 1, lines 17-19; page 5 as pub lished, lines 13-17). To address this prob lem, the in ven tion proposes to de ter mine in a given pro gram image the "pointers that are in need of fixing up" and to sign, instead of the en tire program image, only "selected content of the pro gram image" excluding these pointers (see e.g. present claim 1).

Article 84 and Rule 29(2) EPC 1973, and Article 123(2) EPC

2. The description and the original claims consistently refer to an "executable image" which contains pointers to be fixed up and which is electronically signed ex clu ding these pointers.

2.1 In the present claims and the amended description pages the term "executable image" was replaced by "pro gram image". On amended page 4 a short explanation was added to the effect that the term used in the claims differs from the term used in the description but that they are meant to be equivalent.

2.2 It is unambiguous from the description (see e.g. p. 1, lines 7-22) that the "executable image" refers to the image of a computer pro gram, hence a "program image". It is also directly and unambiguously evident for the skilled person (e.g. from the independent claims) that what the de scrip tion refers to as an "executable image" is execu table only to the extent to which poin ters "in need of fixing up" have actually been "fixed up" (p. 1 as published, lines 14-16). The board hence considers that the re place ment of the term "executable image" by "pro gram image" and the new paragraph on page 4, as well as the corresponding amend ment to claim 18, do not extend be yond the application as origi nally filed.

2.3 Claim 23 was amended to specify that the "selected content" of the program image which is electronically signed excludes not just some but "each pointer ... in need of fixing up". This adapts claim 23 to original claim 1.

2.4 The other amendments to the claims constitute refor mu la tions without any change in substance. The board is thus satisfied that amended claims 1-30 comply with the requirements of Article 123(2) EPC.

3. The amended claims contain a single independent sys tem claim 1 and a single corresponding independent method claim 23. The conciseness objection pursuant to Rule 29(2) EPC 1973 is thus moot. The board is also satisfied that the amen ded claims are clear, in compliance with Article 84 EPC 1973.

The Prior Art

4. Document D2 is concerned with chip cards which allow the dynamic loading and linking of additional program modules (p. 1, lines 6-8). D2 observes that the dynamic linking is too demanding of memory to be executed on-card (p. 2, lines 28-31) but that it would compro mise security if the linking would take place in the card terminal (p. 2, lines 15-20). In this context D2 mentions the problem that the chip card cannot check a statically predefined signature of the program in question because the linking process must resolve the symbolic references (p. 2, lines 22-26). Therefore, it is proposed to split the linking process into a complex prelinking step which leaves for the second step only the resolution of the symbolic refe rences; Only the second step will be performed on card (cf. p. 5, lines 16-23; p. 8, lines 26-29). D2 dis closes that after the prelinking "the code" can be signed, and that the signed code will be linked and verified on card (p. 8, lines 29-32).

5. Document D1 is concerned with maintaining the guaran teed integrity of a verified architecture-neutral pro gram ANP (e.g. written in Java) when on the other hand the program should be compiled so as to increase execu tion speed (p. 2, lines 3-5 and 29-40). The solution accor ding to D1 is to package an architecture neutral program ANP (i.e. source code) together with its com piled version in an architecture specific - i.e. com piled - version ASP and three signatures (see p. 6, lines 25-36 and fig. 3), namely the signature of the program provider (the "original party", OrigParty, in dex OC) applied to the ANP and the signatures of the compiler (index C) and the "compiling party" (CompParty, index CP), respectively, applied to the ASP.

Novelty

6. The appellant argues (grounds of appeal, p. 4) that D2 would not anticipate the claimed invention because D2:

a) is not concerned with the authenticity of an execu table image,

b) has no reference to pointers that need to be fixed up,

c) does not generate a digital signature based upon the content of an image

d) does not generate an authenticity digital signature based upon the content of an executable image,

e) does not compare the two signatures, and

f) does not disclose the generation of a signature from content from which the pointers requiring fixing up have been excluded.

Since the term "executable image" was replaced by "pro gram image" in order to clarify the claims without changing their scope the board assumes the appellant to maintain with regard to the amended claims that D2

a') is not concerned with the authenticity of a program image as claimed, and

d') does not generate an authenticity digital signature based upon the content of a program image as claimed.

7. The board disagrees with the appellant as regards features a/a' and b-e.

7.1 Re. b: The board concurs with the examining division that the symbolic references which the program loader resolves according to D2 read on the "pointers that are in need of fixing up" according to the invention.

7.2 Re. a/a' and c: The board agrees that the term "authen ti ca tion" is not used literally in D2. However, the con cept of authentication is disclosed in D2. Authenti ca tion of code means verification that a piece of code is the expected one. Thus where D2 addresses the prob lem that code might be manipulated between the terminal and the card (p. 2, lines 18-20) the skilled person would clearly under stand this as a reference to code authentication.

Furthermore, the "code" signed according to D2 (cf. page 8, lines 30-31) requires only final linking (cf. p. 5, lines 19-21) before it can be executed on the card and therefore is a program image in the sense of the independent claims which also contains pointers "in need of fixing up" before it can be executed.

Therefore, the digital signature genera ted for the code according to D2 also qualifies as an "authen ticity digital signature based upon the content of a program image" as claimed.

7.3 Re. d/d' and e: On page 8 (lines 29-31) D2 does not spe ci fy any details about the signature or the verifi cation process. It is clear, however, in the board's view that the signature verification referred to on page 8 is meant to implement the signature verification discussed on page 2 (esp. lines 22-26) because D2 proposes the two-step linking process specifically in order to enable the signature verification which traditional linking does not allow (p. 3, lines 16-21).

D2 discloses that a statically predefined signa ture of the program cannot be checked if and because the linking process changes the program (loc. cit.). For the skilled person this statement implies that the desired verification involves the comparison of two signatures as claimed.

Thus the board concurs with the examining di vision that D2 discloses features d (resp. d') and e, too.

8. The board however agrees with the appellant as regards feature f.

8.1 The board understands the examining division's argument to be as follows (see communication of 30 October 2007, point 3.1, item e):

i) The "code" signed after the prelinking process of D2 (see p. 8, lines 30-31) must be identified with the term "object code" as used elsewhere in D2 (see p. 6, last par. and fig. 1). Because the "object code" according to D2 is clearly distinct from the symbo lic references this argument implies that D2 dis clo ses signing only "selected content exclud[ing the] pointer[s] ... in need of fixing up".

ii) The examining division further argues (loc. cit., last sentence) that the problem defined in D2, name ly that changed modules cannot be verified, would not be solved if the object code including the sym bo lic references were signed.

8.2 The board disagrees with both considerations.

i) D2 does not imply the identi fi cation of the terms "code" and "object code". In the board's view, the skilled person would identify the term "der Code" in the phrase "Nach dem prelink Prozeß kann der Code sig niert werden" (p. 8, lines 29-30) with the entire output of the prelinking process (including the sym bolic reference) rather than only the "object code" (excluding the references).

ii) D2 discusses the problem that verification of pro gram signatures is impossible when it requires the comparison of a program before linking with a pro gram after linking (p. 2, lines 22-26). As a solu tion for this problem D2 discloses the option to run the entire linker on-card. This would allow, as is implied by D2, the verification of the original program against the loaded program before linking. This option is dismissed in D2 because it would exceed the memory resources available on the card.

The prelinking process according to D2 produces object code packaged with symbolic references which remain to be resolved in the second linking step. D2 discloses that the signed code will be linked and ve ri fied "during" the loading process (p. 8, lines 30-32). In the board's view, the skilled person would understand that this phrase refers to linking and verification as two logically distinct steps per formed during loading. On this understanding, the signed code could be verified on the card before the final linking step.

Therefore, the problem of D2 is indeed solved when the entire output of the prelinking pro cess is signed. Thus the interpretation according to point i) is not in conflict with the problem addressed by D2.

8.3 The board therefore concludes that by virtue of feature f the subject matter of independent claims 1 and 23 is new over D2 in the sense of Article 54(1)(2) EPC 1973.

8.4 According to D1 the electronic sig na tures are generated on the basis of a program before or after compilation (ANP and ASP; cf. p. 4, lines 50-52; p. 6, lines 3-5 and 12-14). More specifi cally, the digital signature is based on a hash func tion calcula ted "on the data bits of the ANProgram code" or the "ASProgram code" (cf. p. 4, lines 52-54; p. 6, lines 5-6 and 14-19). The skilled person would understand this as meaning that the elec tro nic signatures are generated from the entire pro grams rather than only from selected content, let alone from content selected by exclusion of pointers. Hence, the subject matter of claims 1 and 23 is also new over D1 by virtue of feature f.

Inventive Step

9. Although the decision was only based on lack of novelty as far as the independent claims were concerned, the board deems it appropriate in the present case to exer cise its power under Article 111(2) EPC and to con si der inventive step as well.

10. Document D2 constitutes the most pertinent document on file because it also addresses the problem of authen ti cating an electronically signed program in the context of linking.

10.1 The solution according to D2 provides that code authen tication is possible on the card up until the final lin king step but not after that. This is sufficient to authenticate a program loaded onto the card before it is run and to run only programs which have not been tampered with before loading (p. 2, lines 15-20).

10.2 Beyond D2, by virtue of feature f the claimed invention enables code authentication also after final linking or even after the program has been executing for some time (cf. application as published, p. 1, lines 21-23 and p. 9, lines 17-19). Feature f hence further increases the se cu rity of the system according to D2.

10.3 While increased security is an obvious desirable in general, D2 does not specifically disclose the need for code authentication after linking (p. 2, lines 15-20). This omission is consistent with the appa rent assump tion in D2 that the chip card itself is safe (see e.g. p. 2, lines 26-27). The board thus con si ders that D2 contains no prompt to increase the se cu rity by enabling run-time code authentication on the chip card, nor does it suggest to achieve this by means of feature f. Also D1 cannot, in the board's view, suggest this feature be cause D1 does not even disclose the general authen ti cating problem in the context of linking.

10.4 In the board's judgement thus the subject matter of claims 1 and 23 is not obvious over D2 alone or in combination with D1.

10.5 In the board's judgment thus claims 1 and 23 are based on an inventive step over the prior art to hand in the sense of Article 56 EPC 1973.