The European Patent Office refused to grant a software patent on a method of managing booting of secure devices with untrusted software. The decision was appealed successfully and the case was remitted to the Examining Division. Here are the practical takeaways of the decision T 1563/17 (Booting untrusted software) of 7.5.2019:
This European patent application considers the situation in which a “third party” or “contract manufacturer” manufactures a computing device on behalf of an OEM. In the eventually delivered product, only trusted operating systems should be executed; trust may be established with cryptography. 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.
To deal with this situation, the invention proposes to provide the device with two modes: “factory mode” and “product mode” (see figure 2).
In product mode, only “secure boots” are allowed. In factory mode, a limited number of “insecure boots” is allowed during which the access to a “security block” is disabled. The security block is disclosed as containing, inter alia, device-specific cryptographic keys or “user-specific data”.
Here is how the invention is defined in claim 1 of the sole request:
A method of executing either an unsigned operating system or a signed operating system on a device (100) having a processor (128) and a collection of hardware resources designated as a security block, the security block comprising user data and device specific cryptography keys, the device being operable in a factory mode (220) where access to the security block is not allowed and in a product mode (210) where access to the security block is allowed, said method comprising the processor (128) loading a boot loader and under the instructions from the boot loader:
- loading (302) an operating system and subsequent to loading the operating system:
- determining (304) whether said device is in the factory mode (220) or in the product mode (210),
on determining (304) that the device (100) is in factory mode:
- determining (310) whether the operating system is signed by a trusted entity:
- if the operating system is signed by a trusted entity allowing (308) execution of the operating system on authentication (306) of [the] operating system and denying execution of [the] operating system on failure to authenticate the operating system;
- if the operating system has not been signed by a trusted entity and represents an untrusted operating system, determining (312) whether a counter of allowed insecure boots exceeds zero and:
- upon determining (312) that the counter of allowed insecure boots exceeds zero, decrementing (314) the counter of allowed insecure boots and disabling (316) access to the security block to maintain security for user data and cryptographic keys saved in or protected by the security block, the disabling further comprising erasing all user data not stored [in] or protected by the security block and, once access to the security block has been disabled, allowing execution (318) of the untrusted operating system; or
- upon determining (step 312) that the counter of allowed insecure boots has reached zero, deactivating (320) factory mode and restarting (322) the device to exit factory mode (220);
on determining (304) that said device is in product mode determining (306) whether the operating system is authenticated and allowing execution (308) of the operating system on authentication of [the] operating system and denying execution of [the] operating system on failure to authenticate the operating system.
Is it technical?
When assessing inventive step, the Board found that having two “modes” of operation in which two security policies apply is non-technical:
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.
However, the Board found that to validate a cryptographic signature of the OEM before execution is technical.
8. The application starts from the situation in which a device manufacturer has to execute software provided by an OEM during manufacture and, for security reasons, to validate a cryptographic signature of the OEM before execution. …
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.
After a detailed comparison between all the features of claim 1 and D1, the Board found the following feature technical and inventive:
- (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.
The reasons are:
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.
Therefore, the subject-matter of claim 1 was found to involve an inventive step.
You can read the whole decision here: T 1563/17 (Booting untrusted software) of 7.5.2019.