Secure Device Mode Transition for Untrusted OS Execution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Secure devices face challenges in managing transitions between 'product mode' and 'factory mode' while ensuring secure execution of untrusted operating system code, which is not cryptographically signed by the OEM, to streamline manufacturing processes and reduce costs.
Innovation Solution
A method and secure device implementation that allows execution of untrusted operating system code by adapting the processor to manage transitions between 'product mode' and 'factory mode' using cryptographic signatures and OTP fuses, enabling execution of unsigned or signed code by entities other than the OEM, while preventing access to secure data in 'factory mode'.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the device executes only cryptographically signed operating system code, then security is improved, but manufacturing flexibility and cost are worsened
Solution Approach 1:
The patent segments the operational modes into distinct states: a secure product mode where only signed code executes, and a factory mode where unsigned code can execute. This segmentation allows the system to maintain security in product mode while enabling manufacturing flexibility in factory mode, resolving the contradiction between security and manufacturing adaptability.
Solution Approach 2:
The system dynamically transitions between product mode and factory mode based on operational context. The processor can switch between these modes, allowing the same hardware to exhibit different security behaviors - highly restrictive in product mode and flexible in factory mode - thus resolving the contradiction between security and manufacturing versatility.
2Adaptability or versatility
If the device allows execution of untrusted operating system code, then manufacturing flexibility is improved, but security is worsened
Solution Approach 1:
The patent segments the operational modes into distinct states: a secure product mode where only signed code executes, and a factory mode where unsigned code can execute. This segmentation allows the system to maintain security in product mode while enabling manufacturing flexibility in factory mode, resolving the contradiction between security and manufacturing adaptability.
Solution Approach 2:
The patent introduces an intermediary mechanism (the mode transition system with cryptographic verification) that mediates between the conflicting requirements of security and manufacturing flexibility. The system uses cryptographic signatures and mode transitions as intermediaries to safely enable unsigned code execution only when appropriate, resolving the contradiction.
3Adaptability or versatility
If the device transitions between product mode and factory mode, then operational versatility is improved, but system complexity is worsened
Solution Approach 1:
The patent implements a universal mode transition mechanism that handles both product mode and factory mode operations through a single cryptographic verification system. This multi-functional approach allows the same hardware and software infrastructure to support both secure product operation and flexible factory operation, reducing the complexity that would arise from completely separate systems for each mode.
4Reliability
If cryptographic verification is performed on operating system code, then security is improved, but processing time is worsened
Solution Approach 1:
The patent applies preliminary action by performing cryptographic verification during the boot process before the operating system is fully loaded and executed. The secondary boot loader verifies the cryptographic signature of the operating system code before transferring control, ensuring security is established upfront rather than requiring continuous verification during operation, thus minimizing time loss.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Normally, at the time of manufacturing, security may be provided to a device being manufactured through the loading of an operating system that has been cryptographically signed. The present application discloses a "factory mode" for the device. The "factory mode" allows the device to execute untrusted operating system code, such as unsigned operating system code and operating system code that has been signed, but the certificate authority is not trusted. To support execution of untrusted operating system code in a secure manner, the device may be adapted to prevent data of predetermined type from being loaded on the device while the device is in the "factory mode". In contrast to the "factory mode", the secure mode of the device is referred to herein as a "product mode". There develops a need to manage, in a secure manner, transitions between the "product mode" and the "factory mode".