KR20130096239A - Host device and method for securely booting the host device with operating system code loaded from a storage device - Google Patents

Host device and method for securely booting the host device with operating system code loaded from a storage device Download PDF

Info

Publication number
KR20130096239A
KR20130096239A KR1020137003383A KR20137003383A KR20130096239A KR 20130096239 A KR20130096239 A KR 20130096239A KR 1020137003383 A KR1020137003383 A KR 1020137003383A KR 20137003383 A KR20137003383 A KR 20137003383A KR 20130096239 A KR20130096239 A KR 20130096239A
Authority
KR
South Korea
Prior art keywords
host device
storage device
device
operating system
host
Prior art date
Application number
KR1020137003383A
Other languages
Korean (ko)
Inventor
보리스 돌구노브
류벤 엘하미아스
에후드 코헨
Original Assignee
샌디스크 아이엘 엘티디
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US12/853,924 priority Critical patent/US8996851B2/en
Priority to US12/853,924 priority
Application filed by 샌디스크 아이엘 엘티디 filed Critical 샌디스크 아이엘 엘티디
Priority to PCT/IB2011/001748 priority patent/WO2012020292A1/en
Publication of KR20130096239A publication Critical patent/KR20130096239A/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • G06F9/4406Loading of operating system
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575Secure boot
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material
    • G06F21/12Protecting executable software
    • G06F21/121Restricting unauthorised execution of programs
    • G06F21/123Restricting unauthorised execution of programs by using dedicated hardware, e.g. dongles, smart cards, cryptographic processors, global positioning systems [GPS] devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82Protecting input, output or interconnection devices
    • G06F21/85Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices

Abstract

A host device and method are provided for securely booting a host device with operating system code loaded from storage. In one embodiment, the host device communicates with a storage device having a private memory area storing boot loader code and a public memory area storing operating system code. The host device enters the boot mode and instructs the storage device to receive the boot loader code from the storage device. The host device executes boot loader code that performs a security check and executes operating system code loaded from storage only if the security check is successful.

Description

HOST DEVICE AND METHOD FOR SECURELY BOOTING THE HOST DEVICE WITH OPERATING SYSTEM CODE LOADED FROM A STORAGE DEVICE}

The present invention relates to a boot technique, and more particularly, to a host device and method for securely booting a host device with operating system code loaded from storage.

In some environments, the host device (such as a mobile phone or other) may reside on an embedded or removable storage device (such as a secure digital (SD) card or a multimedia card (MMC)) that stores boot loader code as well as operating system code for the host device. Other devices) are used. To boot the host device, the host device instructs the storage device to enter the boot mode, and in response, the storage device provides boot loader code to the host device. Running the boot loader code allows the host device to load operating system code from storage. In some mobile device environments, the command to enter the boot mode is not a standard command that the host device sends in typical read / write communication with the storage device. For example, under the Joint Electron Devices Engineering Council's (JEDEC's) JESD84-A44 standard and Micron's TN-29-18 specification, the host device keeps the command line low or takes over the command line to storage for 74 clock cycles. (argument) You can tell the storage device to start boot mode by sending a CMD 0 command with OxFFFFFFFA.

Since the operating system code is stored on storage, it is possible for a hacker to change the operating system code without the host device knowing to put malware on it. Thus, in some circumstances it is desirable to verify the integrity of operating system code before it is executed by the host device. To perform this "secure boot", the controller of the host device may include secure read only memory (ROM) code or other features to verify it before the operating system code is executed. However, having such a code in the controller increases the cost of the controller, and controllers that are initially manufactured without a verification code generally cannot be retrofitted to include the verification code after manufacture.

It is an object of the present invention to provide a host device and method for securely booting a host device with operating system code loaded from a storage device.

summary

Embodiments of the invention are defined by the claims, and nothing in this paragraph should be taken as a limitation on these claims.

By way of introduction, the following embodiments are directed to a host device and method for securely booting a host device with operating system code loaded from storage. In one embodiment, the host device communicates with a storage device having a private memory area storing boot loader code and a public memory area storing operating system code. The host device enters the boot mode and instructs the storage device to receive the boot loader code from the storage device. The host device executes boot loader code that performs a security check and executes operating system code loaded from storage only if the security check is successful.

Other embodiments are possible, and each of the embodiments can be used alone or together in combination. Embodiments will now be described with reference to the accompanying drawings.

According to the present invention, a host device and a method for securely booting a host device with an operating system code loaded from a storage device can be provided.

1 is a block diagram of an exemplary host device and storage device in an embodiment.
2 is a block diagram of a host device and a storage device that diagrammatically illustrates the boot process of an embodiment.
3 is a block diagram illustrating an interface between a host device and a storage device in an embodiment.
4 is a diagram illustrating an instruction of an embodiment for initiating a boot mode.
5 is a diagram illustrating another embodiment of a command for initiating a boot mode.
6 is a block diagram of a host device and a storage device that diagrammatically illustrates the boot process of an embodiment involving a security check.
7 is a flowchart of a boot process of an embodiment involving a security check.

Introduction

In general, the following embodiments are directed to a host device and method for securely booting a host device with operating system code loaded from storage. In the embodiments described below, the boot loader code stored in the storage device is configured to enable the host device to load operating system code as well as perform a security check. Accordingly, the boot loader allows the host device to execute operating system code loaded from storage only if the security check is successful. The security check can take any suitable form. For example, a security check may attempt to verify the integrity of operating system code to ensure that operating system code has not been altered by a hacker to put malware. This provides a "secure boot" without the cost or inflexibility associated with having such a function in the controller of the host device. Other examples of security checks that may be performed include attempting to authenticate a user of a host device, attempting to authenticate a host device, and attempting to authenticate a Subscriber Identity Module (SIM) card used for the host device. One, but not limited to these. Before going to these security checks, the following paragraphs describe example hosts and storage devices.

Example Virtual Hosts and Storage Devices

Turning now to the figures, FIG. 1 is a block diagram of a host 50 in communication with the storage device 100 of an embodiment. As used herein, the phrase “communicating with” means communicating directly or indirectly through one or more components that may or may not be shown or described herein. The host 50 can be any device, such as a mobile phone, digital media player, gaming device, personal digital assistant (PDA), personal computer (PC), kiosk, set-top box, TV system, book reader, or any combination thereof. Suitable forms can be taken, but are not limited to these. In this embodiment, the storage device 100 is not only a universal serial bus (USB) device and a removable or non-removable hard drive (eg, magnetic disk or solid state drive), but also internal memory (eg, a host). Security modules embedded in device 50) and portable removable memory, but may be of any suitable form. In one embodiment, the storage device 100 takes the form of an iNAND eSD / eMMC embedded flash drive by SanDisk Corporation.

As shown in FIG. 1, the storage device 100 includes a controller 110 and a memory 120. The controller 110 includes a memory interface 111 for interfacing with the memory 120 and a host interface 112 for interfacing with the host 50. In addition, the controller 110 may include a central processing unit (CPU) 113, a hardware encryption-engine 114, a read access memory (RAM) 115, and storage 100 that operate to provide encryption and / or decryption operations. Read only memory (ROM) 116 capable of storing firmware for basic operations, and non-volatile memory (NVM) 117 capable of storing device-specific keys used for encryption / decryption operations. do. Controller 110 may be implemented in any suitable manner. For example, the controller 110 may be executed by a microprocessor or processor and for example (micro) processors, logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Computer-readable media that store computer-readable program code (e.g., software or firmware). Examples of controllers include, but are not limited to, ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320 as microcontrollers.

Memory 120 may take any suitable form. In one embodiment, memory 120 takes the form of a solid state (eg, flash) memory and may be programmable once, programmable a few times, or programmed multiple times. However, other forms of memory may be used, such as optical memory and magnetic memory. In this embodiment, memory 120 includes public memory area 125 managed by a file system on host 50 and private memory area 135 managed internally by controller 110. The private memory area 135 may store boot loader code (as described below), as well as other data, including but not limited to content encryption keys (CEKs) and firmware (FW) codes. Public memory area 125 may store operating system code (as described below) for host device 50 as well as user data and other data. The public memory area 125 and the private memory area 135 may be different partitions of the same memory unit or different memory units. Private memory area 136 is “private” (or “hidden”) because it is managed internally by controller 110 (not by controller 160 of the host). In one embodiment, private memory. Area 136 cannot be read or accessed only after the boot process to prevent anyone from overwriting or modifying the boot loader code In addition to storing operating system code, public memory area 125 stores user data. In addition, in one embodiment, operating system code is stored in rewritable memory to enable updates to be written to the operating system code.

Now going to host 50, host 50 includes a controller 160 having a storage interface 161 for interfacing with storage 100. The controller 160 may also include a central processing unit (CPU) 163, an encryption-engine 164, read access memory (RAM) 165, read-only memory (ROM) operative to provide encryption and / or decryption operations. ) 166, a security module 171, and a storage device 172. The storage device 100 and the host 150 communicate with each other via the storage interface 161 and the host interface 112. For operations involving the integrity transfer of data, the crypto-engines 114 and 164 in storage 100 and host 150 are preferably used to authenticate each other and provide key exchange. After mutual authentication is complete, the session key is preferably used to establish a secure channel for communication between storage 150 and host 100. The host 50 may include other components (eg, display device, speaker, headphone jack, video output connection, etc.), but these are not shown in FIG. 1 to simplify the drawings.

Overview of the Boot Process for Host Devices

Returning to the drawings, FIG. 2 diagrammatically illustrates the boot process of an embodiment. In general, the CPU 163 of the host device can execute only program code found in the ROM 166 or the RAM 165 (FIG. 1) of the host device. When host device 50 is initially powered on, host device 50 does not have an operating system in ROM 166 or RAM 165. However, the host device 50 has a small program stored in the ROM 166, and the CPU 163 can execute this to send a command to the storage device 100 to start a boot mode. In response to this command, storage device 100 sends boot loader code to host device 100 that is stored in RAM 165 of the host device to be executed by its CPU 163. This process of copying the boot loader code into the RAM 165 of the host device for execution is also referred to as "image shadowing". The boot loader code (also known as the boot loader image, bootstrap loader, or bootstrap loader image) is executed when the host device 50 reads operating system code from the public memory area 125 of the storage device 100 and thereafter. Computer-readable program code that executes operating system code and thereby makes the host device 50 bootable.

As mentioned above, in this embodiment, the boot loader code is stored in the private memory area 136 of the storage device 100 (preferably, to ensure the integrity of the boot loader code against tampering). In a read-only manner). As mentioned above, the private memory area 136 is managed by the storage device 100 internally, not by the host device 50. Therefore, the command to the storage device 100 to start the boot mode is not a standard command for reading from an address in the storage device 100. This is in contrast to some personal computers (PCs) and other environments that send a standard read command of logical address zero to read the boot loader code stored on the PC's hard drive. In addition, sending the boot loader code to the host device 50 is in response to receiving a special command from the host device 50 and being in boot mode, as in some PC environments, the standard reading of a logical address from the host device 50. It did not comply with the order.

The command to the storage device 100 to enter the boot mode may take any suitable form. For example, the Joint Electron Devices Engineering Council's (JEDEC's) JESD84-A44 standard and the Micron's TN-29-18 specification allow the host device to directly generate read / write storage commands (e.g., standard multimedia card commands) without having to generate them. Defines the multilimiter card (MMC) internal memory interface / protocol to load boot loader code from storage. The JEDEC standard and Micron specification describe two suitable instructions for initiating a boot mode on storage. These example instructions will be discussed with respect to FIGS. 3-5.

3 is a block diagram illustrating an interface between the host device 50 and the storage device 100. As shown in FIG. 3, in this embodiment the interface includes a clock (CLK) line, one or more command (CMD) lines, and one or more data (DAT) lines, which may take the form of pins on the bus. Have The signal on the CLK line synchronizes data between the host device 50 and the storage device 100. The CMD line transmits instructions from the host device 50 and the storage device 100 and sends back responses from the storage device 100 to the host device 50. The DAT line is used to transfer data between the storage device 100 and the host device 50.

In one embodiment (shown in FIG. 4), the command to the storage device 100 to enter the boot mode takes the form of keeping the CMD line low for 74 clock cycles. The storage device 100 recognizes this as a command to the storage device 100 to start the boot mode and starts sending the first boot data to the host device 50 via the DAT line (s). The host device 50 will keep the CMD line low to read all boot data. When boot authorization is enabled, the storage device 100 sends an authorization pattern "010" to the host device 50 within 50 ms after the CMD line goes low. If boot authorization is not possible, storage device 100 will not issue an authorization pattern "010".

In another embodiment (shown in FIG. 5), the command to the storage device 100 to enter the boot mode is issued after 74 clock cycles following a power on / reset and before CMD 1 is issued or the CMD line goes low. It takes the form of sending a CMD 0 command with the argument OxFFFFFFFA on the CMD line before going. The storage device 100 will recognize this as a command to enter the boot mode and begin to prepare boot data internally. Within one second after CMD 0 with an argument of OxFFFFFFFA is issued, the storage device 100 begins to send the first boot data to the host device 50 on the DAT line (s). Once boot authorization is enabled, storage device 100 sends authorization pattern " 010 " to host device 50 within 50 ms after receiving CMD 0 with argument OxFFFFFFFA. Conversely, if boot authorization is disabled, storage device 100 will not issue an authorization pattern "010". The host device 50 may end the boot mode by issuing CMD 0 (reset).

As mentioned above, these instructions are not commands to read the data stored at the address. Rather, they are special instructions that cause storage 100 to enter a boot mode to send boot loader code to host device 50. After the boot loader code is sent to the host device 50, the host device 50 executes the boot loader code to load operating system code from the public memory area 125 of the storage device 100. In this embodiment, the process of loading operating system code from public memory area 125 of storage 100 may be performed using standard read instructions.

Boot Loader  Example Security Features of Code

As mentioned in the background above, since the operating system code is stored in the storage device 100, it is possible for a hacker to change the operating system code without the host device 50 knowing to put malware. Thus, in some circumstances, it is desired to verify the integrity of operating system code before it is executed by host device 50. Code for verifying the integrity of the operating system code may be included in the ROM of the host device, but this increases the cost of the controller. In addition, since such provisioning must be done at the manufacturing stage, host device controllers initially manufactured without the verification code cannot be newly provided to include the verification code after manufacture. To overcome these problems, in one embodiment, the boot loader code stored in storage 100 is configured to attempt to verify the integrity of the operating system code and only if the attempt to verify the integrity of the operating system code is successful. Only allow device 50 to load and execute operating system code. This embodiment will be illustrated with respect to FIG. 6.

As shown schematically in FIG. 6, the host device 50 sends a command to the storage device 100 to initiate a boot mode and receives and executes a boot loader code in response to the command. In this embodiment, the boot loader code includes reference image verification code, such as a hash value of operating system code (ie, operating system code digest). (Boot loader code is stored in read-only memory in storage 100, so the stored reference image verification code cannot be changed). Also in this embodiment the boot loader is configured to initiate a special read mode to instruct the storage device 100 to calculate a digest of all read data. Thus, when the boot loader is reading operating system code from storage 100, the controller of the storage device simultaneously digests all read data (e.g., using a hash function message authentication code (HMAC)). Will calculate. Using storage 100 instead of host device 50 to calculate the digest avoids degrading the performance of host device 100 during the boot process. After the host device 50 finishes reading the operating system code from the storage device 100, the boot loader receives the calculated digest from the storage device 100 and compares the calculated digest with a reference digest stored in the boot loader. . The digest comparison is affirmative (ie, if the security check is successful), and the host device 50 can execute operating system code. (Instead of using digest comparison, the calculated digest can be used for signature verification). Since the verification of the integrity of the operating system is performed by the boot loader and the storage device 100, not by the code provided in the controller of the host device during the manufacture of the host device 50, this embodiment is implemented in the controller of the host device. It provides the desired "secure boot" feature without the cost or inefficiencies associated with having this functionality.

Note that while the security check in the above example is intended to verify the integrity of the operating system, the boot loader can be configured to provide additional or alternative security checks. For example, since operating system code is stored in public memory area 125, it may be desirable to implement some form of access control on public memory area 125, so that operating system code is stored by the boot loader. It cannot be executed unless a successful security check is performed. Thus, storage device 100 may be designed to allow access to operating system code only when host device 100 presents credentials appropriate for storage device 100, and these suitable credentials may be Can be generated by the boot loader upon completion of a successful security check. In such embodiments, the boot loader may embed an application program interface (API) that enables communication with a special security software stack in storage 100 that is responsible for authentication and access control functions. This embodiment is shown in the flowchart of FIG. 7 and discussed below.

As shown in FIG. 7, the host device 100 may use a subscriber identity when the attempt to authenticate the user of the host device is successful, when the attempt to authenticate the host device is successful, and / or used by the host device. Module) When an attempt to authenticate the card is successful, suitable credentials may be generated for authenticating the storage device 100. Each of these security checks will now be described. Of course, different security checks or variants of these security checks can be used.

In one embodiment, the boot loader is configured to attempt to authenticate the user of the host device 50. In this embodiment, the user may be required to enter a password to be provided to the storage device 100 in order to be able to access the data stored in the storage device 100. This password authentication can be implemented using proprietary technologies defined by specific applications, or used by TrustedFlash memory products by SanDisk Corporation and by PCs operating in a Trusted Computing Group (TCG) environment. It can be implemented using other techniques such as those. If the user is authenticated by a boot loader running on the host device 50, the storage device may open the public memory area 25 and provide access to the operating system code stored therein to allow the operating system code to be loaded and executed. Credentials suitable for 100 are sent.

In another embodiment, the boot loader code is configured to attempt to authenticate the host device 50, which actually associates the operating system code with a particular host device. In this embodiment, the boot loader code collects various hardware parameters of the host device 50 to calculate the digest. Examples of hardware parameters include, but are not limited to, unique hardware identifiers, memory sizes, media access control (MAC) addresses, and controller versions. The calculated digest is then compared to the digest value stored in the boot loader. If the calculated digest matches the stored digest, then the security check is successful, and the storage device is opened in order to open the public memory area 25 to provide access to the operating system code stored therein so that the operating system code can be loaded and executed. A command suitable for 100) is sent. In yet another embodiment, the boot loader code may be configured to attempt to authenticate the Subscriber Identity Module (SIM) card used for the host device 50. This embodiment is similar to that discussed above, but the hardware parameters are of a SIM card (eg, an International Mobile Subscriber Identity (IMSI) identifier and an International Mobile Equipment Identity (IMEI) identifier). Thus, the operating system code is tied to the SIM card and will not be tied to the host device 50. Of course, if the digest is calculated from the hardware parameters of both the host device 50 and the SIM card, the operating system code would be attached to both the host device 50 and the SIM card. In addition, the host device 50 may generate a SIM card-to generate an authentication code for opening the storage device 100 (e.g., using a challenge response PKI scheme or using symmetric or password authentication). Host device authentication can be performed.

There are several alternatives that can be used in these embodiments. For example, instead of a single operating system code, storage 100 may store a plurality of operating system codes, and a user may be asked which of these codes to upload during the boot process. As another alternative, the boot loader may execute a purchase application that allows a user to purchase specific operating system code or other content. As an alternative, the boot loader can be used to upgrade the operating system at a lower level through boot loader upgrades.

The

The foregoing detailed description is to be understood not as a definition of the invention but as an illustration of selected forms that the invention may take. It is only the following claims, including all equivalents, intended to define the scope of the claimed invention. Finally, it is noted that any feature of any embodiment of the preferred embodiments described herein may be used alone or in combination with each other.

50: Host
100: storage device

Claims (22)

  1. A method of securely booting a host device with operating system code loaded from storage, the method comprising: at a host device communicating with a storage device having a private memory area storing boot loader code and a public memory area storing operating system code A method comprising performing the following.
    Instructing the storage device to enter a boot mode;
    Receiving the boot loader code from the storage device; And
    Executing the boot loader code, when executed, executing the operating system code loaded from the storage device only when the boot loader code performs a security check and the security check is successful.
  2. 2. The method of claim 1, wherein the host device instructs the storage device to enter the boot mode as opposed to sending a command to read from an address in the storage device.
  3. 2. The host device of claim 1, wherein the host device and the storage device communicate with an interface comprising a command (CMD) line, the host device initiating the boot mode by keeping the CMD line low for 74 clock cycles. Instructing the storage device.
  4. 2. The host device of claim 1, wherein the host device and the storage device communicate over an interface that includes a command (CMD) line, and the host device initiates the boot mode by sending CMD 0 with the argument OxFFFFFFFA to the CMD line. Instructing the storage device.
  5. The method of claim 1, wherein the security check is performed by attempting to verify the integrity of the operating system code.
  6. The method of claim 1, wherein the security check is performed by attempting to authenticate a user of the host device.
  7. 7. The method of claim 6, wherein attempting to authenticate the user of the host device comprises requesting a user password.
  8. The method of claim 1, wherein the security check is performed by attempting to authenticate the host device.
  9. 8. The method of claim 7, wherein attempting to authenticate the host device comprises authenticating hardware parameters of the host device.
  10. The method of claim 1, wherein the host device is further in communication with a Subscriber Identity Module (SIM) card, and the security check is performed by attempting to authenticate the SIM card.
  11. The method of claim 1, wherein the storage device comprises storage built into the host device.
  12. The method of claim 1, wherein the storage device comprises a storage device removably connected to the host device.
  13. In the host device,
    An interface configured to communicate with a storage device having a private memory area storing boot loader code and a public memory area storing operating system code; And
    A controller in communication with the interface, the controller
    Instruct the storage device to enter a boot mode;
    Receive the boot loader code from the storage device;
    Configured to execute the boot loader code, and when executed, the boot loader code
    Perform security checks,
    And execute the operating system code loaded from the storage only if the security check is successful.
  14. 14. The host device of claim 13, wherein the controller is configured to instruct the storage device to enter the boot mode as opposed to sending a command to read from an address in the storage device.
  15. The host of claim 13, wherein the interface comprises a command (CMD) line and the controller is configured to instruct the storage device to enter the boot mode by keeping the CMD line low for 74 clock cycles. Device.
  16. 14. The host of claim 13, wherein the interface comprises a command (CMD) line and the controller is configured to instruct the storage device to initiate the boot mode by sending CMD 0 with an argument OxFFFFFFFA to the CMD line. Device.
  17. The host device of claim 13, wherein the security check is performed by attempting to verify the integrity of the operating system code.
  18. The host device of claim 13, wherein the security check is performed by attempting to authenticate a user of the host device.
  19. The host device of claim 13, wherein the security check is performed by attempting to authenticate the host device.
  20. The host device of claim 13, further comprising a Subscriber Identity Module (SIM) card in communication with the controller, wherein the security check is performed by attempting to authenticate the SIM card.
  21. The host device of claim 13, wherein the storage device comprises a storage device embedded in the host device.
  22. The host device of claim 13, wherein the storage device comprises a storage device removably connected to the host device.
KR1020137003383A 2010-08-10 2011-07-28 Host device and method for securely booting the host device with operating system code loaded from a storage device KR20130096239A (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US12/853,924 US8996851B2 (en) 2010-08-10 2010-08-10 Host device and method for securely booting the host device with operating system code loaded from a storage device
US12/853,924 2010-08-10
PCT/IB2011/001748 WO2012020292A1 (en) 2010-08-10 2011-07-28 Host device and method for securely booting the host device with operating system code loaded from a storage device

Publications (1)

Publication Number Publication Date
KR20130096239A true KR20130096239A (en) 2013-08-29

Family

ID=44658783

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020137003383A KR20130096239A (en) 2010-08-10 2011-07-28 Host device and method for securely booting the host device with operating system code loaded from a storage device

Country Status (6)

Country Link
US (1) US8996851B2 (en)
EP (1) EP2603874A1 (en)
KR (1) KR20130096239A (en)
CN (1) CN103069384A (en)
TW (1) TW201212617A (en)
WO (1) WO2012020292A1 (en)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8751782B2 (en) * 2010-12-16 2014-06-10 Intel Corporation Secure local boot using third party data store (3PDS) based ISO image
KR20120123885A (en) * 2011-05-02 2012-11-12 삼성전자주식회사 Storage device authentication apparatus and Storage device comprising authentication apparatus connection means
WO2012159366A1 (en) * 2011-08-03 2012-11-29 华为技术有限公司 Data management method and device
US9319884B2 (en) 2011-10-27 2016-04-19 T-Mobile Usa, Inc. Remote unlocking of telecommunication device functionality
WO2013101083A1 (en) 2011-12-29 2013-07-04 Intel Corporation An apparatus for hardware accelerated runtime integrity measurement
FR2989197B1 (en) * 2012-04-05 2014-05-02 Toucan System Method for securing access to a computer device
US9172538B2 (en) 2012-04-20 2015-10-27 T-Mobile Usa, Inc. Secure lock for mobile device
US10075848B2 (en) 2012-08-25 2018-09-11 T-Mobile Usa, Inc. SIM level mobile security
KR101987144B1 (en) 2012-10-10 2019-06-11 삼성전자주식회사 Main memory system storing Operating System program and computer system including the same
CN104182242A (en) * 2013-05-28 2014-12-03 华为技术有限公司 System booting method and system booting device
US9613214B2 (en) * 2013-07-09 2017-04-04 Micron Technology, Inc. Self-measuring nonvolatile memory devices with remediation capabilities and associated systems and methods
WO2015065431A1 (en) * 2013-10-31 2015-05-07 Hewlett-Packard Development Company, L.P. Memory integrity checking
KR20150061945A (en) * 2013-11-28 2015-06-05 삼성전자주식회사 All-in-one data storage device having internal hardware filter, method thereof, and system having the data storage device
US10359937B2 (en) 2013-12-20 2019-07-23 Sandisk Technologies Llc System and method of implementing a table storage support scheme
CN104811304B (en) * 2014-01-27 2020-02-14 腾讯科技(深圳)有限公司 Identity verification method and device
US9195831B1 (en) 2014-05-02 2015-11-24 Google Inc. Verified boot
US9720855B2 (en) 2014-08-19 2017-08-01 Samsung Electronics Co., Ltd. Virtual device based systems with access to parts other than data storage elements through the virtual device
WO2016033539A1 (en) 2014-08-29 2016-03-03 Memory Technologies Llc Control for authenticated accesses to a memory device
US9807607B2 (en) 2014-10-03 2017-10-31 T-Mobile Usa, Inc. Secure remote user device unlock
CN106295318A (en) * 2015-06-05 2017-01-04 北京壹人壹本信息科技有限公司 A kind of system start-up bootstrap technique and device
US20170010896A1 (en) * 2015-07-06 2017-01-12 Lear Corporation Shared Memory Architecture Autoupdater
US9813399B2 (en) 2015-09-17 2017-11-07 T-Mobile Usa, Inc. Secure remote user device unlock for carrier locked user devices
CN106897623A (en) * 2015-12-21 2017-06-27 深圳市中兴微电子技术有限公司 It is a kind of support more than the chip that guides safely and its startup method
SG10201602449PA (en) * 2016-03-29 2017-10-30 Huawei Int Pte Ltd System and method for verifying integrity of an electronic device
CN106126200B (en) * 2016-06-13 2019-07-19 房玮 A kind of cloud computing system that can remotely guide client computer
CN108664280A (en) * 2017-03-31 2018-10-16 深圳市中兴微电子技术有限公司 A kind of embedded system start method and device
US10171649B2 (en) 2017-04-21 2019-01-01 T-Mobile Usa, Inc. Network-based device locking management
US10476875B2 (en) 2017-04-21 2019-11-12 T-Mobile Usa, Inc. Secure updating of telecommunication terminal configuration
CN108287671A (en) * 2018-04-10 2018-07-17 南京扬贺扬微电子科技有限公司 A kind of SD card and its fabrication method with boot functions

Family Cites Families (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0449242A3 (en) * 1990-03-28 1992-10-28 National Semiconductor Corporation Method and structure for providing computer security and virus prevention
US5870520A (en) * 1992-12-23 1999-02-09 Packard Bell Nec Flash disaster recovery ROM and utility to reprogram multiple ROMS
US5379431A (en) * 1993-12-21 1995-01-03 Taligent, Inc. Boot framework architecture for dynamic staged initial program load
US5701477A (en) 1995-03-30 1997-12-23 Cirrus Logic, Inc. Method and apparatus for master boot record shadowing
US6185678B1 (en) 1997-10-02 2001-02-06 Trustees Of The University Of Pennsylvania Secure and reliable bootstrap architecture
US6463535B1 (en) 1998-10-05 2002-10-08 Intel Corporation System and method for verifying the integrity and authorization of software before execution in a local platform
EP1001331B1 (en) * 1998-11-11 2004-08-11 O2 Micro International Limited Pre-boot security controller
US6425079B1 (en) * 1999-03-31 2002-07-23 Adaptec, Inc. Universal option ROM BIOS including multiple option BIOS images for multichip support and boot sequence for use therewith
US6748544B1 (en) * 1999-08-19 2004-06-08 International Business Machines Corporation Discrete, background determination of the adequacy of security features of a computer system
US7266849B1 (en) * 1999-12-08 2007-09-04 Intel Corporation Deterring unauthorized use of electronic devices
US6601166B1 (en) * 1999-12-23 2003-07-29 Intel Corporation Mechanism for booting a computer through a network
US6625729B1 (en) 2000-03-31 2003-09-23 Hewlett-Packard Company, L.P. Computer system having security features for authenticating different components
US7065654B1 (en) * 2001-05-10 2006-06-20 Advanced Micro Devices, Inc. Secure execution box
US20030009657A1 (en) * 2001-06-29 2003-01-09 Ibm Corporation Method and system for booting of a target device in a network management system
US20030018892A1 (en) * 2001-07-19 2003-01-23 Jose Tello Computer with a modified north bridge, security engine and smart card having a secure boot capability and method for secure booting a computer
US7111050B2 (en) * 2001-08-02 2006-09-19 International Business Machines Corporation Private memory access in multi-node system
EP1283464A1 (en) * 2001-08-06 2003-02-12 Hewlett-Packard Company A boot process for a computer, a boot ROM and a computer having a boot ROM
US7234052B2 (en) * 2002-03-08 2007-06-19 Samsung Electronics Co., Ltd System boot using NAND flash memory and method thereof
US7216369B2 (en) 2002-06-28 2007-05-08 Intel Corporation Trusted platform apparatus, system, and method
US7313684B2 (en) * 2002-08-14 2007-12-25 T1 Technologies Limited Method and apparatus for booting a computer system
US7017038B1 (en) * 2002-08-26 2006-03-21 Network Equipment Technologies, Inc. Method and system to provide first boot to a CPU system
US7424610B2 (en) * 2003-12-23 2008-09-09 Intel Corporation Remote provisioning of secure systems for mandatory control
US7565522B2 (en) * 2004-05-10 2009-07-21 Intel Corporation Methods and apparatus for integrity measurement of virtual machine monitor and operating system via secure launch
US7716494B2 (en) * 2004-07-15 2010-05-11 Sony Corporation Establishing a trusted platform in a digital processing system
US7711942B2 (en) 2004-09-23 2010-05-04 Hewlett-Packard Development Company, L.P. Computer security system and method
JP2006195703A (en) * 2005-01-13 2006-07-27 Hitachi Ltd Operation management system for diskless computer
US8533845B2 (en) * 2005-02-15 2013-09-10 Hewlett-Packard Development Company, L.P. Method and apparatus for controlling operating system access to configuration settings
JP2007025821A (en) * 2005-07-12 2007-02-01 Seiko Epson Corp Information processor and control method therefor
JP4793628B2 (en) 2005-09-01 2011-10-12 横河電機株式会社 OS startup method and apparatus using the same
US8201240B2 (en) 2005-09-16 2012-06-12 Nokia Corporation Simple scalable and configurable secure boot for trusted mobile phones
US7865740B2 (en) * 2005-09-27 2011-01-04 Intel Corporation Logging changes to blocks in a non-volatile memory
US7467295B2 (en) * 2005-10-07 2008-12-16 International Business Machines Corporation Determining a boot image based on a requesting client address
CN100428157C (en) * 2005-10-19 2008-10-22 联想(北京)有限公司 A computer system and method to check completely
US8291226B2 (en) 2006-02-10 2012-10-16 Qualcomm Incorporated Method and apparatus for securely booting from an external storage device
EP1832977A3 (en) * 2006-03-09 2007-10-10 Telefonaktiebolaget LM Ericsson (publ) Platform boot with bridge support
US20070239996A1 (en) * 2006-03-20 2007-10-11 Cromer Daryl C Method and apparatus for binding computer memory to motherboard
US20070235517A1 (en) * 2006-03-30 2007-10-11 O'connor Clint H Secure digital delivery seal for information handling system
US7984283B2 (en) * 2006-05-22 2011-07-19 Hewlett-Packard Development Company, L.P. System and method for secure operating system boot
WO2007135672A2 (en) * 2006-05-24 2007-11-29 Safend Ltd. Method and system for defending security application in a user's computer
US20070288761A1 (en) * 2006-06-09 2007-12-13 Dale Jason N System and method for booting a multiprocessor device based on selection of encryption keys to be provided to processors
US8452988B2 (en) * 2006-07-24 2013-05-28 Michael Sujue Wang Secure data storage for protecting digital content
US7958343B2 (en) * 2006-09-08 2011-06-07 Hewlett-Packard Development Company, L.P. BIOS bootable RAID support
US20080077592A1 (en) * 2006-09-27 2008-03-27 Shane Brodie method and apparatus for device authentication
US8683212B2 (en) * 2006-10-06 2014-03-25 Broadcom Corporation Method and system for securely loading code in a security processor
US7711941B2 (en) * 2006-12-19 2010-05-04 Lsi Corporation Method and apparatus for booting independent operating systems in a multi-processor core integrated circuit
US7925875B2 (en) 2006-12-31 2011-04-12 Sandisk Corporation Systems and methods for identifying and booting a computer architecture
US8032181B2 (en) * 2007-09-01 2011-10-04 Apple Inc. Service provider activation with subscriber identity module policy
US20090204964A1 (en) * 2007-10-12 2009-08-13 Foley Peter F Distributed trusted virtualization platform
IL187042D0 (en) 2007-10-30 2008-02-09 Sandisk Il Ltd Write failure protection for hierarchical integrity schemes
US20090193507A1 (en) * 2008-01-28 2009-07-30 Wael Ibrahim Authentication messaging service
US8082435B2 (en) * 2008-05-07 2011-12-20 Micron Technology, Inc. Memory device initiate and terminate boot commands
US8843602B2 (en) * 2008-05-29 2014-09-23 Co-Conv, Corp. Network boot system
US20100011350A1 (en) 2008-07-14 2010-01-14 Zayas Fernando A Method And System For Managing An Initial Boot Image In An Information Storage Device
TWI389031B (en) * 2008-09-15 2013-03-11 Mstar Semiconductor Inc Embedded electronic device and booting method thereof
US20100122076A1 (en) * 2008-09-30 2010-05-13 Aristocrat Technologies Australia Pty Limited Security method
US20100106953A1 (en) * 2008-10-23 2010-04-29 Horizon Semiconductors Ltd. Method for patching rom boot code
US8504693B2 (en) * 2009-05-26 2013-08-06 Intel Corporation Method and apparatus for operating system streaming
EP2278514B1 (en) * 2009-07-16 2018-05-30 Alcatel Lucent System and method for providing secure virtual machines
US8589302B2 (en) * 2009-11-30 2013-11-19 Intel Corporation Automated modular and secure boot firmware update

Also Published As

Publication number Publication date
WO2012020292A1 (en) 2012-02-16
US8996851B2 (en) 2015-03-31
EP2603874A1 (en) 2013-06-19
TW201212617A (en) 2012-03-16
CN103069384A (en) 2013-04-24
US20120042376A1 (en) 2012-02-16

Similar Documents

Publication Publication Date Title
US10359957B2 (en) Integrated circuit device that includes a secure element and a wireless component for transmitting protected data over short range wireless point-to-point communications
US10142104B2 (en) Securely recovering a computing device
US9092632B2 (en) Platform firmware armoring technology
US8949626B2 (en) Protection of security parameters in storage devices
EP2798559B1 (en) Methods and apparatus for trusted boot optimization
US20160174068A1 (en) Integrated Circuit Device That Includes A Secure Element And A Wireless Component For Transmitting Protected Data Over A Local Point-To-Point Wireless Communication Connection
TWI559167B (en) A unified extensible firmware interface(uefi)-compliant computing device and a method for administering a secure boot in the uefi-compliant computing device
KR101687277B1 (en) Key revocation in system on chip devices
US8688967B2 (en) Secure booting a computing device
US8874892B1 (en) Assessing BIOS information prior to reversion
JP5362767B2 (en) Method and apparatus for checking the safety of a data storage device from a remote server
US8909940B2 (en) Extensible pre-boot authentication
KR101237527B1 (en) A computer system comprising a secure boot mechanism
CN101154256B (en) Methods and arrangements to launch trusted, co-existing environments
JP5476363B2 (en) Computer startup method using biometric authentication device and computer
US7421588B2 (en) Apparatus, system, and method for sealing a data repository to a trusted computing platform
KR101719381B1 (en) Remote access control of storage devices
US9613215B2 (en) Method and system for implementing a secure chain of trust
US8078788B2 (en) Media card command pass through methods
US8613081B2 (en) Apparatus for controlling processor execution in a secure environment
JP4433401B2 (en) Information processing system, program, and information processing method
CN100462918C (en) Operation syste starting method and apparatus using the same
TWI221580B (en) Pre-boot authentication system
US8214632B2 (en) Method of booting electronic device and method of authenticating boot of electronic device
CN100514344C (en) Safety identification method based on safe computer

Legal Events

Date Code Title Description
WITN Withdrawal due to no request for examination