T 1563/17 (Booting untrusted software) 07-05-2019

The invention

1. The application considers the situation in which a "third party" or "contract manufacturer" manufactures a computing device on behalf of an "Original Equipment Manufacturer" (OEM) (see paragraphs 2 and 26). In the eventually delivered product, only trusted operating systems should be executed; trust may be established with cryptography (see paragraph 3). During manufacture, however, it may be convenient to allow the execution of operating systems which are unsigned or only signed by an entity not trusted by the OEM (see paragraph 28).

1.1 To deal with this situation, the invention proposes to provide the device with two modes: "factory mode" and "product mode" (see figure 2).

1.2 In product mode, only "secure boots" are allowed (figure 3, nos. 304, 306 and 308). In factory mode, however, a limited number of "insecure boots" is allowed (see figure 3, nos. 310 and 312) - i.e. the booting of an operating system not signed by a trusted entity (see figure 3, no. 306, and paragraphs 28 and 38) - during which the access to a "security block" is disabled (see figure 3, no. 316; paragraphs 6 and 42-44; and original claim 2). At the latest when this number has been reached, factory mode is left (see figure 3, no. 320, and paragraph 29).

1.3 The security block is disclosed as containing, inter alia, device-specific cryptographic keys (see paragraph 42) or "user-specific data" (or "user data", see paragraphs 47 and 48). Where user data "is not stored in or protected by the security block", it may be deleted when access to the security block is disabled (paragraph 48).

The prior art

2. D1 addresses the problem of enabling a "third party to perform testing, debugging and servicing of [an] electro­nic device and its software without risking that the third party is given access to [sensitive] informa­tion" (see paragraph 6). As a solution, D1 discloses a system which has two operating modes, a secure one for standard usage and an "insecure" one for testing or debugging. The secure mode is said to be the "normal" mode (see paragraph 12 and figure 2, box 2 from the top). In the secure mode, access to certain "security related data" is allowed, in the insecure mode it is inhibited (loc. cit. and abstract). During the boot procedure, the system of D1 checks the signatures "for the first protected applications and operating system" (see paragraph 31, and figure 2, box 3 from the top). When the signatures are correct, the application and the operating system are downloaded in the secure environment RAM (paragraph 31; figure 2, box 4 from the top, left branch; and figure 1) and both execute in secure mode. When the signature check fails or no sig­na­ture is present, unsecure mode is activated and the non-verified application is loaded into a RAM outside the secure environment (paragraph 32, and figure 2, right branch). What happens with a non-verified operating system in this case is not specifi­cally disclosed. At the latest after a fixed time period, the system returns to secure mode (see paragraphs 31 and 32, and figure 2).

3. D2 discloses a device with a TCG ("Trusted Computing Group") compliant trusted component (abstract; see also figures 6 and 7, no. 120) and a "secure boot process". Depending on whether, during that process, integrity of the trusted component can be verified, the device will "operate in accordance with" one of two "security policies". The "first se­curity policy", used in case of successful verifica­tion, allows access to certain confi­­dential data; the "second" one, used in case of failure, does not (see paragraphs 35, 71 and 76-79, figure 4 and 9).

4. D3 discloses a device operating in one of two modes called "secure mode" and "production mode", the latter of which allows debugging and testing by "bypassing trust evaluation" (see figure 5, nos. 502A and 502B, and paragraphs 43-45).

5. D4 discloses another circuit with two modes of operation, a secure mode and a non-secure mode. The circuit stores "circuit identification information" indicating whether it is a "test circuit" or a "production circuit" (see paragraphs 12 and 28). For production circuits the secure mode is entered in which security checks are enforced. For test circuits, security checks may be bypassed and non-secure access to certain information or registers is allowed (see paragraphs 13 to 15, 25 and 29, figure 2).

Inventive step

6. The decision used D1 to assess inventive step.

6.1 D1 discloses that the operating system is checked in place but not, as claimed, that:

(i) the operating system is loaded before being tested (see also the decision, point 2.2 a) of the reasons).

6.2 The operating system in D1 is held in local ROM and thus need not be loaded to be validated (see para­graphs 22 and 31). However, it would have been an obvious alternative to load the operating system from an external source, for instance, so as to allow for new and corrected versions of the operating system and so that the latest version of the operating system would always be used (see the decision, point 2.2.1 of the reasons). In this situation, the board agrees with the examining division that it would have been obvious that the loading would have to precede the validation. Therefore, feature (i) cannot represent an inventive step over D1.

6.3 In D1, the decision whether execution is to take place in the secure or the insecure mode is made depending on the result of the signature check (see figure 2). In contrast, D1 does not disclose that:

(ii) the two claimed modes are determined before - and thus independent of - the authentication of the operating system.

Accordingly, the insecure and secure modes of D1 must be compared to the two alternatives within the "factory mode" rather than with the factory and product modes, respec­tively. In passing, the board notes that the names of the two modes, "factory mode" and "product mode", do not, per se, imply any specific limitation on the claimed subject-matter and thus do not constitute a separate difference.

6.4 D1 discloses a method of determining whether a given ope­rating system is signed and of executing at least the signed operating system (see paragraph 31). It further disclo­­­­s­es that "if the signature check fails or if no sig­nature is present", the non-verified application is executed "outside the secure environ­ment" (para­graph 32). The appellant argued that this paragraph only referred to the execution of applications with incorrect or absent signatures but did not allow the conclusion that "unsigned operating systems" were executed. Rather, it allowed for the option that an unsigned operating system was not executed at all.

6.4.1 The board agrees that D1 does not expressly disclose that or how:

(iii) an unsigned operating system may be executed,

let alone that:

(iii') the unsigned operating system may be executed a limited number of times.

6.4.2 D1 discloses that, in secure mode, access to a particular storage area, holding security data such as cryptographic keys (see paragraph 10), may be allowed in secure mode but not in insecure mode. That is, D1 discloses a "security block" storing cryptographic keys, but does not disclose that:

(iv) the keys are device-specific or that user data is also stored in the security block.

Moreover, D1 does not disclose that:

(v) "user data not stored in or protected by the security block" is erased along with the disabling of the access to the security block.

7. Having two "modes" of operation (see feature (ii)) in which two security policies apply is the direct consequence of a non-technical requirement. Starting from D1, the invention would have to be viewed as the provision of a "product mode" as opposed to a (suitably modified) "factory mode" as disclosed in D1.

7.1.1 At the same time, a fair application of the COMVIK-style problem/solution approach (see T641/00) requires an argument as to why the non-technical requirement would have arisen in a particular technical context (see also T 1325/17, reasons 10.2).

7.1.2 The board takes the view that the objective technical problem to add a stricter "product mode" to the system of D1 while modifying the given security policy (claimed as the "factory mode") cannot realistically be assumed to have arisen and therefore starts its assessment from the prior art disclosed in the application.

8. The application starts from the situation in which a device manufacturer has to execute software provided by an OEM during manufacture (see paragraph 2) and, for security reasons, to validate a cryptographic signature of the OEM before execution (see paragraph 4). In this scenario, the operating system is first loaded and then verified (see paragraph 4). This is feature (i).

8.1 Claim 1 differs from this scenario at least in features (ii) to (v).

8.2 A device manufacturer would naturally experience the inconvenience of having to obtain an OEM signature for any software to be executed and would want to have this requirement relieved at least during manufacture­­. The OEM would then address the objective technical problem of providing a more lenient security policy to the manufacturer without unnecessarily compromising security.

8.3 It follows from general security considerations that any lenient security policy should only be provided for as short a period as possible. In the given instance, this means: only during manufacture. It thus would have been obvious to provide two modes as claimed and to allow the exe­cu­tion of an unsigned operating system during but not after manufacture. This renders features (ii) and (iii) obvious.

8.4 The idea of allowing the execution of an unsigned ope­rating system ("insecure boots") only a limited number of times (feature (iii')) is a generally obvious alternative to allowing unsigned software to run during a limited period of time as proposed in D1. Moreover, no detail is given of the manufacturing process so that no specific technical advantages of the claimed counter can be determined or invoked to establish an inventive step. Any particular manufacturing process would probably have suggested the claimed counter in view of the particular manufacturing process which might, for instance, require the execution of an unsigned operating system up to, say, 3 times during substantially different periods of times.

8.5 With regard to feature (iv), D1 discloses the use of a "security environment" storing and controlling access to all kinds of security related information, i.e. a "security block" as claimed. D1 explicitly discloses that the security data might contain cryptographic keys (see paragraph 10). That the claims require the storage of "device-specific" keys is not inventive because being "device-specific" is not a property of the key but, at best, its use which is not claimed. Moreover, it would have been obvious to place "user data" into the "security block" of D1 if it happened to be security-relevant.

8.6 D1 does not disclose an explicit step of erasing user data that happens not to be stored in the security block - or rather, the security environment of D1, for that matter (see feature (v)).

8.7 Erasing user data outside of the security block before allowing the execution of an unsigned operating system contributes to increasing the security of the claimed device in a way not suggested by D1 or any of documents D2 to D4.

8.8 Therefore, the subject-matter of claim 1 is non-obvious over the prior art described in the application in view of D1, Article 56 EPC.