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:
Key takeaways
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.
The invention
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:
-
Claim 1
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.
More information
You can read the whole decision here: T 1563/17 (Booting untrusted software) of 7.5.2019.